For a few months, I’m writing less often on this blog, except to publish my conference wrap-up’s and cross-posting my SANS Internet Storm Center diaries. But today, I decided to write a quick post after spending a few hours to debug a problem with my mail server…
It started with a notification from a contact who found one of my emails stored in the junk folder of his Office365 account. In the past, I already had the same issue a few times but I did not pay attention. This could always happen due to a “border line” expression in the message. I asked him to provide me all headers of my blocked email and I found this:
Incoming X-Forefront-Antispam-Report: CIP:x.x.x.x;IPV:;CTRY:DE;EFV:NLI;SFV:SPM;SFS:(10001)(199004)(189003)(7596002)(86362001)(7636002)(1096003)(54906003)(63350400001)(26005)(8676002)(36756003)(336012)(53546011)(58800400005)(2616005)(966005)(5660300002)(6966003)(4326008)(33656002)(246002)(22186003)(356004)(6266002)(6862004)(107886003)(33964004)(6666004)(112026008);DIR:INB;SFP:;SCL:5;SRVR:PS1PR0302MB2507;H:mail.xxxxxxxx.xx;FPR:;SPF:TempError;LANG:en;PTR:mail.xxxxxxxx.xx;A:1;MX:3;CAT:SPOOF;
To decode why it was categorised as spam, Microsoft provides a page with all details. Apparently, Microsoft was not able to check the SPF record (“SPF:TempError” means a temporary DNS failure occurred). I don’t know the reason because the DNS hosting the zone with SPF records are available! Anyway…
In the mean time, I started to investigate on my web server what could be the reason to flag a mail as “suspicious” or “malicious”. To achieve this, I started to review all the security controls related to SMTP:
- SPF? ✔ï¸
- DMARC? ✔ï¸
- DKIM? Oops… It was not working, outgoing emails were not signed.
And it started… I dived into my Postfix config, my OpenDKIM config, checked the keys, configured domains, the selectors, the DNS records… For most of us, Google is our fist step to get some support. Let’s search for potentially useful keywords. Ouch, the first hit suggest stackoverflow.com… Not the most reliable place on the Internet 😉 Finally, the problem was fixed and DKIM is now working properly again!
If you step back a few seconds, this is a good example to demonstrate why security of many systems keeps failing… Everything is way too complex and many people are afraid when they have to implement more security controls. Their motto sounds like:
If it works, don’t break it! It was running like this for a long time, nobody know exactly how…
Here are some examples (feel free to share yours via comments):
- SPF records are kept in “safe mode” to avoid outdated filters to block emails’ delivery
- Certificates expire without notification (always on December 31st at 23:59)
- DNSSEC is a pain to maintain with the regular renewal of keys (Did you read the latest story about DNSSEC?)
- Docker credentials are difficult to integrate into some application with Docker secrets.
- Let’sEncrypt SSL certificates are nice but the certbot may fail for multiple reason… The most classic one being a too strict redirect of HTTP to HTTPS.
- Products’ documentation is not complete and does not mention what ports/IPs/domains allow. People configure “any to any” to be certain that the application will work.
- Mail encryption with PGP is out of the competition (people will never understand the difference between public / private keys 😉
- Etc…
Finally, while working at customers’ premises, I see that there is a trend to make platforms more and more complex. It seems that today, everything must be “agile”, must be “orchestrated”, … Finally, we loose the control!
Feel free to share your thoughs!