Re: Outbound SMTP

["Halliday,Paul" <Paul.Halliday () NSCC CA>]

A *cough* and *chuckle* from the absolute back of the room..

A very interesting perspective that is quite misleading at times.

Once my Mom, Grandmother, TCP/IP, *Hardware Vendors and *OS jump on your
reasoning bandwagon I will happily drink your Kool-Aid.

------
Paul Halliday 
NSCC | Network Security Analyst
Tel 902.565.9057 | Fax 902.563.0511 
1240 Grand Lake Rd., Sydney, NS B1P 6J7
http://www.nscc.ca

-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Joe St Sauver
Sent: Friday, April 25, 2008 12:15 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Outbound SMTP

Matt mentioned:

#I have been considering approaching management to just block all port
25
#traffic.  My holdback is that I feel bad for anyone that has their own
#domain somewhere and sends mail through it.  We do not allow students
to
#relay SMTP mail through our mail servers.

At the risk of disrupting the chrous of support that's been expressed so

far when it comes to blocking outbound port 25 traffic, I feel compelled

to wave my hand from the back of the room and express disagreement.

Earlier this week, I did a talk at the Internet2 Member Meeting on 
"Cyberinfrastructure Architectures, Security and Advanced Applications"
(slides available at www.uoregon.edu/~joe/architecture/architecture.pdf
).

One of the themes you'll see in that talk is that higher ed is doing
*too much* blocking via things like perimeter firewalls, and that we're
getting to the point where firewalls are actively interfering with
advanced
applications, and that in fact, just as we currently have security
officers
and privacy officers, we probably ALSO need, or shortly will need,
"network 
usability officers" just to balance out the efforts of security officers
and privacy officers. I mean dang it all, we build wonderful networks,
and
then we proceed to block the heck out of 'em to the point where
application
programmers can hardly use 'em! That just makes no sense.

It is so tempting to say, when confronting any security risk, "block
it."
But as easy and tempting as that may be, it is neither the only option
nor
necessarily always the right option.

Consider blocking port 25 (except for traffic sent through authorized 
campus mail servers). This is actually a recommendation that's
consistent
with the recommendations of the Messaging Anti-Abuse Working Group
(MAAWG),
(see http://www.maawg.org/port25 ). Nonetheless, it is a recommendation
that I disagree with... why? Well, let me just share a few reasons of 
many...

1) Even if you block port 25 traffic, the host is still infested

   You may be able to stop the immediate problem of the host spewing
spam
   by blocking port 25, but by doing so you're just suppressing the
symptom
   of the problem, you're not curing the disease -- it is like giving
cough
   syrup to a lung cancer patient! You need to clean up the infected
host,
   because if you don't, even if you *do* block port 25 traffic, that 
   system can still:

   -- be used as a spammer fast flux web server or DNS server,
   -- participate as part of a DDoS attack network
   -- sniff traffic
   -- engage in click fraud
   -- act as a stepping stone inside your perimeter

   or otherwise cause a substantial amount of problems for you and
others
   on the Internet. You need to clean up infected hosts.

2) There are other ways you can express your preference about where mail
   should be originating

   Prefer that mail only come from your authorized mail servers? Okay,
   have you published an SPF record describing that? No? Well, if you 
   don't, even if you control port 25 traffic at the perimeter of your
   network, you've done NOTHING to control SMTP traffic that's 
   pretending to be "from you" even though it is originating elsewhere.

3) If you force all email traffic through your campus mail servers,
   recognize that you are explicitly adopting an "all your eggs in 
   one basket" strategy

   By this I mean, assume that spammers compromise a machine on your
   campus and begin spewing through your campus mail servers. For
   whatever reason, this is not immediately clamped, and the traffic
   hits some major service providers or block list spamtraps. Bang,
   your campus mail servers end up getting block listed at those 
   major service providers or by the block lists your spammer happened
   to hit. I suspect that this will be a bigger deal than just having
   some of your dynamic IPs blocked or listed, eh?

4) Having all your eggs in one basket is more than a reputation issue,
   however

   Having all your eggs in one basket means that you may have a single
   point of failure. Having all your eggs in one basket may mean that
   you sacrifice privacy and lose a little freedom. Having all your
   eggs in one basket may mean that you're stuck with one vendor's
   "solution" or another, and its quirks and oddities (and yes, they 
   all have them). Having all your eggs in one basket may mean that
   suddenly your email is subject to maximum message size limits, or
   if there are no limits, your two line reply is stuck behind "mail"
   carrying a 68MB PowerPoint attachment. And then there are those 
   questions about usability, and scalability... I think I see why some
   folks are outsourcing their campus email...

5) Blocking port 25 (only) is a point solution to a more general problem

   Having blocked port 25, you will find (surprise!) that doing that
   does not make all your other problems go away. For example, consider
   DNS-oriented attacks. If you don't also control port 53 traffic, 
   the bad guys may be able to freely repoint your users' DNS settings
   to use their untrustworthy DNS servers rather than your own. So now
   you step up to the plate, and add controls on port 53, another point
   solution for a specific problem. But that's still not enough...
   what about a miscreant who changes your user's proxy server settings,
   or users who are clicking on come-and-get-it malware download links
   they find on web pages or in their mail? Better block all web traffic

   except traffic that goes through the campus proxy servers (with A/V
   filtering). And then there's all that problematic P2P traffic! More 
   blocks, we need more and more and MORE blocks!

   And that, my friends, is how we totally lose Internet transparency,
   and that's why increasingly you see traffic that looks like either
   "everything over port 80" or everything smeared over every still-open
   port that still exists (and yes, I've got a talk to back up that 
   thought, too, see "A Look at the Unidentified Half of Netflow,"
   http://www.uoregon.edu/~joe/missing-half/missing-half.pdf )

A Prediction

I predict that before too long, we're going to have "outbound VPNs."
That 
is, there will be VPN concentrators outside the firewall, in the DMZ,
not 
meant to terminate connections from roaming users, but meant to allow a 
few authorized "elite" *internal users* to get past the virtually 
all-encompassing Internet blocks on direct access to anything external.

But as we move in that direction, be clear about what we're giving up.
Internet transparency isn't just a nice idea, it is a foundation of what
the Internet's all about. Internet transparency is what makes new
applications possible. Internet transparency means that H.323 works 
(which may not be true if you have a firewall in the way, H.323 firewall
traversal "fixes" notwithstanding). Internet transparency means that
computational grids can exist, and that bulk scientific file transfers 
will not be constrained by the throughput of many firewalls.
Internet transparence also enables end-to-end encryption, and end-to-end
encryption is the foundation of privacy online. 

A real test will be to see how heavily firewalled sites deal with IPv6!

And An Empirical Comment

You can also use things like Senderbase.org to SEE who's limiting campus
SMTP traffic and who isn't -- just search for a domain of interest.

Although you may get the impression that "everyone" is blocking port 25
traffic at their border (except for authorized servers) that's simply
not the case. Some sites that don't have a right hand column that's all
green, others have a right hand column that's all pink, and some have
a right hand column that's in between. It's all a matter of how closely
you instrument your network/how much attention you pay to complaints, 
and how quickly you deal with problems when/if they do arise. 

Regards,

Joe St Sauver (joe () oregon uoregon edu)
http://www.uoregon.edu/~joe/

Disclaimer: All opinions expressed are solely my own.