Detecting on IP taps

Are you absolutely sure that this mysterious box isn't your cable modem? Quite a few cable modems have their own IP address, and a lot of cable companies use the private address space for thier internal routers and cable modems to simplify matters. They just set up a DHCP server, the cable modem asks for an IP address and they assign it an IP from the 10 subnet so they don't have to waste a valid IP address on a simple cable modem. Then as long as their internal routers know where to route the packets, they're ok. So maybe your cable company just changed their internal network architecture. Give it a thought.

Ummmm... guys?!?!?

Many ISPs use private addressing for their serial lines between the routers in their core infrastructure so that they can save the IPs they have FOR YOUR USE. There's no reason that anyone outside of their infrastructure ever needs to talk to one of their routers directly, so it's much more secure and signs of a much better and well-planned infrastructure if your ISP actually uses these.

It is not necessarily a sign of a wire tap

Most taps, on the other hand, are passive. That is, they sit on a segment with the transmit leads clipped and looped back so that there is no way in hell that you can see them from the monitored side of the connection.

Quote:

---

Most taps, on the other hand, are passive. That is, they sit on a segment with the transmit leads clipped and looped back so that there is no way in hell that you can see them from the monitored side of the connection.

---

While it used to be possible to clip wires and still listen to traffic, with the advent of ethernet it is no longer possible. This is due to a feature in networking known as a heartbeat (not the technical term). If you clip the transmit wires between a computer that you're trying to listen with and a hub, the hub no longer hears the heartbeat from the ethernet card and assumes that the machine is off. So the link is lost, the link light turns off and the hub no longer transmits data down that wire. Trust me, I've tried. The only way to do this is to either set up a passive interface on the computer (i.e. no IP address) or buy a device known as a network tap that generates the heartbeat for you and allows your computer to still listen in on the traffic passing through the hub.

Quote:

---

Originally posted here by str34m3r

While it used to be possible to clip wires and still listen to traffic, with the advent of ethernet it is no longer possible. This is due to a feature in networking known as a heartbeat (not the technical term). If you clip the transmit wires between a computer that you're trying to listen with and a hub, the hub no longer hears the heartbeat from the ethernet card and assumes that the machine is off.

---

Hence the need for a loopback, as I indicated (albeit rather tersely).

Have you tried this and found it to work? If so, I need to know what kind of hub/switch you're using and buy some. Becuase I worked on this exact problem for two days and never found any solution except the ethernet taps. I tried several different configurations of wires (including looping back some of the wires) and several different hubs and switches. The best I ever got was one hub that let me sniff for about 15 seconds before the loopback was too much for it and it locked up totally. Now I've never seen a hub lock up before, but I guess it got very confused and just started blocking all traffic. I'm certain that if there was a way to connect a monitor to the hub, there would have been a blue screen of death. :)

The loopback is done in such a way as to provide voltage, but not much more... I'll see if I can grab the pinout for you, if you like. (But yes, I've used it - it's my preferred method for running network IDS boxes as it tends to help prevent people from "seeing" them and trying to get around them).

The second means of course, as I think has already been said, is to mirror a port on a switch and listen that way... ISS supports putting interfaces in "stealth mode," but personally I don't trust it (ISS also tends to be one of the last choices for me for IDS boxes, etc). Mirroring can also be kind of "expensive" on a busy switch and can lead to serious problems/issues, so I'd personally not recommend it.

I thank everyone for their input and inquiries. I use VisualRoute Trace all the time; I know what is normal between me and my ISP's servers. As I said it normally reads xxx.xxx.xxx.xxx as my computer and then immediately following that is the ISP's server at yyy.yyy.yyy.yyy and over the weekend between the two systems apeared 10.228.200.1 which does not respond to ftp/http/telnet or id requests.

It is not my cable modem, or I would have seen it for the past year or so. It is not used by my broadband ISP, and it is BEFORE their servers not in/after... ok, so it COULD be IN the server, but then why would it show seperately?

I agree, taps are NORMALLY passive. This one is... unless you trace routes like I do on a regular basis and know when something is not right in the trace.

An internal change of routing by the ISP... sounds possible, but you would think THEY would know. What gets me is others can hit the IP this thing sets at, and it comes up right where I see it, but my provider "does not see anything at that address between us and your computer, but we also don't see your computer. Are you running a firewall?". Not the brightest bulbs in the package, but they should be able to see the 10 IP like my friends do when they trace to me.

str34m3r, love your phrase "Paranoia is the only sane approach. In this business, you would be crazy not to be paranoid." but don't forget... Just because you are paranoid does not mean they are not out to get you. :)

It might be interesting to see how many hops (TTL diffs) the guys at your ISP get if they ping you. If the "conspiracy theory" is true, I would bet the eavesdropper is filtering connections from the ISP "managment" (techs and admins computers) so his box doesn't show up to them.
However I doubt he would have hacked the kernel to not decrease the TTL values from ip packets. Thus inspecting TTLs from packets comming from the ISP could reveal the attacker's presence to the ISP techs.

I gotta say though that the eavesdropper theory sounds unprobable to me, but if you say that your ISP knows noting of such an host on their network I'd probably get suspicious too...

Ammo

Also, you might want to try some nmap scans* on the rogue host to gather more information...

*Check your ISP's AUP first!

Ammo

Quote:

---

Originally posted here by Airwolf
I thank everyone for their input and inquiries. I use VisualRoute Trace all the time; I know what is normal between me and my ISP's servers. As I said it normally reads xxx.xxx.xxx.xxx as my computer and then immediately following that is the ISP's server at yyy.yyy.yyy.yyy and over the weekend between the two systems apeared 10.228.200.1 which does not respond to ftp/http/telnet or id requests.

---

Of course, no one ever changes the structure of their networks, let alone the addresses. Particularly during weekend maintenance hours.

And, as you said, 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/24 are "reserved network address space." Specifically, these are addressed/outlined in RFC1918 and are used "for networks not connected to the Internet." What this /really/ means is that they're not meant for anything that connects directly - when was the last time you got on a router's serial port to browse the web or anything? And again, most ISPs block these addresses as a matter of principle at the very point in which they become moot. So, you pinging the thing is going to go one hop beyond your router/modem and STOP (ie. bit-bucket); try tracerouting to them... chances are it's not going to go anywhere.

Just because something doesn't respond doesn't mean it's "a tap." And, just because you can't ping something doesn't mean the server's down. I know it's a tough concept, but trust me here. Try pinging www.antionline.com, too, and set off some of JP's alarms for him... chances are you're going to get back ICMP DEST Unreachables (which are completely optionable - most BofHs just trash annoying things like that rather than creating additional network traffic with a reply of any sort). <edit>So, tell me... you can't ping or "id" www.antionline.com but, well, how are you reading this message then?</edit>

Quote:

---

It is not my cable modem, or I would have seen it for the past year or so. It is not used by my broadband ISP, and it is BEFORE their servers not in/after... ok, so it COULD be IN the server, but then why would it show seperately?

---

You were right the first time... they're part of the trace/path. What you are seeing is the source of the packet in the ICMP ECHO-REPLY header. For all intents and purposes, it's meaningless (and intentionally makes it more difficult for you to figure out the path your packet is taking through their systems).

Quote:

---

I agree, taps are NORMALLY passive. This one is... unless you trace routes like I do on a regular basis and know when something is not right in the trace.

---

With the advent of dynamic routing, packets sent side-by-side don't always take the same path, particularly through large networks. That is, two consecutive pieces of a transmission, in theory, can possibly be transmitted through completely separate parts of a network.

Quote:

---

An internal change of routing by the ISP... sounds possible, but you would think THEY would know. What gets me is others can hit the IP this thing sets at, and it comes up right where I see it, but my provider "does not see anything at that address between us and your computer, but we also don't see your computer. Are you running a firewall?". Not the brightest bulbs in the package, but they should be able to see the 10 IP like my friends do when they trace to me.

---

Most helpdesk people are simply following procedures, and not well at that... invariably, anyone you can talk to doesn't know squat about tcp/ip, except it's this "network thingy." Having worked for a global ISP before, I can tell you that the trend is that anyone that shows promise on being able to troubleshoot things like network issues tends to find themselves not on the phone talking to people but in baseline NOC or higher up (possibly a junior engineer), helping to troubleshoot and fix the problems that the clueballs down on the phone are coached enough to filter on when it gets deeper than their "bullsh*t level." (ie. they talk to people so the people who actually know something can do something worthwhile)

One of my favorite quotes taken from a call to tech support that I made: "Well, traceroute to it and you'll see that it's a line problem." Of course, he didn't understand me telling him that my firewall dropped all spurious UDP.