Re: firewall test and NAT
- From: John John - MVP <audetweld@xxxxxxxxxxx>
- Date: Fri, 08 May 2009 11:47:22 -0300
ToddAndMargo wrote:
Brian A. wrote:<snip>The trouble with NAT is that the bad guys just slap their
guess as to what your internal off Internet address on
to their probe. They find you very quickly if your internal
off Internet address is 192.168.0.xxx. (Recommendation:
pick an internal address other than 192.168.0.0/24 or
192.168.1.0/24.)
NAT does not stop incoming requests called SYN (TCP) or
state "New" (TCP or UDP). It only stops traffic not
properly addressed to your internal network. Enough
guessing and the bad guys will find you.
If that were to be true, every network in the universe would be no more, Port probes are being performed 24/7 and have been for years.
The Client sends a SYN to the Server requesting a connection.
The Server sends back a SYN-ACK to the Client acknowledging the request.
The Client responds with an ACK and the connection is completed.
Port probes are looking for any open Port, and if they don't find one, they move on to the next possible victim without ever responding with an ACK to the Server. Without an ACK response from the Client, the Server will wait X amount of time before sending another SYN-ACK, then again, and again, etc. until it reaches it's max set of times to send. It's when a Sever is overwhelmed with these Half-Open connections that it becomes a real issue.
Hi Brian,
You are correct. You are missing that the probe can include an
internal address as well as the required external address.
An unsuccessful sample attack on my machine for you:
kernel: Incomming SYN IN=eth1 OUT= MAC= SRC=192.168.1.1 DST=192.168.1.46 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=228 DF PROTO=TCP SPT=1030 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
Translation:
SRC is my NAT router (192.168.1.1) on my 1st Ethernet port
RST is a virtual machine (192.168.1.46) on my second Ethernet
port that has not run for over three weeks (currently off)
SYN is a SYN packet
The probe got right through my NAT router (and got stopped by my
software firewall). NAT is a good idea in a lot of ways.
And it does stop tons of state=new packets. But, as I have
shown, you can poke through it. It takes a lot more skill,
so it does cut way down on the bad guys attempt to probe
you. But it does not stop all unsolicited state=new probes.
This is why I am tell everyone that doubts me that
*NAT is not a firewall*.
Let's forget the *NAT is not a firewall* business, this is not a disputed point, we know that NAT is not a firewall but by its nature it has firewall like qualities.
What we don't buy is your assertion that NAT is flimsy to the point where it can be broken by the most simple scanning techniques, that almost anything can just easily shoot through it. Many years ago when NAT was designed the network engineers who put it together would have had to have security in mind, they would have known about network intrusions. These engineers knew that their design had to be robust enough to keep the bad guys out, willingly or unwillingly it had to be part of the design. If what you say is true NAT would not have made it past the starting gate, the engineers would have presented their new "baby" to the world and in less than 24 hours it would have been completely hacked and the project would have fallen apart! There is *absolutely* no way that NAT would have become accepted if it could have been so easily broken, no one today would be using it, certainly Microsoft's Internet Connection Sharing (ICS) would have never seen daylight. Like Brian said, "probes are being performed 24/7 and have been for years". If you log intrusion attempts the router log will probably fill up rather quickly. Instead of logging at the router perhaps you should use a third party firewall or a tool like Wireshark and log on your computer on the inside of the NAT device and see what is actually making it past the router to your computer.
I think that the point that you are leaving out of the picture is that NAT only allows *solicited* traffic past the gate. It sort of works like this:
"John John" sends a message to "ToddAndMargo", NAT forwards the message and remembers this, it "waits" for a reply from ToddAndMargo and when the reply arrives from ToddAndMargo NAT sends it to John John. While NAT waits for solicited replies "Tom***&Harry" come by trying to send a message to John John and NAT says: "John John didn't ask for anything from "any Tom, *** and Harry", NAT tells them to get lost and drops the message, the unsolicited packets never make it any further than this. Whether or not "any Tom, *** and Harry" know that John John is home is almost completely irrelevant, what matters is whether or not John John invited them in, that invitation is next to impossible to fake!
NAT works like this:
*Outgoing Packet at the NAT*
The NAT will intercept this outgoing packet and create a port mapping using the destination IP address (server), destination port, external IP address of the NAT, external port, network protocol, and the internal IP address and port from the client.
The NAT will maintain a table of these mappings, storing this port mapping in the table. The external IP address and port are the public IP address and port to be used by for this data traffic in place of the internal client's IP address and port.
The NAT then "translates" the packet by swapping the source fields of the packet from the private, internal IP address and port of the client to the public, external IP address and port of the NAT.
The packet is then sent on the external network (the Internet) to eventually reach the intended server.
*Incoming Packet at the NAT*
The NAT receives these packets from the server and compares them to its table of port mappings. If the NAT finds a port mapping where the source IP address, source port, destination port, and network protocol of the incoming packet match the remote host IP address, remote port, external port, and network protocol of the port mapping, the NAT will perform a reverse translation. The NAT replaces the external IP address and external port in the destination fields of the packet with the client’s private IP address and internal port. This is an example of solicited incoming traffic. The NAT silently discards unsolicited incoming traffic that does not match a port mapping.
The NAT then sends the packet on the internal network to the client.
Overview of Network Address Translation (NAT) in Windows XP
http://technet.microsoft.com/en-us/library/bb457077.aspx
You are leaving out the part about port mappings, router tables and *unsolicited* requests from your intrusion scenario. Of course without these NAT would be next to completely useless, such a flimsy and completely insecure setup could never be exposed to the internet, you would have to place a firewall between it and the internet. But NAT is not designed in such a flimsy manner.
Of course this brings a catch 22 or a chicken or the egg kind of dilemma. If NAT only allows solicited requests how can anything move about, somewhere along the line someone has to accept an unsolicited request. That is what your ISP does with its servers and expensive border routers, these systems are designed to accept unsolicited requests, they use different methods to keep the unwanted out, your ISP may require you to logon to a server or it may only accept unsolicited requests from known IP or MAC addresses. Without expensive border routers and elaborate security setups anyone else has to punch holes in NAT to allow it to pass unsolicited requests, you have to open ports in the router. If your router is properly secured outsiders cannot open ports or punch holes in it. And for your simple probes to make it through masqueraded as solicited traffic they would have to actually break in to the router and hack the mapping tables! The only other way that I can think that one may make it in under the guise of solicited traffic would be by way of a "Man in the middle" attack, not such an easy thing to to. Much easier to send in malware and have it open holes from the inside for you.
John
.
- Follow-Ups:
- Re: firewall test and NAT
- From: ToddAndMargo
- Re: firewall test and NAT
- References:
- firewall test and NAT
- From: ToddAndMargo
- Re: firewall test and NAT
- From: John John - MVP
- Re: firewall test and NAT
- From: ToddAndMargo
- Re: firewall test and NAT
- From: John John - MVP
- Re: firewall test and NAT
- From: ToddAndMargo
- Re: firewall test and NAT
- From: Brian A.
- Re: firewall test and NAT
- From: ToddAndMargo
- firewall test and NAT
- Prev by Date: Re: Best Windows Explorer replacement?
- Next by Date: Re: microsoft net.framework
- Previous by thread: Re: firewall test and NAT
- Next by thread: Re: firewall test and NAT
- Index(es):