Re: [fw-wiz] Firewalls that generate new packets..



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@xxxxxxxxxxxxxxxxxxxxx
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards



Relevant Pages

  • Re: What do you think of my acces list?
    ... These ACEs would not be necessary if you were using "inspection" on an internal interface to provision the return path (temporary dynamic holes in the firewall). ... " permit udp any eq domain any " ... If you were trying to accommodate DNS "responses" resulting from queries initiated by internal clients, I would have expected the generic UDP inspection to provision the return path for this return traffic. ...
    (comp.dcom.sys.cisco)
  • RE: Yahoo Messenger Stale Sessions
    ... sequence correct (the TCP application on the host doesn't look at the IP ... If your site is protected by a stateful firewall (or even a NAT device ... If the intention is to masquerade as your friend would it be easier to ... Subject: Yahoo Messenger Stale Sessions ...
    (Incidents)
  • Re: [fw-wiz] Firewalls that generate new packets..
    ... behind the firewall then it's a layer-7 problem for the service ... regexp match causes packet drop ... is exactly why I used the term "placebo" for "stateful ... inspection"; accupuncture patients report the same degree ...
    (Firewall-Wizards)
  • Re: Kerio PFW 2.14 - Safe?
    ... If Kerio 2.14/5 states it's stateful, ... inspection is a type of inspection... ... the rules set the firewall applies. ...
    (comp.security.firewalls)
  • Re: Is known IP-number filtering pretty much all that is needed for website security/vulnerabili
    ... saturated and the server becomes overwhelmed. ... The firewall intercepts the syn packet and constructs a syn-ack packet where the sequence number is a cryptographic hash of the source IP and port, destination IP and port, a timestamp, sequence number, and a rotating IV of some sort. ... When an ack is received the firewall again intercepts it, calculates the hash again and if the sequence number matches then it performs the TCP handshake with the server on behalf of the client and the connection is allowed. ...
    (comp.security.misc)