Packet School 101 – Part 5

** Disclaimer to all new readers – This blog post is VERY old and not really representative of my current work. I’ve just left it up here for historical purposes. If you are interested in learning more about packet analysis I’d reccommend reading some of my newer posts or looking at my book, Practical Packet Analysis. **

After a couple weeks of down time I finally have completed the next installment of Packet School 101! In this section we are going to turn towards the security side of things and look at a couple trace files of what effects a port scan and a denial of service attack can look like.

Port Scan

One of the first steps a hacker is going to take when determining whether or not he can break into your computer is to perform a port scan on it. As most of us are aware, every form of network traffic that enters or leaves your computer does so through the use of a port. Most services use a standard port, and with this being the case potential intruders can often identify what services are running on your computer in an attempt to exploit them. A port scanner is the primary tool used to identify these ports and services. These tools usually have a predefined range of ports and will scan a target computer to see if those ports are open.

Examining the Scan

Click here to download the sample trace file (<5 KB)

This trace file is very small and to the point. In this scenario, we are concerned that someone from within our network may be trying to remotely compromise another workstation. In order to get a better understanding of what is going on we take the trace of the suspected target computer and the suspicious activity we have found is what is in the sample trace file. What we see is a lot of communication happening between 10.100.25.14 (local machine) and 10.100.18.12 (remote computer). If you look a little closer at these packets you will see exactly why they are so suspicious.

Most packet analysis programs will show the port that the communication you are witnessing takes place on. Wireshark is no different and does so exactly the same in the “info” column. What we see in our trace file shows us that every single packet that is being transferred from the remote computer is being sent to a different port number. Not only this, but these port numbers just happen to be commonly exploited ports. We see ports such as telnet, microsoft-ds, ftp, smtp, etc. Anytime you see something like this where a remote computer is sending packets to commonly exploited ports such as these you can typically assume something is up, and that something will usually lead you to piece of port scanning software.

Denial of Service Attack

Eventually in dealing in network administration and security you will encounter hackers who have malicious intentions in mind. One of the methods commonly used in a malicious manner is a Denial of Service (DoS) attack. During these attacks, a remote computer will flood another computer with a continuous amount of data in order to slow it down to the point that it fails to provide service to its legitimate users. To complicate things even more, remote computer can often be teamed together in this effort to perform what is called a Distributed Denial of Service (DDoS) attack in which more than one computer attempts to flood another with data. Going one step further, a DoS or DDoS attack can target an entire network as well as an individual computer. These applications send out a continuous stream of broadcast packets on the network, which are then sent to every node on your network (we will talk more about broadcast and multicast packets in the next installment). In our sample trace file we will look at an example of a DoS attack aimed at an entire network segment.

The Packet Level

Click here to download the sample trace file (<10 KB)

In our scenario we have noticed a major network slowdown that has virtually stopped all network activity on a particular segment. Upon physical observation of the switches we can see that all of the port activity lights are blinking furiously in unison. This information alone is enough to know that we have some type of broadcast traffic coming from somewhere.

Once we begin to look at our trace file we see a whole bunch of the same thing. It appears we have packets being sent out at a blistering rate to every node on the network. Our first reaction would normally be to look at the source IP address of this traffic and begin tracking it down. However, in this case we can see that no two packets are coming from the same IP address. This is because unfortunately, sometimes attackers think of things before we do, and in this case the program that is being used to generate this traffic was designed to spoof fake IP addresses to send the data from. So how can track down the source of this attack? Well, there is a technical and a non-technical solution to this.

The technical solution to this problem will require you to have some type of software that is integrated into your switches/routers that allows you to view the amount of inbound and outbound traffic coming from each particular port. With this method you can find the port that is amassing a lot of outbound traffic and take a visit to that machine. The non-technical solution is to go to your wiring closet and start unplugging ports one by one until the lights on the switches stop flashing repeatedly and in unison. If you have your ports labeled properly you should then be able to track down the physical location of the machine and take further action. The non-technical solution is something probably left better for after business hours.

Homework

It is obvious that examining things at the packet level can be a security analysts best friend. You will not find a successful network security analyst who doesn’t have a good understanding of how things function at the packet level and how to interpret the things they see when doing packet analysis. Sniffers can be used for simple security issues like the ones we looked at as well as more complicated scenarios such as looking for hidden data injected into packet headers or analyzing complex network worms and viruses. To get a better grasp on the security aspect of packet analysis you may want to try running a couple of different types of port scans on your test network. In the next and final section of Packet School 101 I will be answering your questions. I have already gotten a lot of questions but am looking for more so feel free to e-mail them to me at chris@chrissanders.org.