On Wed, Oct 01, 2003 at 10:06:59PM +1200, wrote:
I cleverly sent a half-baked reply earlier thanks to my quick fingers.
> > 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.
It has turned out to be somewhat easier to design secure firewall
configurations using stateful filtering, plus there are some performance
benefits that can be extracted from stateful filtering, e.g. allowing
packets that are part of an existing state to bypass rules traversal in
some cases.
> > 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.
This really depends on what type of connections are passing through the
firewall. You're talking about client applications that use ephemeral
port ranges.
> > 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.
You can't easily 'block all but SYN' with a stateless packet filter and
still have working connections.
> > 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
NAT requires you to keep some state: the source IP and port, the
translated source or destination IP and port, and the destination IP and
port. This is not the same state that a stateful firewall is aware of.
Indeed, some systems that perform stateful firewalling and NAT can and
have merged the NAT and filter state tables for performance reasons.
> > 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.
A system that is performing NAT and nothing else will not protect you
from the likes of spoofed IP addresses and sourced routed packets, to
name but two things.
NAT does not protect the machine with the public IP address. You would
need to perform packet filtering on this interface to protect the
NAT/firewall host's external interface properly.
> > 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.
Nothing is a magic or silver bullet.
I had intended to write a more in-depth explanation about network
address translation and packet filtering, but I've been too busy
recently. The half-baked email I sent earlier was the very early
beginning of this, and had been lingering in my postponed mailbox long
enough that most people had probably forgotten about the thread it was
relevant to.
The crux of my message is this: NAT and packet filtering are not even a
vague replacement for each other. They are complementary technologies,
and you are putting yourself at grave risk if you believe that NAT will
protect you from anything at all. It is dangerous enough to espouse
this belief personally, but it is much more damaging when preached to
people who don't know any better.
If you care about security, don't base your security processes on
something you read about on a mailing list. Do your own research.
Cheers,
-mjg
--
Matthew Gregan |/
/| [EMAIL PROTECTED]
