Importance of Network Monitoring
Importance of Network Monitoring A LearnsSecurityOnline.com Article
http://www.learnsecurityonline.com © Learn Security Online, Inc. 2004-2005
Contents
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.
11:43:09.720356 arp who-has 10.0.0.3 tell 10.0.0.211:43:09.720741 arp reply 10.0.0.3 is-at 8:0:2b:93:1b:8e11: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.
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:
S 682928328:682928328(0) win 163840x0000: 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 -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
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) ack0 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 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 more information on ethereal visit http://www.ethereal.com/
Dsniff ------
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:3a04:12:29.693495 arp reply coda.club.cc.cmu.edu is-at 0:3:6d:0:7e:9504:12:29.693495 arp reply coda.club.cc.cmu.edu is-at 0:3:6d:0:61:3a04: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/.
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.
[**] [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 <nop,nop,sackOK,mss 1460> (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 2292329807win 5840 <mss 1460,nop,nop,sackOK> (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.http0x0030 3a2f 2f31 3238 2e32 2e34 2e31 3636 2f65 ://128.2.4.166/e0x0040 7669 6c2e 7068 703f 7661 723d 6861 636b vil.php?var=hack0x0050 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:"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.
[**] [1:0:0] hackstring exploit [**] [Priority: 0] 08/09-02:53:30.554607 128.2.13.132:33073 -> 128.2.4.166:80TCP 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.
http://www.learnsecurityonline.com © Learn Security Online, Inc. 2004-2005
Tell others about
this page:
Comments? Questions? Email Here