RE: UDP port scan results

["Ofir Arkin" <ofir () sys-security com>]

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 [ofir () sys-security com]
Founder
The Sys-Security Group
http://www.sys-security.com
PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA  

-----Original Message-----
From: R. DuFresne [mailto:dufresne () sysinfo com] 
Sent: 26 April 2002 15:20
To: Franck Veysset
Cc: ''pen-test () securityfocus 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
me
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
as
I've seen on such scans, I forget the message returned when nmap hits
such
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
timings
increased drmatically.

thanks,

Ron DuFresne

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 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

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        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/