Packet Sniffing

Published: 2007-08-31
Last Updated: 2007-08-31 13:19:00 UTC
by Mike Poor (Version: 1)
0 comment(s)

Packet Sniffing

Many of our readers routinely ask us what ways they can capture packets to send data to the Storm Center.  A couple of different things to consider:

What do you want to capture? 
    Specific ports or protocols? 
    Snapshot of traffic?

What line speed are you capturing at?

What device are you capturing on?

Two common tools to do the packet capturing with are: tcpdump, wireshark/tshark.  In this diary we will examine each of these briefly, along with their pros and cons.

tcpdump

The venerable tcpdump is a staple to many of us that analyze traffic for a living.  It is simple, powerful, and above all ported to many platforms.  Tcpdump uses the bpf (Berkeley Packet Filter) format for filtering packets out of your capture. 

An example tcpdump command:

tcpdump -nn -i eth0 -s 1514 -w file.cap 'tcp and port 5050'

This command will capture full ethernet packets (1500 MTU + 14 bytes for the frame header), binding to interface eth0 (-i switch), and write to a file called "file.cap".  The end of the command line is the bpf, filtering packets matching tcp port 5050 (both source and destination).  The -nn disables name and port resolution.


wireshark / tshark

Wireshark and tshark are the new names for the oldschool tools, ethereal and tetheral.  Wireshark is the graphic tool, and tshark is a commandline tool.

Given that most probably have experience with wireshark or ethereal, lets look more closely at tshark.

The biggest advantage for using tshark is that it includes a ring buffer for packet capturing.  If you find yourself dropping packets with tcpdump, try using tshark with the ring buffer.

The following command runs tshark binding to interface en0 (-i) , disabling name resolution (-n), and using a ring buffer rotating files after every 10000K (-b filesize:10000) and writing to a basename of "foo" (-w foo).

tshark -i en0 -b filesize:10000 -w foo -n

You end up with files named as follows:
foo_00001_20070831000015
foo_00002_20070831000039

Next time we will look at Marty (of Snort fame) Roesch's new tool: Daemonlogger.
 
Mike Poor
Intelguardians

Keywords:
0 comment(s)

Blocklisting Bad Apples (no not the i kind)

Published: 2007-08-31
Last Updated: 2007-08-31 13:18:24 UTC
by Handlers (Version: 2)
0 comment(s)

We regularly have readers inquire about recommendations for filtering bad IPs, networks, or in the worst case regions or entire  countries. When used properly, blocklisting/watchlisting can provide enormous benefits, however using stale or inaccurate lists or employing heavy-handed tactics like filtering out continents can stifle communications and affect commerce in hard to foresee ways. Except for very specific cases like a parts distributor that only services customers in a region and therefore may not need to allow inbound access from across the globe, blocklists need to be approached with caution.

A good example of a blocklist gone bad is the still unresolved issues with APEWS and the senseless fallout their practices have caused:

http://isc.sans.org/diary.html?storyid=3189

There are a number of high-quality feeds out there providing granular (and fresh) blocking or alerting capability and there are times where such filters may prove to be highly appropriate and useful. We see IP addresses and entire netblocks never leaving the Top 10 offender lists for things like command and control, call-homes, and malware download sites.

We'd like to take this opportunity to point folks at a drop list they might not have seen before. The goal here is to highlight a few of these bad apple netblocks that many sites not already leveraging this list might find useful to use in systems which provide alerting or filtering capabilities as appropriate (your mileage may vary and the use of any "feed" should be evaluated first)

http://www.spamhaus.org/drop/drop.lasso

Now for a few gems from the list that some will recognize right away and others will see the light after a brief google or diary search:

Russian Business Network:

81.95.144.0/20  #SBL43489
(81.95.144.0 - 81.95.159.255)

Nevacon:

194.146.204.0/22  #SBL51152
(194.146.204.0 - 194.146.207.255)

Intercage:

85.255.112.0/20  #SBL36702
(85.255.112.0 - 85.255.127.255)

 

A good place to start is to search your proxy logs for IPs in these ranges for example and pay particular attention to query strings. Anything like a "port=12345" might be worth looking into port 12345 on that client machine for example.

[Note: There are many other dynamic blocklists out there from volunteers and companies which are excellent. The goal here was to highlight the list of fairly static bad apple netblocks and the possible benefits of not allowing traffic to or from them.]

The Handlers

 

 

 

Keywords:
0 comment(s)

Comments


Diary Archives