Penetration Testing mailing list archives
Re: Port Scanning Issues
From: "Jamie Riden" <jamie.riden () gmail com>
Date: Tue, 26 Jun 2007 08:22:32 +0100
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 ------------------------------------------------------------------------
Current thread:
- Port Scanning Issues crumdub12 (Jun 25)
- Message not available
- Port Scanning Issues Steinar Watne (Jun 26)
- Message not available
- Re: Port Scanning Issues sherwyn . williams (Jun 26)
- Re: Port Scanning Issues Jamie Riden (Jun 26)
- Re: Port Scanning Issues Vijay (Jun 26)
- Re: Port Scanning Issues Lee Lawson (Jun 26)
- <Possible follow-ups>
- Re: Port Scanning Issues ebk_lists (Jun 26)