Tuesday, November 27, 2007

firewall-wizards Digest, Vol 19, Issue 26

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.. (Marcus J. Ranum)
2. Re: Firewalls that generate new packets.. (Paul D. Robertson)
3. Re: Firewalls that generate new packets.. (Anton Chuvakin)
4. Eggs in one basket (VPN in Firewall, UTM) (Bill Stout)
5. Re: Firewalls that generate new packets.. (Darden, Patrick S.)
6. Re: Firewalls that generate new packets.. (jdgorin@computer.org)
7. Re: Firewalls that generate new packets.. (Cat Okita)


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

Message: 1
Date: Tue, 27 Nov 2007 11:14:22 -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.20071127104300.046fa018@ranum.com>
Content-Type: text/plain; charset="us-ascii"

Paul Melson wrote:
>State tables allow your firewall to have a deny-all
>default inbound policy and an allow-all default outbound policy.

Thanks for playing. A router with "established" SYN/ACK
filtering gives you exactly the same thing, with basically
the same degree of assurance.

If all you're doing is setting up a "one way mirror" style policy
it's a no-brainer. If you're allowing incoming traffic to targets
behind the firewall then it's a layer-7 problem for the service
on the target - unless the firewall is doing some additional
layer-7 security. (hint: regexp match causes packet drop
is "deep packet inspection")

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. Yet, because they
have been so effectively marketed, they have been accepted
as terms of art without any examination at all. Kind of like
the way "alternative medicine" has been accepted as
"medicine" without passing the all-important stage at
which it has to prove it actually does something. That
is exactly why I used the term "placebo" for "stateful
inspection"; accupuncture patients report the same degree
of improvement in controlled studies as patients that
receive fake accupuncture. If a network protected by a
correctly configured router+ACLs and layer-7 controls
is just as safe as a network protected by a correctly
configured "stateful inspection" firewall and layer-7
controls then what does that tell you?

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. What
happens if I send a packet to a target that has ACK
set but that is not part of a TCP stream that has been
established in the target's IP stack? Compare and contrast
this with what happens if I send a packet toward a "stateful"
firewall that is not part of an established stream. Second
question: what does the "stateful" firewall do if the
un-established packet (i.e.: not associated with a known
stream) comes at it from the "authorized" side of the network
or interface or IP range?

By exploring questions like these, we can realize what a
"stateful inspection" firewall actually does. I don't expect to
change anyone's mind on this topic. After all, homeopathy,
accupuncture, chiropractic, energy therapy, etc - have been
revealed as placebos for decades, yet huge amounts of
money are still spent on them because anecdotal evidence
carries a great deal of weight in human affairs. After all, who
has done side-by-side comparisons between "stateful inspection"
firewalls an just a plain old router? Everyone always does
side-by-side comparisons between various brands of firewalls -
and all they can think of to measure is performance. Doesn't
that tell you something? If you have a device that purports
to do security, and you can't measure anything about its
purported security properties, shouldn't that peg your
skeptico-meter?

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 can easily enumerate the "inspection" done by early
Checkpoint firewalls. It was "inspecting" the FTP command
stream for lines beginning with "PORT...." and dynamically
opening a return-hole rule for the ( source, destination ) pair.

mjr.

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

Message: 2
Date: Tue, 27 Nov 2007 12:45:08 -0500 (EST)
From: "Paul D. Robertson" <paul@compuwar.net>
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.44.0711271242310.25225-100000@bat.clueby4.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 27 Nov 2007, Paul Melson wrote:

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

Paul
-----------------------------------------------------------------------------
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: 3
Date: Tue, 27 Nov 2007 11:43:19 -0800
From: "Anton Chuvakin" <anton@chuvakin.org>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.icsalabs.com>
Message-ID:
<b2591e2e0711271143w505fee28te3fe951568c0e05a@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

This adds some fun fuel to this fire:
http://rationalsecurity.typepad.com/blog/2007/11/take5-episode-7.html

"I think that a more important trend in network security today is the
move from port-centric to application-centric classification
technologies. This will make most of the existing products obsolete,
similar to the way stateful inspection has made its predecessors
disappear from the world."


--
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA

http://www.chuvakin.org

http://chuvakin.blogspot.com

http://www.info-secure.org


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

Message: 4
Date: Tue, 27 Nov 2007 11:25:39 -0800 (PST)
From: Bill Stout <billbrietstout@yahoo.com>
Subject: [fw-wiz] Eggs in one basket (VPN in Firewall, UTM)
To: firewall-wizards@listserv.icsalabs.com
Message-ID: <935176.99480.qm@web31803.mail.mud.yahoo.com>
Content-Type: text/plain; charset=us-ascii

Hello all,

I'm evaluating an existing VPN infrastructure, and am looking at replacement options that can support IPSEC and SSL.

Currently VPN appliances are used for site-site and remote access. One of the options is to make use of the VPN capabilties of existing (SYN/ACK semantic type) firewalls.

What is the current opinion of adding more services to a firewall vs. deploying standalone VPN appliances?

Also, what is the current best practice as far as controlling who can get to what via the VPN? (e.g.contractors, vendors)

Thank,

Bill Stout


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

Message: 5
Date: Tue, 27 Nov 2007 13:47:41 -0500
From: "Darden, Patrick S." <darden@armc.org>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <CBE22E5FF427B149A272DD1DDE1075240184E5A9@EX2K3.armc.org>
Content-Type: text/plain; charset="iso-8859-1"

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


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

Message: 6
Date: Tue, 27 Nov 2007 19:21:19 +0100
From: jdgorin@computer.org
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: firewall-wizards@listserv.cybertrust.com
Message-ID: <1196187679.474c601f7af68@imp.free.fr>
Content-Type: text/plain; charset=ISO-8859-1


> Marcus J. Ranum wrote:
[...]
> 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 can easily enumerate the "inspection" done by early
> Checkpoint firewalls. It was "inspecting" the FTP command
> stream for lines beginning with "PORT...." and dynamically
> opening a return-hole rule for the ( source, destination ) pair.

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!

New products, new guys in town, and allways the same trouble... Nothing really
new on the Internet security side from more than 10 years!
Some old fashioned minds and ancient lurker might survived this (no)security era
;)


JDG
"Reality is that which, when you stop believing in it, doesn't go away."
Philipp K. Dick

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

Message: 7
Date: Tue, 27 Nov 2007 21:36:26 -0500 (EST)
From: Cat Okita <cat@reptiles.org>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Cc: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20071127213259.O63953@gecko.reptiles.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 26 Nov 2007, Bill McGee (bam) wrote:
> 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.

I suspect that you might decline to respond, but I'd be quite interested
in hearing your thoughts about the vulnerability implications of code
sharing between products - I've noticed that many of the recent issues
with various Cisco products appear in groups that leave me quite curious
about the extent of code and/or programmer sharing.

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet. This is the defining metaphor of my life right now."


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

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

No comments:

Post a Comment