IT Sept. 24 Assignment: Some MAC addresses: Since I have an airport (wireless 802.11b) network card in my computer, I have two MAC addresses right here. My ethernet card is: 00:03:93:19:4f:1a My wireless card is: 00:30:65:01:ce:c9 Jim's number conversion tool doesn't seem to like MAC addresses, because they are very big. This is of course the point, since we don't want to run out of MAC addresses. MAC addresses are six bits long, which means there are 2^48 possible numbers. The technical term for this is a real $&%!-load. This goes well into the trillions --far more than we need right now. The first byte in both of these addresses is zero, probably part of the range given to Apple to burn on their cards. But more interesting is that until we start networking our keys and socks, Apple probably won't have a problem with this '0' byte. Some IP addresses: Both of these addresses are "local" IP addresses (note the 10.1.*.*). This means that these packets wouldn't survive in the "wild" of the internet. I'm a little uncertain what would happen, were these frames to be released from a network, but I suspect that they would be dropped by most routers and firewalls. If they got *into* another network, they could cause some confusion, since one computer would probably think its buddy was talking to it. akbar: 10.1.2.5 Converted to base 10 is: 167_838_213 me: 10.1.5.108 Converted to base 10: 167_839_084 There's really not much more to be learned from converting these IP's to base 10. host: Host is pretty straightforward. It can be followed by either a URL (URI) or an IP address. With an URL, it just makes a DNS query and gets the respective IP address. With an IP(v4) address, it makes a "reverse DNS lookup" through the in-addr.arpa database. This can give multiple results, since many servers will have multiple servers or web addresses. For example: [localhost:~] gabe% host 64.4.33.7 7.33.4.64.in-addr.arpa domain name pointer hotmail.co.uk. 7.33.4.64.in-addr.arpa domain name pointer lc2.bay0.hotmail.com. So MSN has two servers running on this IP address. That's handy. traceroute: Traceroute attempts to trace the route (wow) from the localhost to a specified server. It does this by sending a small IP packet and modifying the TTL (time to live) field in the IP header. So the first packet has TTL of 1, gets sent off, and hits the first hop on its journey to serverX. This gateway decriments the TTL field and finds "uh oh, the TTL is now zero. I should drop this packet." If the gateway is nice, it will send an ICMP "time exceeded" packet back to the originating host informing them of the dropped packet and giving their IP address. Traceroute recieves this and captures the address portion. "Oh, it went here." It does this three times, reporting the round trip time for each. Traceroute then sends out a packet with TTL set to 2. So this time, the packet hits the first gateway, is decremented, and moves on to the second. Again, if that gateway is feeling helpful it will send back an ICMP packet. This continues until the packet either makes it all the way to the host or reaches a max hops (default 30, but can be set at runtime). If the packet reaches the destination host, that host sends back a "port unreachable" ICMP packet (again assuming the gateway is being helpful), which lets traceroute know it's arrived at the destined location. There are some concerns with traceroute. If a gateway along the route doesn't have ICMP packet sending on (a common security measure), traceroute will never recieve a response and will eventually time out. In this case, after the third attempt, traceroute just moves on. Another thing a gateway can do is to re-increment the TTL field and pass it along. So if router A recieves a packet with TTL=1, it will pass it to the next hop, still with TTL=1, and THAT gateway will respond. As far as the gateway and originating host are concerned, router A doesn't exist, which allows for good security for router A, but spotty results for the originating host. Finally, the internet is not a static system. It is possible (though usually fairly unlikely) for a packet to take two completely different routes in transit to the same destination. In this case, hop five on one run may end up in New Jersey, while the next time it may be in Iowa. Usually this doesn't happen, but it's worth running traceroute a few times if results look weird. Here's an example running traceroute from the Marlboro cs server: [glein@cs glein]$ traceroute www.ign.com traceroute to appscs.ign.com (216.35.123.121), 30 hops max, 38 byte packets 1 MC3640 (10.1.2.1) 1.041 ms 1.073 ms 0.982 ms 2 MC3620 (192.168.4.1) 961.059 ms 891.186 ms 714.795 ms 3 12.125.46.65 (12.125.46.65) 1093.946 ms 1247.237 ms 1453.740 ms 4 gbr1-a30s4.cb1ma.ip.att.net (12.123.40.78) 1339.920 ms 1012.974 ms 786.384 ms 5 tbr2-cl1.n54ny.ip.att.net (12.122.10.22) 1383.523 ms 984.882 ms 899.445 ms 6 ggr2-p3120.n54ny.ip.att.net (12.123.3.109) 934.672 ms 783.875 ms 853.726 ms 7 dcr1-so-3-0-0.newyork.savvis.net (192.205.32.198) 1674.850 ms 1311.226 ms 1524.815 ms 8 dcr1-loopback.SanFranciscosfo.savvis.net (206.24.210.99) 1157.538 ms 1287.591 ms 1266.973 ms 9 bhr1-pos-13-0.SantaClarasc5.savvis.net (208.172.147.110) 1228.621 ms 1434.376 ms 1774.932 ms 10 csr1-ve240.sc4.savvis.net (216.34.2.218) 1256.338 ms 1535.691 ms 993.639 ms 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * So the packet clearly makes it to San Francisco (which is good, since that's where ign.com is based). After the tenth hop however, traceroute wasn't getting any response. Were there just one or two lines of asterisks, we might expect these were just secure intermediary routers, but we can pretty safely say at this point that the packets arrived and the ign.com server itself isn't sending ICMP packets. nmap: Nmap scans ports on a host by sending out of order or otherwise incorrect TCP headers with the hopes of getting a response. While a "correct" connection attempt might be ignored by a listening port, the incorrect one can solicite a TCP reset message or other statement to the effect "hey, your info is screwy", which is of course all an attacker needs to know. Nmap is good enough for Trinity, so clearly it's good enough for me. Here's an example: [glein@cs glein]$ nmap akbar Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-11-25 14:56 EST Interesting ports on akbar.marlboro.edu (10.1.2.5): (The 1648 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 25/tcp open smtp 80/tcp open http 110/tcp open pop3 139/tcp open netbios-ssn 143/tcp open imap 548/tcp open afpovertcp 993/tcp open imaps 995/tcp open pop3s So lots of interesting stuff open here. We have smtp, pop3 and secure pop3 and imap, all email protocols, http, file sharing, secure shell, telnet, netbios (a windows security thing I don't really know much about), and whatever afpovertcp is (Apple filesharing thing maybe?). So there are certainly plenty of attack options. Telnet and smtp suggest (and we know, don't we?) that email spoofing is possible, so now I can write a script sending thousands of telnet emails claiming to be a Nigerian diplomat. nc: Netcat's creators describe it as the network swiss army knife or some such thing. You can use it to listen on or talk over any designated port. For example, if I type nc -vlp 9541 and then point my browser at http://cs.marlboro.edu:9541, I get this message at the command line: connect to [10.1.2.19] from cs.marlboro.edu [10.1.2.19] 41020 GET / HTTP/1.1 Host: cs:9541 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cache-Control: max-age=0 Hey! That's an HTTP request! Then I can type HTTP/1.1 hello there, wonder boy. And voila, the text appears in my browser. Thus we can run a poor man's web browser, or even a poor man's chat client if both sides use Netcat.