Red Hat NETSCAPE MANAGEMENT SYSTEM 6.2 - COMMAND-LINE Guida di Installazione Scaricare il pdf (Pagina 70)

This is more than just "interesting" ports −− it is everything. We picked up a couple of new ones in the

process too. We've seen these before with netstat, so we know what they are. That is the Junkbuster web

proxy on port 8000/tcp and named on 32768/udp. This scan takes much, much longer, but it is the only way

to see all ports.

So now we have a pretty good idea of what is open on bigcat. Since we are scanning localhost from localhost,

everything should be visible. We still don't know how the outside world sees us though. Now I'll ssh to

another host on the same LAN, and try again.

# nmap bigcat

Starting nmap V. 2.53 by [email protected] ( www.insecure.org/nmap/ )

Interesting ports on bigcat (192.168.1.1):

(The 1520 ports scanned but not shown below are in state: closed)

Port State Service

22/tcp open ssh

3000/tcp open ppp

Nmap run completed −− 1 IP address (1 host up) scanned in 1 second

I confess to tampering with the iptables rules here to make a point. Only two visible ports on this scan.

Everything else is "closed". So says nmap. Once again:

# nmap bigcat

Starting nmap V. 2.53 by [email protected] ( www.insecure.org/nmap/ )

Note: Host seems down. If it is really up, but blocking our ping probes, try −P0

Nmap run completed −− 1 IP address (0 hosts up) scanned in 30 seconds

Oops, I blocked ICMP (ping) while I was at it this time. One more time:

# nmap −P0 bigcat

Starting nmap V. 2.53 by [email protected] ( www.insecure.org/nmap/ )

All 1523 scanned ports on bigcat (192.168.1.1) are: filtered

Nmap run completed −− 1 IP address (1 host up) scanned in 1643 seconds

That's it. Notice how long that took. Notice ports are now "filtered" instead of "closed". How does

nmap know that? Well for one, "closed" means bigcat sent a packet back saying "nothing running here", i.e.

port is closed. In this last example, the iptables rules were changed to not allow ICMP (ping), and to

"DROP" all incoming packets. In other words, no response at all. A subtle difference since nmap seems to

still know there was a host there, even though no response was given. One lesson here, is if you want to slow

a scanner down, "DROP" (or "DENY") the packets. This forces a TCP time out for the remote end on each

port probe. Anyway, if your scans look like this, that is probably as well as can be expected, and your firewall

is doing its job.

Security Quick−Start HOWTO for Red Hat Linux

8.7. nmap 67

1 2 ... 65 66 67 68 69 70 71 72 73 74 75 ... 81 82

Nessun commento

Red Hat NETSCAPE MANAGEMENT SYSTEM 6.2 - COMMAND-LINE Guida di Installazione Pagina 70