IT Oct. 8 Assignment: Reconnaissance: So first let's run traceroute from cs to bob: [glein@cs html]$ traceroute bob traceroute to bob.marlboro.edu (216.114.150.85), 30 hops max, 38 byte packets 1 MC3640 (10.1.2.1) 1.073 ms 1.073 ms 1.107 ms 2 192.168.1.2 (192.168.1.2) 13.224 ms 12.702 ms 12.853 ms 3 lr (216.114.150.1) 13.842 ms 13.583 ms 13.599 ms 4 bob (216.114.150.85) 14.344 ms 14.208 ms 14.600 ms We see three things between us and bob: MC3640, 192.168.1.2, and lr. Let's try something to the "outside world" now. [glein@cs html]$ traceroute mit.edu traceroute to mit.edu (18.7.22.69), 30 hops max, 38 byte packets 1 MC3640 (10.1.2.1) 1.033 ms 3.946 ms 1.854 ms 2 MC3620 (192.168.4.1) 1963.592 ms 660.825 ms 1129.935 ms 3 12.125.46.65 (12.125.46.65) 1162.397 ms 1159.541 ms 1003.005 ms ... ... ... So two hops to the outside world from cs. We see MC3640 again, but this time also MC3620. Interesting. So it would appear there are two "layers" separating the interior academic network at Marlboro College from the outside world. Let's take a look at bob now. I can't run traceroute on bob for some reason, but I can try from the outside world. [localhost:~] glein% traceroute bob.marlboro.edu traceroute to bob.marlboro.edu (216.114.150.85), 30 hops max, 40 byte packets ... ... ... 16 cisco0.wnskvtao.sover.net (207.136.212.233) 54.095 ms 55.224 ms 55.017 ms 17 mtc-gw.burl.sover.net (209.198.103.186) 60.035 ms 58.32 ms 60 ms 18 bob.marlboro.edu (216.114.150.85) 72.081 ms 59.876 ms 59.999 ms Isn't this interesting? I see nothing between sover.net and bob. That doesn't sound very safe to me... I know Matt said something about a "hidden" router (see Sept. 24 assignment), maybe this is it. Okay, let's draw an ascii picture. ********** ************** |(acad.) | | bob | | cs | | | ********** ************** | | | | MC3640 lr | < >---------------< >---- | (?) | |--< >--********* (?) | |Mather?| < > MC3620 ********* | < > | | | | | ****************************************** | | | Here there | | be monsters | | | ****************************************** Cs is on the academic network, and I know the administrative offices are on a separate part of the Marlboro network (damn), so they're probably past that first router but not the second. It probably has its own router as well. Lr and the "mystery router" may be one and the same, just different network interfaces. Or there could just be two there, we can't tell from this information. Ethereal: According to Ethereal, traceroute submits UDP packets, rather than TCP. I suppose that makes sense, since the headers are smaller, and we don't really care about setting up a connection. Interestingly, every packet sent out by the host is pointed towards one higher port than the last. Here are some ARP packets that were flying around at the same time: Frame 2 (64 bytes on wire, 64 bytes captured) Arrival Time: Nov 30, 2004 21:19:39.179197000 Time delta from previous packet: 0.223676000 seconds Time relative to first packet: 0.223676000 seconds Frame Number: 2 Packet Length: 64 bytes Capture Length: 64 bytes Ethernet II, Src: 00:0e:7b:33:97:0a, Dst: ff:ff:ff:ff:ff:ff Destination: ff:ff:ff:ff:ff:ff (Broadcast) Source: 00:0e:7b:33:97:0a (00:0e:7b:33:97:0a) Type: ARP (0x0806) Trailer: 00000000000000000000000000000000... Address Resolution Protocol (request) Hardware type: Ethernet (0x0001) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (0x0001) Sender MAC address: 00:0e:7b:33:97:0a (00:0e:7b:33:97:0a) Sender IP address: 10.1.4.172 (10.1.4.172) Target MAC address: 00:00:00:00:00:00 (00:00:00_00:00:00) Target IP address: mdhcp189.marlboro.edu (10.1.4.189) Frame 3 (64 bytes on wire, 64 bytes captured) Arrival Time: Nov 30, 2004 21:19:39.194051000 Time delta from previous packet: 0.014854000 seconds Time relative to first packet: 0.238530000 seconds Frame Number: 3 Packet Length: 64 bytes Capture Length: 64 bytes Ethernet II, Src: 00:05:02:ae:d6:0c, Dst: ff:ff:ff:ff:ff:ff Destination: ff:ff:ff:ff:ff:ff (Broadcast) Source: 00:05:02:ae:d6:0c (aquarium.local) Type: ARP (0x0806) Trailer: 55555555555555555555555555555555... Address Resolution Protocol (request) Hardware type: Ethernet (0x0001) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (0x0001) Sender MAC address: 00:05:02:ae:d6:0c (aquarium.local) Sender IP address: aquarium.local (10.1.5.45) Target MAC address: 00:00:00:00:00:00 (00:00:00_00:00:00) Target IP address: 10.1.1.7 (10.1.1.7) These are two ARP request packets (in full gory detail). As you can see, we have a query from 10.1.4.172 for 10.1.4.189 and a query from 10.1.5.45 for 10.1.1.7. An interesting note on this... I thought ARP packets were strictly a network frame operation (no IP addresses except that in the reply payload). I think the reason we can see this info is not because it's in the transmitted information but because there's an option in Ethereal to resolve MAC addresses. Ethereal isn't always clear *where* it's getting its information (probably because it assumes you already know). Here's a DHCP request packet: Frame 2236 (346 bytes on wire, 346 bytes captured) Ethernet II, Src: 00:30:65:01:d2:78, Dst: ff:ff:ff:ff:ff:ff Internet Protocol, Src Addr: 0.0.0.0 (0.0.0.0), Dst Addr: 255.255.255.255 (255.255.255.255) User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67) Bootstrap Protocol Message type: Boot Request (1) Hardware type: Ethernet Hardware address length: 6 Hops: 0 Transaction ID: 0x1bb556ed Seconds elapsed: 11 Bootp flags: 0x0000 (Unicast) Client IP address: 0.0.0.0 (0.0.0.0) Your (client) IP address: 0.0.0.0 (0.0.0.0) Next server IP address: 0.0.0.0 (0.0.0.0) Relay agent IP address: 0.0.0.0 (0.0.0.0) Client hardware address: 00:30:65:01:d2:78 Server host name not given Boot file name not given Magic cookie: (OK) Option 53: DHCP Message Type = DHCP Request Option 55: Parameter Request List Option 57: Maximum DHCP Message Size = 1500 Option 61: Client identifier Option 50: Requested IP Address = 10.1.5.123 Option 51: IP Address Lease Time = 90 days End Option Padding So we have a source address of 0.0.0.0, broadcasting on 255.255.255.255, as we'd expect. We have the interesting Option 50: Requested IP Address section. This means the host was probably on the network earlier and disconnected but remembered its own info (likely a laptop). This raises a security issue: Does Matt's NetReg system remember this info as well? Users don't have to go through the registration process *every* time they plug into a jack. So if NetReg keeps track of an IP address with an associated MAC address, then when this host jacks in again, it can know it's the same person. If not, I can wander on campus and just have my DHCP request specify an address (though if NetReg is just keeping track of recently used IP addresses, that already makes it harder). Abbott & Costello: 1. So Abbott checks the IP addresss to see "yes! Costello is on the LAN." Abbott checks his ARP cache. Blast. It's empty. So Abbott's network device sends out a broadcast ARP packet (MAC address FF:FF:FF:FF:FF:FF) to query "who has IP address 213.172.12.21?" Costello recieves this and says "oh, that's me." Because Costello already has Abbott's (or "Stranger A who wants my address") MAC address, he can send an ARP reply packet straight back to "Stranger A." Abbott gets this packet and adds Costello to his ARP cache with glee, and then sends along a data frame to his beloved companion. 2. Costello checks Abbott's IP address against his subnet mask. "Blast, who knows WHERE this bloke is." Poor Costello has no idea Abbott is just sitting there a cubicle away waiting for someone to send him a personalized ARP query. Not know who to call (Ghostbusters being out of town), he resorts to his default gateway (D.G.), 213.172.12.1. Costello checks his ARP cache again. Still empty. Desperately, he sends out a broadcast ARP query "who's 213.172.12.1??" D.G., the gender neutral gateway, recieves this and realizes "oh, that's me." Shortly afterward, Costello recieves D.G.'s ARP reply. Bam. D.G.'s in Costello's ARP cache. "Great," says Costello, "I don't know what to do with this IP packet for Abbott, so I will send it to D.G." He wraps it in a etwork frame (addressed to D.G.) and fires it off. D.G. gets this, sees its own MAC address and says "yay! A present!", unwraps the frame for the chewy IP center, and sees "oh, this is for 213.172.12.40." Now, in part I of our story, G.g. saw very little action and did even less. As far as it's concerned, some ARP packets and frames were flying around the network, but nothing directed to it until Costello's ARP query. Because Costello's query contained only his MAC address, D.G.'s ARP cache is still empty. So now G.D. makes an ARP query (since it knows 213.172.12.40 is on its LAN -- if not, things break down here). Abbott responds, D.G. is happy, adds Abbott to its ARP cache, rewraps Costello's IP packet in a network frame to Abbott and sends it off. Abbott recieves the frame, unpacks the IP packet, sends it on up the protocol stack, and finds a spam email for dirty pictures. Damn that Costello. 3. D.G. needs to have a subnet mask of 255.255.255.192 or less to have both Abbott and Costello on its LAN. Were it to have, for example, subnet 255.255.255.224, its LAN members would have to have the final IP byte (000-----). Since Abbott's last IP byte is (00101000), we can see straight off that he would be excluded due to that third bit, and D.G. couldn't talk to him directly (or in this case at all). 4. This is a poor configuration because every time Costello wants to send a packet to Abbott, it has to pass through the default gateway. This means wasting precious memory and CPU cycles on what could be a direct communication. If Abbott wants to watch streaming video on Costello's webserver, that's a *LOT* of D.G.'s time right there. If Costello just sets his subnet mask the same as Abbott's, D.G. is free to do something useful, and Abbott gets less lag in his movie.