ExchangeDefender Whitelist vs. DEA (Disposable Email Addresses)
ExchangeDefender is a cloud-based email firewall, and as such we enforce client’s policies against the only email address that is trustworthy: the envelope from address.
Over the past few years there has been a significant increase in use of disposable email addresses (DEA), specifically among mass/bulk mailing operations such as SendGrid, AmazonSES, MailJet, SMTP2Go, SocketLabs, Postmark, Mandrill, Mailgun, MailChimp, ConstantContact, etc. These email addresses, also known as “dark mail” create a unique email address to serve as the official From: line, in an effort to track bounces and delivery problems. Every time you get an email from one of these mass mailing operations the address the message actually came from is unique and generated just for that email/campaign – so whitelisting/blacklisting such addresses can be a challenge for clients that do not use ExchangeDefender’s admin portal or quarantine reports (which detect BATS/DEA addresses and auto-suggest the domain or IP to create a policy).
Bulk mail operations are not just used for mass marketing mail, where companies large and small do not want to build out the infrastructure to deliver tons of email. They are used for notifications, alerts, and most legitimate junk mail that you get. Unfortunately, the same companies are abused in virtually the same way by hackers to deliver spear phishing content. Because the body/header From: address can be easily faked, hackers hide behind places such as SendGrid, AmazonSES. Because they are highly automated, there is relatively little in the way of policing on these networks: after all, they make money to deliver junk mail to you and have little incentive to keep SPAM and phishing content from being sent through their networks.
Over the years, we’ve taught countless MSPs and IT people the difference between the “envelope from” (routing address) and “header or body from” (fake, but friendly looking From address displayed in your email software like Gmail or Outlook). As our client base has changed over the years, we’ve decided to write up an intro-level explanation of the process and how to master it. You can find it here:
https://www.exchangedefender.com/docs/whitelist
We hope you can use it to better block or permit access to these operations. If you’d like our assistance with this process, please open a ticket at https://support.ExchangeDefender.com and remember to attach the .eml file and/or full headers which are required for troubleshooting.
For our pro subscribers, stay tuned. We’ve been hard at work on our antispam engine enhancements and we’ll have a friendlier way to manage this by Thanksgiving 2020.
ExchangeDefender Phishing Firewall Whitelist and Blacklist explained
ExchangeDefender Phishing Firewall goes online tomorrow, and we wanted to explain our policy and our implementation of the URL rewriting/redirection because it is a departure from a traditional IT hierarchy where organizational policies override group and user requirements.
Our goal with ExchangeDefender PF is to provide a level of alert and notification to our clients that is designed to provide additional information about the link they clicked on. As we scale this service out, that will be it’s purpose: Be aware of what you clicked on, and prepare for what you’re about to see. Phishing, and spear phishing in particular, is designed to be a convincing fraudulent identity theft of an organization you know and trust (your bank, your coworker, your vendors) and our goal is to help you discern if something is valid or not.
Our whitelist/blacklist implementation is in line with “we inform, you decide” mantra, as we cannot outright block you from actually going to the dangerous site. That is the responsibility of your IT department, your network management, and your organization.
How do Whitelists and Blacklists work?
In ExchangeDefender we have 4 sets of whitelists and blacklists: user, domain/organization, service provider, and global. Our global lists are automatically populated for our service providers and when they protect a domain with ExchangeDefender, those entries are applied on the domain/organization level, and further down to the end user. As we continue to monitor, manage, and get additional intelligence about dangerous sites we will continue to curate these lists as a part of the service.
For example, we might find out that *.vlad8150.microsoft.net is a Microsoft Azure instance that is attempting to spread malware. We will promptly add it to our global blacklist and that site will now be blacklisted for every ExchangeDefender user. When they click on a link that leads them to that domain, they will see the ExchangeDefender PF notice with the URL in red. User will then have the option of ignoring it and proceeding to the site, or adding it to their whitelist. If they whitelist a domain/web site, any future requests will bypass ExchangeDefender PF web site and automatically redirect to the target URL.
The hierarchy of whitelists/blacklists is as follows, whichever rule is defined on the top is the one that is applied to the user when they click on a link.
But why, why not implement policies like NTFS, access list, or any other policy in which global deny rules override end user policies?
Simply put: Traffic blocking should be done on the network level. We are simply the alert service, we will advise you when we see something dangerous and it’s up to you to discern if the site is trustworthy or not. We believe that this implementation will cause the least amount of interruption to the day-to-day use.
That said, we have been working on additional controls and policies to help our service providers and CIO’s better enforce company security policies. As with everything, security policies must be implemented in layers – and dangerous content should be enforced in accordance to business requirements. This means that if your clients should not be downloading .exe files, the network firewall should be doing that. We don’t have the means to do that as an email service – users can right click on the email, put it in notepad, remove https://r.xdref.com/url= from the link and go straight to the web site.
How do we manage them?
ExchangeDefender PF whitelists are available at every level of ExchangeDefender. Simply add a site to either a whitelist and blacklist and ExchangeDefender will automatically propagate your rules down through the entire organization. Users will have the ability to add / block sites from the ExchangeDefender PF in real-time and their settings will be preserved in their account only.
P.S. Officially the service goes online tomorrow, unofficially it’s been in place for months we just haven’t rewritten a single URL except for the emails you received from us – we have worked very hard on the implementation and we don’t expect major problems but will have staff on hand around the clock to address any issues immediately. Spear phishing is an epidemic, over 90% of compromises start with a link in an email. We will handle any glitches, bugs, and issues as fast as possible and have full confidence that having an alerting service with potential problems is far more useful than having nothing and leaving clients exposed.
ExchangeDefender PTR & RBL Whitelisting
ExchangeDefender is opening a wider beta test of our whitelisting functionality, which allows IT Solution Providers to whitelist sender mail servers that have broken DNS (missing PTR, mismatched A/PTR records) and poor sender reputation (hosts listed on multiple RBL blacklists).
If you have a sender you would like to whitelist against these essential network tests, please open a ticket at support.ownwebnow.com with subject “Whitelist PTR/RBL: IP Address” and provide as much information in the ticket so we can accommodate this specific request. Only hard non-negotiable rejections to whitelist will be for unknown address space and dialup/consumer cable IP addresses (because due to their nature those are typically dynamically assigned address spaces that shouldn’t be relaying mail at all, they should be using their ISP mail server provided smarthost)
Requests will be reviewed and either approved (and enrolled) or rejected within 24 hours by our CSO.
Background: Inability to previously whitelist broken DNS and dynamic IP address space is rooted in our mission statement. We are here, beyond everything else, to help secure the email. We know our partners, IT Solution Providers, VARs, MSPs, etc do not have the skill set, the time to properly research underlying issues, enough data and statistical models to evaluate sender IP reputation, or even the incentive to discern how big of a security threat and compromise a specific IP address with broken DNS or poor reputation may pose to your client.
In fact, you pay us to worry about those things and keep your clients secure. But, sometimes clients like to think they know better than their technology experts, generally accepted security standards on the Internet, and ExchangeDefender. And the client is always right. But, when they get infected attachments, broadcast storm, password dumps, or other security compromises because they insisted on lowering their security – then ExchangeDefender is on the hook for securing them. And we don’t get to say “told you so” nor do we have any rapid means to fix the issue.
Since my retirement, all of those hard-line policies designed to keep clients safe beyond whatever “specific business case requirement” they may have, are slowly going away. Good news for the client, good news for the partners. Good news for us, because going forward we will start providing Email Security Engineering services – so when you get a security compromise or an usual issue and you’ve asked us to compromise your security – we will be able to address the issue on your behalf.
I choose to look at this as a positive – we will help our clients meet their business needs and get the mail they desperately need – and if something breaks we will be there to help assist with the cleanup (for a fee, of course). This, among many other service related things, is just the part of the ExchangeDefender being more responsive and service oriented when it comes to our clients demands as opposed to our expert opinion as a security policy.
