From: Jamie Riden (jamie.riden@gmail.com)
Date: Tue Jun 26 2007 - 03:22:32 EDT
On 25 Jun 2007 21:59:58 -0000, crumdub12@gmail.com <crumdub12@gmail.com> wrote:
> A Chairde,
>
>
> Havin, some issues with scanning stacks on my system.
>
>
> 1. Using Superscan4 , I scan stack UDP-TCP 1-65534 , Sometimes I
>
> get no ports open , another time I get 49159 UDP Ports open, only get port report, no attempt made to open any ports ... , when get open ports , I always get 49159 UDP Ports ...... , use the scanner at 250msecs , takes around 16 hours to finish.
>
>
> 2. Using Languard, Nessus and Retina , get different scans from each tool, any ideas why, how do I find out real ports open.. differences can be 10,000 ports
UDP port-scanning does not always give reliable results. Have a look
at the nmap man page for UDP scanning ( nmap -sU target.example.com ).
In the man page Fyodor suggests using nmap -sU -sV to attempt to
fingerprint any services which are running on UDP ports.
"UDP scan works by sending an empty (no data) UDP header
to every targeted port. If an ICMP port unreachable error (type 3,
code 3) is returned, the port is closed. Other ICMP unreachable errors
(type 3, codes 1, 2, 9, 10, or 13) mark the port as filtered.
Occasionally, a service will respond with a UDP packet, proving that
it is open. If no response is received after retransmissions, the port
is classified as open|filtered. This means that the port could be
open, or perhaps packet filters are blocking the communication.
Versions scan (-sV) can be used to help differentiate the truly open
ports from the filtered ones.
A big challenge with UDP scanning is doing it quickly.
Open and filtered ports rarely send any response, leaving Nmap to time
out and then conduct retransmissions just in case the probe or
response were lost. Closed ports are often an even bigger problem.
They usually send back an ICMP port unreachable error. But unlike the
RST packets sent by closed TCP ports in response to a SYN or connect
scan, many hosts rate limit ICMP port unreachable messages by default.
Linux and Solaris are particularly strict about this. For example, the
Linux 2.4.20 kernel limits destination unreachable messages to one per
second (in net/ipv4/icmp.c).
Nmap detects rate limiting and slows down accordingly to
avoid flooding the network with useless packets that the target
machine will drop. Unfortunately, a Linux-style limit of one packet
per second makes a 65,536-port scan take more than 18 hours. Ideas for
speeding your UDP scans up include scanning more hosts in parallel,
doing a quick scan of just the popular ports first, scanning from
behind the firewall, and using --host-timeout to skip slow hosts."
cheers,
Jamie
-- Jamie Riden, CISSP / jamesr@europe.com / jamie@honeynet.org.uk UK Honeynet Project: http://www.ukhoneynet.org/ ------------------------------------------------------------------------ This List Sponsored by: Cenzic Are you using SPI, Watchfire or WhiteHat? Consider getting clear vision with Cenzic See HOW Now with our 20/20 program! http://www.cenzic.com/c/2020 ------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:54 EDT