Apache Hack on port 80

[Nobody's Hero]

I was reading a previous post on hacks on port 80 and to scan the access log for suspicious activity. I am not sure what I sould be looking for that would qualify the entry as suspicious. I would like to write a script but I dont know what I am looking for. Any ideas?

RPM

[Nobody's Hero]

I see that access_log starts with an IP address. Should I be looking for IPs that are outside my network?

[F.J.Llorente Wayfarer]

Hi!

That's right if you're using your Apache server only for serve your intranet. If your server is a public one, that does not make any sense... ;-)

If you're serving only your intranet, it'd be a good idea to configure your firewall to filter out all the incoming traffic to port 80.

My two cents...

-- Wayfarer

[Mark Grant]

Robert,

Apart from the IP address point you raise above, hacks against web servers tend to be pretty obvious when you find them. They tend to attempt to run things (usually ending in .exe" that have failed. Failing that, they will contain a URL that doesn't make sense or contains perl/shell or possibly even very large, ugly looking numbers but usually something fairly obvious like that.

[Steven E. Protter]

You need to be careful about innocuous search engine stuff verus real attacks.. A lot of search engines will assume you are running a Microsoft server and run programs they expect to find.

This will show up in error logs and can be ignored. Hack attacks will create files, gain access and start changing things.

SEP

[Vernon Brown_4 · Accepted solution]

I see many attempts to compromise Windows servers such as a URI "GET /system32/cmd.exe"

You can find them by:

cat /var/log/httpd/access_log | grep cmd.exe
or
cat /var/log/httpd/access_log | grep SEARCH./
Replace the path to access_log to whatever you're using.

You'll know the buffer overflow attempts when you see them because they can be more than 32,000 characters long.

[Martin P.J. Zinser]

Hi,

other typical hack attempts include:

GET /_vti_bin/....
GET /_mem_bin/....
GET /scripts/root.exe....
GET /MSADC/root.exe....
GET /default.ida.....
GET /sumthin....
GET /scripts/nsiislog.dll

Greetings, Martin

[frankb_1]

if you want automated reports install snort. you can configure snort to only show you possible webservices alerts. there is also a webconsole available called ACID which shows you the snort reports in detail very easy.

otherwise, if you dont want to use snort, check also for possible "external include" hacks. if you find urls ending with "=http://xyz.dyndns.org/hack.cgi" or something like that check if the accessed file allows external includes.

the other comments from authors above are also important to check. if you see alot of "x03x73x82x03x73" in your access_log there are possible intrusions going on.

[lowster]

I don't think it realy helps either when your member profile comes up on google does it, because yours is Robert.

[Nobody's Hero]

Can you explain in more detail what you are saying? I have no idea what you mean.


Thanks

[Nobody's Hero]

Christopher, I dont understand your point.

Your profile is accessable via google also. So what is the point?

[lowster]

"I don't think it realy helps either when your member profile comes up on google does it? because yours is Robert".
Sorry, I meant it to be a question, not a point.

Thanks,
Chris.

[Florian Heigl (new acc)]

You don't really need to worry about attacks intended for windows servers, of course.

You should watch out for people trying to POST things to Your server, i.e. to /tmp or shared memory, especially if the server is not chrooted. (failed) buffer overflow attacks appears as very long strings of garbage in the access.log. You should be aware that a successful attack will include removing it's traces. :)

The best point for learning about possible angles of attack would be apache-specific mailing lists where You can get some insight from people that survived attacks.

for the very least, I always try to
- mount $TMPDIR (usually /tmp) noexec,nosuid,nodev
- chroot apache
- run apache on port 8080 only and ipforward 80->8080 (this means no part of apache has root permissions left
- of course run the most current apache version (2.0.53 today)
- have another non-apache webserver at hand in case there are unresolvable problems.

[Paul Cross_1]

Although this will all depend on how your network is setup, but if you are on a private network serving an intranet with a firewall between you and the outside world, there is little point in scanning for external IP numbers. All attacks have to come through your firewall, and will show up accordingly. Check your firewall logs for such attacks.