From nanog-bounces@nanog.org Wed Sep 3 11:58:37 2008
From: Alec Berry <alec.berry@restontech.com>
Subject: Re: ingress SMTP
Michael Thomas wrote:
> I think this all vastly underrates the agility of the bad guys. So
> lots of ISP's have blocked port 25. Has it made any appreciable
> difference? Not that I can tell. If you block port 25, they'll just
> use another port and a relay if necessary.
I'm pretty sure it has, although without aggregate stats from various
ISPs it is hard to tell. Since mail transport is exclusively on port 25
(as opposed to mail submission), a bot cannot just hop to another port.
One small data-point -- on a personal vanity domain, approximately 2/3 of
all the spam (circa 15k junk emails/month) was 'direct to inbound MX'
transmissions. The vast majority of this is coming from end-user machines
outside of North America. China, India Thailand, Brazil, Poland, "CZ", and
a couple of providers each in Germany and France, appear to be the most
prevalent sources _I_ see.
The message count would be a fair bit higher, but I have several overseas
networks (4 in DE, 2 in TW, 1 in CZ) plus pieces of 2 domestic networks
(*da.uu.net, *pub-ip.psi.net) blocked at the firewall. Also firewalled are
a couple of dozen IP addresses that have -each- made over 10k attempts
to _relay_ mail through me.
I'm seeing a significant amount of 'Received' header forgery, apparently
intended to fool "dumb" header parsers into believing the direct-to-MX
transmission _did_ go through the server associated with the domain used
in the '"from: ", "from ", and "Reply-to: " lines. The good news is that
only a _really_ dumb parser would be fooled by most of what I'm seeing. 
Robert Bonomi wrote:
One small data-point -- on a personal vanity domain, approximately 2/3 of
all the spam (circa 15k junk emails/month) was 'direct to inbound MX'
transmissions. The vast majority of this is coming from end-user machines
outside of North America.
This confirms the limited data I have. I configure my edge firewall (pf)
to drop anything to/from the Spamhaus DROP list, as well as sendmail to
use their XBL. The DROP list seems like it blocks mostly MX lookups
(nice to see the blocking of mail start so early in the process!), so it
is hard to say how many SMTP connections never happen (remote server/bot
does not know where to connect). The XBL list, which is mostly
residential IPs around the world, seems to be the single most effective
technique in blocking incoming traffic-- on port 25. Obviously, these
connections are coming from ISPs that do *not* block egress TCP 25.
Slightly off topic-- I found it quite easy to configure the DROP list to
work with pf (or is that the other way around?). I would be happy to
share the small Perl script that updates the pf table. When I configured
the DROP list on a free public wireless system I maintain, I was amazed
at how much egress traffic it blocked-- obviously rogue/bad/evil
webservers, IRC hosts, etc.
I wonder if anyone else is using it that way?
...
alec
- --
`____________
/ Alec Berry \______________________________
Senior Partner and Director of Technology \
PGP/GPG key 0xE8E9030F |
http://alec.restontech.com/#PGP |
-------------------------------------------|
RestonTech, Ltd. |
http://www.restontech.com/ |
Phone: (703) 234-2914 |
\___________________________________________/
In article <48BFE61F.8040509@restontech.com> you write:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert Bonomi wrote:
One small data-point -- on a personal vanity domain, approximately 2/3 of
all the spam (circa 15k junk emails/month) was 'direct to inbound MX'
transmissions. The vast majority of this is coming from end-user machines
outside of North America.
This confirms the limited data I have. I configure my edge firewall (pf)
to drop anything to/from the Spamhaus DROP list, as well as sendmail to
use their XBL. The DROP list seems like it blocks mostly MX lookups
(nice to see the blocking of mail start so early in the process!), so it
is hard to say how many SMTP connections never happen (remote server/bot
does not know where to connect). The XBL list, which is mostly
residential IPs around the world, seems to be the single most effective
technique in blocking incoming traffic-- on port 25. Obviously, these
connections are coming from ISPs that do *not* block egress TCP 25.
You do realise that there a mail clients that check MX
records *before* submitting email (or before on sending the
email) so that typos get detected in the client before any
email is sent from the client.
But you would never see those false positives. I know they
exist because I've experienced them because I work from
home and even though I tunnel email out via the office
servers I prefer the typos to be caught locally.
I doubt this will change your mind but it might stop someone
else from making a bad decision to do what you are doing.
Mark
Mark Andrews wrote:
You do realise that there a mail clients that check MX
records *before* submitting email (or before on sending the
email) so that typos get detected in the client before any
email is sent from the client.
I think you are not familiar with the difference between the DROP list
and the XBL. The DROP list is *not* an RBL!
I do not allow any traffic at all to or from the DROP list-- including
MX lookups. I can't think of any good reasons why I would.
The XBL is used only to block mail transport-- it is configured in
sendmail, not at the firewall. The scenario you lay out will still work:
- - end user on a dial up that happens to be on the XBL (common)
- - end user queries MX records, either directly or via their name server
- - end user submits mail to their SMTP server (not on the XBL)
- - SMTP server transports mail to my system
Unless one of those systems mentioned above is a hijacked name server in
Kyiv (and thus on the DROP list), everything will work.
...
alec
- --
`____________
/ Alec Berry \______________________________
Senior Partner and Director of Technology \
PGP/GPG key 0xE8E9030F |
http://alec.restontech.com/#PGP |
-------------------------------------------|
RestonTech, Ltd. |
http://www.restontech.com/ |
Phone: (703) 234-2914 |
\___________________________________________/