Tag Archives: packets

Packet Carving with SMB and SMB2

One of the more useful network forensic skills is the ability to extract files from packet captures. This process, known as packet data carving, is crucial when you want to analyze malware or other artifacts of compromise that are transferred across the network. That said, packet data carving has varying degrees of difficulty depending on the type of traffic you are attempting to extract data from. Carving files from simple protocols like HTTP and FTP is something that can be done in a matter of minutes and is usually cut and dry enough that it can be done in an automated fashion with tools like Foremost and Network Miner.

There are articles all over the Internet about carving files from simple protocols so I won’t rehash those. Instead, I want to take a look at a two more complex protocols that are extremely common in production networks. Server Message Block (SMB) is the application-layer protocol that Microsoft operating systems use for file sharing and communication between networked devices. If you live on a Microsoft network (or a Unix network that utilizes SAMBA) then you are a user of SMB or SMB2, depending on your operating system version. In this article I’m going to discuss the art of carving files from SMB and SMB2 traffic. If you want to follow along you’ll need to download a copy of Wireshark (http://www.wireshark.org) and your favorite hex editor. I’ve used Cygnus Hex Editor (http://www.softcircuits.com/cygnus/fe/) for the purpose of this article since it’s simple and a free version exists.

 

Carving Files from SMB Packets

 

The first version of SMB is in use on all modern Microsoft operating systems prior to Windows Vista. In order to setup a packet capture for this scenario I took two Windows XP SP3 virtual machines running on VMWare Workstation and placed them in the same network. Once they were able to communicate with each other I setup a shared folder on one host (192.168.47.132) that is acting as the server. I then fired up Wireshark and began capturing packets as I copied an executable file from the client (192.168.47.133) to the servers shared folder. The resulting packet capture is called smb_puttyexe_xfer.pcap.

If you’ve never looked at SMB traffic then don’t get scared by all the different types of SMB packets in the capture, we will only be looking at a few of them. This article isn’t meant to be an exhaustive reference on each and every type of SMB packet (there are over a hundred of them), so if you want the gory details then take a look at the references at this end of this article.

In order to carve the file out of these packets we have to find some basic information about it. Before and after transferring a file to a server the client will attempt to open the file in order to see if it exists. This is done with an SMB NT Create AndX Request packet.  The response from the server to this is an SMB NT Create AndX Response, which contains the name, extension, and size of the file being transferred. This is everything we need to get started. You can filter for Create AndX Response packets in Wireshark with the filter (smb.cmd == 0xa2) && (smb.flags.response == 1). If we examine one of those requests that occur after the file has been transferred, we can identify that the file being transferred is putty.exe and its file size is 454,657 bytes. We will use this information later.

Figure 1: Note the file name, extension, and size.

The next step we have to take in order to extract this file is to isolate the appropriate block of traffic. Wireshark makes this pretty easy with its Follow TCP Stream functionality. Start by right-clicking any packet in the capture file and selecting Follow TCP Stream. This will bring up a window that contains all of the data being transferred in this particular communication stream concatenated together without all of the layer 2-4 headers getting in the way. We are only concerned about the traffic transferred from the client to the server so we will need to specify this in the directional drop down box by selecting 192.168.47.133 –> 192.168.47.132 (458592 bytes). Click Save As and save the file using the name putty.raw.

Figure 2: Saving the isolated traffic from Wireshark

If you were to view the properties of the data you just extracted and save you should find that its file size is 458,592 bytes. This is 3,935 bytes more than the size of the actual file that was transferred. This means that our goal is to get this raw files size down to exactly 454,657 bytes. This is where the real carving begins.

First things first, we have to delete all of the extra data that occurs before the executable data actually begins. Since we do know that the transferred file is an executable the quickest way to do this is to look for the executable header and delete everything that occurs before it. The executable header begins with the hex bytes 4D 5A (MZ in ASCII), which occurs approximately 1112 bytes into the putty.raw file. Once deleted, resave the file as putty.stage1. You should now be down to a file size of 457,480 bytes.

Figure 3: Removing added bytes from the beginning of the file

Now things get a bit trickier. SMB transmits data in blocks. This is great for reliability since a lost or damaged block can be retransmitted, but it adds some extra work for us. This is because each block must contain some bytes of SMB header data in order to be interpreted correctly by the host that is receiving it. The good thing is that the size of this data is somewhat predictable, but you have to understand a bit more about SMB in order to put the rubber to the road. The thing to know here is that the data block size in SMB is limited to 64KB, or 65536 bytes.  Of this amount, only 60KB is typically used for each block. These 61,440 bytes are combined with an additional 68 bytes of SMB header information. This means that after every 61,440 bytes of data we will have to strip out the next 68 bytes.

There is one thing to add to this that must be taken into consideration before stripping out those bytes. As a part of the normal SMB communication sequence, an additional packet is sent right after the first block. This is an NT Trans Request packet, which is packet 77 in the capture file. The SMB portion of this packet is 88 bytes, which means we will have to remove those 88 bytes in addition to the 68 bytes that make up the normal SMB block header, for a total of 156 bytes.

Now that we have all that sorted out let’s start removing bytes. In your hex editor, skip one byte past the 61,440th byte. This will be offset 0x0F000. You should start with this byte and select a range of 156 bytes and delete them. Save this file as putty.stage2.

Figure 4: Removing the initial 156 bytes

Things get a bit easier now as we are just concerned with stripping out the 68 bytes after every block. Skip through the file in 61,440 byte increments deleting 68 bytes each time. This should occur X times in this file at offsets 0x1e000, 0x2d000, and 0x3c000, 0x4b000, 0x5a000, 0x69000. Once finished, save the file as putty.stage3.

Figure 5: Removing a 68 byte SMB header block

Go ahead and take a look at the file size of putty.stage3. We are still XXX bytes off from our target, but luckily the last part is the easiest. The data stream is actually just padded by some extra information that needs to be deleted. We know that the file should be 454,657 bytes, so browse to that byte and delete everything that occurs after it.


Figure 6: Trimming the extra bytes off the end of the file

Save the final product as putty.exe and if you did everything right, you should have a fully functioning executable.

Figure 7: Success! The executable runs!

 

The whole process can be broken down into a series of repeatable steps:

  1. Record the file name, extension, and size by examining one of the SMB NT Create AndX Response packets
  2. Isolate and extract the appropriate stream data from Wireshark by using the Follow TCP Stream feature and selecting the appropriate direction of traffic
  3.  Remove all of the bytes occurring before the actual file header using a hex editor
  4. Following the first 61,440 byte block, remove 156 bytes
  5. Following each successive 61,440 byte block, remove 68 bytes
  6. Trim the remaining bytes off of the file so that it matches the file size recorded in step 1

 

Carving Files from SMB2 Packets

 

Microsoft introduced SMB2 with Windows Vista and began using it with its newer operating systems moving forward. In order to setup a packet capture for this scenario I took two Windows 7 (x32) virtual machines running on VMWare Workstation and placed them in the same network. Once they were able to communicate with each other I setup a shared folder on one host (192.168.47.128) that is acting as the server. I then fired up Wireshark and began capturing packets as I copied an executable file from the client (192.168.47.129) to the servers shared folder. The resulting packet capture is called smb2_puttyexe_xfer.pcap.

You should notice that this traffic is a little bit cleaner than the SMB traffic we looked at earlier. This is because SMB2 is optimized so that there are a lot less commands. Whereas SMB had over a hundred commands and subcommands, SMB2 only has nineteen. Regardless, we still need to find the filename being transferred and the size of that file. One of the best places to do this is at one of the SMB2 Create Response File packets. This packet type serves a purpose similar to that of the SMB NT Create AndX Response packet. You can filter these out in Wireshark with the filter (smb2.cmd == 5) && (smb2.flags.response == 1). The last one of these in the capture, which is packet 81, is the one we want to look at since it occurs after the file transfer is complete. This identifies the file name as putty.exe and the file size as 454,656 bytes. This is indeed the same file as our earlier example, but it is being reported as being one byte smaller. The missing byte is just padding at the end of the file and has a null value so it’s not of any real concern to us.

Figure 8:  Once again we note the file name, extension, and size

At this point you should perform the same steps as we did earlier to isolate and extract the data stream from the capture using Wiresharks Follow TCP Stream option. Doing this should yield a new putty.raw file whose file size is 459,503 bytes. This is 4,847 too big, so it’s time to get to carving.

Once again we need to start by stripping out all of the data before the executable header. Fire up your favorite hex editor and remove everything before the bytes 4D 5A. This should account for a deletion of 1,493 bytes.

Figure 9: Removing the extra bytes found prior to the executable header

Now things change a bit. SMB2 works in a method similar to SMB, but it actually allows for more data to be transferred at once. SMB had a maximum block size of 64K because it has a limit of 16-bit data sizes. SMB2 uses either 32-bit or 64-bit data sizes, which raises the 64KB limit. In the case of the transfer taking place in the sample PCAP file, these were two 32-bit Windows 7 hosts under their default configuration which means that the block size is set at 64KB. Unlike SMB however, the full 64KB is used, so we will see data in chunks of 65,536 bytes being transferred. These 65,536 bytes combine with a 116 byte SMB2 header to form the full block.

SMB2 doesn’t include an additional initial request packet like the SMB Trans Request, so we don’t have to worry about stripping out any extra bytes right off the bat. As a matter of fact, some might say that carving data from SMB2 is a bit easier since you only have to strip out 116 bytes after each block of 65,536 bytes. You can do this now on putty.stage1. In doing so you should be deleting 116 bytes of data at offsets 0x10000, 0x20000, 0x30000, 0x40000, 0x50000and 0x60000.

Figure 10: Removing 116 bytes of data following the first 65,536 chunk

Once you’ve finished this save the file as putty.stage2. All that is left is to remove the final trailing bytes from the file. In order to do this, browse to by 454,656 and delete every byte that occurs after it.

Figure 11: Removing the final trailing bytes

Finally, save the file as putty.exe and you will have a fully functioning executable. The process of carving a file from an SMB2 data stream breaks down as follows:

  1. Record the file name, extension, and size by examining one of the SMB2 Create Response File packets
  2. Isolate and extract the appropriate stream data from Wireshark by using the Follow TCP Stream feature and selecting the appropriate direction of traffic
  3.  Remove all of the bytes occurring before the actual file header using a hex editor
  4. Following each successive 65,536 byte block (assuming a 64K block size), remove 116 bytes
  5. Trim the remaining bytes off of the file so that it matches the file size recorded in step 1

 

Conclusion

 

That’s all there is to it. I’ll be the first to admit that I didn’t cover every single aspect of SMB and SMB2 here and there are a few factors that might affect your success in carving files from these streams, but this article shows the overall process. Taking this one step farther, it’s pretty reasonable to assume that this process can be automated with a quick Python script, but this is something I’ve not devoted the time to yet. If you feel like taking up that challenge then be sure to get in touch and I’ll be glad to post your code as an addendum to this post. In the mean time, happy carving!

 

References

http://msdn.microsoft.com/en-us/library/cc246231%28v=PROT.10%29.aspx

http://msdn.microsoft.com/en-us/library/cc246482%28v=PROT.10%29.aspx

http://channel9.msdn.com/Blogs/Darryl/Server-Message-Block-SMB21-Drill-down

 

The 10 Commandments of Intrusion Analysis

I’ve been actively involved in the training and development of intrusion detection analysts for a few years now which includes being a SANS Mentor for SEC 503: Intrusion Detection In-Depth. One thing I find myself constantly doing is trying to evolve my philosophy on effective intrusion detection. While doing this, some themes arise that tend to stay consistent no matter how that philosophy changes. Through that, I’ve written up something I call the “10 Commandments of Intrusion Analysis” which highlight some of those themes that seem to be at the core of what I try to instill in the analysts I train and in my own analysis. They don’t really command you to anything, but there are 10 of them, so the name kind of fits. These may not fit you or your organizational goals or personal style, but they work for me!

1. Analysts, Analysts, Analysts!

The most important thing an analyst can have ingrained into them in their importance. An analyst is the first line of defense. The analyst is sitting in the crows nest watching for the icebergs. It is the analyst who can keep attacks from happening and can stop attacks from getting worse. Most security incidents begin with an analyst providing a tip based upon an IDS alert and end with an analyst putting in new signatures and developing new tools based up on intelligence gained from a declared incident. The analyst is the beginning and the end in information security. The alpha and omega. Okay, maybe that’s a bit dramatic, but the importance of an intrusion analyst can’t be understated.

2. Unless you created the packet yourself, there are no absolutes.

Analysis happens in a world of assumptions and its important to remember that. Most of the decisions you will make are centered around a packet or a log entry and then honed based upon intelligence gathered through research. The fact is that the analyst isn’t the one who generated the traffic, so every decision you will make is based upon an assumption. Don’t worry though; there is nothing wrong with that. Ask your friendly neighborhood chemist or physicist. Most of their work is based upon assumptions and they have great success. The takeaway here is that there are no absolutes. Is that IP address REALLY a known legitimate host? Does that domain REALLY belong to XYZ company? Is that DNS server REALLY supposed to be talking to that database server? There are no absolutes, merely assumptions, and because of that remember that assumptions can change. Always question yourself and stay on your toes.

3. Be mindful of how far abstracted from the data you actually are.

An analyst depends on data to perform their function. This data can come in the form of a PCAP file, an IIS log file, or SYSLOG file. Since most of your time will be spent using various tools to interact with data it’s crucial to be mindful of how that tool interacts with the data. Did you know that if you run Tcpdump without specifying otherwise, it will only capture the first 68 bytes of data in a packet? How about that Wireshark displays sequence and acknowledgement numbers within TCP packets in a relative manner by default? Tools are made by people and sometimes “features” can cloud data and prevent proper analysis. I think both of the features I described earlier are great, but I’m also mindful that they exist so I can see all of the packet data available or view the real sequence and acknowledgement numbers when needed. In a job where reliance upon data is critical, you can’t afford to not understand exactly how tools interact with that data.

4. Two sets of eyes are always better than one.

There is a reason authors have editors, policemen have partners, and there are two guys sitting in every nuclear silo. No matter how much experience you have and how good you are you will always miss things. This is to be expected because different people come from different backgrounds. I work with the government so the first thing I look at when examining network traffic is the source and destination country. I’ve worked with people who have systems administration backgrounds and as a result, will look at the port number of the traffic first. I’ve even worked with people who have a number crunching background who will look at the packet size first. This demonstrates that our experiences shape our tactics a bit differently. This means that the numbers guy might see something that the sysadmin didn’t see or that the government guy might have insight that the numbers guy didn’t. Whenever possible it’s always a good idea to have a second set of eyes look at the issue you are facing.

5. Never invite an attacker to dance.

This is something I’ve believed since the first day I ever fired up a Snort sensor, but IDS guru Mike Poor phrased it best while I was attending one of his SANS classes when he said that you should never invite an attacker to dance. As an analyst its very tempting to want to investigate a hostile IP address a bit beyond conventional means. Trust me, there have been many occasions where I’ve been tempted to port scan a hostile that kept sending me painfully obviously crafted UDP packets. Even more so, any time someone attempts to DOS a network I’m responsible for defending, I wish nothing more than to be able to unleash the full fury of a /8 network on their poor unsuspecting DSL connection. The problem with this is that 99% of the time we don’t know who or what we are dealing with. Although you may just be seeing scanning activity, the host that is originating the traffic could be operated by a large group or even a military division of another country. Even something as simple as a ping could tip off an attacker that you know they exist, prompting them to change their tactics, change source hosts, or even amplify their efforts. You don’t know who you are dealing with, what their motivation is, and what there capabilities are, so you should never invite them to dance.

6. Context!

One word can drastically change the dynamic of your monitoring and detection capabilities. In order to be effective you must have context into the network you are defending. Network diagrams, listings of servers and their roles, breakdowns of IP address allocations, and more can be your best friend. Basically any and everything that can be used to document the assets within the network, how they function, and how they relate to other assets are beneficial in running down anomalous events. Depending upon your role in the organization you may not be in a position to obtain these things and if they don’t already exist you are going to have a heck of a time getting the systems folks to put in the leg work to create them. However, as difficult as this may be, its an effort that’s worth pursuing. Whether you have to present your case to the CIO or just buy your network engineers a case of their favorite adult beverage its ultimately worth the effort.

7. Packets, in a word, are good.

The ultimate argument in life is whether or not people are inherently good or inherently evil.  This same argument can be had for packets as well. You can either be the analyst that believes all packets are inherently evil or the analyst that believes all packets are inherently good. I’ve noticed that most analysts typically start their career as for the former and quickly progress the later. That’s because its simply not feasible to approach every single piece of traffic as something that could be a potential root level compromise. If you do this, you’ll eventually get fired because you spent your entire day running down a single alert or you’ll just get burnt out. There is something to be said for being thorough but the fact of the matter is that most of the traffic that occurs on a network isn’t going to be evil, and as such, packets should be treated innocent until proven guilty.

8. Analysis is no more about tcpdump than astronomy is about a telescope.

Whenever I interview someone for any analyst position that’s above entry level I always ask them to describe how they would investigate a typical IDS alert. I get frustrated when someone gives answers along the lines of “I use  Tcpdump, Wireshark, Network Miner, Netwitness, Arcsight, Xeyes, etc” with no further clarification. Although their are processes and sciences in intrusion analysis, intrusion analysis itself is not a process or a science, but rather an art. If this wasn’t the case then it wouldn’t even be necessary to have humans in the loop when it comes to intrusion detection. An effective analyst has to understand that while different tools may be the most important part of the job, those things are merely pieces of the puzzle. Just like an astronomer’s telescope is just another tool in his arsenal that allows him to figure out what makes the planets orbit the sun, Wireshark is just another tool in an analysts arsenal that allows him to figure out what makes a packet bypass a firewall rule. Start with the science, add in a few tools and processes, stay cognizant of the big picture, keep an attention to detail, and eventually the combination of all of those things and the experience you gain over time will help you develop your own analysis philosophy. It’s at that point you have taken your analysis to the level of an art, and made it so that your worthy enough to not be replaced by a machine.

9. Sometimes, we lose.

No matter how hard you try there will come a point in which the network you are defending gets successfully attacked and compromised. In the modern security landscape its inevitable and there isn’t a lot you can do about it. In these times its likely that the analyst will take the heat over the incident. Because of this, you need to be prepared when it happens. An incident won’t be remembered for how an intrusion occurred, but rather how it was responded to, the amount of downtime that occurred, the amount of information that was lost, and ultimately the amount of money it costs the organization. What recommendations can you make to management to ensure a similar incident doesn’t occur again? What can you show your superiors to explain why the attack wasn’t detected? What shortcomings do your tools have? These are questions that can’t fully be answered until an intrusion has occurred and you have the context of an attack, but you can definitely consider the questions now and have a plan for how your information will be presented to key figures. You will get caught off guard and you will be blind sided, but its important that you don’t appear as such and you keep your game face on. This can make the difference between a promotion and a pink slip.

10. Dig deeper.

At the end of the day you have to have something to rest your laurels on and that has to be the fact that you’ve done your due diligence and that you’ve given your best. My “motto” per se when it comes to intrusion analysis is “Dig Deeper”. A defender has to control 65,535 ports. An attacker has to compromise one. A defender has to protect 10,000 users. An attacker has to deceive one. A defender has to examine millions of packets. An attacker has to hide a malicious payload in one. What can you do to increase your visibility into the data? What proficiency can you develop that gives you that edge against the attacker? You have a hunch that there is more than meets the eye, so what can you do to dig deeper?

Sanitizing PCAP Files for Public Distrubution

It happens pretty often that I’ll come across an interesting PCAP file that I want to share with others. Unfortunately, divulging these packet captures can give away certain sensitive information such as an organizations internal IP range, IP addresses of sensitive company assets, MAC addresses of critical hardware that could identify the product vendors, and more.

Fortunately, there is a tool which helps alleviate some of these issues. The tool is called Tcprewrite and is actually a part of the Tcpreplay suite. Tcpreplay is used to send packets from a PCAP back across the wire, but the suite actually contains a few other useful tools.Tcprewrite itself can be used to add and modify packet fields within PCAP files. For example, if you wanted to replace the layer two addressing information within a PCAP so that all of the packets have a specified source and destination MAC address you could use the following syntax:

tcprewrite --enet-dmac=00:55:22:AF:C6:37 --enet-smac=00:44:66:FC:29:AF --infile=input.pcap --outfile=output.pcap

Tcprewrite can do neat things at layer four as well, including remapping ports used in sessions. The following example will remap all port 80 traffic to port 8080.

tcprewrite --portmap=80:8080 --infile=input.pcap --outfile=output.pcap

The examples shown above were taken directly from the tcprewrite wiki page (http://tcpreplay.synfin.net/wiki/tcprewrite) where you can find quite a few other usage examples.

The real value of tcprewrite, and the reason for this article, is its ability to randomize the addressing information in a PCAP file. This is done with the following syntax:

tcprewrite --seed=423 --infile=input.pcap --outfile=output.pcap

In this line, the seed option is used in the randomization of the addresses. This will replace all of the IP addresses in the IP headers of the packets and will also modify any ARP packets in the traffic accordingly.

From what I’ve been able to determine this option doesn’t randomize and rewrite and MAC addresses, which is a bit of a problem since MAC addresses can give away the vendor of a piece of hardware. The last thing I want is the entire world knowing that I use Cisco/Juniper/Enterasys/Etc based external firewalls. The ability to rewrite MAC addresses is there but its not random. What you can do in this case is to split a PCAP file into two separate files representing each direction of traffic. This can be done with tcpdump or tcpprep, which is a part of the tcprewrite suite as well. Using tcprewrite you can split the traffic like this:

tcpprep --auto=bridge --pcap=input.pcap --cachefile=input.cache

From there you can use syntax similar to what was shown above to replace the MAC addresses. This isn’t randomized so you will basically have to make something up. At the very least I’d recommend replacing the OUI section of the MACs. That syntax would look something like this:

tcprewrite --enet-dmac=00:44:66:FC:29:AF,00:55:22:AF:C6:37 --enet-smac=00:66:AA:D1:32:C2,00:22:55:AC:DE:AC --cachefile=input.cache --infile=input.pcap --outfile=output.pcap

It wouldn’t be too much of a stretch to write a python script that uses tcpprep and tcprewrite to automate the randomization of MAC addresses as well.

You can download tcprewrite as part of the tcpreplay suite at http://tcpreplay.synfin.net/ or just apt-get/yum install tcpreply. The tool is Unix only (or you can use Cygwin if you are tied to Windows).

Viewing Packet Captures Online with CloudShark

I woke up this morning and was very excited to see a post on a blog a frequent, Packet Life. It looks like the folks at QA Cafe have just launched a new project called CloudShark. I’ve been playing with CloudShark all morning and I’m very impressed. A colleague of mine wrote something similar to this a while back with intentions of publishing it but never did, so I’m glad someone set forth on a similar project. I plan on using CloudShark as a component of this blog, so from now on any packet captures I post will have a “view online” link that should display the captures directly in your browser.

The best resource for more information on CloudShark seems to be their FAQ:

What is CloudShark?

CloudShark is a web site that displays network capture files right in your browser instead of running desktop tools such as Wireshark. You upload, link, or email your capture files and we’ll display them.

Why CloudShark?

We work with network capture files on a daily basis. After trying to view capture files on mobile devices without Wireshark support, we realized it was time to move packets to the cloud. The CloudShark idea was born. CloudShark was created to make viewing capture files easy from any device ranging from desktops to smart phones. After creating our own solution, we decided to make it available to everyone as CloudShark.org.

How does it work?

* Generate your capture file or use an existing capture file
* Email it, upload it, or link it
* CloudShark does the rest by providing a decode session
* If you email CloudShark with an attached capture file, we’ll email you back with a link to your decode session
* Send your capture files as an attachment to cap@cloudshark.org
* If you are in the browser already, we’ll drop you into your decode session

Are my capture files publicly accessible?

While the URLs to your decode session are not publicly shared, we make no claims that you data is not viewable by other CloudShark users. For now, if you want to protect sensitive data in your capture files, don’t use CloudShark.

Is there any limit to the size of the capture file I can upload?

Capture files are currently limited to 512 Kbytes. Larger files will be rejected.

Can I delete my decode session after I am done with it?

Not directly. Eventually it will be deleted when the disk space is recycled.

How long is my decode session available?

CloudShark is not a file storage site. We’ll try to keep your files around, but obviously there is a limit to the amount of files we can keep around. If the link to your decode session is no longer working, you may need to upload the capture file again. In the future we may provide persistent storage, but for now you should store your capture files somewhere else.

What capture formats are supported?

CloudShark uses tshark to do the actual decoding. tshark supports several capture files from other tools besides Wireshark. See http://wiki.wireshark.org/FileFormatReference.

I have a capture file hosted on my web site. Is there an easy way I can link a CloudShark decode session to this capture file?

Yes. You can create a CloudShark link that includes a URL to your capture file. Here is an example:

http://www.cloudshark.org/view?url=http://packetlife.net/captures/TCP_SACK.cap

Who are you?

CloudShark was created by QA Cafe. We are the creators of CDRouter, the leading CPE testing solution. We spend a lot of time working with capture files. You can visit us at qacafe.com.

Is this project connected to Wireshark.org?

No, not directly. We do use Wireshark, tshark actually, on our back end.

How can I contribute?

If you have any ideas, you can contact us at info@cloudshark.org.

Kudos to the folks at QA Cafe for putting this together! You can visit CloudShark at http://www.cloudshark.com and you can follow Cloudshark developments on Twitter at @Cloudshark.

Keeping Capture Files Manageable

When you are capturing a lot of traffic the size of your capture files can grow really quickly. When this happens you are really going to have a hard time getting anything done when trying to sort through the file. There are a couple of things you can to do prevent this from happening.

Use an Effective Capture Filter

Capture filters are great when you know what you are looking for. If you ONLY want SMTP traffic, you can capture only that traffic. If you ONLY want to see HTTP POSTs, then you can capture only that traffic. If you aren’t sure what you are looking for then its bests to stick to capturing everything and using display filters, but when you have an eye on your target then capture filters are a great way to cut through the weeds. You will find this especially beneficial when capturing packets from a busy server or network segment.

Some of the things you can filter based upon include:

  • Specific Protocols
  • A Particular IP/MAC Address
  • Incoming/Outgoing Traffic Only

Split the Capture File as It’s Being Captured

Wireshark has some really great flexibility in allowing you to split a capture file as its being created. You can access this by selecting Capture from the main drop-down menu and selection Options, or by pressing Ctrl+K.

captureoptions

You have a couple of options here and they all become available to you when you place a check mark next to the Use Multiple Files box. There are two primary sections which I’ve creatively labeled the Multiple File and Stop Capture sections.

The multiple file section lets you specify a point at which a new file is created, either by reaching a certain size limit or at a certain time interval. I find that I typically use the size option for typical uses, but specifying a time interval for the packet capture can become very useful when you are trying to pinpoint when a certain event is happening. In this scenario you could start the capture at 12:00 and place and set the multiple file option to create the next file every 1 hour which should create a nice clean display of capture files by the hour.

It’s important to note that you can specify both of these criteria and in this case, a new file will be created when EITHER condition is met. In this top section you can also specify a maximum number of files to be created (don’t underestimate the value of this, I’ve accidentally filled up a hard drive on many occasions) and specify a ring buffer. A ring buffer uses a set number of files, and after the last file has been written it will begin overwriting the first file and cycling back through.

The stop capture section of this area is very straightforward and allows you to stop a capture after it reaches a certain point, either at a certain number of packets captured, a certain size limit, or a particular time interval. This comes in handy when you want to start a capture and run off to lunch or take a call.

Ensure You Are Capturing in the Best Location

One of the most overlooked parts of the packet analysis process is ensuring you are properly tapped into the network and getting the packets you need. Although the typical concern is whether or not you are getting enough packets, there are some cases in which you may be capturing TOO MUCH information. If you are having trouble weeding through a large capture file then you need to ask yourself if you really need to be where you are at. If it is a client/server issue, do you really need to capture from the server or would capturing from the client yield the traffic you need? If you are analyzing a slow network link, do you really need to be inside the router or would you be best suited to tap the outside interface of the router and get away from the internal networks broadcast domain?

Working with larger capture files is a real quick way to bog down your system and further complicate what may already be a long drawn out process. Using these techniques you should be able to keep tabs on your capture file size and make your analysis process quite a bit more efficient.