Cisco PIX MailGuard and SMTP Banner

There is an RFC requirement that MTAs return '220 hostname' upon the initial connection. With the smtp fixup protocol enabled it returns 220

****.

  1. Is it possible to meet the RFC with this fixup enabled?

  1. If not, what are the security implications of turning this off?

Thanks.

Reply to
Seeker
Loading thread data ...

Please see following TID::

formatting link
Exchange is using ESMTP not SMTP, the mailguard feature is blocking the ESMTP command. I believe in PIX OS 7.X this has been fixed.

HTH,

Chad

Reply to
Chad Mahoney

Thanks for the reply, but this is not an Exchange issue. The question is of a general RFC/risk nature.

Reply to
Seeker

you are correct as said in the TID also says cisco has released a fix for this.

/quote/ Cisco has corrected this issue in later software releases. Customers who do not want to turn off Mailguard must contact Cisco for the latest updates to the PIX operating system. /end quote/

as said in the TID a well secured server will not have any problems. you are opening SMTP to the server as long as the server is not an open relay I would not see a problem.

/quote/ The Mailguard feature is intended to help protect weakly secured mail servers /end quote/

/quote/ Mailguard allows connections to an e-mail host through Transport Control Protocol (TCP) port 25 only. It logs all Simple Mail Transfer Protocol (SMTP) activity and allows only the minimum SMTP server commands found in Request for Comments (RFC) 821, Section 4.5.1. /end quote/

Reply to
Chad Mahoney

It depends on how much of an RFC lawyer you want to be. It appears that someone is pretty picky, as I don't recall anyone ever raising this issue before.

If you want to argue back, you could use the fact that RFC 821 uses the qualifier "usually" in describing originating the 220 connection message. This could be one of the times that isn't "usual" -- and if your implementation happens to throw in a gratitutious 220 message with a different format, then so be it ;-)

In a follow up you spoke of "risk". There is a security risk in leaving the hostname exposed. If someone does a portscan looking for smtp servers, it is better that you don't tell them who you are, at least not until you have more reason to trust them.

Other than that, if the smtp fixup is enabled, then it restricts permitted commands to a relatively small subset of SMTP, with no ESMTP extensions, and it restricts command lengths, but it does not restrict the length of anything within a DATA flow. The questions then becomes "Do you trust that your mail server would be able to handle commands of indefinite length", and "Do you trust that your mail server would be able to handle arbitrary unfiltered commands, possibly including obscure ESMTP features?"

The smtp fixup is good for the mail servers of days gone by, which might have included accessible DEBUG features (sometimes it just isn't feasible to update a computer more than every couple of decades...). Modern mail server bugs are -usually- more subtle. e.g.,

Sendmail 8.13.7 is available (2006-06-14); it contains a fix for a potential denial of service problem caused by excessive recursion which leads to stack exhaustion when attempting delivery of a malformed MIME message.

That's going to get by PIX mailguard anyhow.

There -have- been occasional mail server security issues in the last few years that PIX mailguard would have blocked... just has there have (for example) been BIND9 security issues involving features that earlier BIND versions didn't have at all. risk vs utility...

Reply to
Walter Roberson

The RFC states that the text of SMTP replies is only for human users (i.e. to troubleshoot) and are not required for the operation of an MTA.

Since most MTAs like to tell the whole world their version number, minor revision number, OS and patch level of the OS, giving hackers more info than they require, Mailguard changes all non-numerical replies to xxx to hide that info from the outside world. Mailguard also disables many SMTP commands to prevent additional data leakage (EXPN and VRFY, for example).

The risk of turning Mailguard off is that your MTA is then naked on the Internet. If you know your stuff and use an MTA that does not have

984574372643 known vulnerabilities, then go ahead.

The only two problems I have seen with keeping Mailguard on, is (a) that unless you run PixOS 7, you can't use any of the ESMTP commands of RFC2821 and (b) the Pix will eat messages that have the . combination split between two packets *and* where the receiving party replies to the frist half of the combination with a "250 Message accepted".

Reply to
Francois Labreque

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.