Starting with Ubuntu 5.10 and the helloworld module at http://www.embeddedlinuxinterfacing.com/source/helloworld_proc_module_symbol.c
1) uname -a to determine what version of the kernel we're running.
In our case, the output was:
Linux tbdev1 2.6.12-10-386 #1 Tue Jul 18 22:08:27 UTC 2006 i686 GNU/Linux
2) sudo apt-get install linux-source-2.6.12
3) cd /usr/src
4) sudo tar -xvjf linux-source-2.6.12.tar.bz2
5) sudo ln -s linux-source-2.6.12 linux to create /usr/src/linux
6) sudo apt-get install build-essential
7) cat /proc/version to see what version of gcc the kernel was compiled with
In our case, the output was:
Linux version 2.6.12-10-386 (buildd@terranova) (gcc version 3.4.5 20050809 (prerelease)
(Ubuntu 3.4.4-6ubuntu8.1)) #1 Tue Jul 18 22:08:27 UTC 2006
8) sudo apt-get install gcc-3.4 to have the command "gcc-3.4"
Now, we can issue make CC="gcc-3.4"
9) build the kernel using sudo make CC="gcc-3.4" bzImage so the kernel module build had something to link against.
10) Building a module in 2.6.10 isn't the same as 2.4, and we need a Makefile, so use the following:
11) wget http://www.embeddedlinuxinterfacing.com/source/helloworld_proc_module_symbol.c
12) make
Oops, the output shows some warnings about EXPORT_SYMBOL_NOVERS, and an unreferenced variable (int rv at line 170), and a redefinition of MODULE_VERSION. Some research shows the EXPORT_SYMBOLS_NOVERS macro is now deprecated. So, removing lines 213 and 214 will fix that warning. Removing line 170 (unreferenced variable, rv) will fix that warning. Modifying references of MODULE_VERSION to hwMODULE_VERSION will fix the redefinition warning. Note that a MODULE_VERSION macro added to 2.6.3(?), so a better solution would be to use another #define to indicate the version string, but this will do for a quick and dirty fix.
13) make clean;make ---> should now produce a clean (no warnings or errors) build of helloworld_proc_module_symbol.ko
15) sudo insmod helloworld_proc_module_symbol.ko
16) cat /proc/helloworld produces "helloworld Default"
17) sudo rmmod helloworld_proc_module_symbol
An embedded Linux distribution aimed at helping users learn Linux by creating bootable Linux images "virtually from scratch" has achieved a new release. Eagle Linux 2.3 is currently distributed as a concise, 26-page PDF documenting the creation of a minimalist, network-ready Linux image for bootable CDs, floppies, or flash drives.
Introduction
Ethernet
Internet Protocol
TCP,UDP and ICMP
Tcpdump Basics
Ethereal
Dsniff
Snort and IDS Fundamentals
Putting it together
Introduction
------------
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.
Ethernet
--------
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 betreated.
3rd and 4th bytes: Total length of packet5th byte: time to live, decremented by one by each router along theway, prevents loops.
6th byte: protocol number of protocol used in encapsulated data7th and 8th byte: checksum of header.
9th,10th,11th,12th bytes: source internet protocol address13th,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.
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.
TCP, UDP and ICMP
-----------------
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 ServerServer sends SYN/ACK to client if port is openClient 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/0www.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 snippet from a
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)
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 Basics
--------------
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.
# tcpdumptcpdump: verbose output suppressed, use -v or -vv for full protocoldecode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes23:35:11.945236 arp who-has rjs3.dsl.telerama.com tell mastergw.lm.net23: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-57139.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-57139.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-57139.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-57139.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 53tcpdump: verbose output suppressed, use -v or -vv for full protocoldecode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes23:35:17.347336 arp who-has enesha-print.dsl.telerama.com tellmaster-gw.lm.net23:35:17.432273 IP mail.messagingengine.com.imaps >
bat.dsl.telerama.com.1042:
F 2107976910:2107976910(0) ack 2779636333 win
23:35:18.386298 arp who-has rjadams3.dsl.telerama.com tell mastergw.lm.net23:35:18.889386 IP 66-240-89-81.ftl.fdn.com.57253 > dhcp-7212.dsl.telerama.com.6346:
S 3065668763:3065668763(0) win 3276823: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 -ntcpdump: verbose output suppressed, use -v or -vv for full protocoldecode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes23:43:41.751980 arp who-has 205.201.8.44 tell 205.201.8.123:43:42.019528 IP 66.240.89.81.57692 > 205.201.7.212.6346:
S 3170403634:3170403634(0) win 3276823:43:42.996488 arp who-has 205.201.13.127 tell 205.201.13.123:43:43.033694 arp who-has 205.201.9.78 tell 205.201.9.123: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 -nXtcpdump: verbose output suppressed, use -v or -vv for full protocoldecode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes23:45:22.412291 IP 24.69.127.253.3206 > 205.201.7.212.6346:
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 -nXXtcpdump: verbose output suppressed, use -v or -vv for full protocoldecode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes00:12:46.278269 arp who-has 205.201.9.211 tell 205.201.9.1
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 80not port 80 and not port 22host yahoo.com and port 2222icmpicmp 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/software/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 features.
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 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.
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.
Snort and IDS Fundamentals
--------------------------
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
pre-processors which are capable of detecting many things on their own. Current pre-processors are
able to reassemble streams of packets, handle fragmentation, detect port scans, and decode relevant
parts of protocols. From the pre-processor 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.
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.
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.
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:"hackstringexploit";)
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.
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.
