39

My website gets thousands of hits daily from different IPs trying to access:

/php-myadmin/
/myadmin/
/mysql/

...and thousands of other variations. None of these directories exist, I don't even have phpmyadmin on my server.

I don't think any of these attempts have been successful, however they must be taking their toll on the server's resources and wasting bandwidth, so I would like to stop them if possible. I've blocked a handful of these IPs but they keep coming back with fresh IPs, is there any way I can prevent this more permanently?

masegaloeh
  • 18,236
  • 10
  • 57
  • 106
amba88
  • 513
  • 1
  • 4
  • 4
  • 8
    Thousands of hits per day is nothing. Are you actually experiencing performance difficulties or are you just assuming? A few thousand 404s in a day is really *nothing*. – MDMarra Jan 08 '14 at 01:11
  • No I'm not experiencing performance issues. But it's annoying me and I wondered if there's anything I can do. – amba88 Jan 08 '14 at 01:16
  • 6
    Be careful with IP-based blocking - a lot of IPs end up getting cycled to legitimate users. Also, some legitimate users may be infected as part of a botnet. If you do any IP-based blocking, please make sure it has a reasonably short expiry. – Bob Jan 08 '14 at 05:23
  • No mention of `mod_security` in this thread, so [check that out](http://mbrownnyc.wordpress.com/technology-solutions/create-a-secure-linux-web-server/install-mod_security-for-apache-2-4-x/). Note a comment below notes that this would actually cause more work to be done by the server of course. So maybe `mod_evasive` would also be good [to implement](http://mbrownnyc.wordpress.com/technology-solutions/create-a-secure-linux-web-server/install-and-configure-mod_evasive-for-apache-2-4-x/). `fail2ban`, but that's listed below. – brandeded Jan 14 '14 at 20:08

7 Answers7

41

Don't worry about it. Serving a 404 is a tiny, tiny, tiny amount of work for a web server to do. You could probably serve ten 404's a second using a 486. The bandwidth per 404 is negligible; a tiny GET request and a tiny 404 response.

Seriously; don't worry about it. This is just part and parcel of running a server on the internet.

Mark Henderson
  • 68,823
  • 31
  • 180
  • 259
  • 14
    Hell-Banning: Serve a normal page (200 OK) with gibberish output. The tools the kids use will report page found and they'll need to investigate by hand (a fake login page would certainly be a devil-device) :) – arul Jan 08 '14 at 12:23
  • 4
    @arul - Some attackers might take this as a challenge and pay extra attention to your server out of spite. Would serving a smaller or different 404 be at all useful here? For example if the host normally serves a 404 with a support link, should/could it instead serve a plain 404 with no content to these targeted urls? – Freiheit Jan 08 '14 at 14:28
  • 1
    The purpose is to make the adversary spent additional resources (time) to analyze the results. If you get a 404 you know that there's been no possibility for the attack to work. Variable-length OK result are [without further investigation] indistinguishable from expected results. They run these scans because patience is not their virtue, so demotivate the hell out of them and they'll stop :) – arul Jan 08 '14 at 16:09
  • 1
    For bonus points, return a static page that looks exactly like the real phpmyadmin page, but is entirely non functional. – captncraig Jan 09 '14 at 07:56
  • 1
    For additional bonus points, build a delay of 0.5 - 1 second. This will not significantly increase time for loading by legitimate users but it will slow down the scanning that the bad guys are doing. (You just need to make sure that your server has the capacity to hold connections open for longer than necessary and still process legitimate requests.) – Moshe Katz Jan 10 '14 at 06:50
  • 1
    Note that string matching (e.g. mod_sec, or anywhere else) is actually just going to make the server work harder than simply sending a 404 (that wasn't suggested, I'm just noting it here in case someone was considering it). These really are just noise you can safely drown out, provided that your setup is properly secured. – Tim Post Jan 12 '14 at 09:34
  • Login process (on linux at least) uses the same "demotivational" approach like suggested here (increasing the delay in unsuccessful response). This affects any botnet scanning your login page, as it increases the time needed to finish scanning your domain with a complete list of passwords they have, so your domain always shows as slowest in their logs and eventually they don't want to waste time any more with you. They're usually after a quick win, unless they targeted you for a reason. In that case read about [fail2ban](https://github.com/fail2ban/fail2ban/wiki/How-fail2ban-works). – Mladen B. Jul 16 '23 at 10:10
38

Unfortunately for You this is how Internet works. Just ignore it. Thousands of bots/trojans scan the Internet. Source IP will be always random. There is no cure.

The only 100% solution for eliminating that traffic is illustrated below: enter image description here

An alternative is:
- to move with https/http from port 80/443 to something else. Bots usually don't look for http server on all other 65k ports.
- use VPN to connect to the server (I guess this not possible if You host a public website).

Bartłomiej Zarzecki
  • 1,726
  • 1
  • 13
  • 17
  • LOL +1 for the diagram :-) I have this annoying issue (as do we all) on a static site and this is the most useful answer. – Dave Everitt Jul 16 '18 at 12:40
32

What you want is Fail2ban (assuming this is a linux machine, you didn't say...)

What is Fail2ban?

Fail2ban will parse system logs, looking for particular regular expressions to block. When it finds a match (or several matches from the same IP, depending on how you configure it), it will block, typically through IPTables. Typically this is used to block failed authentication attempts against SSH or web servers.

You configure it to ban them for a set amount of time (could be minutes, could be days...depends on how persistent they are), after which the ban will expire, unless they try again.

How does this help block phpmyadmin scanning bots?

It can just as easily be used to match common signs of an attack, like trying to access non-existent phpmyadmin folders. You will have to figure out the correct regular expression to match such attempts, and ensure you don't block legitimate users.

The configuration given in this blog post may work verbatium or require some tweaking for your setup.

Why should I block them? The 404 errors don't cost much

Blocking them in iptables DOES have some use - odds are if they are checking for phpmyadmin vulnerabilities, they may try other services for vulnerabilities as well, until they hit something that works. Banning them will make most bots/scripts give up after awhile, and they'll move on to better targets.

Even through the scans don't cost much (unless they actually find a vulnerability), they do flood your logs making it harder to see successful attacks and problems with your web server.

As the comment below says, Fail2ban does require some system resources. But not much. At the very least I can say I've never had a performance problem I could attribute to Fail2ban. I have however had performance problems from very aggressive scripts trying to brute force passwords or throwing thousands of SQL injection attempts and other exploits per second at my server. Blocking them at the firewall level takes FAR fewer resources than blocking them at the server/application level. It can also be extended to run custom scripts to ban IP addresses - so instead of banning them in IPtables, you could possibly have it ban them in a hardware firewall, or email someone if the same person keeps trying to attack you so you can complain to their ISP or have your datacenter block them on their firewalls.

Any other tips?

It is HIGHLY RECOMMENDED that you whitelist a few IP addresses that you control so you don't accidentally lock yourself out.

Grant
  • 17,859
  • 14
  • 72
  • 103
  • 6
    that will be a waster of resource :) I think You will use more CPU cycles on Fail2ban than on simply serving sometimes 404 :) – Bartłomiej Zarzecki Jan 08 '14 at 02:35
  • 5
    @BartłomiejZarzecki Better security always require more resources – user11153 Jan 08 '14 at 09:34
  • @user11153 I wouldn't call it security if you ban after the attempts. – heinrich5991 Jan 08 '14 at 11:11
  • 3
    @heinrich5991 it will block after the *first* attempts. Makes no difference for some scans, but a huge difference for scans that try multiple attempts on the server. – Grant Jan 08 '14 at 13:04
  • 2
    Fail2ban (or similar) will hopefully be for more than just /phpmyadmin. Assuming he has any kind of remote access, F2B type blocking (3 passwords and you... are... gone!) is for more than just 404s. – WernerCD Jan 09 '14 at 03:07
  • 3
    If you do something like this, make sure to set the ban to expire relatively quick (some hours, at maximum), or you risk locking out legitimate users if the attack comes from a dynamically allocated IP. – Jens Neubauer Jan 09 '14 at 13:57
  • 1
    @JensNeubauer yep. You also have to watch out for people behind proxy servers or carrier grade NAT boxes, since a whole group of users will share the same IP address. – Grant Jan 09 '14 at 13:59
8

What I do is putting a small script into the appropriate directory, so it runs if someone accesses /phpmyadmin/ . That script does nothing else but invoke iptables (under Linux), which blocks the IP address accessing the script for 30 minutes (after which a cron-job flushes the iptables chain the IP address gets added to).

The advantage over fail2ban is that you don't use any resources for parsing the syslog/access-log. The disadvantage, of course, is that you don't check for anything else, except accessing this very specific address.

Why do I do this? Sure, serving a 404 would be easy for the server, but I don't want them poking around, simple as that. I want to waste their tool's time, waiting for the server to reply, retrying until it finally gives up. In addition, if you do not block them, they'll try a lot of different URLs before finally moving on - sometimes over a thousand. Depending on the tool, it might be "nice" and space those out over a few hours, or it might just not care and pound your server with all of them within minutes.

Why don't I serve a valid page? Their tool might stop scanning you and alert the skiddie that's running it - who then has to check out the manually. The flipside of this is that they will give your server a much closer look than they would have, if their scan didn't make you turn up in their results. Maybe they'll poke around a bit more, maybe a few port scans, maybe you get them mad, and they launch a DoS to see if they can do anything. Simply blocking them - which from their point of view makes the server time out the moment they access the phpmyadmin script - is effective wasting their tool's time, while avoiding unwanted attention.

If you DO have phpMyAdmin on the server, an effective solution may be putting it in a separate directory, and use your web-server's password control (.htpasswd for Apache) to block access before anything ever reaches it.

Aaa
  • 261
  • 2
  • 7
  • Sounds like a good alternative option...but doesn't that require the web server to be able to run the script with root permissions? – Grant Jan 08 '14 at 18:29
  • 1
    Adjust the alias for tools like phpMyAdmin. Simple change to the config file to change it to adminMyPhp or chrisPhpAdmin... or something that won't be script-kiddied. – WernerCD Jan 09 '14 at 03:10
  • Sorry for the late reply - it does not (necessarily). You can use sudo (with the sudoers file) to allow the web server to execute one well-known script (and just that script) with root permissions. That script would accept (as parameter) the IP, and you check it against a regular expression ([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+) to make sure it isn't injecting anything odd. – Aaa Mar 05 '14 at 17:35
1

FWIW we restrict access to /phpmyadmin/ to whitelisted IP Addresses only.

We also use mod_evasive (on apache2) to deter DOS / poorly behaved scripted attacks.

user204880
  • 11
  • 1
1

bind the mysql admin tool to your machine loopback address 127.0.0.1

then use ssh with port forwarding to access your admin back end.

add an extra layer of security which can be quite transparent.

The Unix Janitor
  • 2,458
  • 15
  • 13
-4

The best way we've found is to password protect the folder that phpmyadmin is in. Also, don't use anything that relates to phpmyadmin as a folder name: pma, phpmy, etc...

WeWatchYourWebsite
  • 1
  • 2
    From the question: `None of these directories exist, I don't even have phpmyadmin on my server.` - He's not asking how to harden his existing installs... he's asking what to do about stuff that doesn't exist. You can't rename `PMA` or what have you if it doesn't exist. – WernerCD Jan 09 '14 at 13:54