0

There are many scans for php files on my server, though I don't use php. I used the following rule to block those guys -

iptables -I INPUT -p tcp  --dport 80 -m string --string 'php'  --algo bm -j DROP

Is this rule OK? When I used this without the dport, I ended up losing the admin url, because the admin url page had the string php somewhere in the body. I want to scan only the urls, not body. How can this be done? The failed scans are causing issues when I do a performance scan of the log files. For example, I have these entries

. /phpMyAdmin/scripts/setup.php | 4,750 total ms | 475 avg ms | 584 max ms | 10 calls 
. /myadmin/scripts/setup.php | 4,309 total ms | 478 avg ms | 698 max ms | 9 calls
3
  • If you would like more assistance in troubleshooting a noticed performance issue, please provide implementation details (OS, web server software/relevant modules, scripts/packages served, and any other relevant details). Please also note the symptoms of the issue and any patterns. And please note if these scans are coming from diverse or single ip addresses (it may be better to just block a malicious IP than attempt to stop its attack vectors). – Daniel Widrick Feb 24 '14 at 17:24
  • 1
    This is not a 'performance' issue - i.e. it is not slowing down the system. This is an issue when I create performance reports of our web-site - data about all these scans also get into the output. I can just do a grep -v php on the output and get rid of it. – Jayadevan Feb 25 '14 at 2:28
  • grep sounds good to me ;) – Daniel Widrick Feb 25 '14 at 5:10
4

Ignoring the fact that your rule as written scans every single packet destined for port 80 on your server for the string "php" - the rule is ok. I'd suggest using the string ".php" instead, so less things are potentially matched.

The truth is, to block this traffic which isn't really bothering you in the first place, should be done either by a filtering frontend proxy or by your webserver if it's able to.

To be clear, this isn't the type of problem that iptables is meant to solve.

5
  • +1. And no, the rule is not ok because there is a difference between .php (file extension) and php in "NewsAboutPHP.html" (as you said). But generally this is really not waht IpTables is meant to do. – TomTom Feb 24 '14 at 13:42
  • OK. Thanks for pointing out the issues. I am a newbie to iptables/networking. So does this rule scan the entire content? Can I limit it to scan only the url that is being requested? I felt it is better to filter unplanned requests as early as possible - i.e. before it hits our nginx server. – Jayadevan Feb 24 '14 at 14:13
  • No, you cannot limit it to scan only the URL that is being requested. This rule scans the entire everything that is tcp destined for port 80 on your server. It would be best to do your filtering on your nginx server. As I said earlier, do not try to solve this problem with iptables. – etherfish Feb 24 '14 at 14:16
  • Right. Will do that. – Jayadevan Feb 24 '14 at 14:24
  • It's also important to note that this iptables rule will be utterly and completely useless in an SSL/HTTPS sense as iptables will have no way to decrypt and inspect the encrypted packets. – Daniel Widrick Feb 24 '14 at 17:26
3

This would likely be better handled by apache / whatever your web server is.

As for this being a good iptables rule: It is clearly not. It seems you don't fully understand what it is doing / the implications of implementing it. Something this broad is quite likely to break a great handful of things.

We understand our traffic flow an limit tcp SYNs to keep malicious bots from scanning our web infrastructure.

Finally:

The proper solution to this issue is to properly secure and harden any web applications that you run. A scan is not dangerous in itself. A scan only reveals potential holes. Hiding those holes behind a firewall is not an ideal solution.

7
  • I felt the scans may be consuming some resources (search for file, not found, return error) and wanted to avoid that. – Jayadevan Feb 24 '14 at 14:16
  • If you have proof of an adverse affect of these scans feel free to post here and we can guide you through resolving any issues. If it is just a 'hunch' that you are being adversely affected by these scans, I'd say you are better off ignoring them. We deal with scans like this day in and day out. It's part of 'doing business' on the web. – Daniel Widrick Feb 24 '14 at 14:19
  • One obvious issue is the log file size growing in size. This may be better - stackoverflow.com/questions/8286214/… ? – Jayadevan Feb 24 '14 at 14:27
  • See the man pages for logrotate: linuxcommand.org/man_pages/logrotate8.html – Daniel Widrick Feb 24 '14 at 14:28
  • That I already have in place. I scan the log file to check performance of the pages - max/min/avg load . So these entries get annoying - they also come in the output. I guess cleaning the file before parsing should be possible. – Jayadevan Feb 24 '14 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.