| 4405 | Jul 11 | 2003 | ||
| 20 | Aug 28 | 2005 | ||
| 29 | Aug 28 | 2005 | ||
| 32 | Aug 28 | 2005 | ||
| 848 | Jul 11 | 2003 |
Lets say I have a class C 17.18.19.0/24, some of which might have rogue connections to the Internet, and may be set up for ICS (MS Win) or masquerading (Linux; I wouldn't make the assumption that only MS systems are rogue). I use a Linux/*nix machine on that network (say 17.18.19.4) to probe each of the other machines and see if there's a live connection. First, I need a machine on the Internet (say, 66.59.109.137) that can watch for incoming packets. I run: tcpdump -qtnX 'icmp[0]=8' on the monitoring machine on the Internet. On the probe machine (.4) run the routeprobe script at http://www.stearns.org/routeprobe/ . This does nothing but send a ping packet to 66.59.109.137 with the gateway for that machine set to each of the local IP's in turn. The contents of the ping packet hold the original IP address, so you can tell who's routing. Here's a sample run. I run this on the local probe box after starting the tcpdump on the monitor box (in this case, 66.59.109.137): [wstearns@sparrow doc]$ /usr/src/routeprobe/routeprobe 172.27.1 1 3 66.59.109.137 Probing 1 Probing 2 Probing 3 [wstearns@sparrow doc]$ On the monitor box, I get the following: 216.177.24.101 > 66.59.109.137: icmp: echo request (DF) 0x0000 4500 0054 0000 4000 2c01 adce d8b1 1865 E..T..@.,......e 0x0010 423b 6d89 0800 f3f3 675e 0100 b82a 0f3f B;m.....g^...*.? 0x0020 d32b 0100 0001 0001 0001 0001 0001 0001 .+.............. 0x0030 0001 0001 0001 0001 0001 0001 0001 0001 ................ 0x0040 0001 0001 0001 0001 0001 0001 0001 0001 ................ 0x0050 0001 .. 216.177.24.101 > 66.59.109.137: icmp: echo request (DF) 0x0000 4500 0054 0000 4000 2c01 adce d8b1 1865 E..T..@.,......e 0x0010 423b 6d89 0800 91ed 675e 0200 b92a 0f3f B;m.....g^...*.? 0x0020 3332 0100 0001 0001 0001 0001 0001 0001 32.............. 0x0030 0001 0001 0001 0001 0001 0001 0001 0001 ................ 0x0040 0001 0001 0001 0001 0001 0001 0001 0001 ................ 0x0050 0001 .. 216.177.24.101 > 66.59.109.137: icmp: echo request (DF) 0x0000 4500 0054 0000 4000 2c01 adce d8b1 1865 E..T..@.,......e 0x0010 423b 6d89 0800 c3e9 675e 0300 ba2a 0f3f B;m.....g^...*.? 0x0020 ff35 0100 0001 0001 0001 0001 0001 0001 .5.............. 0x0030 0001 0001 0001 0001 0001 0001 0001 0001 ................ 0x0040 0001 0001 0001 0001 0001 0001 0001 0001 ................ 0x0050 0001 .. First off, the "0001"'s in the packet mean that the machine with the last octet of "1" (172.27.1.1) was the machine that was able to route packets. Makes sense, as that's my masquerading router. Note we didn't get any packets with 0002 or 0003; if we had, that would imply that one or both _also_ had ICS/masq running. How do we tell where 172.27.1.1 is getting its connectivity? Easy; the souce IP address of the ping packet. In the above example, the packets came from 216.177.24.101, so the box I see as 172.27.1.1 is masquerading for me and it uses an external IP address of 216.177.24.101. Note that this will identify IP capable boxes that have ip forwarding turned on. As a general rule, that's ics/masq boxes and routers with legal addresses, but that doesn't _have_ to be the case. If I turn on IP forwarding on a normal host with nothing but a single network card and IP address that uses the stock router to get out, I should see packets for that host in the tcpdump output above, with a source address of the normal router and that host's last octet embedded in the packet payload. This isn't anywhere near as big a security risk as a machine with its own line to the Internet, but it's still worth asking the owner why forwarding is turned on. If the rogue host in question has firewalling turned on to block me, or block icmp outbound pings, or can't handle masquerading pings, or has ip forwarding turned off, this won't work. If the probe workstation has a legal IP and the rogue router in question is sending IP packets _without_ doing masquerading/connection sharing, the packets will still arrive at the monitor box and will still have the rogue router octet embedded, but will have the original probe box's IP as the source address.
The files in this collection are part of William Stearns' software archive. If any of the links on this page do not work, you may be viewing an incomplete mirror. There is a complete list of the mirror sites at the starting page for this mirror and at the primary mirror.