Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Ofir Arkin (ofirsys-security.com)
Date: Sat May 11 2002 - 15:47:08 CDT
Although late answering...
With UDP Scanning:
UDP datagram -> Closed Port -> ICMP Port Unreachable
UDP datagram -> Open Port -> No Reply (or application dependent)
Scanning -> all ports are open -> Firewall/Filtering device
How to detect filtering device presence?
1. Fyodor's way - threshold number of "open" UDP ports -> Filtered
2. MY WAY -> send a UDP packet to a definitely closed UDP port. No ICMP
Port Unreachable -> Filtering Device Present (might be firewall, router,
or host based filtering)
You can see ICMP Usage in Scanning v3.0 Chapter 4 section 4.4 page 66-67
available from: http://www.sys-security.com for more information.
Ofir Arkin [ofirsys-security.com]
The Sys-Security Group
PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA
From: R. DuFresne [mailto:dufresnesysinfo.com]
Sent: 26 April 2002 15:20
To: Franck Veysset
Cc: ''pen-testsecurityfocus.com' '; Dawes, Rogan (ZA - Johannesburg);
'Noonan, Wesley '
Subject: Re: UDP port scan results
I believe, and am sure Wesley will correct me if I read him wrong, but,
the system sends no ICMP's it drops all, thus the term *"stealth host"*.
I'm not stating anything about whether or not a host should drop all
ICMP's and respond to none, but, I think that is the definition he gave
in a private e-mail on this.
What I would expect with a nmap scan would be drastically increasing
timeout limits returned by the client app, as it recived no replies and
I've seen on such scans, I forget the message returned when nmap hits
a system and don't present;y have time to find one of the hosts I've
scanned and seen such responses returned at the scan threashold on
On Fri, 26 Apr 2002, Franck Veysset wrote:
> Another problem I can see is the time needed to perform such a scan!
> If you read RFC 1812 section 220.127.116.11:
> "A router which sends ICMP Source Quench messages MUST be able to
> limit the rate at which the messages can be generated. A router
> SHOULD also be able to limit the rate at which it sends other sorts
> of ICMP error messages (Destination Unreachable, Redirect, Time
> Exceeded, Parameter Problem). The rate limit parameters SHOULD be
> settable as part of the configuration of the router. How the limits
> are applied (e.g., per router or per interface) is left to the
> implementor's discretion."
> You will see that a lot of RFC compliant implementation will implement
> rate limitating in term of ICMP generation, which means, UDP scan
> limitation. (ICMP port unreachable)
> If you read NMAP man page on UDP scan: (thanks Fyodor)
> "For example, the Linux kernel (in net/ipv4/icmp.h) limits destination
> unreachable message generation to 80 per 4 seconds, with a 1/4 second
> penalty if that is exceeded."
> I think that some Solaris implementations are even worse.
> So, let's assume you want to scan 64K port, 10 packets a port to try
> different handshakes... It's gonna take more than a week on a Solaris!
> "Dawes, Rogan (ZA - Johannesburg)" a écrit :
> > I think nmap has an explanation of how it determines whether a UDP
> > listening or not.
> > Essentially, if a UDP port has a listener, the packet will be
> > times silently (i.e. if it is not the correct format that the
> > normally respond to). If there is no listener there, the machine
> > an ICMP port unreachable message, containing the port number in
> > Hence, a port scanner can assume, if it gets no response, that there
> > something listening, i.e. the port is "open".
> > However, this behaviour is easily mimicked (?sp) with a firewall in
> > the target server. If the firewall is configured to silently drop
> > unauthorised packets, the scanner will receive no response to its
> > and assume that ALL ports are open.
> > If there is a screening router in front of the target, and it is
> > to send ICMP unreachables (fairly standard Cisco filter result), the
> > can report that the port is filtered, since the unreachable is
coming from a
> > different IP address to that of the target.
> > So, to answer your question eventually, it would be possible to
write a port
> > scanner that interrogated EVERY port, and only highlighted those
> > responded, however, that would require the following conditions:
> > The scanner author knows every possible UDP protocol, enough to
> > first handshake packet, that would cause a response packet. (I would
> > this is prohibitive to start with)
> > The scanner would have to try EVERY UDP protocol it knows about
> > every port, in order to discern between "not there", and "I'm
> > invalid packets" on non-standard ports. An example might be a TFTP
> > running on the SNMP well-known port. It wouldn't answer to a SNMP
> > but would likely respond to a TFTP handshake . . . .
> > To your , I recommend this, because otherwise, you are providing
> > info, rather than the 65535 "positive" results they'd get otherwise.
> > Hope this was useful.
> > Rogan
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ admin & senior security consultant: sysinfo.com http://sysinfo.com
"Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart
testing, only testing, and damn good at it too!
------------------------------------------------------------------------ ---- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/
---------------------------------------------------------------------------- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/