Re: Firewalls that generate new packets..

["Marcus J. Ranum" <mjr () ranum com>]

Darden, Patrick S. wrote:
> Actually, there are a couple of attacks that can use
> non-statefulness against you.  Several of the MITM attacks
> depend upon either statelessness or guessing the next sequence 
> # (this is where the OS's randomness comes in--the more random
> the more secure).

Don't any and all MITM attacks work successfully against
any unencrypted (and even a few encrypted) streams?
I didn't even mention MITM because they're pretty much
shooting fish in a barrel.

> You posit either stateless or stateful, however, I would 
> like to point out that a lot of "stateful" firewalls are 
> only stateful in a virtual sense--they do not record sequence
> #s.  I'd like to profer, in ascending order of security, the
> following:

I like this... Now, we're trying to actually define what
these things actually do. So we can compare "darned
little" against "shockingly little" ;)

> *stateless:     i.e. extended ACLs that merely look for syns/acks 
> or less--e.g. if it has the proper syns/acks let it through.
> This is a recipe for DOS disaster of course.  Connection
> hijacking.  You name it.  Stateless would not just include
> firewalls that only look for proper syns/acks--it would also
> include less artful firewalls that don't even do something
> that complex.

Let's take MITM and DOS off the table. No firewall will
protect you against either of those.

Does a router with ACL+"established" let unsolicited
RSTs through? I thought that all that got through was
SYN, unless it had an ACK. And to do an RST with
an active connection don't you need the sequence #?
That would require a MITM, right?

The hard thing I had to wrap my brain around was the
observation that between a router+ACLs combined
with the state that is held in the TCP stack of the
target, you've got exactly the same thing (and often
quite a bit better!) than a "stateful" firewall.

> *virtual stateful: keep a matrix of connections, but do nothing 
> with tcp sequence #s.  This is a little better than the above,
> in that improper resets would be ignored (e.g. that Charter
> business where they were sending resets back to p2p clients).

What is an improper reset? Is that an out-of-sequence reset?
What does a TCP stack do withan out-of-sequence reset?
(I am not asking to be a wiseass; I'm a layer-7 nazi and don't
recall the behavior of a TCP stack at that level of detail
any more.)

> *stateful: keep a matrix of connections, including sequence #s
> and actually checking sequence #s.  This can be much more
> secure than VS or stateless, depending upon the randomness
> of your OS.

How much more secure, and why?
(There, I _am_ being a wiseass)

> I believe packet inspection actually works.  By checking to make
> sure that data in a certain connection is actually "sane", you
> make it that much more difficult to overcome your security.  

I would argue a step further, namely that making sure the
data in a connection is safe (you say "sane") is all a
firewall can do. That, and apply a thin veneer of policy
direction atop the sanity check. So we're on the same page.

> Stream inspection (deep packet inspection) would be even better.

Is "deep packet inspection" stream inspection?

I am not convinced that the vendors that are selling "deep packet
inspection" are doing stream reassembly, packet sequencing,
and fragmentation reassembly, fragmentation overlap checking,
etc. Wouldn't those be a minimal set of features that one might
reasonably call stream-oriented inspection?

Would you like to bet that "deep packet inspection" means
nothing at all like stream inspection but rather means
something more like "regexes applied to packets?

What I'm getting at is that the industry was sold a gigantic
bill of goods (or load of bull, depending on your preferred
metaphor) in the form of "stateful inspection" and is
re-subscribing for another load called "deep packet inspection."

Put another way:
"Where's the 'deep'?"

> So:
>
> *stateful with packet inspection: a connection matrix is kept, 
> mindful of sequence #s, and checking to make sure that only 
> proper protocols are allowed--e.g. checking port 80 for http
> commands.  This would disallow blatant stuff like trying telnet
> over port 80, smtp over 443, etc.

Ahhhhh... Now we're in the ballpark of what any
reasonable thing called a "firewall" would be doing, no?

After all, when the customer says "let port 80 back and
forth" what they really mean is "allow web traffic." So if
the objective is "allow web traffic" the stuff that is being
allowed ought to look like web traffic - and, actually
like valid web traffic, not simply a bunch of packets
that are heading for port 80.

> *stateful with deep packet inspection: a connection matrix 
> is kept, mindful of sequence #s, checking to make sure that 
> only proper protocols are allowed, and additionally checking
> for application level sanity--e.g. squid, a web application
> proxy that allows for various levels of sanity checking on 
> http commands, can ensure that requests follow RFCs, allows a 
> lot of custom filtering/sanitizing such as regexp type addons 
> for getting rid of pop-ups, malware, pushes that might break
> cgi boundaries, etc.

Now, you're cooking with gas.

> I am well aware that Squid does not do all of the previous--
> it is an application proxy.  Application level proxies, or
> the equivalent, are the best form of deep packet inspectors.
> The rest of the Stateful with deep packet inspection would be
> what is more traditionally thought of as a firewall.  They
> would not substitute for one another, but instead complement
> each other.

That's really what I'm trying to get people to think
about. What is a firewall? Is it just a router that has a
tiny little bit of amplification to ACL+"established"?
Or is it a device that does security at higher layers,
including some layer-7 awareness? If it's doing layer-7
stuff, can it be excused from worrying about fragment
re-assembly (how could it possibly?) or re-ordering?

Is it possible that a "firewall" is largely "a router
with a sticker on it that says 'firewall'?"

Unless it's doing a lot of useful "deep" stuff at
layer-7, I'd say that might be the situation.

The question I want you all to start asking is:
"What's 'deep' about that?"

You didn't ask about the "stateful inspection" stuff and
look what happened. Now that they know you're suckers
they're gonna hit you with another load.

mjr. 

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards