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: Dark Reading: Firewalls Ready for Evolutionary Shift
(Bill Stout)
2. open source web application firewall (Darden, Patrick S.)
3. Re: Dark Reading: Firewalls Ready for Evolutionary Shift
(Dave Piscitello)
4. Re: Dark Reading: Firewalls Ready for Evolutionary Shift
(Darren Reed)
5. Re: Question on Cisco ASA's... do all the features slow it
down? (jacob c)
6. Re: Firewall Administration Survey (jdgorin@computer.org)
----------------------------------------------------------------------
Message: 1
Date: Mon, 10 Dec 2007 08:19:10 -0800 (PST)
From: Bill Stout <billbrietstout@yahoo.com>
Subject: Re: [fw-wiz] Dark Reading: Firewalls Ready for Evolutionary
Shift
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <896429.70782.qm@web31811.mail.mud.yahoo.com>
Content-Type: text/plain; charset=us-ascii
----- Original Message ----
> From: Kristian Erik Hermansen <kristian.hermansen@gmail.com>
> To: firewall-wizards@listserv.icsalabs.com
> Sent: Friday, November 30, 2007 6:31:33 AM
> Subject: Re: [fw-wiz] Dark Reading: Firewalls Ready for Evolutionary Shift
>
> On Nov 30, 2007 8:12 AM, George Capehart wrote:
> > Some light reading for the weekend . . . Thought it'd stir the pot a
> > bit more for the "Firewalls that generate new packets . . ." thread. ;>
> >
> > http://www.darkreading.com/document.asp?doc_id=140121&f_src=drweekly
>
> You're talking about a layer7 firewall. I almost worked for Palo Alto
> networks. They have some bright guys over there, mainly founders of
> Netscreen. They have great VC backing from the big guys, and it could
> become more mainstream, but it's not really anything new. Standard
> layer3/4 firewalling is insufficient these days, but as soon as you
> start tunneling data over ssh/ssl, then layer7 fw doesn't matter
> anyways. However, it will be interesting to see just how many bugs
> are introduced into these new devices. There is no way a company
> could implement all the common protocols properly, because even some
> vendors don't know how they work :-)
I agree, perimeter firewall isn't the answer for everything since the 'wall' can only be built so high, plus it can't read inside tunnels as you said. The firewall has to be between the O.S. and the untrusted code, since the entry points are:
1. File System [file system filters]
2. Registy [file system filters]
3. Network (also internal network and local network services) [TDI filters]
4. COM services
5. User Shell [global hooks, keyloggers]
6. System Calls [protected storage, etc]
7. Misc. other holes that access the O.S.
Good luck in getting perimeter firewalls to filter any of the above.
GreenBorder did this, and the company (mostly our development team and code) was bought by Google. Checkpoint then started experimenting with 'ForceField' (http://download.zonealarm.com/bin/free/beta/forcefield/index.html).
Bill Stout
------------------------------
Message: 2
Date: Fri, 7 Dec 2007 10:50:15 -0500
From: "Darden, Patrick S." <darden@armc.org>
Subject: [fw-wiz] open source web application firewall
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <CBE22E5FF427B149A272DD1DDE1075240184E666@EX2K3.armc.org>
Content-Type: text/plain; charset="iso-8859-1"
With all of our talk on application layer firewalls, I thought this would be appropo.
Marketing warning: http://www.linuxlookup.com/2007/dec/06/breach_securitys_modsecurity_open_source_web_application_firewall
Project Home: http://www.modsecurity.org/
Anybody used or worked on this open source web application firewall? Anybody have any details on it? I'd never heard of it until I saw the marketing blurb at lxer.com (linux portal). I would be interested in hearing of anyone's experiences with it.
>From what I have gleaned:
apache 2.x module
rule based http request and response inspection
supports: black list model (looks for known signatures of malicious requests)
white list model (excludes all but known good requests)
extrusion detection (e.g. soc sec #s)
core rule set includes
http protection
common web attacks protection
bots, crawlers, scanners, etc.
trojan detection
error hiding
alerts
xml support
regular expressions
a lot more
Thanks,
--Patrick Darden
------------------------------
Message: 3
Date: Mon, 10 Dec 2007 12:37:25 -0500
From: Dave Piscitello <dave@corecom.com>
Subject: Re: [fw-wiz] Dark Reading: Firewalls Ready for Evolutionary
Shift
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Cc: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <475D7955.50300@corecom.com>
Content-Type: text/plain; charset="iso-8859-1"
Sorry to rez this thread but I am curious.
david@lang.hm wrote:
> what you need to be able to do is to enforce valid HTTP,
This would indeed be a positive step but:
What is "valid HTTP"?
Who defines it (not being naive here but it does not seem that W3C is
the answer when tens of millions of browsers will do HTTP according to
what the vendor releases, which becomes de facto "valid").
Who asserts/certifies that client and server software comply with it?
> and work to detect the common ways of tunneling other things across it.
I don't quite know how to interpret "common ways of tunneling".
Tunneling apps in HTTP seriously broken. The logic behind an application
developer reaching the conclusion that the best way to assure that his
application port is not blocked by a firewall egress traffic policy is
to employ firewall evasion techniques is way broken. That this "clever
workaround" became common practice not only for HTTP, but that certain
apps go so far as to port probe for any open outbound path is even more
broken.
Yes, this is common, but frankly, common sucks. What makes it "beyond
sucking" is that common has become *accepted*.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dave.vcf
Type: text/x-vcard
Size: 220 bytes
Desc: not available
Url : https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20071210/d9c4aaed/attachment-0001.vcf
------------------------------
Message: 4
Date: Sat, 08 Dec 2007 09:38:35 +1100
From: Darren Reed <darrenr@reed.wattle.id.au>
Subject: Re: [fw-wiz] Dark Reading: Firewalls Ready for Evolutionary
Shift
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <4759CB6B.4030803@reed.wattle.id.au>
Content-Type: text/plain; charset=ISO-8859-1
david@lang.hm wrote:
> On Wed, 5 Dec 2007, Frank Knobbe wrote:
>
>
>> On Tue, 2007-12-04 at 15:12 -0600, Thomas Ptacek wrote:
>>
>>> [...] In pure CS terms,
>>> "doing layer 7 stuff" comes pretty close to rocket science. Read
>>> Varghese, and remember that without actual algorithms, you crash into
>>> the speed of SRAM. Even on a fancy multicore whizz-bang NPU.
>>>
>> Besides the question of how hard/accurate it is to perform
>> protocol-application-correlation, one also has to consider the impact on
>> the average administrator.
>>
>> If we start seeing firewalls where your rule set reads like:
>>
>> allow $internal_net Mozilla $external_net port_80
>> deny $internal_net InternetExplorer $external_net port_80
>> allow $internal_net gnome-meeting $external_net port_any
>> ...etc...
>>
>> ...then I would consider it breaking new ground. If the end-user of
>> firewalls can create their policies based on application rather than
>> just IP-Port pairs, then it's a shift from current network firewalls.
>>
>
> I'm not sure you really want to try and tell the difference between
> Mozilla, Firefox, Internet Explorer, Opera, Lynx, etc on the firewall
> (especially since some of these can be configured to lie and claim that
> they are others to work around broken websites)
>
> what you need to be able to do is to enforce valid HTTP, and work to
> detect the common ways of tunneling other things across it.
>
That and control the content that gets sent back to the client.
Darren
------------------------------
Message: 5
Date: Thu, 6 Dec 2007 15:17:42 -0800 (PST)
From: jacob c <jctx09@yahoo.com>
Subject: Re: [fw-wiz] Question on Cisco ASA's... do all the features
slow it down?
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <373028.65926.qm@web54007.mail.re2.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"
1) Firewall performance figures from all vendors are highly overrated on the datasheets.
2) Personally, I'm not a big fan of the PIX/ASA line for many reasons. From a performance perspective only, I'd much rather go with a Juniper Netscreen appliance or even Fortinet for pure firewall and IPS functionality. Let me say it again.. for POWER use the Netscreen. Also, the cli is very Cisco-like so it's an easy migration.
3) If you run a true UTM solution for an All-in-ONE box you might even want to look at the Fortinet box since it has great, easy-to-use management in one gui and it won't choke when you enable content filter and anti-virus scanning.
Just my three cents...:)
Brett Cunningham <cssniper22@gmail.com> wrote:
The IPS feature does slow it down. Of course the more you do with the
packets, the slower it will get. I'd still recommend the ASA with the
SSM though. For the 5510, here is the specs:
Feature
Firewall throughput Up to 300 Mbps
Concurrent threat mitigation throughput (firewall + IPS services)
? Up to 150 Mbps with AIP-SSM-10
? Up to 300 Mbps with AIP-SSM-20
VPN throughput Up to 170 Mbps
(see: http://www.cisco.com/en/US/products/ps6120/products_data_sheet0900aecd802930c5.html)
If 150 Mbps is okay, go with the SSM-10. Otherwise, the SSM 20 hardly
slows it down.
I think the ASA is a huge leap from the PIX and would suggest the ASA
over the PIX.
On 12/4/07, John G. wrote:
> hello list,
>
> we are currently running Cisco PIX 515E's with 128 Megs of RAM. the problem
> is their CPU's are getting up to high 80% usage. gone through a bunch of
> troubleshooting things and i think it is just time to upgrade.
>
> my question is do the IDS/IPS features of the ASA make it kinda slow? i
> would hate to have us upgrade to these devices just to find us in the same
> spot. what do people think of the ASA's as compared to the vaunted PIX?
>
> we were thinking of getting this model: Cisco ASA5510-SEC-BUN-K9
>
> thanks much,
> jg
>
>
> _______________________________________________
> 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
---------------------------------
Never miss a thing. Make Yahoo your homepage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20071206/cf23ca55/attachment-0001.html
------------------------------
Message: 6
Date: Mon, 10 Dec 2007 10:41:39 +0100
From: jdgorin@computer.org
Subject: Re: [fw-wiz] Firewall Administration Survey
To: firewall-wizards@listserv.cybertrust.com
Message-ID: <1197279699.475d09d32c247@imp.free.fr>
Content-Type: text/plain; charset=ISO-8859-1
Lihua Yuan [lihua.yuan@gmail.com] wrote:
>
> Jean-Denis Gorin [jdgorin@computer.org] wrote:
> >
> > To connect this message to the rolling other threads:
> > consequences of rule configuration error in a packet
> > filter (stateful or not) can be more dreadful than
> > configuration error in a proxy.
>
> I'm curious on what kind of configurations errors for
> stateful firewalls do you have in mind ?
Hi Lihua,
You can quite mess a lot of things in a stateful firewall configuration.
Mistyping errors are the more common. Other errors are misunderstanding of how
things works (than means how the FW rules engine deal with rules).
The problem is complexity: in a statefull firewall configuration, you get one
rules set for all services and hosts. In a proxy configuration, you get one
rules set for each services.
So, in a statefull FW configuration, the impact of an error is broader than the
error in a proxy configuration.
Some examples:
1/ the rules parsing order are *very* important
Example: you want to open access to a range of hosts in your DMZ else some.
You have a first "closing" rule for the "else some" followed by an "opening"
rule to the hosts' range.
If you put thoses 2 rules in the other order, you open access to the "else some"
hosts.
Same for port numbers instead of host addresses.
NB: some statefull FW use "optimization" for their rules engine. You don't know
what rules will be runned prior to another one.
2/ default implicit rules
Depend of the FW, some authorize default flow like DNS or ICMP.
I count these as errors in the "misunderstanding of how things works" category.
3/ number of rules
Some statefull FW configuration are over 1000 rules. You can't manage that
number of rules without making errors (even if you use GUI, or automatic rule
management tools).
JDG
"Reality is that which, when you stop believing in it, doesn't go away."
Philipp K. Dick
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 20, Issue 5
***********************************************
No comments:
Post a Comment