Re: Firewalls that generate new packets..

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

Hello!

On Tue, Nov 27, 2007 at 10:39:04PM -0500, jason () tacorp com wrote:
> If I opened up port 80 into a 
> web server and the state was tracked the reply packet would be able to 
> pass back out of the firewall without having to have a rule allowing 
> packets from the webserver sourced from port 80 out.  Why should I need to 
> put two rules in (one for the incoming traffic, and one for the reply) 
> when I can rely on the state of the packet for the reply?

Who said, you can't? But how do you know that it's HTTP that
is flowing over port 80?

You should have <something> in place that enforces that it's HTTP
and not some propriatary encrypted data stream for e.g. a bot.
Or if we change the subject to egress filtering and "trusted"
internal users, how about a proprietary encrypted "Internet telephony"
application - hm, what product to pick as an example ...? ;-)

Of course, all sorts of applications can be made "firewall friendly"
and it's possible to tunnel IP through perfectly valid HTTP
or even DNS - but as Marcus put it lately, when he corrected me on
this list - why make it easier for the bad guys?

Firewalls have never been about "ports", yet the security industry
has brainwashed everone with half an understanding of how TCP/IP
works into believing they were.

My customers keep asking me things like "internal user A wants to
run application X, vendor says it uses port Y - is this port
dangerous or can we open it up?" Well ...

Kind regards,
Patrick M. Hausen
Leiter Netzwerke und Sicherheit
-- 
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
_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards