Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
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.
Originally posted by mnauta
Connection attempts using mod_proxy:
220.127.116.11 -> 18.104.22.168:1337 : 2 Time(s)
22.214.171.124 -> mx0.domainsite.com:25 : 2 Time(s)
What this says is that 126.96.36.199 tried to use mnauta's server to connect to 188.8.131.52:1337 ( Isn't that cute ) 2 times, and 184.108.40.206 tried to connect to mx0.domainsite.com:25 2 times.
Mod_proxy does just what it's name implies. It acts as a proxy for connections. In this case it's just letting you know that it didn't allow those 4. There is nothing here to indicate a buffer overflow attempt. Not saying it's impossible, only that there is nothing here to indicate that. An attempt to forge spam headers is more likely.
The first entry, CONNECT attempts to 220.127.116.11:1337 has been a pretty common thing to see in Apache logs for some time now (way before the negative content-length bug) that's been associated with a proxy-scanner. As long as you aren't getting a 200 status code in response to the proxy attempts (and have an updated apache version), then you should be alright. Plus the negative-content length exploit requires you to connect to a malicious server via the vulnerable target proxy and download a file with the exploit payload and at least for the first entry, 18.104.22.168 is not a valid IP address.
On a Fedora Core 3.
I commented out the mod_proxy* lines in httpd.conf and restarted the server, just to be on the safe side. So far it has not affected my site, but I'd really like to know what this is about and googling around i found stuff that related to apache version 1.3x affected by a bug, but they say that 2.0 versions are not. However, 2.0 versions shouldn't return a 200 response unless proxying is *explicitly* set in the config file, which is NOT the case.
On Fedora proxying will actually return a 200 status code even though the proxy attempt failed. Apache will serve your default home page instead of whatever content the proxy was trying to reach. Check the file size of index.html or whatever the default page is and see how that compares to 5436 bytes.
The FC apache config should not allow proxying by default and would need to specifically be enabled for the connect method to work. You can restrict the http methods that are allowed in the config file or use mod_rewrite.
And i do remember doing a minor modification to the index file, which would explain the size difference between the different access attempts. You'll also notice that there are no new access attempts being logged after i commented out the mod-proxy* lines. However, they're not listed in error_log either (should they be there? or is this IP not trying those attempts?).
The attempts should still show up in the error or access log, so your likely not seeing any further proxy attempts. They're pretty common though, so you'll probably see them occasionally in the future. You can ban any persistant abusers with iptables if you like.