Re: Firewalls breaking stuff: [Was re: fwtk]

["Charles W. Swiger" <chuck () codefab com>]

On Thursday, July 18, 2002, at 05:57  PM, Marcus J. Ranum wrote:
> Charles W. Swiger wrote:
> > To focus more on topics more relevant for this list, one of the biggest 
> > problems certain firewalls and mail proxies have is that they break the 
> > SMTP protocol.  For example, Cisco's PIX (with MailGuard?) attempts to 
> > proxy SMTP and breaks the state machine defined in RFC-821 or -822, as 
> > well as preventing ESMTP and violating the SMTP banner requirements.
>
> This comes up periodically - and it's the focus of considerable stress 
> for firewall
> product builders who care about security. What should a firewall do with 
> things
> that are specified in an RFC that are stupid? Obviously, something has to 
> break.

Yes, there are times when you have to decide between security and 
functionality or backwards-compliance with older protocols.  Is there any 
convincing reason to believe that Cisco's MailGuard SMTP implementation is 
more secure just because it breaks ESMTP?

> Historically, I've never felt remorse over violating RFCs where they are 
> stupid.

Nor should you.  Please explain why SMTP AUTH or performing SSL-based 
encryption of mail en transit via STARTTLS is "stupid" rather than 
important functionality which improves security?

If you also provide SSL-based IMAP (993/tcp), you can provide email access 
for remote employees where their usernames, passwords, and the mail itself 
is never sent in plain text.  That seems quite worthwhile to me.

> When I broke FTP bouncing in fwtk and broke FTP server side low-port 
> binding,
> I had a flurry of complaints that I was trampling on RFCs. I believe that 
> I was
> retroactively fixing them - standards are not something handed down by a
> priesthood; they're just advice from a bunch of standards pukes who "do 
> not
> address security"   If you're trying to address security it's entirely 
> acceptable
> and, indeed, the only option, to implement a subset of a dangerous 
> protocol.

Someone capable of implementing SMTP correctly is more likely to produce 
secure code than someone not capable of implementing SMTP correctly.  
Microsoft wasn't willing (or competent enough) to implement SMTP according 
to the RFCs, either.  Oddly enough, M$ Exchange and M$ Outlook aren't well 
known for the security improvements they've brought to electronic mail.  :
-)

Let me repeat a private remark I made: while a program might be easier to 
audit because it doesn't have a lot of source code, there's little reason 
to assume that a security problem is going to be less severe just because 
you've removed a lot of functionality.
If you really try you can screw up SMTP badly enough to lose mail, but it'
s easier and more secure to disconnect the ethernet cable on the MX box, 
or filter port 25 entirely.  It's not clear that Cisco's SMTP 
implementation is any less broken than that of Microsoft Exchange.

-Chuck

       Chuck Swiger | chuck () codefab com | All your packets are belong to 
us.
       
-------------+-------------------+-----------------------------------
       "The human race's favorite method for being in control of the facts
        is to ignore them."  -Celia Green

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards