[ILUG] Somewhat OT: Dynamic vs. Static NAT?
paul at clubi.ie
paul at clubi.ie
Wed Jan 16 11:38:18 GMT 2008
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:
> ~ ----- = 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
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
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. :(
Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A
"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
More information about the ILUG