Microsoft Exchange Server 2007 : Components of a Secure Messaging Environment (part 1) - Hardening Windows Server 2003 - Auditing Policies

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
Although network administrators generally focus on server-level security, which protects data stored on the server itself, the administrators must keep in mind that the server they are attempting to protect is connected to a local area network (LAN), and usually the Internet, to allow it to function to its full potential.

To properly protect a server from attack, administrators should implement multiple layers of defense, each reinforcing the other, and each specializing in repelling certain types of attacks. Firewalls, network perimeters, accessibility options for users, security policies, and more are integral components that must be well designed and properly implemented to be effective.

A phrase coined by the military, “defense in depth,” is used to describe this strategy. Defense in depth increases a server’s security by creating multiple layers of protection between the server and potential attackers. An attacker who successfully maneuvers through the first line of defense finds himself faced with a second challenge, one requiring different skills and tools to bypass, and then a third, and so on.

Hardening Windows Server 2003

Exchange Server 2007 is designed to run on Windows Server 2003. No matter what steps you take to secure your Exchange Server 2007 servers, if the underlying operating system (OS) is not secure, the Exchange installation is vulnerable to attack. Therefore, it is critical that you secure Windows Server 2003 by utilizing a combination of your organization’s security standards and industry best practices.

Layered Approach to Server Security

When discussing security measures, whether server-level or transport-level, protective measures work best when they are applied in layers. For example, if a thief were to attempt to steal your car, it might not be very challenging if all they had to do was break the window and hot-wire the vehicle. However, if you were to add a car alarm, or install an ignition block that requires a coded key, the level of difficulty is increased. Each of these obstacles takes additional time, as well as additional skill sets, to overcome.

This same principle applies to both server- and transport-level security methods. By applying multiple layers of security, you can effectively decrease the likelihood of a malicious user successfully tampering with your systems.

Many security features are already built in to Windows Server 2003. Among these are the following:

  • Kerberos authentication— Windows Server 2003 uses the Kerberos version 5 authentication protocol to provide a mechanism for authentication between a client and a server, or between two servers.

  • NTFS file security— Utilizing the NTFS file system provides improved performance and reliability over traditional file allocation table (FAT) file systems. NTFS has built-in security features, such as file and folder permissions and the Encrypting File System (EFS).

Windows Server 2003 also includes built-in security tools and features to help secure your environment. Among these are object-based access control, automated security policies, auditing, Public Key Infrastructure (PKI), and trusts between domains.

Physical Security Considerations

The first layer of security for any server, and one that is often overlooked, is preventing physical access to the computer. It takes very little skill or knowledge to simply unplug a computer or to remove it from the network; however, this could have a serious impact on your environment even if the intruder was not able to access your data. In addition, just as security professionals have tools and utilities to assist with the defense of computer systems, hackers have tools and utilities to assist them with their attacks. If a hacker can get physical access to a server, he can use a variety of methods to circumvent basic password security.

At a minimum, servers should be physically secured behind locked doors, preferably in an environmentally controlled area.

Some common physical security methods are the following:

  • Configure the server BIOS so that it will not boot from a floppy disk drive or CD-ROM.

  • Password protect the BIOS so that it cannot be reconfigured.

  • Lock the server case to prevent access to the BIOS jumpers on the motherboard.

  • Enclose the server in a locked cage or locked room that has limited access.

Restricting Logon Access

All servers should be configured so that only administrators can log on physically to the console. By default, Exchange Server 2003 does not allow any members of the domain users group local logon privileges. This prevents nonadministrators from logging on to the server even if they can gain physical access to the server.

Auditing Security Events

Auditing is a way to gather and keep track of activity on the network, devices, and entire systems. By default, Windows Server 2003 enables some auditing, but there are many additional auditing functions that must be manually turned on to be used. This control allows your system to easily be customized to monitor those features that you desire.

Although the primary use of auditing methods is to identify security breaches, this feature can also be used to monitor suspicious activity and to gain insight into who is accessing the servers and what they are doing. Windows Server 2003’s auditing policies must first be enabled before activity can be monitored.

Auditing Policies

Audit policies are the basis for auditing events on a Windows Server 2003 system. Bear in mind that auditing can require a significant amount of server resources and can potentially slow server performance, especially if the server does not have adequate memory or CPU bandwidth available. Also, as more and more data is collected by auditing policies, it can require a significant amount of effort to evaluate. Administrators should be cautious, as gathering too much data can sometimes be overwhelming, effectively diminishing the desired benefits. As such, it is important to take the time to properly plan how your systems will be audited.

Audit policies can track successful or unsuccessful event activity in a Windows Server 2003 environment. These policies can audit the success and failure of events. The types of events that can be monitored include the following:

  • Account logon events— Each time a user attempts to log on, the successful or unsuccessful event can be recorded. Failed logon attempts can include logon failures for unknown user accounts, time restriction violations, expired user accounts, insufficient rights for the user to log on locally, expired account passwords, and locked-out accounts.

  • Account management— When an account is changed, an event can be logged and later examined. Although this pertains more to Windows Server 2003 than Exchange Server 2007, it is still very relevant because permissions granted in Active Directory can have an effect on what data or services an individual has access to in Exchange.

  • Directory service access— Whenever a user attempts to access an Active Directory object that has its own system access control list (SACL), the event is logged.

  • Logon events— Logons over the network or by services are logged.

  • Object access— The object access policy logs an event when a user attempts to access a resource such as a printer or shared folder.

  • Policy change— Each time an attempt to change a policy is made, the event is recorded. This can apply to changes made to user rights, account audit policies, and trust policies.

  • Privilege use— Privileged use is a security setting and can include a user employing a user right, changing the system time, and more. Successful or unsuccessful attempts can be logged.

  • Process tracking— An event can be logged for each program or process that a user launches while accessing a system. This information can be very detailed and take a significant amount of resources.

  • System events— The system events policy logs specific system events, such as a computer restart or shutdown.

The audit policies can be enabled or disabled through either the local system policy or Group Policy Objects (GPOs).

To open the Group Policy Object Editor, which is a snap-in to the Microsoft Management Console (MMC), perform the following steps:

Click Start, Run, type MMC in the Open text box, and click OK.

In the MMC Console, click File, Add/Remove Snap-in.

On the Add/Remove Snap-in page, click Add.

Select the Group Policy Object Editor, and then click Add.

Under the Group Policy Object section, click Browse, and select the default domain policy. Click OK to continue, and then click Finish.

Close the Add Standalone Snap-in page by clicking Close, and then click OK to continue. On the Mail Flow Setting tab, select Message Delivery Restrictions and click Properties.

Check the Accept Messages: From Authenticated Users Only check box.

Audit policies are located within the Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy folder of the Group Policy Object Editor, as shown in Figure 1.

Figure 1. Windows Server 2003 audit policies.

  •  Microsoft Exchange Server 2007 : Server and Transport-Level Security - Considering the Importance of Security in an Exchange Server 2007 Environment
  •  Security and Windows 8: Keeping Your PC Safe (part 2) - Windows SmartScreen, Using Windows SmartScreen, Action Center Improvements
  •  Security and Windows 8: Keeping Your PC Safe (part 1) - Windows Defender, Boot-Time Security
  •  Netgear EX6200 AC1200 Wi-fi Range Extender
  •  Windows 8 : Managing BitLocker and other policy-based mobility tools (part 5) - Configuring offline file synchronization, Configuring policy settings for device power
  •  Windows 8 : Managing BitLocker and other policy-based mobility tools (part 4) - Configuring policy settings for offline files
  •  Windows 8 : Managing BitLocker and other policy-based mobility tools (part 3) - Managing BitLocker at the command line
  •  Windows 8 : Managing BitLocker and other policy-based mobility tools (part 2) - Managing BitLocker at the command line
  •  Windows 8 : Managing BitLocker and other policy-based mobility tools (part 1) - Configuring BitLocker policies
  •  Connecting Us TP-LINK TL-PA6010 Test
    Top 10
    Free Mobile And Desktop Apps For Accessing Restricted Websites
    MASERATI QUATTROPORTE; DIESEL : Lure of Italian limos
    TOYOTA CAMRY 2; 2.5 : Camry now more comely
    KIA SORENTO 2.2CRDi : Fuel-sipping slugger
    How To Setup, Password Protect & Encrypt Wireless Internet Connection
    Emulate And Run iPad Apps On Windows, Mac OS X & Linux With iPadian
    Backup & Restore Game Progress From Any Game With SaveGameProgress
    Generate A Facebook Timeline Cover Using A Free App
    New App for Women ‘Remix’ Offers Fashion Advice & Style Tips
    SG50 Ferrari F12berlinetta : Prancing Horse for Lion City's 50th
    - Messages forwarded by Outlook rule go nowhere
    - Create and Deploy Windows 7 Image
    - How do I check to see if my exchange 2003 is an open relay? (not using a open relay tester tool online, but on the console)
    - Creating and using an unencrypted cookie in ASP.NET
    - Directories
    - Poor Performance on Sharepoint 2010 Server
    - SBS 2008 ~ The e-mail alias already exists...
    - Public to Private IP - DNS Changes
    - Send Email from Winform application
    - How to create a .mdb file from ms sql server database.......
    programming4us programming4us