How many Star Trek classic fans are in the house? Man, I just love that show. I honestly believe that is was Star Trek that generated my interest in engineering and of course kept me from getting dates until college, but that's a story for my therapist. There is an episode called "The Corbomite Maneuver," where the intergalactic King of Cool Captain Kirk bluffs a goober alien into thinking he has a heavy duty bomb onboard and the alien backs off. Then he, Spock and Scotty drink a case of Newcastle and ash out a Cohiba. OK, I am kidding about that part; Spock wasn't there.
Sometimes I feel that when we learn security, NAT/PAT is the Corbomite Maneuver of networking. It seems logical that NAT should be a safety net since my users are on RFC 1918 non-Internet-routable IP addresses front-ended by a single routable one. Logic breaks down where news headlines begin. Many, many networks are still being hacked every day. How are the hackers getting around NAT? How are they breaking this rule? Well, the truth is they are not breaking it, as much as they are going around it via one of two ways:
- Compromise an internal host
- Exploit a vulnerability in the firewall to compromise trust
The old-school method of getting an internal host was via email and load a netcat shell so that I can reverse-telnet back thru a firewall (via port 80) to my machine. I am seeing a newer method now called reverse proxy tunneling, which is taking over ground from the traditional IRC bots. Most bot coders have avoided a SOCKS type of proxy since NAT would prevent an inbound request and the code base is much too fat.
Reverse-connect proxies are taking advantage of a couple of things that many network admins do:
- Do not filter egress traffic
- Do not look for well-known ports. (Sockets below 1024)
A Port 666 reverse-connect proxy gets its name from the custom hex string 0x029a which in ASCII is 666. This piece of code actually uses some of the concepts from SOCKSv5 to form a huge global network for (at least now) spamming folks to death. SOCKSv5 has the advantage of being overlooked by many IDS/IPS systems. Typically how this gets thru your NAT filter is like this:
- A proxy bot is installed on your machine. Methods like Java exploits, Flash overflows, iFramers, etc.
- The bot starts to contact back to the host command-and-control server via 80 or if it is blocked it starts port walking to find an open port 8088,25,23, etc.
- Once connected that machine is under the control of the bot herder and it is a reverse proxy. 0wn3d
It is that easy and that quick. Port 666 proxy bots are designed to look like legitimate traffic on your network and truthfully, can be hard to track down. I am a huge Snort user and believer on my networks. If you have a Snort server there is a good rule set called: ?unusual-client-port-connection? that works good for Port 666 detection.
If you have a Cisco network then are two great options for detecting this threat:
- Netflow: This is fantastic telemetry data to monitor the flow of traffic and detect an anomaly or even just feed it straight into a CS-MARS box
- Flexible Packet Matching: This is one of the best security features in Cisco products that I just completed a detailed WebEx workshop on. (replay available) FPM is the next-gen Access Control List that can look so deep into a packet that we can look for offset 0x029a and drop this on the spot.
Keep in mind that NAT is just another tool on your network to secure it. It is not bulletproof to hackers but only a speedbump on the road to stealing your data. Plus, know when any vendor is trying to pull the Corbomite Maneuver on you when it comes to security!
Jimmy Ray Purser
Trivia File Transfer Protocol
Biblical speaking, the number 666 is considered the mark of the beast. However, in the oldest copies of the book of Revelation the number is actually 616.
Jimmy Ray Purser is the technical co-host for Cisco's TechWise and BizWise TV. Jimmy Ray also conducts advanced training for engineers across North America and Europe and regularly speaks at industry conferences such as VON, CeBIT, N+I, and Networkers. As a field engineer, Jimmy Ray experiences networking first hand behind the console or in the rack. He is an active member in the IEEE and the Ethernet Alliance and has designed, installed and tested numerous networks for Fortune 500 companies, the United States military and other institutions worldwide. He holds 3 U.S. patents for Ethernet security algorithms with two others pending and one defensive publication, as well as numerous other vendor certifications in networking and security.
Purser holds a Bachelor of Science degree in electrical engineering from Southern Illinois University is currently pursuing a master of science degree in electrical engineering.
The Leader in Network Knowledge
NAT is far from a security tool
IMO, nat just translates Private IP to a Public IP, doesnt not protect anything.
In fact, say you have 192.168.1.0/24 INSIDE and 213.1.1.1/32 OUTSIDE, if your service provider decides to put a static route as such to you :"ip route 192.168.1.0 255.255.255.0 213.1.1.1" you bet you have all your INSIDE network exposed for good.
Of course a firewall should solve it if you deny ANY to 192.168.1.0/24 from the OUTSIDE.
The comment about a Service
The comment about a Service Provider advertising a static route to the "INSIDE" private RFC address displays ignorance of internet routing protocols. That might work in the RIP section of your CCNA labs, but no ISPs accept paths in BGP for those private RFC-reserved networks.
I do agree completely that NAT is not a security measure.
Comment about the comment
Correction: no RESPECTABLE ISP accepts paths in BGP for those private RFC-reserved networks. That fails to account for those ISPs with less than favorable reputations, nor a rogue individual working for the ISP that bypasses their protocols to earn a little on the side. Rule #1 for any security manager: If it can be done, someone's going to do it.
Yes you will see providers
Yes you will see providers from time to time advertise bogus IPs and AS numbers. Link provided with proof that Public ISPs accidently slip private AS #s and RFC 1918 subnets into the Internet routing tables out on the internet. Prime example is: 10.221.3.149/32, being routed by AS 1267. Infact 1267 is RIPE! If you read this post please do us all a favor and stop advertising 10.x ips out to the internet....
http://bgpmon.net/showbogons.php?inet=4&global=yes&private=yes
If you are setup with BGP to an ISP, ensure you filter RFC1918 Ip subnets, and reject them! And if you wouldn't mine calling your ISP to make sure their aware to stop advertising them too that would be nice for the rest of us.
Also note, IPv6 boguns being routed on the same link. 2001:/48 come on people stop advertising the stupid routes!
-Adam
SP AND NAT
For your information BGP takes static routes.
If a static route is introduced in a PE by someone with bad intentions, the PE can route straight away to the INSIDE network of the customer. OF course won't leak to the internet due to the fact most ISP's drop private IP's.
I also seen customers sending us access-lists full of private hits in their external access-lists from Private IP's.
Theres a lot of EDUCATION university's providing BGP with staff that dont fully know how to configure or design stuff. (NAT is not any type of security).
Another brilliant thing is that when Im in the hphone with major ISP's like Sprint or Cable and wireless, I am speaking of Local-pref or origin and they have no clue of what is it funny ha?
First get your CCIE then talk to me kiddo...
Fully agree with the above
Fully agree with the above commentuhi
Not Applicable
Actually if your ISP put a static route of 192.168.1.x/24 to your registered IANA address, which in this case you have as 213.1.1.1, then nothing would happen, other than perhaps the guy who entered this route statement might need to update his resume.
192.168.1.0/24 is a non routable address on the world wide web, and is reserved for private networks (See RFC 1918). Any attempts to route to this private reserved address block from the World Wide Web would be unsuccessful.
As for what NAT does, NAT actually allows you to use RFC 1918 addresses on your internal hosts and still have access to and from the World Wide Web without having to expose the hosts directly. The Nat device, whether a firewall, router or proxy server sometimes referred to as a "bastion host", accepts connections on behalf of the internal server. The bastion host translates the IP and sends a new packet onto the local area network and on to your system. This is important, particularly in denial of service type attacks, where the NIC itself can be overloaded. A decent firewall (such as a Cisco PIX\ASA or ISA server) capable of shunning denial of service attacks means your servers NIC is not overloaded responding to these attacks, such as a SYN flood for example.
Hope this helps.
RouteRanger
Kiddo, what about u read the
Kiddo, what about u read the post????
Nothing would happen just like you said period.
I said that the PE (directly router connected router to the customer) would be able to route to the Private Network. I will make you a draw maybe you need.
Customer router----------PE(ISP)
someone logged into that PE could ping the customer 192.168.1.0/24 after a static route being applied. Behind that PE no one could route to that 192.168.1.0/24 of course. I was trying to prove that NAT aint any sort of Security feature.
Besides I wouldnt have
Besides I wouldnt have meniton this if I havent seen it before, people do lots of stuff in their free time at work....
Understanding NAT and its role in Network Security
Thanks for your response. I did read your comment however and you said “In fact, say you have 192.168.1.0/24 INSIDE and 213.1.1.1/32 OUTSIDE, if your service provider decides to put a static route as such to you :"ip route 192.168.1.0 255.255.255.0 213.1.1.1" you bet you have all your INSIDE network exposed for good.”
That’s not accurate. You would not have your network “exposed for good" by this errant route statement.
Also you said nothing about anyone needing to breach your Customer Premise Equipment first, which in and of itself constitutes a breach. If a hacker is in control of my edge router then I’d say my network is already somewhat exposed.
You might take another look at where a commenter tried to explain to you earlier that ISP’s do not forward those private addresses in their BGP tables. He was correct in that regard. Regardless of the errant route statements entered into access layer routers by technicians with too much spare time on their hands, at the distribution and core layers which your traffic will traverse to get to its destination no such array of errors exists. These routers do not pass private RFC 1918 addresses. That’s essential to proper functioning of the Internet.
But there’s even more reasons your scenario is incorrect. You say the person needs access to the CPE to make it work. Well, if he had access to the CPE, such as a standard ISP provided edge router, GRE is usually available. What would he need any sort of route statement from the ISP to your private network? He could just set up a GRE tunnel between your two endpoints and send all traffic he’s interested in to the tunnel. So with the scenario you provide, a route statement to the private address space if it were effective, which it would not be, wouldn’t be required anyway. He’d already have access if the network were that unprotected. And he could just ping the inside host from the CPE assuming the networks as wide open as your scenario indicates. That is assuming his NAT appliance is also misconfigured, which when referring to SOHO devices means he actually would have had to remove the default settings.
The fact is most NAT appliances are firewalls, gateways, proxies, multifunction routers, etc, and hence most are going to be configured to only accept traffic on the outside interface directed to one of the registered addresses hosted on the outside interface and NOT to the internal address space on the external interface. That means you’d need to ping the registered NAT address, which is where the inherent security NAT provides is evident. When a properly configured (which is usually the default configuration on SOHO appliances) NAT appliance sits between you and your private network, it’s the NAT appliance responding to the ICMP requests from the internet, NOT the internal hosts. The NAT appliance responds on behalf of the host meaning the host cannot be overwhelmed with ICMP requests, one of the most basic rudimentary forms of attack. And of course there’s the fact that most NAT appliances are configured to reject ICMP requests from the internet facing side by default.
So in a nutshell even if your ISP set an errant route entry pointing to your private RFC 1918 address space and last hop, and even if every router along the path was configured to route RFC 1918 private address ranges to your ISP or the hacker was able to route them directly and even if he breached your perimeter router, even if all this could occur, if your network had anything as advanced as a simple Linksys SOHO Router\Gateway with the default settings, their ICMP requests would never traverse the NAT appliance (in this case the Linksys SOHO device) and thus your ISPs route statement would still be moot. He wouldn’t be able to ping you even from the CPE router.
And as for NAT, NAT of course was originally designed to conserve registered IANA address space but it is also a form of security.NAT avoids direct connections to your network equipment by permitting the NAT appliance to respond on behalf of the registered public address and connecting to the private internal address of the NAT’d host. In fact the scenarios you describe point to SOHO or home user implementations meaning most likely “PAT” (one to many) would be employed instead of one to one NAT translations. Egress connections returning to the inside would arrive at a port determined by the NAT appliance and would differ from the socket connection on the outside interface of the NAT device, and ingress traffic to port forwarded services such as a game server or personal web server connect to the outside of the PAT device on the advertised port and then are translated to an unadvertised port for connection to the internal host. Thus the NAT\PAT appliance acts as a basic bastion host to some degree, answering such things as the ICMP requests you indicated thus protecting the internal host from having to respond to flood requests, etc.
NAT is a defensive security measure and correctly configured can help protect internal networks from discovery and some forms of denial of service attacks as well as denying connections to listening ports not configured to accept connections. Of course its not a complete turn key security solution and nowhere does the aritcle or anyone suggest it is. But it is a key and critical component of basic network security when connecting hosts to the world wide web. After all what network admin or engineer would ever configure his internal hosts with publicly registered addresses? Obviously not one who wanted to keep his job. Its basic security 101 and failing to recognize the role of NAT in security is a mistake we see all too often but one that can be easily avoided.
Hope this helps.
Post new comment