In Whose Fault is it When Your Internet Dies? Troubleshooting Networks with Linux we learned some basic network troubleshooting commands. Today we’re going to explore the fine fun world of network discovery and find out who is on our network without ever leaving our comfortable chairs.
In Whose Fault is it When Your Internet Dies? Troubleshooting Networks with Linux we learned some basic network troubleshooting commands. Today we’re going to explore the fine fun world of network discovery and find out who is on our network without ever leaving our comfortable chairs.
Who Is On My Network?
Nmap (network mapper) is one of the best network-probing tools to learn in-depth. Be sure to to read the fine manual and practice carefully, because Nmap has mighty snooping powers and can get you in trouble. This command finds all hosts on a LAN subnet:
$ nmap -sP 192.168.10.0/24
Starting Nmap 5.00 ( http://nmap.org ) at 2011-07-18 11:01 PDT
Host freya.alrac.net (192.168.10.105) is up (0.0018s latency).
Host demeter.alrac.net 192.168.10.107 is up (0.00012s latency).
Host persephone.alrac.net 192.168.10.109 is up (0.00015s latency).
Nmap done: 256 IP addresses (3 hosts up) scanned in 27.31 seconds
That is a simple ping sweep and reverse-DNS resolution that reports hostnames and IP addresses of all hosts on the network that respond to ICMP echo requests. It detects both wired and wireless hosts. On newer versions of nmap this has changed to nmap -sn. You can refine your IP address range using CIDR notation and lists of octets. For example, 192.168.0-5.100-150 scans only the 192.168.0.100-150 up to 192.168.5.100-150 address ranges. You can enter your specific address ranges in a text file, separated by spaces, tabs, or newlines, and call this file with the -iL filename option.
The -sS scan (TCP SYN scan) is a fairly benign scan that doesn’t bog down your network or set off alarms. It requires root privileges, and shows which ports are open on your network hosts:
# nmap -sS freya
Starting Nmap 5.00 ( http://nmap.org ) at 2011-07-18 11:34 PDT
Interesting ports on freya.alrac.net (192.168.10.105):
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
139/tcp open netbios-ssn
445/tcp open microsoft-ds
631/tcp open ipp
These are all legitimate for this host. I always have SSH access set up to all hosts (TCP 22), TCP 139 and 445 are for Samba, and TCP 631 is CUPS. A similar useful test is to log in to Freya and run netstat to see active TCP and UDP connections. This example shows just a few of the reported active connections:
# netstat -untap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 1 0 127.0.1.1:46192 127.0.1.1:631 CLOSE_WAIT 2277/cups-polld
tcp 0 0 192.168.10.105:22 192.168.1.107:51968 ESTABLISHED 2468/sshd: alrac [p
udp 0 0 0.0.0.0:68 0.0.0.0:* 1430/dhclient
udp 0 0 0.0.0.0:5353 0.0.0.0:* 936/avahi-daemon: r
Local Address shows which ports are open and listening, and Foreign Address shows active connections. I can see my SSH session, and I can also see that I forgot to remove Avahi, which I always uninstall because I have no use for it, and it’s good basic security to not leave daemons running that you don’t need. If you’re new to Linux networking, open ports means you have running services. To close a port stop the service. There are multiple ways to do this now, thanks to the insatiable need of developers to keep changing perfectly functional systems, so I shall leave it as your homework to learn how for your particular Linux distribution.
You can map all open ports on your whole LAN and do some operating system discovery with the -O option:
# nmap -O 192.168.10/24
Starting Nmap 5.00 ( http://nmap.org ) at 2011-07-18 12:32 PDT
Interesting ports on node.alrac.net (192.168.10.77):
Not shown: 995 filtered ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
443/tcp open https
5060/tcp closed sip
8000/tcp closed http-alt
MAC Address: 55:22:B9:05:FF:B4 (PC Engines GmbH)
Aggressive OS guesses: Linux 2.6.9 - 2.6.28 (96%)
Discovery and Simple Performance Measurements
The fping utility is a useful little program for both host discovery and simple performance measuring. It sends ICMP echo requests to a number of hosts in sequence to see if they are up. Its unfiltered output is very large, showing all failures as well as successful hits, so this example filters the output to show only successful hits:
$ fping -c1 -gds 192.168.2.0/24 2>&1| egrep -v "ICMP|xmt"
phineas.alrac.net : [0], 84 bytes, 2.43 ms (2.43 avg, 0% loss)
franklin.alrac.net : [0], 84 bytes, 0.53 ms (0.53 avg, 0% loss)
fatfreddy.alrac.net : [0], 84 bytes, 3.42 ms (3.42 avg, 0% loss)
256 targets
3 alive
253 unreachable
0 unknown addresses
0 timeouts (waiting for response)
0.53 ms (min round trip time)
2.12 ms (avg round trip time)
3.42 ms (max round trip time)
10.310 sec (elapsed real time)
Ffping be used like plain old ping for quick single-host checks, and it’s more encouraging:
$ fping franklin
franklin is alive
You can also give fping a plain-text file with a list a of hosts to check, delimited by newlines:
$ fping -c1
If you’re running this as root then the syntax is a little different:
# fping -c1 -f filename
Quick Throughput Measurements
The fping and plain old ping utilities give you an idea of how fast traffic is running over your network, but iperf is better, and almost as easy. iperf operates in a client-server mode, so you need to install it on all machines you want to test. Then open a server session on one machine, and connect to it from a client session on a second machine. The server session looks like this:
host1:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
The client session looks like this:
host2:~$ iperf -c host1
------------------------------------------------------------
Client connecting to host1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
When the test run is finished, both will show similar output like this:
[ 3] local 192.168.10.25 port 40245 connected with 192.168.20.25 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 8.18 MBytes 6.85 Mbits/sec
6.85 Mbits/sec is pretty slow, but not surprising since host1 has an old wireless network interface. For Fast Ethernet and GigE you should see many times higher speeds. Add the -d options to run the test both ways on duplexing network interfaces. On the server host you’ll see results like this:
[ 5] 0.0-10.0 sec 99 MBytes 82.1 Mbits/sec
[ 6] 0.0-10.1 sec 105 MBytes 89.4 Kbits/sec
That’s some good numbers over wired Ethernet, and it shows that duplexing is working correctly.
Who Is On My Server?
Need to know who’s logged into your server at all times? Use whowatch, a utility that displays all logged in users on a machine. Just run whowatch without options, and it opens a nice ncurses display:
5 users: (4 local, 0 telnet, 1 ssh, 1 other) load: 0.31, 0.23, 0.13
(login) carla tty1 xinit /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/
(login) terry tty2 -bash
Whoops! Terry is logged in. Nobody else should be logged in. So what to do? Use the arrow keys to navigate to the first unauthorized user line, if there is more than one, and press the return key:
7 users: (5 local, 0 telnet, 1 ssh, 2 other)
(init) terry tty2
1599 - /bin/login --
3239 `- -bash
Arrow-key to the line with the lowest process number and press Ctrl+k to log the user off the system. Then go figure out how they got there and repair the breach. Press F9 to display the whowatch menus.
All of these commands have good man pages, and the Nmap documentation is thorough, and a great education in understanding what goes over the wires of TCP/IP networks.
