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.. (Darren Reed)
2. Re: Firewalls that generate new packets.. (Patrick M. Hausen)
3. Re: Firewalls that generate new packets.. (Darden, Patrick S.)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Nov 2007 15:54:44 -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>, sil@infiltrated.net
Message-ID: <474DFFC4.7080804@Sun.COM>
Content-Type: text/plain; format=flowed; charset=us-ascii
J. Oquendo wrote:
>...
>On the flip side of this whole argument right here... Coming from an attack
>vector, I've pretty much shut down (local and remotely) three of the five
>firewalls I mentioned with a DoS tool I wrote that is being looked at by 2
>of the five mentioned. Isn't that ironic... Here they are protecting, yet
>here they are all vulnerable at the bottom of it all. I cannot, will not
>post any coding probably ever because I do not believe there are fixes
>(legacy TCP thing I believe). PSIRT has tinkered with it for the past 60+
>days without a resolution. The other vendor solely sent a generic "eye eye
>Spock we will look at it!" but my guess is they'd rather spend money on
>inviting us all to continental breakfast and a movie (hey you got that
>too!)
>
>To be fair to firewall vendors about this attack though, it pretty much
>shuts down anything connected period, from a DSL --> DS3 goodbye. So I
>guess it would be fair to state that as opposed to seeming as if I'm
>pointing a finger at the entire firewall industry.
>
>
This kind of attitude really annoys the heck out of me.
There are more people that care about hearing about these styles
of problems than those 5 companies.
Put up or shut up - at present, what you're describing sounds like
something you can talk about to make yourself seem clever as
there is no acknowledgement from anyone else that what you've
thought of works.
It's highly doubtful that you've run across something that nobody
else has and email like this does nothing except spread FUD.
Darren
------------------------------
Message: 2
Date: Thu, 29 Nov 2007 09:19:44 +0100
From: "Patrick M. Hausen" <hausen@punkt.de>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Darren Reed <Darren.Reed@Sun.COM>
Cc: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20071129081944.GA56743@hugo10.ka.punkt.de>
Content-Type: text/plain; charset=iso-8859-1
Hi, Darren,
> So what you're really comparing is the default configuration
> of packet based firewalls with proxy based firewalls.
Well, yes.
When engaged in selling Secure Computing gear, I always
put an emphasis on the "more reasonable default configuration"
and the fact that it's more complicated if not impossible to do
something stupid by accident.
I also take my time to carefully explain the concept of egress
filtering.
E.g. does PIX still have these implied rules that say: if I
configure port X from here to there, this automatically implies
the same access to all interfaces with a lower security level than
'there'? This is the case in 6.x - now, whoever at Cisco came
up with this concept should be shot.
I have not looked at 7.x or ASA, yet.
Kind regards,
Patrick M. Hausen
Leiter Netzwerke und Sicherheit
P.S. I know that PIX access lists do not implement stupid things like
the above, but PIX Device Manager does. Now, which is a customer
with limited time and knowledge more likely to use?
--
punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
info@punkt.de
http://www.punkt.de
Gf: J?rgen Egeling AG Mannheim 108285
------------------------------
Message: 3
Date: Wed, 28 Nov 2007 09:08:34 -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: <CBE22E5FF427B149A272DD1DDE1075240184E5B4@EX2K3.armc.org>
Content-Type: text/plain; charset="iso-8859-1"
I disagree slightly with what you say. Squid can do the
following security oriented things:
0 sanitizes http commands going through it (dos, espec
unintentional doses by corrupt clients or bad networks)
0 can limit sizes to limit buffer overflows
0 can anonymize or even edit headers to limit access to
user-agent, link, www-authenticate, referer, from, server,
accept-charset, etc.
0 filter out known signatures for malware such as pop-ups,
hijack scripts, cross-site scripting, etc.
That's just what I can think of off the top of my head.... You
can use Squid as an outgoing proxy for your users, or an incoming
cache for your servers, and both ways would provide different
security possibilities.
I am NOT saying Squid is the end-all be-all, not even advocating
its use at all. I was merely using it as an example of an
application proxy. SOCKS might make more sense than Squid,
from a purely security perspective....
--p
Marcin Antkiewicz
> 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.
------------------------------
_______________________________________________
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 34
************************************************
No comments:
Post a Comment