Solved

How to lock down the IP addresses allowed to connect to our Exchange 2010 server?

Posted on 2016-08-09
12
34 Views
Last Modified: 2016-10-09
It is possible for an attacker to bypass our Spamtitan protection service by sending emails directly to our Exchange server rather than sending to the host specified by our DNS MX records. I understand there is a way to restrict using firewall. Besides using firewall, can we use the Receive Connectors where we can put the Spamtitan's ip address? It is in the Network tab / "Receive mail form remote servers that have these IP addresses:"

please help.
0
Comment
Question by:Castlewood
  • 3
  • 3
  • 2
  • +2
12 Comments
 
LVL 5

Assisted Solution

by:Manuel Flores
Manuel Flores earned 124 total points
ID: 41749456
You should restrict the access to SMTP ports except for Spamtitan service.

Your exchange server public IP could receive any mail directly if not restricted.

..MFlores..
0
 
LVL 39

Assisted Solution

by:Adam Brown
Adam Brown earned 186 total points
ID: 41749462
Yes, you can use the Accept from servers with these IP addresses list to limit remote access to the mail server. Only the IPs you list there will be able to connect to the exchange server using the port assigned to the connector, so you can limit that way as well as with a firewall. It is usually best, though, to use both methods together for layered defense.
0
 
LVL 14

Accepted Solution

by:
Todd Nelson earned 128 total points
ID: 41749476
My guess is that you are an open relay.  If the firewall is not isolated for SMTP (including 587) from only the spam host to your perimeter network, then you will be subject to anyone bypassing your spam host--via port scan based in IP.

Additionally, I would recommend that your firewall is also configured so that only your Exchange server(s) are allowed to send outbound SMTP.

Personally, I would not touch the receive connectors as that could potentially introduce issues for client connectivity.

If your receive connector settings are not configured like the following reference you could have problems with inbound (or internal) mail flow ... https://oddytee.wordpress.com/2016/01/12/exchange-2010-default-receive-connector-settings/
0
Does Powershell have you tied up in knots?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 

Author Comment

by:Castlewood
ID: 41749533
Todd,
You mentioned "Personally, I would not touch the receive connectors as that could potentially introduce issues for client connectivity."
Can you give an example of the issue caused by changing Receive Connectors please?
Thanks.
0
 
LVL 14

Expert Comment

by:Todd Nelson
ID: 41749542
Potentially could prevent inbound mail flow and communication with other Exchange servers within the organization.  In my experience, they have been changes that were made that affected Exchange coexistence and migration projects.  In many cases where I've added additional Exchange servers within an organization or performed a migration to Office 365 for a customer, where the receive connectors have been modified, I have had to reset these connectors to default in order to get coexistence working properly.

I understand if a company doesn't have additional Exchange servers, but if the foundation is not stable, neither is the house.
0
 
LVL 39

Assisted Solution

by:Adam Brown
Adam Brown earned 186 total points
ID: 41749547
@Todd - That is not correct. The Port 25 Receive Connector is not used for internal Exchange Server to Exchange Server communications, nor is it used for Outlook connectivity. It is only used to receive messages from the internet. It will not allow POP3 or IMAP outgoing messages either. That uses the Port 587 Receive connector.

The error you dealt with in the past was likely due to the additional servers not being added to the Default Internet Send Connector, or not having a copy of the Hybrid Coexistence receive connector configured for the new server. Send connectors exist on an Organizational level (meaning all send connectors are available to all servers). Receive connectors exist on a server by server basis only. If it fails to communicate in a Hybrid Coexistence with O365, it's usually due to the EOP IPs not being in the connector, which is easy enough to add, since they are publicly available.

Limiting the IP address list allowed to use the Receive Connector set for port 25 will only prevent external communications from servers that are not in the list of allowed IP addresses. That is exactly how you would limit communication to your Spam filter/smart host IPs if you don't have access to limit the Firewall ports (like many Exchange Administrators). It is best to *also* limit the Firewall accepting connections on port 25 to the Spam filter IPs, but since most Exchange Admins either have no access to the Firewall configuration or lack the knowledge necessary to change firewall settings, changing the receive connectors will accomplish the goal just as well as doing so through the firewall. Exchange will simply refuse all connections on port 25 that don't meet the IP limitations.
0
 
LVL 22

Assisted Solution

by:yo_bee
yo_bee earned 62 total points
ID: 41749574
I have my firewall accepting port 25 traffics from only my spam filter service. All other connections attempts to port 25 on my firewall are rejected.

This is the best and most secure way to handle this right at the perimeter of your network.


Make sure that the only mx record registered is your spam filter service.
1
 
LVL 14

Assisted Solution

by:Todd Nelson
Todd Nelson earned 128 total points
ID: 41749582
Andy,

I can agree with your comment of Exchange regarding the configuration of receive connectors as part of the holistic approach with a firewall.

Food for thought...
However, how can you blindly refute what I've experienced and what it took to address those issues?  Castlewood asked for an example and I provided him with one that I have seen many times.  Your assumptions are off base.  I'm certain you have seen some interesting Exchange configurations but who would I be to tell you what you saw and did to resolve them was wrong.

Good day, sir.
0
 
LVL 5

Assisted Solution

by:Manuel Flores
Manuel Flores earned 124 total points
ID: 41750499
Hi Castlewood,

So finally, if you can, configure your firewall so just the IP's from your spam gateways service are allowed to hit your Exchange server from the outside and just to the correct ports.

It is not necessary to modify the exchange connectors, at least not for what you asked for.  However, if you suspect, or have any problem related to unwanted relayed emails, etc.  Let us know, I think better in other thread.

..MFlores..
0
 

Author Comment

by:Castlewood
ID: 41750950
Thank all you guys.
One concern raised while locking down firewall to only allow our spam filter host incoming SMTP traffic to hit our Exchange is: we currently don't route the outgoing mails to the spam filter host. Would that become an issue for our Exchange to be labeled as a spam generator since our Exchange directly sends out mails but don't directly receive mails?
0
 
LVL 39

Assisted Solution

by:Adam Brown
Adam Brown earned 186 total points
ID: 41751174
Having messages send from a server that doesn't match up with your MX records is a potential red flag. But it is best mitigated with the use of a properly configured SPF record. Most spam filters today will take SPF records into account when processing messages, but that alone is not a guarantee that things won't get blocked by spam filters. However, if you are already set up to send messages directly and not through your incoming spam provider, locking down the firewall will not result in a sudden flood of messages from your organization getting blocked.

@Todd - You made a recommendation to not ever modify receive connectors. That is a very bad recommendation that goes counter to best practices. Your suggestion that modifying receive connectors could block communication between Exchange servers is flawed, regardless of your experience. It is possible with Exchange 2013 and later to block communication by modifying some settings of the Default receive connector. However, this issue doesn't really occur if you avoid installing CAS and MBX roles on separate servers (per recommendations from MS). Your statement:
In many cases where I've added additional Exchange servers within an organization or performed a migration to Office 365 for a customer, where the receive connectors have been modified, I have had to reset these connectors to default in order to get coexistence working properly.

Suggests very strongly that you didn't actually determine the cause of the problem you were faced with. I suggested a few potential causes based on how receive connectors work. You're right, I wouldn't know the exact problem without looking at it, but recommending a course of action to prevent a problem that you don't have a valid solution to doesn't help the person asking the question. We have a responsibility as Experts on here to be as accurate as possible with our answers and recommendations. A solution that works isn't always a good solution to use. I've run into countless environments where people just took the first solution that solved the immediate problem without realizing the consequences of doing so. If I correct people on here or point out when they are wrong, it's out of a desire to see things get solved correctly. Also...my name is not Andy.
0

Featured Post

Courses: Start Training Online With Pros, Today

Brush up on the basics or master the advanced techniques required to earn essential industry certifications, with Courses. Enroll in a course and start learning today. Training topics range from Android App Dev to the Xen Virtualization Platform.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

MS Outlook is a world-class email client application that is mainly used for e-communication globally.  In this article, we will discuss the basic idea about MS Outlook, its advanced features, and types of MS Outlook File formats.
This article aims to explain the working of CircularLogArchiver. This tool was designed to solve the buildup of log file in cases where systems do not support circular logging or where circular logging is not enabled
The basic steps you have just learned will be implemented in this video. The basic steps are shown to configure an Exchange DAG in a live working Exchange Server Environment and manage the same (Exchange Server 2010 Software is used in a Windows Ser…
This video discusses moving either the default database or any database to a new volume.

813 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now