Your Network's Secret Life, Part 1
Right off, I'd like to say Willy Shakespeare has nothing to fear when it comes to classic stage drama. An opening like that on this web site can only mean that you have found the SysAdmin's Corner, home of all things Linux, with your resident host, Marcel Gagné. Before diving headlong into a whole new series, I want to take a moment to thank each of you for your comments on the "Sharing" series. With the enthusiasm surrounding it, we might just have to revisit it again in the future (with all new ideas, of course). But now, it is time to explore some new ground with a whole new series.
Over the course of this series, I want to be able to give you some insight into your network. What's happening out there over your twisted pair cabling that you don't know about? We'll look at the tools you already have and then some nice, graphical tools that not only let you monitor your network but visualize it. Looking to impress the boss with what Linux can do? The old Corner may have the ticket.
While it may seem incredibly obvious, the best way to understand what is happening on your network is to know your network. If there is a host out there doing anything, you need to be able to identify it (or at least account for it).
One of the single most effective (and overlooked) network discovery tools is netstat. It comes bundled with every Linux distribution, and it can tell you a great deal about what is happening on your server. For instance, by using the program with the -a and -p flags, you can find every connection (or port) open on your system and what programs are using those ports.
For you security-conscious types out there, (that's all of you, right?), netstat should become your close friend. Check out those open ports. Does every one of those connections make sense to you? Are there live connections from a host you can't recognize?
In the following example, I also use the -n flag. This tells netstat not to worry about resolving IP addresses into symbolic addresses. It also makes the program run a bit faster, precisely because no name resolution is being done. Since this can be quite a long listing, I would suggest you pipe the whole thing to "more".
# netstat -apn | more Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 20 192.168.22.10:22 192.168.22.100:1014 ESTABLISHED 4003/sshd tcp 0 0 192.168.22.10:22 192.168.22.100:1015 ESTABLISHED 6122/named tcp 0 0 192.168.22.10:53 0.0.0.0:* LISTEN 6122/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 6122/named tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1231/httpd tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
The PID is the process ID of the running program using the connection. Consequently, you could do a ps ax and look for the connection, dealing with it as you see fit.
netstat is quite a flexible program, and you should arm yourself with a handful of useful options. In order to filter the output to display only TCP connections, use the -t flag. The -u flag will limit the output to UDP, while -w will display raw sessions. Finally, -x will limit the display to UNIX-type sockets (some database applications, X11 connections, font server, etc).
It's not uncommon to see a Linux server providing internet access for a business or home office network by sharing a single network connection (whether dialup, cable, or DSL) with other PCs on the network. This is the magic of IP forwarding and masquerading. To see what your masqueraded sessions are up to, use the -M flag, like this:
# netstat -M IP masquerading entries prot expire source destination ports icmp 0:59.13 gateway.mydomain.dom gateway.mycustomer.dom 49165 -> 8 (61808)
As you can see, I was pinging a remote site to generate a masqueraded connection. Here's another one to try. The -e option (meaning "extend") will give you additional information about exactly who is using the active socket.
# netstat -et Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode tcp 0 3419 www:www ts2-f-p01.rndm.dom:1328 ESTABLISHED www 1143804 tcp 0 12728 www:www ts2-f-p01.rndm.dom:1327 ESTABLISHED www 1143797 tcp 0 20 website.mysite.dom:ssh gateway.site22.dom:1760 ESTABLISHED root 1143189 tcp 0 0 www:smtp n1.groups.yahoo.c:27247 TIME_WAIT root 0
How about a nice graphical approach to this whole netstat business? Written in Perl and using Gtk libraries, Alexander Neptun's Nnetstat.pl program (see Figure 1) provides a simple means of accessing netstat's many functions. For starters, pay Alexander's web site a visit and pick up a copy of the script; it's at http://www.aneptun.de/linux/Nnetstat.
Since there is no compiling to do, make sure the script is executable and run it.
This is still alpha code, but it is quite usable. You can flip between the different views by clicking on the appropriate tab (TCP, UDP, etc). You can also turn on the extended options or DNS resolution, under the "Options" menu. Simple and clean.
Yes, it's time to wrap up yet again. Before I go, however, I want to make a suggestion regarding the wily system cracker. Because netstat can tell you so much about what is happening on your system, it is one of the first programs a cracker will replace upon creating a beachhead on your system. The new version will work almost exactly like the old one, except it will hide the cracker's open ports and addresses.
Consenquently, netstat is a good program to keep a clean (from a fresh install) copy of on a floppy diskette, somewhere other than on your system. (You want a copy there as well, of course). The program can be run from the diskette (you would mount a floppy filesystem and execute it like any other program), or you can save it to a diskette with tar and restore it as needed.
tar -cvf /dev/fd0 /bin/netstat # To save the file tar -xvf /dev/fd0 # To extract the file
You can also slow down a potential cracker (though not necessarily stop them) by making the file immutable using the chattr program. The immutable setting is defined by the +i flag.
chattr +i /bin/netstat
If you try to modify the file now, you get something like this:
# mv /bin/netstat /bin/netstat.old mv: cannot unlink `/bin/netstat': Operation not permitted mv: cannot remove `/bin/netstat': Operation not permitted
A file whose attribute has been modified in this way cannot be modified, renamed or deleted. You have to first gain root access, then reset the attributes using chattr (with a -i flag) before you can make any changes. As you can see, this adds a few steps to the average script kiddie's crack attempt.
When next we meet, we'll take this network discovery stuff to the next level. <insert appropriate smiley here>. Until the next SysAdmin's Corner, remember...if you are not watching your network, who is?
Looking for past articles to this series? Click here for a list.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Designing Electronics with Linux
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Kernel Problem
8 hours 26 min ago
- BASH script to log IPs on public web server
12 hours 53 min ago
16 hours 28 min ago
- Reply to comment | Linux Journal
17 hours 1 min ago
- All the articles you talked
19 hours 24 min ago
- All the articles you talked
19 hours 28 min ago
- All the articles you talked
19 hours 29 min ago
23 hours 54 min ago
- Keeping track of IP address
1 day 1 hour ago
- Roll your own dynamic dns
1 day 6 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?