Slashdot Mirror


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."

9 of 147 comments (clear)

  1. What irony! by swordboy · · Score: 5, Funny

    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.
  2. One thing missed by 13013dobbs · · Score: 5, Insightful

    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.

  3. incomplete document by Angry+Black+Man · · Score: 4, Informative

    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
  4. Fingerprint Database by helleman · · Score: 5, Interesting

    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?

    1. Re:Fingerprint Database by Tenebrious1 · · Score: 5, Interesting

      And, unbeknownst to you and thousands of others, the site that maintains the list has been hacked, and you are downloading empty lists that allow every exploit.

      It's a good idea, but there's a problem when you create a central point of failure.

      --
      -- If god wanted me to have a sig, he'd have given me a sense of humor.
  5. Snort by Frums · · Score: 5, Informative

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

  6. Not very interesting by brettbender · · Score: 4, Informative

    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.
  7. Partial solution for log trash by wytcld · · Score: 5, Informative
    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.

    --
    "with their freedom lost all virtue lose" - Milton
  8. What to do after attack? by Tazzy531 · · Score: 4, Informative

    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..."