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 casting their system off into the wilds. If you’re even the least bit interested in maintaining your (or your company’s) privacy, you’ll want to give your system a good scrubbing before it heads out the door.

I know. Who in the world could care less about your old data? Unfortunately, the answer that question is that you just never know. Most users rid themselves of an old PC by giving it to a friend, dropping it off at a recycling facility, or donating it to a charitable cause. Many of these systems in end up in the hands of normal people who will simply format the drive, install an operating system and programs, and be on their merry way. However, there are some people who just can’t help but be nosy, and will take the time to rummage through the hard drive first.

What’s that you say? No worries because you made a point of formatting all of the system’s drives? Sadly, this is the technique used by most users to clean up their data, but unfortunately it does nothing to truly wipe the drive free. A format simply deletes partition tables, with all data still stored in clusters on the disk. Any undelete program will be able to quickly scan the drive, and though it might not find all of your files, it certainly will find its fair share and be able to recover them easily.

Rather than run the risk that the next user of your PC will be able to sift through personal information about you (including credit card information, email messages, and documents), its important to “scrub” the drive to be sure that all of your data has been safely deleted. It’s simply better to be safe than sorry.

Secure Erasing Methods

Without getting into the specifics of data scrubbing techniques ands methods in too much detail, the basic premise of scrubbing a drive involves overwriting every sector on a disk to be sure that the previous data stored on the drive cannot be read. The most basic (and fastest) method involves overwriting every sector on the disk once with repeating values. This technique makes it difficult (but not impossible) for data to be recovered using software or hardware methods. For perspective, the US government (DoD) considers a disk to be “clean” (unrecoverable) after 7 overwrite passes on the entire disk. However, users very serious about ensuring that data is unrecoverable should use the “Guttman” method, which involves overwriting the disk an incredible 35 times. Most commercial data scrubbing applications support up to at least 35 passes, and some even more.

Two popular tools commonly used to scrub drives are Drive Scrubber from iolo technologies and Eraser, a free tool that can be downloaded from www.heidi.ie.

Because Eraser is freeware and one of the most popular tools available, it’s definitely worth a closer look. Eraser includes a tool to securely scrub hard drives using a bootable floppy disk (Darik’s Boot and Nuke) as well as a Windows utility that allows you to securely delete files or scrub free space on your existing partitions.

Boot and Nuke

As the name would suggest, Darik’s Boot and Nuke is a very dangerous tool. After using the WinImage extractor to create the “nuke” boot floppy disk, you then reboot the target system with the disk in drive A. The main point of this program is to securely delete everything, so NEVER run it on a system that you intend to use again.

Files and Free Space

Finally, installing Eraser also provides you with the main Eraser application (see annotation) which allows you to create tasks that will securely delete files and clear disk space on-demand or according to a schedule. It even adds handy shortcut menu items to permanently erase files and clear disk space quickly and effectively – just be careful!

Securing Email Messages and Files Using PGP

Privacy and data security in the Internet age are huge issues. Many of us send hundreds if not thousands of email messages per year, and give little thought to what happens after we hit the Send button. We naturally assume that the message will arrive in the mailbox of our intended recipient, and that this person will be the only person to see our message. Unfortunately, nothing could be further from the truth.

Given the open and inherently unsecured nature of email (and by extension, the Internet), there’s nothing stopping anyone – from hackers to government – from tracking your correspondence. This may not be as simple as it sounds here, but with a little time, money and effort it is not nearly as difficult as you might imagine.

Much in the same way that you might put a letter in an envelope to hide its contents, there are also methods available to secure your email and data files. Of the methods that exist, Pretty Good Privacy (PGP) is among the most secure, in that it makes use of what is known as public key cryptography to both securely encrypt and digitally sign messages and/or data files.

PGP was originally developed by Phil Zimmerman in 1991. Shortly after the release of version 3, the US government laid criminal charges against him, claiming that PGP encryption was ‘munitions grade’. Although the charges were eventually dropped, the fact that the US government went to such lengths gives you an idea of how secure PGP is.

Pages: Page 1, Page 2, Page 3, Page 4, Page 5, Page 6, Page 7

Audit Your Wireless Network

The best way to ensure the security of your wireless network by far is to perform your own regular security audits. Far from being a complex task, performing an audit involves taking many of the same steps that a hacker might use to try and compromise your network, and using common “tools of the trade” like Network Stumbler and AirSnort. To perform an audit, grab a Wi-Fi equipped laptop or PDA, and then take a walk. Literally position yourself in different areas within and around your home or office, and then try to connect to your network. Keep in mind that Wi-Fi signals can often extend to ranges of up to 1000 feet, so a trip to your parking lot or different floors of your building may be in order.

Your best bet when performing an audit it to start off by configuring the wireless network card in your laptop of PDA with the default security settings, which usually means that no security settings (like WEP or WPA) are enabled. Then, try to associate with different access points on your network. Install and use Network Stumbler to determine whether your network is visible, and how many of your network’s settings this tool can obtain.

Many of the client utilities included with wireless network adapter cards include the ability to scan for additional networks in a manner similar to Network Stumbler. You may be surprised at how many networks you find in your vicinity that you never even knew existed. If you do come across other networks whose owners you recognize (by their SSID value, for example), be sure to let them know of the potential security risks they face. Another benefit of doing so is that you might find that a “neighbour” is using the same wireless channels on their network as you are, which would provide the opportunity for you both to move to a distinct channel, potentially reducing interference and improving performance.

Wireless Router DHCP Settings

Most access point hardware includes a built-in DHCP server to automatically allocate IP addresses to your wireless clients. In many cases, this range is the same as the range used for other Internet-sharing services, such as Windows ICS. Because of this, you’ll need to be careful of conflicts, since multiple devices (including other access points) may be handing out duplicate IP addresses on your network. Be sure to limit DHCP functionality to a single device by disabling the service on either your access point or other internal servers. If you’re using ICS to share an Internet connection, the DHCP component cannot be disabled, so keep this in mind.

Some folks recommend changing the IP address range used by your DHCP server if possible. Most access points will hand out addresses in the 192.168.0.x range, another well-known fact. Unfortunately, simply disabling DHCP will not solve the problem, since rogue users will commonly configure themselves with a static address in this range as an educated guess. To combat this issue, consider changing the gateway IP address of your access point from the default value (typically 192.168.0.1), and use static addressing for wireless clients instead. If anything, this will make things harder to guess, but realize that anyone using a packet capture utility on a network not using WEP or WPA would still be able to determine the range in use with relative ease via a utility like AirSnort. This is just another reason why implementing MAC address security is critical as a method of limiting which systems can connect to your network.

Wi-Fi Protected Access (WPA)

The fact that numerous security issues with WEP have been brought to light hasn’t gone unnoticed in the eyes of vendors that manufacturer Wi-Fi equipment. Although not yet officially standardized by the IEEE (the same folks that (standardized) the 802.11 Wi-Fi standards, the industry has come together in support of a new wireless encryption method known as Wi-Fi Protected Access, or WPA. WPA addresses many of the shortcomings of WEP by including a facility for dynamically changing the encryption keys used between wireless access points and clients on a regular basis.

Unfortunately, only the newest Wi-Fi equipment currently ships with WPA capabilities, although many vendors are providing firmware updates for existing access points and network cards, so check the vendor’s website for your particular equipment. If your equipment already supports WPA, you’ll need to download an update to get it working with Windows XP clients – see this KB article for more information on how WPA functions, and to download the update (Service Pack 2 for XP also adds WPA capabilities).

Wired Equivalent Privacy (WEP)

Because Wi-Fi networks use radio signals for communication, the packets transferred between wireless clients and access points are literally floating in thin air, for the entire world to see. Even without the ability to associate with an access point, any user running a wireless packet capture utility like AirSnort can literally capture packets and view their contents. To the untrained eye, these packets might seem to contain a fairly useless hodge-podge of information such as an address of a URL being visited by a wireless user. To a potential hacker, however, the information contained within these packets is exceptionally useful. Not only will they provide information such as the IP address range in use on the network, they will also include the network SSID and more. Armed with this information, a hacker looking to connect has already removed a great deal of the guesswork associated with accessing the network.

While you may not be able to control the air over which radio signals travel, you can take steps to control the information that is made visible during wireless transmissions. Just about every access point and wireless network card sold today supports an encryption standard known as Wired Equivalent Privacy, more commonly referred to as WEP. At the most basic level, WEP settings must be configured on both access points and on client systems in order to encrypt the traffic that passes between them. This is usually as simple as turning the setting on in the properties of each, and then configuring what is known as a “shared secret” on all systems. The value chosen for a shared secret should be given the same consideration as any network password – it should be complex, and changed fairly regularly. For example, on a corporate wireless network, you should consider changing this value on all systems at least once every month or two.

Unfortunately, WEP is not quite the security standard it was once envisioned to be. Although it is typically made available in both 64- and 128-bit encryption versions, a number of known flaws in the way that WEP encryption keys are stored have led hackers to create a variety of utilities to get past the security that WEP was meant to provide. For example, utilities like AirSnort can often compromise WEP keys in a matter of minutes, and in many cases much less time. For this reason, many experts claim that it may not be worth implementing WEP at all, since it provides only a low barrier to entry for the experienced hacker. However, since WEP is the only real encryption facility provided with most wireless equipment currently on the market, you should still consider implementing it on your network. It’s simply a case of some security being better than none, and to that end, it still provides enough of a barrier to keep inexperienced users at bay.

If you do decide to implement WEP on your network, one additional note of caution from a performance standpoint – the speed of your wireless network will almost certainly take a hit. With WEP configured, performance degradation of anywhere between 15 and 50% is generally considered normal (lower-end access points tend to fare worse) based on the overhead associated with encrypting each packet.

Change Your Wireless Network’s Service Set Identifier (SSID)

In much the same way that a traditional Windows network is identified by a workgroup or domain name, wireless networks are “named” using what is known as a Service Set Identifier, or SSID. The default SSID configured on an access point varies between manufacturers, but is always set to a default value in a manner similar to administrator passwords. In the absence of security features like MAC address security, knowing the SSID to a wireless network is typically all that is necessary to form an association with an access point. The SSID values associated with popular access points are also well documents, so you’ll want to be sure to change the SSID for your network. For example, a default SSID of “linksys” should be changed to a unique value for your network.

Hopefully you’re well aware of the difference between a good and a bad password. Some of the same principles should be applied to SSID names. For example, never set the SSID value to something that explicitly identifies you or your organization, such as a proper name or address – this will only make your network easier to locate or identify. Instead, change the SSID value to something a little more obscure.

Another unfortunate default security setting of most wireless access points is that they have a setting known as “Broadcast SSID” enabled by default. What this means is that an access point will broadcast out its configured SSID value for the entire world to see if left unchanged. When systems with a wireless network card come within range of an access point broadcasting its SSID, that network is then listed as an available network (in the wireless network card properties of XP, for example), making it very easy to connect. As a best practice, disable the broadcasting of SSID information if your access point supports it (most do). Understand, however, that if you do disable SSID broadcast, all wireless clients will need to be explicitly configured with the SSID value for the network or they will be unable to form an association.

Wireless Router MAC Address Security

One of the easiest ways to improve the security of your access points is to implement MAC address security. Available on even entry-level wireless access points and routers, this feature allows you to control exactly which wireless clients can associate with an access point according to their Media Access Control (MAC) address. If this feature is enabled and the MAC address of the client is not present in the configuration, that client with not be able to form the association necessary to access the wireless network.

Although it is possible for MAC addresses to be spoofed, doing so is generally beyond the skill level of most wireless users. Implementing this feature usually involves simply turning it on, and then specifying the MAC addresses of clients that should be allowed to associate with a particular access point. To determine the MAC addresses of client systems, use the ipconfig /all command on Windows ME/2000/XP, or the winipcfg utility on Windows 95/98 systems. Unfortunately, this task can be time consuming on larger networks, where they might be anywhere from tens to hundreds of MAC addresses to enter. It’s also worth noting that on larger networks with more than one access point, the access points will not share the MAC address information that you configure with one another. In other words, on a network with 3 access points, you would need to configure each with all of the MAC addresses of clients that will need to be able to associate. Some higher-end access points allow an administrator to store information about valid MAC addresses on a RADIUS server, and then configure the access point with the IP address of this server. When access points need to authenticate the validity of a wireless client, they can then query the centralized RADIUS server without the need to maintain this information locally.