I am being attacked right now from Tor nodes which are doing 404 requests to my HTTP server. It is from one IP but when i use the DROP iptables rule, it starts again from another IP in a matter of seconds.

It started to ask requests to the cgi-bin folder, but now it is doing requests in my images folder. So based on my investigation it is a tool connected to TOR looking for something and right now it drives me mad.

I tried fail2ban, mod_evasive and mod_security, but those programs get triggered when the other side is looking for one thing or banging at the door at one port. But this tool is looking at every request for a different file.

45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/imgsupport.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/imgppexg.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/imgppantivirussoft.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/imgwin95.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/imgnws.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/imgroundcorner.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/imgppcdl.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/yellowbuy3.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/imgvirusinfo.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/escan4.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/imgredline.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/imgonlinescan.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/ram1.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/imgmanualscan.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/userdefine.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"
45.63.100.91 - - [26/Dec/2016:03:27:17 +0100] "HEAD //images/betterinterface.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; MATBJS; rv:11.0) like Gecko"

You see it is looking in the folder images for a specific .php file, but at every request it is looking for a different php file. So, what the hell is this thing doing?

This also eats up my bandwidth, so I am really desperate what I need to do now. Anyone an idea how I can block this?

Server setup: CentOS 7 (OpenVZ, so I am stuck with a kernel where ipset isn't working) with Apache.

share|improve this question
    
Try upgrading ipset to 6.30 directly from netfilter.org. See if it is the kernel or ipset that is actually broken. – cybernard yesterday
    
Are you getting similar requests from other IP addresses? This looks suspiciously like botnet behavior – John yesterday
3  
These are just HEAD requests - they should be some of the smallest http requests you can get. What kind of bandwidth use are you seeing to make you worry about overall bandwidth use? – Xiong Chiamiov 16 hours ago
4  
Also, if they're getting 404s, that doesn't really matter - it means they aren't successfully finding vulnerabilities. Any filtering you put in place has a decent chance to hurt legitimate traffic, so unless this is actually causing harm to your site, it's best to ignore it. – Xiong Chiamiov 15 hours ago
2  
You can certainly write a custom fail2ban match for this sort of thing. – Michael Hampton 14 hours ago

You could drop packets from tor nodes all together if you like with ip tables. List of tor nodes can be found at:

Ref 1: https://check.torproject.org/cgi-bin/TorBulkExitList.py
Ref 2: https://www.dan.me.uk/tornodes

Here is a bash one liner to block all traffic from tor to your web server. There are currently about 2000 tor nodes online now that support port 80. So you will be inserting quite a few iptable's wouldnt really call this a long term fix but should stop the attack.

wget "https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8&port=" -O /tmp/ip.lst && sed -i -e '1,3d' /tmp/ip.lst && for i in $(cat /tmp/ip.lst); do iptables -A INPUT -p tcp -s $i --match multiport --dports 80,443 -j DROP; done
share|improve this answer
    
Did this and that seems to work. Iptables is piling up with Tor servers now which is a good thing. – Alex yesterday
    
Hmm, it started again...guess not all IP are on that list :( – Alex yesterday
7  
Or your attacker has switched onto a different proxying network. – Xiong Chiamiov 16 hours ago

You can drop packets that contain specific string and apperantely all requests contain: 'HEAD //images/' string.

I suggest the following rule for now and later you can remove it:

iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string 'HEAD //images/' -j DROP

share|improve this answer
    
You could do this, but they just move to different folders, and you will still end up with 100's of rules. – cybernard yesterday
    
If this was the case, the user can block "HEAD " request in the same way and in 99% this will not affect the functionality of the website. – Opaida yesterday
    
Hi, i tried this, but it didn't do much. I even tried it with only HEAD, but it didn't stopped any request. – Alex yesterday
    
Make sure about the HTTP port.. the rule considers you are using port 80 (default). – Opaida yesterday
6  
@Alex It looks OK from here but the best way to ensure this rule is well written is to disable the TOR-related rule you wrote before. Especially knowing that some people can legitimately be using TOR while using your website properly - you don't want to ban these ones. – Shlublu yesterday

If your security model permits passing traffic to third party, then the easiest and most effective solution may be to front your application with Cloudflare. At the time of this writing, Cloudflare pretty much automatically blocks all Tor connection unless they solve a CAPTCHA page and they also have Web Application Firewall you can configure to further filter traffic before reaching your server so the attacker don't consume your server bandwidth.

Otherwise, you may have some luck by configuring fail2ban. fail2ban is a piece of software that puts temporary IP block by changing the OS firewall policy when someone fails authentication too many times. In your case, fail authentication would be someone that keeps 404-ing.

share|improve this answer
4  
atm i can't use Cloudflare because i use a EV SSL. I need to have a business account from them and my business isn't that big yet to pay 200USD per month just for the website. – Alex 23 hours ago

My web server has this all the time, and after months of examining logs I can see there are 100's of different things they will eventually ask for.

One of thousands of bot networks is mapping your apache for vulnerable components. Hoping to get lucky, with a common component that it knows how to exploit. I get bots searching for phpmyadmin all the time. Along with dozens of other things.

Then of course if does get lucky, they will eventually deploy further bad things so they can use your computer for their own nefarious deeds.

Virtualize with something you can install a modern kernel, so you can use ipset. Maybe KVM, docker uses the built-in kernel so that is no good.

There botnet is likely 10's of thousands of computers so you won't be able to effectively block this, especially not without ipset.

Also as long as you are using TOR they have access to even more IP addresses from random people.

Option #2

Replace the HTTP_NOT_FOUND.html.var file found, at least on my system, /usr/share/apache2/error

You could create a HTTP_NOT_FOUND.html.var.php file then change the apache file,/etc/apache2/errors.conf, to point to said file.

Then the 1st attempt would be the last.

share|improve this answer
    
All i found out is that it is a scriptkiddie which found a script to search for something through the TOR network. I'm glad it is not a botnet :) – Alex yesterday

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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