Scanning Your Network
04/18/2001In the last few articles, we've spent a fair bit of time examining IP packets and TCP/IP connections. In the next few articles, I'd like to demonstrate putting some of this knowledge together in order to increase the security of your FreeBSD system.
In my home network, I have a computer running FreeBSD 4.2; it has a constant connection to the Internet using a cable modem. Up to this point, the only security change I've made to this system was to configure TCP wrappers, which I demonstrated in "Securing BSD Daemons." However, since I now have a constant Internet presence, I should be aware of the information my FreeBSD system is willing to give to anyone who tries to find out. Once I know this, I can decide which IP packets from the Internet I am willing to allow into my machine.
The ports collection includes the nmap utility, which is a valuable
tool for determining which services your FreeBSD system is advertising to
other TCP/IP hosts. However, like most useful utilities, it should only be
used to test the computers in your own network. You should also be aware
that it is very common for unscrupulous users to use this utility to scan
for insecure hosts on the Internet. It is preferable for you to find
out first what they'll be able to discover about your system so you can
take measures to ensure they'll only be able to see what you want them to
see.
I'll become the superuser, connect to the Internet, and install
nmap; once the build is finished, I'll leave the superuser account:
su
Password:
cd /usr/ports/security/nmap
make install clean
exit
The nmap utility comes with several different scan types so you can test
your network daemons for several different behaviours. Since I'll be
running nmap on the same machine that I wish to scan, I'll run my scans
against the "localhost." If you wish to scan another host in your network,
substitute that host's IP address for the word "localhost."
Let's start by not specifying a scan type; this will tell the
nmap utility to determine which daemons are listening for TCP connections:
nmap -v localhost
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
No tcp,udp, or ICMP scantype specified, assuming vanilla tcp connect() scan. Use -sP
if you really don't want to portscan (and just want to see what hosts are up).
Host localhost (127.0.0.1) appears to be up ... good.
Initiating TCP connect() scan against localhost (127.0.0.1)
Adding TCP port 515 (state open).
Adding TCP port 22 (state open).
Adding TCP port 80 (state open).
Adding TCP port 6000 (state open).
Adding TCP port 111 (state open).
Adding TCP port 25 (state open).
Adding TCP port 587 (state open).
The TCP connect scan took 7 seconds to scan 1523 ports.
Interesting ports on localhost (127.0.0.1):
(The 1517 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
80/tcp open http
111/tcp open sunrpc
515/tcp open printer
587/tcp open submission
6000/tcp open X11
Nmap run completed -- 1 IP address (1 host up) scanned in 8 seconds
You may have noticed from this output that I've disabled telnet, have
added Apache to my system (http), and that I've been playing with NFS
(sunrpc).
If I now use Alt-F1 to look at the console, I'll see something interesting:
icmp-response bandwidth limit 364/200 pps
icmp-response bandwidth limit 335/200 pps
icmp-response bandwidth limit 380/200 pps
icmp-response bandwidth limit 482/200 pps
icmp-response bandwidth limit 418/200 pps
icmp-response bandwidth limit 246/200 pps
icmp-response bandwidth limit 317/200 pps
If you ever see this type of message at your console and you weren't running
the nmap utility, someone else was scanning your machine looking
for open ports. When nmap scanned my ports, it tried to connect to
1523 of my ports, and my FreeBSD system responded by sending out an ICMP Type 3
Code 3 response for each non-listening port. (See the last article on ICMP.)
By default, FreeBSD limits itself to only sending 200 of these types of packets
per second; this limit is a good thing, as it prevents your kernel from trying
to respond to more packets than it can handle. There is a FAQ on this console
message here