Detecting NAT devices!!!

Hello everyone,

once again i was in a chat room with a couple of buddies, and one of em mentioned something that i really would like to share with you people here.

Quote:

---

Unauthorized NAT (Network Address Translation) devices can be a significant security problem. Typically the NAT device will appear to the network administrator as an end host and it will authenticate itself onto the network. However, the NAT device provides unrestricted access to any number of hosts connecting to it directly, or more troublingly via wireless (Wi-Fi 802.11). Wi-Fi is a particular problem since it allows access to the network from a considerable distance, allowing unauthorized access without even entering the building.

---

I really recomend that you take a look at the full source which can be found HERE!

There is also a possible work around mentioned on the site.

Cheers.

I know, its crazy, isn't it?

Check out this paper too.

http://www.research.att.com/~smb/papers/fnat.pdf

Quote:

---

Typically the NAT device will appear to the network administrator as an end host

---

Yes, this is correct, however, a skilled admin/security professional can spot these pests by examining open ports on the device and on occasion, the hostname that it reports. Typically, they look to be routers or print servers that have the standard ports 21,80 and 23 open. This method isn't fool proof but it is effective none the less.

Also, Nessus can find Wifi access points pretty easily. It basically tries to do an OS fingerprint which as you know can be problematic at times.

Isn't networking fun?
:)

--TH13

yaaaaaaaaaaa.....fun

Horse: I'm pretty sure that a sophisticated user would be able to use the functions of the device to MAC spoof and provide a valid FQDN. Then by carefully forwarding the appropriate ports to an internal machine and blocking others they could make it very difficult indeed to determine that anything other than a PC is sat there. Certainly, an admin with a substantial amount of PC's on a network would not have time to check his network in that way.

Tiger,

Yep, welcome to my nightmare :)

We have a few methods to ferret out devices like this but like I always say, network security is like a sun roof on a Yugo, eventually there's gonna be a leak! ;)

Horse:

Intimidation is the key my friend..... There isn't a user in the 650 on my network that would dare to try to pop a wireless or other device on my network...... See, they are quite confident I _will_ find it and they are even more confident that we will be discussing it - well, ok.... discussion may not be the right word...... It's more of a monologue and they don't get to say much....... ;)

Well the word is out at our place too. We have 10k users and every once in a while one of them will get sneaky and try to throw a wifi device up but we *always* catch them :)

Remember scooby doo? "We would have gotten away with it if it wasn't for those damn kids."

LOL!!!

Anyway, that's usually the reaction we get.

This paper is quite interesting.

I would just suggest that a traceroute achieves the NAT device detection as well(provided NAT device decrements the TTL).
Windows default TTL = 128
LINUX & BSD = 64 & so on.
But the technique would not work if hosts TTL default value were changed.

An another point, what if hosts are behind a multi proxy server (FTP, HTTP, ...)?
On AO site, in thread profiles on left precise if a proxy had been detected or not! Does anyone knows?

Networker: Using the TTL doesn't work I'm afraid. At least it doesn't work against a linksys 'cos i tried it a week or so ago. It seems that the linksys rebuilds the packet ans provides a new TTL itself. Thus the linksys seems to be the originating machine.

OTOH there is a way that just jumped into my head but I haven't had, nor will I have for a few days, the time to set up the details. It assumes that the nasty has not used MAC address spoofing. Place a Snort box in each collision domain with rules to alert on the MAC address octals pointing to the manufacturer's Linksys, Netgear etc. Then, when the little bugger throws up his WAP he gets a "WHAP" upside the head from you because the Snort box will send you a nice little email..... ;) .

It would work with semi-literate "ab"users and you could never tell them what triggers the "WHAP".......

Since we're on the topic, you gotta check out this article. Beward of the Rogue Nodes , : )~.

Tiger:

Quote:

---

Networker: Using the TTL doesn't work I'm afraid. At least it doesn't work against a linksys 'cos i tried it a week or so ago. It seems that the linksys rebuilds the packet ans provides a new TTL itself. Thus the linksys seems to be the originating machine.

---

Yeah u'r write, that restriction had been pointed in the paper linked by instronics & that's what Imeant by saying "(provided NAT device decrements the TTL)."

What I meant, in my previous post, is just that the sflow tool do nothing more that a simple traceroute (except maybe a log utility).