[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Port Scan for UDP

Excuse your arrogance, but let me correct you in some points you made!

First of all nmap does not scan only the services listed in /etc/services, if 
you were to have bothered reading the manual before answering you would have 
read, and I quote: 
"The default  is  to  scan  all ports  between  1  and  1024  as  well as any 
ports listed in the services file which comes with  nmap." NOTE! Comes with 
nmap! usually located in /usr/local/share/nmap/nmap-services.

You could have spared the TCP/UDP diff lecture since the question wasn't 
directed to that... Although you were correct about UDP and it's difficulty 
when it comes to remote scanning.

jc: If you own the box and *don't* have any reason to assume/think you've 
been compromised (Just checking) you can check locally using nice tools like:
netstat -an --ip <for both udp and tcp> or netstat -an --udp[--tcp] for 
either one.
lsof -i -n 
nmap localhost -p 1-[HigherPortNumber]
and the list goes on =)

"I only drink to make other people interesting"

On Sunday 21 October 2001 09:45 am, Craig McPherson wrote:
> I can't believe nobody has answered this correctly yet.  UDP is
> different than TCP in that it is a stateless protocol, and that means
> you have to understand a few things to interpret UDP port scan results
> correctly.  With TCP scans, you get one of three results:  OPEN
> (meaning that the TCP handshake sequence to open a connection
> completed), CLOSED (meaning that the target sent a "port closed" ICMP
> message), or FILTERED (meaning that no response was received at all:
> this is also called "stealthed" by so-called "security experts" like
> Steve Gibson but it's a good idea to ignore him just on general
> principles).
> UDP is a completely stateless protocol, though.  Even if you send a UDP
> packet to a port that a valid daemon is listening on, the system isn't
> obligated to send anything back to you at all: there is no handshake
> sequence to establish a connection.  So making a determination is
> harder than with TCP.  If you receive a "port closed" ICMP message, the
> port can be safely listed as CLOSED, but if you receive nothing at all,
> that could mean that the port is either OPEN or FILTERED -- it's pretty
> much impossible to tell the difference.
> NMAP assumes that every UDP port that it doesn't receive a responsee
> from is OPEN, which means that if you have your firewall DROP all UDP
> connections, every UDP port will appear as open.  If you want to fix
> this, have your firewall REJECT instead of DROP, and the ports will
> appear correctly as CLOSED to a port scan.  DROPing connections without
> a response is in violation of the RFCs, too, if you care about that
> sort of thing.  Having the local machine portscan itself will also tell
> you which UDP ports are *actually* open, because I assume you don't
> have your firewall set to DROP packets from itself.
> Also, did you know that by default, nmap only scans ports listed in its
> services file?  So although it scans commonly-used ports, it's not
> scanning the entire system.  If you have enough time (this will make
> the scan very slow, especially over a slow network link), use the "-p 1-
> " argument to every scan to force nmap to scan every port from 1 to
> 65535 instead of just the maybe 400 or 500 ports that it has listed in
> its services file.  That's the only way you can get a complete picture
> of what your box looks like from the outside.
> > I'm doing portscans on a system I'm working to learn more about
> > securing hosts and setting up iptables.  My tcp portscan reported
> > what I expected, only www, ssh and smtp listening.  The udp
> > portscan reported a huge list of 'open' ports.  I really didn't
> > know what to expect for this scan, so I want to know if this is
> > normal.  Just for grins, I removed every udp listing in
> > /etc/services and restarted inetd and the scan came back the
> > same.  I figure this is normal, but if someone can confirm this
> > behaviour, I'd really appreciate it.
> >
> > If this isn't secure behaviour, perhaps I can add an iptables
> > entry like:
> >
> > iptables -A INPUT -p udp -j drop
> >
> > However, I don't have any applications running using udp, so the
> > 'open' port doesn't have anywhere to go, as far as I know.
> > Again, if someone can confirm this, I'd really appreciate it.
> >
> > thanks,
> > jc

Reply to: