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

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.
Who is Participating?

Improve company productivity with a Business Account.Sign Up

Todd NelsonConnect With a Mentor Systems EngineerCommented:
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 ...
Manuel FloresConnect With a Mentor Commented:
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.

Adam BrownConnect With a Mentor Sr Solutions ArchitectCommented:
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.
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

CastlewoodAuthor Commented:
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?
Todd NelsonSystems EngineerCommented:
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.
Adam BrownConnect With a Mentor Sr Solutions ArchitectCommented:
@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.
yo_beeConnect With a Mentor Director of Information TechnologyCommented:
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.
Todd NelsonConnect With a Mentor Systems EngineerCommented:

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.
Manuel FloresConnect With a Mentor Commented:
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.

CastlewoodAuthor Commented:
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?
Adam BrownConnect With a Mentor Sr Solutions ArchitectCommented:
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. name is not Andy.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.