Penetration Testing mailing list archives
Re: UDP port scan results
From: Franck Veysset <franck.veysset () intranode com>
Date: Fri, 26 Apr 2002 09:09:31 +0200
Another problem I can see is the time needed to perform such a scan! If you read RFC 1812 section 4.3.2.8: "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! -Franck "Dawes, Rogan (ZA - Johannesburg)" a écrit :
I think nmap has an explanation of how it determines whether a UDP port is listening or not. Essentially, if a UDP port has a listener, the packet will be accepted, most times silently (i.e. if it is not the correct format that the listener would normally respond to). If there is no listener there, the machine will return an ICMP port unreachable message, containing the port number in question. Hence, a port scanner can assume, if it gets no response, that there is something listening, i.e. the port is "open". However, this behaviour is easily mimicked (?sp) with a firewall in front of the target server. If the firewall is configured to silently drop unauthorised packets, the scanner will receive no response to its packets, and assume that ALL ports are open. If there is a screening router in front of the target, and it is configured to send ICMP unreachables (fairly standard Cisco filter result), the scanner 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 that responded, however, that would require the following conditions: The scanner author knows every possible UDP protocol, enough to build a first handshake packet, that would cause a response packet. (I would think this is prohibitive to start with) The scanner would have to try EVERY UDP protocol it knows about against every port, in order to discern between "not there", and "I'm ignoring invalid packets" on non-standard ports. An example might be a TFTP server running on the SNMP well-known port. It wouldn't answer to a SNMP handshake, but would likely respond to a TFTP handshake . . . . To your [1], I recommend this, because otherwise, you are providing accurate info, rather than the 65535 "positive" results they'd get otherwise. Hope this was useful. Rogan
-- Franck Veysset -- http://www.INTRANODE.com Intranode Software Technologies It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. (RFC 1925) ---------------------------------------------------------------------------- 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/
Current thread:
- UDP port scan results Noonan, Wesley (Apr 22)
- Re: UDP port scan results Anders Thulin (Apr 23)
- <Possible follow-ups>
- RE: UDP port scan results Dawes, Rogan (ZA - Johannesburg) (Apr 22)
- Re: UDP port scan results Franck Veysset (Apr 26)
- Re: UDP port scan results R. DuFresne (Apr 26)
- Re: UDP port scan results Franck Veysset (Apr 26)
- RE: UDP port scan results Dario N. Ciccarone (Apr 24)