OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Lamont Granquist (lamont_at_scriptkiddie.org)
Date: Fri Aug 30 2002 - 21:26:24 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    One thing to note is that on FreeBSD systems there's a sysctl called
    net.inet.icmp.icmplim which determines the number of closed-port RSTs that
    a box will give out per second, which is normally set to 200. When I try
    with the options that you give below I get the following spammed in the
    syslog of the target FreeBSD box:

    Aug 30 19:17:25 warez /kernel: Limiting closed port RST response from 852
    to 200 packets per second

    I find that I can't get any higher than --max-parallelism 3 before the
    target box starts to complain.

    So, I haven't dug into the algorithm that NMAP uses on SYN scans recently,
    but it must still be doing retransmits and must be agressive enough about
    retransmitting that it eventually gets a RST or SYN back from all the
    ports because I'm still getting the correct results. The exact logic
    would be interesting...

    On Thu, 29 Aug 2002, Lance Spitzner wrote:
    > Not sure if this is commonly known, however I wanted to share
    > something I've learned with nmap. As part of my job, I often
    > do a great deal of scanning of firewalls, or scanning through
    > firewalls. This can be VERY TIME consuming, as you get no
    > response for each probe, a full scan (all 65000+ ports) of a
    > firewall used to average me 3200 seconds. While teaching
    > a class we were able to DRAMATCALLY reduce this for TCP
    > scans to average 840 seconds. Using the following command line
    > options
    >
    > --max_rtt_timeout 50 --max-parallelism 100
    >
    > By reducing rtt_timeout to 50, we DRAMATICALLY reduced the
    > time for scanning, however, this is when the target is only
    > 2 hops away, you may experience dropped packets if there
    > are more hops. I can say this with a high degree with confidence,
    > as we had 8 different systems probe all 65000+ TCP ports,
    > all averaging around 840-850 seconds per scan. By changing
    > the rtt_timeout to 10, we got the time down to 350+, but
    > you are really pushing it. Increasing the number of parrallel
    > scans beyond 100 seemed to have no improvement.
    >
    > Unfortunatelyl, UDP still took MUCH LONGER, averaging
    > 2000-3000 seconds perscan :-0
    >
    > Just thought I would share this tidbit, for those of you
    > who have waited to firewall scans :)
    >
    >
    > --
    > Lance Spitzner
    > http://www.honeynet.org
    >
    >
    >
    >
    > --------------------------------------------------
    > For help using this (nmap-hackers) mailing list, send a blank email to
    > nmap-hackers-helpinsecure.org . List run by ezmlm-idx (www.ezmlm.org).
    >
    >

    --------------------------------------------------
    For help using this (nmap-hackers) mailing list, send a blank email to
    nmap-hackers-helpinsecure.org . List run by ezmlm-idx (www.ezmlm.org).