Recently, I took the time to discover a simple and flexible network-monitoring tool: IPTraf. This tool does little more than monitor the traffic flowing on a network. Although this sounds limiting, and possibly not terribly useful, these types of tools can be critical for troubleshooting networking issues.
One of the strengths of this particular application, and one that makes it highly useful to a network administrator, is the ability to define exactly what network traffic is to be monitored. I’ll show you how to use IPTraf's filter creation tools to specify which traffic is monitored on your network.
For the purposes of this article, I’ll be using a 192.168.1.x private addressing scheme. I’ll assume a standard network configuration, and the test network will assume the servers are mapped to the addresses listed in Table A.
|Gateway||192.168.1.1 (will also have an external address)|
For my example, I’ll assume standard traffic patterns (traffic flow in and out) and standard networking needs (as dictated by the above network layout).
I’ll be defining a number of filters in this article, starting with the very general and moving toward the specific in order to track down suspicious traffic. I’ll try to cover every possible need, but individual needs may require a bit of creativity on the part of the administrator.
On defining filters with IPTraf
Take a look at my previous article, “Police your network with IPTraf,” to learn the basics of filter definition with IPTraf.
As I define my filters, I’ll do so by specifying the following information:
- Hostname IP addresses
- Wildcard mask
One thing to remember is that, when defining a filter, two sets of data will be entered. You might think, at first, that one set of data would be used for source address and one for destination address. This is not so. With IPTraf, I can enter two sets of data, and the application will watch traffic flowing from either direction. Regardless of this fact, I tend to always think of traffic monitoring as source and destination addresses. I’ll always define a source on the right side of IPTraf and the destination on the left side.
Each time after I define my information, I’ll exit the filter definition screen, select Apply Filter, and then start the IPTraf monitor. Once I’m done with a filter, as I move to a new filter, I’ll make sure to detach the existing filter by selecting Detach Filter. With the old filter detached, I can move on to my next filter definition. That, of course, is not to say I can only have one filter attached at a time. With IPTraf, I can define and attach as many filters as I please.
The first filter I’ll create will monitor all traffic on my 188.8.131.52 network. I’ll name this filter All_traffic. The information entered will all go into the left-hand data and will look like that shown in Figure A.
|All zeroes indicate that all addresses will be monitored.|
Once I’ve entered the information, I’ll press [Enter] to add the filter data to the database. Then I’ll press [Ctrl]X to get out of the Add screen and back to the main Filter screen.
From within the main Filter screen, I’ll scroll down to Apply Filter, select All_traffic, press [Enter], exit the main Filter screen, scroll up to IP Traffic Monitor, press [Enter], and watch the traffic flow. Because I decided I wanted to watch all traffic moving to and from all IP addresses, I’ll see a ton of information flying by the Entries screen (the upper portion of the screen where traffic packets matching defined filters are listed). This is one of the main reasons for filter definition. I want to be able to catch only specific packets and display their information.
I’ll make this a tiny bit more specific. Let's say I want to monitor all traffic moving on port 22 (ssh). Even though I’m going to define my entire network, the only traffic that I’ll see displayed in the upper half of my IPTraf screen will be traffic flowing in and out of the ssh port. My filter will be called All_22, and the information will be like that shown in Figure B.
|With this information in place, I’ll only be logging traffic going to and from port 22.|
Once I apply this filter and begin monitoring, I’ll see any traffic flowing in and/or out of port 22 on my network.
Let's make this even more specific, shall we? I’ve seen a lot of ssh traffic flowing into and out of my firewall (192.168.1.2). To watch any traffic hitting this machine’s 22nd port, I’ll create a filter called Firewall_22 and enter the filter information listed in Figure C.
|Any traffic hitting port 22 on my firewall will be logged by IPTraf.|
Once I apply this filter and start monitoring traffic, I can begin to narrow down where any suspect traffic is emanating from. If I choose, I can add rules to my firewall to keep this specific traffic from traversing my network.
Let's say I notice a slowdown on all outgoing traffic on my network. I can add a filter to check all traffic going to/from the gateway to/from the firewall with a filter, named Gateway_to_firewall, that looks like that shown in Figure D.
|Watching traffic flowing between the gateway and the firewall will be hectic because of the amount of outgoing packets.|
With this filter in place, I’ll see any traffic passing between the firewall and the gateway. From there, I can start narrowing down until I find the suspect packets. Let's say, for instance, I see that the majority of traffic is hitting port 111 (sunrpc) on the firewall. Once I have narrowed that down, I’ll create a new filter based on that information. Now I can watch for any traffic bouncing between the firewall and the gateway hitting port 111 with a filter named Bouncing_111 and the information found in Figure E.
|Narrow the search by specifying a port with gateway and firewall addresses.|
Now I'm getting closer. As I take a look at the passing packets, I notice that the majority of the hits to port 111 are coming from the outside network. Because they’re coming from the outside network, I can assume that none of the internal IP addresses are suspect (unless they are being spoofed). I’ll exclude all internal traffic from my filter. By excluding the internal traffic to port 111, I’ll be able to see only the external traffic calling that particular port, further narrowing my search. Figure F shows a filter named Exclude_internal, which contains the exclude information; Figure G, aptly named Include_information, shows the include information.
|To switch from the default Include to Exclude, tab to the Include/Exclude field and press the E key.|
|All connections (that are not listed in the Exclude filter) hitting port 111 are logged.|
Here, I’ve defined two filters. The first filter tells IPTraf to not include any traffic from the internal network. The second filter will show any traffic from the outside interface (this will be the public IP address assigned to my gateway server) that is hitting port 111. Then, I hope, I’ll see specific information that will show me exactly where the suspected attack is coming from. Say, for example, that IPTraf is showing that the hit is coming from some.url.org. With this information, I can update my firewall to not allow through any traffic from that domain. I have prevented possible pilfering of data.
Figure H illustrates what the IPTraf application looks like when it’s running. This particular configuration was set to log all traffic to port 22 coming and/or going into 10.16.58.190. As you can see in the upper pane, traffic to port 22 is flowing between addresses 10.16.58.190 and 10.16.58.91.
|The upper pane shows you not only the address of the traffic, but also the number and size of the packets.|
Tracking down suspect traffic can be a long and arduous process, but it’s not impossible. With the ability to completely customize which traffic you see (and which you don't see), IPTraf is the perfect solution for chasing down potential hackers, as well as problems on your network.
Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website jackwallen.com.