Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 1 subscriber
  • Views 12158 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Completely Block Mail from Internal Domain

despich
For our Company Domain (petroleumtraders.com) all our users send emails from Inside the firewall. So we know any email that comes from outside the firewall with that as a sending address is fake. So we have a *@petroleumtraders.com Address pattern added to the Sender BlackList section of the AntiSpam tab on our email protection. 

But today one of our Vice Presidents got a fake email that appeared to be from the owners address complete with a @petroleumtraders.com address. Luckily it looked a little suspicious because it was a wire transfer request.

After inspecting the email I found in the header that the X-Sender was a external address and the From header was a @petroleumtraders.com and the Reply-To, Return-Path were also a external address. 

So I guess the Sender blacklist does not block the "envelope-from" address?

How can I block these so internal users can't be tricked?

Dan


This thread was automatically locked due to age.
Parents
  • 0
    After three days I was finally able to get a support engineer on the phone.

    FIX- They found the device was only querying internal DNS servers. I did not have a SPF configured internally, only on external hosts so the device was unable to confirm my own SPF record. How to check if this applies to you:

    1) Enable Shell Access (Management >> System Settings >> Shell Access)
    1a) Reset the root and loginuser passwords if you don't know them.
    2) SSH to device, logon with loginuser and password
    3) enter "su -" 
    3a) enter root password
    4) enter "dig -t txt yourdomainname.com +short"
       *This does a query to your default configured DNS server. If the results are blank this applies to you, if it returns with your SPF record this is not your issue.*
    5) verify by entering "dig @8.8.8.8 -t txt yourdomain.com +short"
       *if this external DNS query (using google) resulted with your SPF record and the default DNS server query (step 4) was blank, then this confirms it is your issue. Add a TXT record on your default DNS servers with your SPF*

    How to check what your default DNS servers are set to in UTM:

    In the Web GUI- Network Services >> DNS >> Request Routing >> Find your domain that should be listed and review the "target servers".

    For my setup, the target servers are my internal domain controllers.
Reply
  • 0
    After three days I was finally able to get a support engineer on the phone.

    FIX- They found the device was only querying internal DNS servers. I did not have a SPF configured internally, only on external hosts so the device was unable to confirm my own SPF record. How to check if this applies to you:

    1) Enable Shell Access (Management >> System Settings >> Shell Access)
    1a) Reset the root and loginuser passwords if you don't know them.
    2) SSH to device, logon with loginuser and password
    3) enter "su -" 
    3a) enter root password
    4) enter "dig -t txt yourdomainname.com +short"
       *This does a query to your default configured DNS server. If the results are blank this applies to you, if it returns with your SPF record this is not your issue.*
    5) verify by entering "dig @8.8.8.8 -t txt yourdomain.com +short"
       *if this external DNS query (using google) resulted with your SPF record and the default DNS server query (step 4) was blank, then this confirms it is your issue. Add a TXT record on your default DNS servers with your SPF*

    How to check what your default DNS servers are set to in UTM:

    In the Web GUI- Network Services >> DNS >> Request Routing >> Find your domain that should be listed and review the "target servers".

    For my setup, the target servers are my internal domain controllers.
Children
  • 0 in reply to migiT
    Tried these steps.. No return at all on these digs ... and never had anything in "request routing" before.

    Would be interesting to know the reason why this would be a fix  and, if it is realy the fix for it, it would also be nice to be informed by Sophos or whoever in advance what is coming next, just to be prepaired...
  • 0 in reply to MacDrive
    Had the exact same issue this morning, accounting got an email from "our CEO"

    even though I have a blacklist on external incoming emails from our domain, this one snuck through

    An the email in question was even social engineered with an (outdated) email signature etc. 

    there is a feature suggestion for a similar case

    Mail Protection: SenderID Support
Unfiltered HTML