This seems to be a fairly easy question to figure out, but I wanted to make sure. I've got about a thousand entries on one of my web servers with phpmyadmin in the connection criterion, but as I don't have phpmyadmin installed, it always 404s. They originate from several former-Soviet-bloc countries, which makes me concerned.

Should I assume these are exploit scans? Further, are there any additional preventative measures which I can implement on the system to block these requests (such as a selective iptables rule or something)?

Server Info:
Ubuntu 10.10 Linux, 32bit.
WebServer: NGINX

  • 2
    Be careful about thinking that an IP address will resolve nicely to a political region. Even with no attempt at deception, IP to location resolving is potentialy unreliable.
    – this.josh
    Jul 14, 2011 at 18:16
  • Given the ranges of IPs are owned by three ISPs which operate in the region in question (as they originate from those countries), its highly likely they're from that region. Jul 14, 2011 at 18:32
  • 1
    You're assuming the IP's belong to the enduser, and were not spoofed/proxied/botneted/Torred/etc...
    – AviD
    Jul 17, 2011 at 9:02
  • I also agree that it looks like a duplicate of security.stackexchange.com/questions/5001/…, I dont see a difference simply because the webserver is different - can you explain why this shouldnt be closed as duplicate?
    – AviD
    Jul 17, 2011 at 9:09
  • 2
    If you're focused on how to respond, then you might want to change the title so people know what you're looking for and what to expect in the answers. But given that the accepted answer in question 5001 is "ignore it", I'm not sure what you really expect.
    – nealmcb
    Jul 17, 2011 at 18:29

3 Answers 3


This is pretty well the background noise of the Internet. Since phpMyAdmin had such a poor security history it is not uncommon to see systems looking for instances of it running on the network. Chances are, that is exactly what is happening. There are a few things you could do to take action on such an activity, though which one, or ones, you choose will depend wildly on how your site is used.

Block It Entirely
Depending on who needs to access your web site, you could insert firewall rules to only allow access from specific addresses or address ranges. For example:

-A INPUT  -s tcp -p tcp --dport 80 -j ACCEPT
-A INPUT  -s -m tcp -p tcp --dport 80 -j ACCEPT

This will specifically allow address from the host and the network Here the benefit is limiting your scope of access to a relatively small set, however you need to know every where access is required.

Rate Limit Connections
IPtables has built in support for rate-limiting. As an example take these firewall rules:

-A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW -m recent --set --name WEB
-A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name WEB -j DROP

What this will do is limit each source address to only 8 connections within 60 seconds. These values may need tweaking, depending on your environment, but will certainly slow down any kind of brute force or fast scan.

Dynamic Detection and Blocking
There are a number of applications for doing this, but they all basically work the same way:

  1. Read specific log files for actionable events
  2. Compare events against some kind of scoring system
  3. Take action if meets criteria

One of the most popular (subjectivity alert) is probably an application called fail2ban. It will process a large variety of logs on your system, including SSH and Apache, and issue blocks for those source addresses that are committing "suspicious" behavior. Typically this would be adding a source IP drop rule in your host firewall. You mention that you are using Nginx as your web server, so you would have to research whether or not fail2ban, or what other product, would work for you.

  • Upvote for being detailed in your answer. Can the iptables module conntrack be used in place of state, as the system in question has the conntrack module, rather than the state module. Jul 14, 2011 at 18:07
  • Should still work. You would have to swap out --state for --cstate and -m state with -m conntrack.
    – Scott Pack
    Jul 14, 2011 at 19:47
  • That shouldn't be a problem. One of my systems has the state module on it, and was getting hit with all of the scanning attempts. The other server has the conntrack module on it. After implementing the steps outlined above, I have rate limited the connection attempts on both machines, which seems to be working for my needs. Thanks for all the help! Jul 18, 2011 at 17:22

Yes, those are just scanning scripts, looking for vulnerable versions of phpmyadmin and other software to exploit.

There are various ways to combat such problems.

One of them is through utilities like fail2ban, that (among other things) can monitor web server logs and ban IPs on the firewall matching your criteria.

In your specific case, look at this post (although you must convert it for nginx)

You can also go the other way around, and automatically filter bad ips that are seen in the wild and categorized as bots, tools exist for that too.

  • You mentioned tools that exist to filter bad ips that are seen in the wild, which tools are those? Jul 14, 2011 at 17:44
  • See this one for example: projecthoneypot.org/services_overview.php
    – john
    Jul 14, 2011 at 18:21
  • BTW: The link to that post in your answer has an invalid security cert. how can I know its trustworthy? Jul 14, 2011 at 18:28
  • Use the http version, they have misconfigured the https one - probably a css file is included over http thats why there's a warning (i use plugins to redirect me to the https of every site that's why i posted the wrong link). will fix it.
    – john
    Jul 14, 2011 at 18:33

Well first and foremost, it appears that they would be from Soviet bloc countries. Second it could be an exploit scanner, but if you don't have the software what does it matter? You would want to whitelist MAC + IP addresses (where static) that are involved with your network operations. How far apart were the requests, are we talking 20 requests over a week or 4000 in a minute? You could look into setting up an IDS to at least see everything that is coming your way, or a step further implement an IPS and monitor those logs actively. If the box that is being scanned is critical I would also suggest pulling it offline for a bit to run analysis on it to see if anything else doesn't belong there.

  • approx. 150 in an hour, on any given day of the week. Jul 14, 2011 at 17:43
  • how large is your internal user base, the whitelist may be manageable
    – Woot4Moo
    Jul 14, 2011 at 17:46
  • define "internal user base" in the context of a site which runs multiple forums - do you mean the number of users who use each forum? if so, its not a manageable list... over 200+ users who are legitimate users per day over 3 forums on the site. So on any given day, between 400 and 700 users who are legitimate users are accessing the system. Jul 14, 2011 at 17:49
  • Ahh. I was not aware it was a public application. Could always break out the ban hammer on the whole ip block then and wait for people to say hey I've been banninated. Or throttle connections
    – Woot4Moo
    Jul 14, 2011 at 18:02
  • I very rarely run internal applications of web servers (or severs in general) except those which sit on my development environment (laptop), for which I test modifications to pages and new PHP scripts prior to sending to production, or when its an intranet (in which case its already behind a NAT, and is not Internet-facing). But as this is a public application, I will likely consider using fail2ban as well as connection throttling. :) Jul 14, 2011 at 18:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .