NetAnalysis: Using Ethereal.

2004 ~kdm

The basis of this writing is to help you understand what is going through your network. We will be seeing what the data looks like, and learning some of the tools to see and/or change, the data. To see what is happening on the network you need the proper tools and the knowledge to understand what you are seeing. Many people just jump right in and have either no, or a minimal idea of what they are seeing. In order for you to understand what you are seeing, while using any network analysis tools, you have to have at least a basic understanding of networking protocols. The main areas that we will be covering in this document are in the lower layers of the network. If you are unfamiliar with protocols, or the different OSI layers, you had better start in another area of study first. Spend some time in learning the protocols and OSI model. The tool that we will be using is called Ethereal. Ethereal is a free network/protocol analyzer. There are number of network/protocol analyzers available and I use several, but why pay for one, especially when you are learning? Some of these other network/protocol analyzers include: CommView by TamoSoft Inc. I have tested this one. It is affordable for home usage and has some nice options, but does lack some options that I think are important. Of course, I do things that regular home users wouldnt. You can find it @ http://www.tamos.com/products/commview/ Iris by eEye Digital Security I have tested this one and find it very handy, but it isnt inexpensive for home usage. You can find it @ http://eeye.com/html/Products/Iris/index.html EtherPeek by WildPackets Inc. I have not tested this analyzer. At around $3000, it is not for the home user. They do have a demo for people to try it out and I have heard mixed reports on its usage. You can find it @ http://www.wildpackets.com/products/etherpeek_nx Sniffer by Network Associates Inc. I have not tested this analyzer. Very expensive for home usage. You can find it @ http://www.networkassociates.com/us/products/sniffer/mgmt_analysis/cat egory.htm Distinct Network Monitor

I have not tested this analyzer. You can find it @ http://www.network-monitor.com/ Analyzer: a public domain protocol analyzer This is a work in progress, I have not tested this analyzer. You can find it @ http://analyzer.polito.it/ Traffic Monitor and Packet Analyzer by Javvin I have tested this one. It is affordable for home usage and has some excellent options, but it also lack some options that I think are important. You can find it @ http://www.javvin.com/packet.html Some of the other tools that are available and you should have in your arsenal include: netstat ping arp ifconfig/ipconfig/winipcfg tracert/traceroute route whois dig netcat hex editor netscantools pro nmap packet builder tcpview

Some of these tools are already available on your system (dependent on your OS distribution) while others you will need to download or purchase.

What are you Concerned about?

This is the easiest part of network analysis. Basically, you need to know what the concerns are, so you know what needs to be examined. Are the concerns about: the traffic on intranets backbone? the traffic on a specific segment? a certain department's traffic? a specific workstation? the traffic going to/from the Internet?

Perhaps the concern is:

finding out exactly what an application is doing? knowing if the application is secure? finding out if there is any spyware running? knowing if there is any background communications? Someone is going someplace they shouldn't (like to another persons computer)?

Whatever the concern, you need to find out exactly what that concern is, otherwise you could be totally overloaded with information. You need to focus on a specific area. Even if there are multiple areas that need to be investigated, focus on each individual area until finished, then move on to another area. Tracking down network performance problems can be very time-consuming and can get extremely complicated. Frames of data can run into a variety of problems when they are being packetized and transmitted across your network. We will look at some of the most common reasons for non-delivery of your information later. No matter what your interest, there are a few things that you will have to keep in mind. 1. You need to have an interface, and driver, that allows promiscuous mode 2. If you are connected to a switch, you may need to configure the switch for port spanning or mirroring* 3. Dont put absolute trust in the analyzers decodes**
*

If you have a non-switched hub, you can put the interface into promiscuous mode and you will see all traffic that is on your network. If, however, you have a switched hub, then you will only see the traffic that that particular interface is privy to.
**

Analyzers typically apply decodes based on the port value in the header. IE: If you changed FTP to work from port 21 to port 110, then the analyzer will report POP as the protocol being used in the transport name resolution.

Plug into the area of Interest

When it's time to connect to the network to analyze the data, where you 'tap in' depends on the type of network, and your area of interest. The following devices can/will isolate packets for controlling traffic: Bridges Switches Routers

To see filtered traffic on both sides of a bridge or router, you can simply move your analyzer connection from one side to the other side. To see filtered traffic through a switch requires more work. Hopefully the switch allows spanning or port mirroring. NOTE: If you are using Microsoft Windows, and you have bridged your network setup, you will not see all the data that is passing through the network. You will need to make sure that you select the actual Network Interface Card, and not the Bridged MAC. We will go over this in more detail later.

I have, depending on what I wanted to track, placed a small unmanaged, non-switched, hub - with the network/protocol analyzer attached to watch all traffic that passes through. To do this, you need to place the hub between the router or any switches that you want to monitor.

Watching the data (while capturing traffic)

Physically watching the data as it is being captured is the first step in analyzing the performance of a network. It sounds tough, but it really isn't too bad --you may need to practice a few times to get the hang of it. An interesting challenge for protocol analysis is that when an Ethernet NIC (Network Interface Card) receives a packet from the network, it compares the destination address to its own MAC address. If the addresses match, the adapter passes the packet on to the NOS (Network Operating System) for further processing. But, if the addresses do not match, the packet is discarded. For network analysis, we need to monitor every packet on a network or segment. Fortunately, most Ethernet adapters support an option called 'promiscuous mode'. When promiscuous mode is activated, the adapter forwards all the packets it receives, enabling the packet analyzer to see all the traffic that is on that particular network segment. One note of interest: If you find that the network is being flooded, you might want to turn off all resolution processes, such as MAC name, Network name, and Transport name. Ethereal (pronounced i-thear-eel) The "i" sound is the same as the "i" sound for "it" A lot of people want to pronounce it Eth-real or E-thrill, but that is not the correct pronunciation. Anyway, Ethereal is a free network/protocol analyzer, and is distributed under the GNU public license. It doesn't have all the bells and whistles of some of the network/protocol analyzers that are available, but then those aren't free either. Of course, Ethereal has some nicer bells and whistles that arent available in some of the expensive network/protocol analyzers. You can get Ethereal at www.ethereal.com.

Starting up Ethereal
When you first start up Ethereal, you will see that the screen has three panes. The top pane is the packet list pane, the center pane is the packet tree pane, and the bottom pane is the packet data view pane.

The packet list pane (top) displays a summary of every captured packet. When you highlight one of the items in this pane, the other 2 panes will display the contents of the packet. The packet tree view (middle) displays the packet detail information from the highlighted packet selection in the packet list pane. The packet data view pane (bottom) displays the data content of the packet selected in the top pane. If you left click on any of the fields in the packet tree view, that field will be highlighted, showing you where that data is actually located within the packet. NOTE: Using Ethereal also allows you to see the various encapsulations of the OSI model. This can help you to better understand how encapsulation works. Data are sent in blocks called packets. A packet contains header information such as source and destination addresses, control data bits, error-checking bits, etc. The packet also contains the data that is needed by an application program; This data is called the payload. The packet size and the number of bits in the packet depend on the underlying protocol, network type, and other parameters that we will discuss later. The actual packet format also depends on the protocol.

When using a network packet analyzer, every new packet, and all the data in that packet, is stored in a frame. This frame consists of the embedded packet and control (header) information. Some articles, books and many networking professionals use the words Frame, Packet, or Datagram when talking about communication via a network. Most use these terms interchangeably. Generally speaking, using these terms synonymously is accurate. You also may hear the term PDU (Protocol Data Units.) PDUs are the messages that get passed between networks devices at a given level; Such as, layer 2 PDUs are called LPDUs (Link layer Protocol Data Units) or frames, layer 3 PDUs are called NPDUs (Network layer Protocol Data Units) or datagrams, layer 4 PDUs are called TPDUs (Transport layer Protocol Data Units) or segments. What is a datagram? A datagram is a Network layer packet that is an independent, self-contained message whose arrival, arrival time, and contents are not guaranteed. Usually, connectionless data packets are commonly referred to as datagrams, where-as connection-oriented data packets are commonly referred to as segments and are passed on to the Transport layer. What is a frame? A frame contains variable-length packets of data that are created when a stream of information from a networked device are to be sent to another networked device. It is the DLL (Data Link layer), Layer 2, that encapsulates the packet of data for transmission by adding a header, a trailer, and a preamble, to the data. The header includes the network address for the destination, the network address of the sender and control information such as frame, routing, and segmentation information. The trailer contains a CRC (Cyclical Redundancy Check) which is a special calculation that determines a special value for the bit value of the frame. For this section, we dont even need to know about the preamble. The entire frame and contents (Header, Data, & Trailer) created by the DLL is not viewable by protocol analyzers or any other computer-based tool because the hardware strips this part of the data frame prior to any software analysis. To see this information, you would need to use an oscilloscope. For our purposes, in this section, the frame gives us information like, the time of arrival, the Source Address, Destination Address, the Protocol being requested (possibly), and some information about the packet. Using Ethereal a frame can be broken into the following elements: Frame Packet Protocol Type & Header Information [Possible Further Encapsulated Data ]

What is a packet? A packet is a very generic term for a capsule of data that traverses a network. So when the word packet surfaces in a book, or conversation, the person

could be referring to any single, or entire, portion of the transmitted communication between networked devices. We will only be dealing with Ethereal and Ethernet Types as they pertain to TCP/IP and Ethernet networking. A full list of Ethernet Types can be found at: http://www.iana.org/assignments/ethernet-numbers

What is this data?

To better understand what you are looking at, you should know the protocol layers. For example, looking at the Packet Tree Pane (center window) you would see something similar to:
Frame 1 (187 bytes on wire, 187 bytes captured) Ethernet II, Src: 00:08:74:48:57:a5, Dst: 00:d0:b7:14:28:03 Internet Protocol, Src Addr: 192.168.0.4 (192.168.0.4), Dst Addr: 216.54.230.98 (216.54.230.98) Generic Routing Encapsulation (PPP) Point-to-Point Protocol PPP Compressed Datagram

Breaking this down, we would get:

Frame 1 (187 bytes on wire, 187 bytes captured)

This is the preamble data. The software network protocol analyzer gathers the data that it receives which is at the Data-Link layer. So this portion of the packet could be called the Meta-Data. This information breaks down the information into the base information of the packet that has arrived. It informs you of the arrival time, delta time, referenced time, the length of the packet and captured packet size. The analyzer will also number the frame in accordance to the analyzers start, not the transmission start. This information can be used to help determine slowdowns or other possible network problems.
Frame 1 (187 bytes on wire, 187 bytes captured) Arrival Time: Mar 22, 2004 20:02:57.304860000 Time delta from previous packet: 0.000000000 seconds Time since reference or first frame: 0.000000000 seconds Frame Number: 1 Packet Length: 187 bytes Capture Length: 187 bytes

Next, we are informed of what type of packet that has arrived.

Ethernet II, Src: 00:08:74:48:57:a5, Dst: 00:d0:b7:14:28:03

This packet is an Ethernet packet, and if we look at the information here, we are given the MAC addresses of the two systems that are communicating, and also the protocol type.
Ethernet II, Src: 00:08:74:48:57:a5, Dst: 00:d0:b7:14:28:03 Destination: 00:d0:b7:14:28:03 (192.168.0.1) Source: 00:08:74:48:57:a5 (192.168.0.4) Type: IP (0x0800)

Since we are dealing with the Internet, the majority of the packet types will be IP (0x0800), but also very common types of packets that you could see would be ARP (0x0806) and ICMP (0x0800). Next, since this is an IP packet, we would see the IP protocol information.
Internet Protocol, Src Addr: 192.168.0.4 (192.168.0.4), Dst Addr: 216.54.230.98 (216.54.230.98) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 173 Identification: 0x02ed (749) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 128 Protocol: GRE (0x2f) Header checksum: 0xb7ef (correct) Source: 192.168.0.4 (192.168.0.4) Destination: 216.54.230.98 (216.54.230.98)

I am not going go through this packet, or the rest of the information and protocols in this frame right now, we will cover this information in detail later.

Starting the Capture

Next we will start the capture. When we click on the Capture option we will be presented with:

To start, we will make sure that we set Capture packets in promiscuous mode, Update list of packets in real time, and Automatic scrolling in live capture is turned on, and we will turn off the Enable MAC, network, and transport name resolution options. You may be presented with more than one interface option. Depending on the setup of your system that will be doing the capture, you will want to make sure that you select the NIC that will be connected to, and gather information from, your actual connection to the network or segment. When we click on the OK we will see data start to stream in the different panes on the display.

So in Packet List Pane, we see that each packet has a number, time stamp, source address, destination address, protocol, and information about the packet. In the Packet Tree Pane, we see that each packet is numbered sequentially, and gives the number of bytes that traversed the network, and the number of bytes that were actually captured by the analyzer. For instance, in the above depiction, we see that the first packet that we captured has a delta time of 0 (zero) and that this packet is a 90 byte packet and that 90 bytes have been captured. The Data View Pane shows the entire packet contents. The first packet that we captured in our example is an NTP packet. NTP (Network Time Protocol) is designed to time-synchronize a networked device. NTP is documented in RFC 1305 and SNTP (Simple Network Time Protocol) is documented in RFC 2030. and http://www.ietf.org/rfc/rfc1305.txt?number=1305 http://www.ietf.org/rfc/rfc2030.txt?number=2030 There are many reasons for using NTP. One reason is that packet round-trip delay is an important measurement for you to see your networks performance. Another reason is to make sure that your systems stay synchronized for application or logging information. So you may ask Why do I need to check that this packet is correct? The quick answer is that you may not need to check! But time synchronization can be an important part of

any analysis or investigation of systems or network activity. Also, you never know what protocol an attacker may try to tell your system that it is being sent. Lets look at the information about this packet. Frame 1 is the first packet in our capture. Looking in the Tree Pane, it lets us know the captured arrival time of this packet: Arrival Time: Feb 17, 2004 08:00:30.323634000 The next couple items tell us how long it has been since the last packet arrived and the time that the first frame for this transmission took. In this case, since it is the first packet and reference, it is 0: Time delta from previous packet: 0.000000000 seconds Time since reference or first frame: 0.000000000 seconds Next, it is verifying the frame number. If this was different then we would have to start an investigation as to why this was different. Frame Number: 1 The next two pieces of information tell us the size of the packet and the length of the capture. Packet Length: 90 bytes Capture Length: 90 bytes The last piece of information lets us know what protocols are in the frame. [Protocols in the frame: eth:ip:udp:ntp] Now that we have the base information for the packet arrival, we should take a look at the actual packet of data. But before we begin, lets look over the structure of packets and where in the TCP/IP & OSI Layer models the different protocols play their part in the scheme of network communication. Todays networks work on a layered structure. Each layer has its own functions and services and offer these services to the adjoining layers. Starting at the lowest level that we will be dealing with when using Ethereal is the Network Interface layer or Data-link layer. This layer is responsible for checking each packet, and prepares the data for transport to the proper destination. Whether that destination is to an upper level layer or another device on a network. This is the level where the Ethernet structure is created or stripped. The Ethernet packet does not use the IP format for source and destination addresses; Here, the addresses of the source and destination are specified in the form of the MAC (Media Access Control) addresses. The next level that we will be dealing with is the Internetwork layer or Network layer. This layer is responsible for forwarding/routing datagrams. The protocols IP/ICMP and

ARP/RARP reside at this layer. This is the layer that works with the 4 octet addresses that we are more familiar with, which is in the form nnn.nnn.nnn.nnn. It is this layer that gives no guarantees, so sequence errors may be introduced here; It is up to a higher layer operation to correct these errors. The last level that we will go over for now is the Transport layer. This layer is responsible for making sure that segments are reliably transferred from the source to destination. The layer 4 connectionless protocol is UDP (User Datagram Protocol), while the layer 4 connection-oriented protocol is TCP (Transmission Control Protocol). You can find out more about UDP at: http://www.ietf.org/rfc/rfc768.txt?number=768 You can find out more about TCP at: http://www.ietf.org/rfc/rfc793.txt?number=793 Below is a depiction of the Ethernet structure:

The first thing that we see is that this is an Ethernet II packet.

There are many components to the Ethernet specifications which we will not be discussing here. (see Ethernet) We are going to focus our attention on the aspects of Ethernet that we will actually see with the packet analyzer, namely Ethernet addressing and protocol types. Ethernet II packet layout consists of two parts: The header (14 bytes) The data (variable size) The Ethernet Header contains information only of interest to the Ethernet protocol itself while the data typically contains the network-layer data. The header consists of three components, a 6 octet destination address, a 6 octet source address, and a 2 octet type: Ethernet II Destination address: ##:##:##:##:##:## (48 bits) Source address: ##:##:##:##:##:## (48 bits) Length/Type: ##:## (16 bits) An Ethernet address is often referenced as one of the following terms:

DLC Address - Data link Control Address MAC Address - Media Access Control Address Hardware address The 6 octet address is a unique address. Every network adapter has a unique serial number (MAC or OUI Organizationally Unique Identifier). It can get very interesting if two network interfaces end up with the same address. If interested, you can lookup which vendors network interface is being used here: http://standards.ieee.org/regauth/oui/index.shtml Unfortunately, OUIs do not always properly identify the actual equipment vendor. It only identifies the manufacturer. Also, some OUI allocations are kept private. The last two bytes indicate the protocol that will be processed for this packet. The most common types that you will see include: Protocol Type: 0800 0806 0835 809b 80f3 8137 8138 86dd Description: IP - Internet Protocol version 4 (IPv4) [DoD] ARP - Address Resolution Protocol RARP Reverse Address Resolution Protocol Appletalk (Ethertalk) Appletalk Address Resolution Protocol (AARP) Novell IPX (old) Novell IP - Internet Protocol version 6 (IPv6)

On close inspection of the above example, we see that Ethereal put the MAC address in parentheses. If we had turned on MAC Name Resolution, Ethereal would have placed the MAC name first, then placed the MAC number in parentheses. From this information, Ethereal decodes the rest of the packet following the IP packet rules. So next, we see the IP Header. This information is located in RFC 791 http://www.ietf.org/rfc/rfc0791.txt?number=791

First we see that this is an IP version 4 packet. Version: 4 Next, we see that the header length is 20 bytes. Header length: 20 bytes Now the interesting part here is if you highlight (click) the line that tells us the version and look in the Data View Pane, then highlight (click) the Header line and look in the Data View Pane you will see that the same byte is highlighted.

The version is needed for identification of the IP protocol version that is being used. Currently, most traffic is using version 4, but version 6 is being used. The version field is contained in the first four bits of the IP packet.

The Header length is in words (multiples of 4 byte lengths) and is contained in the second 4 bits of the IP packet. The smallest (which is typical) IP header length is 20 bytes, so this field generally will have a value of 5. If the packet is larger, it will be extended in multiples of 4. So if you look at this in binary, you would see it as 0100:0101. The second byte of the IP Header is the Type of Service or referred to as the ToS, and is not widely used. The basics of the type of service portion is to label packets with the type of service.

Looking at the next portion of our dump we see: Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00) 0001 00 . . = Differentiated Services Codepoint: Unknown (0x04) . . . . . . 0 . = ECN-Capable Transport (ECT): 0 . . . . . . . 0 = ECN-CE: 0 The Differentiated Services Field contains two fields: The DSCP field which is used to determine the required priority, and the ECN field. Some of the values that you could see in the DSCP field include: 0x04 (Reliability), 0x08 (Throughput), and 0x10 (Low Delay). The RFCs are located at: http://www.ietf.org/rfc/rfc2474.txt?number=2474

and http://www.ietf.org/rfc/rfc2475.txt?number=2475

We can see that the Total Length of this IP Packet is 76 bytes. Total Length: 76 The Total Length is a 16 bit field that tells the total length of the IP packet in bytes. IP will not support a datagram larger than 65,535 bytes. Most systems will recognize packets that are larger than this and will not except them. An ICMP packet with a datagram larger than this is called a Ping of Death. The next three fields: Identification, Flags, and Fragment Offset are needed for any IP packet fragmentation. Identification: 0x0000 Flags: 0x04 . 1 . . = Dont fragment: Set . . 0 . = More fragments : Not set Fragment Offset: 0 Not all systems or networks use the same packet size for communication. This could be due to resources or even the type of network that may be in use. Ethernet networking tends to have the MTU (Maximum Transmission Unit) set to 1500 bytes per packet, but might be setup differently for different reasons. Sometimes a router will fragment a

packet because the packet is too large for it to service. Whatever the reason a packet is segmented, these three fields are used to reassemble the packet.

The Identification field is primarily used for identifying an IP datagram and all the fragments of a specific datagram, that is, if there is any fragmentation. Basically if a packet is fragmented, this field would have a value that would match all the other packets that need to be reassembled into a single unit.

Next we see Flags which works in conjunction with the Identification Field. The first bit (bit 0) is reserved and not used. The second bit (bit 1) is the Dont fragment bit. If this bit is set, then this informs systems that the packet traverses, not to fragment this packet. If this bit is not set, then the packet can be fragmented. The third bit (bit 2) is set when a packet contains more fragments.

The Fragment Offset informs the receiving system where this packet belongs in the chain of packets that have been fragmented. A fragmented packet cannot be put together until all the packets are received. The receiving machine matches fragmented packets by using the IP address of the transmitting machine and the Identification field.

The Time to live field is used for determining the maximum number of hops a packet can take to get to its destination. Time to live: 64 Next is the protocol field.

It designates what follows the IP header. Protocol: UDP (0x11) The standard values that this field contains include: Keyword ICMP TCP UDP Protocol Internet Control Message Protocol Transmission Control Protocol User Datagram Protocol Hex Rep. 0x01 0x06 0x17

For the complete list go to: http://www.iana.org/assignments/protocol-numbers Next we see the Header checksum.

This is a unique identifier that is used to ensure that the data in the header is delivered intact. The details of the IP checksum are discussed in RFC 1071. The RFC also includes sample code for calculating the checksum. http://www.ietf.org/rfc/rfc1071.txt?number=1071 Next is the Source IP address.

The source address is the IP address of the sending system. Source: LINDOZ (192.168.1.40) The last field in the IP Header is the destination IP.

This is the expected address of the machine that is to receive the datagram. Learning these fields, especially the Protocol field, can assist in monitoring your systems and preventing attacks. One of the most used, and easiest to prevent, attacks on a network is an ICMP attack. I found an excellent paper on ICMP attacks (I dont know who the author is) that you can download and read: ICMP Attacks illustrated @ http://www.sans.org/rr/papers/index.php?id=477 You could setup the system to monitor traffic going to or from a specific IP address. The next item in the analyzers list pane is a Transport layer UDP datagram packet. As you saw in the Protocol field in the IP Header. A UDP packet provides a minimized transmission delay by eliminating the connection setup process, flow control, or any retransmissions of data. What this means is that there will be no attempt made to keep track of packets, as to being in a sequence, order, or even verify that they were received. Checks are made to see if the packet appears to be the same packet transmitted by evaluating the checksum and comparing it to the packets checksum. If the checksums do not match, then the packet is dropped.

On examination of this packet we see: User Datagram Protocol, Src Port: ntp (123), Dst Port : ntp (123) Source port: ntp (123) Destination port: ntp (123) Length: 56 Checksum: 0x72a4 (correct) The Source port specifies what port the local machine is waiting to listen for responses from the destination machine. The Source port is optional and is normally only needed when a reply is to be expected. The Destination port specifies what port initial connections should use. When connecting up to a service on a remote machine, it is the Application Layer program that normally designates the port for a specific service. When it is not a part of an initial connection, or specific service, this identifies what port number is going to be open for the remote machine to communicate. The Length informs the receiving machine of how many of the incoming bits are used for the packet. The length is the total bytes of the UDP packet, which includes the bytes in the header. A UDP always has 4 fields in the header and each is 16 bits. Since the data following (the packets payload) is variable in its length, we can know the length will be 8 bytes + (number of bytes in the payload.)

The Checksum is a calculation that covers the header and data portion of the UDP packet to allow the receiving host to verify the integrity of an incoming UDP packet. This is an optional field, and if it is not used, will be all zeros. If the checksum is used and is correct, then the data is allowed to pass on through, but if the checksum is incorrect, then the packet is dropped, and no attempt is made to try to recover the packet. Basically, the packet is lost forever. More information about checksums are in RFC 1122: http://www.ietf.org/rfc/rfc1122.txt?number=1122 Last portion of this frame contains the data that is in the payload of this packet. It is a request to an NTP server. The NTP (Network Time Protocol) is designed to synchronize the time of a networked device. NTP is a service that runs over UDP, which in turn, runs over IP. You can find out more about NTP in RFC 1305 and SNTP in RFCs 1769 & 2030: and http://www.ietf.org/rfc/rfc1305.txt?number=1305 http://www.ietf.org/rfc/rfc1769.txt?number=1769 http://www.ietf.org/rfc/rfc2030.txt?number=2030

There is a new draft being proposed that would make 1769 and 2030 obsolete. You can read the draft at: http://www.ietf.org/internet-drafts/draft-mills-sntp-v4-00.txt The networked device that is using NTP gets its time from an authoritative time source, such as an atomic clock that is attached to a time server. Looking at the entire NTP packet, we see: Network Time Protocol Flags: 0x23 00 . . . . . . = Leap Indicator: no warning (0) . . 10 0. . . = Version number : NTP Version 4 (4) . . . . . 011 = Mode: client (3) Peer Clock Stratum: secondary reference (2) Peer Polling Interval: 10 (1024 sec) Peer Clock Precision: 0.000015 sec Root Delay: 0.0487 sec Clock Dispersion: 0.0466 sec Clock Reference ID: 130.94.123.235 Reference Clock Update Time: 2004-02-17 15:28:22.2830 UTC Originate Time Stamp: 2004-02-17 15:54:36.1554 UTC Receive Time Stamp: 2004-02-17 15:54:36.1799 UTC Transmit Time Stamp: : 2004-02-17 16:02:30.1003 UTC

I will not be going over the details of this packet because this gets into upper layer operation and I only want to discuss the lower layer operations in this section. Just to let you know, NTP Version 4 has not yet been formalized in the RFC standards yet. If you want to learn more about Version 4, you can go to the NTP organization site and read about NTP and the revisions that it is going through. http://www.ntp.org/ I also wont go over the Time Servers response here, as the information/layout will be very similar.

Monitoring your systems

There are several reasons to monitor your network: Troubleshooting Optimization Security Statistics and Trends Application analysis

Troubleshooting

Troubleshooting networks can be extremely quick and easy, or it can be one of the most mind melting, head pounding, exasperating and most frustrating thing you can do! If you are going to do troubleshooting, then you have to read RFC 1925, The Twelve Networking Truths http://www.ietf.org/rfc/rfc1925.txt?number=1925 Many problems can be quickly found and resolved with a network/protocol analyzer. One way is by using ICMP (Internet Control Message Protocol). It is a message control and error reporting protocol and you really must understand the ICMP packet structure and know how network/protocol analyzers differentiate ICMP packets from other network traffic. ICMP packets are somewhat unusual. ICMP packets do not rely on UDP or TCP, but rather, they are encapsulated directly within an IP datagram.

Each ICMP Message has its own format, but they all begin with the same three fields:

The TYPE and CODE fields are 8 bits each and the CHECKSUM field is 16 bits. The remainder is for data and is variable in size. NOTE: If an ICMP message is reporting an error, it will include the entire header and first 64-bits of the IP datagram that caused the problem. The higher-layer protocols that are in TCP/IP was designed to encode essential information in the first 64-bits of a datagram/message for this reason. I am going to cover ICMP is some depth here because it is so important. Why is it important? Well ICMP can be used to test your network, it is also used by hackers to find out more about your computer or network. It is also used for certain types of attacks on a network. You should be aware of all the parameters of ICMP. You can get the complete lowdown at: http://www.iana.org/assignments/icmp-parameters The RFCs are located at:

http://www.ietf.org/rfc/rfc729.txt?number=792 and http://www.ietf.org/rfc/rfc1122.txt?number=1122 and http://www.ietf.org/rfc/rfc1256.txt?number=1256 and http://www.ietf.org/rfc/rfc1349.txt?number=1349 and http://www.ietf.org/rfc/rfc1812.txt?number=1812 The ICMP protocol is an integral part of the IP protocol and must be implemented. It uses the basics of the IP protocol and acts like a higher level protocol. Some network administrators block ICMP at the firewall. This can be very useful for protecting your network, but ICMP is needed for troubleshooting TCP/IP by allowing you to monitor/manage traffic flow and to make sure that everything is functioning properly. Hackers use ICMP for mapping and attacking networks. Some common ICMP attacks include a Smurf attack and the Ping of Death. If interested in more detail, I am writing another e-booklet about security, or you can check out: Identifying ICMP Hackery Tools Used In The Wild Today. Written: December 4, 2000 http://www.sys-security.com/archive/securityfocus/icmptools.html Or another excellent document, by the same person, is: ICMP Usage In Scanning http://www.sys-security.com/archive/papers/ICMP_Scanning_v2.5.pdf. Using Ethereal, you can setup filters for ICMP:

Internet Control Message Protocol (icmp)

Field icmp.checksum icmp.checksum_bad icmp.code icmp.type Field Name Checksum Bad Checksum Code Type Type Unsigned 16-bit integer Boolean Unsigned 8-bit integer Unsigned 8-bit integer

The protocol field in the IP header indicates that the ICMP header will follow the IP header. The assigned value for ICMP in this field is 0x01.

ICMP Echo Reply

The ICMP Echo Reply message is generated in response to an ICMP type 8 (Echo request) message.

Type and Code must be set to 0. The Identifier and Sequence Number are to be returned to the sender unaltered.

ICMP Destination Unreachable

The Destination Unreachable message is generated by a router, informing the requestor that the requested destination address is unreachable. If the datagram is destined for a multicast address, then this message is not generated in response to the datagram. Some of the possible reasons for this message is that the physical connection of the requested destination does not exist, the indicated protocol or port is not active, or possibly the data must be fragmented but the 'don't fragment' flag is on. Type must be set to 3. Code is used to specify the type of error, and can be any of the following:
Code 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Description Network unreachable error. Host unreachable error. Protocol unreachable error. Port unreachable error. The datagram is too big and 'don't fragment' (DF) flag is on. Source route failed error. Destination network unknown error. Destination host unknown error. Source host isolated error. The destination network is administratively prohibited. The destination host is administratively prohibited. The network is unreachable for Type Of Service. The host is unreachable for Type Of Service. Communication administratively prohibited. Host precedence violation. Precedence cutoff in effect.

ICMP Source Quench

This message is a request to decrease the rate of which the data message traffic is being sent, to an Internet destination. The reason this message may be generated is if the destination or a router to the destination does not have enough buffer space to process the request. It could also be generated if a router or the destination's buffer is approaching its limit.

Type must be set to 4. Code must be set to 0. The additional data is used by the sender to match the reply with the associated request.

ICMP Redirect Message

This message is to inform the ICMP requestor that it needs to redirect datagrams by an alternative route. This is a mechanism used by routers to communicate routing information. As an example; if data is being sent through Router1, then through Router2, to get to a destination, but there is a direct route available for the requestor, then this message will inform the requestor of the direct route to the destination. The routers will still send the request on to the destination unless the data contains routing information. Redirects are only sent by gateways. Type must be set to 5. Code, which specifies the reason for the redirection, include the following:
Code Description 0 Redirect for Network Error.

1 2 3

Redirect for Host Error. Redirect for Type of Service and Network Error. Redirect for Type of Service and Host Error.

The IP address is a 32-bit address of the gateway where the redirection is to be sent.

ICMP Echo Request

An Echo Request message is a packet of data that is sent to a destination. The requestor expects the data that was sent, to be returned in an Echo Reply. If the receiving host responds to an Echo Request, it must respond with an Echo Reply that contains the exact data received in the request message. The Identifier, sequence number and data fields should be returned to the sender unaltered

If you are going to block ICMP at a firewall, it is suggested by the System Administration Networking and Security Institute (SANS) that to maximize computer security, system admin's should block ICMP among other measures: ICMP -- block incoming echo request (ping and Windows traceroute), block outgoing echo replies, time exceeded and host unreachable messages". Unfortunately, this recommendation will also block Path MTU discovery. Furthermore, it is also the reverse of the recommendations of RFC 1435. I recommend that you block all ICMP, then set the Don't Fragment (type 3, code 4) and allow these messages inbound, which should relieve any Path MTU Discovery problems. You should further allow ICMP Echo Request outbound with Echo Reply inbound messages. For Traceroute, be sure to allow TTL-exceeded and Port-Unreachable inbound messages.

Other possible troubleshooting problems

Problem: Out-of-Window collisions occur when a CSMA/CD (Carrier Sensing Multiple Access/Collision Detection) network is extended beyond the recommended guidelines. Out-of-window collisions can significantly reduce network performance because the transmitting stations that contributed to the collision are unaware of the problem until the receiving station(s), notify the transmitting station that the packet was not received. The transmitting station must then wait for access to the network, then resend the data packet. Cause: There are a couple conditions that can cause this type of error to occur. 1. The network's physical length exceeds the IEEE 802.3 specifications of 100 meters (328 Feet) 2. A station on the network is transmitting data without listening for carrier sense (Listening to see if another station is transmitting data, and beginning an illegal transmission of data more than 51.2 microseconds after the first station began transmitting). Solutions: Insure the cabling distances are not greater than recommended by the standard. Check that the number of repeater(s) in the collision domain has not exceeded the standard. If both of the above prove ok, then replace the NIC in the offending station. Problem: Giants are packets that are larger than the maximum allowed Ethernet size of 1,518 bytes (excluding preamble). Cause: Giants are caused by a station that is continuously transmitting; Generally as a result of a hardware or firmware failure (also called a Jabbering Node.) Other possibilities include packets that are being corrupted either by: EMI or RFI from cabling areas, or misaligned packets. The corruption of data via misaligned packets could be a result of a Data Link layer packet formation problem or possibly from some type of transmission medium (cabling)

problem would result in the corrupting or loss of data. They could also be the result of packets that are being passed through more than the recommended number of multi-port transceivers (repeaters, hubs, or switchs.) Alignment packet errors typically also have CRC errors. Solutions: A jabbering station on the network, indicates a bad network card, replace the network card in the offending station. Check the wiring (cabling) and replace the faulty cable with a good cable. Remove possible sources of any EMI or RFI from the cabling areas. Encase all cables in a conduit, or reroute the cables. Problem: Cyclic Redundancy Check (CRC) errors occur when the packets are somehow damaged in transit. When each packet is transmitted, the Data Link layer of the transmitting stations networking device calculates a frame check sequence (FCS) based on the data contained in the packet. The receiving station performs the same calculation. If the FCS values are different, the packet is assumed to be corrupt and is dealt with as a CRC error. Cause: CRC errors are a result of a possible Data Link layer hardware problem, which is causing an erroneous FCS value. Other possibilities include transmission problems from data being corrupted during transmission. Solutions: Replace the network card in the offending station, check the wiring (cabling) and replace any faulty cable with a good cable, or check for, and remove, any possible sources of any EMI or RFI from the cabling areas. Encase all cables in a conduit, or reroute the cables. Problem: A Runt is a data packet that is less than the minimum Ethernet size of 512 bits (64 bytes) in length. Runts are not desirable and usually bridges and routers will automatically discard them rather than forward them. Generally, a ratio of one runt per one million bytes is acceptable but any more and it is likely that the network is experiencing excessive collisions. Cause: Runts are usually the result from collisions, so they may be a natural occurrence of a busy Ethernet segment. However, they could also indicate that there is another problem, such as a bad network card (possible packet shaping), data transmission (corrupted data), or a badly designed network (possibly more than the recommended number of repeaters, hubs, or switchs.) Solutions: Insure the cabling distances are not greater than recommended by the standard. Check that the number of repeater(s) in the collision domain has not exceeded the standard. If both of the above prove ok, then replace the NIC in the offending station.

Filtering and Coloring

Whether you use the Coloring Display or the Display Filters, you are building a filter. By filtering traffic, you can troubleshoot a single station. This is accomplished by narrowing down the packet list to only those packets to or from the station that you want to test. IE, click in the filter field text box on the bottom, left center portion of the screen and enter: ip.addr == ##.##.##.## Once you enter the ip.addr, such as 192.168.1.10, click on the Apply button. The display will show only the activity that is associated with that address. To remove the filter, click on the Clear button to the right of the filter field. I have found that one of the best ways to monitor a system is by color coding. That way, as you watch the data, you can see something suspicious a lot easier and quicker. Not all network/protocol analyzers have the option to color code the different packets. That is one of the better options that Ethereal has available. I suggest color coding the different services, such as: Login services: telnet - 23 (tcp), SSH - 22 (tcp), FTP - 21 (tcp), rlogin - 512 (tcp) through 514 (tcp) RPC and NFS: Portmap/rpcbind - 111 (tcp/udp), NFS - 2049 (tcp/udp), lockd 4045 (tcp/udp) NetBIOS in Windows - 135 (tcp/udp), 137 (udp), 138 (udp), 139 (tcp), and 445(tcp/udp) X Windows - 6000 (tcp) through 6255(tcp) Naming services: DNS - 53 (udp) to any station that is not a DNS server, DNS zone transfers - 53 (tcp) except from an external secondary, LDAP - 389 (tcp/udp) Mail: SMTP - 25 (tcp) to all stations that are not external mail relays, POP - 109 (tcp) and 110 (tcp), IMAP - 143 (tcp) Web: HTTP - 80 (tcp), SSL - 443 (tcp) except to external Web servers, you might want to consider common high-order HTTP port choices - 8000 (tcp), 8080 (tcp), 8888 (tcp) "Small Services": any port that is below - 20 (tcp/udp), time - 37 (tcp/udp) Miscellaneous: TFTP - 69 (udp), finger - 79 (tcp), NNTP - 119 (tcp), NTP - 123 (tcp), LPD - 515 (tcp), syslog - 514 (udp), SNMP - 161 (tcp/udp), 162 (tcp/udp), BGP - 179 (tcp), SOCKS - 1080 (tcp) I prefer setting the colors to match the severity, such as: Red o for anything that is dangerous, or that you know shouldnt be traversing the network. Orange

o For anything that is possibly dangerous, or that you need to really look at, a lot closer. Yellow o For anything that could be dangerous, or that you should check out, to be safe. Brown o For services

You can change the background color to distinguish the differences between the services that a system should be using and any other systems that may be using these services. As an example:

Which will let you see things out of the ordinary, real quick. Like in the depiction below, you can quickly see where a DNS Query passed through the network. If you set up your coloring so that any call to a DNS server other than what you allow, you will notice it very quickly and then can respond to it properly.

For example, if your inside subnet is using the private class C address range of 192.168.1.1 through 192.168.1.254 and the subnet mask that you are using is 255.255.255.0, then you can set up filters where any NetBIOS operations could be quickly spotted with: NetBIOS Inside netbios or nbss or nbns or udp.port == 135 or tcp.port == 135 or udp.port == 137 or udp.port == 138 or tcp.port == 139 or udp.port == 445 or tcp.port == 445 and ip.addr == 192.168.1.0/24 NetBIOS Outside netbios or nbss or nbns or udp.port == 135 or tcp.port == 135 or udp.port == 137 or udp.port == 138 or tcp.port == 139 or udp.port == 445 or tcp.port == 445 and ip.addr != 192.168.1.0/24 and by using different background coloring you could tell very quickly if something suspicious was happening. As discussed earlier, you should keep a close eye on are ICMPs. You could do internal and external as separate colors or possibly use the same color foreground with different color backgrounds. Also, be sure to watch for echo request (ping and Windows traceroute), outgoing echo replies, time exceeded, and destination unreachable.

Coloring your Display

To colorize you display, you need to click on View, Coloring Rules.

Once you have opened the Coloring Rules Display, you can then start adding rules.

Click on New:

We will now add a Coloring Rule for any NetBIOS traffic that is allowed. We will call it NetBIOS Inside. In the Name portion, type NetBIOS Inside, then in the String portion we will add or parameters. NetBIOS Inside netbios or nbss or nbns or udp.port == 135 or tcp.port == 135 or udp.port == 137 or udp.port == 138 or tcp.port == 139 or udp.port == 445 or tcp.port == 445 and ip.addr == 192.168.1.0/24

Next we want to add a Foreground Color. You should create a color chart, so that you can match the Foreground Colors and any Background Colors you are going to use for similar strings coloring rules. Filter Name: NetBIOS Inside NetBIOS Outside Good DNS Hue: 40 40 115 FG Colors BG Colors Sat: Val: Red: Gre: Blu: Opa: Hue: Sat: Val: Red: Gre: Blu: Opa: .96 .96 .94 .99 .99 .42 .99 .99 .05 .68 .68 .42 .04 .04 .02 1 1 1 11 .77 .57 .57 .21 .13 1

DNS Bad 115 DNS Good 71.24 eMail Suspect 71.24 eMail Legal 149 Logon Illegal 149 Logon Ok 116 ICMP Suspect 116 ICMP Web Queries Small Services GRE / Tunnels Port Mapping Inside 99 ARP Outside 99 ARP Misc Services

.94 .96 .96 .90 .90 .75 .75

.42 .63 .63 .63 .63 .42 .42

.05 .52 .52 .06 .06 .12 .12

.42 .63 .63 .63 .63 .42 .42

.02 .03 .03 .34 .34 .11 .11

1 1 1 1 1 1 1

.31

.73

.73

.50

.50

2.96

.29

.98

.98

.71

.69

.91

.96

.06

.04

.31

.73

.73

.50

.50

.83 .83

.58 .58

.27 .27

.58 .58

.10 .10

1 1 64 .44 .95 .93 .95 .54 1

As an Example, I would want the same Forground Color for both the NetBIOS Inside, and NetBIOS Outside.

But I suggest that you change the Background color for the NetBIOS Outside.

This way, you are keeping similar coloring for the operation you want to check, but you can then tell very quickly when something is on the network that should not be on the network.

Once you have made the Display Color selections, you are ready to go.

Creating filters
As an example, by using AND, you can catch a Port Unreachable, which could be an indication of someone is looking for a service that doesnt exist at a station. icmp.type == 3 and icmp.code == 3 Which would show you a packet similar to:
Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Checksum: 0xa7d5 (correct) Data (28 bytes)

I recommend that you build sets of filters and have them ready for use when needed. This would include filters based on specific services, devices, and personnel. That way, if someone is complaining of a problem, you could have a filter made and wouldnt have to look up the address of the station, or device. Also, when creating filters, especially when colorizing, you should consider using pertinent addresses rather than a specific protocol. This is because someone could send information that says it is a specific protocol, when in fact it is not. Also, you could miss information that is relevant. As an example, we will use the pop (port 110) protocol. If we place the protocol pop in the filter field text box, and click on Apply, we will get all the associated calls that are dealing with the pop protocol.

Unfortunately, not all data dealing with email will be displayed. Lets change the filter to: tcp.srcport == 110 or tcp.dstport == 110

We now have other information showing. If you look at frame 12, you will see that the protocol is TCP, yet the actual data is dealing with the email. This is true for all operations, so you want to be careful not to miss some important data. I suggest that when you want to check for email activity you create a filter using the IP address of the email server(s) that should be used. So if your email server is at 192.168.100.10, you would create a filter for the IP address. IE: (ip.dst == 192.168.100.10 and (tcp.dstport == 25 or tcp.dstport == 110)) or (ip.src == 192.168.100.10 and (tcp.srcport == 25 or tcp.srcport == 110)) Then to check for any email activity that passes through the network that is going to nonauthorized email server(s), use: (ip.dst != 192.168.100.10 and (tcp.dstport == 25 or tcp.dstport == 110)) or (ip.src != 192.168.100.10 and (tcp.srcport == 25 or tcp.srcport == 110)) This way, if someone is checking their personal email, it will show up and can be dealt with according to the policies that have been established. As suggested earlier, you might want to set up predefined filters. You can do this by clicking on Analyze.

Then click Display Filters.

Now to create a filter, click in the Filter name text box and type in the name you want for the filter. Next, click in the Filter string text box and type the expression you want. There are expressions that are already created, and many are useful and can be implemented by themselves or added to your own. Once you are done, click New, and then be sure to click on the Save. An interesting thing that I have found in Ethereal, or any protocol analyzer, is that you cannot trust what you think you are looking for by applying a filter to track or analyze. You may need to do some manipulation of a needed expression. What do I mean? Well, lets look at an example. Lets say you want to see any illegal tunneling into the network, or even a certain system. It is easy to set up a filter to do this; but will the filter get everything? In the following example, the computer has been compromised. A tunnel has been created and we need to see what is going on. If you look at frames 30 through 35, the protocol is telling us that it is PPP, but then frame 36 is PPTP and frame 37 is TCP. If we had selected just the protocols, we would have missed frame 37, along with several other frames.

Comparing Values
Filters can be built using several types of comparative operators to compare values. Display filter comparison operators English C-like Description and example eq == Equal ip.addr==192.168.1.16 ne gt lt ge le != > < >= <= Not equal ip.addr!=192.168.1.16 Greater than frame.pkt_len > 10 Less than frame.pkt_len < 128 Greater than or equal to frame.pkt_len ge 0x100 Less than or equal to

English C-like Description and example frame.pkt_len <= 0x20 In addition, all protocol fields are typed. Below is a list of the types and example of how to express them. Field Types Type Example Unsigned integer You can express integers in decimal, octal, or hexadecimal. (8-bit, 16-bit, The following display filters are equivalent: 24-bit, 32-bit)
ip.len le 1500 ip.len le 02734 ip.len le 0x436

Signed integer (8-bit, 16-bit, 24-bit, 32-bit) Boolean

A boolean field is present in the protocol decode only if its value is true. For example, tcp.flags.syn is present, and thus true, only if the SYN flag is present in a TCP segment header. Thus the filter expression tcp.flags.syn will select only those packets for which this flag exists, that is, TCP segments where the segment header contains the SYN flag. Similarly, to find source-routed token ring packets, use a filter expression of tr.sr.

Ethernet address (6 bytes) IPv4 address IPv6 address IPX network number String (text) Double-precision floating point number
Combining expressions

You can combine filter expressions in Ethereal using the logical operators shown in Table 3-9

Table 3-9. Display Filter Logical Operations English C- Description and example like and && Logical AND
ip.addr==192.168.1.16 and tcp.flags.fin

or

||

Logical OR
ip.addr==192.168.1.16 or ip.addr==192.1.1.1

xor

^^

Logical XOR
tr.dst[0:3] == 0.6.29 xor tr.src[0:3] == 0.6.29

not

Logical NOT
not llc

[...]

Substring Operator Ethereal will allow you to select subsequences of a sequence in rather elaborate ways. After a label you can place a pair of brackes [] containing a comma separated list of range specifiers.
eth.src[0:3] == 00:00:83

The example above uses the n:m format to specify a single range. In this case n is the beginning offset and m is the length of the range being specified.
eth.src[1-2] == 00:83

The example above uses the n-m format to specify a single range. In this case n is the beginning offset and m is the ending offset.
eth.src[:4] == 00:00:83:00

The example above uses the :m format, which takes everything from the beginning of a sequence to offset m. It is equivalent to 0:m
eth.src[4:] == 20:20

The example above uses the n: format, which takes everything from offset n to the end of the sequence.

English C- Description and example like

eth.src[2] == 83

The example above uses the n format to specify a single range. In this case the element in the sequence at offset n is selected. This is equivalent to n:1.
eth.src[0:3,1-2,:4,4:,2] == 00:00:83:00:83:00:00:83:00:20:20:83

Ethereal will allow you to string together single ranges in a comma-separated list to form compound ranges as shown above.

Ethereal filters (eth.src != 00:0c:76:7e:c3:21) and (ip.src != 192.168.1.115) and (eth.dst != 00:0c:76:7e:c3:21) and (ip.dst != 192.168.1.115) and (eth.src != 00:0c:e5:c7:29:fc) and (ip.src != 66.119.217.142) and (eth.dst != 00:0c:e5:c7:29:fc) and (ip.dst != 66.119.217.142) Jackie Pleasants (eth.src != 00:0c:76:7e:c3:21) and (ip.src != 192.168.1.115) and (eth.dst != 00:0c:76:7e:c3:21) and (ip.dst != 192.168.1.115) Surveillance PC (eth.src != 00:06:29:f1:37:ea) and (ip.src != 192.168.1.211) and (eth.dst != 00:06:29:f1:37:ea) and (ip.dst != 192.168.1.211) conspiracy theory
HTTP client sends message requesting document: GET /comm.html HTTP/1.1 HTTP daemon listening on TCP port 80 interprets message. HTTP daemon sends a result code and a description of the information that the client will receive. HTTP/1.1 200 OK Date: Mon, 06 Jan 2003 23:56:44 GMT Server: Apache/1.3.23 (Unix) Last Modified: 03 Sep 2002 02:58:36 GMT Content-Length: 8218 Content-Type: text/html

Result code 200 indicates that the client request was successful and that the document is to follow. The message also contains information about the server software, the length of the document (8218 bytes), and the content type of the document (text/html). If the request was for an image, the type might be image/gif. If the request is not successful, the server sends a different result code, which usually indicates the type of failure, for example, 404 when a document is not found.
HTTP daemon reads the file and sends requested file through the TCP port.

<html> <head><title></title>... <font face="Arial" >What is Communications?</font> Text is displayed by client browser, which interprets the HTML format. HTTP daemon disconnects the connection after the connection is idle for some timeout period.

In the case of HTTP, we require a two-way connection that transfers a stream of bytes in correct sequential order and without errors. The TCP protocol provides this type of communication service between two processes in two machines connected to a network. Each HTTP process inserts its messages into a buffer, and TCP transmits the contents of the buffer to the other TCP in blocks of information called segments, DNS - Typically the requesting machine accesses a local name server, which, for example, may reside in a university department or at an ISP. These local name servers are able to resolve frequently used domain names into the corresponding IP addresses by caching recent information. When unable to resolve a name, the local name server may sometimes send a query to a root name server, of which there are currently 13 distributed globally. When a root server is unable to determine an IP address, it sends a query to an authoritative name server. Every machine on the Internet is required to register with at least two authoritative name servers. If a given name server cannot resolve the domain name, the queried name server will refer to another name server, and this process continues until a name server that can resolve the domain name is found.
Application requests name to address translation. Resolver composes query message. Header: OPCODE=SQUERY Question: QNAME=tesla.comm.toronto.edu., QCLASS=IN, QTYPE=A Resolver sends UDP datagram encapsulating the query message. DNS server looks up address and prepares response. Header: OPCODE=SQUERY, RESPONSE, AA Question: QNAME= tesla.comm.toronto.edu., QCLASS=IN, QTYPE=A Answer: tesla.comm.toronto.edu. 86400 IN A 128.100.11.1 DNS sends UDP datagram encapsulating the response message.

The short message returned by the server in step 4 has the Response and Authoritative Answer bits set in the header. This setting indicates that the response comes from an authority that manages the domain name. The question portion is identical to that of the query. The answer portion contains the domain name for which the address is provided. This portion is followed by the Time-to-Live field, which specifies the time in units of seconds that this information is to be cached by the client. Next are the two values for QCLASS and QTYPE. IN again indicates that it is an Internet address. Finally, the IP address of the domain name is given (128.100.11.1). In this example the DNS query and response messages are transmitted by using the communication service provided by the User Datagram Protocol (UDP). The UDP client attaches a header to the user information to provide port information (port 53 for

DNS) and encapsulates the resulting block in an IP packet. The UDP service is connectionless; no connection setup is required, and the datagram can be sent immediately. Because DNS queries and responses consist of short messages, UDP is ideally suited for conveying them. Finally, we consider an e-mail example, using the Simple Mail Transfer Protocol (SMTP). Here a mail client application interacts with a local SMTP server to initiate the delivery of an e-mail message. The user prepares an e-mail message that includes the recipients e-mail address, a subject line, and a body. When the user clicks Send, the mail application prepares a file with the above information and additional information specifying format, for example, plain ASCII or Multipurpose Internet Mail Extensions (MIME) to encode non-ASCII information. The mail application has the name of the local SMTP server and may issue a DNS query for the IP address. Table 2.3 shows the remaining steps involved in completing the transfer of the e-mail message to the local SMTP server. Before the e-mail message can be transferred, the application process must set up a TCP connection to the local SMTP server (step 1). Thereafter, the SMTP protocol is used in a series of exchanges in which the client identifies itself, the sender of the e-mail, and the recipient (steps 28). The client then transfers the message that the SMTP server accepts for delivery (steps 912) and ends the mail session. The local SMTP server then repeats this process with the destination SMTP server. To locate the destination SMTP server, the local server may have to perform a DNS query of type MX (mail exchange). SMTP works best when the destination machine is always available. For this reason, users in a PC environment usually retrieve their e-mail from a mail server using the Post Office Protocol version 3 (POP3) instead.

Inside Network ip.src == 192.168.1.0/24 and ip.dst == 192.168.1.0/24

Filtering on a Single Bit Value
Connection-oriented services, such as FTP and HTTP, require an initial TCP handshake to establish the connection and exchange a starting sequence number. This sequence number increases in accordance with the amount of data received, thereby offering reliable, guaranteed service for TCP data. In the first packet of the TCP handshake, the SYN (SYNchronize sequence number) bit in the TCP header is set to 1. Why would you care about this packet? Well let's say you've configured a very secure network. You decided that no one should be able to connect to your inside computers from the Internet. That means no SYN packets should make it through the firewall, right? You might want to check that out by building a filter on all SYN traffic crossing the wire on the inside of the firewall. The bit sequence in TCP headers is structured as shown in Figure 2-15. The TCP flag set. where, r = reserved bits - set to 0 U = Urgent bit (value 0x20)
FIGURE 2-15.

A = Acknowledgment bit (value 0x10) P = Push bit (value 0x08) R = Reset bit (value 0x04) S = Synchronize bit (value 0x02) F = Finish bit (value 0x01)
If someone is really trying to be sneaky, they may try to go through your firewall using a packet with both the SYN flag and another flag set. Ugh. In this case, you might have to build a more advanced filter - a boolean filter that ORs together various flag setting patterns.

Yes. You really do need to know the protocols and how they operate! Consider getting TCP/IP Illustrated by W. Richard Stevens. The reason I like that book more than the others is (a) it is accurate and detailed, and (b) it shows packets throughout the book.

Protecting your systems

One way to protect your systems is by setting up a firewall to stop ICMP attacks by blocking packets that contain a 0x01 in the Protocol field. You could do this in several ways; by stopping all packets that contain the 0x01, or just stop all outside IP addresses that contain the 0x01, or even set it up so that only certain IP addresses are allowed to use this protocol. After setting up your firewall to stop ICMP attacks, you can turn the display color of ICMP packets to red. When you scroll through and you see a red ICMP, you can take a closer look to see what actually happened. This way you can fine tune your firewall. I use a FreeBSD box for my firewall. I also use ZoneAlarm on all MS Windows boxes that are behind the firewall. If interested, you can read about my firewalling techniques in Firewalls: To Protect and To Serve.

Now that the analyzer knows this is an ARP packet, it decodes the remainder of the packet following the rules for the ARP protocol: A TCP/IP protocol used to convert an IP address into a physical address (called a DLC address), such as an Ethernet address. A host wishing to obtain a physical address broadcasts an ARP request onto the TCP/IP network. The host on the network that has the IP address in the request then replies with its physical hardware address.

Network Analysis Codes:

TCP:

URG ACK PSH RST SYN FIN UDP:

RETR <data> Depending on the data that is seen, can help you determine exactly what is actually happening. FIN RST ACK URG PSH

Re: simulated winupdate flood packets - MSBLAST analysis thread said by Steve : The TCP source port is always in the range 1000 .. 1999. The TCP sequence number is always 0xXXYY0000 where XX is 0..255 and YY is 0..127 (the result of the bad use of the random number generator)

Here is the text output from Ethereal for a couple of network frames. This was just an internal LAN test with systems with IPs in the 192.168.100.xxx range. I added line breaks for a couple of lines to keep the formatting. Edit: in order to prod the worm into doing the TCP SYN packet "flood," I also added a hosts file entry for windowsupdate.com to point to the target system (192.168.100.21) and set the system clock forward to 17 August on the "infected" system: Frame 856 (60 bytes on wire, 60 bytes captured) Arrival Time: Aug 12, 2003 02:00:39.602922000 Time delta from previous packet: 0.020046000 seconds Time relative to first packet: 18.705396000 seconds Frame Number: 856 Packet Length: 60 bytes Capture Length: 60 bytes Ethernet II, Src: 00:10:4b:75:54:96, Dst: 00:03:47:d9:26:60 Destination: 00:03:47:d9:26:60 (Intel_d9:26:60) Source: 00:10:4b:75:54:96 (3Com_75:54:96) Type: IP (0x0800) Trailer: 000000000000 Internet Protocol, Src Addr: 192.168.247.140, Dst Addr: 192.168.100.21 Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 40 Identification: 0x0100 Flags: 0x00 .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 128 Protocol: TCP (0x06) Header checksum: 0x5cdd (correct) Source: 192.168.247.140 (192.168.247.140) Destination: 192.168.100.21 (192.168.100.21) Transmission Control Protocol, Src Port: 1436 (1436), Dst Port: http (80), Seq: 1293025280, Ack: 0, Len: 0 Source port: 1436 (1436) Destination port: http (80) Sequence number: 1293025280 Header length: 20 bytes Flags: 0x0002 (SYN) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...0 .... = Acknowledgment: Not set .... 0... = Push: Not set .... .0.. = Reset: Not set .... ..1. = Syn: Set .... ...0 = Fin: Not set Window size: 16384 Checksum: 0x3ff1 (correct) 0000 00 03 47 d9 26 60 00 10 4b 75 54 96 08 00 45 00 ..G.&`..KuT...E. 0010 00 28 01 00 00 00 80 06 5c dd c0 a8 f7 8c c0 a8 .(......\.......

0020 64 15 05 9c 00 50 4d 12 00 00 00 00 00 00 50 02 d....PM.......P. 0030 40 00 3f f1 00 00 00 00 00 00 00 00 @.?......... Frame 857 (60 bytes on wire, 60 bytes captured) Arrival Time: Aug 12, 2003 02:00:39.622931000 Time delta from previous packet: 0.020009000 seconds Time relative to first packet: 18.725405000 seconds Frame Number: 857 Packet Length: 60 bytes Capture Length: 60 bytes Ethernet II, Src: 00:10:4b:75:54:96, Dst: 00:03:47:d9:26:60 Destination: 00:03:47:d9:26:60 (Intel_d9:26:60) Source: 00:10:4b:75:54:96 (3Com_75:54:96) Type: IP (0x0800) Trailer: 000000000000 Internet Protocol, Src Addr: 192.168.57.140 (192.168.57.140), Dst Addr: 192.168.100.21 (192.168.100.21) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 40 Identification: 0x0100 Flags: 0x00 .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 128 Protocol: TCP (0x06) Header checksum: 0x1ade (correct) Source: 192.168.57.140 (192.168.57.140) Destination: 192.168.100.21 (192.168.100.21) Transmission Control Protocol, Src Port: 1271 (1271), Dst Port: http (80), Seq: 1927610368, Ack: 0, Len: 0 Source port: 1271 (1271) Destination port: http (80) Sequence number: 1927610368 Header length: 20 bytes Flags: 0x0002 (SYN) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...0 .... = Acknowledgment: Not set .... 0... = Push: Not set .... .0.. = Reset: Not set .... ..1. = Syn: Set .... ...0 = Fin: Not set Window size: 16384 Checksum: 0xd8c3 (correct) 0000 0010 0020 0030 00 03 47 d9 26 60 00 10 4b 75 54 96 08 00 45 00 ..G.&`..KuT...E. 00 28 01 00 00 00 80 06 1a de c0 a8 39 8c c0 a8 .(..........9... 64 15 04 f7 00 50 72 e5 00 00 00 00 00 00 50 02 d....Pr.......P. 40 00 d8 c3 00 00 00 00 00 00 00 00 @...........

Not that is matters, but both of those packets have the slightly different "payloads" / data fields: 00 00 00 00 00 00 50 02 40 00 3f f1 00 00 00 00 00 00 00 00 vs. 00 00 00 00 00 00 50 02 40 00 d8 c3 00 00 00 00 00 00 00 00 Those are the TCP checksums, I believe. http://www.ntp.org/ http://www.iana.org/assignments/protocol-numbers http://taosecurity.blogspot.com/2004_01_01_taosecurity_archive.html http://www.gocertify.com/quizzes/osi/osi16.shtml http://www.dmccormick.org/tcpip.htm http://www.windowsnetworking.com/j_helmig/tcpip.htm http://www.tcpipprimer.com/packets.cfm http://www.mynetwatchman.com/pckidiot/ http://www.tcp-ip.ca/understanding_the_layer_models.htm http://studsys.mscs.mu.edu/~doug/spectral/Networks2001F/IP/ http://hackers.inside.net/staticpages/index.php?page=20030529215111284 Managing the System: http://www.prz.tu-berlin.de/docs/misc/ciscodoc/data/doc/software/9_21/rpcg/78728.htm#HDR1 http://www.rapid7.com/SampleReports/DiscVulnerabilities.html http://www.helsinki.fi/atk/unix/dec_manuals/DOC_40E/HTML/MAN/MAN1/0340____.HTM

zerowindow segment: The duration in seconds of a zero window before a symptom is triggered. Generating zero-window probes using TCP echo service Probing Procedure Keep sending data to the echo port without readingthe echoed data. Because the probe program sends data without reading the echo, the receive buffer of TCP A eventually becomes full, causing it to send a zero-window ACK segment to TCP B. Because TCP B cannot send data to TCP A, the send buffer of TCP B will become full of echoed data. When the echo server on B cannot send more data, the receive buffer of TCP B will become full. Once the receive buffer of TCP B becomes full, it advertises a zero window to TCP A. After the zerowindow condition exists for more than a threshold time period, both sides begin sending zero-window probes.

DNS Standard Query PTR DNS Standard Query Response DNS Standard Query A DNS Standard Query CNAME UDP Source port: 4834 Destination port: 53 Length: 0x0032 (50) Checksum: 0x63B2 (25522) - correct DNS ID: 0x3122 (12578) Response packet: 0 Operation code: 0x00 (0) - Standard query Flags Authoritative Answer: 0 Truncation: 0 Recursion Desired: 1 Recursion Available: 0 Question records: 0x0001 (1)

The fields labelled NUMBER OF ... give each a count of entries in the corresponding sections in the message. The QUESTION SECTION contains queries for which answers are desired. The client fills in only the question section; the server returns the question and answers with its response. Each question has Query Domain Name followed by Query Type and Query Class fields . ANSWER, AUTHORITY, ADDITIONAL INFORMATION sections consist of a set of resource records that describe domain names and mappings. Each resource record describes one name . The Domain Name Service (DNS) protocol searches for resources using a database distributed among different name servers. The DNS message header structure is shown in the following illustration: 16 ID 21 Q Query A T R V 28 B 32 bits Rcode

Question count Answer count Authority count Additional count DNS message header structure ID - 16-bit field used to correlate queries and responses. The IDENTIFICATION is set by the client and returned by the server. The 16-bit PARAMETER consists of: 0-th bit field -qr: 0 means the message is a query,1 means it's a response. 1-4 bit fields - OPCODE: 0 -is a normal value (Standard query). 1 - an inverse query. 2 - the server status request. 5-th bit field - Authoritative answer. The name server is authoritative for the domain in the question section. 6-th bit field is set if message truncated. With UDP this means that the total size of the reply exceeded 512 bytes, and only the first 512 bytes of the reply were returned. 7-th bit field - Recursion Desired. This bit can be set in a query and is then returned in the response. 8-th bit field - Recursion Available. 9-11 -th bits field has to be 0. 12-15 -th bits field - Return Code. 0- no error, 3- name error.

Q - 1-bit field that identifies the message as a query or response.

Query - 4-bit field that describes the type of message: 0 1 2 Standard query (name to address). Inverse query (address to name). Server status request.

A - Authoritative Answer. 1-bit field. When set to 1, identifies the response as one made by an authoritative name server. T - Truncation. 1-bit field. When set to 1, indicates the message has been truncated. R - 1-bit field. Set to 1 by the resolve to request recursive service by the name server. V - 1-bit field. Signals the availability of recursive service by the name server. B - 3-bit field. Reserved for future use. Must be set to 0. Rcode - Response Code. 4-bit field that is set by the name server to identify the status of the query: 0 1 2 3 4 5 No error condition. Unable to interpret query due to format error. Unable to process due to server failure. Name in query does not exist. Type of query not supported. Query refused.

Question count - 16-bit field that defines the number of entries in the question section. Answer count - 16-bit field that defines the number of resource records in the answer section. Authority count - 16-bit field that defines the number of name server resource records in the authority section. Additional count - 16-bit field that defines the number of resource records in the additional records section.

Object Types
The domain name system can be used for translating a host name to an IP address or a domain name to mail exchanger. The domain name system can be used for arbitrary hierarchical names. One might store names of applications along with mapping to the names and addresses of vendors that offer such applications. The system accommodates a variety of mappings by including a type in each resource code.

A client must specify the type in its query. Servers specify the type in all resource records they return. Domain name system resource record types:

Type A CNAME

Meaning Host Address Canonical Name

Contents 32 bit IP address Canonical domain name for an alias Name of cpu and os information about mail box or mail list 16-bit preference and name of host that acts as mail exchanger for the domain Name of authoritative server for domain Domain name (symbolic link) Multiple fields that specify which parts of the naming hierarchy a server implements string of ASCII text

HINFO MINFO

CPU & OS Mailbox info

MX

Mail Exchanger

NS

Name Server

PTR SOA

Pointer Start of Authority

TXT

Arbitrary Text

Most of the data is of type A . The second most useful domain type ,MX, is assigned to names used for Email. For the mail address user@domain-part, the mail system uses the DNS to resolve domain-part with query type MX. For each MX resource record the mailer extracts the domain name and uses type A query.

Institute Of Technology psiot.net psiot.com mciot.net mciot.com siot.net Internetworking Training Tecnologies mcitt.net mcitt.com Technical Training Institute mctti.net mctti.com National Indian Tribal Gaming Association nitga.org nitga.com nitga.net Indian Tribal Gaming Association itga.us United Tribal Gaming Services utgs.net Unconfigured e-mailbox (1) Unconfigured e-mailbox (Set up now) September 25, 2004 aaaseptic.com Domain Add Add October 29, 2004

admiralcinemas.com Domain Add Add March 3, 2005 admiraltwintheater.com Domain Add Add March 3, 2005 admiraltwintheaters.com Domain Add Add March 3, 2005 arcadiadrilling.com Domain Add Add October 29, 2004 backportal.net Domain Add Add July 31, 2004

backportal.org Domain Add Add

July 31, 2004

bcplandscape.com Domain Add Add October 29, 2004 bhrrecoveryservices.com Domain Add Add October 29, 2004 bing-design.com Domain Add Add bing-designs.com Domain Add Add bingdesign.biz Domain Add Add bingdesigns.com Domain Add Add September 27, 2004 September 27, 2004 September 27, 2004 September 27, 2004

bingdesignstocarry.com Domain Add Add September 27, 2004 bingdesigntocarry.biz Domain Add Add September 27, 2004 bingdesigntocarry.com Domain Add Add September 27, 2004 bingsdesignstocarry.com Domain Add Add September 27, 2004 bingsdesigntocarry.com Domain Add Add September 27, 2004 bradleylouderback.com Domain Add Add October 29, 2004 bradylouderback.com Domain Add Add October 29, 2004 cabletechsystems.com Domain Add Add October 29, 2004 classic-carpentry.net Domain Add Add April 16, 2005 fmugs.com Domain Add Add fmugs.net Domain Add Add October 13, 2004 October 13, 2004

gatewayz.com

Domain

Add

Add

July 31, 2004 July 31, 2004 August 16, 2004 July 31, 2004 July 31, 2004 March 22, 2006

gatewayz.net Domain Add Add hackrack.net Domain Add Add holez.net Domain Add holez.org Domain Add Add Add

homelabs.net Domain Add Add

internet-gateway.com Domain Add Add July 31, 2005 ipowerwebhosting.net Domain Add Add August 16, 2004 kevinspc.net Domain Add Add August 16, 2004

lakecusmanrealty.com Domain Add Add October 29, 2004 little-creek.net Domain Add Add majikweb.net Domain Add Add mciot.com Domain Add Add September 5, 2006 August 16, 2004 December 21, 2004

Private Registration Registration December 21, 2004 mciot.net Domain Add Add December 21, 2004

Private Registration Registration December 21, 2004 mcisp.com Domain Add Add January 18, 2007

Private Registration Registration January 18, 2007 mcisp.net Domain Add Add October 6, 2006

mcitt.com Domain Add mcitt.net Domain Add mctti.com Domain Add mctti.net Domain Add

Add Add Add Add

October 26, 2004 October 26, 2004 October 26, 2004 October 26, 2004 October 29, 2004

miklethun.com Domain Add Add

networking-security.net Domain Add Add October 3, 2004 networkingsecurity.info Domain Add Add October 3, 2004 nitga.com Domain Add nitga.net Domain Add nitga.org Domain Add Add Add Add May 18, 2005 May 18, 2005 May 18, 2005 July 31, 2004 July 31, 2004 July 31, 2004 July 31, 2004 July 31, 2004 July 31, 2004 February 15, 2007 December 21, 2004

openportalz.com Domain Add Add openportalz.net Domain Add Add openportalz.org Domain Add Add portalsz.com Domain Add Add portalsz.net Domain Add Add portalz.org Domain Add Add prana.bz Domain Add psiot.com Domain Add Add Add

Private Registration

Registration psiot.net Domain Add

December 21, 2004 Add December 21, 2004

Private Registration Registration December 21, 2004 reqwest.us Domain Add Add July 31, 2004

rivercitiescinemas.com Domain Add Add February 28, 2006 routerslab.com Domain Add Add routerslab.net Domain Add Add October 3, 2004 October 3, 2004

sea-west-mortgage.com Domain Add Add October 3, 2004 sea-west-mortgages.com Domain Add Add October 3, 2004 seawestmortgage.com Domain Add Add September 27, 2004 seawestmortgages.com Domain Add Add October 3, 2004 secure-networking.net Domain Add Add October 3, 2004 securing-networks.com Domain Add Add October 3, 2004 securing-networks.net Domain Add Add October 3, 2004 securingnetwork.com Domain Add Add October 3, 2004 securingnetworks.info Domain Add Add October 3, 2004 sheltontechinstitute.com Domain Add Add October 26, 2004 sheltontechinstitute.net Domain Add Add October 26, 2004 sheltontechnicalinstitute.com Domain Add Add October 26, 2004

sheltontechnicalinstitute.net Domain Add Add October 26, 2004 siot.net Domain Add Add December 21, 2004

Private Registration Registration December 21, 2004 sneakerz.net Domain Add Add July 31, 2004

thedentalvillage.com Domain Add Add October 29, 2004 thehomelab.net Domain Add Add thehomelabs.com Domain Add Add thehomelabs.net Domain Add Add thehomepc.net Domain Add Add thispc.net Domain Add Add July 17, 2006 July 17, 2006 July 17, 2006 April 6, 2006 October 3, 2004 October 29, 2004

timberbowl.com Domain Add Add

toziershardware.com Domain Add Add October 29, 2004 unixsystemroot.com Domain Add Add August 16, 2004 utgs.net Domain Add Set up May 18, 2005

1 page Web site Web site Set up May 19, 2005 Private Registration Registration May 19, 2005 youcanhack.us Domain (1) Edit E-mail August 2, 2004

join@youcanhack.us (10MB) Edit September 25, 2004 5 page Web site

Web site

Edit

September 25, 2004