Spam relaying through secondary MX...
Timothy Brown
few days, and I notice something fairly interesting... A lot of spam
is being relaying through my backup mail-exchanger; Now I'd heard of
this sort of thing before, but hadn't actually seen it until now.
I use DynDNS.org's Backup MX service, and it's been pretty reliable
so far, it even lets me add a few RBLs, which helps a little, but
it's still missing some of the core RBLs I use.
Anyway, on to the question, I talked to someone and they recommended
adding my primary MX twice in my DNS record, in order to throw off
the spammers that were doing a mx 20 lookup first.
So, I'd have this for MX entries:
10 crossbow.timb.us
20 crossbow.timb.us
30 mx2.mailhop.org
Does this break any RFCs? Do you think it would even help? The only
way this would work is if you assumed that the spammers are hard
coded to try 20 and then 10, but, if they just go round robin from
highest to lowest it won't...
Is there any other way to prevent spam being relayed this way (short
of adding more RBLs on the secondary, or doing away with it all
together.)
One other question I have that I'll address here as well, is there
any way to force Postfix to only accept mail from hosts with reverse
IPs?
Thanks,
Timothy
Richard Holland
> adding my primary MX twice in my DNS record, in order to throw off
> the spammers that were doing a mx 20 lookup first.
>
> So, I'd have this for MX entries:
>
> 10 crossbow.timb.us
> 20 crossbow.timb.us
> 30 mx2.mailhop.org
>
> Does this break any RFCs? Do you think it would even help? The only
> way this would work is if you assumed that the spammers are hard
> coded to try 20 and then 10, but, if they just go round robin from
> highest to lowest it won't...
Why don't you do it as:
10 crossbow.timb.us
15 mx2.mailhop.org
20 crossbow.timb.us
That way, and SPAM software doing a lookup for MX 20 will have to pass your
own checks, a SPAM source just taking the highest MX will also have to get
past your filters, and if your site goes down for some reason,
mx2.mailhop.org will still accept mail for you (and they should use MXs in
ascending order)
James Brown
highest value.
James.
Richard Holland
Please don't top-post.
OK, then as a general rule to stop spammers use:
10 primary.mx.domain
15 secondary.mx.domain
16 tertiary.mx.domain
...
20 primary.mx.domain
That way any SPAM software going for highest or priority 20 MX will have to
deal with the spam filtering on your primary domain. Proper MTAs will still
use your backups when the primary is down. This, however, won't catch SPAM
where the software manages to pick up one of your backup MX hosts.
Jorey Bump
> OK, then as a general rule to stop spammers use:
>
> 10 primary.mx.domain
> 15 secondary.mx.domain
> 16 tertiary.mx.domain
> ...
> 20 primary.mx.domain
>
> That way any SPAM software going for highest or priority 20 MX will have to
> deal with the spam filtering on your primary domain. Proper MTAs will still
> use your backups when the primary is down. This, however, won't catch SPAM
> where the software manages to pick up one of your backup MX hosts.
This approach is more likely to increase the amount of spam sent to a
domain, because it offers more targets.
Spam seems to fall into one of the following categories:
1. Try each MX in order of priority until successful (normal
RFC-compliant behaviour).
2. Fire-and-forget at the primary MX.
3. Direct-to-secondary-MX only.
4. Target all MX hosts, either systematically or randomly.
Due to the last approach, adding unnecessary MX records is likely to
pollute your IP space. You'll get the best results if you limit the
number of MX records you present to the absolute minimum, and avoid
using a backup MX entirely. If you must use a backup MX, the only
approach worth the effort is to harden it with the same policies you use
on your primary (recipient validation, same RBLs, same AV/spam filters,
etc.).
When it comes to playing tricks with DNS, you have to be very careful,
as a lot of factors come into play. On my sites, I've determined that
close to 50% of all hosts connecting to SMTP are of the type that
fire-and-forget spam at the primary MX. It's easy to fight these by
creating a single primary MX record that points to an unresponding IP
address (no device, or no SMTP listener). This approach appears to be
safe, if done properly. For more details, see:
Nolisting (Poor Man's Greylisting)
http://www.joreybump.com/code/howto/nolisting.html
This disables the primary MX, with the secondary MX taking the
responsibility for handling mail (no backup MX is configured). The
benefit is that 50% of all messages (100% of which are spam) are
dropped, and never processed by Postfix, SpamAssassin, Amavis, Bind, etc.
This still leaves the system vulnerable to direct-to-secondary-MX spam
(although it is now subject to the more stringent policies applied by
the main mail server). I've experimentally extended Nolisting to deal
with this using the Linux ipt_recent module:
Unlisting (Port Knocking for SMTP)
http://www.joreybump.com/code/howto/unlisting.html
In this scenario, both MX hosts are blocked by a firewall, the primary
MX is always blocked, and the secondary MX is made available only if the
connecting host tries the primary MX first (within a predefined time
period). This fights the remaining direct-to-secondary-MX spam very
effectively, but Unlisting is far more fragile than Nolisting, and there
are many, many, many caveats. It offers enough rope to hang a posse of
email administrators, and should be tried only after a lengthy
evaluation of Nolisting, if at all.
The technique used by Unlisting could protect a normal backup MX in
environments where the MX hosts share a firewall. Such an environment is
concerned with providing a backup for the primary MX in case of machine
failure, not network failure, and even then its value is debatable (but
that's another discussion). Where the backup MX is more properly hosted
on another network that is geographically distant, best practice demands
that it has similar restrictions as the primary MX to prevent it from
becoming a backscatter source or a silent discarder of messages.
Craig Skinner
> Spam seems to fall into one of the following categories:
>
> 1. Try each MX in order of priority until successful (normal
> RFC-compliant behaviour).
> 2. Fire-and-forget at the primary MX.
> 3. Direct-to-secondary-MX only.
> 4. Target all MX hosts, either systematically or randomly.
>
> as a lot of factors come into play. On my sites, I've determined that
> close to 50% of all hosts connecting to SMTP are of the type that
> fire-and-forget spam at the primary MX. It's easy to fight these by
> creating a single primary MX record that points to an unresponding IP
> address (no device, or no SMTP listener). This approach appears to be
> safe, if done properly. For more details, see:
>
> Nolisting (Poor Man's Greylisting)
> http://www.joreybump.com/code/howto/nolisting.html
>
> This disables the primary MX, with the secondary MX taking the
> responsibility for handling mail (no backup MX is configured). The
> benefit is that 50% of all messages (100% of which are spam) are
> dropped, and never processed by Postfix, SpamAssassin, Amavis, Bind, etc.
>
> This still leaves the system vulnerable to direct-to-secondary-MX spam
So then if you have a dummy primary mx, why not use the same technique
on the lowest priority mx box? From your great web page, 46% of spam
gets sent to the lowest MX, and 28% goes only to the highest, so that's
3/4 of all spam that can be dispensed with. eg:
$ORIGIN example.com.
MX 5 mx1
MX 10 mx2
MX 15 mx1
mx1 A 192.168.1.3
mx2 A 192.168.1.4
That makes the technique a hi+lo nolisting, hi-lo listing????
Previously, I was using greylisting and the high MX style with a second
postfix instance 451 rejecting with good effect as per here:
http://thread.gmane.org/gmane.mail.postfix.user/138524/focus=138545
I got the idea from here:
http://thread.gmane.org/gmane.os.openbsd.misc/98408/focus=98408
I'm now testing hi+lo with success here. My domain is currently getting
spammed from an infected host in Italy, so I'm seeing over 80% of smtp
connections hitting the pf block return-rst IP. No processing needed.
Brilliant, effective idea, thanks!
--
Craig Skinner | http://www.kepax.co.uk | jo...@kepax.co.uk
Jorey Bump
On Fri, September 29, 2006 4:04 pm, Craig Skinner wrote:
> So then if you have a dummy primary mx, why not use the same technique
> on the lowest priority mx box? From your great web page, 46% of spam
> gets sent to the lowest MX, and 28% goes only to the highest, so that's
> 3/4 of all spam that can be dispensed with. eg:
>
> $ORIGIN example.com.
>
> MX 5 mx1
> MX 10 mx2
> MX 15 mx1
>
> mx1 A 192.168.1.3
> mx2 A 192.168.1.4
The question is if the tertiary MX is really blocking spam you would have
received otherwise. IOW, if you add another low priority MX, you'll
attract more messages, 100% of which are spam, all of which you block.
This causes the percentage of blocked spam to increase, but would you ever
have gotten it without the extra decoy? This is hard to answer without
knowing for sure if spammers are explicitly targeting only the lowest
priority MX, and not all MX hosts (I'm apt to believe the latter is more
the norm). I'm not sure that adding MX hosts spreads the spam thinner,
since there is no technical restriction to cause this.
--
Timothy Brown
> would have
> received otherwise. IOW, if you add another low priority MX, you'll
> attract more messages, 100% of which are spam, all of which you block.
> This causes the percentage of blocked spam to increase, but would
> you ever
> have gotten it without the extra decoy? This is hard to answer without
> knowing for sure if spammers are explicitly targeting only the lowest
> priority MX, and not all MX hosts (I'm apt to believe the latter is
> more
> the norm). I'm not sure that adding MX hosts spreads the spam thinner,
> since there is no technical restriction to cause this.
That was my whole question really... In the end I've left the DNS
records the way they are, but turned on DNS / Reverse DNS lookups on
both the backup and primary MX. This in and of itself seems to have
cut a lot of the spam down. (It seems most of the spam that was
getting through after the other filters were from shaddy countries
that are IP only and don't have a forward or reverse to them.)
-Timothy
Craig Skinner
>
> On Fri, September 29, 2006 4:04 pm, Craig Skinner wrote:
>
> > So then if you have a dummy primary mx, why not use the same technique
> > on the lowest priority mx box? From your great web page, 46% of spam
> > gets sent to the lowest MX, and 28% goes only to the highest, so that's
> > 3/4 of all spam that can be dispensed with. eg:
> >
> > $ORIGIN example.com.
> >
> > MX 5 mx1
> > MX 10 mx2
> > MX 15 mx1
> >
> > mx1 A 192.168.1.3
> > mx2 A 192.168.1.4
>
> The question is if the tertiary MX is really blocking spam you would have
> received otherwise.
Previously I ran just a legit primary MX (with greylisting), and a dud
secondary that had a postfix instance listening that 451 rejected mail.
Due to greylisting, new legit mail would try the dud secondary MX, then
successfully try later on the primary.
However, about 1/4 of new smtp connections were only to the dud
secondary MX, & hence is spam, so to my mind, some malware reverse sorts
the MX's and only tries the least preferable MXer.
Therefore, with running a dud (TCP reset) primary MX, you have killed
off the fire-&-forget-@-primary-MX spam, but you now have to cope with
the lower volume of fire-&-forget-@-lowest-MX.
So, I thought that by combining the 2 ideas, I could get rid of both
sorts of fire-&-forget spam as the legit MXer nestles inbetween 2 dud MX
entries. By eye balling my server, this seems to be working well.
> IOW, if you add another low priority MX, you'll
> attract more messages, 100% of which are spam, all of which you block.
There are lots of different sorts of malware, and this could well be
true in some cases, ie, malware counting the number of MXers in a
domain, and only spamming ones that have more than X number of MXers.
> This causes the percentage of blocked spam to increase, but would you ever
> have gotten it without the extra decoy? This is hard to answer without
> knowing for sure if spammers are explicitly targeting only the lowest
> priority MX, and not all MX hosts (I'm apt to believe the latter is more
> the norm).
Dunno, this could be established by running nolisting, then hi-lo
listing on a busy domain for some period of time and comparaing stats.
> I'm not sure that adding MX hosts spreads the spam thinner,
> since there is no technical restriction to cause this.
Well there sort of is, you've proved it, and this forms the basis of
your nolisting. Also, malware often does not follow conventional
technical restrictions, hence the fire & forget brigade.
--
Craig Skinner | http://www.kepax.co.uk | wonkey...@kepax.co.uk