[Courses] [Security] safe use of nmap

[Raven, corporate courtesan]

Heya --

Quoth jennyw (Fri, Mar 15, 2002 at 06:50:49PM -0800):
> Running nmap on localhost and running it on a different system produce
> different results ... For the record, I'm using Debian Woody on both boxes
> (upgraded from Potato in both cases). The host being scanned is running
> ipchains (kernel 2.2.17).

	I'm guessing from the differing output here that you've based
your ipchains rules on what interface the packets are coming in on.  So
if you have filters for traffic on eth0 (or whatever interface), you'll
get the scan at the bottom.  But your loopback interface doesn't have
those chains applied to it, so you see ports open that you wouldn't from
the outside.
 
> The ellipses are areas where it showed that a bunch of ports were closed.
> Not sure why it chose to display the hundreds and hundreds of ports as
> closed ... maybe because of the 1029 ports it found that were filtered? Kind
> of confusing ... I guess I should read the nmap man page ...

	That's your firewall rules.  Closed = there is nothing listening
on that port.  Filtered = there may or may not be something listening on
that port, but either way I'm not telling you about it or letting you
get to it.

	In protocol terms, the difference is in the packets.  Say that
you're not running a telnet server on your box (10.1.1.17, for example).
When I telnet to 10.1.1.17, I'm sending a TCP packet with the SYN flag
set to port 23 on 10.1.1.17, to try and establish a connection.  This is
what happens when you use a telnet client, and this is what nmap does
when you tell it to do a TCP connect scan.

	If you have no firewall, your box will hear my connection
attempt on port 23, and send back a TCP packet with the RST (reset)
flag set, to kill the connection on my machine.  (If you were trying to
connect to a UDP port that wasn't listening, you'd get an ICMP error
message back saying "Destination Unreachable: Port Unreachable".)

	If you have a firewall and your policy is set to reject, the box
will send back an ICMP error message saying "Destination Unreachable:
Port Unreachable".

	If you have a firewall and your policy is set to deny/drop, there
will be no packets sent back to my machine at all.  No TCP RST, no ICMP.

	There's a good explanation of this with sample tcpdump output
at:

http://logi.cc/linux/reject_or_deny.html

I suspect we'll be getting into tcpdump here shortly, so we can actually
take a look at what's going into and out of each interface.
 
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address           Foreign Address         State
> PID/Program name
> tcp        0      0 *:smtp                  *:*                     LISTEN
> 11342/master

	Postfix, eh?  This is one of those sneaky things that you just
have to know -- if you see something listening on port 25 that
identifies itself as "master", it's Postfix.  (Sendmail IDs as sendmail,
and qmail as qmail-smtpd.)

> tcp        0      0 sw-90-736-717-3.:domain *:*                     LISTEN
> 9686/named
> tcp        0      0 localhost:domain        *:*                     LISTEN
> 9686/named

	So you're allowing that particular machine (sw-90-736-717-3) and
your local box to use you as a nameserver, but nothing else can do TCP
to your nameserver.  Good setup.

> tcp        0      1 sw-90-736-717-3.St:3917 *:*                     CLOSE
> 280/fetchmail
> tcp        0      1 sw-90-736-717-3.St:3916 *:*                     CLOSE
> 280/fetchmail
> tcp        0      1 sw-90-736-717-3.St:3726 *:*                     CLOSE
> 280/fetchmail
> tcp        0      1 sw-90-736-717-3.St:3725 *:*                     CLOSE
> 280/fetchmail
> tcp        0      1 sw-90-736-717-3.St:3722 *:*                     CLOSE
> 280/fetchmail
> tcp        0      1 sw-90-736-717-3.St:3718 *:*                     CLOSE
> 280/fetchmail
> tcp        0      1 sw-90-736-717-3.St:3717 *:*                     CLOSE
> 280/fetchmail
> tcp        0      1 sw-90-736-717-3.St:3716 *:*                     CLOSE
> 280/fetchmail

	Here's a sneaky thing -- TCP connections that are being closed
down (note the CLOSE state) being listed.  Fetchmail is fine here --
this is just your attempts to retrieve your mail every n minutes from
your mailserver.

> tcp        0      0 *:https                 *:*                     LISTEN
> 470/apache-ssl
> tcp        0      0 *:www                   *:*                     LISTEN
> 456/apache

	Apache, both regular and secure.

> tcp        0      0 *:10000                 *:*                     LISTEN
> 455/perl

	Webmin, I am assuming.

> tcp        0      0 *:netbios-ssn           *:*                     LISTEN
> 286/inetd
> tcp        0      0 *:pop3                  *:*                     LISTEN
> 286/inetd
> tcp        0      0 *:pop2                  *:*                     LISTEN
> 286/inetd
> tcp        0      0 *:imaps                 *:*                     LISTEN
> 286/inetd
> tcp        0      0 *:imap2                 *:*                     LISTEN
> 286/inetd
> tcp        0      0 *:ftp                   *:*                     LISTEN
> 286/inetd
> tcp        0      0 *:time                  *:*                     LISTEN
> 286/inetd
> tcp        0      0 *:daytime               *:*                     LISTEN
> 286/inetd
> tcp        0      0 *:discard               *:*                     LISTEN
> 286/inetd

	You should probably shut off any of these that you're not using,
but since they're firewalled it's not a terrible worry.  Just an overall
good idea.

	Good post!

Cheers,
Raven 

"Sed, sed, awk.  Like duck, duck, goose.  Sync, sync, halt.  It's the
 order of nature."
  -- me, after too long a day at work