[ILUG] Somewhat OT: Dynamic vs. Static NAT?

[paul at clubi.ie]

On Wed, 16 Jan 2008, Gareth Eason wrote:

> 	In an attempt to put this argument to bed, allow me for a moment to
> demonstrate that there is, in fact, a use for stateful packet inspection
> and firewalling techniques based on same:
>
> [host]-----[router]-----[firewall]=====[evil_net]===[www_host]
>
> ~     -----  = very slow connection
> ~     =====  = very fast connection
>
> Let's use the example where 'host' initiates a web connection and 
> gets a response on port 1666. Also, the responding host decides to 
> flood on port 1667. (No, I don't know why - but let's say it does.)
>
> 	In that case, to protect the network of slow connections 
> behind the firewall, a stateful firewall is (possibly) the 
> appropriate solution. Waiting for the state machine in the 'host' 
> to discard useless (possibly DoS) packets is too late, whereas the 
> firewall has the knowledge to do this at the edge.

It's this "the firewall has the knowledge" bit that's just wrong - no 
matter how much state it keeps.

The biggest flaw in your idea, is you're using the details of TCP as 
a security "key". Except this "key" is quite visible to evil_net, who 
can replicate it and flood you with otherwise valid packets. Your 
stateful-firewall is in fact *transparent* to evil-net so far as 
DoSing is concerned. You confuse "packets that are valid TCP" with 
security. Only the end-host can know which packet it will treat as 
valid.

Finally, keeping state costs RAM. RAM which gets allocated by the 
actions of remote, potentially hostile attackers. I bet evil net, if 
they can't get past your firewall to flood that slow link, can cause 
your firewall to run out of resources (and how will it fail then?).

And that's no idle speculation: I have a DSL router that behaves 
strangely after I run a simple NMAP through it.

What you /really/ want is to apply rate-limiting - requires much less 
state to be kept. Doesn't require the firewall to try re-construct 
client state-machines. And that actually COULD protect you from a DoS 
(though, not from evil net really).

Less is more.

> operating in that mode. Protection at the edge of a network is 
> often deployed to protect the network, not just the hosts. Unless 
> the edge router omnipotently knows all legal activities of the 
> hosts behind it at all times, it can be shown that it cannot 
> protect the network in all cases without gathering and acting on 
> some kind of state.

Gathering state is NOT a substitute for omni-potence.

I did NOT say that protection should not be deployed at the edge of 
the network. I maintain that stateful validation of protocols should 
not be in the /middle/ of networks (including the edges of 
sub-networks).

My point was that TCP can be effectively filtered in a stateless 
manner. Your example above only REINFORCES that.

1. Ah "Some kind of state": I should be more careful in my 
terminology. State that is kept so as to be able to validate the 
state-machine of some protocol is the particularly evil 'stateful 
filtering'. This is what's usually referred to with "stateful 
filtering" I think, and for TCP especially.

Keeping historical state for the purposes of rate-limiting or opening 
a port in one direction based on flow in other direction at some 
stage in past (e.g. how UDP is usually "statefully" filtered) is not 
as problematic. Though, if there's a fully stateless manner to 
achieve the same high-level goal, that'd be better.

It might be an idea to distinguish between the kind of stateful 
filtering, I can't think of good terms for them though. :(

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
"The Mets were great in 'sixty eight,
  The Cards were fine in 'sixty nine,
  But the Cubs will be heavenly in nineteen and seventy."
-- Ernie Banks