March 14, 2024
Leadership vs. Management, what exactly are the differences? And what is needed in both areas to meet the current challenges?
In our first article On the subject of e-mail spoofing, we presented the Sender Policy Framework (SPF) and the DomainKeys Identified Mail (DKIM) method as options for securing e-mail servers. The Domain-based Message Authentication, Reporting and Conformance (DMARC) standard was addressed for checking the SPF and DKIM functions and creating corresponding rules and measures. We explain this standard in more detail in this second article. Besides that gehen wir further measures to secure your email server against spam, phishing and relay attacks.
E-mail is the most used work tool in companies and unfortunately also the most vulnerable. In addition to spam and phishing, it is often malicious attachments and links that give IT departments and management sleepless nights. The easiest way to protect yourself from such problems is to block attachments completely. However, this would affect the workflow in most companies too much.
There is therefore another solution: upon receipt, all potentially harmful emails must be blocked or sent to quarantine before anyone can click on the links contained in them or download attachments. (Basically, the following should apply to everyone in your company: "Think before you click!")
SPF and DKIM only protect if the receiving email server takes appropriate action when the appropriate checks fail. We show you how you, as a domain owner, can use the standard for Domain-based Message Authentication, Reporting and Conformance (DMARC) to define recommendations for action in these cases.
DMARC is a standard that was developed at the initiative of several large tech companies (e.g. Google and Microsoft) to prevent spoofing attacks. It adds important behavioral guidelines to SPF and DKIM in the event that a check of these records fails.
A special feature of DMARC is that these recommendations for action are not defined by the recipient but by the sender. As a legitimate domain owner, you can preemptively determine what should happen to emails that supposedly come from your domain but don't pass the SPF/DKIM check: should they be treated normally, end up in the spam folder or be discarded entirely?
Another important part of DMARC is the ability to specify addresses for the automatic receipt of reports. These give an insight into the statistics of sent mails. For example, you can keep an eye on how many emails from your domain have recently ended up in recipients' spam folders. This can provide information about a possible misconfiguration or malicious use of your domain. We encourage you to periodically review these reports using visual editing tools to stay current.
Like SPF and DKIM, DMARC works with TXT resource records in the sender's DNS server and builds on these records. So it doesn't make much sense to just set a DMARC entry alone. Within this record is the DMARC policy, with which the domain owner communicates that messages from him are secured by SPF and/or DKIM. At the same time, he can use predefined rules to give the recipient a recommendation on how to deal with unauthenticated messages.
For example, you can set up a subdomain "_dmarc" and set the corresponding resource record there. You can create multiple values within this record. You separate them with a semicolon. Many of the possible entries are optional. You only have to specify the protocol version (“v”) and the policy on how to deal with emails from the main domain (“p”). However, we strongly recommend that you also provide the e-mail address for receiving the reports ("rua"). So you can analyze which mails are filtered out.
When introducing DMARC, you should proceed cautiously and step by step (similar to the implementation of firewall instances). In principle, it is possible to set the percentage of emails to which the DMARC policy is applied to 100%. However, we advise against this at the beginning. For starters, just setting the DMARC record and setting the "pct" variable to "0" is perfectly sufficient. This opens up the possibility of receiving DMARC reports without having a direct impact on the delivery of the mails.
Once you've gathered enough information, you can gradually increase the percentage. In this way you gradually apply the policy to more emails and thus increase protection against spoofing.
DMARC is the first and only standard to date that checks the validity of the "From header" of an email. In addition to the desired increase in security, this also has undesired side effects. This is because DMARC sets very strict requirements. For example, a sent mail must be forwarded unchanged.
This leads to problems with the usual mailing lists, for example: With DMARC, it is no longer so easy to exchange the "From header" of the mail. If you decide to do this, you must also remove the DKIM signature. Otherwise, the recipient cannot successfully verify them. Depending on the setting of the mail flow rules of the receiving server, you run the risk that the mail will not arrive at all due to the missing signature.
In the following section we will introduce you to the Authenticated Received Chain (ARC), which you can use to get this problem under control.
ARC addresses precisely the major disadvantage of DMARC's strictness: it enables a mail relay server to sign the original authentication of the email sent. This gives the recipient of an email the opportunity to verify the origin of the email without taking into account the SPF and DKIM records (which are invalid due to the forwarding). Trust plays a big role here as the ARCs can be faked. The recipient must therefore determine whether or not to trust the ARC signatures.
Reverse Domain Name System (reverse DNS/ rDNS) queries help the receiving email server to confirm the authenticity of the sender. This is done as follows: Before the entire e-mail body is received, the header information is checked. In addition, a DNS query is made with the sender IP and the domain specified in the HELO Command. If the authoritative DNS server does not have a (suitable) pointer entry (PTR record) for the sender's IP, the e-mail will be discarded or moved to the spam area.
Using the sender restriction, a domain owner can determine which users within their domain are allowed to send emails “outside”, i.e. beyond their own domain. Using Postfix as an example, two different lookup tables are used here: one table in which all users with restrictions are listed, and another in which all “local” domains are defined. If a restricted user now wants to send an email to a domain that was not marked as local in the config, they will be rejected with a generic message.
As already mentioned, you can use various sets of rules for your domain that make it easier for you to deal with spam and other e-mails. You can picture it like this: an employee is standing in front of your mailbox and checks every letter that you put in using a set of rules you have defined. On this basis, he decides whether the letter should really end up in the mailbox or not. If, for example, you have recently received a lot of annoying advertising from a certain advertising agency, you can say, for example: "All letters that have a sender from this company location can be thrown in the trash without further examination".
This is exactly how digital email transport rules work. Depending on which appliance or provider you use, you can set up different sets of rules.
A common fallacy is the assumption that the Simple Mail Transfer Protocol (SMTP) is only at home on port 25 and that only this port is responsible for it. This was the case in the early days of the internet. In the meantime, however, the spectrum has expanded: in addition to port 25, ports 465 and 587 are also responsible for handling e-mails.
Why is this important to you? Depending on which ports are open and which configurations apply, e-mails can be treated differently depending on the port used. The following configuration would be possible, for example: e-mails that are transferred to the server on port 587 undergo specified security checks. However, emails can be submitted untreated on port 465.
These are the special features of all ports relevant to SMTP:
STARTTLS is a method presented in 1999 for establishing encrypted communication using Transport Layer Security (TLS). In the meantime, the use of STARTTLS is discouraged, since the initial communication setup up to the actual encrypted communication is in plain text. It is therefore vulnerable to man-in-the-middle or so-called "downgrade" or "STRIPTLS" attacks. These attacks require that the attacker has successfully positioned himself as a man-in-the-middle before the actual communication begins in order to prevent a secure connection from being established.
The recommended alternative is the direct, secure connection establishment via TLS via the predefined ports. In this case, communication does not take place in plain text and the use of TLS is negotiated, but communication begins directly with the TLS handshake.
How exactly would a downgrade/STRIPTLS attack work?
An attacker cuts in on an ongoing communication and starts sniffing traffic. If the attacker is able to intercept an incipient SMTP communication, he grabs the STARTTLS package. In this, the responsible mail server tells you that it wants to communicate in encrypted form and replaces the content with any character string that the client does not understand. The client can then assume that this is an option it does not understand and revert to using plain text.
An open relay is often a misconfigured SMTP server that allows emails to be sent and forwarded without prior authentication. While there are prerequisites that require the internal use of Open Relay. (A typical example is the frequently used scan-to-mail function.) However, if possible, the problem should be fixed instead of using a vulnerability as a workaround.
For example, an open relay allows an attacker to send e-mails with forged sender information via this server. Unfortunately, you can still find some such servers today.
If open relay is so insecure, why does it even exist?
Like many older protocols (such as DNS), SMTP dates from a time when the Internet as such was still very young and full of insecure configurations and standards. The aim was to ensure the highest possible availability of the services. The “normal” post also tries to deliver letters at any price. At the time, no one could have imagined that SMTP would ever be used to send spam in bulk.
Many have now migrated to secure configurations and providers, but some such legacy systems still exist. You can't just "disconnect" them and exclude them from communication.
Leadership vs. Management, what exactly are the differences? And what is needed in both areas to meet the current challenges?
Should standard users in your tenant be allowed to complete an Azure App Registration? The answer is clearly “no” and this article
The bad news first: In Germany there is no central nationwide emergency number for hacked companies or authorities. That's why it is
