Among the named methods, the first three ones are first-level filters. They allow to deal with bulk mailing of spam, malicious email, which includes mails with supposititious sender. In this case, malefactors use all-out attack effect, not making preliminary reconnaissance and not trying to match content to particular recipient precisely. These may be letters on behalf of bank official with request of reporting any restricted information, sent massively. Methods from 4 to 6 allow dealing with situations when senders’ names in letter headers are put precisely to a sign. Method 7 fits occasions similar to the above described story, when letter header was modified the way to look like the genuine one. However, header in the forged letter differs from the header of genuine sender and this fact allows to circumvent checking by methods 4-6. Let’s consider the mentioned above methods more closely.
1. Filtering based on a sending server’s reputation. If corporate mail security system offers a qualitative base of senders’ reputations, it makes possible to filter significant amount of spam disseminators and malicious mailing on the stage of TCP-session establishment, not having a look into either body or envelope of the letter. This approach appreciably saves system resources. The moment sender is trying to set TCP-session on the port 25, security system defines reputation for sender’s IP-address and makes decision. 2.
Filtering based on checking DNS records of sending server. Mail sender must be registered in DNS correctly. PTR record, as well as A record, must be also correct. Sender must be correctly introduced in SMTP command HELO. Making bulk mailing, malefactors constantly change IP-addresses of sending servers. They do it every day or even more frequently. It’s hard to register required DNS records, so many spam disseminators neglect such requirements. This helps to filter them by DNS attributes.
3. Filtering based on checking DNS records of sending server. Information in “MAIL FROM” is also a subject to inspection by DNS. The letter may be rejected if: 1.
There’s no information about sending domain in the envelope. 2. Domain name is not permitted in DNS. 3. Domain name doesn’t exist in DNS.
4. Filtering by checking SPF records. Sender Policy Framework (SPF) is a system checking an email sender.
Checking by DNS records of sending server means that required PTR and A records in DNS exist for sender’s IP-address. But these procedures never let define whether the sending server is allowed to send messages from the specified domain. It’s worth mentioning that often A records of mail servers contain company’s domain name, for example “smtp01.mycompany.com”.
In the case, when server is used for mail receiving, the same A record will be included into MX record. It is likely that, if the letter from “mycompany.com” was sent from server “smtp01.mycompany.com”, it means that the letter is genuine. Otherwise, if message was sent from “smtp01.
anythingelse.com”, the letter is a forged one. In the meantime, companies often email not from their mail servers directly, but using auxiliary servers MTA; for instance – their providers’ servers.
That leads to the situation when letters from domain “mycompany.com” are sent from servers “smtp01.provider.com” etc. Canonical names of servers don’t belong to company’s domain “mycompany.com”.
How can recipient understand whether sending servers are legitimate or not? Sender Policy Framework solves this task. The task can be solved with the help of DNS by publishing special TXT record. This TXT record includes IP-addresses, subnets or A records of servers, which could send mail. Those servers are not regarded as legitimate senders.
Using SPF, sender can resort to DNS and define if he could trust sender’s server, or sending server is trying to simulate somebody else. At this time, not every company forms SPF records. 5. Filtering by DKIM.
Domain Keys Identified Mail (DKIM) is an email authentication method. Let’s turn back to the example when company “mycompany.com” mails correspondence out through provider’s MTA “smtp01.mycompany.
com”. MTA works with SPF records; this is why mail from “mycompany.com” passes checking procedures successfully. But what if MTA data turns out to be compromised, and malefactor will also be able to send forged letters via these servers? How to authenticate sender in this case? The answer is email authentication. Authentication uses asymmetric cryptography and hashing functions. Private key is known to sending server solely. Public key is published with the help of DNS in special TXT record. Sending server forms the print of letter headers, using hashing functions; and signs it, using private key.
Signed print is added to the letter header “DKIM-Signature:”. Now, using the public key, recipient can get the decoded print and compare it with the print of received letter fields (hashing function is known). If prints match, signed headers weren’t changed while being sent, and sender that formed header “DKIM-Signature:” is a legitimate one. 6.
Filtering by DMARC. Domain-based Message Authentication, Reporting and Conformance (DMARC) is a system that describes how to use check results made by SPF and DKIM. DMARC policies are published by DNS in TXT record.
They point what specifically should be done to the letter on the recipient’s side, and it depends on SPF and DKIM check results. DMARC also provides sender with reverse communication with the recipient. Sender may get reports about all the emails with sender’s domain. The information will include IP-addresses of sending servers, quantity of messages, in accordance with DMARC policies, and SPF and DKIM check results. 7.
Creating granular filtering in manual way. Unfortunately, not every company uses SPF, DKIM, or DMARC, while sending email. On the other hand, sometimes SPF, DKIM and DMARC checks may run successfully, but letters may be forged, anyway. For those cases, the solution is filter tuning. Different system capabilities for filter rules are variable. Filters tuning depends on different ways the attack may be arranged, as well as on peculiarities of mail system organization in company. For example, some companies may receive letters with the same company domain-sender. Conclusion.
Email attacks with sender’s falsification are widespread. Successful ones may lead to the miserable consequences that may affect both individual employees and the whole company. Material losses and restricted information leakage are possible. I hope, that the article will help you to get a sense of forged letters attacks danger and to learn a bit about the safety methods.