A lot of things have been broken because Internet usage is unmetered. When attackers have universal connectivity and essentially zero marginal cost, what outcome would you expect? It shifts tremendous costs to recipient organizations, and because those defenses are inadequate, it leads to even higher costs as a result of breaches. A similar problem has been created for voice telephony, because the free internet has made international calling free for attackers, and knowing the true source of a call has become proportionately difficult.
But it seems worth elaborating on the problem by pointing out obstacles in the defense process. The first obstacle is obtaining an effective and efficient message review tool, so that malicious messages can be identified. The second obstacle is interpreting an unwanted message to determine if a message is acceptable, unwanted, or malicious. In some cases, the appropriate response is an unsubscribe, other times a block, and sometimes a block with an abuse report to the attacker's infrastructure provider. Once a decision is made, the filtering rules need to be updated to make an acceptable message allowed next time, or to make an unacceptable message blocked next time. All of that decision-making is labor-intensive. I don't trust the "trust us" vendors, and the assemble-it-yourself toolkits seem to stop well short of a complete workflow.
But to start thinking for anyone who wants to build a better workflow, here is my description of the "whom to block" problem:
Spam Filtering – Deciding what to block
Assume you have one or more confirmed-hostile messages, so something needs to be blocked. How do you decide what identifiers should be blocked? Identifiers can be treated as a hierarchy, in descending order:
- Reply-To address(es)
- Message From address
- SMTP Mail From address
- Helo server name
- Reverse DNS server name
- IP address
Identify Infrastructure identifiers
One identifier will represent the entity primarily responsible for the message. Identifiers above that entity will either be impersonations or identifiers controlled by the attacker. Identifiers below that entity will be infrastructure providers that offer services to many clients. Infrastructure services are expected to have a mix of acceptable and unacceptable clients, so they are generally not punished for misbehavior by a single client. Exceptions to this rule will be discussed later.
Working from the top down, assess each identifier role, to evaluate whether it is an infrastructure identifier or an entity responsible for the message. Infrastructure identifiers include:
- Internet Service Providers that assign IP address to client organizations
- Bare-metal hosting services that allocate their assigned IP addresses to their clients. IP allocations tend to be shared or fluid, so an IP address may not reliably indicate the hosting service’s client organization.
- Email hosting services that serve multiple clients on multiple domains.
- Email service providers (ESPs) that send messages on behalf of clients. The ESP domain is indicated in the SMTP Mail From address, while the message From address indicates the client (Sendgrid.Net, ConstantContact.com)
- Mailbox providers (Gmail.com, Hotmail.com)
- Outbound gateway service providers (MaxMind.com, ProofPoint.com)
(Note that Outlook.com falls into most of these categories)
Assess Impersonation
Some identifiers within a malicious message may be impersonations. These are ignored, as they are neither responsible for the message nor an infrastructure provider for the message.
Some spammers use a bare-metal hosting provider that does not restrict outbound email. That allows them to impersonate both the message From address and the SMTP Mail From. If the server names represent the hosting service, the attacker remains completely anonymous.
Server names may indicate the hosting service, the SMTP organization, or obfuscation. Forward-confirmed DNS can rule out obfuscation, while names without a PSL parent domain are confirmed obfuscation.
Considerations when an email address needs to be blocked:
- You need to determine whether the domain is a mailbox provider or not. If it is a mailbox provider, you block the full email address. Otherwise, you block the domain name.
- In almost every case, a domain name should be blocked at the organizational domain level, because you have determined that the domain is controlled by malicious actors. For example, user@mail.badguys.com is blocked using “badguys.com”, not “mail.badguys.com”.
Considerations when the server needs to be blocked:
- You need to determine if the server name represents the attacker or a hosting service with a malicious actor. If the server name represents the malicious actor, block the server organizational domain as well as the IP address. If the server names represent a hosting service, block the IP address and send an abuse report to the hosting service.
- In the rare case that the hosting service is determined to be fully untrusted, block the hosting service by organizational domain and known IP address ranges.
- If the hosting service is determined to be legitimate but too frequently used by malicious clients, configure messages from that server organizational domain to be quarantined by default. Then as messages arrive from that company’s clients, create rules to allow acceptable clients and block unacceptable ones.
- MaxMind.com and IPInfo.io can be useful for determining IP address ownership and IP address blocks assigned to a single company.