Search This Blog

Monday, November 26, 2007

firewall-wizards Digest, Vol 19, Issue 23

Send firewall-wizards mailing list submissions to
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.. (Marcin Antkiewicz)
2. Re: Firewalls that generate new packets.. (Marcus J. Ranum)
3. Re: Firewalls that generate new packets.. (Paul Melson)
4. Re: Firewalls that generate new packets.. (Paul D. Robertson)
5. Re: Firewalls that generate new packets.. (Bill McGee (bam))


----------------------------------------------------------------------

Message: 1
Date: Sun, 25 Nov 2007 22:38:29 -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.0711252213060.28804@runt.uhhh.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

> Isn't that kind of amazing? People look at these "stateful firewalls" as
> if they're somehow doing something IMPORTANT but they're basically
> a router with "established" and a kind of "synthetic established" for UDP.
> People, that's barely a security device at all - 99% of what you're
> getting is the "firewall" sticker on the front.

In practice, most people have stateful firewall because they have to - if
they did not their vulnerability assessments/pentesting/other reports
would come with a "High" in one column, and "replace with a stateful
firewall" in the other. Not to bash state checking (OpenBSD pf, defense in
depth), but that seems to be the reason. Same with anti-spoofing,
filtering bogons, and using IP stacks with cryptographicaly secure IP
IDs/TCP sequence numbers.

> Security is such a disaster because we're fighting and losing
> a battle with software complexity and extravagantly stupid
> software specifications. Firewalls, rather than acting as bastions
> against the complexity, have "adapted" by succumbing to
> that complexity themselves.

Like using "session" and "user" authentication in place of actual access
controls, allowing use of crypto tokens with not pins (or pins written on
the devices) for the managers, inability to differentiate corporate laptop
from a vendor laptop (except for noting that a Dell is not HP).

When security went mainstream, and IT Sec folks were invited into the
board meeting, but they showed up without a business case (not enough
power point, wrong language, _something_ went wrong).

Now there is another chance to fix it, this time by using lessons
learned. Well, there can be no lessons without textbook materials, but
good universally known security cases and security metrics are... few.

The good news is that Web 2.0 mashups will take care of it all.

--
Marcin Antkiewicz


------------------------------

Message: 2
Date: Mon, 26 Nov 2007 00:31:08 -0500
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: dave@corecom.com, Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <6.2.0.14.2.20071126002624.06f989e0@ranum.com>
Content-Type: text/plain; charset="us-ascii"

Dave Piscitello wrote:
>I really would like to see a thorough analysis of the performance of an application layer policy enforcement using strictly stateful inspection techniques versus the same policy enforced using strictly proxy techniques.

It's pointless, Dave. "stateful inspection firewalls" ought to consistently
perform about as fast as routers. Because that's pretty much what they
are. Something that does any layer-7 analysis will always be slower
than something that does nothing more than table lookup and a
sequence number check.

mjr.

------------------------------

Message: 3
Date: Mon, 26 Nov 2007 09:44:57 -0500
From: "Paul Melson" <pmelson@gmail.com>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: "'Firewall Wizards Security Mailing List'"
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <007b01c8303a$ea952b20$4d00300a@ad.priorityhealth.com>
Content-Type: text/plain; charset="us-ascii"

> Isn't that kind of amazing? People look at these "stateful firewalls" as
if they're somehow
> doing something IMPORTANT but they're basically a router with
"established" and a kind of
> "synthetic established" for UDP. People, that's barely a security device
at all - 99% of what
> you're getting is the "firewall" sticker on the front.

You're overlooking the real value of state tables, I think. The real
advantage isn't technical, it's cognitive. If I don't have to think about,
decide on, classify, and manage all ends of the traffic crossing my border,
my life is a whole lot easier. A stateful firewall lets you think about
your policy in terms of published services; "I let the whole Internet
connect to this web server and that mail server, but nothing else. And then
whatever our people inside want to do."

Call it cynical. Call it misguided. Call it naive. Call it stupid. But
it saves time and energy which translates to money. And it seems to be
where the equilibrium for the firewall security vs. admin overhead equation
is, or at least has been in recent history.

PaulM

------------------------------

Message: 4
Date: Mon, 26 Nov 2007 10:13:58 -0500 (EST)
From: "Paul D. Robertson" <paul@compuwar.net>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Chris Blask <chris@blask.org>
Cc: bam@cisco.com, Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>, Paul Melson
<pmelson@gmail.com>
Message-ID: <Pine.LNX.4.44.0711261004300.15220-100000@bat.clueby4.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 25 Nov 2007, Chris Blask wrote:

> technical and marketing aspects of such things. It is
> therefore also quite defensibly true what Bill said: <sic>
> "That is on purpose".

This is the part I have serious troubles with- "on purpose" implies that
it was a pre-planned, thought-out event, not that you just didn't screw it
up by not doing anything[1]. The code bases _started out differently_ for
no reason other than the fact that the products were from different
companies, on two different platforms. To paint that fact as if it were
some sort of strategic plan does the readers of this list a disservice.

> PS - Paul R, my posts seem to again not be making the list,

The list is still moderated, it takes the moderator some time to get
through the queue...

Paul
[1] From what I recall when Cisco was repeatedly trying to get me to buy
in to the fact that PIX should be on my list of approved firewalls at
Gannett, one of the points they kept trying to make was that PIX was
getting more IOS features to make it easier for folks to deal with a
single interface- so it would seem to me that even the keeping them apart
wasn't necessarily a planned event.
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
paul@compuwar.net which may have no basis whatsoever in fact."

http://www.fluiditgroup.com/blog/pdr/

Art: http://PaulDRobertson.imagekind.com/


------------------------------

Message: 5
Date: Mon, 26 Nov 2007 07:32:00 -0800
From: "Bill McGee (bam)" <bam@cisco.com>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.cybertrust.com>
Message-ID:
<A0A653F4CB702442BFBF2FAF02C031E90529E079@xmb-sjc-21e.amer.cisco.com>
Content-Type: text/plain; charset="us-ascii"

Hi, Paul,

Here's some information around some of your questions/statements:

> Are you sure it's not just that PIX was originally BorderWare and that
> IOS runs (or ran) on m68k processors while the PIX codebase is x86?

PIX was never BorderWare. (BorderWare is STILL BorderWare, BTW. See
www.borderware.com)

You're right, though, that PIX was an acquisition. It ran on a
proprietary, hardened OS called 'Finesse.' The original plan was to port
it to IOS, as we had an IOS firewall project we were working on.
However, the market at the time really bought into the idea of a
separate appliance running its own IOS. So we instead maintained two
separate development teams, but with a great deal of cross-development.

> Chris Blask subscribes to this mailing list, you know.

I know. Chris was part of BorderWare when their firewall was first
conceived (I think he still has the original concept that he and a few
others sketched on a napkin over dinner somewhere.) My first company
hired Chris from BorderWare to manage our BorderWare reseller program.
Chris later returned the favor by hiring me to work with him as
co-Product Managers for the PIX. I'd be happy for him to chime in here.

> Are you sure it's not the difference in hardware platforms again?
> Combining IOS and PIX OS is too complicated to be worth the effort.

Complicated, yes. Too complicated? Hardly. In fact, a number of features
in the PIX and the IOS Firewall were the result of program and code
sharing between our PIX and IOS Firewall teams.

> That's OK. I'm not trying to start a flame war, but I'm a little
> offended that you didn't think anybody here would know the real
> answers.

No offense taken. Hope this clears things up for you...

-bill


PaulM
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards


------------------------------

_______________________________________________
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 23
************************************************

No comments: