yes. there are a lot of pix firewalls out there with smtp fixup turned on, effectively disabling ESMTP (not to mention sporadically breaking traditional SMTP.)

Could you elaborate on this? I use PIX firewalls all over the place and don't seem to have a problem with SMTP or ESMTP. Rob Nelson ronelson@vt.edu Rob Nelson ronelson@vt.edu

On Sun, 28 Mar 2004 08:59:40 -0500 Rob Nelson <ronelson@vt.edu> wrote:

...

yes. there are a lot of pix firewalls out there with smtp fixup turned on, effectively disabling ESMTP (not to mention sporadically breaking traditional SMTP.)

Could you elaborate on this? I use PIX firewalls all over the place and don't seem to have a problem with SMTP or ESMTP.

then you must have smtp fixup disabled. when smtp fixup is on (default on many older pixes, i gather that there may be some improvements on newer pixes), the smtp banner is mostly obscured by * characters. the intent is a classic security by obscurity play, to hide the type and verison of the MTA behind the pix. the problem is two fold: 1) it obscures so much of the banner that any ESMTP advertisement in the banner is hidden, so the SMTP client doesn't know that it can EHLO. for standards compliant MTAs, the result is a default to the minimal SMTP standard mode of operation, and options such as SMTP over TLS are never negotiated even when both the SMTP client and server are "ready to go". 2) it turns out that the * obscurity ploy is badly done, and while it hides enough of the banner to break ESMTP, it doesn't hide enough of the banner to reliably obscure the MTA in use. even if security by obscurity were a good idea (i, and many others, maintain that it is not), broken security by obscurity is annoying beyond belief. on more than one occasion, i've had clients ask me to investigate why they're having obscure problems with email transactions. in many cases, i've found that telneting to port 25 on the SMTP server end has produced the "wall of asterisks", and that having them turn off smtp fixup on the pix invariably cures the problem. it's sufficiently frequent that it's generally the first thing i check for these days (it's also first because ruling it in or out is very quick.) richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security

On 3/28/2004 9:57 AM, Richard Welty wrote:

before i write an extended explanation of why i don't like this idea much, i'd very much like to hear some of the motivation behind the proposal.

It wasn't a proposal, it was a request for data. My own local data suggests that HELO is almost exclusively used by malware agents (modulo the internal appliances and user agents, which is why I referenced the local exceptions). I'm mostly wondering how representative that is. It might be feasible for some of us to disable legacy SMTP entirely. Nothing is universal, of course, and what works for me and my domains obviously wouldn't work for ~Hotmail or other large-scale providers. But since I don't manage those networks, they are not part of my local decision process either. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/

On Mar 28, 2004, at 10:44 AM, Eric A. Hall wrote:

To be more realistic (and to close-in on any 'proposal' which might subsequently develop), it would likely be far more feasible to assign somewhat agressive negative weighting to sessions that use HELO (and further possible to assign mild positive weighting to sessions that use properly-formed EHLO), such as for use with session-wide rejects.

This solution might work/help for what, maybe a week? Spammers are scum but they aren't dumb. I would imagine that posting this technique to NANOG just made it totally worthless. Look for malware to start being ESMTP compliant in a few hours, days or maybe a week if the spammers are too busy laughing at our complete and total collective failure at dealing with them effectively to put down their pina colada's to code the fix. Cynical? maybe. True? Sadly I think it is. Thanks, david ulevitch

On Mon, 29 Mar 2004 07:20:47 -0500 Rob Nelson <ronelson@vt.edu> wrote:

Richard Welty wrote:

...

when smtp fixup is on (default on many older pixes, i gather that there may be some improvements on newer pixes), the smtp banner is mostly obscured by * characters. the intent is a classic security by obscurity play, to hide the type and verison of the MTA behind the pix.

Okay, so this is a problem when an SMTP server is hosted behind the PIX?

yes.

I thought the fixup statements were for outbound connections, and with it on right now I get the full banner from SMTP servers. I don't host an SMTP server myself, so can't check that.

nope, they mangle inbound connections too. in addition to the banner obscuration, i (and others) have seen patterns of intermittant, arbitrary disconnections of SMTP sessions when fixup is turned on. this is harder to diagnose, though, because there is a TCP bug in some variants of Outlook that causes similar behavior. those of us running exim as an MTA a couple of revs back had to patch our installs to work around the Outlook TCP bug. i believe that patch is now permanently part of exim, as it is unlikely that the Outlook bug will ever entirely go away. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security

At 07:20 AM 3/29/2004, Rob Nelson wrote:

...

when smtp fixup is on (default on many older pixes, i gather that there may be some improvements on newer pixes), the smtp banner is mostly obscured by * characters. the intent is a classic security by obscurity play, to hide the type and verison of the MTA behind the pix.

Okay, so this is a problem when an SMTP server is hosted behind the PIX? I thought the fixup statements were for outbound connections, and with it on right now I get the full banner from SMTP servers. I don't host an SMTP server myself, so can't check that.

SMTP fixup is for hosts behind the firewall. That is after all what it's trying to protect (in theory) by mangling the SMTP protocol. :) Vinny Abello Network Engineer Server Management vinny@tellurian.com (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.