post of the month, thanks for the explanation.
On Wed, 24 Sep 2003 16:41:21 +1200 (NZST) David Zanetti <[EMAIL PROTECTED]> wrote: > -----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----- > > -- Nick Rout Barrister & Solicitor Christchurch, NZ Ph +64 3 3798966 Fax + 64 3 3798853 http://www.rout.co.nz [EMAIL PROTECTED]
