Category: Security

Security Tutorials

Testing Email Server Security

Back in the day, getting a mail server set up was definitely not a point-and-click operation. Today, messaging systems are much easier to get up and running – often no more difficult than installing any regular desktop software package.

Unfortunately, simplicity often comes with a price. While installing a mail server and getting it to exchange messages with other SMTP servers is no longer a tangled web of configurable settings at a basic level, there’s still plenty to consider on the security front. Most importantly, you’ll want to ensure that your server is not being used as a junk mail gateway by spammers.

It used to be the spammers used their own servers to send out spam email messages. While this is sometimes still the case, most “spamming” servers have been shut down by service providers or “blacklisted” as known sources of spam. Needing a way to continue getting their messages out, spammers next turned to other user’s mail servers. Specifically, they scan the Internet for unsecured mail servers that allow what is known as “relaying”.

In a nutshell, relaying ties into the lack of security with the SMTP protocol used to send messages – typically you don’t provide a username or password to send messages. So, if no other restrictions are implemented, any user can send set an unsecured mail server as their SMTP server, and then fire messages through that server at will – often thousands at once. Ultimately, it’s the mail server owner who has to deal with the fallout. Their server ends up being blacklisted as a source of spam, and other servers that subscribe to blacklists won’t exchange mail with them. Even after securing the email server to deny relaying, it can often take weeks to be removed from these blacklists, a frustrating exercise that you just don’t want to deal with.

They key to not having your mail servers used as a spam gateway is to block relaying. Different servers implement different techniques to prevent relaying, from checking sending user domain names (ineffective, as spammers can spoof these), to limiting senders to those on a specific network. Most SMTP servers also support authentication, allowing you to require users to supply a username and password to send messages via the server.

This tip isn’t about securing your particular mail server, but rather testing its security. If you want a quick an easy way to determine whether your mail server allows relaying, just head to http://www.abuse.net/relay.html.

If you input your mail server’s IP address or host name and click the Test for Relay button, this service will run through 17 different tests to check whether your server allows relaying. If your server is properly secured, you’ll be presented with the message “All tests performed, no relays accepted”. That’s good news.

Should your server fail any of the tests, you’ll want to get on top of things immediately. All mail server software packages provide clear documentation on ways to prevent relaying. If you don’t get the issue sorted today, you may just end up on a blacklist tomorrow. So, take a moment to test your mail server and be sure that it’s properly secured.

Securing Active Directory Using a Roles-Based Approach

While Windows 2000 and 2003 offered a few new Built-In security groups to use in granting permissions to administrative resources, they both still leave much to be desired when designing security models. With the advent of Sarbanes-Oxley (thanks again Enron), System Administrators are now tasked with not only increasing security, but also auditing changes to the environment. (Note – change management also plays a major role regarding Sarbanes-Oxley; however, that topic is too expansive to be discussed here.)

Let’s take a slight step backwards and define exactly what role-based security is. In a nutshell, role-based security is creating ACE’s (Access Control Entries or users and groups) based upon job function and then using very specific ACL’s(Access Control Lists) to lock them down allowing administrators to have the ability to perform only their job function and nothing more. For example, if we have a junior administrator that performs basic user creation and administration as well as basic workstation management, we probably don’t want this person to have the ability to delete server accounts from AD, or modify Cisco Unity attributes on user accounts, or alter PKI certificate settings in the environment, etc. Using the built-in groups, this is quite cumbersome to do but using a role-based approach, we suddenly discover a new level of granularity that makes such detailed permissions possible.

First Steps

Before we can start creating groups for our different permissions, we must first define our roles. This will more than likely entail some interaction with the management team and HR staff to obtain the company accepted titles and their required job functions. (If you are fortunate enough to have input into this, now is a great time to redefine job responsibilities if they are misaligned to new technologies because they haven’t been updated in a while.)

Once we’ve obtained the roles within the company, we can begin to create the role-based groups in AD. These groups will mimic the roles in title so we know what they represent. For example, if we have a Sr. AD Engineer, AD Engineer II, System Administrator, and Jr. System Administrator we might want to use the following naming schemes for the groups:

* GG_Sr_AD_Eng
* GG_AD_Eng
* GG_SysAdmin
* GG_Jr_SysAdmin

We prepend the “GG” to the name so that we know it’s a Global Group. We will use Global Security Groups to nest within Domain Local Groups explained next. Remember, we can only nest Global Groups with Domain Local Groups, not the other way around. In addition, this allows us the ability to nest the Global Group within Domain Local Groups in other domains if we have a multi-domain forest (must be at least 2000 native mode).

Defining the Access Groups

Now that we have our role-based groups, it is time to create the groups that will allow the actual access to the AD resources. Since domains are simply security boundaries we would create the access groups as Domain Local Groups within each domain in our forest. (Note – we can also apply this same functionality to Forest and Site objects as well. In addition, in Windows2003 we could use Universal Groups as the replication traffic is greatly reduced since only attribute level deltas are replicated instead of the entire object.)

This part is a bit trickier than before as we need to be careful to allow for all necessary permissions for each role to be able to perform their job functions. An easy method to use in visualizing this is a spreadsheet matrix format. Let’s define the job functions of the aforementioned roles as follows (these examples are vastly simplified as there are thousands of possible configurations):

  • Sr_AD_Eng
    • Create, modify, delete users
    • Create, modify, delete workstations and servers
    • Create, modify, delete groups
    • Create, modify, delete OU
    • Create, modify, delete GPO
  • AD_Eng
    • Create, modify, delete users
    • Create, modify, delete workstations and servers
    • Create, modify, delete groups
    • Create, modify OU
    • Create, modify GPO
  • SysAdmin
    • Create, modify users
    • Create, modify workstations and servers
    • Create, modify groups
  • Jr_SysAdmin
    • Modify users
    • Create, modify workstations
    • Modify groups

Remember, each of these are Domain Local Groups that need to be created as listed below.

Our matrix would be as seen in this table.

By using our matrix, we can better visualize who has permissions to do what in the environment. Each cell in the leftmost column represents a Domain Local Group that will be created and the cells in the top row represent the Global Groups we used to define roles. This can be easily be tailored to meet any needs for any AD environment and depending upon the security definition requirements can grow to be quite large depending on how granularly the permissions in the left column are defined.

Implementing the Security Model

The next step is to actually modify the ACL’s on AD resources to meet our security requirements defined in our matrix. To do this we initially use the Delegation Wizard to create the security framework and then the ACL Editor to “tweak” the settings. We will use the DLG_Create_Modify_Delete_Users Domain Local Group in our example.

1. First, open up ADUC and navigate to the Users OU. (It’s always a good idea to move users out of the default Users container into a separate custom OU so that more granular GPO’s can be applied.) Right click on the OU and select Delegate Control. Next, click the Add button and select the DLG_Create_Modify_Delete_Users Domain Local Group created earlier then click Next to get to the Tasks to Delegate window.

2. We will want to select Create a custom task to delegate as the standard common tasks are too broad and will grant more permissions than we want which will require us to go back and make more edits in the ACL Editor later. Click Next.

3. As we are only interested in modifying the ACL’s for User objects in this OU, select the Only the following objects in this folder button. In the object window, select the User objects checkbox. Next, select the Create and Delete checkboxes underneath as we want the Domain Local Group to be able to both create and delete user objects in the Users OU. Click Next.

4. In the Permissions window, select the Property-Specific checkbox in addition to the already checked General checkbox. This brings up many more attribute options for us to work with.

Note – The list of attributes in the Permissions window is NOT a complete list of all the attributes for an object. This list is controlled by the dssec.dat file located in the %SYSTEMROOT%\System32 directory on the Domain Controllers. This file can be edited using Notepad and defines what appears in this list. For example, the City attribute does not appear by default. To modify the file to enable this attribute to appear, open the dssec.dat file in Notepad and navigate towards the bottom to the [user] section. Look for the “l” (lowercase L) attribute and change the number from a 7 to a 0 (zero) and save the file. This setting will make the City attribute appear in the list and be Read/Write enabled. You must close and open the ADUC for the changes to take effect.

5. Select the following settings in the Permissions window to grant the DLG_Create_Modify_Delete_Users Domain Local Group the ability to create, modify, and delete user accounts:

  • Read
  • Write
  • Read all Properties (enables the Read flag on all other attributes)
  • Write all Properties (enables the Write flag on all other attributes)
  • Change Password
  • Reset Password

Review the rest of the permissions and then click Next and then Finish to apply the changes.

6. Follow steps one through four for the other Domain Local Groups. Modify the selections in step five to reflect the correct settings in the matrix we used earlier for each access role.

Review and Edit Permissions using the ACL Editor

1. Right click on the User OU again and select Properties. Next, select the Security tab and then the Advanced button to bring up the Advanced Security Settings window.

2. Highlight the entry for the DLG_Create_Modify_Delete_Users Domain Local Group that has Special underneath the Permissions column and select Edit. In the editor we can view the currently selected Permissions as well as make modifications to the settings.

3. Modify the existing ACL permissions that were created by the Delegation Wizard as needed.

Configure Auditing

In order to track changes made to an object in AD, we must enable Auditing on that object and then specify the ACE (a user or group object) that will be audited as well as what parameters we are going to audit.

1. From the Advanced Security Settings window select the Auditing tab.

2. Select the Add button and add the DLG_Create_Modify_Delete_Users Domain Local Group. Click OK.

3. This brings up the Auditing Entry window in which we will define the level of auditing we want to perform for the DLG_Create_Modify_Delete_Users Domain Local Group on User objects in the Users OU. In the following example, we have selected to audit whenever a member of this group deletes a user object from this OU.

4. Repeat these steps for each additional Domain Local Group on each object that needs to be audited.

Final Steps

To bring it all together we will now nest the Global Groups into the appropriate Domain Local Groups. Using the Jr. SysAdmin role as an example we would place the GG_Jr_SysAdmin Global Group into the DLG_Modify_Users, DLG_Create_Modify_Computers, and DLG_Modify_Groups Domain Local Groups.

Erasing Files and Hard Drives Securely

If you’re planning on recycling, donating, or even scrapping your old PC, it’s important to ensure that you’ve securely erased all data from your hard drives. Too many people make the mistake of simply formatting the drives prior to getting rid of their old PC, thinking that their personal/business data has been safely erased. Even harder to imaging is the fact that many people don’t bother to delete anything prior to c