[9561] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Fw: Fw: No Security is Bad Security

daemon@ATHENA.MIT.EDU (Jon Ribbens)
Sat Feb 13 17:30:40 1999

Mail-Followup-To: Jim Maze <jmaze@EZSAFE.COM>, BUGTRAQ@netspace.org
Date: 	Sat, 13 Feb 1999 17:02:17 +0000
Reply-To: Jon Ribbens <jon@OAKTREE.CO.UK>
From: Jon Ribbens <jon@OAKTREE.CO.UK>
X-To:         Jim Maze <jmaze@EZSAFE.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <366EE329.4343F4C6@ezsafe.com>; from Jim Maze on Wed, Dec 09,
              1998 at 12:52:57PM -0800

Jim Maze <jmaze@EZSAFE.COM> wrote:
> That's funny. How can the PIX be certified as conforming to any
> "Application Level Firewall Protection Profile", when the PIX is not an
> application lever firewall? As you know the PIX is based on stateful
> packet filtering - not application layer proxies.

This is wrong. The PIX has 'protocol fixups' which are application-level
filters. I cannot find any documentation on what they do, though.

> Here's the problem with the PIX, and any other packet filter - stateful
> or not. The darn things don't break the client server connections. Every
> network in the world has at least one mail server and one web server.
> With a PIX, you have to have an ACL entry that allows port 25 to the
> mail server and port 80 and possibly 443 to the web server. The problem
> is, any traffic that meets these basic requirements will pass right
> through unrestricted.

Definitely wrong. Here, for example, is a connection to sendmail via
a PIX firewall:

<<< 220 SMTP/cmap ready______________________________________________________
>>> HELP
<<< 500 Command unrecognized: "XXXX"

The PIX is replacing any data it doesn't think we need to know with
underlines, (e.g. the sendmail banner), and replacing any commands it
doesn't think are necessary with Xs.

Cheers


Jon
--
\/ Jon Ribbens / jon@oaktree.co.uk

home help back first fref pref prev next nref lref last post