Understanding Tcpdump's -d Option

Have you ever used Tcpdump's -d option? The man page says:

-d     Dump the compiled packet-matching code in a human readable  form
       to standard output and stop.

I've never used that option before, but I just saw a Tcpdump developer use it to confirm a Berkeley packet filter in this thread. The user in the thread is trying to see TCP or UDP packets with a source address of "centernet.jhuccp.org" (162.129.225.192). First he specifies an incorrect BPF filter, which the developer then corrects. This is mildly interesting, but the useful information on the -d option appears in this post.

Tcpdump developer Guy Harris interprets output from the -d option:

> www:~# tcpdump -d src host centernet.jhuccp.org and \( ip proto \\tcp 
> or \\udp \)
> (000) ldh      [12]
> (001) jeq      #0x800           jt 2    jf 8
> (002) ld       [26]
> (003) jeq      #0xa281e1c0      jt 4    jf 8
> (004) ldb      [23]
> (005) jeq      #0x6             jt 7    jf 6
> (006) jeq      #0x11            jt 7    jf 8
> (007) ret      #96
> (008) ret      #0

OK, that code:

 loads the 2-byte big-endian quantity at an offset of 12 from the 
beginning of the packet - which, on an Ethernet packet, is the 
type/length field in the Ethernet header - and compares it with 0x0800 
- which is the type code for IPv4 - and, if it's not equal, jumps to 
instruction 8, which returns 0, meaning "reject this packet" (i.e., it 
rejects all packets other than IPv4 packets);

 loads the 4-byte big-endian quantity at an offset of 26 from the 
beginning of the packet - which, for an IPv4-over-Ethernet packet, is 
the source IP address in the IPv4 header - and compares it with 
0xa281e1c0 - which is 162.129.225.192, or "centernet.jhuccp.org" - and, 
if it's not equal, jumps to instruction 8 (i.e., it rejects all packets 
that don't have a source IP address of 162.129.225.192);

 loads the one-byte quantity at an offset of 23 from the beginning of 
the packet - which, for an IPv4-over-Ethernet packet, is the protocol 
type field in the IPv4 header - and, if it's equal to 6 - i.e., if it's 
a TCP packet - jumps to instruction 7, which returns 96, meaning 
"accept this packet and get its first 96 bytes", and, if it's not 6, 
jumps to instruction 6, which does the same check for 17, i.e. UDP.

I found this explanation very enlightening and I appreciate Guy taking the time to discuss it.

Read More

Fedora Legacy Project Provides Updates for Old Red Hat Linux Versions

Are you still running Red Hat Linux 7.3 or 9.0? What about Fedora Core 1? If you want to keep those systems patched now that Red Hat has suspended support, consider the Fedora Legacy Project. I just read their advisory for Tcpdump, notifying users of updated libpcap and Tcpdump packages. (Note: The URLs in the advisory are funky. Visit http://download.fedoralegacy.org/redhat/9/updates/i386/ to access the RPMs for Red Hat Linux 9.0 directly.) I used their libpcap and Tcpdump RPMs to patch a system and had no problems.

Read More

FreeBSD 5.3 on the SlickNode PC

I previously reported my successful installation of FreeBSD on a Soekris net4801. While the Soekris is a really popular small form factor system, it lacks a fan to keep moving components (like laptop HDDs) cool. It's also not the sort of system you can use to replace a tower PC, since it doesn't have video output, a CD, or mouse and keyboard inputs.

If you need the sort of functionality a true PC provides, but want small form factor, check out Padova Technologies. I just installed FreeBSD 5.3-BETA6 on their SlickNode Mini PC. You can see my dmesg output at the NYCBUG dmesg archive. The box is equipped with two NICs -- one is an Intel NIC (fxp0) and the other is unfortunately a Realtek NIC (re0). When you order a SlickNode you can opt for a quad NIC to be installed, or a Wi-Fi card, or several other options. This is a great appliance box for systems that need more of a PC's functionality.

Read More

Open Source Operating Systems with Fall Release Dates

This fall will see the release of upgrades to several open source operating systems I use. First, FreeBSD 5.3 is currently scheduled to be released on 17 October. Over the weekend a sixth beta was cut and a seventh and final beta will be produced this weekend. The following week a release candidate (RC) will arrive. Although no second RC is planned, I expect to see one. The arrival of FreeBSD 5.3 RELEASE will mark the 5.x tree as STABLE. The current STABLE tree, 4.x, will go into maintenance mode. The 6.0 tree is already marked as CURRENT; that's where cutting edge developments are introduced before being "merged from CURRENT" (mfc) to the STABLE tree. I recommend anyone interested in trying FreeBSD for the first time wait until 5.3 is released in mid-October. FreeBSD 5.2.1, the latest in the 5.x tree, arrived in February 2004.

On Monday RC1 for NetBSD 2.0 was announced. NetBSD 2.0 has been several years in the making. The last version, 1.6.2, was a patch release that arrived in March 2004. The last major version, 1.6, was released in September 2002.

If you like regular releases, you can't beat OpenBSD. OpenBSD 3.6 will begin shipping 1 November 2004. OpenBSD 3.5 started shipping in May 2004.

Finally, I'm not much of a Linux user, but I am looking forward to the long-awaited next release of Debian, called sarge. The last discussion of a timetable suggested a September release, but it looks like October or even later is more realistic. The last stable Debian version, woody, arrived in July 2002.

At first glance it seems that upgrades to some of these operating systems, especially NetBSD and Debian, have been few and far between. Then I visited the Microsoft server timeline and desktop timelines. These reminded me that the last desktop release, Windows XP, arrived in October 2001. We got a serious upgrade in XP SP2, but that took 3 years to materialize. On the server side, we have to wait until 2006 for Longhorn. The open source OSs are interesting because they are both client and server operating systems, and still beat the three year Microsoft development cycle.

Read More

Further Musings on Digital Crime

Adam Shostack posted a response to my Thoughts on Digital Crime blog entry. Essentially he questions the "bandwidth" of the law enforcement organizations I listed, i.e., their ability to handle cases. The FBI CART Web page says "in 1999 the Unit conducted 2,400 examinations of computer evidence." At HTCIA I heard Mr. Kosiba state that thus far, in 2004, CART has worked 2,500 cases, which may involve more than one examination per case. The 50+ CART examiners and support personnel and 250 field examiners have processed 665 TB of data so far this year! The CART alone spends $32,000 per examiner on equipment when they are hired, and another $12,500 per year to upgrade each examiner's equipment.

This is a sign that the DoJ is pouring money into combatting cyber crime. Of course local and state police do not have the same resources, but especially at the state level we are seeing improvements.

If more resources are being plowed into cybercrime, what is the likelihood that law enforcement will decline from prosecuting juveniles? I believe being a teenager isn't a viable way to escapae prosecution either. During HTCIA I attended a talk by Rick Aldrich, former AFOSI legal advisor. He explained how it has been traditionally difficult to prosecute juvenlile offenders in federal court. The state of California, however, has a special unit set up to investigate and prosecute juvenile cybercriminals. Other states who identify underage intruders now look for ways to get California to prosecute these offenders, due to California's system.

The last way to avoid a trip to the pokey is to hack from overseas locations. A visit to Cybercrime.gov shows plenty of active prosecutions for "hacking," including some foreigners. It's true that the people least likely to be prosecuted are those who physically reside in a country whose law enforcement agencies dislike working with the US government. However, even a country like Romania is working to catch intruders. I still believe all of this does not bode well for low- to mid-level cyber crininals -- you will be caught. Justice may be slow but it does not appear to give up. I have one caveat -- there must be evidence to support a prosecution. If a victim doesn't collect the sorts of high-fidelity data which can show damage and link it to the intruder's action, it's difficult to attract law enforcement's interest.

Read More

"Certified" Digital Forensics Labs

One helpful speaker at the HTCIA conference was Timothy Kosiba of the FBI Computer Analysis and Response Team (CART). (Some people say "CART Team." These are probably the same people who say "NIC Card," forgotting "NIC" means "Network Interface Card.") Mr. Kosiba explained the rising importance of forensic lab accreditation by the American Society of Crime Laboratory Directors / Laboratory Accreditation Board (ASCLD/LAB). Apparently the CART parent organization, the FBI Lab, only attained ASCLD/LAB accreditation four years ago, in the wake of the OJ Simpson trial.

What might ASCLD/LAB accrediation entail? A few excerpts from the Proposed Revisions to 2001 Accreditation Manual provides a few hints, as the ASCLD/LAB documents are not available for free:

"2.11 Digital Evidence

Principle

Examiners must have mastery of the theories, procedures, and techniques necessary to produce reliable results and conclusions.

Standards and Criteria

Digital evidence examiners should have a baccalaureate degree with science courses.

Examiners must have a good understanding of the principles, uses, and limitations of the hardware, software, and the methods and procedures as applied to the tasks performed.

Examiners must have education and training/experience commensurate with the examinations and testimony provided. Independent case examinations must not be undertaken until extensive instruction from a qualified examiner has been completed.

Examiners must have successfully completed a competency test.

A proficiency test must be successfully completed by each examinder at least annually."

There are a few other items in the .pdf, so I recommend reading it or requesting the original documents from ASCLD/LAB itself.

Mr. Kosiba also mentioned the Scientific Working Group on Digital Evidence (SWGDE) and the European Network of Forensic Science Institutes (ENFSI) as sources of standards.

Read More

Thoughts on Digital Crime

Last week I spoke at and attended the High Technology Crime Investigation Association International Conference and Expo 2004. The keynote speaker was US Attorney General John Ashcroft. Although I spent time furiously copying notes on his speech, the text is online. Not printed in that text was the AG's repeated theme: the US Department of Justice and Federal Bureau of Investigation are committed to "protecting lives and liberty." I thought this was a curious stance given the recent efforts to scale back the Patriot Act. The AG mentioned that "protect[ing] the United States against cyber-based attacks and high-technology crimes" is the number 3 FBI priority.

I believe that if you are a low- to mid-skilled intruder physically located in the United States, you will eventually be caught. The days when hardly anyone cared about prosecuting digital crime are ending. The FBI has 13 Computer Hacking and Intellectual Property (CHIPS) units with plans to open more. The Computer Crime and Intellectual Property Section (CCIPS) are available to US Attorneys across the country. The Secret Service operates 15 Electronic Crimes Task Forces. There are 5 Regional Computer Forensic Laboratories operating now with 8 planned to open in the coming years. The Internet Fraud Complaint Center (IFCC) is taking reports from victims of cyber crime and the National White Collar Crime Center supports law enforcement efforts. All of this adds up to a lot of federal, state, and local police working to bust bad guys.

Read More