Shulou(Shulou.com)06/02 Report--

Ensuring e-mail security is probably one of the most important and difficult tasks that administrators must face. Every day, the server handles thousands of e-mails, and it is not easy to control such a large amount of mail traffic. No wonder we focus on this channel when planning. They use a variety of techniques to make users think it's a good idea to open a suspicious attachment.

What is email spoofing? E-mail fraud is a very popular method. The sender modifies the message title to send an e-mail from someone else. For example, * uses it to imitate company employees to obtain login credentials, personal data, or other confidential information. The two most common ways to protect your organization from external fraud are:

SPF record-list of IP addresses that are authorized to send e-mail messages from the domain.

DKIM check-an email authentication method. It enables you to sign and verify e-mail messages using both public and private keys. The public key published in the DNS record is used to verify that the message is from the original sender. You cannot configure it locally on Exchange Server-you need a plug-in for the SMTP gateway.

Both of these methods can lead to very bad results when fighting external deception. When an employee tries to impersonate a colleague, we encounter the problem of internal deception. It could be a joke, or to get some benefits-either way, it can destroy the company in a variety of ways:

Lead to chaos

Induce material damage

Compromise data integrity

Damage the company's reputation.

To make matters worse, fighting internal deception attempts requires a slightly different approach. Now I'll show you how to prevent internal e-mail spoofing in your Exchange organization. But first, quickly explain the test environment:

Test environment

For demonstration and testing purposes, I will use the following machines:

-Windows Server 2012 as the domain controller. The domain name is domain128.lab,IP 192.168.23.1

-Windows Server 2012 R2 and Exchange 2016 CU3,IP 192.168.23.2192.168.170.79

-Windows 10Magi IP 192.168.23.3 with Outlook 2013

-Windows 7 Magi IP 192.168.23.4

Now is the appropriate part. I will show you how to perform email spoofing and how to prevent them:

Internal email spoofing

First, let's look at how an employee pretends to be another user when sending an email. A PowerShell cmdlet is enough to achieve this. In the following example, user1@domain128.lab simulates user3@domain128.lab and sends an email to user2@domain128.lab

The cmdlet used by user1 is as follows:

Send-MailMessage-SmtpServer 192.168.23.2-To user2@domain128.lab-From user3@domain128.lab-Subject "It`s me user3"-Body "Send me your report"

Of course, such e-mails should not do any harm. If user2 replies to the message, the email goes to user3 instead of * *. The problem is that with some modifications, Send-MailMessage can send an HTML email with a malicious link, or attach an infected file. I won't use examples to illustrate how to use deception to hurt an organization, but believe me; there are many.

The same technique can be achieved using the Telnet client. The Telnet client is not installed by default, but you can open or close Control Panel > programs > Open Windows Features, and then select Telnet client to open it. To test internal email spoofing, run cmd.exe and connect to your server by plugging in port 25:

Telnet 192.168.23.2 25

Just remember to use your IP address instead.

Next, using the SMTP command, you can send an email:

HELO domain128.lab (connects to your domain)

MAIL FROM: user3@domain128.lab (address of the user you want to impersonate)

RCPT TO: user2@domain128.lab (your victim's address)

DATA: it enables you to specify subject and body of your email. Enter a full stop (.) In a new line to finish data input.

Both methods end with the same result:

For a more realistic scenario, a similar * * deployed in different environments is as follows:

As you can see, e-mail is no different from any other message sent in a normal way. It is easy for the recipient to fall into this trick. As an administrator, you can detect such actions in Exchange logs, but in large organizations with a large number of users and dense mail flows, it can be troublesome to say the least. Not to mention that this can be done before such an attempt is discovered. So why does Exchange allow such behavior? And how to stop it?

In the default Exchange deployment, a receive connector is created. The default front end (the name of your server) is configured so that it:

Receive from all IP addr

Use the default SMTP port 25 to receive email

Disable email from anonymous users

The last point is the reason why internal users abuse the mail system. Unfortunately, turning off the permissions of anonymous users also prevents receiving e-mail from external e-mail addresses. Well, I don't know under what circumstances this would be a reasonable choice.

How to prevent internal email spoofing

There may be many third-party solutions that can defend against this threat, but in this article, I will only show you how to eliminate cheating within organizations that use native Exchange mechanisms. I will demonstrate two methods:

Use SPF to record

As I have already mentioned when describing external * *, one of the most popular (and effective) weapons in anti-spoofing attempts is the use of SPF records. See the syntax of the SPF record below:

V=spf1 ip4:your_server's IP-all

In short, the SPF record resides in the DNS area file. They specify the IP address of the server that allows e-mail to be sent from a domain. This mechanism can be used to ensure internal communication in a manner similar to that commonly used for external communication. To make this method applicable to internal email spoofing, you need to configure three elements:

SPF records in the local DNS

Anti-spam function in Exchange Server

Sender ID agent.

Before I introduce the configuration process, I'll talk about its main shortcomings. To use this method to completely prevent internal email spoofing, you must include all IP addresses (including printers, applications, and other Web objects) that allow e-mail to be sent on the network. If you have a huge network with loads on various devices, this is not the most convenient solution. But if you don't have an overwhelming infrastructure and you know it's like your hand, then the solution should work well.

Step by step exercise

First, you should create a txt record on the DNS server in the local domain. As far as I am concerned, the record will be as follows:

V=spf1 ip4:192.168.23.2 ip4:192.168.170.79 ip4:192.168.169.51-all

192.168.23.2 and 192.168.170.79 are the IP addresses of my Exchange Server, while 192.168.169.51 is the IP address of my network printer in another subnet. The printer sends an email to Exchange.

The next step is to install Exchange Antispam Agent. You can use PowerShell to do this. The cmdlet is:

& $env:ExchangeInstallPath\ Scripts\ Install-AntiSpamAgents.ps1

A successful installation should look like this:

To apply your changes now, restart the MSExchangeTransport service:

Restart the service MSExchangeTransport

Provide the IP addresses of all Exchange servers:

Set-TransportConfig-InternalSMTPServers

I have to provide two addresses because my Exchange Server has two network interfaces.

We're almost done. You must now configure a rule to reject e-mail messages from addresses that are not included in your SPF record. PowerShell cmdlet is:

Set-SenderIdConfig-SpoofedDomainAction Reject

All that is left is to test whether the current configuration successfully prevents internal spoofing attempts. I'll use the same cmdlet described at the beginning of this article. Instead of sending an email, you should get the following error:

As you can see, the Exchange server blocks attempts and displays error 5.7.1 "Sender ID not allowed".

Even if the user enters his own mailbox in the-From attribute, the effect will remain the same:

Finally, let's check what happens if I try to pretend to be another user on the computer whose IP address is 192.168.169.51 (I added it to the local SPF record earlier):

There is no problem with the passage of the mail:

This example shows another disadvantage of the SPF recording method. Because authentication is based on the sender's IP, misconfiguration does not guarantee that your company is completely protected against internal fraud.

Implementing this method does not affect sending email from email clients (Outlook,OWA or ActiveSync) because they use RPC or MAPI through HTTP through different ports (443 or 80).

Use a dedicated receive connector

The second method is to create an additional receive connector on port 25. The connector controls the local network and allows only e-mail from domain users. This approach uses different authorization methods. It uses domain credentials (login and password) instead of using IP. A change in the authorization method creates a problem-all internal exchange connections must be authorized. In other words, every Web device and application that sends email to Exchange needs a domain account (or at least one regular account).

As I mentioned earlier, the connector will be set to TCP port 25. However, as you know, there is already a receive connector that accepts anonymous connections from the SMTP server on port 25. So how does the connector work with one you are going to create? How does Exchange know which one to choose? Exchange Server is quite clever when it comes to this. The server will always choose a more precise connector for each connection. The receive connector I configured is defined for the LAN network, and the default applies to all connections. Therefore, for internal SMTP connections, Exchange will always select the new connector specified for LAN.

Step by step exercise

In addition to being more secure, the second approach is easier to implement. This is because it only needs to create a new receive connector. You can use a good PowerShell cmdlet. I'll use the internal client SMTP name for the connector so that it can be easily recognized later. Remember, the IP scope is personalized for my environment:

New-ReceiveConnector-Name "Internal Client SMTP"-TransportRole FrontendTransport-Usage Custom-Bindings 0.0.0.015 25-RemoteIPRanges 192.168.23.0 RemoteIPRanges 24192.168.170.0 AuthMechanism TLS,Integrated-PermissionGroups ExchangeUsers

I should also be able to go to Exchange Management Center > Mail flow > receive Connector > New:

These settings are similar to the cmdlet used above. The connector should be internal and the role should be set to front-end transport. Unfortunately, the default role is Hub Transport, and I can't seem to change it to the option I need. Let's continue to see what happens.

The next page is very important-this is where you must specify all LAN networks in your organization. In my case, it is 192.168.23.0 amp 24 and 192.168.170.0 amp 24.

This is where Exchange caused the error.

The values you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on the receive connector "ENV128-E2016\ Default Frontend ENV128-E2016". Receive connectors assigned to different transport roles on a single server must listen for unique local IP addresses and port bindings.

It seems that Exchange doesn't like to have two connectors with different transport roles listening on the same port. However, the two roles are different only because an option is grayed out. This is unique considering the fact that a single cmdlet does not throw any errors. You can check to see if you encounter the same error, but my recommendation is to use PowerShell.

The connector (no matter how you create it) should appear in the list:

Let's test it now. User1 will attempt to send a message to user2@domain128.lab as user3@domain128.lab.

The PowerShell command has been used several times in this article, and no email is sent this time. The error code is different from the error code that occurred using the above method: the 5.7.60 SMTP; client does not have permission to send this sender.

Well, what if the user tries the same technique after providing his / her credentials?

Well, still no luck. However, when the same user stops trying to display as someone else:

The cmdlet performs its work. Today's victim user3@domain128.lab can read the email as well as the original sender:

If a malicious user attempts to use telnet, internal spoofing attempts will also be blocked:

Summary

As an Exchange Server administrator, you must know that the default Exchange deployment is not sufficient to protect your users from malicious emails. Fortunately, you can use this guide to completely prevent internal email spoofing. Both methods are based on the native Exchange mechanism and require only a little effort.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.