[Postfix] Limiting outbound FROM domains

An app on our server allowed customers to pick whatever FROM address they wanted for their email alert including domain. This completely skewed our statistics over at Sparkpost as we attempted to send emails from unverified domains like a.com, none.com, dont.care etc.

I was growing tired of waiting for the developers to move their ass so I decided to step in. This is how you limit your outbound emails to specific domains:

Edit /etc/postfix/header_checks

if /^From:/
!/(^From:.*domain\.com|^From:.*domain\.net|^From:.*domain\.co\.il)/ DISCARD SEND FROM THE RIGHT DOMAINS ASSHOLE
endif

Edit /etc/postfix/main.cf

header_checks = pcre:/etc/postfix/header_checks

Restart or reload Postfix.

And there you have it.
All emails should be of either of domain.com, domain.co.il or domain.net.
The rest will be scrapped.

 

Fixing ESP Packet with Unknown SPI

I was having some weird times with our Virtual Fortigate Appliance.
It had a very steady IPSEC VPN connection with our of our sites but for some reason the packets were being dropped with no good reason although the tunnel remained connected.

I found the following in the logs:

Untitled

“Received ESP packet with unknown SPI”.
Official Fortigate KBs claim turning on DPD should prevent this from happening.
But in actuality it did NOT.
My intuition somewhat told me that this has got something to do with PFS as it deals with generating keys per data. I was right. After disabling it the tunnel became stable like a rock.

Cheers

 

Synching folders between multiple servers

After a DFSR meltdown and spending an entire day trying to figure out why it will not sync anymore, I decided to go for an alternative.
I needed something relatively simple:

– Run as a service
– Preferably free.
– No hosting server required like with Owncloud

Surprisingly this was MUCH harder to find than I thought as even paid services were either incredibly lacking or stupidly overpriced.

Then I found this:

https://forum.syncthing.net/t/syncthing-windows-installer/2009

It does all of the above with ease.

DMARC and why should you give a damn

So for the very first time our company received a phishing email attempt. The asshole supposedly sent a message from the CEO’s mailbox to the CFO’s and requested a very large amount of cash to be wired to some unknown off-shore account. Imagine the depth that fucker went into to get all that info, huh? Luckily, the CFO sensed something in the context was wrong so she called yours truely. Baffled by this mystery and with a lot of curiousity I sat down and began my investigation.

I literally didnt sleep that night. Not because I fought aimlessly trying to figure out how he did it, but because I discovered how INCREDIBLY EFFORTLESS it was to spoof an undefended domain’s email address. Within a few hours I managed to send an email to a friend from his employer telling him he’s fired and another to my wife from her Bank Manager telling her she got promoted. Just for the record, this could probably be done with ANY domain out there that doesnt enforce DMARC or any special email filter inspection like Forti Mail, Pineapp etc. So without a due, this is why you should give a damn.

DMARC – Domain-based Message Authentication, Reporting & Conformance

DMARC – What does it do?

Easily put, it’s a mechanism that stops assholes from spoofing YOUR email addresses. But the biggest thing about DMARC is that it prevents them from spoofing your emails against OTHER domains as well. Meaning it doesnt allow for an unknown source to send emails on your behalf to different organizations, NOT just from you to yourself. Moreover, it encompasses ways to receive reports about external attempts being made at forging your domain.

DMARC – How does it do it?

  1. Policy – When you receive an email the MAILFROM header domain is being checked for a published DMARC policy (based on DNS). What this policy basically says is that the domain owner has a working set of SPF and DKIM records and that it’s 100% “aligned” which I’ll be explaining shortly. On top of it, it tells or better yet recommends the receiver what to do if the message he received fails DMARC and where to send the report to. Need I say that without such policy DMARC is bypassed.
  2. Alignment – All an attacker really needs to do in order to spoof the common domain email address today is to use a MAILFROM address of a domain that does NOT have an SPF record while forging the FROM header to be from your domain. What this check does is it compares between the two and SPF\DKIM. SPF: smtp.MAILFROM domain must match RFC5322.From domain; DKIM: d= domain must match RFC5322.From.
  3. SPF Records – At this point if the SPF record passes then it’s extremely likely that the sender is indeed legitimate. His FROM and MAILFROM addresses checked out and his physical IP address is within the bounds of the allowed IPS in the sender’s record. No further checks will be required but if SPF fails then the final decision will be made according to DKIM.
  4. DKIM Records – You cant go wrong if an encrypted email header did not decrypt properly with the public key hanging, well, publically out in the open. This method of cryptography by itself is enough to tell if the sender is who he’s telling he is. The decision whether or not to accept the email will be made accordingly.

If like me you’re running Office 365 or Google Apps, chances are that all you have right now for email verification is an SPF record. That of course is laughably not enough to stop someone from forging your emails. Thankfully DKIM is being rolled out in Office 365 as we speak (already supported in GoogleApps) and DMARC is already fully supported.  This sent me at the right path. Hopefully it will do someone else good as well.

How to block default in Fortigate via BGP

Problem:

Solution:

config router access-list
edit “Block_Def_Route”
config rule
edit 1
set action deny
set exact-match enable
next
edit 2
set exact-match disable
next
end
next
end

config router bgp
config neighbor
edit “10.40.15.1”
set distribute-list-in “Block_Def_Route”
set remote-as 6167
set route-map-out “Verizon_Prepend1”
next
edit “10.40.16.1”
set distribute-list-in “Block_Def_Route”
set remote-as 6167
set route-map-out “Verizon_Prepend”
next
end
end