Professional Documents
Culture Documents
Packet
1. Packet Sniffers
A packet sniffer, the network analyzer, is a wire-tap device that plugs into computer networks and eavesdrops on the network traffic. To capture the information going over the network is called sniffing. It is a "sniffing" program that lets someone listen in on computer conversations. However, computer conversations consist of apparently random binary data. Therefore, network wiretap programs also come with a feature known as "protocol analysis", which allow them to "decode" the computer traffic and make sense of it. These tools known as network sniffers are named after a product called the Sniffer Network Analyzer. Introduced in 1988 by Network General Corp. (now Network Associates Inc.), the Sniffer was one of the first devices that let managers sit at their desks and take the pulse of the larger network. The original sniffers read the message headers of data packets on the network, giving administrators details about the addresses of senders and receivers, file sizes and other low-level information about those packets, in addition to verifying transmission. Using graphs and text-based descriptions, sniffers helped network managers evaluate and diagnose performance problems with servers, the network wire, hubs and applications. They help keep networks humming, but they can also be used by hackers to uncover user names and passwords from data packets traveling across public or private WANs. Encrypting the headers of data packets (using the Secure Sockets Layer standard in browser-based environments, for example) thwarts sniffer-assisted password thefts. Sniffing also has one advantage over telephone wiretaps: many networks use "shared media". Sharing means that computers can receive information that was intended for other machines. This means that you don't need to break into a wiring closet to install your wiretap, you can do it from almost any network connection to eavesdrop on your neighbors. However, this "shared" technology is moving quickly toward "switched" technology where this will no longer be possible, which means you will have to actually tap into the wire. A sniffer being used on a network to snoop passwords and anything else is considered to be a passive attack. A passive attack is one that doesn't directly intrude onto a foreign network or computer. On the other hand, an active attack directly interfaces with a remote machine. Remote buffer overflows, network floods and other similar attacks fall under the category of an active attack . By nature, passive attacks are not www.seminarsonly.com
1
Packet
meant to be discovered by the person(s) being attacked. At no point should they have indication of your activity. This makes sniffers just as serious as any active attack.
Types of Sniffers
Today, sniffers exist in two broad varieties: The first is a stand-alone product incorporated into a portable computer that consultants can carry to customer sites and plug into the network to gather diagnostic data. The second is part of a larger package of network-monitoring hardware and software for helping organizations keep tabs on their LANs, WANs and Web services. Thus Commercial packet sniffers are used to help maintain networks. Underground packet sniffers are used to break into computers.
www.seminarsonly.com
Packet
www.seminarsonly.com
Packet
Some products contain features that allow you to edit your own network packets and transmit them onto the network.
www.seminarsonly.com
Seminar Report Sniffers your online activities, such as: Which Web sites you visit What you look at on the site Whom you send e-mail to What's in the e-mail you send What you download from a site
Packet
located at one of the servers of your ISP would potentially be able to monitor all of
What streaming events you use, such as audio, video and Internet telephony.
From this information, employers can determine how much time a worker is spending online and if that worker is viewing inappropriate material.
www.seminarsonly.com
Packet
3C 2E AC 00 01 01 00 01 D0 E1 66 80 08 00 45 00 01 F7 E8 80 40 00 80 06 39 40 C2 7E 57 A5 D1 01 EC 1A Fig. 2.1 A Captured Frame Each box represents a byte of the frame. The number in each box is actually a hexadecimal number. This frame can be broken down into different parts : The Ethernet header - Bytes 1 to 14 The IP header - Bytes 15 to 35 The TCP header - Bytes 36 to 56 The actual data i.e. the HTTP GET request.
www.seminarsonly.com
Packet
with its MAC address. Every machine on the network segment will receive this message and check its IP address. If it finds it does have that IP address it will respond accordingly. If not then it will go on about its business. The next two bytes represent which protocol the Ethernet header is framing. Here we can see the value is 08 00. Hex 08 00 represents IPv4. Below are some other common protocols 08 06 - ARP 08 08 - Frame Relay ARP 86 DD - IP Next Generation (IPv6) 08 05 - X.25 level 3
Packet
to the beginning of the header....this way a router learns almost immediately the priority of a datagram and can base its following actions on that. The next 4 bits represent the delay, throughput, reliability and cost. Delay If this bit is set to 1 it is requesting of the router that it be sent via a path that offers least amount of delay time (propagation delay). Throughput If this bit is set to 1 it is asking that the router send the datagram through a path that has the most bandwidth i.e. the amount of data that can be stuffed through a pipe in a given moment. Reliability While data is travelling over the lines if there is too much noise (whether this be cross talk or electromagnetic interference (EMI)) it can become corrupt or lost. If this bit is set to 1 it is requesting to be sent through a path with the least chance of data loss. Cost Some network paths can be more expensive to use than others eg the using microwave technology is more expensive than using a frame relay route. This bit allows you to request a path whether that be the more expensive one or not. The last bit of the second byte is reserved, as per the RFC, for future use. Bytes 3 and 4 The next two bytes (01 F7) represent the total IP datagram length. In this case it's 503 bytes (01 F7 hex > dec = 503). Because the total length field is limited to two bytes this means the maximum possible size for an IP datagram is 65535 bytes (FF FF hex). Remember though that the datalink protocol being used may have a maximum transmission unit (MTU) that is smaller than 65535 bytes. In this case the datalink protocol being used is Ethernet and this has an MTU of 1500 bytes. Bytes 5 and 6 When an IP datagram is fragmented i.e. it is chopped up into more managable chunks there has to be a way for the receiving host to reassemble the fragmented IP datagram. The next two bytes (E8 80) denote the datagram ID number. Each fragment of the IP datagram will have the same ID number. The next two bytes are linked to this.
www.seminarsonly.com
Packet
These bytes represent the fragment area.... When IP has a datagram to send it contacts the protocol operating at the datalink level to ascertain how much data it can handle at anyone time i.e. the MTU. IP will then divide its data into chunks that the datalink protocol can handle. If fragmentation is necessary IP uses these two bytes to keep a track of each fragment. Byte number 9 This byte (80) represents the Time To Live (TTL). The TTL is a timing method used by routers to kill off any datagrams that are not delivered for whatever reason. The TTL byte here is set to hex 80 (128 dec.). So this datagram has 128 "seconds" to live. If it doesn't reach the destination by then it'll be discarded. When the datagram comes to the first router in its journey the router will reduce this number. Every router along the way will reduce this number. When it reaches the host at the receiving end this number would have a lower value. Byte number 10 This byte denotes what higher level protocol the IP datagram is carrying. In this case it's (06) .i.e. the Transmission Control Protocol (TCP). Others are: (01) ICMP (Internet Control Message Protocol) (08) EGP (11) UDP (User Datagram Protocol) (59) OSPF (Open Shortest Path First) (58) IGRP. Bytes 11 and 12 Starting on the next line down, these two bytes (39 40) make up the header checksum. This is as much as IP will do for data integrity...it is a connectionless protocol after all. IP assumes that most of the error checking will be done by the higher level protocols such as TCP. Bytes 14 to 20 The first four make up the source IP address and the last 4 bytes make up the destination IP address : C2 7E 57 A5 > 194.126.87.165 D1 01 EC 1A > 209.1.236.26
www.seminarsonly.com
Packet
py.'..HTTP/1.1.2 00.OK..Via:.1.0. STRIDER..Proxy-C onnection:.Keepength:.29674..Co ntent-Type:.text icrosoft-IIS/4.0 ..Date:.Sun,.25. Jul.1999.21:45:5 1.GMT..Accept-Ra nges:.bytes..Las t-Modified:.Mon, .19.Jul.1999.07: 39:26.GMT..ETag: ."08b78d3b9d1be1 :a4a"....<title> Sniffing.(networ k.wiretap,.sniff er).FAQ</title>. ...<h1>Sniffing. (network.wiretap ,.sniffer).FAQ</ ment.answers.que stions.about.tap ping.into...comp
070 41 6C 69 76 65 0D 0A 43 6F 6E 74 65 6E 74 2D 4C Alive..Content-L
0A0 2F 68 74 6D 6C 0D 0A 53 65 72 76 65 72 3A 20 4D /html..Server:.M
Seminar Report Sniffers 1F0 75 74 65 72 20 6E 65 74 77 6F 72 6B 73 20 61 6E ... Fig. 2.4 "hexdump" of a network packet
Packet uter.networks.an
In the hexdump shown above and decode, the "Time to Live" field of 0x7F is underlined. This is how a protocol decode works: it pulls each of the fields out of the packet and attempts to explain what the numbers mean. Some fields are as small as a single bit, other span many bytes. A "protocol analyzer" will then take this hexdump and interpret the individual fields ETHER: Destination address : 0000BA5EBA11 ETHER: Source address : 00A0C9B05EBD ETHER: Frame Length : 1514 (0x05EA) ETHER: Ethernet Type : 0x0800 (IP) IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Service Type = 0 (0x0) IP: Precedence = Routine IP: ...0.... = Normal Delay IP: ....0... = Normal Throughput IP: Total Length = 1500 (0x5DC) IP: Identification = 7652 (0x1DE4) IP: Flags Summary = 2 (0x2)
Packet
TCP: Reserved = 0 (0x0000) TCP: Flags = 0x10 : .A.... TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....0... = No Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin TCP: Window = 28793 (0x7079) TCP: Checksum = 0x8F27 TCP: Urgent Pointer = 0 (0x0) HTTP: Response (to client using port 1909) HTTP: Protocol Version = HTTP/1.1 HTTP: Status Code = OK HTTP: Reason = OK
....
Fig. 2.5 Representation of a network packet by sniffer Protocol analysis really is a difficult art, and requires a lot of knowledge about protocols in order to do it well. However, the rewards are that a lot of information can be easily gleaned from protocols. This info can be useful to network managers trying to debug problems, or hackers who are trying to break into computers.
Packet
and reception on Ethernet is governed by the Ethernet equipment. You just can't send data raw over the wire, you must first do something to it that Ethernet understands. Following a is a brief explanation how this works:
Sniffer
Fig. 3.1 An Ethernet Setup Alice has IP address: 10.0.0.23 Bob has IP address: 192.168.100.54 In order to talk to Bob, Alice needs to create an IP packet of the form 10.0.0.23 192.168.100.54 As the packet traverses the Internet, it will be passed from router-to-router. Therefore, Alice must first hand off the packet to the first router. Each router along the way will examine the destination IP address (192.168.100.54) and decide the correct path it should take. In the diagram, we draw the Internet as a "cloud". All Alice knows about is the local connection to the first router, and Bob's eventual IP address. Alice knows nothing about the structure of the Internet and the route that packet will take.Alice must talk to the router in order to send the packet. She uses the Ethernet to do so. An Ethernet frame looks like the following:
www.seminarsonly.com
13
Packet
What this means is that the TCP/IP stack in Alice's machine might create a packet that is 100 bytes long (let's say 20 bytes for the IP info, 20 bytes for the TCP info, and 60 bytes of data). The TCP/IP stack then sends it to the Ethernet module, which puts 14 bytes on the front for the destination MAC address, source MAC address, and the ethertype 0x0800 to indicate that the other end's TCP/IP stack should process the frame. It also attaches 4-bytes on the end with a checksum/CRC (a validator to see if the frame gets corrupted as it goes across the wire). The adapter then sends the bits out onto the wire. All hardware adapters on the wire see the frame, including the routers adapter, the packet sniffer, and any other machines. Proper adapters, however, have a hardware chip that compares the frame's "destination MAC" with its own MAC address. If they don't match, then it discards the frame. This is done at the hardware level, so the machine the adapter is attached to is completely unaware of this process.
When the ROUTER ethernet adapter sees this frame, it reads it off the wire and removes the leading 14-bytes and the trailing 4-bytes. It looks at the 0x0800 ethertype and decides to send it to the TCP/IP stack for processing (which will presumably forward it to the next router in the chain toward the destination). In the above scenario, only the ROUTER machine is supposed to see the Ethernet frame, and all other machines are supposed to ignore it. The sniffer, however, breaks the rules and copies the frame off the network, too.
www.seminarsonly.com
14
Packet
3.4 RMON
RMON (Remote MONitoring) is an SNMP-based standard that allows management of network traffic. SNMP is the standard way of remotely managing devices. In a typical network, you have routers, hubs, switches, backup power supplies, servers, mail gateways, and so forth. In a modern network, all these devices can be remotely managed with a centralized console. The console sends SNMP commands to monitor their status, to reconfigure them, and receive alerts from them. Of course, each of these devices accepts different commands and support different parameters that can be monitored. For a router, you might be concerned with the rate that packets are being forwarded. For a hub, you might want to monitor for any cabling faults on the ports. For backup power supply, you will want to monitor the voltage of the power being supplied. The collection of monitorable/changeable parameters are stored in a virtual database called a MIB (Management Information Base). www.seminarsonly.com
15
Packet
RMON is just another SNMP MIB. The item that this MIB manages is the traffic on the wire. In other words, we aren't talking about managing a real thing, but a virtual device. 3.4.1 Does RMON function as a remote sniffer? In a pinch, RMON can be used to remotely sniff traffic. The problem is that it isn't very good at it. For example, with today's sniffing products, you can easily do a packet capture of all traffic and save it real time to gigabyte disk drives. If you try to do that with RMON, you'll find difficulties in trying to transfer all that data back to your management console. One way to reduce this data is to set packet capture filters. However, filtering is extremely weak in RMON. If you want to do sniffing, don't rely upon RMON to do it for you. On the flip side, there is a big security concern that RMON is so pervasive on equipment throughout the Internet that you can often find open RMON probes that will allow remote sniffing. Again, it won't provide very good sniffing capabilities, but it will be good enough. 3.4.2 Limitations of RMON: First of all, RMON suffers from the basic problems of SNMP. SNMP has always been a "checkbox" item that customers always want in their products, but which vendors don't spend a lot of time on. Thus, basic activities work within SNMP, but it never quite reaches the hype. Likewise, while there are a ton of products out there that support RMON, they don't always work correctly. Indeed, since RMON is so resource intensive, you will often find that heavy use of RMON crashes the remote device. Second of all, RMON is extremely resource intensive.
www.seminarsonly.com
16
Packet
00-40-05-A4-79-32 ?? ?? ?? ?? ?? ??
Fig. 4.1 ARP Request The entire exchange might look like the diagram below. Alice has an IP packet of some sort (let's say an ICMP ping) to send to Bob. In order to find Bob's MAC address, Alice ARPs it. Bob responds to Alice, telling her his MAC address. Now Alice sends her IP packet to that Ethernet MAC address. Alice ARP broadcast request ARP unicast response ICMP ping request
Alice Alice
Alice
www.seminarsonly.com
Alice
17
Charles
Packet
Fig. 4.2 Requests exchanged between 2 nodes in a network Now Bob has an IP packet to send to Alice. In theory, Bob would need to ARP Alice in order to find her MAC address. But he doesn't. This is because he has remembered her MAC address information that was sent in the original ARP request. In fact, everyone on the local Ethernet saw that request since it was broadcasted. So if Charles at this point wants to ping Alice, he doesn't need to ARP her either, even though he wasn't involved with the original exchange. Broadcasts are sent to everyone on an Ethernet switch. Therefore, you can subvert the switch by sending out ARPs claiming to be somebody else as the source address. You can broadcast out an ARP claiming to be the router, in which case everyone will try to route through you. Or you can send an ARP request just to the victim's MAC address, claiming to be the router, at which point just the victim will forward packets to you. Conversely, you can send an ARP to the router's MAC address claiming to be the victim. In all these cases, you must be prepared to forward packets in the real direction, otherwise you cut off communication.
www.seminarsonly.com
18
Packet
The obvious problem is that victim itself will still send out frames with its MAC address (causing the switch to revert). Another problem is that if the victim doesn't receive the frame, then its communications breaks, and there won't be anything more to sniff. There are a few solutions to this problem, depending upon what you want to do. You may want to subvert an authenticated connection, in which case you DoS (Denial of Service) the victim (taking it offline), redirect the switch, and continue on with the connection as if nothing happened. For example, let's say that Alice has a Telnet connection to the BOB server. You DoS Alice's machine, taking her off line. You then send out packets with Alice's MAC address, causing the switch to send you all packets destined for her. In order to pick up her connection, you cause the server to send you a TCP packet (i.e. use the talk service to prompt her for a connection). At this point, you simply start reversing the sequence and acknowledgement numbers to continue the Telnet connection. Another solution to this problem is to "sample" traffic. Send out packets with the victim's MAC on occasional intervals. You'll likely get the next few packets destined for the victim, but the victim will timeout and recover the connection. The victimized user will notice occasional network delays. A similar solution is that when you receive an incoming packet, turn around and broadcast it back out. This way the victim still receives the packet. A steady stream of outgong traffic and broadcasts of the incoming traffic will allow you to recover a good percentage of the original traffic.
Packet
Alomost all SNMP traffic is SNMPv1, which has no good security. SNMP passwords (called community-strings) are sent across the wire in the clear. 5.4 NNTP, POP, FTP, IMAP Passwords sent in the clear. Data sent in clear Note that all of these systems have secure alternatives. When entering things like credit card information, most web sites use SSL encryption rather than normal HTTP. Similarly, S/MIME and PGP can encrypt e-mail at a level higher than e-mail protocols like POP/IMAP/SMTP.
Packet
send RIP information. The Sniffer will show any IP RIP activity, tipping the network manager off to unusual and potentially harmful routing activity on the network.
www.seminarsonly.com
21
Packet
Packet
Packet
5. Remember that NOBODY should see this packet, because as the frame goes down the wire, each Ethernet adapter matches the MAC address with their own MAC address. If none matches, then they ignore the frame. 6. If you see the response, then the suspect wasn't running this "MAC address filter" on the card, and is hence sniffing on the wire. There are ways defending against this. Now that this technique is widely publicized, newer hackers will enabled a virtual MAC address filter in their code. Many machines (notably Windows) have MAC filtering in drivers. (There is a hack for Windows: most drivers just check the first byte, so a MAC address of FF-00-00-00-0000 looks like FF-FF-FF-FF-FF-FF (the broadcast address which all adapters accept). However, some adapters implement multicast in such as way that this address will match as a multicast, which is any address whose first byte is an odd number. Thus, this can result in false positives). This technique will usually work on switched/bridged Ethernets. When switches see an unknown MAC address for the first time, they will "flood" the frame to all segments.
www.seminarsonly.com
24
Packet
Many sniffing programs do automatic reverse-DNS lookups on the IP addresses they see. Therefore, a promiscuous mode can be detected by watching for the DNS traffic that it generates. This method can detect dual-homed machines and can work remotely. You need to monitor incoming inverse-DNS lookups on the DNS server in your organization. Simply do a ping sweep throughout the company against machines that are known not to exist. Anybody doing reverse DNS lookups on those addresses are attempting to lookup the IP addresses seen in ARP packets, which only sniffing programs do. This same technique works locally. Configure the detector in promiscuous mode itself, then send out IP datagrams to bad addresses and watch for the DNS lookups. One interesting issue with this technique is that hacker-based sniffing programs tend to resolve IP addresses as soon as they are found, whereas commercial programs tend to delay resolution until the point where the packet sniffer user views the protocol decodes.
1. Encryption
www.seminarsonly.com
25
Packet
standard, which in theory means that both Apple computers and Windows-based PCs (as well as a host of other equipment) should be able to use the same wireless infrastructure. For example, a person with a Nokia wireless PCMCIA adapter in their notebook should be able to connect via TCP/IP to an AirPort base station (and be configured automatically via DHCP). There are two IEEE 802.11 standards, one for 2mbps and one for 11-mbps. This discussion focuses on the 2-mbps standard. Spread Spectrum The first question dealing with sniffing is the signaling. This wireless standard uses "spread spectrum" technology. * Rather than transmitting data at a single frequency, data is transmitted over a range of frequencies. * This makes it more immune to electronic noise. * It allows many users to share the same spectrum like cellular. In fact, CDMA, a cellular technology, uses spread spectrum, where each "code" (code division multiplexing) determines the sequence used to "spread" the signal. * In theory, spread-spectrum makes it impossible to eavesdrop. The eavesdropper would need to know the "spreading" function used. Spread-spectrum technology came out of the cold war as a way of sending signals that were near impossible to eavesdrop on. The theory is that an eavesdroppper only hears whitenoise, and that even proving there is a signal could be difficult. However, this assumed that you could securely communicate the "spreading function" to both the transmitter and receiver. This isn't reasonable in consumer-grade products that we'll be buying. The keys will be distributed manually. Moreover, there aren't that many keys. The upshot is that spread-spectrum has little impact as an antisniffing countermeasure. To be fair, it isn't intended to be -- it's used in wireless communication for its anti-noise, bandwidth-sharing capabilities. Security will be accomplished via standard digital encryption techniques. The spectrum used by the standard is 2.400 GHz to 2.4835 GHz, though in theory different frequencies are defined for Japan and Europe. Signal range Roughly 100-meters (300-feet) indoors and 300-meters (1000-feet) outdoors. Estimates indicate that a base station will be able to communicate one floor in each direction. In extreme office conditions, vendors are quoting about 20-meters.
www.seminarsonly.com
26
Packet
However, with parabolic antennas, eavesdroppers can receive signals from much In theory, any IEEE 802.11 compliant device can eavesdrop on all the packets that are within range. (Though, of course, the may need to decrypt it as well). Encryption A method called "Wired Equivalent Privacy (WEP)" is used. This is based upon the RC4 encryption protocol with 40-bit keys. This is essentially the same protocol used by web-browsers for secure connections. RC4 supports up to 128-bit encryption, but the 802.11 standard is at 40-bit encryption for export purposes. Some vendors are providing more bits in the security key, for example Lucent is selling their "WaveLAN Gold" cards supporting 128-bit encryption (though it appears that 128-bit is available outside the US, not inside, as it was developed outside the US and Lucent is protesting US export restrictions by not selling the stronger version inside the US). WEP only protects the data portion. This means that a sniffing machine can decode the physical layer transmissions, but must decrypt the data portion. WEP uses a "shared-key" architecture. This is actually a very bad design, because it requires users to enter in their keys in order to use the network. These keys will likely be based upon passwords, which usually result in effective keys even less than 40-bits. In contrast, web-browsers using SSL are able to encrypt data with no predetermined shared key. WEP is optional, by default it is turned off. We will have to see in the future how often it really is used. For example, WEP is not practical for "ad-hoc" networks (peer-to-peer networks); it is more useful with the use of Access Points (APs). From the look of it, vendors are selling the encryption feature as an "add-on" as well. This bodes well for malicious packet sniffers. To summarize encryption: it will make sniffing difficult, but not impossible. Most people won't use encryption, but even then it will be easy to decrypt the 40-bit encrypted messages. Specialized hardware could be built to recover the key in near real time, but also distributed computing power (like http://www.distributed.net/) can also be used to recover keys. In particular, because the data portion is very well known (IP headers), it is susceptible to a "known plaintext" attack. Access A security concern related to sniffing is simple access. Someone can walk into a building with a notebook computer, which can connect to the network behind the
www.seminarsonly.com
27
Packet
firewall. Internal networks tend to be insecure, so this is a real danger. The WEP protocol has a number of features to prevent this, such as the ability to hard-code MAC addresses into the base-stations specifying who may connect to the network. Roving Users can rove around a network, and be handed off from area-to-area much like cell-phones. A unit maintains the same MAC address and IP address, but changes who it's talking to. This means that the backbone to handle this has to be switched Ethernet or ATM with VLANs. In theory, you could walk around a company and have your notebook beep at you as soon as it finds an area where computers are talking unencrypted. Airports Several companies are equiping places like airports with access stations that allow you to surf online. The WEP protocol as no support for this type of authentication (shared secrets suck). These companies plan on charging connect time, but you could equally have fun by sitting down with your notebook and sniffing everyone else connected to the web. Have fun reading their e-mail, eavesdropping on their chatrooms, and the like.
www.seminarsonly.com
28
Seminar Report Sniffers This will now set the network interface eth0 in promiscous mode.
Packet
/************************simple_Tcp_sniff.c********************/ 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. } /***********************EOF**********************************/ What this means : www.seminarsonly.com
29
#include <stdio.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include "headers.h" int main() { int sock, bytes_recieved, fromlen; char buffer[65535]; struct sockaddr_in from; struct ip *ip; struct tcp *tcp; sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP); while(1) { fromlen = sizeof from; bytes_recieved = recvfrom(sock, buffer, sizeof buffer, 0, (struct sockaddr *)&from, &fromlen); printf("\nBytes received ::: %5d\n",bytes_recieved); printf("Source address ::: %s\n",inet_ntoa(from.sin_addr)); ip = (struct ip *)buffer; printf("IP header length ::: %d\n",ip->ip_length); printf("Protocol ::: %d\n",ip->ip_protocol); tcp = (struct tcp *)(buffer + (4*ip->ip_length)); printf("Source port ::: %d\n",ntohs(tcp->tcp_source_port); printf("Dest port ::: %d\n",ntohs(tcp->tcp_dest_port)); }
Packet
These are the header files required to use some needed c functions we will use later <stdio.h> = functions like printf and std_out IPPROTO_TCP defines <netinet/in.h> = <arpa/inet.h> = structs like the sockaddr_in lets us use the functions to do network to host byte order conversions Line 5 : This is the header file headers.h that is also included with this program to give standard structures to access the ip and tcp fields. The structures identify each field in the ip and tcp header for instance : struct ip { unsigned int unsigned int unsigned char unsigned short unsigned short unsigned short unsigned char ip_length:4; ip_version:4; ip_tos; ip_total_length; ip_id; ip_flags; ip_ttl; /*time-to-live, sets upper limit for max number of routers to go through before the packet is discarded*/ unsigned char unsigned short unsigned int unsigned int }; struct tcp { unsigned short unsigned short www.seminarsonly.com tcp_source_port; tcp_dest_port;
30
/* length of ip-header in 32-bit words*/ /* set to "4", for Ipv4 */ /* type of service*/ /* Total length of ip datagram in bytes */ /*identification field*/
/*identifies the correct transport protocol */ /*calculated for the ip header ONLY*/ /*source ip */ /*dest ip*/
Packet /*tcp sequence number, identifies the byte in the stream of data*/
tcp_ackno; tcp_res1:4,
/*contains the next seq num that the sender expects to recieve*/ /*little-endian*/ /*length of tcp header in 32-bit words*/ /*Finish flag "fin"*/ /*Synchronize sequence numbers to start a connection /*Reset flag */ /*Push, sends data to the application*/ /*acknowledge*/ /*urgent pointer*/ /*maxinum number of bytes able to recieve*/ /*checksum to cover the tcp header and data portion of the packet*/
tcp_hlen:4, tcp_fin:1, tcp_syn:1, tcp_rst:1, tcp_psh:1, tcp_ack:1, tcp_urg:1, tcp_res2:2; unsigned short unsigned short tcp_winsize; tcp_cksum;
unsigned short
tcp_urgent;
/*vaild only if the urgent flag is set, used to transmit emergency data */
}; Line 8-13 : This is the variable declaration section integers : sock bytes_recieved fromlen buffer =socket file descriptor = bytes read from the open socket "sock" = the size of the from structure char : = where the ip packet that is read off the wire will be held buffer will hold a datagram www.seminarsonly.com
31
Seminar Report Sniffers of an ip datagram. Struct sockaddr_in : struct sockaddr_in { short int struct in_addr unsigned char }; sin_family; /* Address family */ */ unsigned short int sin_port; /* Port number
Before we go any further two topics should be covered,byte-ordering and sockaddr structures. Byte-ordering,is the way that the operating system stores bytes in memory. There are two ways that this is done first with the low-order byte at the starting address this is known as "little-endian" or host-byte order. Next bytes can be stored with the high order byte at the starting address, this is called "big-endian" or network byte order. The Internet protocol uses >>>>>> network byte order. This is important because if you are working on an intel based linux box you will be programming on a little-endian machine and to send data via ip you must convert the bytes to network-byte order. For examle lets say we are going to store a 2byte number in memory say the value is (in hex) 0x0203. The next topic that one must understand is the sockaddr vs. the sockaddr_in structures. The struct sockaddr is used to hold information about the socket such as the family type and other address information it looks like : struct sockaddr { unsigned short sa_family; char }; The first element in the structure "sa_family" will be used to reference what the family type is for the socket, in our sniffer it will be AF_INET. Next the "sa_data" element holds the destination port and address for the socket. To make it easier to deal with the sockaddr struct the use of the sockaddr_in structure is commonly used. Sockaddr_in makes it easier to reference all of the elements that are contained by sockaddr. sa_data[14]; /*address family*/ /*address data*/
www.seminarsonly.com
32
Seminar Report Sniffers Sockaddr_in looks like: struct sockaddr_in { short int struct in_addr unsigned char }; sin_family; sin_addr; /* Address family /* Port number /* Internet address */ */ */ unsigned short int sin_port;
Packet
We will use this struct and declare a variable "from" which will give us the information on the packet that we will collect from the raw socket. For instance the var "from.sin_addr" will give access to the packets source address (in network byte order). The thing to mention here is that all items in the sockaddr_in structure must be in network-byte order. When we receive the data in the sockaddr_in struct we must then convert it back to Host-byte order. To do this we can use some predefined functions to convert back and forth between host and network byteorder. Here are the functions we will use: ntohs ntohl : this function converts network byte order to host byte order for a 16-bit short : same as above but for a 32-bit long dotted decimal ip address inet_aton : converts a character string address to the 32-bit network binary value inet_addr : takes a char string dotted decimal addr and returns a 32-bit network binary value To further illustrate ,say I want to know the port number that this packet originated from: int packet_port; packet_port =ntohs(from.sin_port); If I want the source IP address of the packet we will use a special function to get it to the 123.123.123.123 format: char *ip_addr; ip_addr=inet_ntoa(from.sin_addr) Line 11-12: inet_ntoa : this function converts a 32-bit network binary value to a
www.seminarsonly.com
33
Packet
This is a structure that we defined in our header file "headers.h". This structure is declared so that we can access individual fields of the ip/tcp header. The structure is like a transparent slide with predefined fields drawn on it. When a packet is taken off the wire it is a stream of bits, to make sense of it the "transparency" (or cast) is laid on top of or over the bits so the individual fields can be referenced. Line 14 : sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP); This is the most important line in the entire program. Socket() takes three arguments in this form: sockfd = socket(int family, int type, int protocol); The first argument is the family. This could be either AF_UNIX which is used so a process can communicate with another process on the same host or AF_INET which is used for internet communication between remote hosts. In this case it will be AF_INET . Next is the type, the type is usually between 1 of 4 choices The main four are : 1. 2. 3. 4. SOCK_DRAM SOCK_STREAM SOCK_RAW SOCK_PACKET : used for udp datagrams : used for tcp packets : used to bypass the transport layer and directly access the IP layer : this is linux specific, it is similuar to SOCK_RAW except it accesses the DATA LINK Layer For our needs we will use the SOCK_RAW type. You must have root acces to open a raw socket. The last parameter is the protocol,the protocol value specifies what type of traffic the socket should receive , for normal sockets this value is usally set to "0" because the socket can figure out if for instance the "type" of SOCK_DGRAM is specified then the protocol should be UDP.In our case we just want to look at tcp traffic so we will specify IPPROTO_TCP. Line 15 : while (1)
www.seminarsonly.com
34
Seminar Report Sniffers after the first packet is processed we will loop around and grab the next. Line 18:
Packet
The while (1) puts the program into an infinite loop this is necessary so that
bytes_recieved = recvfrom(sock, buffer, sizeof buffer, 0, (struct sockaddr *)&from, &fromlen); Now here is where we are actually reading data from the open socket "sock".The from struct is also filled in but notice that we are casting "from" from a "sockaddr_in" struct to a "sockaddr" struct. We do this because the recvfrom() requires a sockaddr type but to access the separate fields we will continue to use the sockaddr_in structure. The length of the "from" struct must also be present and passed by address. The recvfrom( ) call will return the number of bytes on success and a -1 on error and fill the global var errno. This is what we call "blocking-I/O" the recvfrom() will wait here forever until a datagram on the open socket is ready to be processed. This is opposed to Non-blocking I/O which is like running a process in the background and move on to other tasks. Line 20: printf("Source address ::: %s\n",inet_ntoa(from.sin_addr)); This printf uses the special function inet_ntoa() to take the value of "from.sin_addr" which is stored in Network-byte order and outputs a value in a readable ip form such as 192.168.1.XXX. Line 21: ip = (struct ip *)buffer; This is where we will overlay a predefined structure that will help us to individually identify the fields in the packet that we pick up from the open socket. Line 22: printf("IP header length ::: %d\n",ip->ip_length); The thing to notice on this line is the "ip->ip_length" this will access a pointer in memory to the ip header length the important thing to remember is that the length will be represented in 4-byte words this will be more important later when trying to access items past the ip header such as the tcp header or the data portion of the acket. Line 23: printf("Protocol ::: %d\n",ip->ip_protocol); This gives access to the type of protocol such as 6 for tcp or 17 for udp.
www.seminarsonly.com
35
Seminar Report Sniffers Line 24: tcp = (struct tcp *)(buffer + (4*ip->ip_length));
Packet
The ip header length is stored in 4 byte words, this is where that bit of information becomes important. Here we are trying to get access to the tcp header fields, to do this we must overlay a structure that has the fields predefined just as we did with ip. There is one key difference here the ip header fields were easy to access due to the fact that the beginning of the buffer was also the beginning of the ip header as so : |----------------------- buffer ----------------------------| _________________________________________
ip header ^
* ip
^
* header
So to get access to the ip header we just set a pointer casted as an ip structure to the beginning of the buffer like "ip = (struct ip *)buffer;". To get access to the tcp header is a little more difficult due to the fact that we must set a pointer and cast it as a tcp structure at the beginning of the tcp header which follows the ip header in the buffer as so : |----------------------- buffer ----------------------------|
ip header
tcp header
^ * tcp
This is why we use 4*ip->ip_length to find the start of the tcp header. Line 25-26: printf("Source port ::: %d\n",ntohs(tcp->tcp_source_port); printf("Dest port ::: %d\n",ntohs(tcp->tcp_dest_port)); We can now access the source and dest ports which are located in the tcp header via the structure as defined above. This concludes a simple tcp sniffer. This was a very basic application that should help define how to access packets passing on the network and how to use sockets to access the packets.
www.seminarsonly.com
36
Packet
To use the above program, cut out the above code and strip off all of the line numbers. Save the edited file as sniff.c. Next cut out the header file headers.h and save it to a file headers.h in the same directory. Now just compile: gcc -o sniff sniff.c You should now have the executable "sniff", to run it type #./sniff /*************************headers.h**************************/ /*structure of an ip header struct ip { unsigned int unsigned int unsigned char unsigned short unsigned short unsigned short unsigned char unsigned char unsigned short unsigned int unsigned int }; /* Structure of a TCP header */ struct tcp { unsigned short unsigned short unsigned int unsigned int unsigned int tcp_hlen:4, tcp_fin:1, tcp_syn:1, tcp_rst:1, tcp_psh:1, tcp_source_port; tcp_dest_port; tcp_seqno; tcp_ackno; tcp_res1:4, /*little-endian*/ ip_length:4; /*little-endian*/ ip_version:4; ip_tos; ip_total_length; ip_id; ip_flags; ip_ttl; ip_protocol; ip_cksum; ip_source; ip_dest; */
www.seminarsonly.com
37
Seminar Report Sniffers tcp_ack:1, tcp_urg:1, tcp_res2:2; unsigned short unsigned short unsigned short }; tcp_winsize; tcp_cksum; tcp_urgent;
Packet
/*********************EOF***********************************/
WinDump
A version of tcpdump for Windows.
Echelon
Echelon for Dummies is a distributed sniffer which tries to show how the "echelon" network could be designed. It uses sniffer servers that can be installed and run on remote hosts, and will dig through local network traffic, using custom pattern/keyword matching to find packets with interesting content, which are then forwarded to a central loghost on which the logging daemon is run that gathers and logs the data. For stealth purposes, Sniffers and the logger communicate via random protocols and encryption, and are compatible to many Unix systems and NT.
Gobbler
The Gobbler is perhaps the best freeware DOS Ethernet sniffer. It can decode the Ethernet, IP, TCP and UDP layers, as well as a few low-level protocols like ARP and ICMP. The interface is notable because it's surprisingly easy to quickly browse a
www.seminarsonly.com
38
Packet
dump looking for interesting packets. The source code is available, so in theory one could extend it to your own needs, though I don't know if this is easy to do.
11.1 SSL
"Secure Sockets Layer", SSL is built into all popular web browsers and web servers. It allows encrypted web surfing, and is almost always used in e-commerce when users enter their credit card information. E-mail can be sniffed in many alternative ways. It passes through corporate firewalls, which may monitor the traffic. It often gets logged and saved for extended periods of time. It may get accidentally misdirected, and end up in somebody else's mailbox. The best way to keep such e-mail secret is to encrypt it.
www.seminarsonly.com
39
Packet
machine will occupy its own LAN segment and that segment will only carry data traffic intended for that machine. Such LAN segmentation renders promiscuous mode packet sniffers completely powerless.
Packet
12. Conclusion
Thus Sniffers capture packet traffic across a network, usually an Ethernet. These can be placed surreptitiously on your drives. A sniffer can catch all packet traffic on a particular network block (or segment). Prevention of compromise is a two-fold process: encryption and compartmentalization. Encrypted communications can be used to prevent the capture of passwords if a sniffer attack is underway. It can be assert that one can benefit greatly by running a sniffer on a network, even if only for a day. This will familiarize him with what problems are faced to implement various attacks. Also, if one is proficient with a sniffer, one can see for himself what type of information can actually be gleaned from your particular network configuration
www.seminarsonly.com
41
Packet
Bibliography
[1] The Internet Protocol Journal (IPJ), Volume 2, Number 2, June 1999, Firewalls and Internet Security, the Second Hundred (Internet) Years by Frederick Avolio, Avolio Consulting, Inc. [2] UltimateSniffin' the Ether v2_0. http://networking.earthweb.com [3] Tapping across a network. http://www.wiretapped.net/ [4] Sniffer Packages. http://packetstormecurity.org and http://www.wiretapped.net [5] Sniffers the Network Analyzers http://www.networkingunlimited.com [6] Beej's Guide to Network Programming. http://www.ecst.csuchico.edu/~beej/ [7] TCP/IP Illustrated Vol 1,2,3 - W.Richard Stevens
www.seminarsonly.com
42