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."
I'm sure that the server that the article is posted on is getting a nice "attack" on port 80 right now!
Life is the leading cause of death in America.
formmail script exploits. Due to post 25 blocking, spammers are looking for exploitable formmail scripts to send their spam through. I guess the author just wanted to talk about root exploits, but there are other ways to abuse a web server.
No replies made to AC posts. Please log in.
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.
the byproduct of years of oppression by the white man
I think there is some value to this article for new admins - it highlights most of the common things you will see in your log files if someone is poking at your site.
By the same token, most well-written CGIs will block these sorts of attacks (and hopefully if you are writing CGIs you will have enough knowledge (and common sense) to write them in a reasonably secure manner).
At the least it's worth a quick five-minute scan.
/~mikeg
I'd love to see a plugin for apache that allowed a central server fingerprint database for new exploits.
Every hour or so, a web server could access a central fingerprint server and download what the latest exploits look like. If a exploit comes in, the server could deny that IP, or drop those accesses without needing to know what the particular exploit is. A self maintaining web server via the web.
What do you think?
Yes, I know I could grep 'em out while viewing, but I think garbage should be kept in a separate place to the real visitors' log entries.
NO TOUCH MONKEY!
I do have a question for my fellow slashdotters: Why does the author single out TFTP but not FTP? Does TFTP have inherrent weaknesses that would make it the file transfer protocol of choice for an attacker?
"Prepare for the worst - hope for the best."
Hmm, Snort has signatures written for all of these =)
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.SetEnvIf Request_URI "cmd\.exe" ATTACK /www/logs/access_log
common env=!ATTACK
/www/logs/attack_log common env=ATTACK
SetEnvIf Request_URI "root\.exe" ATTACK
CustomLog
CustomLog
<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.
"with their freedom lost all virtue lose" - Milton
Among the utilites mentioned like snort, no one has hit on the actual fingerprinting utilities out there like nmap, nbtscan and something like portsentry.
/ect/hosts.deny and rereads hosts.deny and passes the address off to nmap or nbtscan to figure out what the box is running.
I forget off the top of my head if portsentry has scriptable events, if it does then the possibility of having a "guarddog" type box would be interesting.
For instance, if attack is detected portsentry and it does its thing by putting the offending adderss in
Nothing beats calling up an ISP and saying "you have a windows/linux/whatever box probing for webservers/mailservers/(insert service) and is attempting to execute a vulnerability of that service".
Nmap and Nbtscan are excellent utilities, but from using them and playing around, nmap is more of a discovery tool, nbtscan is more of a retalitory tool. Or, at the very least they both can be used as such.
I know from personal experience that nbtscan's default setting (normal, aggressive, insane) is enough to knock a box off of a network.
I scanned my cable modem...had to power down to get back up and knocked my boss off even with his knowledge...only a complete power down would bring the box back on the network.
If you can have a "honeypot" why not a "watchdog" box for computer security?
Has the "security/watchdog" been done before?
If it is not on fire, it is a software problem.
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.
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
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
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.
_______________________________
"I'm not Conceited...I'm just a realist..."