Problem solve Get help with specific problems with your technologies, process and projects.

Protecting the messenger, part 2: Is Microsoft your Internet Messiah?

Protecting the messenger, part two: Is Microsoft your Internet Messiah?

Have hackers pitched their "tent of meeting" near your IT camp? Like Moses and the Israelites, are you wandering in the wilderness in search of security and the promised LAN - a network safe and secure from the bondage of hackers? Have you implemented mail server security, or is there a divine pillar of cloud guiding your company with network security? Is Microsoft your Internet Messiah?

We continue our three-part series on protecting your mail server with this follow-up to my article "Protecting the messenger, part one" which launched our investigation into your Exchange 2000 Server security. In this mini-series, we will focus on security at the Exchange System Manager level. However, it's important that you understand that layered security requires that you continually address the potential threats against any of the seven layers of the Open Systems Interconnect (OSI) model.

Join me on this journey as we continue to explore and identify the security vulnerabilities in your network.

Use caution when making changes in Exchange since it can impact part or all of Active Directory objects. Consult with your IT Manager to define an effective recipient policy for your organization. Make sure that you follow company protocol and adhere to policies and procedures before taking the initiative to address the need for customized recipient policies.

When was the last time you checked your Exchange Recipient Policy and Filter Rules? Are you still using Microsoft's default recipient policy and filters on your Exchange server?

Exchange recipient policy
Create one or more recipient policies and define filters for existing and new users in your Exchange Organization. Instead of accepting Microsoft's default policy, modify or customize the policy to reflect your existing environment. In Exchange System Manager, go to Recipients folder, de-collapse the folder and click on the Recipient Policies object.

If you're using Microsoft default policy, you'll see the "Default Policy" with Priority set to "low" and in the General tab a filter rule of (mailnickname=*). Right-click on Recipient Policies object and select New to create a new policy. Once you have completed your policy, remember to right-click on the policy to "Apply this policy now" and make it active.

Remove unnecessary e-mail address types
Prevent administrators from inadvertently generating incorrect addresses and users from accessing other unsecured mail systems. Remove unnecessary e-mail address types defined in the Generation Rules section of the E-Mail Addresses tab.

All global address lists security
Beneath the Recipient Policies icon, you'll find "All Address Lists" and "All Global Address Lists" on your left pane. You'll need to right-click each one, select Properties, and then go to the Security tab to view a list of groups and users with permissions. (Remember to test changes in a staging network and not in a live network.) Ensure that the groups Everyone and Authenticated Users do not have Full (or other special) permissions.

Restrict propagation of inheritable permissions
Replace the group "Everyone" with "Authenticated Users" and if possible, remove the Everyone object from inheriting any permissions. To accomplish this, click on the Everyone object and deselect "Allow inheritable permissions from parent to propagate to this object". You will be prompted to Copy or Remove or Cancel. Select Remove to replace inheritable permissions with explicitly specified permissions for the Everyone object. You'll need to remove this object from the "All Address Lists" and "All Global Address Lists".

Recipient update service
This service is responsible for processing updates to your address lists and maintains recipient modifications made in your Exchange environment. You will notice two services: Recipient Update Service (Enterprise Configuration) and Recipient Update Service (your domain name). Make sure that you customize the update interval to reflect your organization's update requirements, instead of accepting the "Always run" default value. Why create additional network traffic if it is not necessary?

Restrict update interval
Avoid "always running" the Recipient Update Service at the cost of mail security. Closely manage the update interval by choosing when updates will occur in your organization. (You can also customize when Active Directory services will propagate updates in your network.) You may find that running recipient/address list updates overnight is not required, and that propagating changes at that time can assist a hacker.

Set up a custom schedule to update changes during your company's hours of operations (for example, between 8 a.m. - 6 p.m.) You should also create a schedule for the Offline Address List. Remember you can always right-click on the service and select "Update Now" to force an update throughout your domain. My preference is to manually force updates, however, this may not be practical solution depending on your organizational structure.

Note: To rebuild and "recalculate the Address List membership and the Recipient Policy settings of all recipients in your domain in the next scheduled update interval", select "Rebuild".

Protecting the messenger (mail server) begins at the firewall
How do you begin to protect your mail server at the firewall? By identifying the maximum simultaneous connections recorded or logged to your mail servers(s) and enforcing that in your firewall static route/object entries for each mail server. This requires an understanding of the latest traffic volume to each mail server? Why allow unlimited connections in the firewall to your SMTP server, if your syslog server has never logged more than 100 simultaneous connections to the mail server?

Why allow more connections in the firewall to your Outlook Web Access (OWA) server than configured OWA users? These are just two servers (out of many) that can benefit from an embryonic limit; that is, a maximum connection limitation imposed in your firewall static entries for your mail server and OWA server objects.

Your firewall policy should reflect the minimum connection requirements (with some room for growth) of your servers, where the value of maximum connections is NOT set to unlimited.

Medina's 4-R rule of network administration
When in doubt as to deciding if a network administrator should be assigned privileges to administer part or your entire server, consider using my 4-R Rule of administration as a guide. The 4-R Rule of administration is: Retire or Renew based on Role or Requirements.

You won't want to miss my next installment in our protecting the messenger (mail server) mini-series. I can't wait to show you security tips with respect to the Administrator Groups, Exchange Tools, and eSMTP.

It's been my experience that some of these basic steps have often been overlooked by experienced IT professionals. If you're serious about security, you must pay attention to security details and leave no room for hackers.

In the absence of network security, exists an opportunity for intrusion.

Please write to me or visit my website (http://www.medinasystems.com) and let me know if this article has brought to light any potential weak links in your network.

Luis Medina is the author of "The Weakest Link Series," which offers network managers an opportunity to identify ongoing network security issues. Luis also answers security questions in SearchNetworkings Ask the Expert section. Submit a security question to Luis here or view his previously answered Ask the Expert questions.

This was last published in November 2002

Dig Deeper on Network Administration

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close