A vendor wants us to add all of Amazon AWS to our WHITELIST

[keithsauer507]

A vendor stated we need to add these IP's to our ESA whitelist:

199.255.192.0/22, 199.127.232.0/22, 54.240.0.0/18, 69.169.224.0/20

Upon looking them up, it seems its all of Amazon AWS!

See we are having issues with their product who is to make emails look like they come from us.  We have a text based rule that is only viewable if you SSH into the ESA which basically states if our domain name.com or domain name.org is in the email from and its not in RELAYLIST or WHITELIST, then move to Spoofed quarantine.  This really helps cut down on phishing emails that are made to look like they come from us.  Because if so perfectly crafted, even Exchange or Outlook will match the address and tie in the Active Directory picture on file and display it in Outlook, making it look pretty legit.

I'm afraid to add these HUGE IP ranges to whitelist because my thought is, what if a bad guy sets up shop in Amazon AWS and uses their server for bad?  With cloud based services these days why would bad guys set up shop on their own ISP's in their mothers basement?  Of course they are going to use servers that are elsewhere in the world and probably stolen bank account information to pay for it.  Even if caught and terminated, the few hours days or weeks it goes un-noticed means these bad guys still have plenty of opportunity to harvest or infect users.

What is your thought to this?  Is Amazon AWS prety safe, or is my cautious thinking right?

[Ken Stieers]

Your fears are valid. Don't do it.

With the advent of cloud mail, IP is often a bad discriminatory. Hence the new Sender Domain Reputation feature.

I tell the vendor to send a few tests and see what's catching, if anything and then build a mail policy or content filter as needed to address it. And no one gets exempted from AV/AMP/Outbreak filters.

[ppreenja]

Hi Keith,

From what I understand of your post is that your 3rd party vendor is a legitimate entity who is entitled to send emails on your behalf.
Now, in order to make sure that any emails from their end don't end up in spoofed quarantine they are requesting you to add all the Amazon SES (simple email services) IP addresses, which are apparently being used by them, to add to your WHITELIST sendergroup.

Now you're in a dilemma that whether adding the publicly shared AWS servers to your WHITELIST will pose any threat to your email environment making it vulnerable to some illegitimate activities.

If my above understanding is correct then, first of all, I would like to make it clear that we add only the servers to the WHITELIST that we trust.
Now, having said that, if it is something that is essential to be done then I have a suggestion which doesn't guarantee a completely risk-free solution, however, will be able to provide you a work-around for your scenario with controlled security measures in place.

My recommendation will be as below:
1) Create a custom mail flow policy (Mail Policies--> Mail Flow policy-->Add Policy).
2) Edit the policy with all the security parameters to have control over the connections made etc.
3) After this create a new sendergroup (Mail Policies--> HAT Overview-->Add Sendergroup) with a customer name (such as "ALLOWSPOOF") and assign the above created mail flow policy to the same.
4) Have this sendergroup added to the message filter created in the CLI similar to the condition of "if not a part of RELAYLIST" i.e.
if the condition is set as (if sendergroup != "RELAYLIST|WHITELIST") then change it to (if sendergroup != "ALLOWSPOOF|RELAYLIST|WHITELIST").

This way you won't be giving them the leniency in security you provide to the servers in the WHITELIST sendergroup via TRUSTED mail flow policy, however, on the other hand, your vendor will be able to send emails on your behalf as well in a controlled manner.

Please find below a few reference articles as well.

AWS SES Servers:
https://aws.amazon.com/blogs/messaging-and-targeting/amazon-ses-ip-addresses/
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/blacklists.html

Message Filters:
https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118145-technote-esa-00.html
https://www.cisco.com/c/en/us/td/docs/security/esa/esa11-0/user_guide_fs/b_ESA_Admin_Guide_11_0/b_ESA_Admin_Guide_chapter_01000.pdf

I hope the above information helps!

Regards,
Pratham

[keithsauer507]

Before you posted ppreenja, under HAT I created a new AMAZONAWS sender group and added those IP ranges in.  I made the SenderBase reputation score from 0 to 10.  The mail flow policy I created was TLSREQUIRED which basically REQUIRES TLS (drop if it doesn't).  My thought was I figured if the sender used TLS and it had a 0 to 10 SBRS score, it should help somewhat from bad guys who don't thoroughly pay attention to all of the details spinning up spam or phishing email servers in AWS.

This seemed to work.  But then today even though it seemed that email was working fine... two vendors inquired via Skype for Business about email bounce backs (Our organization rejected the message).  Looking through some message logs it seemed like every email was being detected and applied to the AMAZONAWS sender group, even if the IP address DID NOT MATCH the 4 CIDR IP addresses.  The HAT overview screen was in this order:
1 CISCO_CRES     TLSREQUIRED
2 RELAYLIST     RELAYED
3 WHITELIST     TRUSTED
4 BLACKLIST     BLOCKED

5 SUSPECTLIST     THROTTLED

6 AMAZONAWS     TLSREQUIRED

7 ACCEPT-TLS     ACCEPTED
8 UNKNOWNLIST     ACCEPTED

ALL     ACCEPTED

So this time I tried reordering it like so:

1 CISCO_CRES     TLSREQUIRED
2 RELAYLIST     RELAYED
3 WHITELIST     TRUSTED
4 BLACKLIST     BLOCKED

5 SUSPECTLIST     THROTTLED

6 ACCEPT-TLS     ACCEPTED

7 UNKNOWNLIST     ACCEPTED
8 AMAZONAWS     TLSREQUIRED

ALL     ACCEPTED

I sent a test email from my gmail account and in the message logs it detected it as ACCEPT-TLS sender group.  I also had a vendor resend me an email that was "rejected by our organization" and it now came through this time (they are not using Amazon AWS either).  Now I don't have an Amazon AWS email system I can test to see if that is detected properly, but does anyone know what is going on?  Will my reordering work?

Yes ppreenja, you have a full understanding of our rule.  

Here is the text based filter we have when I SSH to the ESA and view it: (since this is a publicly accessible forum I changed our actual domain name in here to simply domain.)

  1   Y      Y   Anti-Spoofing
Anti-Spoofing: if sendergroup != "RELAYLIST|WHITELIST|AMAZONAWS" {
                   if (header("from") == "(?i)@domain\\.com") OR ((mail-from
== "(?i)@domain\\.com") OR ((header("from") == "(?i)@domain\\.org") OR
(mail-from == "(?i)@domain\\.org"))) {
                       quarantine("Spoofed");
                   }
               }

[ppreenja]

Hi Keith,

The answer to your queries must be there in the details you put in the ACCEPT-TLS sendergroup and the message trackings of the emails for both the times when you were facing the issue and the time when the issue resolved by reordering.
If you can paste the snippet of the same here then maybe I can try and have a look to check on the reason for the same.

Note: Just to let you know that emails are matched in the HAT overview in order from Top to Bottom. Hence, there must be some reason the sendergroup that came first got matched.

However, if it is something that might require more complex and in-depth troubleshooting, then I would encourage you to go ahead and open a TAC case so that we can investigate the issue for you.

Regards,
Pratham