Apache 2 on Linux Red Hat 7.3: have I been hacked?
 

Hi guys!
I was reading access_log file in my apache 2 webserver installed on a Linux Red Hat 7.3 box and I noticed the following lines:

remote_host - - [29/May/2003:18:37:53 +0200] "GET /default.ida? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucb
d3%u7801%u9090%u6858%ucbd3%u7801%u9090%u
6858%ucbd3%u7801%u9090%u9090%u8190%u00c3
%u0003%u8b00%u531b%u53ff%u0078%u0000%u00
=a HTTP/1.0" 404 812

remote_host - - [31/May/2003:02:10:27 +0200] "GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir" 404 812

remote_host - - [31/May/2003:13:37:06 +0200] "CONNECT 208.254.5.170:25 HTTP/1.0" 405 737

remote_host - - [01/Jun/2003:18:12:22 +0200] "SEARCH / HTTP/1.1" 501 736

remote_host - - [02/Jun/2003:07:11:36 +0200] "CONNECT maila.microsoft.com:25 / HTTP/1.0" 405 743

remote_host - - [07/May/2003:09:29:51 +0200] "GET / HTTP/1.1" 200 1583

remote_host - - [03/Jun/2003:13:01:34 +0200] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 789

remote_host - - [03/Jun/2003:03:41:19 +0200] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 789

remote_host - - [03/Jun/2003:03:41:27 +0200] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 789

remote_host - - [03/Jun/2003:03:41:35 +0200] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 789

remote_host - - [03/Jun/2003:03:41:43 +0200] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 789

remote_host - - [03/Jun/2003:03:41:50 +0200] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 789

remote_host - - [03/Jun/2003:03:41:57 +0200] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 789

remote_host - - [03/Jun/2003:03:42:05 +0200] "GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 789

And so on. There are tons of these lines (with different remote hosts).
(of course in all the lines above I've changed the real remote host with 'remote_host')

I'd like to know: what damn are they trying to do to my webserver (that, anyway, works fine... or it seems so)?

I think that those attacks are intended to windows servers, but my machine is Linux... they can't do anything, right?

How can I block them?
How can I see if they've made catastrophes?

How can I let them know that I undestood their game?

Am I running risks?
Should I do something?
If yes, what should I do?

Thanks to anyone who can help me.
:) :)

Could be an attack on a windows server as you say. i wouldn't worry if your on the net you'll get lots of these, ALL THE DAMM TIME.

NO you didn't got hacked. That is just someone scanning your system for the IIS UNICODE vulnerability, but since you are running an apache server it's worth shit :)

No need to worry m8, that's just a scanner :) Apache isn't vulnerable for the UNICODE hole :)


edit: as you can see he's trying to access the cmd.exe but you're on linux so you don't have an cmd.exe (even if you're running apache in windows that wouldn't work)

Your first two questions being handled fine, I'll go for the next ones:

How can I block them?
Keeping in mind these probes where directed at IIS (the Incredibly Insane Server), and if this is a public webserver then the first thing before deciding to block would be to realize that if you block by address or range with the wrong app this could have averse effects. So, what options are open for dropping packets?
- Best option: using and IDS like Snort + one of it's 3rd party contributed apps like Guardian. Snort doesn't care for traffic unless it matches a signature that marks it as malicious, then it fires off an alert (and allows you to save the offending packets for inspection). Guardian then can fire off a blocking rule for Netfilter (iptables, ipchains) or a null-route.
*Snort also has a feature called "flexresp". Read this on why *not* to use it.
Other ways of dropping packets using Snort:
Snortsam: http://www.snortsam.net
Hogwash: http://hogwash.sourceforge.net
Snort-inline: http://www.snort.org/dl/contrib/patc...ort-inline.tgz

- Not-so-good option: using a "scan detector" app like Portsentry. Read this on the difference between Snort and Portsentry.
In short Portsentry doesn't care for what contents a packet has, but only looks at the port it trips. That's BAD.

How can I see if they've made catastrophes?
For this you need to have an exact picture of how the system state was before you started having doubts. Filesystem integrity apps like Aide, Samhain or tripwire can provide you with such "snapshots".
Save their binaries/databases on read-only media and check regularly.

How can I let them know that I undestood their game?
I'd say: don't. Ppl who scan your box thrive on any attention, plus you haven't got anything to gain from such actions. The best way would be the silent way: making sure your box is secure.

Am I running risks?
We all run risks and you cannot avoid calculating in some margin of error. Just make sure you pick up the security basics and stick to them.

Should I do something?
If yes, what should I do?
Check out the LQ FAQ: Security references. Especially post #1. Some basic actions could be to:
- Check out the basics like the checklist, top 20,
- Make sure you read up on breaches of compromise *before* it happens,
- Remove all apps, libs and dev stuff that is not necessary for operating it as a webserver,
- Ensure all apps and libs that remain are updated regularly and keep informed of any of your vendor's SO bulletins,
- Remove any users that aren't necessary for the box purpose,
- Run processes as un- or lesser-privileged users whenever possible,
- Place limits on users and processes,
- Audit your webservers setup and any scripts involved regularly (basically the whole LAMP thing, not just the conf files),
- Audit your system regularly,
- Check your logs regularly,
- Make sure the firewall doesn't allow traffic that doesn't fit in the purpose of the box,
- Use TCP Wrappers to deny access where necessary (admin sshd for example).

THANK YOUUUUUUUUUUU!!!!!!!!!
You're really great!
;-);-);-);-);-);-);-);-)