7

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

nealmcb
  • 20,544
  • 6
  • 69
  • 116
Thomas Ward
  • 731
  • 1
  • 7
  • 24
  • 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 '11 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. – Thomas Ward Jul 14 '11 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 '11 at 09:02
  • I also agree that it looks like a duplicate of http://security.stackexchange.com/questions/5001/iis-logs-show-someone-is-trying-to-hack-my-site-what-should-i-do, I dont see a difference simply because the webserver is different - can you explain why this shouldnt be closed as duplicate? – AviD Jul 17 '11 at 09:09
  • @AviD This was argued with @Scott in the chat. The methodology for activating preventative measures is far different, as is the fundamental question: "What should I do" vs. "What preventative measures exist" To be more specific, the link you have there has this question: "What should I do with this [log]?" Mine isn't "What should I do", but "Are there any preventative measures to block these?". Those two questions are fundamentally different. – Thomas Ward Jul 17 '11 at 17:43
  • 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 '11 at 18:29
  • I changed the title to help lead people to the useful answers here about fail2ban - that should help. But as always, feel free to revert it :) – nealmcb Jul 17 '11 at 19:43
  • Nope, your edits are worthy. The title seemed to need editing, i agree, @AviD. However, I was on the road most of yesterday so I couldnt edit the title accordingly. – Thomas Ward Jul 18 '11 at 13:04

3 Answers3

10

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 198.51.100.50-m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT  -s 203.0.113.0/24 -m tcp -p tcp --dport 80 -j ACCEPT

This will specifically allow address from the host 198.51.100.50 and the network 203.0.113.0/24. 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.

Scott Pack
  • 15,167
  • 5
  • 61
  • 91
  • 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. – Thomas Ward Jul 14 '11 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 '11 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! – Thomas Ward Jul 18 '11 at 17:22
7

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.

john
  • 10,968
  • 1
  • 36
  • 43
  • You mentioned tools that exist to filter bad ips that are seen in the wild, which tools are those? – Thomas Ward Jul 14 '11 at 17:44
  • See this one for example: https://www.projecthoneypot.org/services_overview.php – john Jul 14 '11 at 18:21
  • BTW: The link to that post in your answer has an invalid security cert. how can I know its trustworthy? – Thomas Ward Jul 14 '11 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 '11 at 18:33
3

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.

Woot4Moo
  • 889
  • 6
  • 10
  • approx. 150 in an hour, on any given day of the week. – Thomas Ward Jul 14 '11 at 17:43
  • how large is your internal user base, the whitelist may be manageable – Woot4Moo Jul 14 '11 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. – Thomas Ward Jul 14 '11 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 '11 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. :) – Thomas Ward Jul 14 '11 at 18:04