Many of us do not give much thought to just what is traversing the corporate network. That is largely a job for the company’s system administrator. The thing of it is though the sys admin quite often does not look at the packets themselves, as they go about their business of administering the network. About the only time they do look at actual packets is if there is a network problem, and they feel it must lie at the protocol level ie: packet level. With that in mind the fact is that there are untold riches lying in that great mass of packets flying around on your network.
Why should I audit though?
What are the concerns that we as computer network professionals worry about in today’s computing environment? Well for one spyware infiltrating the corporate LAN is certainly of concern. Spyware is quickly becoming more and more virulent as time marches on. Dealing with this pest is quickly gaining front stage. The recent release of new Internet Explorer vulnerabilities has also raised concerns of possible network breaches. There is also the stealthy threat of Trojans, and the ever-present virus. What do most of these things have in common? They will all “dial home” if you will. Once installed on a user’s computer they will in some shape, or form send data back to someone. That will result in packet flows out through your border gateway. With the creative use of bpf filters, and bitmasks these traffic flows can be found. There will be more to follow on this a little later on in this article.
A corporate LAN has a chokepoint through which all traffic must flow both in, and out of. This would be the edge router, border gateway, or another term that some of you may know it by. Behind this router is normally the main switch, which in turn sometimes has a variety of secondary switches hanging off of it. This type of setup is common today, and has some nice features that we can take advantage of. Just like I mentioned above this chokepoint allows us to see all traffic coming in and out of our network. Bearing this in mind we can tap into this setup, and then be able to monitor all of the traffic going both in and out of the network in the following manner.
How do you do it?
What we would want to do is plug a hub into the span port of the main switch so that we can have the ability to see all of the network activity as it exits, and enters our network.
After we have plugged our hub into the switch we would then in turn plug whatever we like into the hub itself. This could consist of an intrusion detection system, or a computer used for packet collection and storage. In essence you could plug whatever you like at this tap point. This setup is ideal, and of great help to monitor the health of your network.
There are many different ways to analyze traffic at the packet level. The one I personally espouse is tcpdump with the addition of bitmasks to it. To many this analysis method is not user friendly, and they therefore prefer using a gui front end like Ethereal. All of the tools that do packet analysis for you are good, but I would advise you to simply use tcpdump, and bit masks until you master their usage. Simply put using the mentioned command line tools will help keep your skills sharp, and keep you used to seeing the packets in their native state. After all we want to be able to know what is going with our network via packet inspection. To stay sharp you need to continually exercise your packet reading abilities, and that means not using a gui! There are very few things you can’t do in tcpdump that Ethereal can do. Should you become too dependent on a tool like Ethereal, your skill could degrade.
Taking inventory
Now, to return to our mission of auditing our network, we must first take an inventory of the services the network offers. Does the corporate network have a web server, ftp server, web mail, and what type if any of database is used? Is file sharing enabled? All of these questions must be answered. Once this is done you will have properly base lined your network services, and know what should be present on the LAN. All that remains traffic wise is therefore technically suspect. This is a structured, and logical approach to take. It will also help to save you some time while combing through the traffic that you have collected.
So we now come back to actually using tcpdump, and bitmasks to see what is going on. Well pretty much all services, which are known (HTTP, SMTP POP3,…) operate on the ports below 1024. There are some services though that operate above this range such as SQL, which is on port 1433. The vast majority of known services run below 1024 though. Knowing this gives us a starting point to run some simple filters looking for specific activity.
Currently one of the main threats to the corporate LAN is peer-to-peer software that many employees have running on their workstations. It just so happens though that the majority of these P2P applications run on ephemeral ports. An ephemeral port is one that starts from 1025 and goes up to 65535. With this little nugget of information in mind we could design a bpf filter with a bitmask looking for any outbound connection attempts on a range of ports from say 1025 on up. That would allow us to see if there are some P2P running on the network. Even though the workstations in your company sit behind a router, and probably a firewall you can still be the unwitting “victim” of P2P software. All a user has to do is start this file sharing software up, and start a search for a file they want. Once found they then download it. The problem with P2P shared files is that they are often infected with various malware. So your otherwise secure network has now quite possibly been compromised from within.
Writing up a filter with the criteria (looking for connections on the ephemeral port range) noted above will easily pick out the packets in question if they are present. Though this requires that you log all packets coming, and out of your network. Logging all packets traversing your network is not as daunting a task as you may think it is. Many companies simply log all packets for an hour, and then compress the contents for later inspection if required. This is done to conserve disk space.
If we follow the same parameters that I described for a peer-to-peer application, and how to detect it then we can easily amend it to look for other types of undesirable traffic. Spyware depending on the type will act much in the same way, and can therefore be detected using the same methods. Conversely if you think that you may have been compromised, and want to look at the known port range (port 0 to 1024) for activity other than offered services you can still use a bpf filter to do so. It is only slightly more involved to design, but you can simply exclude known services and check the known port range for activity.
A side benefit of doing network auditing this way is that it reinforces your knowledge of TCP/IP, and specifically the core protocols themselves; TCP, UDP, IP, and ICMP. The greater your knowledge of the TCP/IP protocol suite the better you will be able to leverage this investigatory technique. So we now know that auditing our networks at a packet level is not only very much possible, but I would say definitely desirable.
For some more information about filtering IDS packets:
http://www.onlamp.com/pub/a/security/2004/06/17/ids_filtering.html
