BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


IP Packets Revealed
Pages: 1, 2, 3

You'll remember from last week that when I demonstrated the telnet session, several bits of information were displayed on my screen. Those bits of information came from the telnet application on 10.0.0.1 and we can use the tcpshow utility to see it being sent in the data fields of the following packets:



-------------------------------------------------------------
Packet 28
TIME: 10:25:37.040099 (0.000144)
LINK: 00:50:BA:DE:36:33 -> 00:00:B4:3C:56:40 type=IP
  IP: 10.0.0.1 -> 10.0.0.2 hlen=20 TOS=10 dgramlen=90 id=955C
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=912F
 TCP: port telnet -> blackjack seq=1746119733 ack=3205630343
      hlen=20 (data=50) UAPRSF=011000 wnd=17520 cksum=2DFE urg=0
DATA: ...
      FreeBSD/i386 (istar.ca) (ttyp0)...
      ...
      login: 
-------------------------------------------------------------
Packet 51
TIME: 10:25:39.140175 (0.012092)
LINK: 00:50:BA:DE:36:33 -> 00:00:B4:3C:56:40 type=IP
  IP: 10.0.0.1 -> 10.0.0.2 hlen=20 TOS=10 dgramlen=51 id=9564
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=914E
 TCP: port telnet -> blackjack seq=1746119790 ack=3205630352
      hlen=20 (data=11) UAPRSF=011000 wnd=17520 cksum=815F urg=0
DATA: .
    Password:
-------------------------------------------------------------
Packet 66
TIME: 10:25:41.680125 (0.020455)
LINK: 00:50:BA:DE:36:33 -> 00:00:B4:3C:56:40 type=IP
  IP: 10.0.0.1 -> 10.0.0.2 hlen=20 TOS=10 dgramlen=150 id=956B
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=90E4
 TCP: port telnet -> blackjack seq=1746119801 ack=3205630360
      hlen=20 (data=110) UAPRSF=011000 wnd=17520 cksum=AE21 urg=0
DATA: .
    Warning: your password expires on Thu Mar  8 17:31:47 2001.
    Last login: Sun Mar  4 10:23:04 from 127.0.0.1.
	
-------------------------------------------------------------
Packet 68
TIME: 10:25:41.779159 (0.000175)
LINK: 00:50:BA:DE:36:33 -> 00:00:B4:3C:56:40 type=IP
  IP: 10.0.0.1 -> 10.0.0.2 hlen=20 TOS=10 dgramlen=283 id=956C
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=905E
 TCP: port telnet -> blackjack seq=1746119911 ack=3205630360
      hlen=20 (data=243) UAPRSF=011000 wnd=17520 cksum=30D1 urg=0
DATA: Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
    .
    The Regents of the University of California.  All rights re
    served..
    .
    FreeBSD 4.2-RELEASE (SOUND) #0: Tue Dec 12 20:01:29 EST 2000
    .
    .
                Welcome to FreeBSD 4.2!!!.
    You have mail..
	
-------------------------------------------------------------
Packet 70
TIME: 10:25:41.879117 (0.000163)
LINK: 00:50:BA:DE:36:33 -> 00:00:B4:3C:56:40 type=IP
  IP: 10.0.0.1 -> 10.0.0.2 hlen=20 TOS=10 dgramlen=237 id=956D
      MF/DF=0/1 frag=0 TTL=64 proto=TCP cksum=908B
 TCP: port telnet -> blackjack seq=1746120154 ack=3205630360
      hlen=20 (data=197) UAPRSF=011000 wnd=17520 cksum=DDC6 urg=0
DATA: .
    Everybody is somebody else's weirdo..
            -- Dykstra.
    .[1mgenisis@~.[m: 
-------------------------------------------------------------

You may have noticed there were many packets that I snipped out between Packet 28, which echoed the login prompt; and Packet 51, wwhich echoed the password prompt. These packets required sending the login name of "genisis" one character at a time. Again, each of these characters needed to be individually acknowledged and echoed to my screen.

The packets between Packet 51 and Packet 66 contained my password -- again sent one character at a time. These packets were acknowledged but the characters were not echoed to my terminal. This is one of the reasons why you don't run a tcpdump on someone else's network. If someone happens to login over the network, you will be able to capture and view the packets which contain the login and password prompts followed by the user's login name and password. At that point, it won't matter how good the password policy is on that network.

Finally, Packets 66, 68, and 70 showed the rest of the data from the telnet application that was echoed to my terminal during the session.

Also in FreeBSD Basics:

Fun with Xorg

Sharing Internet Connections

Building a Desktop Firewall

Using DesktopBSD

Using PC-BSD

So far, we've only examined the packets that contained TCP headers. However, TCP was not the only protocol involved during this telnet session; the protocols ARP and ICMP also played a role.

Let's start with ARP or the Address Resolution Protocol. We've learned that before we can send an IP packet, it must first be encapsulated into a frame, in our case, an Ethernet frame. To create an Ethernet frame, the MAC (Media Access Control) address of the destination NIC must first be determined. A special packet known as an ARP packet is used to determine this MAC address. Since ARP knows the IP address of the destination, it can send out a broadcast packet, meaning all nodes must read the packet, asking for the MAC address associated with that IP address. Running tcpdump with the r switch summarizes this procedure nicely:

tcpdump -r dump
<snip output to just show packets 2 and 3>

10:25:28.608173 arp who-has 10.0.0.1 tell 10.0.0.2
10:25:28.608285 arp reply 10.0.0.1 is-at 0:50:ba:de:36:33

Because 10.0.0.2 wished to initiate a TCP connection with 10.0.0.1, it sent out an ARP request asking who was using that IP address. You'll notice that it received a reply that included the MAC address associated with 10.0.0.1.

Let's look at a more detailed view of these two packets using tcpshow:

tcpshow < dump
<snip to just show packets 2 and 3>

-------------------------------------------------------------
Packet 2
TIME:	10:25:28.608173 (4.305875)
LINK:	00:00:B4:3C:56:40 -> FF:FF:FF:FF:FF:FF type=ARP
ARP:	htype=Ethernet ptype=IP hlen=6 plen=4 op=request
	sender-MAC-addr=00:00:B4:3C:56:40 sender-IP-address=10.0.0.2
	target-MAC-addr=00:00:00:00:00:00 target-IP-address=10.0.0.1
-------------------------------------------------------------
Packet 3
TIME:	10:25:28.608285 (0.000112)
LINK:	00:50:BA:DE:36:33 -> 00:00:B4:3C:56:40 type=ARP
ARP:	htype=Ethernet ptype=IP hlen=6 plen=4 op=response
	sender-MAC-addr=00:50:BA:DE:36:33 sender-IP-address=10.0.0.1
	target-MAC-addr=00:00:B4:3C:56:40 target-IP-address=10.0.0.2
-------------------------------------------------------------

Notice the MAC addresses used in the LINK section of Packet 2. The source address is the MAC address of 10.0.0.2. This is needed so the response can make it back to the correct NIC. Since 10.0.0.2 does not know the MAC address of 10.0.0.1 (finding that MAC address is the whole point of this ARP packet), it uses a MAC address of FF:FF:FF:FF:FF:FF. A MAC address of all Fs indicates a broadcast packet, meaning all NICs must process the packet, but only the NIC the data pertains to should respond.

Also note that an ARP packet is different than an IP packet. It only contains one header and no data. There is a diagram of an ARP packet here.

The hardware type (htype) indicates this ARP request is looking for an Ethernet hardware address, that is, a MAC address. The protocol type (ptype) indicates the protocol address in use is an IP address. The operation (op) field indicates this is an ARP request. It then contains the known MAC and IP addresses. Because the target MAC address is the unknown value, it has been set to all zeros.

Packet 3 contains the response to Packet 2. Its op field indicates that it is a response, and it contains all of the necessary MAC addresses.

Let's wait until next week to see what role ICMP played in our telnet session as the ICMP protocol deserves an article of its own.

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.


Read more FreeBSD Basics columns.

Return to the BSD DevCenter.





Sponsored by: