Re: Firewalls that generate new packets..

["Darden, Patrick S." <darden () armc org>]

Marcus J. Ranum said (I am snipping (not sniping)):

> What I'm trying to get people to understand is that there are
> these cool sounding marketing terms like "stateful" and
> "deep packet" which, when you look under the covers,
> are basically not doing a whole lot. 

I couldn't agree more.

> In a "stateful" firewall the state is all held in the firewall,
> but in a router+ACLs relying on TCP SYN/ACK semantics
> the state is held in the endpoint/target's IP stack. 

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).

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:

*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.

*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).

*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.

Additionally, I think there are at least 2 more levels of even
higher security (security simply meaning it is harder, or more
difficult, or takes more effort, or at the least is more 
complex to overcome).  But first:


> Last topic: "inspection"  The term "inspection" has been
> successfully glued onto these devices by marketing
> weasels for over a decade. Can anyone tell me what
> "inspection" is going on? What is inspected, and how, and
> what decisions are made as a result of that inspection?

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.  
Stream inspection (deep packet inspection) would be even better.
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.

*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.

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.

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