PPA Book Acknowledgements

I consider the acknowledgements section the absolute most important part of my book. As a matter of fact, it was something I was constantly working on from the books inception to its finish. That being the case, I thought it very appropriate that I post a copy of those acknowledgements here. I attribute very little of my success to myself, because it is the people around me who give me the ability to do what I do.

 

Acknowledgments

First and foremost, I would like to thank God for giving me the strength and fortitude it took to complete this project. When my to-do list piled up higher and higher and there was no end in sight, he was the one who helped me through all of the stressful times.

I want to thank Bill, Tyler, Christina, and the rest of the team at No Starch Press for giving me the opportunity to write this book and allowing me the creative freedom to do it my way. I would also like to thank Gerald Combs for having the drive and motivation to maintain the Wireshark program, as well as performing the technical edit of this book. A special thanks goes out to Laura Chappell, as well, for providing some of the best packet analysis training materials you will find, including several of the packet captures used here.

Personally speaking, I would like to thank Tina Nance, Eddy Wright, and Paul Fletcher for helping me along the path that has led me to this high point in my career. You guys have been great spiritual and professional mentors as well as great friends. Along with that, I have several amazing friends who managed to put up with me while I was writing this book, which is an accomplishment in itself. With that being the case, I would like to extend a very special thank you to Barry, Beth, Mandy, Chad, Jeff, Sarah, and Brandon. I couldn’t have done it without you guys behind me.

Mostly, however, I want to thank my loving parents, Kenneth and Judy Sanders. Dad, even though you have never laid hands on a computer, your constant support and nurturing is the reason all of this was possible. Nothing makes me more driven than to hear you say that you are proud of me. Mom, you have been gone from us for five years as of the writing of this book, and although you couldn’t be around to see this achievement, you are always in my heart, and that is my true driving force. The passion you showed for living life is what has inspired me to be so passionate in what I do. This book is every bit as much your accomplishment as it is mine.

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.

Packet School 101 – Part 4

** 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. **

In this segment of Packet School 101 we are going to take a look at the trace files of a computer infected with spyware and one suffering from an application fault.

Spyware Infection

In our first sample scenario, a user has called complaining that her computer is dropping its network connection three minutes or so after booting up. When this happens the computer also maxes out its processor utilization. After making some calls you verify that everybody else is running as they should be, so the problem is just isolated to this one computer. When looking at the computer, it is apparent that her problem does exist as told. So what do we do? We fire up our sniffer of course!

Examining the Packets

Click here to download the sample trace file (< 1MB)

In examining our trace file there are a lot of problems with many things going on but we are only going to focus on the one client machine we are looking out down. It’s IP address is 172.16.1.10. The first thing we notice at the beginning of the capture is that an outside IP address keeps trying to make a connection to our computer on port 26452. Our client doens’t know what to do with this traffic since it is not expecting it, and therefor sends repetitive RST packets effectively ending the communication. This obviously should not be happening, however it continues to do so until we get to packet 70 and see the client requesting a copy of a file called analiz.exe from this rogue IP address via TFTP. This file begins to download, and ironically enough, that is when the computer starts experiencing problems

The Resulting Analysis

After spending some time actually on the physical computer the process analiz.exe was found to be running. After terminating this process and removing the file via an autmated spyware scanning utility the computer began to run normally. What was happening in this case was that after a computer would boot up it would try to make a connection to the rogue IP address associated with this spyware. After a certain amount of time the client would then download an updated copy of this spyware file via TFTP and run it on the system.

This brings up several good security points to remember. The first one of these is the most obvious and that is to education your uses about spyware and how to avoid it. However, another key point to mention is that this infection did a lot of its dirty work through TFTP which is a UDP based protocol. A lot of the time when configuraing firewall filtering rules most administrators will completely ignore UDP and only focus on TCP. You can not neglect UDP protocols when doing this, as a lot of spyware will use this weakness to completely hammer your netork.

Application Fault

The next file we are going to examine is the trace of an appliciation fault that is causing a client computer to run incredibly slow. In this scenario we have a client who is complaining that their application is not working because the network is running to slow.

Digging Deeper

Click here to download the trace file (< 1MB)

When we open our trace file we can determine several things by looking at the first fewpackets. The first thing we see is communication taking place between our client and server machines. Looking at the packet times we can see those requests are happening at rates of less than a millisecond so that indicates that there shouldn’t really be any latency on the wire itself. Also, we see that the client and server are sending their data back at more than adequate rates so there shouldn’t be an issue with either of them acting sluggish.

When we get to packet 5 however, we begin to see something interesting. Our client machine is making a NetBIOS request to our server, and then in the following packet, our server (which is NOT running NetBIOS) returns an ICMP Destination Port Unreachable packet. So what is causing this NetBIOS traffic from our client? Well Wireshark provides a great interface for viewing data contained within a stream of data. In order to utilize this you will need to right click on packet number 4 and click “Follow TCP Stream”. This will show us the data contained in that stream of communication, including upper layer protocol information.

When we look at this stream of data it is clear to us what is going on. The user is attempting to use the AIDA32 application. Not only do we find out this information, but we can also see that they are doing this under the “Chadwick” user account which is in the administrators group of the local machine.

The Verdict

After looking at this TCP Stream data it is clear to see that the network is not at fault. What is happening is that the application is making a NetBIOS request to the server, and since the server isn’t running NetBIOS it responds to the applications request by saying it is busy. In the design of the application which is being used, there is no formal mechanism in place that lets the user know that the server is not accepting its communication. This means that the application is just sitting there doing nothing waiting for valid response, which it will never get. This being said, the proposed solution to this type of problem would be to enable NetBIOS on the server which the program is connecting to or find a program that uses an alternate means of communication.

Homework

Today we have analyzed to more trace files that have given us a further understanding of more packet related troubleshooting techniques. If you manage any type of network I would be willing to bet that you have problems with spyware on occasion. This being the case, the next time you see a computer with a spyware problem, sniff it’s communication. You would be amazed to see how often various spyware applications will silently “phone home” to download updates to the infection and perform various other tasks. In the next installment of Packet School 101 we will take a look at what a trace file looks like when a computer is the target of a port scan and attempted denial of service attack.

 

**UPDATE**

Enjoy Packets School 101? Check out Packet School 201!

You can have online degrees from well reputed institutions all over the world. Different constraints like; money, distance etc. will no more restrict you from getting valuable IT diplomas and certifications from any online university. Demand for professionals having MS 70-290 certifications has been increasing day by day. Presently, Microsoft is offering MS 70-536 certifications for the people interesting in learning the essentials of IT and MS 70-554 is more advance certification in this field.
 

Packet School 101 – Part 3.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. **

I just wanted to make a couple of quick notes before I published the next section in Packet School 101. I have been in touch with Gerald Combs, who as many of you know is the original developer of Ethereal, and he has informed me that due to copyright and legal restrictions that Ethereal HAS been rebranded as the Wireshark project. I had heard this from several sources but wanted to make sure it was legitimate before I posted anything about it. This being said, Wireshark is basically the same program as Ethereal so all of the previous tutorials I have posted should still be valid. Also, from here on out I will no longer refer to the program as Ethereal, and all of the screenshots will also reflect the Wireshark program. You can learn more about Wireshark at http://www.wireshark.org.

Also, I want to thank you guys for all of the comments anad questions you have sent. Towards the end of the series I am going to devote one whole section to nothing but questions, so keep sending them my way.

Be sure to check back in the next couple of days for Packet School 101 – Part 4!

Packet School 101 – Part 3

** 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. **

The response from this series has been tremendous! As of yesterday I have managed to make the front page of digg.com and make #2 on the list of the most linked sited on del.icio.us. I have seen my bandwidth grow exponentially and have logged over 5 GB of traffic in the past 24 hours. I have also had a lot of great comments regarding the first two parts that I hope to address later on in the series. I plan on ending with a Q & A so if you have any major questions feel free to e-mail me.

Troubleshooting a Slow Router

Download the sample trace file by clicking here (<1 MB)

In this section we are going to look at a client who is trying to connect to a website but it experiencing all kinds of network slowness issues. Opening the sample trace file, the first thing you will notice is a lot of ARP broadcast packets. These are typical in a lot of network environments for layer 3 to layer 2 address resolution. For the purpose of what we are doing here, we are going to remove these from out trace file so that they don’t clutter things up. You can do this by typing “!arp” in the filter text box near the top of the Ethereal window.
Getting on Time

At this point in our learning it is pertinent to take notice of the “Time” column in the main Ethereal window. You will see a time listed next to each packet, and by default, this shows the time the packet was recieved in relation to the beginning of the packet capture. This type of view has its purposes in some settings, however, for troubleshooting a slow network you will want to change this setting to display the time relative to the packet recieved previously. You can do this through by going to View > Time Display Format, and selecting “Seconds Since Previous Packet”. In this new time view you will notice that the times are now displayed as the amount of time since the previous packet was captured. For example, packet 4 was recieved 1.728522 seconds after packet 3. This will be much more handy to us in our troubleshooting of the slow network communication.

Looking for the Source of the Latency

Now that we have our time column set to display data to us in a much more helpful way, scrolling down through the trace file we see our first major network activity at packet 18 where the client (172.17.8.66) makes an HTTP request to get the website www.packet-level.com. Typically, the next packet we see should be the dns servers response to the client. In this case however, the server does not respond back to the client, so the next packet we see is over a second later and is the client attempting to request the webpage a second time. After this second request we finally see a response from the DNS server pointing us to the IP address of the web server in packet 20. In an ideal situation, as soon as this dns query is completed the client and server should begin a standard TCP/IP handshake (SYN, SYN/ACK, ACK), and in our case the client does its part sending it’s initial SYN packet out within 4 milliseconds (third place from the decimal point is milliseconds) of recieving the DNS response. The server on the other hand responds an incredible amount slower taking over half a second to send its SYN/ACK reply. At this point we can definitely begin to see that it is something other than the client causing the network latency.

Interestingly enough as we continue down into the trace, in packet number 26 we see a second DNS reply from the server. This the reply to our second DNS request that we made initially. The only problem is that it is about 5 seconds too late! Given that our client computer has already established a connection with the server there is no real need for this second connection, and it throws up an ICMP destination unreachable packet immediatly following the reciept of the DNS response.

Going back to our already established connection to the server, we begin to see problems sprouting up. After making our initial TCP/IP handshake the client requests the actual content of the webpage at packet 25. Quite some time goes by and then in packets 29 and 32 we see two TCP Retransmission packets. In this case, the client has requested the webpage, not gotten a response, waited a certain amount of time, and sent a retransmission to the server in order to make another attempt at getting the data. After the third retransmission we finally see a response from the server in packet 33. Now if you add up the times from packets 25 to 33 you will see it has taken us nearly 9 seconds to get the first bit of data from the webpage we are requesting. It doesn’t take a packet analyzing expert to realize this is entirely unacceptable.

Fixing the Problem

Given the information we have just seen we know that the client is not at fault for the slow communication. The principal rule of thought for figuring out the problem location is to move upstream along the network. In this network, the next step would be to look at the router to see if it is malfunctioning in any way. Upon rebooting the router on this particular network, the speed of data communication increased tremendously and the problem was solved. However, if the problem had not been the router then you would need to move upstream to the router of the network in which the web server you are connecting to is behind. Unfortunately when that is the case you typically do not have the power over the remote network to do anything about it.

Homework

In our next installment we are going to look at a spyware infection and its effects on a workstation. Now that you understand the concept of restransmissions and latency you may be asking yourself what exactly is a good time for something such as a website request to take place? The best thing to do in this case is to sniff the packets on your own network whenever you are not having any issues. Ideal communication times are going to vary for each and every network you are on so this is another case in which you will want to sniff your own network. Getting to know what the packets look like in your network when it is healthy will SURELY pay off in the future.

Packet School 101 – Part 4�

 

 

With the help of Internet technology, you can find wide range of available online IT courses and certifications. You can search out online schools that offer certification for MS 70-296. Online instructors help you in grasping the tricky concepts of MS 70-620. Free and fast registration for MS 70-554 is also available for business professionals.