Archive for September, 2009

How To Review A Firewall Log In 15 Min Or Less – Part 2

September 29th, 2009

In my last post I introduced the concept of using white listing in order to review firewall logs. I discussed how this process can both simplify as well as expedite the log review process, by automating much of the up front work. In this post we will look at some actual examples, as well as start creating a firewall log parsing script.

The basics of grep

In order to show you the process of white listing your firewall logs, I am going to use grep. Grep is a standard Linux/UNIX tool, with free versions available for Windows (grab both the Binaries as well as the Dependencies). Grep is certainly not the most efficient tool for the job, but it is by far the simplest to learn. If you are a Perl, PHP, AWK&SED, SQL, etc. guru, by all means stick with your tool of choice. Simply mimic the process I’ve defined here using your appropriate command set.

Grep is a pattern-matching tool. It allows you to search one or more files looking for a specific pattern. When the pattern is found, the entire line is printed out. So for example the command:

grep 192.168.1.10 firewall.log

would produce all lines in the file “firewall.log” that contains the IP address “192.168.1.10”. Grep has a number of supported switches, but the only one we need for firewall log review is the “-v” switch. This switch tells grep to match all lines that DO NOT contain the specified pattern. So for example:

grep –v 192.168.1.10 firewall.log

would only print out lines that do not contain the specified IP address.

With grep, a period is actually a wild card character. So while I said the first grep command would match on the IP address 192.168.1.10, it could actually match on more than that. Grep interprets the string to read:

Match on: 192 <any single character> 168 <any single character> 1  <any single character> 10

If we want grep to match periods as periods, we have to preced them with a backslash character. So the proper syntax would actually be:

grep 192\.168\.1\.10 firewall.log

Finally, sometimes we want to match on multiple patterns that are strung together. For example what if we are only interested in 192.168.1.10 traffic when that’s the destination IP address? Depending on your firewall log format, the command may look something like this on a Linux or UNIX system:

grep ‘dst 192\.168\.1\.10’ firewall.log

On Windows, the command would look like this:

grep “dst 192\.168\.1\.10” firewall.log

Note the only difference is that Linux and UNIX uses single quotes, while Windows uses double quotes.

Logical AND’s and OR’s

Sometimes we need to match on multiple patterns within the same line. For example what if we only wish to see TCP/80 traffic to our Web server? In this case there are actually two patterns we wish to match on the same line. The problem is there may be other stuff in the middle we don’t care about.

To perform a logical AND, simply use the grep command twice on the same line. For example:

grep “dst 192\.168\.1\.10” firewall.log | grep “dst_port 80 ”

The pipe symbol simply lets you run the second grep command before execution ends. So the first grep command will grab all traffic going to 192.168.1.10 and then pass it to the second grep command. The second grep command then searches this output for all traffic headed to port 80. Look closely after the port number and you will see I included a space character. Without a space character, we could potentially match on port 800, 8080, etc.

Sometimes we may wish to match on either of two values. For example what if we wanted to see both HTTP and HTTPS traffic to our Web server? In this case we would need to do a logical AND combined with a logical OR. Here’s how to do that with grep:

grep ‘dst 192\.168\.1\.10’ firewall.log | grep ‘dst_port \(80 \|443 \)’

The first half of the command should look familiar, but the second half needs some explaining. We need to tell grep that the parenthesis characters are actual commands and not part of the string we wish to match. We do this by preceding them with a backslash character. The pipe character is what tells grep to process this command as a logical OR. Note the pipe also needs to be preceded by a backslash.

Sorting logs with grep

OK, so we have the basics, now let’s start applying them to reviewing a firewall log file. The first thing you need to do is get the log file into ASCII format. This is the native format for many firewalls, so no conversion may be required. If the log uses a proprietary format, the vendor usually supplies a tool to do the conversion. Personally I just send the logs to a SIM (http://www.chrisbrenton.org/2009/08/setting-up-a-security-information-management-system-sim-%E2%80%93-part-1/). From there you can simply copy them off to a working directory.

Next we need to open a text editor. While we can run our grep commands on the command line to test their accuracy, we want to place the commands in a shell script or batch file so they can be easily run later. For the rest of this post I will use single quotes, which is the syntax for both Linux and UNIX. Remember that your Windows version of grep may want to see double quotes instead.

The next step is to review the log file looking for traffic patterns you recognize. Let’s take an easy one like HTTP traffic to your Web server. Look closely at a log entry and identify what unique characteristics it has which tells you its HTTP traffic to your Web server. Most likely this will be the target IP address of your Web server, as well as a target port of TCP/80. Now simply create a grep command to copy these entries to a new file:

grep ‘dst 192\.168\.1\.10’ firewall.log | grep ‘dst_port 80 ’ > web_server_http.txt

Note that rather than print the output to the screen, we redirected it to a file with a descriptive name. That way the log entries are available for later review.

If our Web server is only offering HTTP, we should only see traffic headed to port TCP/80. Any other port connect attempts can be considered suspect traffic, and may be part of a scan or probe. With port TCP/80 traffic in it’s own file, we now simply redirect everything else to another file:

grep ‘dst 192\.168\.1\.10’ firewall.log | grep –v ‘dst_port 80 ’ > web_server_scan.txt

This should account for all traffic headed to our Web server. Now we need to get all of this saved traffic out of the way so it will be easier to spot other entries. While we could try to delete them, it would be prudent to keep an unmodified version of the firewall log just in case we need to refer back to it. The easiest way to handle this conflict is to simply create a new temporary file.

grep –v ‘dst 192\.168\.1\.10’ firewall.log > temp1.txt

Now we simply open “temp1.txt” and look for the next pattern we recognize. Let’s say that’s inbound and outbound SMTP. That section of our script may look something like this:

grep ‘dst 192\.168\.1\.12’ temp1.txt | grep ‘dst_port 25 ’ > smtp_inbound.txt

grep ‘dst 192\.168\.1\.12’ temp1.txt | grep –v ‘dst_port 25 ’ > smtp_server_scan.txt

grep –v ‘dst 192\.168\.1\.12’ temp1.txt > temp2.txt

grep ‘src 192\.168\.1\.12’ temp2.txt | grep ‘dst_port 25 ’ > smtp_outbound.txt

grep ‘src 192\.168\.1\.12’ temp2.txt | grep –v ‘dst_port 25 ’ > smtp_server_compromise.txt

grep –v ‘src 192\.168\.1\.12’ temp2.txt > temp3.txt

SMTP is a bidirectional service, so the first three lines take care of inbound traffic, while the last three look at outbound. Note that in line five we expect to see the server only communicating out on TCP/25. Any other port attempts may indicate the system has been compromised and is now calling home. Obviously it would be a good idea to do the same for the Web server:

grep ‘src 192\.168\.1\.10’ temp3.txt  > web_server_compromise.txt

grep –v ‘src 192\.168\.1\.10’ temp3.txt > temp4.txt

Closing out your script

Now simply repeat this process until you are left with a temp file that has log entries you don’t expect to see. It is now time to start closing out our script. First, rename your last temporary file to something that will catch your attention. On Windows the command would be:

ren temp23.txt interesting_stuff.txt

On Linux or UNIX the command would be:

mv temp23.txt interesting_stuff.txt

This interesting file will probably be the first file you are going to want to review, as it will contain all of the unexpected patterns. Now that all the normal traffic flow is out of the way, it should take substantially less time to spot anything you truly need to worry about.

One nice thing about the temp files is that they can aid in troubleshooting. For example if grep moves 1.5 MB of log entries into a new file, I should expect to see the next temp file shrink by 1.5 MB as well. If not, something is wrong in my script. Also, if you notice that all of your temp files after “temp12.txt” have a zero file length, chances are you have a syntax error just after you created “temp12.txt”.

Once your script is vetted and working however, you may not want to have the temp files in your working directory. That way it is easier to focus in on the sorted files during a review. When you reach this point, simply have the last line of your script delete the temp files. On Windows the syntax would be:

del /q temp*.txt

and on UNIX or Linux the command would be:

rm –f temp*.txt

Automating the process

Once you have a working script, it is now time to automate the process. If you are running Linux or UNIX, simply setup the script to run via cron. If you need help with configuring a cron job there are some excellent help pages. The equivalent on Windows is called a Scheduled Task, and Microsoft has some excellent help in the knowledgebase.

Final thoughts

I mentioned in my last post that I like to look for error packets. I will typically do this right at the beginning of my script. Also, it is not uncommon for systems to call home in order to check for patches. I usually put these exceptions at the beginning of my script as well. Something like:

grep ‘dst 1\.2\.3\.[60-61] ‘ firewall.log > server_patching.txt

grep ‘dst 10\.20\.30\.[1-8] ‘ firewall.log >> server_patching.txt

The first command grabs all traffic headed to 1.2.3.60 or 1.2.3.61. The second looks for traffic headed to 10.20.30.1 – 10.20.30.8. Be very careful in specifying multiple systems! This is a great way to miss something interesting in your log files. You should only use this syntax to describe known patch server. Never specify all the subnets for a particular company. For example if you filter out all Microsoft IPs this way, than a single owned system on their network could control bots on your network and you would never know it.

This syntax is also handy when writing filters for outbound log entries. For example assume that we use 192.168.1.0 – 192.168.1.24 for internal addressing. To grab all outbound HTTP traffic we could say:

grep ‘src 192\.168\.[1-24]\.[0-255] ‘ temp15.txt | grep ‘dst_port 80 ’ > outbound_http.txt

As mentioned in the last post, we may wish to check outbound HTTP during non-business hours to see if we have any Malware calling home.

Don’t forget you can use grep as part of your review process as well. For example let’s say we are reviewing interesting_stuff.txt and spot a source IP (1.2.3.4) we know is hostile. We want to check the file to see if there are any other IP addresses we need to be concerned with. While we could keep paging through the file, a simpler solution would be to use grep:

grep –v 1\.2\.3\.4 interesting_stuff.txt

You review script has the potential to act as a mini-IDS system. By this I mean if you find a suspect pattern but figure out what’s going on, don’t be afraid to leverage your script to categorize this pattern in the future.

For example, let’s say we notice a number of systems on the Internet attempting to access port 5060, but we do not have this port open through our firewall. A quick Google search will tell us that this is SIP (http://en.wikipedia.org/wiki/Session_Initiation_Protocol) traffic. Why bother to look it up every time we see it however if our script can identify it for us? Now that we know 5060 is SIP, simply add the following lines to our script:

grep ‘dst_port 5060 ‘ temp.txt > sip_traffic.txt

We can do the same for any ports that are commonly being probed.

Exec Summary

What makes firewall log review so time consuming is that you need to sift through all of the normal traffic patterns in order to find the log entries that identify a true security issue. By white listing all expected traffic patterns, it becomes far simpler to find and review any unexpected entries within your logs. By further automating the process of sorting the logs, log review can be reduced to a quick activity that can easily be performed on a daily basis.

No comments »

Posted in 3-err, Network Security

Tags:

How To Review A Firewall Log In 15 Min Or Less – Part 1

September 25th, 2009

One of the most difficult and time consuming parts of maintaining a perimeter is reviewing firewall logs. It’s not uncommon for an organization to generate 50, 100, 500 MB or more worth of firewall log entries on a daily basis. The task is so daunting in fact, that many administrators choose to ignore their logs. In this series I’ll show you how to expedite the firewall log review process so that you can complete it faster than that morning cup of coffee.

Why firewall log review is important

I once took part in a panel discussion where one of my fellow SANS instructors announced to the crowd “the perimeter is dead and just short of useless”. I remember thinking I was glad I was not one of his students. I occasionally take on new clients and find that 7/10 times I can identify at least one compromised system they did not know about. In every case it has been the client’s own firewall logs that pointed me to the infected system.

In the old days firewall log review was all about checking your inbound drop entries to look for port scans. Today the focus is on outbound traffic. Specifically, you should be checking permitted patterns. With the plethora of non-signature Malware today it has become far too easy for an attacker to get malicious code onto a system. A properly configured perimeter will show you when a compromised system tries to call home. This is typically your best chance to identify when a system has become compromised.

What needs to be logged?

Dropped traffic does not have to be logged provided you are not blind to DoS flood attacks. For example if you are running a tool such as NTOP on your perimeter, collecting RMON or Netflow data, than it is OK not to log dropped packets as you can collect this information through other means.

When traffic is permitted across the perimeter however, you need to log it. This includes all permitted traffic, regardless of direction (egress as well as ingress). At a minimum we want to see header information for the first packet in a session. Anything beyond that can be considered a bonus.

Some kernel level rootkits do an excellent job of hiding themselves within the infected system. In fact many are so stealthy they cannot be detected by checking the system directly. One possible option is to pull the hard drive and check it from a known to be clean system. Obviously this is highly impractical whenever you have more than just a couple of systems.

A better option is to check the network for tell tale signs of the Malware calling home. Malware typically creates outbound sessions either to transfer a toolkit or check in for marching orders. The firewall is in an optimal position to potentially block, or at the very least log, both of these activity patterns. So by reviewing our firewall logs, we can quickly check every system on our network for indications of a compromise.

Malware can leverage any socket to call home, but most use TCP/80 (HTTP) or TCP/443 (HTTPS). This is because Malware authors know most firewall administrators do not log these outbound sessions because they are responsible for the greatest portion of perimeter traffic. So again, if we are going to permit the traffic to pass our perimeter, we must insure we are logging it.

Log review as a process

The mistake I see most administrators make is they perform a time linear analysis of their log entries looking for “the interesting stuff”. The problem is suspect traffic can be extremely difficult to detect this way as it will be mixed in with normal traffic flow. So the first thing we need to do is get the normal traffic out of the way.

Think of the rectangle in Figure #1 as representing your firewall log. Assume it contains a mixture of normal as well as suspect traffic patterns. Rather than immediately looking for the suspect patterns, let’s first get the normal patterns out of the way. For example HTTP headed to our Web server from the Internet is an expected pattern. If we pull all of these entries out of the log file, the log file becomes a little bit smaller. Inbound and outbound SMTP to our mail server is another expected pattern. Again, if we can remove these entries as well the firewall log file becomes even smaller.

firewall-log-review-process

Now we simply continue this process for every traffic pattern we expect to see crossing our perimeter. The more traffic patterns we recognize and move out of the way, the smaller the final log file becomes. What’s left is just the unexpected traffic patterns that require review time from a firewall administrator. I’ve seen sites that typically generate 250-300 MB worth of logs daily end up with a final file less that 100 KB in size. Needless to say 100 KB takes far less time to review that 300 MB.

Automate, automate, automate

If this seems like a lot of work, it only will be initially. What I do is create a batch file, shell script, or set of database queries to automate the process of parsing the firewall log. We can then run this process as a CRON job or scheduled task. This means that all of the hard work (breaking up the main log file into smaller files) can be done off hours. When you walk in the door in the morning, the log file will already be segregated. You can then immediately focus in on the suspect patterns.

Helpful tips

Here are some tips I’ve developed over the years:

  • There is no “single right way” to segregate log entries. It is all about how you personally spot unsuspected patterns. You can sort by IP address, port number, or whatever info you have to work with in your logs.
  • This is not about obsessively putting one log entry into every sort file. This process is about creating easier to spot patterns. For example a TCP reset in an HTTP stream could go in both an “error” file and an “HTTP” file. Each would make it easier to spot different types of patterns.
  • Start by pulling our error packets (TCP resets, ICMP type 3’s & 11’s). They always indicate something is broke or someone did something unexpected.
  • A smart attacker will never make your “top 5 communicators” list. I’ve seen infected systems make as few as four outbound connections in a day.
  • Make a note of the average size of each of your sort files. A sharp spike in traffic may warrant further investigation.
  • Sometimes it is helpful to parse the same pattern into two different files. For example I create an “outbound HTTP” file, and then parse out all of the traffic generate during non-business hours. This makes it much easier to find infected systems calling home.
  • Whitelist know patch sites. For example systems may call home all night long to Microsoft and Adobe to check for updated patches. If you can parse out these entries, you’ll end up with far less noise in your final file.
  • Some sites find it helpful to parse out users checking their personal email. This can be helpful information if data leakage occurs.
  • I like to segregate traffic based on security zone. For example I would be far less concerned about SSH from the internal network to the DMZ, than I would about SSH headed to the Internet. If you are not sure why, read this.
  • In an ideal world, ever traffic pattern you find will be described in your organization’s network usage policy. If its not, then further investigation may be required.
  • Expect to tweak your script over time, as networks are an evolving entity.

Exec Summary

White listing expected traffic patterns in your firewall log can help to expedite the log review process. Similar traffic becomes grouped together, and can be more easily checked for suspect patterns. In part 2 of this series I’ll walk you through the process of creating your own script using a number of different firewall products.

No comments »

Posted in 3-err, Network Security

Tags:

Ubergeek Your Laptop For SANS Labs

September 17th, 2009

This morning I’m in San Diego giving a talk on how to work more effectively at the Window’s command line. Here’s a PDF version of the presentation for anyone that is interested:

uber-geek-laptop-R3.pdf

No comments »

Posted in 5-info, Windows Security

Tags:

SANS 502 VMware VMX file

September 16th, 2009

This post is just for the folks out in San Diego taking my SANS 502 Perimeter course. I just created a new DVD for the class, and inadvertently missed a file. Here is the VMware loader file I promised as well as instructions for use:

  1. You need a copy of VMware Player
  2. Grab 502-vmware-loader.zip and unzip it into an empty directory on your system
  3. Copy 502-course-dvd.iso (1.2 GB) from the course DVD into this directory as well
  4. Double click 502-vmware-loader.vmx

Note that you are welcome to run a VMware version of the course DVD in the labs, with the following exceptions:

  • VMware is known to change IP ID increments, so you should not use it during the idle scan lab
  • VMware does not provide a true Ethernet bus, so you should not use it during any lab that involves session hijacking

No comments »

Posted in 5-info

Passively Fingerprinting VMware Virtual Systems

September 15th, 2009

There have been some excellent papers written on how to detect if an operating system is running as a Vmware guest image. Automated tools have even been released to help expedite the process. All assume however that terminal or command prompt access is required to perform the detection. Few people realize that it is possible to passively detect a Vmware guest without any level of system access. In fact, if you know what to look for, you can even identify which version of VMware is hosting the virtual system.

Passive fingerprinting

Passive fingerprinting is a technique where by a remote operating system can be identified by the nuances in the IP packets it produces. For example the payload of Echo-Request packets are pretty unique from operating system to operating system. In a previous post I discussed how different operating systems use different time to live values. By analyzing these variations in the IP packets, you can do a pretty accurate job of identifying the source operating system. In fact many times you can even identify the patch reversion level of the system.

VMware virtual systems

VMware supports two modes for connecting a guest operating system to a network. You can NAT it behind the host, or connect it in bridging mode. Many people think that bridging mode gives the guest OS direct access to the network card, but they forget that VMware is still sitting in between the guest OS and the host system’s drivers to run the NIC. It is not uncommon for this layer to make changes in the IP packets before passing them onto the wire. So if you know what changes to look for, you can detect when VMware software is sitting between an operating system and the local network.

VMware makes multiple changes to the IP datastream. In this post we will only look at two of these changes (window size and scaling), and I’ll leave it to the reader to try and find the others. Further, different versions of VMware will modify the IP datastream in different ways. If you know what changes are unique to each version, you can identify the release level of VMware sitting between the guest OS and the network.

Window size and window scaling

TCP uses window size to identify how much data can be transmitted before a remote system must pause and wait for an acknowledgement. For example if “System A” tells “System B”, “window size = 1400”, “System B” is permitted to send just under one full size Ethernet packet before it must wait. After the 1400 bytes are transmitted, “System B” is not permitted to send any more data till it receives an acknowledgement of that data from “System A”. Window size is adjusted on the fly, so “System A” may eventually advertise “window size = 1600”. This means “System B” can now send a full size packet followed by one small packet before it must pause for an acknowledgement. Window size is a method of flow control to help insure that the receiving system does not see more data than it’s buffers can handle.

Window size dates back to the original implementation of TCP. At the time 16 bits were reserved (bytes 14 and 15 in the TCP header) to specify how many bytes could be transferred before pausing for an acknowledgement. This means we could specify a maximum window size of 65,535 bytes. That’s more than big enough by 1980 standards, but not so great when you are talking about 1 Gb and faster networks. In the early 90’s window scaling was added as a TCP option. Window scaling is only advertised in the first TCP packet sent by a system (SYN or SYN/ACK packet) and is a multiplier for the advertised window size. For example, assume a window size of 1400 bytes. If the window scale is 3, the math would be:

(2*2*2) * 1,400 = 11,200

If the window scale is 4, the math becomes:

(2*2*2*2) * 1,400 = 22,400

So window scaling permits us to now advertise much larger window sizes. This explanation is rather simplistic, but should give the reader a good idea of how window size and scale works. For more info see RFC 1323 or the TCP Wiki.

Backtrack 3 final as a stand-alone host

Here’s a SYN/ACK response to a connection request returned by a Backtrack 3 system (Linux 2.6.21.5 kernel) running on a dedicated host:

IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.100.4.80 > 192.168.100.50.44943: S, cksum 0×9552 (correct), 2760872392:2760872392(0) ack 4071399005 win 5792 <mss 1460,sackOK,timestamp 5362662 198395,nop,wscale 5>

Note the initial window scale is 5, which means the actual window size is 32 * 5792 = 185,344. This is pretty common for Linux systems running a post 2.6.17 kernel.

Now let’s take a look at how the window size for Backtrack 3 gets incremented:

[root@fubar ~]# tshark -n -T fields -e ip.src -e tcp.window_size -e tcp.options.wscale_val dst host 192.168.100.50

Capturing on eth0

192.168.100.4     5792      5

192.168.100.4     245

192.168.100.4     336

192.168.100.4     426

192.168.100.4     517

192.168.100.4     607

192.168.100.4     698

192.168.100.4     788

192.168.100.4     879

192.168.100.4     969

192.168.100.4     1060

I used tshark to clean up the output so we could focus on the fields we actually care about. The above trace is a large data transfer to 192.168.100.4 (BT3 stand alone) via TCP/80, as show in the above tcpdump trace. Note that we can pretty clearly identify how the window size was incremented over the data session.

Backtrack 3 final, guest on Windows XP Workstation

So let’s take a look at how window size and scaling get affected when the operating system is sitting behind VMware. In this test I ran BT 3 as a guest operating system on a Windows XP workstation host. I used VMware player 2.5.3 and wrote a custom VMX file to run the BT 3 iso.

Here’s an initial SYN/ACK packet:

IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.100.7.80 > 192.168.100.50.35245: S, cksum 0x670d (correct), 3795217952:3795217952(0) ack 4108648760 win 5792 <mss 1460,sackOK,timestamp 5210512 208486,nop,wscale 4>

Note that while the initial window size matches the stand-alone BT 3 system, VMware has dropped the window scaling from 5 (32x) to 4 (16x).

Here’s the stream of packets being returned by the guest system:

[root@fubar ~]# tshark -n -T fields -e ip.src -e tcp.window_size -e tcp.options.wscale_val dst host 192.168.100.50

Capturing on eth0

192.168.100.7     5792      4

192.168.100.7     490

192.168.100.7     671

192.168.100.7     852

192.168.100.7     1033

192.168.100.7     1214

192.168.100.7     1395

192.168.100.7     1576

192.168.100.7     1757

192.168.100.7     1938

192.168.100.7     2119

Note that after the first packet the negotiated window size appears larger, but when you factor in the window scale multiplier the overall window size ends up being slightly smaller than BT 3 when it is run on a dedicated system. Not all that surprising as virtual systems typically run slower than dedicated systems, but we’ve just tagged two differences we can look for to determine if the host is stand-alone or a guest virtual image.

Backtrack 3 final, guest on Fedora 11

Of course the big question is, “was the window size change due to the Windows XP host or VMware?”. VMware circumvents the Windows IP stack when transmitting on the wire, so the host OS should have no effect on the packet stream. To verify this, let’s try the same test using the same version of VMware player, only this time we’ll use Linux as the hosting operating system. Here’s the SYN/ACK:

IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.100.13.80 > 192.168.100.50.43363: S, cksum 0x6ef7 (correct), 3423175369:3423175369(0) ack 483782889 win 5792 <mss 1460,sackOK,timestamp 579990 366817,nop,wscale 4>

Here’s the stream of packets being returned from TCP/80 on the guest BT 3 system:

[root@fubar ~]# tshark -n -T fields -e ip.src -e tcp.window_size -e tcp.options.wscale_val dst host 192.168.100.50

Capturing on eth0

192.168.100.13    5792      4

192.168.100.13    490

192.168.100.13    671

192.168.100.13    852

192.168.100.13    1033

192.168.100.13    1214

192.168.100.13    1395

192.168.100.13    1576

192.168.100.13    1757

192.168.100.13    1938

192.168.100.13    2119

Note the results are identical to when BT3 was the guest operating system on Windows XP. So while this methodology will not identify the host operating system being used, we can consistently determine if BT3 is running on a dedicated system or as a guest via VMware. While it is entirely possible to modify a dedicated system to appear to be a virtual guest, the opposite does not appear to be feasible.

Exec Summary

By having an in-depth understanding of IP and the nuances generated by different operating systems, it is possible to determine if an OS is running on a dedicated system or as a guest via VMware. Modifications made by the VMware wrapper leave behind tell tale clues. A smart packet weenie can leverage these clues to determine the virtualization status of the source operating system.

No comments »

Posted in 2-alert, Packet Decoding

Tags:

Cybersecurity Act of 2009 In-Depth – Part 2

September 11th, 2009

In yesterday’s post I covered the first half of the Cybersecurity Act of 2009. Here’s the write up on the second half of the bill.

Section 13: Cybersecurity competition and challenge

As the name implies, this sets up funding for a series of competitions to help identify the best and the brightest.

(a) IN GENERAL- The Director of the National Institute of Standards and Technology, directly or through appropriate Federal entities, shall establish cybersecurity competitions and challenges with cash prizes in order to–

(1) attract, identify, evaluate, and recruit talented individuals for the Federal information technology workforce; and

(2) stimulate innovation in basic and applied cybersecurity research, technology development, and prototype demonstration that have the potential for application to the Federal information technology activities of the Federal Government.

No red flags here. Prizes cannot exceed $1M without checks and balances kicking in. Don’t get your hopes up. That’s for an entire event, not one specific prize.

Section 14: Public-private clearinghouse

This section seems pretty benign, till you read it closely. Here’s the opening section:

(a) DESIGNATION- The Department of Commerce shall serve as the clearinghouse of cybersecurity threat and vulnerability information to Federal Government and private sector owned critical infrastructure information systems and networks.

Yawn. I see this as something you cannot mandate. If you can provide useful information, users will seek out what you have to say. If you simply reprint what has already been released as open source, then my Google news feed will probably get me the info faster and with a better interface. It is easy to want to ignore this section based on this opening statement, but please read a bit further:

(b) FUNCTIONS- The Secretary of Commerce–

(1) shall have access to all relevant data concerning such networks without regard to any provision of law, regulation, rule, or policy restricting such access;

What??? This to me is the ultimate power grab. So any network or system that can be deemed “critical infrastructure” has to let the commerce department have unfettered access to their network. This access is without regard to due process or the rule of law. “Relevant” is a highly subjective term that can be applied to anything.

So it comes back to that “critical infrastructure” description that we already stated is the judgment call of a single individual. Maybe Microsoft’s network should be deemed critical infrastructure, as they are the government’s primary desktop vendor. Perhaps Linux development servers should also be deemed “critical” as servers, appliances, and embedded technology is based on this platform. What about Anti-Virus and firewall vendors who supply products to the government? Internet service providers servicing government networks? Telco’s servicing government employees? Universities funded to develop cyber protection techniques? This can be an extremely slippery slope.

To me, this is probably the single most dangerous part of the bill.

Section 15: Cybersecurity risk management report

In short, this section requires the President to produce a report within one year that identifies:

(1) creating a market for cybersecurity risk management, including the creation of a system of civil liability and insurance (including government reinsurance); and

(2) requiring cybersecurity to be a factor in all bond ratings.

This item could be taken in a number of directions. If they are smart, they will look at the feasibility of voiding end user agreements so that software vendors must accept liability for the security failing in their product. Without liability, vendors have little motivation to architect in a security framework from product inception. It is much easier and cheaper to glue it on after paying customers have already encounter problems.

Section 16: Legal framework review and report

This section calls for the President’s office to review existing cybersecurity laws regarding:

the Federal statutory and legal framework applicable to cyber-related activities in the United States

In short, this is a review to see if the laws are still applicable or need updating.

Section 17: Authentication and civil liberties report

Here’s the entire section:

Within 1 year after the date of enactment of this Act, the President, or the President’s designee, shall review, and report to Congress, on the feasibility of an identity management and authentication program, with the appropriate civil liberties and privacy protections, for government and critical infrastructure information systems and networks.

I’m not sure what to make of this section. It reads like they want to find a single sign-on solution for government networks. If that is the case, I don’t understand the “appropriate civil liberties and privacy protections” statement. This implies an application that is geared more towards the general public. Jury is still out on this section as I have not seen any other opinions on it.

Section 18: Cybersecurity responsibility and authority

Here’s the section that everyone is freaking out about. The blurb:

The President–

(2) may declare a cybersecurity emergency and order the limitation or shutdown of Internet traffic to and from any compromised Federal Government or United States critical infrastructure information system or network;

Sounds bad, but think of it this way. When planes were crashing into building the President ordered the grounding of all commercial flights. I doubt there was a specific law giving him that specific authority, but given it was an emergency situation no one argued the point or considered it an abuse of power.

I see this provision as being similar. If it is confirmed that attackers have taken control of the power grid and are now systematically shutting it down, no one is going to fault the President for requiring those organizations to isolate themselves from the Internet at large. It may or may not actually fix the problem, but it would be an expected defense posture. This would occur with or without this provision in the bill.

So to me this section is a lot of hoopla about nothing. Some of the previously discussed sections are far scarier.

Another interesting point in this section:

(5) shall direct the periodic mapping of Federal Government and United States critical infrastructure information systems or networks, and shall develop metrics to measure the effectiveness of the mapping process

To some extent, this process has already started as part of the Trusted Internet Connect (TIC) program. I’m actually kind of surprised it is not already a requirement. It is possible this is already being done but that data was unavailable when the bill was written.

Section 19: Quadrennial cyber review

(a) IN GENERAL- Beginning with 2013 and in every fourth year thereafter, the President, or the President’s designee, shall complete a review of the cyber posture of the United States, including an unclassified summary of roles, missions, accomplishments, plans, and programs.

In short, each new president gets to provide commentary on how they think their predecessor performed with regards to cybersecurity. This report would be far more useful if it was required a year earlier. That way it would act as a briefing for the new President. It would give them a better idea of what is required going forward.

Section 20: Joint intelligence threat assessment

Specifies (yet another) annual report on cybersecurity to Congress. Nothing to see here. Move along.

Section 21: International norms and cybersecurity deterrence measures

Here’s the clip:

The President shall–

(1) work with representatives of foreign governments–

(A) to develop norms, organizations, and other cooperative activities for international engagement to improve cybersecurity; and

(B) to encourage international cooperation in improving cybersecurity on a global basis

I see this as being more the role of the Department of Justice. What is needed is better interaction between law enforcement across international borders, not PR snippets and posturing. Think of it this way, what would be more effective in deterring physical crimes over state borders, frequent interaction between state law enforcement agencies, or frequent interaction between Governors?

Section 22: Federal secure products and services acquisitions board

To me, this is probably one of the most positive sections of the bill. Here’s the blurb:

(a) ESTABLISHMENT- There is established a Secure Products and Services Acquisitions Board. The Board shall be responsible for cybersecurity review and approval of high value products and services acquisition and, in coordination with the National Institute of Standards and Technology, for the establishment of appropriate standards for the validation of software to be acquired by the Federal Government.

In short, the government would be using its combined purchasing power to enforce security standards for all software purchases. This can have a profound impact on the commercial industry. Vendors love to complain that it is too expensive to ship secured software. Now if they wish to sell to the government, they will have to meet the appropriate NIST standards. Most likely the secured software would be available for commercial purchase as well. So out of the box you would end up with a more secure product.

Again, I see this as an extremely positive requirement. While vendors may grumble about it, as customers we would all benefit.

Section 23: Definitions

This is simply a definition of terms used in the bill. All are either common terms (like “Internet”) or described in earlier sections.

Exec Summary

There are things to love as well as fear in this bill. It increases funding for cybersecurity research as well as leverages the government’s buying power to generate more secure software for everyone. At the same time it attempts to circumvent established processes (as well as rules of law) that have the potential to make the cybersecurity situation worse rather than better. The bill is currently being reviewed by the Senate Committee on Commerce, Science, and Transportation. Now is the time to voice any praises or concerns you may have.

3 comments »

Posted in 1-emerg, General Security

Cybersecurity Act of 2009 In-Depth – Part 1

September 10th, 2009

There have been quite a few articles on the Cybersecurity Act of 2009. Most have focused on the section that would give the president the power to “shutdown the Internet”. But are there other things in this bill you should be even more concerned about? Is there anything actually useful in the bill? In this two part post I’ll take you through the bill section by section.

The first two sections are simply the index and the findings. One notable quote from section 2:

(1) America’s failure to protect cyberspace is one of the most urgent national security problems facing the country.

This sets the tone for the rest of the section and I have to say I agree with the statement. Security wise we truly are in worse shape than most people want to believe.

Section 3: Cybersecurity advisory panel

These two quotes really say it all:

(a) IN GENERAL- The President shall establish or designate a Cybersecurity Advisory Panel.

(c) DUTIES- The panel shall advise the President on matters relating to the national cybersecurity program and strategy

I have mixed feelings regarding these points. I think that cybersecurity is important enough to deserve high-level visibility. However this bill goes hand in hand with S. 788, a bill to create the position of Cybersecurity Advisor, and H.R. 1910, a bill to create the position of Chief Technology Officer. Both of these positions would report directly to the president, so it seems more useful to have the panel fall under these two rolls in the national org chart. May just be semantics, but one of the issues we have today is parallel tenure with no clear ownership of problems. If all three bills pass I see a higher chance of creating conflicts rather than resolutions.

Section 4: Real time cybersecurity dashboard

I’ve seen little attention given to this item, but there is an easily dismissible statement made in this section:

The Secretary of Commerce shall

(1) in consultation with the Office of Management and Budget, develop a plan within 90 days after the date of enactment of this Act to implement a system to provide dynamic, comprehensive, real-time cybersecurity status and vulnerability information of all Federal Government information systems and networks managed by the Department of Commerce;

A couple of points here, why just the department of commerce? If this will be a truly useful resource, why not extend it’s use beyond this one government office? Also, the statement is a bit vague. This could be as ineffectual as the National Threat level or a subset of the data provided by sites such as DShield or Homeland Security’s Open Source Infrastructure Report. Either way I see this as a long-term failure.

Section 5: State and regional cybersecurity program

Here’s the focus of this section:

(a) CREATION AND SUPPORT OF CYBERSECURITY CENTERS- The Secretary of Commerce shall provide assistance for the creation and support of Regional Cybersecurity Centers for the promotion and implementation of cybersecurity standards. Each Center shall be affiliated with a United States-based nonprofit institution or organization, or consortium thereof, that applies for and is awarded financial assistance under this section.

Sounds good on the first read, but what’s up with the “affiliated with… nonprofit organizations” section? We could easily end up with a non-centralized system with no clear point of contact for their target audience. So if I need help with cybersecurity, I should go to… The Jimmy Fund? Farm Aid? Or maybe it’s the Tennessee Elephant Sanctuary?

Personally, I think these centers should be affiliated with InfraGard. They are established in nearly every state, already have a long history of community outreach, and are already focused on dealing with cybersecurity issues. My guess is that the commerce department wants complete control, while InfraGard is already associated with the FBI.

So what is the goal of creating these centers?

(b) PURPOSE- The purpose of the Centers is to enhance the cybersecurity of small and medium sized businesses in United States

This is an admirable goal. Due to lack of resources, small and medium size businesses are struggling the most. Probably the only demographic that is larger would be home users. If we could take steps to support these organizations, it would go a long way towards fortifying our national security posture.

The centers would support small and medium businesses by:

(1) disseminate cybersecurity technologies, standard, and processes based on research by the Institute for the purpose of demonstrations and technology transfer;

(2) actively transfer and disseminate cybersecurity strategies, best practices, standards, and technologies to protect against and mitigate the risk of cyber attacks to a wide range of companies and enterprises, particularly small- and medium-sized businesses; and

(3) make loans, on a selective, short-term basis, of items of advanced cybersecurity countermeasures to small businesses with less than 100 employees.

Again, I see these activities as a great fit for InfraGard. Deployment would be expedited as there is already a national structure. These would dramatically cut the curve on making these resources available.

Section 6: NIST standards development and compliance

The bill looks to NIST to develop security standards for all government agencies:

(a) IN GENERAL- Within 1 year after the date of enactment of this Act, the National Institute of Standards and Technology shall establish measurable and auditable cybersecurity standards for all Federal Government, government contractor, or grantee critical infrastructure information systems and networks

NIST is already responsible for setting standards. In fact their security documents are considered to be some of the best in the industry. Per the Information Technology Reform Act of 1996, NIST is already charged with developing Federal Information Processing Standards (FIPS).

I’m not a lawyer, but I don’t see anything in this section that has not already been specified by earlier bills except this tid bit under “(d) Compliance enforcement”:

(2) shall require each Federal agency, and each operator of an information system or network designated by the President as a critical infrastructure information system or network, periodically to demonstrate compliance with the standards established under this section.

I’m honestly not sure if the President currently has the power to (arbitrarily?) designate any network or system as “critical” and thus subject to this section. I prefer specific definitions versus subjectively trusting the judgment of a single individual. This way we are covered in both directions, from systems that should have been included but were missed, as well as systems that don’t really belong on the list.

Section 7: Licensing and certification of cybersecurity professionals

This section really scares me as it has the potential to do more harm than good. Here’s the description:

(a) IN GENERAL- Within 1 year after the date of enactment of this Act, the Secretary of Commerce shall develop or coordinate and integrate a national licensing, certification, and periodic recertification program for cybersecurity professionals.

To me, someone who has no idea of the scope of what is needed to address the problem wrote this section. Cybersecurity is not a single discipline. There are experts that focus on Malware analysis, perimeter security, packet decoding and intrusion analysis, incident handling, host specific security, auditing, forensics, wireless, databases, and the list goes on and on. A national certification and licensing program would end up being one of the following:

  1. So general it really does not mean anything
  2. So difficult “certified” resources would be hard to come by

Because of the diversity of the cybersecurity field, there really is no middle ground. This section then goes on to say:

(b) MANDATORY LICENSING- Beginning 3 years after the date of enactment of this Act, it shall be unlawful for any individual to engage in business in the United States, or to be employed in the United States, as a provider of cybersecurity services to any Federal agency or an information system or network designated by the President, or the President’s designee, as a critical infrastructure information system or network, who is not licensed and certified under the program.

Wait a minute. Let’s just take one glaring example. Alan Paller is the Director of Research at SANS, was quoted in this bill (Section 2, #8), and is one of my personal heroes in this industry. He’s provided council to the White House and Congress multiple times. He’s one of those unique individuals that can mediate the gap between folks that speak different languages (geeks, CFO, COO, etc.). While he knows the industry, he’s not the kind of guy that spends time writing Nessus plug-ins or decoding TCP attack streams. Is it truly the intent of this bill to loose resources like Alan if they choose not to certify?

There is a pattern here however. Like so many line items before it, this section puts control in the hands of the commerce department. So I personally think this is less about ensuring we have skilled personnel supporting network security, and more about grabbing power.

Section 8: Review of NTIA domain name contracts

This is another scary section:

(a) IN GENERAL- No action by the Assistant Secretary of Commerce for Communications and Information after the date of enactment of this Act with respect to the renewal or modification of a contract related to the operation of the Internet Assigned Numbers Authority, shall be final until the Advisory Panel–

(1) has reviewed the action;

(2) considered the commercial and national security implications of the action; and

(3) approved the action.

The Internet Assigned Numbers Authority (IANA) is run by The Internet Corporation for Assigned Names and Numbers (ICANN). This is a non-profit international organization that is responsible for guiding (not implementing) high-level operations of the Internet. They take guidance from a number of organizations, including the Internet Engineering Task Force (IETF) who defines the standards for Internet communications. The IETF is an international organization made up of everyone from individual researchers to vendors.

To me, this section sounds like an attempt to bring financial pressure on these organizations. Again, this seems to be an attempt to consolidate more power under the department of commerce. Especially when you combine it with section 9.

Section 9: Secure domain name addresses system

Here’s the clip:

(a) IN GENERAL- Within 3 years after the date of enactment of this Act, the Assistant Secretary of Commerce for Communications and Information shall develop a strategy to implement a secure domain name addressing system. The Assistant Secretary shall publish notice of the system requirements in the Federal Register together with an implementation schedule for Federal agencies and information systems or networks designated by the President, or the President’s designee, as critical infrastructure information systems or networks.

As mentioned in the last section, developing Internet standards in the role of the IETF, not the commerce department. Further, we already have standards to secure the domain name structure (DNSSEC) as well as routing and the IP addressing scheme (sBGP). The problem is their deployment has been extremely slow. What we need is deployment of the existing standards, not competitive ones developed outside of the accepted IETF process.

This section then goes on to say:

(b) COMPLIANCE REQUIRED- The President shall ensure that each Federal agency and each such system or network implements the secure domain name addressing system in accordance with the schedule published by the Assistant Secretary.

OK here’s the problem. In order to secure IP and DNS the solution has to be implemented globally. That’s part of the reason why it has been taking so long. If the federal government today deployed DNSSEC and sBGP it would do little to prevent domain name hijacking or route redirection because attackers could simply work outside of the government’s perimeter.

I have to say I share the frustration in this area. Both DNSSEC and sBGP have been around for 10 years. I think we need to suck it up on the disruptions that may be caused by deployment and just get the job done. Perhaps ICANN needs a fire lit under their butts to create some forward motion. I’m just not convinced these two sections are the way to go about it.

Section 10: Promoting cybersecurity awareness

You knew a PR campaign has to be included in here somewhere, right? Here’s the blurb:

The Secretary of Commerce shall develop and implement a national cybersecurity awareness campaign

Not sure how useful this will be because the news feeds are already full of stories that describe our current state of security. I see this as having the potential to be silly rather than informative. I have these visions of walking into my kid’s school and seeing a poster that states “Billy Bytes Says Don’t Be A H4X0r”. OK, hopefully that will never happen, but you never know. ;)

Section 11: Federal cybersecurity research and development

Here’s the initial statement:

(a) FUNDAMENTAL CYBERSECURITY RESEARCH- The Director of the National Science Foundation shall give priority to computer and information science and engineering research to ensure substantial support is provided to meet the following challenges in cybersecurity:

This section dumps a lot of money into the research and development of cybersecurity techniques. It amends existing bills to increase spending by $265M in 2010, to over $310M by 2014. There are already other programs that fund cybersecurity research, but provided the funds are managed appropriately I see this as being helpful to the cause.

Section 12: Federal cyber scholarship for service program

Here’s the clip:

(a) IN GENERAL- The Director of the National Science Foundation shall establish a Federal Cyber Scholarship-for-Service program to recruit and train the next generation of Federal information technology workers and security managers.

This is no different than many other “scholarship for service” programs. I see this as being beneficial to both the student as well as the government. $50M has been allocated to the program, increasing to $70M by 2014.

Summary

That’s it for now. Tomorrow I’ll post the last half of the bill.

No comments »

Posted in 1-emerg, General Security

Hiding A Backdoor Behind An Active Windows Listening Port

September 3rd, 2009

Its a common technique. You suspect one of your systems has been compromised, so you run a port scanner against the system. The hope is that if the system is backdoored you will identify an undocumented listening port. But what if a clever attacker hides the backdoor in plain site? What if they hide the backdoor behind an existing port you actually expect to see listening on the system? Unfortunately this is far too easy to accomplish if the host is running Windows.

The UNIX way

On a UNIX or Linux system, listening ports are always opened exclusively. In other words, if a mail process opens up TCP/25 to accept inbound mail connections, any other application that attempts to listen on TCP/25 will receive a bind error and be denied access. The only way the second application can bind to TCP/25, is to first kill off the mail process using the port. So only one application at a time is ever permitted access to a listening socket.

The Windows way

In Windows, exclusive access to a listening port is optional. Its perfectly legal to have multiple applications listening on the same TCP or UDP port. This of course can simplify the process of setting up a backdoor behind an existing application.

With Windows, exclusivity of socket access is actually a process that has been evolving over the years. Windows 95, 98 and ME actually had no way to open a port exclusively. There was nothing one application could do to prevent another from attaching to the same listening port. For versions of Windows between NT and XP, it is possible to request exclusive port access via the SO_EXCLUSIVEADDRUSE option. If exclusive access is not specifically requested however, the default is to fall back to providing shared access.

With Windows 2003 and later, the default is exclusive port access unless both applications specifically request shared access via the SO_REUSEADDR option. The exception is that if the same account is used to launch both applications, shared access is still possible unless exclusive access is specifically requested. This means that if a savvy attacker can launch their backdoor via the system account, this enhanced security will usually be defeated.

Try it yourself

To test how this works, you’ll need a copy of the Windows version of Netcat. Copy nc.exe into one of the directories in your path statement. Once you do, open a command prompt and try the following command:

C:\>nc -l -p 135

Can’t grab 0.0.0.0:135 with bind

We just told Netcat to listen (-l) on TCP port (-p) 135. When Windows first boots up, Microsoft RPC opens TCP/135 with the SO_EXCLUSIVEADDRUSE option set. Thus if any application (like Netcat) tries to listen on TCP/135, it receives the bind error shown above. This is the type of behavior we would like to see all of the time.

Now try opening a port that is not already in use:

C:\>nc -l -p 1234

It should appear as if the command is hanging (command prompt does not return). This tells you that Netcat is now listening on port TCP/1234. To verify this, open a second command prompt and type the command:

C:\>netstat -an | find “1234″

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING

This shows us that Netcat is now listening on TCP/1234 on all network interfaces.

When Netcat opens a listening port it does not request exclusive access to the port. This means it is possible to bind Netcat to an existing listening port that has not already been opened exclusively. To test this, open a third and fourth command prompt. Enter the same Netcat command into each that you run within the first command prompt. Each command should execute without error.

Does this mean Netcat is listening multiple times? Go back to the second command prompt window and try the following command:

C:\>netstat -aon | find “1234″

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING 448

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING 3044

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING 3016

We’ve added in the “o” switch which prints out the process ID for the application holding open the listening port. Note that a different instance of Netcat is responsible for each of the open listening ports. Because Netcat does not require exclusive access to the port, we can listen on the port multiple times.

So what happens when someone tries to connect to the port? Try it and find out using the following command:

C:\>nc 127.0.0.1 1234

This is a test

You should see the text “This is a test” appear in only one instance of the Netcat listeners. If you leave this session active and open (yet another) command prompt and type:

C:\>nc 127.0.0.1 1234

This is test 2

You should see this text appear in a different instance of the Netcat listener.

What have we learned

Since Windows does not require applications to have exclusive access to a listening port, its possible to have a malicious backdoor sitting behind a legitimate application, on the same listening port. This makes the backdoor undetectable when performing a port scan. In order to connect to the backdoor you must first busy out the legitimate application with an active session, but this is easy to achieve.

No comments »

Posted in 2-alert, Windows Security

Tags:

Filtering Packet Output With Tshark

September 1st, 2009

In my last post we were looking at some packet decodes. One of the biggest pains in working with decodes is following a specific field over multiple packets. Some fields are not too bad as they tend to get printed by default. Good examples are port numbers and TCP flag settings. But in the last post we were working with the IP ID. That usually only gets printed if you view verbose information, so now you end up with a lot of data on the screen that you do not care about.

Luckily, the new version of tshark fixes this problem. Let’s work with some example so you can see what I mean.

What is tshark?

Tshark is the command line packet utility that is included with Wireshark. If you are not familiar with Wireshark, it is arguably one of the best graphical packet decoding tools available today, and it is free for use. There are versions that run on Linux, BSD and Windows (YES! Even Windows!).

So why work at the command line if there is a GUI version? In the case of tshark, it is because you can get a better presentation layout of the data you actually want to see.

The problem

So let’s say we want to monitor the IP ID increment for multiple packets leaving a system. We may try a command similar to the following:

C:\>tshark -n -i 3 src host 192.168.100.5

Capturing on Intel(R) PRO/100 VE Network Connection (Microsoft’s Packet Scheduler)

0.000000 192.168.100.5 -> 192.168.100.3 TCP 0 > 1832 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

1.003331 192.168.100.5 -> 192.168.100.3 TCP 0 > 1833 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

2.007332 192.168.100.5 -> 192.168.100.3 TCP 0 > 1834 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

3.011347 192.168.100.5 -> 192.168.100.3 TCP 0 > 1835 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

4.015336 192.168.100.5 -> 192.168.100.3 TCP 0 > 1836 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

The above command tells tshark not to perform name resolution, listen on the system’s third interface, and only capture packets originating from the system at 192.168.100.5. There is a problem however, where’s the IP ID? Unfortunately, tshark, like tcpdump and windump, does not print the IP ID value by default. Even Wireshark buries it in the middle pane so it can be difficult to spot and follow over multiple packets.

So what to do? Normally we would simply add in the “verbose” switch. This is what I used in the last post to print the IP ID with tcpdump. With tcpdump and windump you use the switch “-v”, but with tshark the switch is capitalized “-V”. Here’s an example:

C:\>tshark -n -i 3 -V src host 192.168.100.5

Capturing on Intel(R) PRO/100 VE Network Connection (Microsoft’s Packet Scheduler)

Frame 1 (54 bytes on wire, 54 bytes captured)

Arrival Time: Aug 31, 2009 13:18:42.532218000

[Time delta from previous captured frame: 0.000000000 seconds]

[Time delta from previous displayed frame: 0.000000000 seconds]

[Time since reference or first frame: 0.000000000 seconds]

Frame Number: 1

Frame Length: 54 bytes

Capture Length: 54 bytes

[Frame is marked: False]

[Protocols in frame: eth:ip:tcp]

Ethernet II, Src: 00:07:e9:46:2d:55 (00:07:e9:46:2d:55), Dst: 00:17:08:54:9a:00 (00:17:08:54:9a:00)

Destination: 00:17:08:54:9a:00 (00:17:08:54:9a:00)

Address: 00:17:08:54:9a:00 (00:17:08:54:9a:00)

…. …0 …. …. …. …. = IG bit: Individual address (unicast)

…. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)

Source: 00:07:e9:46:2d:55 (00:07:e9:46:2d:55)

Address: 00:07:e9:46:2d:55 (00:07:e9:46:2d:55)

…. …0 …. …. …. …. = IG bit: Individual address (unicast)

…. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)

Type: IP (0×0800)

Internet Protocol, Src: 192.168.100.5 (192.168.100.5), Dst: 192.168.100.3 (192.168.100.3)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0×00 (DSCP 0×00: Default; ECN: 0×00)

0000 00.. = Differentiated Services Codepoint: Default (0×00)

…. ..0. = ECN-Capable Transport (ECT): 0

…. …0 = ECN-CE: 0

Total Length: 40

Identification: 0×0461 (1121)

Flags: 0×00

0… = Reserved bit: Not set

.0.. = Don’t fragment: Not set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 128

Protocol: TCP (0×06)

Header checksum: 0xed15 [correct]

[Good: True]

[Bad : False]

Source: 192.168.100.5 (192.168.100.5)

Destination: 192.168.100.3 (192.168.100.3)

Transmission Control Protocol, Src Port: 0 (0), Dst Port: 2535 (2535), Seq: 1, Ack: 1, Len: 0

Source port: 0 (0)

Destination port: 2535 (2535)

[Stream index: 0]

Sequence number: 1    (relative sequence number)

Acknowledgement number: 1    (relative ack number)

Header length: 20 bytes

Flags: 0×14 (RST, ACK)

0… …. = Congestion Window Reduced (CWR): Not set

.0.. …. = ECN-Echo: Not set

..0. …. = Urgent: Not set

…1 …. = Acknowledgement: Set

…. 0… = Push: Not set

…. .1.. = Reset: Set

[Expert Info (Chat/Sequence): Connection reset (RST)]

[Message: Connection reset (RST)]

[Severity level: Chat]

[Group: Sequence]

…. ..0. = Syn: Not set

…. …0 = Fin: Not set

Window size: 0

Checksum: 0×9078 [validation disabled]

[Good Checksum: False]

[Bad Checksum: False]

OK, if we sift through the output we can find the IP ID information. If we want to check the value over multiple packets however, its going to be time consuming.

Printing only specific fields

One of the features in the latest version of tshark is the ability to print only specific packet fields. This is performed using the “-T fields” switch. You then use the “-e” switch to specific the fields you wish to see, in the specific order you want them to be printed. Here’s an example:

C:\>tshark -n -i 3 -T fields -e ip.src -e ip.dst -e ip.proto -e ip.id src host 192.168.100.5

Capturing on Intel(R) PRO/100 VE Network Connection (Microsoft’s Packet Scheduler)

192.168.100.5   192.168.100.3   0×06    0×0491

192.168.100.5   192.168.100.3   0×06    0×0492

192.168.100.5   192.168.100.3   0×06    0×0495

192.168.100.5   192.168.100.3   0×06    0×0496

192.168.100.5   192.168.100.3   0×06    0×0497

The “-e” switch uses the same pcap syntax used by Wireshark for display filters.  Packetlife has an excellent cheat sheet showing commonly used values. From left to right, I specified Source IP, Destination IP, transport, followed by the IP ID value. Note that with this format, it is now trivial to follow the IP ID increment in the packet stream.

Exec Summary

When performing packet decodes, it is not uncommon to end up with far more information on the screen than you actually need. In fact this can make it difficult to find the values you are trying to focus in on. The addition of tshark’s new display options can make following information over multiple packets far easier than it is with similar tools.

No comments »

Posted in 3-err, Packet Decoding

Tags: