Odd HTTP requests. What's going on? Some kind of attack?
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Odd HTTP requests. What's going on? Some kind of attack?
Starting a few weeks ago, I received daily munin warnings that my webserver's loadaverage was spiking. These spikes only lasted a few minutes so it took me a while to find out what was causing these spikes. It turned out that it was caused by a huge amount of weird HTTP requests.
When I looked at my log files, I saw a lot of strange traffic coming from a lot of different IP addresses. All requests were for existing pages, but with some added junk at the end of the URL. I suspect this is to counteract caching. Also, a lot of the requests weren't "GET" requests, but "HEAD" requests.
Everything in blue are legitimate URLs on my server. Everyting in red is added junk.
So what's going on here? Is this an attack? I see these kind of requests all day long, but only sporadic. But during about 5 minutes starting at 3pm, the shear number of requests almost croaks my webserver.
Last edited by unSpawn; 09-12-2012 at 08:24 PM.
Reason: //Ditch the BB size tag
Interesting. Looking for "%26sa%3DU%26ei", "&sa=U&ei=" and "=AFQjCN" shows these "&sa=U&ei=.*&ved=.*&usg=" turn up everywhere from the SANS ISC diary and Jsunpack to Stackoverflow and even a Chillingeffects DMCA notice ;-p The only thread that talks about a reason says the posters' "Google Enhancer became incompatible" with Firefox" but without any proof or technical detail. For the IP addresses I could check I found they were not that different, basically two AS numbers they come from: AS 2899 (majority) and AS 30663. The first one is owned by "Solution Pro" and the related domain names spro.net and micron.net have been blacklisted in rfc-ignorant.org for more than or nearly 10 years now. If your software doesn't accept these parameters then this isn't a threat. If you want to sanitize requests and protect yourself I suggest you check out mod_security.
It seems that every httpd child process created turns to dead and that MaxClients is reached quickly.
The memory is getting full, and the swap increases up to max until the machine hangs.
When I react quickly, "killal -v httpd" command solves the problem, showing hundreds of dead httpd process.
Unfortunately, the only thing I could do was filter out these requests in my cgi scripts. So the requests are still there but since the cgi scripts immediately exit when they encounter these requests, it no longer has an effect on server performance.
Best way of course is to simply block any traffic from those ip-ranges.
Next time you click a search result in Google watch the actual url sent. Goole have started adding all sorts of tracking crap to the end of the actual site url's in their search results links.
Next time you click a search result in Google watch the actual url sent. Goole have started adding all sorts of tracking crap to the end of the actual site url's in their search results links.
Hello NyteOwwl,
This is not tracking generated by a click in Google search result : these are many HEAD requests (and some GET) coming from different IPs in a short time.
The interesting part of your answer is your suggesting of something like Google tracking. As far as I can understand Google tracking, it returns data to Google from the client's browser. In our case, I don't see how the server could act in this way.
First of all : For me, the problem arises in a Joomla! 1.5 of 2009 with a Fireboard forum.
It may look like a DDOS since many queries are coming at once from different IPs inducing heavy load and even crashing the server.
When I clear the httpd process with "killall httpd":
- I see many "[warn] child process xxx still did not exit, sending a SIGTERM"
- each process close sending "PHP Fatal error: Call to undefined method \xf0\xdd\x95::\xf0\xdd\x95() in .../public_html/libraries/joomla/session/session.php on line 135" to error.log.
What I guess :
- the load and the crash are due to the httpd process not being able to exit and the creation of many new httpd process.
- the httpd process is not able to exit because of the Joomla! session object not being destructed.
It seems to me that it isn't an attack : the goal of the offender seems to fool Google with simulated clicks on search results (thank you NyteOwl). The targets of the HEADs requests are some posts in a Joomla! Fireboard forum. These post have for long been deleted, but I remember they were the usual spam containing long links of pills or watches sites.
0. For using Joomla 1.5 you're SOL in my book (http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=joomla) regardless of whatever else problems you have. You just don't have any valid compelling reasons to keep a unsupported, deprecated, vulnerable version alive.
1. There's a fundamental difference between regulating traffic at the network and application level. As a consequence some of the application level problems you have experienced could have been avoided completely.
2. Not following and responding to advice earlier in this thread means you re-invent the wheel over and over again.
In the preferred order:
- If your software doesn't accept these parameters then, stability sure, but it isn't a security threat.
- Until you prove otherwise blocking AS 2899 and AS 30663 prefixes (ipset) wards off that traffic.
- There are very simple iptables rules to limit the amount of new HTTP connections (examples: 0|1).
- Simply allow only the HTTP methods you need and no, you don't need the HTTP equivalent of "ping" requests.
- If you want to sanitize requests check out mod_security.
0 : I agree, but not my choice;
1 and 2 : you are perfectly right.
I will follow your advice.
iptable and mod_security: Ok, I can do that.
ipset : could you explain what are these prefixes and how to configure ipset with it.
ipset is part of netfilter, which is the underlying component of IPTables, your system firewall. It is more suited towards action like blocking whole ranges of IPs.
Edit: I too disagree with the premise of running severely outdated systems. You have a responsibility to make sure that whomever is dictating this action understands and takes responsibility for the consequences.
ipset is part of netfilter, which is the underlying component of IPTables, your system firewall. It is more suited towards action like blocking whole ranges of IPs.
I understand ipset, but not what are the AS 2899 and AS 30663 prefixes unSpawn mentioned.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
