Re: Intrusion Prevention Firewall

["Patrick M. Hausen" <hausen () punkt de>]

Hi all!

Gary Flynn wrote:

> > A firewall which is policy enforcement device with respect
> > to traffic passing from your internal network to the Internet
> > and vice versa, right?
>
> Within the limits of the capabilities of firewall technology.

Aye, there's the rub ... ;-)

> What if my policy is that I wish to allow all ssh traffic
> except that which is trying to exploit an openssh buffer 
> overflow? We've got new research collaborations all the time.

I wholeheartedly agree with you in that case. I just don't come
to the same concluisons ...

> Or allow all http traffic except that which is trying to
> access cmd.exe or *.ida?
>
> Or allow all RPC-portmap traffic except that which is trying
> to overflow statd?

> [... more good and valid examples ...]

> Better to get a better educated armed guard. If the armed guards 
> instructions are simply to only allow company trucks and people with 
> passes and only to the visitors center or warehouse a relatively 
> simple firewall will do the job assuming both the warehouse and
> visitors center are hardened. But not all networks or organizations 
> are designed as closed systems. They want the full capabilities of
> the communications system we call the Internet. They want to allow
> their constituents, who may not always have the most hardened systems
> whether because of training, time, or the vendor's focus on ease of
> use rather than security, full communications access but still provide 
> them some protection. Those organizations need more capable 
> guards...i.e. an IPD.

But the IPD is not armed - most IPDs today are mainly surveillance cameras.
These _are_ of a lot of value - sometimes you're hit and need to
know just what happened. Firewall logs are most often not enough.

But ... do all these points call for an additional type of appliance
with additional problems or does it just show how poor current firewalls
actually are?

All the examples you provided should IMHO be handled by a _proper_
application level proxy which is built to the protocol spec, uses
safe coding techniques and is verified by peer review and testing
to the spec.

Just think, what you'd get: no sshd buffer overflow, no rpc.statd
exploit ...

And in the case of cmd.exe called via HTTP: your website should have a
spec that states which paths are to be considered part of the legal
documents, too. Then an HTTP proxy could be configured to that
spec.

This is just proper engineering and done in any field but ours,
so it seems :-(
And I don't think that another deus ex machina is going to fix that.
We'd have to build _systems_ from _specifications_ employing
_scientific_ methods from the ground up. But somehow nobody's
buying into that.

Again: there is still a point for IDS, but IMHO it's not the one,
you made.
Like an internal host is infected with Nimda by some means that doesn't
need to penetrate the "front door" and then said host starts scanning
the net - the firewall will happily pass the requests and quickly come
to a grinding halt with thousands of proxy processes running.
This happened to one of our customers - I would have been glad if I had
had an IDS at hand then. But: this is aftermath! The workstations
of about a dozen developers had already been infected.

Thanks for listening,

Patrick M. Hausen
Technical Director
-- 
punkt.de GmbH         Internet - Dienstleistungen - Beratung
Scheffelstr. 17 a     Tel. 0721 9109 -0 Fax: -100
76135 Karlsruhe       http://punkt.de
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards