how-to block ads
|
Anon | Re: When NAT becomes NOT
Erm...
NAT, is NOT firewall security. It's simple, very simple address translation. It doesn't prevent inbound connections. It doesn't filter all inside addresses to a singular outside address.
"That's PAT, that does that."
;said the cat in the hat!
The idea behind NAT and PAT is simply to keep publicly routable IP addresses on one side of the router (the public side), and your inside, private (non-routable) addresses on the other.
Effectively, it's as if you had a gate at the end of your street, and all the public mail addresses were given to the gate person, who then distributed them to your private street address within the gated community. A mail bomb sent to your public address will still be delivered to your private one. There is no inspection of the traffic, just forwarding. The security comes from the fact that people cannot see you directly.
(You can further obsfuscate the issue by using someone else's publicly routable address inside your private network, in effect doing an offhand form of NAT at a different layer, but should NAT on the router fail, your network will probably lose total internet connectivity.)
Requiring connections to be established from the inside network is a firewall issue, and is not part of NAT or PAT. It can't be, because if all outside queries were rejected, you'd either have to open a permanent hole in your NAT table, or you'd never give responses to DNS, email, and other queries. That's a good thing right? Umm..not if you're running a game server and want folks to connect to you!
Finally, you can't do encryption over NAT, because the source address is part of the decryption algorythim, and if it's altered, the decryption will fail.
See RFC 1631 at:
»www.faqs.org/rfcs/rfc1631.html
for more detailed info.
Regards,
-Bouncer- | |
justin
Australian
join:1999-05-28
Brooklyn, NY
Host:
IPv6
Business Connectiv..
Home/Office setup ..
Console/Handheld g..
Console Tech
| The mailbomb/mailman analogy is not correct in my experience. NAT devices and NAT software that is being marketed as such do not pass on packages unless a preexisting connection has been opened to the outside party. The letter (packet) cannot be addressed to an inside address unless you've been contacted first.. the packet is dropped.
If you port scan a NAT box, no ports are open, no machines get your packets, no matter how many machines live behind it.
So it isnt a firewall (I said that in the article) but it does provide basic protection.
And the end of the article points out the VPN issues as well.
If you can point me to some documentation for a NAT box or NAT software that shows how a new connection from outside can get in without explicitly allowing it, please post! | |
Anon | Well,
We're kind of going in circles, because I just realized we're talking about two different kinds of NAT. You're referring to outbound-NAT, and I'm referring to bi-directional NAT.
(From RFC 2663: )
"With a Bi-directional NAT, sessions can be initiated from hosts in the public network as well as the private network. Private network addresses are bound to globally unique addresses, statically or dynamically as connections are established in either direction."
Pretty much sums up Bi-directional NAT in a nutshell. We'll call it a draw. (LOL)
To me, the real problem is this:
Neither out-bound or bi-directional does NAT do inspection of the packet. A firewall WILL do that, and more. In addition, out-bound packet sourcing for security isn't part of the RFC, it's more to do with propagating routing tables, and shouldn't be relied upon as the primary method of defense. I'm not down on NAT at all, I just wouldn't bet my data, or recommend you betting yours, on it.
Regards,
-Bouncer- | |
|
