I'm wondering if the installed base of legitimate messaging systems has
migrated to ESMTP so as to get away with disabling plain-old SMTP except
for internal devices.
Anybody got any data or observations on this?
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.)
richard
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
[3/28/2004 7:29 PM] Rob Nelson :
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.
Check whether "smtp fixup" is enabled - and if it is, disable it using
# no fixup protocol smtp 25
Test the results (from an outside host, using netcat / telnet to port 25) to see for yourself.
Briefly, a pix doing "smtp fixup" -
* Munges the smtp banner entirely with ***** (that breaks an rfc or two)
* Disables ESMTP (so EHLO will not be accepted)
* Munges several replies returned by the mailserver, turning them to XXX
srs
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
i should add that i think that this proposal is a bad idea for any
number of reasons, but this cisco pix thing is very concrete
so i just wanted to get it out there.
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. i don't see where a client that gives EHLO
and then doesn't negotiate any options is any different from a
client that gives HELO, so i just don't see what refusing to
accept email from HELO clients is supposed to buy you.
on the server side, i don't see what refusing to send email
when you don't see ESMTP in the banner accomplishes
either.
in either case, such a policy would only last until a VP
figures out that you're responsible for his inability to
exchange email with his mistress.
richard
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.
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
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.
Rob Nelson
ronelson@vt.edu
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
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.
[3/29/2004 6:00 PM] Richard Welty :
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
Older pixes had a major issue with MTU path discovery that'd cause email to be repeatedly resent.
http://archives.neohapsis.com/archives/postfix/2001-06/1198.html for example.