firewall-wizards@listserv.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com
You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. Re: Firewalls that generate new packets.. (Marcus J. Ranum)
2. Re: Firewalls that generate new packets.. (Marcus J. Ranum)
3. Re: Firewalls that generate new packets.. (Marcus J. Ranum)
4. Re: Firewalls that generate new packets.. (Darren Reed)
5. Re: Firewalls that generate new packets.. (Marcin Antkiewicz)
6. Re: Firewalls that generate new packets.. (jason@tacorp.com)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Nov 2007 19:23:02 -0500
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <6.2.0.14.2.20071127190800.045ed880@ranum.com>
Content-Type: text/plain; charset="us-ascii"
Anton Chuvakin wrote:
>This adds some fun fuel to this fire:
>http://rationalsecurity.typepad.com/blog/2007/11/take5-episode-7.html
I see buzzwords and marketing a-plenty in that interview. :)
WTF is "application-centric classification"?? That's what any
decent firewall has done since the beginning. And Zuk's implicit
claim in his first paragraph (that CheckPoint did what they did
because "current firewalls were ineffective") is disingenous
at worst and bullshit at best. Note how he's careful to position
CheckPoint against routers+ACLs, not against any of the
actual layer-7 firewalls that were dominating the market at the
time. CheckPoint won because they were fast and the market
was ignorant, not because they were more "effective" - in fact,
quite the opposite, they were (and are) vastly less "effective"
and are superior to a router+ACL primarily in the user interface
department and because they handled FTP without requiring
high port callbacks. Remember - circa 1994, high port callbacks
to enable FTP, was the raison d'etre for a "stateful" firewall
instead of just a router+ACLs.
>"I think that a more important trend in network security today is the
>move from port-centric to application-centric classification
>technologies.
I see lips moving but I don't actually see anything here that is
not just buzzblah blah foo marketing blah marketing foo buzz blah.
What does all that MEAN?
Any security practitioner that has not been Rip Van Winkleing
for the last decade knows that application layer is where the
action is right now. Is he jumping onto a 10 year old bandwagon
and yelling "LOOK! A BANDWAGON!" or what?
>This will make most of the existing products obsolete,
>similar to the way stateful inspection has made its predecessors
>disappear from the world."
If what he's saying is that "everything tunnelling over port 80 hurts"
well - Duh?
The reason stateful inspection made its predecessors disappear
is not because it was better, but rather because it was WORSE
but its customers like the blah blah foo foo marketing buzz blah
foo stuff that Nir spews better than they like actually understanding
what the expensive doo-dad they bought actually does.
Hey Anton? Did you actually read that article?? I am asking you
this seriously. Because I just read it twice and the only words
that I could find in what Nir was saying that's not pretty much
100% unadulterated marketing bullshit is the words:
"network"
"is"
"the"
mjr.
------------------------------
Message: 2
Date: Tue, 27 Nov 2007 19:28:29 -0500
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <6.2.0.14.2.20071127192315.045ed5f0@ranum.com>
Content-Type: text/plain; charset="us-ascii"
jdgorin@computer.org wrote:
>I also remember that early Checkpoint firewalls broke FTP connection if the PORT
>command and the PORT arguments were sent in differents packets (back in those
>old times, some FTP gateway did that kind of tricks).
>That was deep but not smart inspection!
That was a side effect of the fact that they didn't do TCP reassembly,
packet defragmentation, or re-ordering. I always figured that they were
just doing a case-independent compare for "PORT " at the beginning
of the packet data.
Heck of a "state" engine, huh?
mjr.
------------------------------
Message: 3
Date: Tue, 27 Nov 2007 19:55:05 -0500
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <6.2.0.14.2.20071127192904.045ed218@ranum.com>
Content-Type: text/plain; charset="us-ascii"
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.
------------------------------
Message: 4
Date: Tue, 27 Nov 2007 19:23:24 -0800
From: Darren Reed <Darren.Reed@Sun.COM>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <474CDF2C.2070308@Sun.COM>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Marcus J. Ranum wrote:
>Darden, Patrick S. wrote:
>
>
...
>>*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.
>
>
Understanding what DOS is appears to be a problem for a
*lot* of people. Lots of people seem to fail to understand
what the real problem is - the saturation of your network
(connection) with packets that you don't want anything to
do with at a point at which you've got no control over.
What's more, people seem to think that you can just filter
out DOS attacks. Will someone please give me a cricket
bat (or baseball bat) so I can apply some proper instruction?
*sigh*
As Marcus said, no firewall, be it stateless, stateful, proxy,
or otherwise can help you against DOS.
...
>>*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?
>...
>
>
Marcus, don't you find it funny that people are coming up
with new terms to describe technology that is even more
lame than what has been available via open source for more
than 10 years now?
>>Stream inspection (deep packet inspection) would be even better.
>>
>>
>
>Is "deep packet inspection" stream inspection?
>...
>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'?"
>
>
I think 'deep' is more of a reference about how far they'd like
you to reach into your pocket - again - so they can get their
product bell curve to turn the right way :-)
...
>>*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.
>
>
You know for a while, one of my favourite HTTP commands
to a proxy was "CONNECT". telnet straight through
someone's firewall that was HTTP only ;-)
I forget how it went, but something like this:
CONNECT http://12.34.56.78:23 HTTP/1.0
and sometime later, I'd happily see this:
SunOS foo
login:
Of course now people restrict CONNECT to the more usual
ports, such as 443 but since 443 is normally encrypted, it
is uncommon for any content filtering to be applied to it...
Does your ssh server /also/ run on port 443? ;)
...
>Is it possible that a "firewall" is largely "a router
>with a sticker on it that says 'firewall'?"
>
>
The ADSL+router+NAT+Firewall you buy from Safeway at
$29.95 probably is just that :-)
>...
>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?"
>
>
I first heard the term "deep packet inspection" around 5 years
ago and nothing I've seen or heard since then has convinced me
that it is anything other than a marketting term, used by people
trying to sell _something_ (be it themselves, their ideas or products)
that you'd otherwise not think twice about.
And it is the lack of definition about what "deep packet inspection"
is that continues to make it sound good. Nobody appears to have a
precise definition, so everyone can claim it (for different reasons.)
I mean, would you buy a firewall that did stateful filtering, proxying
or deep packet inspection? I mean, what sounds sexier?
Darren
------------------------------
Message: 5
Date: Tue, 27 Nov 2007 21:19:10 -0600 (CST)
From: Marcin Antkiewicz <firewallwizards@kajtek.org>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <Pine.LNX.4.64.0711272034570.3111@runt.uhhh.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> 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.
I would not look at Squid as a security device - I cannot imagine a
security proxy written for HTTP as it stands today. In order to have
any install base, HTTP proxy can, at most, implement ACLs/user auth with
content filtering and some spam, maybe some cookie encription/info leakage
prevention, but cannot really limit the protocol. Squid and most popular
http proxies are http caches/load balancers but not security devices.
I am not the authority on the subject but, if I am correct, the first
firewalls did not even have packet filters - traffic went through a proxy,
and protocols that were not supported/proxy friendly were transfered via
some kind of authenticated IP replay thingey (or was it decnet to IP
bridge?). DMZ was for housing computers used to connect to the outside
(shellboxes), as they were "tainted". Now - that's secure design! Same
for traffic leaving the network. Caveat: I may be wayyy incorrect here,
I cannot find much info available about the history of
firewalls. (I will gladly take beating, just point me to the docs..).
And now, we slap a NATing router with some ACLs, AV, caching proxy,
sieve-like egress filtering and call it a firewall.
Everyoen loves war stories: I do consulting sometimes, and last time it
was for a place with IDS, IPS, 3 AV subscriptions, HTTP proxy, split
horizon DNS, 2 (!) layers of firewalls (statefull), encrypted and
unencrypted wireless, NAC and traffic shaper. The bad guys still got in!
How you ask? Easy: via HTTP/s, dns, smtp (traffic on all the protocols
was proxied, in and out).
--
Marcin Antkiewicz
------------------------------
Message: 6
Date: Tue, 27 Nov 2007 22:39:04 -0500 (EST)
From: jason@tacorp.com
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <20071127223259.P62990@phoenix.cnwr.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>> in both directions. State tables allow your firewall to have a deny-all
>> default inbound policy and an allow-all default outbound policy. They allow
>
> With today's proliferation of Trojans and Spyware, anyone with a
> Windows user population above three who has an allow-all default outbound
> policy is an idiot and populations of one to three are likely candidates
> for the club if not associate members.
>
I see both points but perhaps a different example show where tracking
state may be beneficial. If I have a number of servers in a DMZ that are
accessible both from the internet and inside my network I can reduce the
administrative overhead by tracking state. If I opened up port 80 into a
web server and the state was tracked the reply packet would be able to
pass back out of the firewall without having to have a rule allowing
packets from the webserver sourced from port 80 out. Why should I need to
put two rules in (one for the incoming traffic, and one for the reply)
when I can rely on the state of the packet for the reply?
-Jason
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 19, Issue 27
************************************************
No comments:
Post a Comment