[Don Tuer]
>> Hello:
>>
>> One question that I've had for some time is why isn't a NAT only
>> solution sufficient security? I'm running a NAT with no
>> filters on outbound
>> or inbound connections but using a private IP address
>> (10.x.x.x) on the
>> inside. Source routing is turned off so how would a hacker
>> exploit my NAT?
This is really quite a good question.
First of all, there IS one type of NAT that is a clear security problem -
"complete" NAT mappings. This is where an IP address is NAT'ed to another
address for all ports, all protocols - so anything that hits the public IP
gets relayed to the private IP.
Don't do that, if you can help it. If you need to do it, don't do it without
filters. It's the equivalent of hanging the box out on the Internet with no
protection at all.
I'm now talking about dynamic NAT and PAT (port address translation).
> -----Original Message-----
> From: Noonan, Wesley [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 13 September 2000 1:36 PM
> To: 'Don Tuer'; '[EMAIL PROTECTED]'
> Subject: RE: LinkSys 4-Port Router
>
>
> As I understand it, one way would be spoofing. Submit the
> packets to the NAT
> device, but make it think they came from the "protected" network.
This is only ever an issue with static NAT. For dynamic NAT a spoofing
attack is pretty much impossible (think about how it works).
Now, consider static NAT with port mappings - you map inbound traffic on a
per port basis - when you map port 80, that's the only port that's "opened".
This is kind of equivalent to a packet filter. Yes, spoofing is an issue
here. The impact? The attacker will never see return traffic, so they need
to rely on the packet being able to do damage just by virtue of being
delivered. If there is a vulnerability of this kind then it can usually be
exploited using any forged IP range - having it appear to be internal
traffic is unlikely to help. That leaves only a very small class of attacks.
There is a difference here, but I don't think the impact is very great.
>
> Additionally, lets say you open port 80 for NAT. Now lets
> assume that some
> hacker has an exploit they can launch on port 80. With a
> filtering firewall,
> or an application firewall, it can do a better job of
> examining the packets
> and making sure they really are what's expected (HTTP instead of the
> exploit).
No. It can't. Well, not for HTTP, anyway. This is one of the biggest
bugbears in the ALG world - you can get almost anything into / out of a
network over HTTP. There's way too much trust in firewalls to secure
insecure protocols, IMO. I don't know how many times I've heard people
respond to my questions about the security of their WWW app with "But isn't
that why we have the firewall?".
> NAT will just hand the exploit of to the machine,
> compromising
> security.
So will pretty much every firewall I know. HTTP is close to the worst
example you could have picked here. I concede your point for SMTP - most
decent firewalls can at least do some control channel inspection and basic
sanity checking on SMTP - it's not a very hard protocol. Maybe FTP as well -
although it appears that FTP is much harder than many people thought. ;)
>
> Finally, NAT devices do nothing I am aware of to counter DDoS
> attacks.
Neither do most firewalls. They _can_ - sometimes. But then again there's no
reason why a NAT device couldn't do this as well.
[snip]
> Also, a DDoS attack could take the NAT device
> down, allowing
> unintentional (hack) traffic through. Most firewalls are designed, if
> compromised, to compromise in a shutdown state.
Hang on - name an edge NAT device that's not fail-closed. It's the same
concept - the box sits at your border. If the box goes down, so does the
network.
[snip]
>
> At least, these are what I understand as some fundamental
> differences. :)
I don't think you've raised any compelling arguments, so far - sorry. This
is an interesting topic, though. I'd like to see some more traffic...
>
> HTH
>
> Wes Noonan
> [EMAIL PROTECTED]
> (281) 208-8993
Cheers,
--
Ben Nagy
Network Consultant, Volante Solutions
PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
