On Wed, Sep 24, 2003 at 04:41:21PM +1200, David Zanetti wrote: > That depends on a lot of factors and exactly what you define as a > "packet filter" or a "firewall".
Yes, and it depends what you define "NAT" as, too. Are we talking source NAT, destination NAT, both src and dst NAT, port address translation, 1:1, 1:M/M:1 or N:M translation? Those who are claiming that NAT is "almost as much protection as a firewall" are making the assumption that we're talking the configuration the average home user may have; multiple machines with RFC1918 addresses and an Internet connected machine with a public IP address acting as a gateway, i.e. M:1 source address NAT aka port address translation. > 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. A stateless packet filter that is dropping all packets has a pretty good chance of stopping inbound data. > 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. Whereas NAT does not. > NAT is typically implemented as a side effect of crossing some > boundry. NAT requires a similar idea of connection state as a There's no "side effect". You need to deliberately configure the router/gateway to perform NAT. > 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. The state table used for NAT and the state table used for stateful packet filtering are often combined. Not because NAT and packet filtering are the same, but because they both have a requirement to record state of packet flows. > Neither NAT, nor plain statefull filtering, will provide any more or > less security than each other, simply because they are the same thing. They are most definitely not the same thing. Source routing http://www.robertgraham.com/pubs/firewall-seen.html#3.1 NAT does NOT protect the machine with the public IP address. > 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. Default deny > 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. Indeed. Even with the use of application specific proxies, a cunning user can pass any data they like over the link if they're able to encapsulate it properly and have control over or access to a suitable end point to decapsulate* the data. Examples of this are IP over DNS, IP over PPP over SSH, and potentially even IP over SMTP. > 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. -- Matthew Gregan |/ /| [EMAIL PROTECTED]
