Fingerprinting Port 80 Attacks

pg writes "I found an interesting article on www.cgisecurity.com that explains common fingerprints in web server, and web application attacks. It goes to describe how to detect most known, and unknown attacks. This may come in handy when trying to detect another internet worm."

Comments

Re:What irony!

[VA Software]

And with an easily detectable fingerprint too : referer = slashdot.org

incomplete document

[Angry Black Man]

That article doesn't cover too many port 80 exploits. It does cover the most common attacks, but, if you want some more information here is a more complete guide. There are also a lot of language translations of it at the top if you're not the most fluent in english.

Remember, these documenst are written to help server administrators get an idea of what to look out for, not to solve every single port 80 problem out there.

Re:incomplete document

[mwalker]

I hate to rain on your parade, but I believe that while the linked information is Informative, it is not quite On-Topic. The article in question talks about how to fingerprint different exploit strings launched at web servers at the application layer on port 80. The document you linked discusses how to fingerprint the TCP stacks of varying operating systems based on details gleaned from the top 3 layers of the network stack, including timing details, TCP sequence numbers, etc. Specifically it describes how Fyodor's excellent nmap utility fingerprints an Operating System by TCP stack. You may note that you must be "root" to use this capability because you must sniff the raw TCP stream in order to be able to do this. Fingerprinting port 80 exploit strings just requires you to read the http logs...

While fingerprinting an OS is certainly a useful thing, we shouldn't confuse it with a fingerpinting and profiling effort aimed at categorizing and identifying buffer overrun and similar exploits aimed at web servers. Automated run-time detection of these attempts can lead to faster detection and elimination of threats. In addition, this is a passive measure, whereas nmap is an active measure.

Re:It makes me angry

[gorillasoft]

This isn't about improving security after the fact, it's about implementing IDS rules based on identifiable attack characteristics so you can build some useful filters, about checking your logs if you want to in order to determine what may have been an attack and what was really innocuous, and so on.

It's not at all about the security of the server itself.

portblocker

[UUDDLRLRBASTRT]

If your using windows (blech!) you can get a program for free that blocks your port 80, as well as tells you the IP number of somebody attempting to get in. The program is called Portblocker, and the company that makes it is analog X. I often bomb the person who tries to access my computer with telnet requests just to irritate them.

Snort

[Frums]

Hmm, Snort has signatures written for all of these =)

Not very interesting

[brettbender]

This paper includes very loose regex heuristics for requests that "might be" attacks. These may be interesting for anomaly detection, when coupled with an engine that records incidence rate (if you see an exponential surge in 'weird' requests, then maybe you're seeing a worm's infection growth curve ).

But the result of deploying these (say, matching for "%20" in a URI) as intrusion detection system rules would be a high false positive rate.

You would be better off looking at arachNIDS for rules that are more specific and less likely to drown you in alerts.

Re:Not very interesting

[jiheison]

But the result of deploying these (say, matching for "%20" in a URI) as intrusion detection system rules would be a high false positive rate.

From the article:

""%20" Requests

This is the hex value of a blank space. While this doesn't mean youre being exploited, it is
something you may want to look for in your logs. Some web applications you run may use these
characters in valid requests, so check your logs carefully. On the other hand, this request
is occasionally used to help execute commands."

What's your beef?

Re:Garbage requests

[Heem]

I think garbage should be kept in a separate place to the real visitors' log entries.

What i do, is setup virtual hosts on apache, with my domain name pointing at the real website, and my numeric IP pointed at just a blank page, and have them log to seperate files. Since MOST attacks come randomly via numeric IP, and MOST real users come in using the domain name.

Re:Looks good and a TFTP/FTP Question.

[rodgerd]

TFTP has no authentication in the protocol, so the only ACLs you've got are network level ones from TCP wrappers.

All it requires is a misconfiguration on the TFTP server, and you'll be able to fetch and overwrite any file anywhere on the filesystem; I've seen this happen in the real world from time to time.

URLSCAN

[Dego]

Microsoft has a free tool that uses a text config file that allows for the rejection of http requests based on fingerprints. Check here if you are interested. Works pretty well.

Re:One thing missed

[ptomblin]

It's a spammer or a mail bomber looking for form-mail scripts that he can hijack to send his millions of email messages through and make it hard to catch him or block mail from him. They used to rely on finding open mail relays, but except for a few thousand in China and Korea, there aren't that many around any more (and anybody who doesn't want to get spam just blocks everything from sites in China or Korea). So they've altered their tactics.

Partial solution for log trash

[wytcld]

Here's how to get part way there (in this case for Nimda). In httpd.conf:

SetEnvIf Request_URI "cmd\.exe" ATTACK
SetEnvIf Request_URI "root\.exe" ATTACK
CustomLog /www/logs/access_log common env=!ATTACK
CustomLog /www/logs/attack_log common env=ATTACK

<Location />
Order Allow,Deny
Allow from all
Deny from env=ATTACK
ErrorDocument 403 "
</Location>

And then optionally for individual bad directories:

<Location /scripts/>
Deny from all
ErrorDocument 403 "
</Location>

At this point requests for cgi.exe are not being logged in access_log but only attack_log (leave out the attack_log line if you don't want even that much). They'll still show in error_log (but with a shorter error statement). The ErrorDocument line instructs Apache to send back nothing and just drop the connection - not as nasty as a tar pit, but at least you don't waste outgoing bandwidth, generally tighter than incoming for a Webserver. Also, Apache doesn't waste any time checking the file system on these requests, since the rules preclude that.

Re:Securing webservers

[b1t r0t]

Also, you shouldn't let your webserver send any outgoing packets unless they are originating from port 80.

If you're really paranoid, you also shouldn't let your web server send any outgoing SYN packets from port 80. This will help prevent web-exploit worms like Code Red and Nimda from spreading.

Answers.

[mindstrm]

TFTP is udp based. Yes there are ports.
It runs on udp port 69.

And, you hit the nail on the head.. embedded systems.
tftp is 'trivial' so it can be used for bootstrapping systems. The protocol is as simple as it could possibly be (but not fast nor efficient network wise).
It was designed so it could be implemented with very little code in order to bootstrap systems.

Given that.. it really has no reason to be enabled at all in most modern systems.
The only uses I've used it for recently are:
booting diskless clients
cisco router configuration files
embeded systems work

Snort

[TV-SET]

All these reminds me of a good old snort - http://www.snort.org

What to do after attack?

[Tazzy531]

A lot of people here have been asking what people should do after they are attacked. Here is an article/guideline for procedures on recovering after an attack. These steps include information on saving logs, documenting everything that you do after the attack, the type of evidence needed to prosecute, and who to contact (FBI, local police, etc) But as always..the best policy is to secure the system so that attacks don't happen.