Monitoring Network Traffic
{LANG_NAVORIGIN} Security Tools
LearnSecurityOnline
06/08/2005
Importance of network monitoring
Reading network traffic is essential for system administrators, network engineers, and security
analysts. At some point there will be a need to read the network traffic directly instead of
monitoring application level details. Examples of situations that might require monitoring
network traffic are, auditing network security, debugging network configurations, and analyzing
usage patterns. For this task we use network monitoring software, or network sniffers, that
sniff the traffic your computer is able to see on the network. What exactly your computer can
see really depends on how the network is laid out, but the easiest way to figure out what it can
see is just start sniffing.
The most common tools to do the job are readily available. Many are even free to download and
use. Two of the most popular tools for monitoring network traffic are tcpdump and ethereal. Both
are freely available for Windows, Linux, and a variety of other platforms. There are also a
number of specialized tools that perform different functions and suit different tasks. Some
provide very basic and raw functionality of reading and parsing every layer out of the stream,
others decode specific information they deem relevant out of the protocol, and others provide
graphical stream tracing for viewing the flow of traffic.
Necessary prerequisites
In order to obtain useful information from sniffing packets, it is necessary to realize how the
data is laid out. Networks operate on many layers, usually described as the 7 layers of the OSI
model. Each protocol runs on top of the ones below it, and encapsulates the data of the protocol
above it. On a common desktop machine at a corporation the machine with have a network card that
speaks Ethernet to the LAN. The Operating System will have an IP stack, and on top of that TCP
will be providing connections to programs. Applications will have their own internal way of
communicating information to the server they use.
As low as it goes
The lowest layer that people will sniff is the layer Ethernet operates on. You can only sniff
what your computer sees. The default mode of operation for Ethernet cards is to only forward
data to the operating system that is addressed to it. This prevents the host machine from
wasting CPU cycles on traffic not destined for that machine. It also means that the default mode
of operations is for you not to see the traffic of other machines. Fortunately for the person
desiring to sniff traffic, you can turn the Ethernet card into promiscuous mode, where it
forwards all traffic to the operating system. This lets you see all the traffic when the network
is in a broadcast layout, where every machine gets the traffic destined for other machines on
the local network. An Ethernet network connected using a HUB is a broadcast network, and allows
any user to sniff the traffic of other users.
Turning an Ethernet card into promiscuous mode is something that most sniffing software does
automatically. Fortunately for those administrators desiring to keep traffic private, a device
called a switch was created. The basic idea of a switch is that it remembers which port has
which Ethernet addresses on it, and when a packet comes in, it forwards it only to the port that
has that Ethernet address on it. This also has the added benefit of improving network speed if
the switch has a high bandwidth interconnect, something that cheap switches often do not. With a
good switch, you can have each pair of ports communicating at the full network speed with the
other.
You get what you pay for
For the user wishing to sniff the network that has a cheap switch, it is often easy to do so.
Switches operate by forwarding only traffic destined to a computer to a specific port. They do
this by remembering what MAC addresses are located on what ports. Switches that have a limited
MAC table turn into HUBs when their table is overflowed. Others don't raise any kind of alarms
when a MAC address appears on two different ports. Good switches will deal with these cases by
not forwarding to ports that a duplicate MAC address has appeared on, and by not turning into a
HUB when the MAC table is full. The most advanced switches can be configured to only let a
certain set of MAC addresses be used on a port.
The Ethernet information is usually not interesting, but it can be useful for tracking down
exactly which machine is broadcasting information on the network, assuming it is writing the
frames with its actual MAC address. Many sniffing programs automatically filter out the Ethernet
layer out of the data it displays.
Internet Protocol
The protocol most often run on top of Ethernet is IP, or Internet Protocol. This is the protocol
that lets data be sent packets through a long and complicated route to other computers over the
Internet. The protocol is able to handle addressing, routing to addresses, identification of
encapsulated protocols, checksum of data, fragmentation, and stop routing loops. Most often when
someone is looking at the IP layer, they are looking for the IP addresses, the four byte numbers
that corresponds to which computer the packet is coming from, and which one it is going
to.
You should know the layout of the IP packet. It is presented in the list below.
- 1st byte: 4 bits version 4 bytes header length (in 4 byte increments).
- 2nd byte: Type of Service, flags for how this packet is to be treated.
- 3rd and 4th bytes: Total length of packet
- 5th byte: time to live, decremented by one by each router along the way, prevents
loops.
- 6th byte: protocol number of protocol used in encapsulated data
- 7th and 8th byte: checksum of header.
- 9th,10th,11th,12th bytes: source internet protocol address
- 13th,14th,15th,16th bytes: destination internet protocol address
Interacting with lower layers
One important interaction between IP and Ethernet is ARP. Address Resolution Protocol is what
the system uses to discover which Ethernet address to send an IP packet to. This is combined
with the use of the net-mask, the mask of 1's and 0's that determine what addresses are local.
For a system with an IP address of
10.0.0.2, a net-mask of
255.255.255.0, and a default router of
10.0.0.1 if it wants to
contact a machine
10.0.0.3, the machine would go through these steps. First it
would see it was local and determine that it needs the Ethernet address of the machine. It would
then query the address of it with a ARP who-has packet. If someone knows the MAC address of the
machine with IP address listed in the packet, then they broadcast that information. Usually just
the machine that you are trying to reach does this. The machine
10.0.0.2 then
assembles the Ethernet frame using the information from ARP to send out the packet. The other
case is where the address is not local. In this case the address of the default router is used
as the ARP query, and the same process is used.
11:43:09.720356 arp who-has 10.0.0.3 tell 10.0.0.2
11:43:09.720741 arp reply 10.0.0.3 is-at 8:0:2b:93:1b:8e
11:43:09.720778 10.0.0.2 > 10.0.0.3: icmp: echo request (DF)
11:43:09.721134 10.0.0.3 > 10.0.0.2: icmp: echo reply (DF)
Domain Name System
Another important protocol for IP is DNS. The problem with IP is that the addresses are hard for
humans to remember. To solve this, a system of resolving names to addresses was created called
Domain Name System, or DNS. DNS typically runs on port 53 and runs in a hierarchy of servers.
For more information on DNS, read RFC 1035. Most of the time you will not really need to read
too much into DNS traffic, but it may be useful. Some more modern developments have included the
ability to tunnel traffic through DNS, so it may eventually become something to watch.
For more information on IP you can refer to RFC 791 which describes the IP protocol in full. ARP
is described in RFC 826. The next document describes the basics of other protocols that run on
top of IP.
Protocols that use IP
The three most common protocols run directly on top of IP are Transmission Control Protocol
(TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP). TCP is the
reliable connection oriented protocol, UDP is connection-less and not reliable, but much faster
than TCP, and ICMP is used to send informational messages to other hosts. The most important of
the three is probably TCP, which most applications use to communicate data to other computers.
The other two are useful to know somewhat in many circumstances.
TCP, the connection oriented protocol has mechanisms to setup a connection, communicate during
the connection, and tear down the connection. The typical flow for a connection is the
following.
Client sends SYN packet to Server
Server sends SYN/ACK to client if port is open
Client sends ACK to SYN/ACK packet to acknowledge it got the packet
...
Side sends data
Other ACKs the packet
...
One side sends FIN
Other side sends ACKS the FIN
First side sends ACK
The important parts of TCP are the Sequence Number, Acknowledgment Number, the Flags, the source
port, and the destination port. Sequence and acknowledgment numbers are the numbers that
determine the order of the packets if they arrive out of order, if they belong in the stream,
and if the packet has been received. Flags determine what kind of packet it is, opening, data,
closing, or other information. The ports are what the applications use to differentiate their
services to other applications connecting to the machine. Typical port numbers are port 80 for
http, 23 for telnet, 25 for smtp, 22 for ssh, and 110 for pop.
UDP
UDP is a simpler protocol than TCP. It is used when transmission does not need to be stateful,
must be one way, or if the extra overhead of TCP is too much. At its simplest form, it has just
a source port, destination port, a length, a checksum, and the data. This leads to only 8 bytes
of overhead. Some common things that use UDP are DNS queries, streaming video, and real-time
multi-player games.
ICMP
ICMP is an even simpler protocol, in that it only sends a message specifying the type, code, and
a checksum. The thing that people most often use that involves ICMP is ping. Ping is a utility
that sends out a ICMP echo request, and times the difference between when it sent that out, and
when it gets a reply to the echo. Here is a sample sample packet capture of pinging
www.yahoo.com. The requests to port 53 are for resolving www.yahoo.com, and getting the PTR
records for its IP address.
02:24:54.131517 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 14275+ A? www.yahoo.com. (31)
(DF) (ttl 64, id 940, len 59)
02:24:54.132346 128.2.4.142.53 > 128.2.4.166.1035: 14275 9/0/0 www.yahoo.com. CNAME[|domain]
(DF) (ttl 64, id 0, len 221)
02:24:54.133544 128.2.4.166 > 216.109.117.205: icmp: echo request (DF) (ttl 64, id 0, len 84)
02:24:54.139914 216.109.117.205 > 128.2.4.166: icmp: echo reply (DF) (ttl 51, id 63834, len 84)
02:24:54.140604 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 14276+ PTR?
205.117.109.216.in-addr.arpa. (46) (DF) (ttl 64, id 941, len 74)
02:24:54.141253 128.2.4.142.53 > 128.2.4.166.1035: 14276 1/0/0 205.117.109.216.in-addr.arpa.
(81) (DF) (ttl 64, id 0, len 109)
02:24:55.145095 128.2.4.166 > 216.109.117.205: icmp: echo request (DF) (ttl 64, id 0, len 84)
02:24:55.151484 216.109.117.205 > 128.2.4.166: icmp: echo reply (DF) (ttl 51, id 64654, len 84)
02:24:55.152078 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 14277+ PTR?
205.117.109.216.in-addr.arpa. (46) (DF) (ttl 64, id 1042, len 74)
02:24:55.152776 128.2.4.142.53 > 128.2.4.166.1035: 14277 1/0/0 205.117.109.216.in-addr.arpa.
(81) (DF) (ttl 64, id 0, len 109)
02:24:56.155171 128.2.4.166 > 216.109.117.205: icmp: echo request (DF) (ttl 64, id 0, len 84)
02:24:56.161643 216.109.117.205 > 128.2.4.166: icmp: echo reply (DF) (ttl 51, id 65403, len 84)
02:24:56.162358 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 14278+ PTR?
205.117.109.216.in-addr.arpa. (46) (DF) (ttl 64, id 1143, len 74)
02:24:56.163058 128.2.4.142.53 > 128.2.4.166.1035: 14278 1/0/0 205.117.109.216.in-addr.arpa.
(81) (DF) (ttl 64, id 0, len 109)
Another utility that makes use of ICMP is trace-route. The request is in the form of an IP
packet with a Time To Live (TTL) of increasing values. Each hop along the route takes one off
from the TTL and if it is zero, then sends an ICMP message back to the machine that sent the
packet. By starting out with a low TTL and increasing it, a route is mapped out of the path to a
remote host. Here is a sample capture of a traceroute to yahoo.com.
02:03:38.317425 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1865+ A? www.yahoo.com. (31)
(DF) (ttl 64, id 4431, len 59)
02:03:38.337540 128.2.4.142.53 > 128.2.4.166.1035: 1865 9/0/0 www.yahoo.com. CNAME[|domain]
(DF) (ttl 64, id 0, len 221)
02:03:38.339550 128.2.4.166.49909 > 216.109.118.73.33435: [udp sum ok] udp 10 [ttl 1] (id 49910,
len 38)
02:03:38.339988 128.2.4.129 > 128.2.4.166: icmp: time exceeded in-transit [tos 0xc0] (ttl 255,
id 57478, len 56)
02:03:38.340991 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1866+ PTR?
129.4.2.128.in-addr.arpa. (42) (DF) (ttl 64, id 4433, len 70)
02:03:38.341642 128.2.4.142.53 > 128.2.4.166.1035: 1866 1/0/0 129.4.2.128.in-addr.arpa.
PTR[|domain] (DF) (ttl 64, id 0, len 104)
02:03:38.342067 128.2.4.166.49909 > 216.109.118.73.33436: [udp sum ok] udp 10 [ttl 1] (id 49911,
len 38)
02:03:38.342542 128.2.4.129 > 128.2.4.166: icmp: time exceeded in-transit [tos 0xc0] (ttl 255,
id 57479, len 56)
02:03:38.342803 128.2.4.166.49909 > 216.109.118.73.33437: [udp sum ok] udp 10 [ttl 1] (id 49912,
len 38)
02:03:38.343190 128.2.4.129 > 128.2.4.166: icmp: time exceeded in-transit [tos 0xc0] (ttl 255,
id 57480, len 56)
02:03:38.343468 128.2.4.166.49909 > 216.109.118.73.33438: [udp sum ok] udp 10 (ttl 2, id 49913,
len 38)
02:03:38.344007 128.2.0.12 > 128.2.4.166: icmp: time exceeded in-transit [tos 0xc0] (ttl 254,
id 43396, len 56)
02:03:38.344562 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1867+ PTR?
12.0.2.128.in-addr.arpa. (41) (DF) (ttl 64, id 4433, len 69)
02:03:38.345254 128.2.4.142.53 > 128.2.4.166.1035: 1867 1/0/0 12.0.2.128.in-addr.arpa.
PTR[|domain] (DF) (ttl 64, id 0, len 106)
02:03:38.345754 128.2.4.166.49909 > 216.109.118.73.33439: [udp sum ok] udp 10 (ttl 2, id 49914,
len 38)
02:03:38.346154 128.2.0.12 > 128.2.4.166: icmp: time exceeded in-transit [tos 0xc0] (ttl 254,
id 43397, len 56)
02:03:38.346408 128.2.4.166.49909 > 216.109.118.73.33440: [udp sum ok] udp 10 (ttl 2, id 49915,
len 38)
02:03:38.346789 128.2.0.12 > 128.2.4.166: icmp: time exceeded in-transit [tos 0xc0] (ttl 254,
id 43398, len 56)
02:03:38.347051 128.2.4.166.49909 > 216.109.118.73.33441: [udp sum ok] udp 10 (ttl 3, id 49916,
len 38)
02:03:38.347806 128.2.33.225 > 128.2.4.166: icmp: time exceeded in-transit [tos 0xc0] (ttl 253,
id 27232, len 56)
02:03:38.348352 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1868+ PTR?
225.33.2.128.in-addr.arpa. (43) (DF) (ttl 64, id 4434, len 71)
02:03:38.349000 128.2.4.142.53 > 128.2.4.166.1035: 1868 1/0/0 225.33.2.128.in-addr.arpa. (79)
(DF) (ttl 64, id 0, len 107)
02:03:38.349358 128.2.4.166.49909 > 216.109.118.73.33442: [udp sum ok] udp 10 (ttl 3, id 49917,
len 38)
02:03:38.349912 128.2.33.225 > 128.2.4.166: icmp: time exceeded in-transit (ttl 253, id 27233,
len 56)
02:03:38.350167 128.2.4.166.49909 > 216.109.118.73.33443: [udp sum ok] udp 10 (ttl 3, id 49918,
len 38)
02:03:38.350829 128.2.33.225 > 128.2.4.166: icmp: time exceeded in-transit [tos 0xc0] (ttl 253,
id 27234, len 56)
02:03:38.351092 128.2.4.166.49909 > 216.109.118.73.33444: [udp sum ok] udp 10 (ttl 4, id 49919,
len 38)
02:03:38.351585 192.88.115.181 > 128.2.4.166: icmp: time exceeded in-transit (ttl 251, id 0, len
56)
02:03:38.352169 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1869+ PTR?
181.115.88.192.in-addr.arpa. (45) (DF) (ttl 64, id 4434, len 73)
02:03:38.353052 128.2.4.142.53 > 128.2.4.166.1035: 1869 1/0/0 181.115.88.192.in-addr.arpa. (85)
(DF) (ttl 64, id 0, len 113)
02:03:38.353411 128.2.4.166.49909 > 216.109.118.73.33445: [udp sum ok] udp 10 (ttl 4, id 49920,
len 38)
02:03:38.353763 192.88.115.181 > 128.2.4.166: icmp: time exceeded in-transit (ttl 251, id 0, len
56)
02:03:38.354024 128.2.4.166.49909 > 216.109.118.73.33446: [udp sum ok] udp 10 (ttl 4, id 49921,
len 38)
02:03:38.354384 192.88.115.181 > 128.2.4.166: icmp: time exceeded in-transit (ttl 251, id 0, len
56)
02:03:38.354647 128.2.4.166.49909 > 216.109.118.73.33447: [udp sum ok] udp 10 (ttl 5, id 49922,
len 38)
02:03:38.355392 192.88.115.5 > 128.2.4.166: icmp: time exceeded in-transit (ttl 250, id 0, len
56)
02:03:38.355947 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1870+ PTR?
5.115.88.192.in-addr.arpa. (43) (DF) (ttl 64, id 4435, len 71)
02:03:38.356581 128.2.4.142.53 > 128.2.4.166.1035: 1870 1/0/0 5.115.88.192.in-addr.arpa. (82)
(DF) (ttl 64, id 0, len 110)
02:03:38.356967 128.2.4.166.49909 > 216.109.118.73.33448: [udp sum ok] udp 10 (ttl 5, id 49923,
len 38)
02:03:38.357563 192.88.115.5 > 128.2.4.166: icmp: time exceeded in-transit (ttl 250, id 0, len
56)
02:03:38.357822 128.2.4.166.49909 > 216.109.118.73.33449: [udp sum ok] udp 10 (ttl 5, id 49924,
len 38)
02:03:38.358215 192.88.115.5 > 128.2.4.166: icmp: time exceeded in-transit (ttl 250, id 0, len
56)
02:03:38.358476 128.2.4.166.49909 > 216.109.118.73.33450: [udp sum ok] udp 10 (ttl 6, id 49925,
len 38)
02:03:38.359441 199.239.216.13 > 128.2.4.166: icmp: time exceeded in-transit (ttl 249, id 0, len
56)
02:03:38.360039 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1871+ PTR?
13.216.239.199.in-addr.arpa. (45) (DF) (ttl 64, id 4435, len 73)
02:03:38.360722 128.2.4.142.53 > 128.2.4.166.1035: 1871 1/0/0 13.216.239.199.in-addr.arpa. (98)
(DF) (ttl 64, id 0, len 126)
02:03:38.361092 128.2.4.166.49909 > 216.109.118.73.33451: [udp sum ok] udp 10 (ttl 6, id 49926,
len 38)
02:03:38.361810 199.239.216.13 > 128.2.4.166: icmp: time exceeded in-transit (ttl 249, id 0, len
56)
02:03:38.362068 128.2.4.166.49909 > 216.109.118.73.33452: [udp sum ok] udp 10 (ttl 6, id 49927,
len 38)
02:03:38.362717 199.239.216.13 > 128.2.4.166: icmp: time exceeded in-transit (ttl 249, id 0, len
56)
02:03:38.362985 128.2.4.166.49909 > 216.109.118.73.33453: [udp sum ok] udp 10 (ttl 7, id 49928,
len 38)
02:03:38.365631 128.2.4.178 > 128.2.4.166: icmp: echo request (DF) (ttl 64, id 0, len 84)
02:03:38.365719 128.2.4.166 > 128.2.4.178: icmp: echo reply (ttl 64, id 32535, len 84)
02:03:38.367604 129.250.24.134 > 128.2.4.166: icmp: time exceeded in-transit (ttl 248, id 0, len
56)
02:03:38.368175 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1872+ PTR?
134.24.250.129.in-addr.arpa. (45) (DF) (ttl 64, id 4436, len 73)
02:03:38.368866 128.2.4.142.53 > 128.2.4.166.1035: 1872 1/0/0 134.24.250.129.in-addr.arpa. (98)
(DF) (ttl 64, id 0, len 126)
02:03:38.369235 128.2.4.166.49909 > 216.109.118.73.33454: [udp sum ok] udp 10 (ttl 7, id 49929,
len 38)
02:03:38.370110 129.250.24.134 > 128.2.4.166: icmp: time exceeded in-transit (ttl 248, id 0, len
56)
02:03:38.370369 128.2.4.166.49909 > 216.109.118.73.33455: [udp sum ok] udp 10 (ttl 7, id 49930,
len 38)
02:03:38.370991 129.250.24.134 > 128.2.4.166: icmp: time exceeded in-transit (ttl 248, id 0, len
56)
02:03:38.371260 128.2.4.166.49909 > 216.109.118.73.33456: [udp sum ok] udp 10 (ttl 8, id 49931,
len 38)
02:03:38.372343 128.2.4.178 > 128.2.4.167: icmp: echo request (DF) (ttl 64, id 0, len 84)
02:03:38.372418 128.2.4.167 > 128.2.4.178: icmp: echo reply (ttl 64, id 52784, len 84)
02:03:38.377513 129.250.5.92 > 128.2.4.166: icmp: time exceeded in-transit (DF) (ttl 248, id
1785, len 168)
02:03:38.378069 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1873+ PTR?
92.5.250.129.in-addr.arpa. (43) (DF) (ttl 64, id 4437, len 71)
02:03:38.378780 128.2.4.142.53 > 128.2.4.166.1035: 1873 1/0/0 92.5.250.129.in-addr.arpa. (95)
(DF) (ttl 64, id 0, len 123)
02:03:38.379152 128.2.4.166.49909 > 216.109.118.73.33457: [udp sum ok] udp 10 (ttl 8, id 49932,
len 38)
02:03:38.385269 129.250.5.92 > 128.2.4.166: icmp: time exceeded in-transit (DF) (ttl 248, id
1788, len 168)
02:03:38.385611 128.2.4.166.49909 > 216.109.118.73.33458: [udp sum ok] udp 10 (ttl 8, id 49933,
len 38)
02:03:38.391488 129.250.5.92 > 128.2.4.166: icmp: time exceeded in-transit (DF) (ttl 248, id
1791, len 168)
02:03:38.391770 128.2.4.166.49909 > 216.109.118.73.33459: [udp sum ok] udp 10 (ttl 9, id 49934,
len 38)
02:03:38.397554 129.250.2.35 > 128.2.4.166: icmp: time exceeded in-transit (ttl 246, id 0, len
56)
02:03:38.398106 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1874+ PTR?
35.2.250.129.in-addr.arpa. (43) (DF) (ttl 64, id 4439, len 71)
02:03:38.398794 128.2.4.142.53 > 128.2.4.166.1035: 1874 1/0/0 35.2.250.129.in-addr.arpa. (95)
(DF) (ttl 64, id 0, len 123)
02:03:38.399443 128.2.4.166.49909 > 216.109.118.73.33460: [udp sum ok] udp 10 (ttl 9, id 49935,
len 38)
02:03:38.405449 129.250.2.35 > 128.2.4.166: icmp: time exceeded in-transit (ttl 246, id 0, len
56)
02:03:38.405746 128.2.4.166.49909 > 216.109.118.73.33461: [udp sum ok] udp 10 (ttl 9, id 49936,
len 38)
02:03:38.406768 128.2.4.178 > 128.2.4.172: icmp: echo request (DF) (ttl 64, id 0, len 84)
02:03:38.406853 128.2.4.172 > 128.2.4.178: icmp: echo reply (ttl 64, id 34752, len 84)
02:03:38.411525 129.250.2.35 > 128.2.4.166: icmp: time exceeded in-transit (ttl 246, id 0, len
56)
02:03:38.411775 128.2.4.166.49909 > 216.109.118.73.33462: [udp sum ok] udp 10 (ttl 10, id 49937,
len 38)
02:03:38.417739 208.51.6.33 > 128.2.4.166: icmp: time exceeded in-transit (ttl 245, id 0, len
56)
02:03:38.418344 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1875+ PTR?
33.6.51.208.in-addr.arpa. (42) (DF) (ttl 64, id 4441, len 70)
02:03:38.433331 128.2.4.142.53 > 128.2.4.166.1035: [udp sum ok] 1875 NXDomain* 0/0/0 (42) (DF)
(ttl 64, id 0, len 70)
02:03:38.433694 128.2.4.166.49909 > 216.109.118.73.33463: [udp sum ok] udp 10 (ttl 10, id 49938,
len 38)
02:03:38.439516 208.51.6.33 > 128.2.4.166: icmp: time exceeded in-transit (ttl 245, id 0, len
56)
02:03:38.439775 128.2.4.166.49909 > 216.109.118.73.33464: [udp sum ok] udp 10 (ttl 10, id 49939,
len 38)
02:03:38.440846 128.2.4.178 > 128.2.4.177: icmp: echo request (DF) (ttl 64, id 0, len 84)
02:03:38.440927 128.2.4.177 > 128.2.4.178: icmp: echo reply (ttl 64, id 16527, len 84)
02:03:38.445567 208.51.6.33 > 128.2.4.166: icmp: time exceeded in-transit (ttl 245, id 0, len
56)
02:03:38.445845 128.2.4.166.49909 > 216.109.118.73.33465: [udp sum ok] udp 10 (ttl 11, id 49940,
len 38)
02:03:38.451771 208.50.13.210 > 128.2.4.166: icmp: time exceeded in-transit (ttl 245, id 44797,
len 56)
02:03:38.452328 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1876+ PTR?
210.13.50.208.in-addr.arpa. (44) (DF) (ttl 64, id 4444, len 72)
02:03:38.470044 128.2.4.142.53 > 128.2.4.166.1035: [udp sum ok] 1876 NXDomain* 0/0/0 (44) (DF)
(ttl 64, id 0, len 72)
02:03:38.470406 128.2.4.166.49909 > 216.109.118.73.33466: [udp sum ok] udp 10 (ttl 11, id 49941,
len 38)
02:03:38.476360 208.50.13.210 > 128.2.4.166: icmp: time exceeded in-transit (ttl 245, id 44798,
len 56)
02:03:38.476631 128.2.4.166.49909 > 216.109.118.73.33467: [udp sum ok] udp 10 (ttl 11, id 49942,
len 38)
02:03:38.482479 208.50.13.210 > 128.2.4.166: icmp: time exceeded in-transit (ttl 245, id 44799,
len 56)
02:03:38.482751 128.2.4.166.49909 > 216.109.118.73.33468: [udp sum ok] udp 10 (ttl 12, id 49943,
len 38)
02:03:38.488835 216.115.96.161 > 128.2.4.166: icmp: time exceeded in-transit (ttl 243, id 0, len
56)
02:03:38.489374 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1877+ PTR?
161.96.115.216.in-addr.arpa. (45) (DF) (ttl 64, id 4448, len 73)
02:03:38.490025 128.2.4.142.53 > 128.2.4.166.1035: 1877 1/0/0 161.96.115.216.in-addr.arpa. (85)
(DF) (ttl 64, id 0, len 113)
02:03:38.490402 128.2.4.166.49909 > 216.109.118.73.33469: [udp sum ok] udp 10 (ttl 12, id 49944,
len 38)
02:03:38.496662 216.115.96.161 > 128.2.4.166: icmp: time exceeded in-transit (ttl 243, id 0, len
56)
02:03:38.496935 128.2.4.166.49909 > 216.109.118.73.33470: [udp sum ok] udp 10 (ttl 12, id 49945,
len 38)
02:03:38.503033 216.115.96.161 > 128.2.4.166: icmp: time exceeded in-transit (ttl 243, id 0, len
56)
02:03:38.503307 128.2.4.166.49909 > 216.109.118.73.33471: [udp sum ok] udp 10 (ttl 13, id 49946,
len 38)
02:03:38.510636 216.109.120.198 > 128.2.4.166: icmp: time exceeded in-transit (ttl 243, id
44967, len 56)
02:03:38.511202 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1878+ PTR?
198.120.109.216.in-addr.arpa. (46) (DF) (ttl 64, id 4450, len 74)
02:03:38.522028 128.2.4.142.53 > 128.2.4.166.1035: 1878 1/0/0 198.120.109.216.in-addr.arpa.
(93) (DF) (ttl 64, id 0, len 121)
02:03:38.522417 128.2.4.166.49909 > 216.109.118.73.33472: [udp sum ok] udp 10 (ttl 13, id 49947,
len 38)
02:03:38.528920 216.109.120.142 > 128.2.4.166: icmp: time exceeded in-transit (ttl 243, id
61675, len 56)
02:03:38.529722 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1879+ PTR?
142.120.109.216.in-addr.arpa. (46) (DF) (ttl 64, id 4452, len 74)
02:03:38.612737 128.2.4.142.53 > 128.2.4.166.1035: 1879 1/0/0 142.120.109.216.in-addr.arpa.
(85) (DF) (ttl 64, id 0, len 113)
02:03:38.613127 128.2.4.166.49909 > 216.109.118.73.33473: [udp sum ok] udp 10 (ttl 13, id 49948,
len 38)
02:03:38.620000 216.109.120.146 > 128.2.4.166: icmp: time exceeded in-transit (ttl 243, id
44973, len 56)
02:03:38.620547 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1880+ PTR?
146.120.109.216.in-addr.arpa. (46) (DF) (ttl 64, id 4461, len 74)
02:03:38.621214 128.2.4.142.53 > 128.2.4.166.1035: 1880 1/0/0 146.120.109.216.in-addr.arpa.
(85) (DF) (ttl 64, id 0, len 113)
02:03:38.621612 128.2.4.166.49909 > 216.109.118.73.33474: [udp sum ok] udp 10 (ttl 14, id 49949,
len 38)
02:03:38.628146 216.109.118.73 > 128.2.4.166: icmp: 216.109.118.73 udp port 33474 unreachable
(ttl 51, id 36371, len 56)
02:03:38.628720 128.2.4.166.1035 > 128.2.4.142.53: [udp sum ok] 1881+ PTR?
73.118.109.216.in-addr.arpa. (45) (DF) (ttl 64, id 4462, len 73)
02:03:38.639794 128.2.4.142.53 > 128.2.4.166.1035: 1881 1/0/0 73.118.109.216.in-addr.arpa. (80)
(DF) (ttl 64, id 0, len 108)
02:03:38.640173 128.2.4.166.49909 > 216.109.118.73.33475: [udp sum ok] udp 10 (ttl 14, id 49950,
len 38)
02:03:38.646520 216.109.118.73 > 128.2.4.166: icmp: 216.109.118.73 udp port 33475 unreachable
(ttl 51, id 36380, len 56)
02:03:38.646797 128.2.4.166.49909 > 216.109.118.73.33476: [udp sum ok] udp 10 (ttl 14, id 49951,
len 38)
02:03:38.653148 216.109.118.73 > 128.2.4.166: icmp: 216.109.118.73 udp port 33476 unreachable
(ttl 51, id 36385, len 56)
The UDP packets going to 216.109.118.73 are the traceroute packets with the incrementing TTL.
The ICMP packets coming from hosts are the routes along the path. The specific port they say is
unreachable specifies which hop they are as the traceroute program remembers that. The only
other packets are the UDP packets to port 53, which are the reverse DNS requests for PTR
records.
It is important to understand the distinction between the layers listed here. ICMP, TCP, and UDP
are independent of each other. There is no TCP port you can block to stop ICMP traffic. UDP and
TCP also are the same way. A diagram of this layout looks like the following.
--------------
|TCP|UDP|ICMP|
--------------
| IP |
--------------
| ICMP |
--------------
The following RFCs provide more information on the protocols. ICMP is described in RFC 792, TCP
is in RFC 793, and UDP is detailed in RFC 768.
Tcpdump
Now that you know a bit about the underlying protocols, let's get to sniffing some traffic. The
first tool we will cover is tcpdump, avaliable at http://www.tcpdump.org/. This tool is the
universal standard in dumping network traffic. On many Unix and Linux machines you will find it
installed by default. There are also Windows versions of the tool for you to download.
Tcpdump is a fairly simple tool to operate, and just running by default will get you going with
the capture process. When run with no arguments it will start to print out a summary of each
packet going by. The summary is a very brief explanation of the packet, protocol, and any high
level details about that packet. Here is a sample dump from a session of tcpdump.
# tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
23:35:11.945236 arp who-has rjs3.dsl.telerama.com tell master-gw.lm.net
23:35:11.946301 IP dhcp-57-139.dsl.telerama.com.46383 > dodgem.telerama.com.domain: 40143+ PTR?
78.9.201.205.in-addr.arpa. (43)
23:35:11.966050 IP dodgem.telerama.com.domain > dhcp-57-139.dsl.telerama.com.46383: 40143*
1/2/2 (185)
23:35:11.966437 IP dhcp-57-139.dsl.telerama.com.46383 > dodgem.telerama.com.domain: 40144+ PTR?
1.9.201.205.in-addr.arpa. (42)
23:35:11.986468 IP dodgem.telerama.com.domain > dhcp-57-139.dsl.telerama.com.46383: 40144*
1/2/2 (175)
23:35:11.987176 IP dhcp-57-139.dsl.telerama.com.46383 > dodgem.telerama.com.domain: 40145+ PTR?
10.1.201.205.in-addr.arpa. (43)
23:35:12.003772 IP dodgem.telerama.com.domain > dhcp-57-139.dsl.telerama.com.46383: 40145 1/2/2
(161)
23:35:12.004260 IP dhcp-57-139.dsl.telerama.com.46383 > dodgem.telerama.com.domain: 40146+ PTR?
139.57.201.205.in-addr.arpa. (45)
23:35:12.022202 IP dodgem.telerama.com.domain > dhcp-57-139.dsl.telerama.com.46383: 40146 1/2/2
(169)
From here the traffic endlessly loops with those two packets going back and forth over and over.
The problem here is that tcpdump tries to lookup the domain name record of the IP address
involved in the packet transactions, but it also tries the same lookup on the packets that are
looking up the dns information for the previous packets. A simple way to prevent this is to add
the argument
not port 53 or
not host dodgem.telerama.com where
the host you specify is your DNS server, or even
-n to stop DNS lookups. So
let's look at that traffic again with the new arguments.
Sniffing with a small filter
# tcpdump not port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
23:35:17.347336 arp who-has enesha-print.dsl.telerama.com tell master-gw.lm.net
23:35:17.432273 IP mail.messagingengine.com.imaps > bat.dsl.telerama.com.1042: F
2107976910:2107976910(0) ack 2779636333 win 5840
23:35:18.386298 arp who-has rjadams3.dsl.telerama.com tell master-gw.lm.net
23:35:18.889386 IP 66-240-89-81.ftl.fdn.com.57253 > dhcp-7-212.dsl.telerama.com.6346: S
3065668763:3065668763(0) win 32768
23:35:19.223265 IP pcp037585pcs.aberdn01.md.comcast.net.oceansoft-lm >
dhcp-7-212.dsl.telerama.com.6346: S 46645961:46645961(0) win 16384
Here is a summary of two seconds of network traffic. We see some arp packets looking up the mac
addresses of two machines. There is a FIN packet closing out the connection to an imap session,
and two requests to open connections to ports on a machine. We can also try the capture without
the DNS information by specifying the
-n option. Here is a sample of that.
# tcpdump -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
23:43:41.751980 arp who-has 205.201.8.44 tell 205.201.8.1
23:43:42.019528 IP 66.240.89.81.57692 > 205.201.7.212.6346: S 3170403634:3170403634(0) win 32768
23:43:42.996488 arp who-has 205.201.13.127 tell 205.201.13.1
23:43:43.033694 arp who-has 205.201.9.78 tell 205.201.9.1
23:43:43.127534 IP 205.201.64.154.4807 > 205.201.57.196.2745: S 3520039812:3520039812(0) win
16384
Again this is similar information for the network traffic, but it is just without the host DNS
information. There is also no delay in waiting for the DNS server to give an answer in order to
display the packets. Although a summary of packets is nice, often we wish to see what is inside
the packets in both hex and ASCII form. For this the option
-X enables us to do
so. This option is very good for looking what is going on in the connection, obtaining plaintext
information sent through the network, or reverse engineering protocols.
# tcpdump -nX
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
23:45:22.412291 IP 24.69.127.253.3206 > 205.201.7.212.6346: S 682928328:682928328(0) win 16384
0x0000: 4500 0030 8653 4000 7306 1395 1845 7ffd E..0.S@.s....E..
0x0010: cdc9 07d4 0c86 18ca 28b4 a8c8 0000 0000 ........(.......
0x0020: 7002 4000 de72 0000 0204 05b4 0101 0402 p.@..r..........
23:45:22.652789 IP 64.30.110.30.15838 > 205.201.7.212.6346: S 2466820352:2466820352(0) win 16384
0x0000: 4500 0030 69b5 4000 6f06 1e39 401e 6e1e E..0i.@.o..9@.n.
0x0010: cdc9 07d4 3dde 18ca 9308 b100 0000 0000 ....=...........
0x0020: 7002 4000 2494 0000 0204 05b4 0101 0402 p.@.$...........
23:45:22.702845 arp who-has 205.201.10.15 tell 205.201.10.1
0x0000: 0001 0800 0604 0001 0030 7b87 c000 cdc9 .........0{.....
0x0010: 0a01 0000 0000 0000 cdc9 0a0f 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
This information is abridged, and does not include the Ethernet layer. If we want to include
layers below the IP layer we can included another X in the flags. This will let us see things
like someone on the local network spoofing IP packets, but not their mac address.
# tcpdump -nXX
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:12:46.278269 arp who-has 205.201.9.211 tell 205.201.9.1
0x0000: ffff ffff ffff 0030 7b87 c000 0806 0001 .......0{.......
0x0010: 0800 0604 0001 0030 7b87 c000 cdc9 0901 .......0{.......
0x0020: 0000 0000 0000 cdc9 09d3 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 ............
00:12:46.442558 IP 64.66.2.26.13227 > 205.201.32.123.25: R 0:3(3) ack 0 win 0
0x0000: 0004 5ae5 90cc 0030 7b87 c000 0800 4500 ..Z....0{.....E.
0x0010: 002b 0000 0000 1006 7a2d 4042 021a cdc9 .+......z-@B....
0x0020: 207b 33ab 0019 0000 0000 0000 0000 5014 .{3...........P.
0x0030: 0000 78fd 0000 636b 6fe0 6100 ..x...cko.a.
00:12:46.519500 arp who-has 205.201.7.84 tell 205.201.7.1
0x0000: ffff ffff ffff 0030 7b87 c000 0806 0001 .......0{.......
0x0010: 0800 0604 0001 0030 7b87 c000 cdc9 0701 .......0{.......
0x0020: 0000 0000 0000 cdc9 0754 0000 0000 0000 .........T......
0x0030: 0000 0000 0000 0000 0000 0000 ............
This information was touched on earlier in this page with the option
not port
53, but tcpdump is fully capable of using many expressions to filter information that
it displays to you. Some examples of useful expressions are the following.
Other packet filters
not port 80
not port 80 and not port 22
host yahoo.com and port 2222
icmp
icmp and host evil.org
It is even possible to add parenthesis to the expressions and make very complicated ones. To use
tcpdump with these expressions just run tcpdump with the argument of the expression. One last
option to mention is the dump option (
-w) and read dump option
(
-r). Dumps are useful because you can later rerun tcpdump on them, run them
with different filters, or run them with a different program, such as tcptrace (
http://jarok.cs.ohiou.edu/softw
are/tcptrace/tcptrace.html).
If you wanted to, you could disassemble every part of the hex code by hand and figure out what
it is doing in the frame. This is not necessary because a nice piece of software called ethereal
will do this for you and is the subject of our next page.
Ethereal
Ethereal is really just a graphical interface to tcpdump, along with some extra code to
disassemble many packets into more useful data for the user. Ethereal isn't installed by default
on as many systems as tcpdump is, so you probably need to download and install it from their
website (
http://www.ethereal.com/).
Once you have ethereal loaded, capturing data from the network is easy. You just have to select
the
Capture menu, and select start. From there you will see a window showing
the number of packets of certain protocols that have been captured. Whenever you are finished,
you can hit the Done button in the window. This will bring you back to the main page of the
captures in a form that is very easy to read. For each packet a short summary in the form that
tcpdump would show is in the list. When you click on the packet a more detailed analysis for the
packet is brought up. Each protocol layer that ethereal handles is disassembled and setup as a
tree form for you to open and close to get more details about each part. Many protocols such as
BGP, AIM, POP, and SMTP are supported. The following image shows the detailed list of
disassembled protocols that is displayed for each packet.
One of the nicest features of ethereal is the follow stream function. You will find this options
in the menu when you right-click a packet. This function lets you completely follow a tcp stream
that is in many packets. It is quite useful when trying to look at the entire protocol that is
being used inside of the TCP stream. Ethereal also displays relative sequence numbers so that
tracking packets in the stream is simplified. Provided below is a sample on how to select the
follow stream feature.
Once you have selected the follow stream feature from the menu, a box displays the entire ascii
stream, and lets you choose a number of different ways to display it. The most useful ways will
probably be ASCII, and Array, which can be used for easily entering the packet into a C program.
The array feature may be useful when discovering exploits that were sniffed off the network, or
other things that require some programming to duplicate the features of the code you have found
on the network.
Other than the decoding and graphical display of packets, ethreal is just an interface to
tcpdump. Having an easy to use filter, save and load function, along with the ability to view
selected parts of a packet by point and click methods is quite useful. You should consider
ethreal a good primary sniffer for your toolbox.
For more information on ethereal visit
http://www.ethereal.com/
Advanced packet sniffing
For those who merely desire to audit passwords being sent out over the network, the dsniff
package is the number one tool for this purpose. This tool, written by dugsong of monkey.org,
enables you to sniff out many private and very sensitive communications going over the network.
Dsniff is really a package of tools, but it also includes a program called dsniff, which
operates in a similar manner to tcpdump. The parameters to tcpdump and dsniff are very similar
and it uses the same filter format. The main feature dsniff offers is only displays passwords
and login information to un-encrypted services that are on the network. This enables the person
running it to quickly identify vulnerable network traffic.
Targeted sniffing against everything
Although dsniff is a very good sniffer, it also is a package of many other utilities that
provide insight to the scope of the problem with un-encrypted network traffic. One of their
utilities called webspy actually changes your netscape browser to show what a victim is browsing
on their computer. This enables you to almost see exactly what is going on in their browser.
Besides for scrolling issues and other minor things it is the same page that is being displayed
on the target's computer. For the network administrator who needs to ensure that employees are
following the set guidelines on internet usage, this is an invaluable tool.
Other interesting abilities the suite of programs has includes the ability to sniff e-mail
messages off the network. The program mailsnarf allows the user to save mail messages going over
the network into a format easily read by existing mail software. There is also support to
interactively view the mail. This could be useful for monitoring employees e-mail usage,
debugging smtp server configurations, or enforcing a request by an investigative organization to
collect a subjects e-mail.
In the same line of tools for extracting un-encrypted information a program called msgsnarf will
decode instant messages that are sent in clear text across the network. Along with web and mail
access, many companies are allowing instant messaging as a form of communications. Msgsnarf
brings the level of monitoring of this traffic up to the same level as the rest of the
protocols. If employees are using instant messaging excessively for personal reasons, then
msgsnarf can help document the violation of policy.
Protocol manipulations using sniffed information
Tools for using the sniffed information to directly manipulate TCP are also in dsniff. The first
of the two programs is tcpnice, which allows adjustments to window and sending source quench
ICMP messages. The effect of this is that high bandwidth network transfers can be slowed down to
a crawl by advertising such packets. There is no interruption or disconnection of the connection
to the users of the connection. The other tool, tcpkill, allows you to kill tcp connections
using a filter in the same syntax as the tcpdump filters. If you want to forcibly stop
connections to and from a host, running
tcpkill host 10.0.0.2 would prevent
communication via TCP with host
10.0.0.2.
Other tools that come with dsniff highlight often overlooked problems. One of the programs
called macof shows a vulnerability in many low end switches, in that they default to becoming a
hub whenever they can no longer store all the MAC addresses that show up on the network in their
memory. In the same manner arpspoof lets you broadcast fake ARP packets saying that your
Ethernet address (or any you specify) is really the hardware address of a certain IP. This can
be used to trick a switch into giving you traffic destined for another machine, forcibly
disconnecting the machine from the network, or taking over a machine's IP address forcibly. The
following is an example attack as viewed on the network.
04:12:29.693465 arp who-has coda.club.cc.cmu.edu tell KRYPTON.CLUB.CC.cmu.edu
04:12:29.693495 arp reply coda.club.cc.cmu.edu is-at 0:3:6d:0:61:3a
04:12:29.693495 arp reply coda.club.cc.cmu.edu is-at 0:3:6d:0:7e:95
04:12:29.693495 arp reply coda.club.cc.cmu.edu is-at 0:3:6d:0:61:3a
04:12:29.693495 arp reply coda.club.cc.cmu.edu is-at 0:3:6d:0:61:3a
Even SSH is not immune to the attacks of dsniff. Included is a program called sshmitm, which
acts as a man in the middle during key exchange. If a host has never connected to the server
being attacked with a man in the middle attack, then they will only have the opportunity to see
the fake host key, and it will be up to them to realize it is a fake host key. Hosts that have
already connected to the host will have the old key stored, but often keys change and the client
will prompt the user to accept the new key. If they do, then the SSH session is completely under
the attacker's control.
For more information on dsniff please see
http://monkey.org/~dugsong/dsniff/.
Intrusion Detection with sniffing
Another specific goal of network sniffing is determining if hackers are attempting to gain entry
into your systems. For this purpose special sniffing software that detects attacks on the
network has been developed. One of the best known, and free, software packages is snort. It is
available for free download at
http://www.snort.org/. Since
it is a sniffer that just has the extra feature of matching packets to known attacks, it is also
able to run in a sniffer mode with the -v flag passed to it. This is the important thing to
realize when running and IDS. It only will pick up attacks that it has a profile for. So your
IDS is not going to alert you if someone does something that the system does not have a rule
for. IDSes will usually not pick up things like unreleased exploits, new exploits, or very slow
and crafted attacks. In some cases it is possible to detect new exploits by looking for commonly
used exploit code in the packets, but this is not necessarily reliable.
The basic flow of data through snort starts out at the sniffer. The data is then prepared to go
through the preprocessors which are capable of detecting many things on their own. Current
preprocessors are able to reassemble streams of packets, handle fragmentation, detect port
scans, and decode relevant parts of protocols. From the preprocessor data moves to the detection
engine, which runs the rules that have been loaded into snort from the configuration files. If
an event is triggered by the detection engine, then any number of event handlers can be called
to deal with the situation. The most common action is to log the event along with the packet or
stream. Other possibilities include notifying the administrator or running a script, which could
do anything.
The logging modes of snort are also an interesting area. Much work has been put into making the
output of snort usable by the administrator. For administrators who need the events put into a
database, there is a comma separated value (CSV) output module. This puts out data that is
importable into most SQL servers, excel, and many other similar programs. Other administrators
desire a readable text file summarizing the event so they can investigate it in more detail at a
later data. This is done with the syslog output module. Other options provide the ability to log
fast connections up to speeds of one gigabit, but the data must be written in a binary mode. It
is even possible to log the entire packet in a form that tcpdump can read, so further analysis
by Computer Emergency Response Team (CERT) is possible.
Running snort
The easiest way to just get running with snort is to run it with the -c snort.conf argument. If
snort.conf is not in the current directory, then you will need to replace it with the full path
to snort.conf, usually in /usr/local/etc. While it is running, it will log alerts into
/var/log/snort. For individual files in the directory, you can watch them in realtime with
another terminal. Run tail -f /var/log/snort/logfile where logfile is the one you wish to watch.
The typical logfile item will look something like the follwoing.
[**] [1:2189:3] BAD-TRAFFIC IP Proto 103 PIM [**]
[Classification: Detection of a non-standard protocol or event] [Priority: 2]
08/09-02:21:13.117406 128.2.4.129 -> 224.0.0.13
PIM TTL:1 TOS:0xC0 ID:26550 IpLen:20 DgmLen:38
[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2003-0567][Xref =>
http://www.securityfocus.com/bid/8211]
Other products
Another interesting IDS product is scanlogd, available for free at
http://www.openwall.com/scanlogd/. Scanlogd uses
sniffing libraries to capture packets and determine if a machine attempts to make connections to
a number of configured ports. The exact ports and limits are configurable in the configuration
file, but whenever the limit is triggered, the application can perform a number of configurable
actions. These actions can include logging, notifying the administrator, or even running a
script to do something like add them to a firewall blacklist. What makes scanlogd notable is
that because it uses sniffing to obtain network traffic, it can even detect the stealth scans of
nmap and react to those as well. Although portscand really does not offer any technical
advantages to snort, it only serves one purpose and is thus much simpler to setup.
Snort is available at
http://www.snort.org/, similarly
scanlogd can be found at
http://www.openwall.com/scanlogd/.
Putting it all together
Lets say that we have been seeing some weird behavior on our webserver lately and that we think
that evil attacker is up to something. To figure out what is going on, we will use our sniffing
tools to discover what kind of traffic is going to our webserver. Hopefully it will be very easy
to discover what the attacker is doing.
# tcpdump -X host 128.2.4.166 and port 80
02:41:37.537110 UNIX2.andrew.cmu.edu.33072 > coda.club.cc.cmu.edu.http: S
2292329806:2292329806(0) win 24820 (DF) [tos 0x68]
0x0000 4568 0030 dadb 4000 3e06 4f56 8002 0d84 Eh.0..@.>.OV....
0x0010 8002 04a6 8130 0050 88a2 2d4e 0000 0000 .....0.P..-N....
0x0020 7002 60f4 d88b 0000 0101 0402 0204 05b4 p.`.............
02:41:37.537242 coda.club.cc.cmu.edu.http > UNIX2.andrew.cmu.edu.33072: S 485194260:485194260(0)
ack 2292329807 win 5840 (DF)
0x0000 4500 0030 0000 4000 4006 289a 8002 04a6 E..0..@.@.(.....
0x0010 8002 0d84 0050 8130 1ceb 7a14 88a2 2d4f .....P.0..z...-O
0x0020 7012 16d0 8b9f 0000 0204 05b4 0101 0402 p...............
02:41:37.537535 UNIX2.andrew.cmu.edu.33072 > coda.club.cc.cmu.edu.http: . ack 1 win 24820 (DF)
[tos 0x68]
0x0000 4568 0028 dadc 4000 3e06 4f5d 8002 0d84 Eh.(..@.>.O]....
0x0010 8002 04a6 8130 0050 88a2 2d4f 1ceb 7a15 .....0.P..-O..z.
0x0020 5010 60f4 6e3f 0000 5555 5555 5555 P.`.n?..UUUUUU
02:41:42.009692 UNIX2.andrew.cmu.edu.33072 > coda.club.cc.cmu.edu.http: P 1:49(48) ack 1 win
24820 (DF) [tos 0x68]
0x0000 4568 0058 dadd 4000 3e06 4f2c 8002 0d84 Eh.X..@.>.O,....
0x0010 8002 04a6 8130 0050 88a2 2d4f 1ceb 7a15 .....0.P..-O..z.
0x0020 5018 60f4 90f6 0000 4745 5420 6874 7470 P.`.....GET.http
0x0030 3a2f 2f31 3238 2e32 2e34 2e31 3636 2f65 ://128.2.4.166/e
0x0040 7669 6c2e 7068 703f 7661 723d 6861 636b vil.php?var=hack
0x0050 7374 7269 6e67 0d0a string..
What we gather from this is that the attacker is making a request to evil.php with some exploit
string, in this case hackstring. From this we can work on a snort rule that will detect this
attack on our network. The first task is to add
include
$RULE_PATH/newattack.rules to the snort.conf file. The next step is to create the
rules.conf file itself. For this we just want to detect the string hackstring going to our port
80. From a look at the snort documentation we are easily able to craft the following rule in the
newattack.rules file.
alert tcp any any -> any 80 (content:"hackstring";msg:"hackstring exploit";)
When running snort again with
snort -c etc/snort.conf and the attacker attempts
again, the following shows up in the log file for snort.
[**] [1:0:0] hackstring exploit [**]
[Priority: 0]
08/09-02:53:30.554607 128.2.13.132:33073 -> 128.2.4.166:80
TCP TTL:62 TOS:0x68 ID:56035 IpLen:20 DgmLen:52 DF
***AP*** Seq: 0x9300E9BC Ack: 0x4A0C9830 Win: 0x60F4 TcpLen: 20
From here you could have it do anything, but there is plenty to be learned by sniffing network
traffic. Just keep a handy refernece around for any protocols you plan to read.
E-Mail Link
Your IP address will be sent with this e-mail
