[AusNOG] Disturbing new spam trend?

[Mark Andrews]

In message <20151007092412.Y23901 at ali-syd-1.albury.net.au>, Ross Wheeler writes:
> 
> I know spoofed headers have been around (almost) forever, but I had a call 
> from a friend this morning who had received some malware.
> 
> On looking through the headers, I noticed something that I find a little 
> disturbing if I'm interpreting it right:
> 
> 
> Received: from ali-syd-1.albury.net.au (208.117.108.170) by
> BN1BFFO11FD024.mail.protection.outlook.com (10.58.144.87) with Microsoft 
> SMTP Server (TLS) id 15.1.286.14 via Frontend Transport; Tue, 6 Oct 2015 
> 10:43:53 +0000
> 
> I suspect this may be a forged header, because I couldn't connect to 
> 10.58.144.87 (even if BN1BFFO11FD024.mail.protection.outlook.com resolved 
> to a 10.x address) - but I suppose it would be possible the mail server 
> could be behind NAT, and report its own internal IP...
> 
> The thing is, ali-syd-1.albury.net.au is NOT 208.117.108.170
> 
> 208.117.108.170 is (currently) showing as another host:
> 170.108.117.208.in-addr.arpa domain name pointer mail.stridersports.com.
> 
> Are spammers now getting sufficiently "crafty" to be changing PTR records 
> to assist with the delivery of their spam and malware, or am I just being 
> paranoid?

Reverse PTR records have long had "bad" values.  You need to do a
forward lookup and check the addresses to find a match before you
can trust a reverse PTR record.  Often this is done with a paranoia
setting.

The best thing you can do is turn on TLS and require a valid matching
client CERT for systems claiming to be your own when they connect
over SMTP.  That way you can't be fooled by people claiming to be
yourself.  Note: there are potentially different requirements for
SUBMISSION.

You should also offer SMTP TLSA if you don't already and log the
presented client CERT.  We havn't yet specified how to do client
cert pinning in the DNS like we do for the server side but it is
theoretically possible to do.  This would allow a SMTP server to
verify the client cert against the presented name and prevent others
pretending to be this client.  All that really needs to be do is
to define a method to go from the present name to the CERT.
_25._tlsa.<name>/TLSA would be one way and it would indicate that
we will present this the cert matching this TLSA record when
connecting to SMTP (port 25).

This reminds me I need to check the I-D on this sort of thing
draft-huque-dane-client-cert-01.

For those of you who haven't read a RFC it might be interesting to
look at the process and provide feedback on the draft.  Most things
in RFC's aren't all that complicated and sending feedback is as easy
as sending a email to the authors.

Mark

> (Has anyone else noticed this, or is it something you'd only notice if you 
> were specifically looking for it?)
> 
> R.
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org