-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 24 Sep 2003, Matthew Gregan wrote:
> NAT does not provide the same protection as a packet filter or firewall. That depends on a lot of factors and exactly what you define as a "packet filter" or a "firewall". There's a few misunderstandings I've seen on this subject in the list, so some clarity with the correct terms is probably a good idea. A stateless packet filter will provide very little protection against inbound data, due to it's lack of state awareness. In order for a stateless filter to work, you have to allow all empherical ports (that's ports 1024-65535) as a destination port to your address because those are the ports used for the local end of the connection. Remember: TCP has _two_ ports, a remote destination port and a local source port. Thus, to allow _any_ outbound connection, even if you are limiting such connections to only specific destination ports, you must allow a very large swath of incoming ports, or nothing will go. You can mitigate some of this by dropping packets which only have SYN set, since these will invariably be initiating a connection. However, this hack only works for TCP, for UDP you have to allow everything regardless. A statefull packet filter will record what packets initiated a connection in a given direction, and use those records to decide when to allow reverse traffic (commonly called "connection tracking"). As such, a statefull firewall does not need to open all empherical ports, it simply looks at the incoming packet and only passes it on if it already has an existing connection listed. This works with all IP protocols, including UDP. Statefull packet filters are therefore inherently less risky than stateless filters. NAT is typically implemented as a side effect of crossing some boundry. NAT requires a similar idea of connection state as a statefull filter because there needs to be some way to untranslate the incomming packets. As a result, you end up with more or less the same results using NAT as a statefull filter. Neither NAT, nor plain statefull filtering, will provide any more or less security than each other, simply because they are the same thing. What matters is how you configure what is allowed to initate a connection. On that point, most people are generally correct, in that you still do have some risk if you "allow all out", but denying all but specific ports outwards is not the magic bullet people may think it is. So long as you allow _any_ data (even de-encapsulated over say a userspace TCP relay) to pass between the Internet and your PC, there is a way it can be used to compromise you. Dropping ports makes it marginally harder, but not hard enough for the truely motivated. A common example of this folly is to limit people to say 80/443, which prevents people from doing anything they like. It does _no_ _such_ _thing_, it's trivial to set up a tunnel over 443 or 80 and get any access you want. It does require some knowledge, but it's easy to implement. - -- David Zanetti | (__) #include <geek/unix.h> | ( oo Mooooooo http://hairy.geek.nz/ | /(_O ./ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE/cSB0T21+qRy4P+QRAm0RAKCdGs5Llf1oFDOIpMshSS6BToFY5QCeOMLW 9/1SEjA/xdKxYw59quq+J/w= =OSzL -----END PGP SIGNATURE-----
