Forum Moderators: open

Message Too Old, No Replies

Bots start looking for back.zip, backup.zip, etc.

Get rid of those if you have them in root.

         

SumGuy

1:26 am on Apr 5, 2019 (gmt 0)

5+ Year Member Top Contributors Of The Month



Is there a forum specifically for discussing (or alerting to) mal-behavior of unidentified or unidentifiable systems / browsers / bots / hosts? I'll post this here and see if it gets moved...

Starting March 31 and happening about once or twice daily, I'm seeing requests for these files:

1.zip
back.zip
backup.zip
cackup.zip

So this is a heads up if you create files with those names in your root directory for temporary or local use.

All the above requests resulted in a 404. These are just fishing attempts, but what has tweaked the bots to look for those specific files, all of a sudden, I don't know. In all of 2018 I don't think I've seen a single example of requests for zip files like that. In 2017 I did see requests for a wider variety of .zip files:

dump.zip
dump.sql.zip
db.zip
dl.sql.zip
htdocs.zip
web.zip
sql.zip
website.zip
www.zip
wwwroot.zip

lucy24

5:47 am on Apr 5, 2019 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Well, there's the Website Security subforum [webmasterworld.com]. But it's true that a lot of things end up in SSID :)

A simple remedy is to flat-out deny access to anything ending in .zip, or more narrowly constrained as
^[^/]+\.zip$
or
^([^./]+\.)+zip$
or whatever fits your site. This won't affect anything you personally do with the zip files, since access controls apply purely to HTTP requests, and you're presumably doing your stuff in FTP-or-similar. You might choose to return a manual 404 (in a RewriteRule it's flag [R=404]) which saves your server the trouble of looking, but gives no further information to the asker.

Trickier of course if you really do have downloadable zipped content (I do); then you need to constrain your rules even more tightly.

:: quick detour to logs ::

Oh, gosh, will you look at that.
139.199.200.abc - - [14/Apr/2018:10:41:31 -0700] "HEAD /wwwroot.zip HTTP/1.1" 403 193 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)" 
139.199.200.abc - - [14/Apr/2018:10:41:31 -0700] "HEAD /\xd0\xc2\xbd\xa8\xce\xc4\xbc\xfe\xbc\xd0.rar HTTP/1.1" 403 193 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)"

185.56.81.abc - - [03/Apr/2019:11:17:21 -0700] "GET /cackup.zip HTTP/1.1" 403 3424 "-" "Opera/9.80 (J2ME/MIDP; Opera Mini/5.0.16823/1428; U; en) Presto/2.2.0"
185.56.81.abc - - [03/Apr/2019:11:17:21 -0700] "GET /backup.zip HTTP/1.1" 403 3443 "-" "Opera/9.80 (J2ME/MIDP; Opera Mini/5.0.16823/1428; U; en) Presto/2.2.0"
et cetera. They're in alphabetical order and I haven't archived last year's logs yet, hence the time spread. Happily, all the unwanted ones seem to have got a bona fide 403 with no action required on my part. A great many of them are HEAD requests; you can see where even a malign robot might want to wait and see “Now that I know this exists, is it worth downloading?”

blend27

12:32 pm on Apr 10, 2019 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I've also seen these patterns over the years. As a matter of fact that is a part of blocking routines to capture IPs that are looking for those file URIs.

A while back I trained myself to just rename(programmatically) the files to have a different extension, something like ".whateverfloatstheboat". Then when if the file is downloaded rename it back to ".zip" if I need to open the archive.