acceptedMicrosoft Exchange Server 2003Guidance for Microsoft Exhange Server 2003 in the Mailbox Server, MTA, and the Client Access (OWA) Server Roles. DISA, Field Security OperationsSTIG.DOD.MILRelease: 5 Benchmark Date: 24 Oct 20141I - Mission Critical Classified<ProfileDescription></ProfileDescription>I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>EMG2-313 Mailboxes only on Mailbox server role <GroupDescription></GroupDescription>EMG2-313 Exch2K3User mailboxes are hosted on non-Mailbox Server role.<VulnDiscussion>Separation of roles supports operational security for application as well as human resources. By isolating a server role such as ‘Mailbox Role’, boundaries that pertain to Mailbox data protection need only be focused in the Mailbox data server. In this way, any Mailbox-specific attack vectors, protocol traffic requirements are more optimally secured. Mailbox data repositories should only be hosted on the Mailbox Server Role. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure non-Mailbox Server role.
Procedure: Exchange System Manager >>Administrative Groups >> [administrative group]>> Servers >> [server name] >> First Storage Group
Remove Mailbox store and mailboxes. Note: Additional administrative tasks to modify dependent configurations may be necessary.
Ensure that mailbox stores are not configured.
Procedure: Exchange System Manager >>Administrative Groups >> [administrative group]>> Servers >> [server name] >> First Storage Group
Individual list of user mailboxes should be an empty list.
Criteria: If user mailbox list is empty, this is not a finding.
EMG2-323 Mailbox Server Requires S/MIME Client <GroupDescription></GroupDescription>EMG2-323 Exch2K3E-mail Server does not require S/MIME capable clients.<VulnDiscussion>Identification and Authentication provide the foundation for access control. The ability for receiving users to authenticate the source of E-Mail messages helps to ensure that they are not FORGED or SPOOFED before they arrive.
MIME (Multipurpose Internet Mail Extensions) is an Internet standard that extends the format of e-mail and other web content to support ASCII and other character sets in both the message and header, text and non-text attachments, and multi-part message bodies. All human-originating E-Mail messages are transmitted in MIME format.
S/MIME (Secure / Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of e-mail encapsulated in MIME. Participants in S/MIME message exchanges must obtain and install an individual key/certificate from the DoD. S/MIME clients will require that each participant own a certificate before allowing them to encrypt messages to others.
To minimize attack vectors revealed by lack of signed or encrypted E-Mail, all clients in the enterprise must be updated to support S/MIME, and all mail servers must require S/MIME capability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure requirement for S/MIME capable clients.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> servers >> [server name] >> [storage group] >> Mailbox store [server name] >> properties >> General tab
Select the “Clients support S/MIME signatures” checkbox. Ensure that E-Mail servers require S/MIME capable clients.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> servers >> [server name] >> [storage group] >> Mailbox store [server name] >> properties >> General tab
The “Clients support S/MIME signatures” should be selected.
Criteria: If the “Clients support S/MIME signatures” is selected, this is not a finding.EMG2-136 Mail Store Storage Quota Limits <GroupDescription></GroupDescription>EMG2-136 Exch2K3E-mail user mailboxes do not have Storage Quota Limitations. <VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. These settings control the maximum sizes of a user’s mailbox and the system’s response if these limits are exceeded. Mailbox data that is not monitored against a quota increases the risk of mail loss due to filled disk space, which can also render the system unavailable. There are three controls, which supply graduated levels of opportunity to respond before risking data loss.
The first control sends an E-mail warning to users stating that they have exceeded their mailbox quota. The second level sends the warning, and causes users to receive, but not send, mail. The third level sends a warning message, and causes users to neither receive nor send mail. Quota limits should be set as multiples of “Maximum Message Size” to ensure no level is skipped.
As a practical matter, levels 1 and 2 serve the purpose of prompting users to manage their E-mail. Level 3 impedes users in their ability to work, and is not required as mail interruption is not acceptable. User Mailbox Quota limitations are not a substitute for overall disk space monitoring. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Make a note of SMTP Virtual Server Message size limitation.
Administrative Groups >> [administrative group] >> Servers >> [server name] >> Protocols >> SMTP ? [Specific SMTP Virtual Server] >> Properties >> Messages Tab >>Limit message size to: (KB)
Use the message size value to configure Mail Store Quota values. Limits should be at least as big as SMTP message size.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server name] >> [storage group] >> Mailbox store [server name] >> Properties >> Limits tab
Select “Issue warning at (KB)” and enter a quota value.
Select “Prohibit send at (KB)" and enter a quota value at least as large as "Issue warning at (KB) plus the value of SMTP Virtual Server message size.
Do not Select "Prohibit send and Receive at (KB)"
Note: Progression of configured actions should be equal to or greater than one message size to prevent an alert being skipped due to one message.
First, make a note of the configured SMTP Virtual Server message size (example, the default is 10,240 KB).
Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server name] >> Protocols >> SMTP >> [Specific SMTP Virtual Server] >> Properties >> Messages Tab >>Limit message size to: (KB)
Use the SMTP Virtual Server Message Size to configure the Mail Store Quota values. Progression of configured values should be 'equal to' or 'greater than' one message size value to prevent an alert being skipped due to one message.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> servers >> [server name] >> [storage group] >> Mailbox store [server name] >> properties >> Limits tab
“Issue warning at (KB)” should be selected and have a value.
“Prohibit send at (KB)” should be selected and have a value.
"Prohibit send and receive at (KB)" should not be selected.
Criteria: If “Issue warning at (KB)” and “Prohibit send at (KB)” are selected, and have assigned values, with "Prohibit send and receive at (KB)" not selected, this is not a finding. EMG2-139 Public Store Storage Quota Limits <GroupDescription></GroupDescription>EMG2-139 Exch2K3E-mail Public Folders do not have Storage Quota Limitations.<VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. These settings control the maximum sizes of a Public Folder and the system’s response if these limits are exceeded. There are two available controls and the system response when the quota has been exceeded.
The first control sends an E-mail warning to Folder Owners roles alerting them that the folder has exceeded its quota. The second level prevents posting any additional items to the folder.
As a practical matter, level 1 serves the purpose of prompting owners to manage their folders. Level 2 impedes users in their ability to work, and is not required where folder use interruption is not acceptable. Public Folder Storage Quota Limitations are not a substitute for overall disk space monitoring. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Make a note of the Public Folder stores item size as follows:
Administrative Groups >> [administrative group] >> Servers >> [server name] >> Storage group >> Public Folder store [Server name] >> Properties >> Limits Tab >>Maximum item size: (KB)
Use Maximum Item size to configure Public Folder Store quota. The value should be 'equal to' or 'greater than' one Public Folder limit on item size.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> servers >> [server name] >> [storage group] >> Public folder store [server name] >> properties >> Limits tab
Select “Issue warning at (KB)” and assign a value.
Do not select “Prohibit post at (KB).
Note: Configured actions should be multiples of one item size to prevent an alert being skipped due to one message.
If site is not using Public Folders, this is N/A.
First, make a note of the Public Folder stores item size.
Administrative Groups >> [administrative group] >> Servers >> [server name] >> Storage group >> Public Folder store [Server name] >> Properties >> Limits Tab >>Maximum item size: (KB)
Use the Maximum item size value to configure the Public Folder Store quota values. Progression of configured values should be 'equal to' or 'greater than' one message size value to prevent an alert being skipped due to one message.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> servers >> [server name] >> [storage group] >> Public Folder store [server name] >> properties >> Limits tab
“Issue warning at (KB)” should be selected, and have a value .
No other limit should be selected.
Criteria: If "Issue warning at (KB)" is selected and has value that is a multiple of a message size, with no other limits selected, this is not a finding. EMG2-507 Public Store Quota Limits Override<GroupDescription></GroupDescription>EMG2-507 Exch2K3Public Folders Store storage quota limits are overridden. <VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. Some settings enable more granular control when it is needed for a specific circumstance, however, if a sound strategy is not planned for configuration placement, it increases the risk that system integrity and availability could be compromised.
This setting gives the Administrator a choice to either “Use Public Store Defaults”, or choose to override with different values. If the “Use Public Store Defaults” is chosen, then the Public Folder store’s settings are applied to this folder and the other alert fields in this group are disabled.
If the “Use Public Store Defaults” is NOT selected then ALL of the storage limit controls in the Public Folder store will be ignored for this folder, and ALL behaviors will then have to be set in this panel and administered separately for this store. If overrides are needed for a Public Folder, they should be documented in the System Security Plan. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-507</Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>If “Use public store defaults” is NOT selected, then ALL of the storage limit controls in the Public Folder store will be ignored for this folder, and ALL behaviors will then have to be set in this panel and administered separately for this store. If overrides are needed for a Public Folder, they should be documented in the System Security Plan.
If these criteria are met, then this is an acceptable solution and "not a finding". </MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSD-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure the Public Folder Store Limit setting.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Folders >> Public Folders >> [Public Folder] >> Properties >> Limits tab >> Storage limits
Select the “Use public store defaults” checkbox.
If Public Folders are not in use at the site, this check is N/A.
For each Public Folder, assess Public Folder overrides for storage limitation alerts.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Folders >> Public Folders >> [Public Folder] >> Properties >> Limits tab >> Storage limits
The “Use public store defaults” checkbox should be selected.
Criteria: If the “Use public store defaults” checkbox is selected, this is not a finding. EMG2-318 Mailbox Stores Mount At Startup<GroupDescription></GroupDescription>EMG2-318 Exch2K3Mailbox Stores "Do Not Mount at Startup" is enabled. <VulnDiscussion>Administrator responsibilities include the ability to react to unplanned maintenance tasks or emergency situations that may require Mailbox data manipulation. Occasionally, there may be a need to start the server with ‘unmounted’ data stores, if manual maintenance is being performed on them. Failure to uncheck the ‘do not mount on startup’ condition will result in unavailability of mail services.
Correct configuration of this control will prevent unplanned outages due to being enabled. On occasions when it is needed, care should be taken in process steps to clear the check box upon task completion, so that mail stores are available to users (unmounted mailbox stores are not available to users). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure Mailbox Mount at Startup.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> servers >> [server name] >> [storage group] >> Mailbox store [server name] >> properties >> Database tab
Clear the “Do not mount this store at startup” checkbox.
Ensure that Mailbox Stores Mount at Startup.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> servers >> [server name] >> [storage group] >> Mailbox store [server name] >> properties >> Database tab
The “Do not mount this store at startup” should be cleared.
Criteria: If the “Do not mount this store at startup” checkbox is cleared, this is not a finding.
EMG2-320 Public Folder Stores Mount At Startup.<GroupDescription></GroupDescription>EMG2-320 Exch2K3Public Folder Stores "Do not Mount at Startup" is enabled. <VulnDiscussion>Administrator responsibilities include the ability to react to unplanned maintenance tasks or emergency situations that may require Public Folder Store data manipulation. Occasionally, there may be a need to start the server with ‘unmounted ’ data stores, if manual maintenance is being performed on them. Failure to uncheck the ‘do not mount on startup’ condition will result in unavailability of Public Folder services.
Correct configuration of this control will prevent unplanned outages due to being enabled. On occasions when it is needed, care should be taken in process steps to clear the checkbox task completion, so that public folder stores are available to users (unmounted public folder stores are not available to users). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Enable Public Folder Stores "Mount at Startup" feature.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> servers >> [server name] >> [storage group] >> Public Folder store [server name] >> properties >> Database tab
Clear the “Do not mount this store at startup” checkbox.If Public Folder stores are not in use at the site, this is N/A.
Ensure that Public Folder Stores "Do not Mount at Startup" is disabled.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> servers >> [server name] >> [storage group] >> Public Folder store [server name] >> properties >> Database tab
The “Do not mount this store at startup” should be cleared.
Criteria: If the “Do not mount this store at startup” checkbox is cleared, this is not a finding.
EMG2-511 Public Folder “Send on Behalf” of User <GroupDescription></GroupDescription>EMG2-511 Exch2K3Public Folder “Send on Behalf of” feature is in use. <VulnDiscussion>The principle of non-repudiation gives a message recipient the assurance that the message can be attributed to the named sender. If users are allowed to send on behalf of other parties, it introduces risk that receivers may never realize the identity of the actual sender of the message. This can enable nefarious senders to mask their activities.
The “Send on Behalf” field should be cleared (messages are not sent on behalf of any party). While the full “from” field displays both the actual sender as well as who the message is on behalf of, in many instances only the party on whose behalf the message was sent may be seen.
If “Send on behalf” is used, accounts with the ability should be documented and monitored to ensure this privilege is not being abused.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-511</Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>If “Send on behalf of” is used, accounts with the ability should be documented and monitored to ensure this privilege is not being abused. If documentation exists in the System Security Plan, then the finding can be closed. </MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Disable the Public Folder “send on behalf of” feature.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Folders >> Public Folders [Public Folder] >> Properties >> Exchange General Tab >> Delivery Options Button.
Empty the “Send on Behalf of” list.If Public Folders are not in use, this is N/A.
Review the 'Send on behalf of' field.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Folders >> Public Folders >> [Public Folder] >> Properties >> Exchange General tab >> Delivery Options button.
The “Send on Behalf of” list should be empty.
Criteria: If the “Send on Behalf” list is empty, this is not a finding.
EMG2-046 Automated Response Messages <GroupDescription></GroupDescription>EMG2-046 Exch2K3Automated Response Messages are Enabled.<VulnDiscussion>SPAM originators, in an effort to refine mailing lists, sometimes use a technique where they monitor transmissions for automated bounce back messages such as “Out of Office” messages. Automated messages include such items as Out of Office responses, non-delivery messages, or automated message forwarding.
Automated bounce back messages can be used by a third party to determine user “liveness” on the server. This can result in the disclosure of active user accounts to third parties, paving the way for possible future attacks.
Mail forwarding is an automated feature that does not provide information to third parties, but it poses a potential risk on networks where classified or confidential information may be sent. For example, if auto-forwarding is configured, sensitive information sent to this user’s account may automatically be transferred outside the control of the organization.
The “Default” format applies to all domains. However, if a new format is created and applied to a specific domain, that domain will use the new format's configuration while all other domains (those without specially designated formats) will use the Default format. Automated messages must be disabled to prevent inadvertent information disclosure about E-mail recipients. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Disable automated responses.
Procedure: Exchange System Manager >> Global Settings >> Internet Messages >>Formats
>> {specific format name} >> Properties >> Advanced tab >> {item list}
For each profile in the list, clear the "Automated Response Messages" checkbox.
Procedure: Exchange System Manager >> Global Settings >> Internet Messages >>Formats >> {specific format name} >> Properties >> Advanced tab >> {item list}
The "Automated Response Messages" checkbox should be cleared.
Criteria: For each listed format, if the "Automated Response Messages" checkbox is cleared, this is not a finding.EMG2-013 Global Accept and Deny Lists - Perimeter<GroupDescription></GroupDescription>EMG2-013 Exch2K3Mailbox server is not protected by E-mail Edge Transport role (E-mail Secure Gateway) performing Global Accept/Deny list filtering. <VulnDiscussion>SPAM origination sites and other sources of suspected E-Mail borne malware have the ability to corrupt, compromise, or otherwise limit availability of E-Mail servers. Limiting exposure to unfiltered inbound messages can reduce the risk of SPAM and malware impacts.
The Global Accept and Deny List settings (sometimes referred to 'Black Lists' and 'White Lists' ) respectively block or admit messages originating from specific sources. Ideally, 'Black List' filtering is done at the perimeter of the network (using a commercial 'Block List' service), because eliminating threats there prevents them being evaluated inside the enclave where there is more risk they can do harm. When no commercial 'Block List Service' is employed as the 'Black List', the values configured here perform similar filtering and can be used to supplement the sites identified in the 'Block List Service'. For example, during a 0-Day threat action, entries can be added, then removed when the threat is mitigated. A common practice is to enter the enterprise’s home domain in the 'Global Deny List', at a minimum, as inbound E-mail where a ‘from’ address of the home domain is very likely to be SPOOFED SPAM.
The Accept List field (referring to the ‘White List’) overrides both the ‘Deny List’ and the ‘Block List’ Service. Even if the ‘Block List’ claims that listed domains are spammers, inbound mail will still be received mail from them. Normally, no entry should appear in the Global Accept List.
Note: Use of ‘White List’ entries can inadvertently lead to Denial of Service situations due to inbound messages bypassing the filtering mechanism. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-013</Mitigations><SeverityOverrideGuidance>Severity can be overridden to Category III if terms of the mitigation are met by configuring this SPAM protection on an Exchange Server processing inbound messages. </SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>Configure Global Accept and Deny List configurations on the first Exchange server receiving messages directly from the public Internet.
Note: This mitigation is preferred to having no SPAM protection employed; however, it does not qualify as closing the open finding for perimeter protection.
Procedure: Exchange System Manager >> Global Settings >> Message Delivery>> Properties >> Connection Filtering tab >> Global Accept and Deny List configuration >> {List of entries}
Enter the Home domain in the Global Deny List. Justify or remove other entries. The Global Accept list should remain empty. </MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Procedure: Implement perimeter protection in the form of a secure E-mail filtering mechanism that performs, among other protections, manually configured 'Deny' List entries (that include the local domain, minimally) to supplement the commercial 'Block List' service. Ensure also, that no 'Accept' List entries exist in the configuration. Interview the E-mail Administrator or the IAO. Request documentation that indicates any manually entered Global Accept and Deny list configurations are in place on an E-mail Secure Gateway at the network perimeter.
Ensure that the local domain appears in the 'Deny' list for the domain to prevent spoofed SPAM.
Criteria: If Perimeter Gateway configurations indicate that the local domain exists in the 'Deny' List and that no entries exist in the 'Accept' List, this is not a finding. EMG2-029 SPAM Evaluation Filter - Perimeter<GroupDescription></GroupDescription>EMG2-029 Exch2K3Mailbox Server is not protected by an Edge Transport Server (E-mail Secure Gateway) performing SPAM evaluation.<VulnDiscussion>By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment. SPAM origination sites and other sources of suspected E-Mail borne malware have the ability to corrupt, compromise, or otherwise limit availability of E-Mail servers. Limiting exposure to unfiltered inbound messages can reduce the risk of SPAM and malware impacts. By performing filtering at the perimeter, SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment. This significantly reduces the attack vector for inbound E-mail-borne SPAM and malware.
SPAM evaluation (heuristic) filters scan inbound email messages for evidence of SPAM and other attacks that primarily use ‘Social Engineering’ techniques. Upon evaluation, a rating is assigned to each message estimating the likelihood of its being SPAM. When the message is received in the user’s mailbox, the junk mail filter threshold determines whether the message will be withheld from delivery, delivered to the junk mail folder, or delivered to the user’s inbox.
For Exchange 2003 servers, Microsoft introduced the Intelligent Message Filter (IMF). Beginning with Exchange 2003 SP2 it was included as part of the application. Since that time, however, it is recommended that such filtering occur at the network perimeter. That said, risk of inbound SPAM can be somewhat mitigated by using the Microsoft IMF on the Exchange 2003 Mail server, even as an interim measure, while planning for a more comprehensive, Edte Transport Server (E-Mail Secure Gateway). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-029</Mitigations><SeverityOverrideGuidance>Severity can be overridden to Category III if terms of the mitigation are met by configuring this SPAM protection on an Exchange Server processing inbound messages. </SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>Exchange Intelligent Message Filter (IMF) is engaged on the first Exchange 2003 Bridgehead server or Mailbox Server that receives inbound messages from anonymous Internet connection.
Note: This mitigation is preferred to having no SPAM protection employed; however, it does not qualify as closing the open finding for perimeter protection.
Configure IMF on the Exchange 2003 server.
Procedure: Exchange System Manager >> Global Settings >> Message Delivery>> Properties >> Intelligent Message Filtering tab
Set the Gateway Blocking Configuration. A usual first choice is 8.
The “When blocking Messages” choices are "Archive", "Delete", "No action", or "Reject".
Note: An action of "Archive" will require sufficient disk space to host the archived messages. However, actions of "Delete" or "Reject" may contribute to inadvertent data loss. Action of "No Action" will cause the message to be forwarded to the user, carrying the evaluation score, where it may eventually be placed in the user's Junk Mail folder.
Set the “Store Junk E-mail Configuration". A usual first choice is 4.
Check the IMF filter “Yes” checkbox.
Exchange System Manager >> Administrative Groups >> [administrator group] >> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties>>General Tab>> Advanced >> Edit
Check "Intelligent Message Filter (IMF)" to activate the filter.
</MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Implement perimeter protection in the form of a secure email filtering mechanism that performs, among other protections, SPAM elimination prior to forwarding message traffic to mailbox servers. Interview the E-mail Administrator or the IAO. Request documentation that indicates SPAM evaluation filters are in place on an Edge Transport Server (E-mail Secure Gateway Server) role outside the network perimeter.
Criteria: If the mailbox servers are protected by a perimeter-based Edge Transport Server role (E-mail Secure Gateway) which performs SPAM filtering prior to forwarding E-mail to the mailbox servers, this is not a finding.
EMG2-015 Block List Service Provider - Perimeter<GroupDescription></GroupDescription>EMG2-015 Exch2K3The Mailbox server is not protected by an Edge Transport Server Role (E-mail Secure Gateway) performing 'Block List' filtering.<VulnDiscussion>SPAM origination sites and other sources of suspected E-Mail borne malware have the ability to corrupt, compromise, or otherwise limit availability of E-Mail servers. Limiting exposure to unfiltered inbound messages can reduce the risk of SPAM and malware impacts.
Ideally, 'Block List' filtering is done at the perimeter of the network (using a commercial 'Block List' service), because eliminating threats there prevents them being evaluated inside the enclave where there is more risk they can do harm.
Block List Services are fee based data providers that collect the IP addresses of known SPAMmers and other malware purveyors. Subscribers to these services benefit from more effective SPAM elimination (up to 90% of inbound mail volume) as well as leveraging the E-Mail Administration effort needed to maintain and update larger block lists than a single E-Mail site administrator could conveniently maintain. Neglecting to specify a 'Block List' would require E-Mail Administrators to manually specify addresses in the ‘Deny List’ field as they are discovered.
The 'Block List' Services provider will provide a value for this field – usually the DNS suffix for their domain.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-015</Mitigations><SeverityOverrideGuidance>Severity can be overridden to Category III if terms of the mitigation are met by configuring this SPAM protection on an Exchange Server processing inbound messages.</SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>The Block List Services provider is configured on the Exchange 2003 Bridgehead server (MTA role) or the Exchange 2003 Mailbox server that is the first Exchange server receiving inbound SMTP messages from the public Internet.
Procedure: Exchange System Manager >> Global Settings >> Message Delivery>> Properties >> Connection Filtering tab >> Block List Service Configuration >> {List of entries}
Click the ADD button, enter Block List Service as specified by vendor.
Note: This mitigation is preferred to having no Block List filtering protection employed; however, it does not qualify as closing the open finding for perimeter protection. </MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Subscribe to, and configure, Block List Services.
Implement perimeter-based protection in the form of a secure E-mail filtering mechanism that performs, among other protections, Block List Services filtering for SPAM elimination prior to forwarding message traffic to mailbox servers. Interview the E-mail Administrator or the IAO. Request documentation that indicates Block List Services filters are in place on an E-mail Secure Gateway outside the enclave at the perimeter.
Criteria: If the Exchange 2003 mailbox servers are protected by a perimeter-based Edge Transport Server role (E-mail Secure Gateway), which performs 'Block List' filtering prior to forwarding E-mail to the mailbox servers, this is not a finding.
EMG2-017 Block List Exceptions - Perimeter<GroupDescription></GroupDescription>EMG2-017 Exch2K3Mailbox server is not protected by an Edge Transport Server role (E-mail Secure Gateway) performing Block List exception filtering at the perimeter.<VulnDiscussion>SPAM origination sites and other sources of suspected E-Mail borne malware have the ability to corrupt, compromise, or otherwise limit availability of E-Mail servers. Limiting exposure to inbound messages is one type of filtering that can reduce the risk of SPAM and malware impacts.
Ideally, 'Block List' filtering is done at the perimeter of the network (using a commercial 'Block List' service), because eliminating threats there prevents them being evaluated inside the enclave where there is more risk they can do harm.
Block List Exceptions are used to specify sources that should not be blocked despite their presence in a block list. Exceptions, if used, should be carefully vetted to ensure they are sources of legitimate email.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-017</Mitigations><SeverityOverrideGuidance>Severity can be overridden to Category III if terms of the mitigation are met by configuring this SPAM protection on an Exchange Server processing inbound messages. </SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>Block List Services Exceptions are configured on the Exchange 2003 Bridgehead (MTA role) server or Mailbox server where Block List subscription content is configured.
Note: This mitigation is preferred to having no Block List filtering protection employed; however, it does not qualify as closing the open finding for perimeter protection.
Procedure: Configure (with documentation) or clear Block List exceptions on the Exchange server as follows:
Exchange System Manager >> Global Settings >> Message Delivery>> Properties >> Connection Filtering Tab >> Block List Service Configuration >> Exception Button >> {List of IP addresses}.
</MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Implement perimeter-based protection in the form of a secure E-mail filtering mechanism that performs, among other protections, Block List exceptions filtering for SPAM elimination prior to forwarding message traffic to mailbox servers.
Interview the E-mail Administrator or the IAO. Request documentation that indicates Block List Services filters are in place, with no exceptions (or exceptions documented as to reasons), on an E-mail Secure Gateway outside the enclave at the network perimeter.
Criteria: If Block List Exceptions are configured and approved on an Edge Transport Server role (perimeter-based E-mail Secure Gateway), this is not a finding. EMG2-043 Sender Authentication - Perimeter<GroupDescription></GroupDescription>EMG2-043 Exch2K3Mailbox Server is not protected by an Edge Transport Server (E-mail Secure Gateway) performing Sender Authentication at the perimeter. <VulnDiscussion>Email is only as secure as the recipient. When the recipient is an E-Mail server accepting inbound messages, authenticating the sender enables the receiver to better assess message quality and to validate the sending domain as authentic. One or more authentication techniques used in combination can be effective in reducing SPAM, PHISHING, and FORGERY attacks.
There are two primary methods of sender authentication; Sender ID Framework (SIDF), and Domain Keys Identified Mail (DKIM).
The Sender ID Framework (SIDF) receiver accesses specially formatted DNS records (SPF format) that contain the IP address of authorized sending servers for the sending domain that can be compared to data in the email message header. Receivers are able to validate the authenticity of the sending domain, eliminate PHISHING SPAM, and can be used in combination with DKIM. SIDF is a Microsoft creation, and is available on Exchange 2003 Servers.
The DKIM receiver accesses specially formatted DNS records that contain the Public Key for the sending domain’s authorized outbound mail servers. The key is used to decrypt the hash in the message header and determine whether the message has been modified. DKIM is not effective against replay attacks, but can detect forgeries. Some false positives are possible if interim E-Mail forwarders append text to the message body. DKIM is a Cisco creation, and is available on most Edge Transport Server (E-mail Secure Gateway) products.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-043</Mitigations><SeverityOverrideGuidance>Note: This mitigation is preferred over not having any SIDF protection at all. however, it does not qualify as closing the open finding for perimeter protection. If SIDF methods are in place, finding to be downgraded to a CAT III.</SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>SIDF is configured on the Exchange 2003 Bridgehead server or Mailbox Server that receives inbound messages from Internet sources. Note: This mitigation is preferred over not having any SIDF protection at all. however, it does not qualify as closing the open finding for perimeter protection. If SIDF methods are in place, finding to be downgraded to a CAT III.
Configure SIDF on the Exchange server that receives inbound E-mail from the public Internet.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Severs >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >> General Tab >> Advanced Button >> Edit
Select “Sender ID Filter”
Note: Microsoft Exchange includes only the SIDF method of sender authentication. Senders that are successfully authenticated using this method are scored higher for non-spam likelyhood. Senders that do not successfully authenticate are scored lower, or are immediately declared SPAM and processed according to configured SPAM removal process for the site.
</MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Implement perimeter-based protection in the form of an Edge Transport Server role (E-mail Secure Gateway) filtering mechanism that performs, among other protections, Sender Authentication upon receipt.
Interview the E-mail Administrator or the IAO. Request documentation that indicates sender authentication techniques are in place on a secure email gateway server outside the enclave at the perimeter. Sender authentication for anonymous connections may take the form of Sender ID Framework (SIDF) or Domain Keys Internet Mail (DKIM), both DNS-based methods of sender authentication. Note: Sender authentication is not always reliable, because not all senders of electronic mail participate in creating public DNS sender profiles for their E-mail infrastructure.
Criteria: If sender authentication is configured and approved on a perimeter-based E-mail Secure Gateway, this is not a finding. EMG2-005 Global Sending / Receiving Message Size<GroupDescription></GroupDescription>EMG2-005 Exch2K3E-mail Server Global Sending or Receiving message size is set to Unlimited.<VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. Message size limits should be set to 30 megabytes at most, but often are smaller, depending on the organization. The key point in message size is that it should be set globally, and it should not be set to ‘unlimited’.
Selecting the “no limit” radio button on either field is likely to result in abuse and can lead to rapid filling of server disk space.
Message size limits may be applied in Routing Group connectors, SMTP connectors, Public Folders, and on the user account under AD. Changes at these lower levels are discouraged, as the single global setting is usually sufficient. This practice prevents conflicts that could impact availability and it simplifies server administration. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set the Global Send and Receive message sizes.
Procedure: Exchange System Manager >> Global Settings >> Message Delivery>> Properties >> Defaults tab
Set "Send Size" and "Receive Size" to a value (do not select Unlimited).
Default size limits are as follows (to be used if other sizes are not justified):
Send Size =10,240
Receive Size = 10,240Verify that the “Set message size”, is not set to Unlimited.
Procedure: Exchange System Manager >> Global Settings >> Message Delivery>> Properties >> Defaults tab
The "Send Size" and "Receive Size" should have a value, and not have "unlimited" selected.
Criteria: If "Send Size" and "Receive Size" have a value, and have not selected "unlimited", this is not a finding. EMG2-010 SMTP Virtual Server Message Size Limit<GroupDescription></GroupDescription>EMG2-010 Exch2K3Sending or Receiving message size is not set to Unlimited on the SMTP virtual server. <VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. E-mail system availability has become a necessary feature in information sharing, and controlling message size limit reduces risk that servers become unavailable due to message size conflicts. By setting “unlimited” at the virtual server level, it enables the global setting to prevail without being overridden at this level. The message size limit applies to E-mail and other features that use Simple Message Transfer Protocol (SMTP), such as Public Folders.
The default setting of ‘no limit’ at the virtual server level is recommended and should provide sufficient protection against excessively large messages passing through the virtual server.
Message size limits may be applied in Virtual Servers, Routing Group connectors, SMTP connectors, Public Folders, and on the user account under Active Directory. Changes at these lower levels are discouraged, as the single global setting is usually sufficient. This practice prevents conflicts that could impact availability and it simplifies server administration. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set the sending and receiving message size for the SMTP virtual server to unlimited.
Procedure: Exchange System Manager >> Administrative Groups >> [administrator group] >> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >>Messages tab
Clear the checkbox for “Limit Message size to (KB)”
Review Message Size setting for each SMTP virtual server.
Procedure: Exchange System Manager >> Administrative Groups >> [administrator group] >> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >>Messages tab
Note: If “administrative groups” do not display in the list, highlight the topmost “Exchange” item in the left hand list, then access the Action menu, select Properties, check the “Display Routing Groups” box, and the “display administrative groups” box. Exit Exchange Manager, then restart it, and repeat the “check” steps.
The checkbox for “Limit Message size to (KB)” should be cleared.
Criteria: If the “Limit Message Size to (KB)" is cleared, this is not a finding.
EMG2-129 SMTP Virtual Server Session Size Limit<GroupDescription></GroupDescription>EMG2-129 Exch2K3The SMTP Virtual Server Session Size is not set to "Unlimited". <VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. This setting controls the maximum SMTP Virtual Server session sizes (inbound and outbound) and applies globally to the Simple Mail Transfer Protocol (SMTP) protocol. If the session size limit is set too low, the SMTP server may increase the number of sessions spawned, which increases the risk that other set limits will be reached. Controlling session resource usage is best done by controlling the number of messages in a session.
It is is recommended that this setting remain at the default of ‘Unlimited’. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set the SMTP Session Size Limit.
Procedure: Exchange System Manager >> Administrative Groups >> [administrator group] >> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >>Messages Tab
Clear the “Limit Session size to (KB)” field.
Perform for each SMTP virtual server:
Note: If “administrative groups” do not display in the list, highlight the topmost “Exchange” item in the left hand list, then access the Action menu, select Properties, check the “Display Routing Groups” box, and the “display administrative groups” box. Exit Exchange Manager, then restart it, and repeat the “check” steps.
Procedure: Exchange System Manager >> Administrative Groups >> [administrator group] >> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >>Messages Tab
The "Limit Session Size to (KB)" field should be cleared.
Criteria: If the “Limit Session Size to (KB)" is cleared, this is not a finding.
EMG2-149 SMTP Virtual Server Message Count Limit<GroupDescription></GroupDescription>EMG2-149 Exch2K3The SMTP Virtual Server Message Count Limit is not 20. <VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. This setting controls the maximum number of messages allowed in a single SMTP session by breaking large numbers of messages into multiple sessions. This configuration is the preferred place to control session size.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-149 Exch2K3</Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>The default value of 20 will be appropriate for most environments. If the message limit is set too high or disabled, it will increase the chance that a batch of messages will fit in a single session, and not use parallel sessions. If the limit is set too low, additional session startup costs may outweigh the advantages in processing sets of messages in parallel. By balancing use of resources, system availability is optimized.
In some environments there may exist valid reason to modify this setting. If a change to the setting is justified and documented in the security plan, this is an acceptable solution and 'not a finding'.</MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure the SMTP Session messages count limit.
Procedure: Exchange System Manager >> Administrative Groups >> [administrator group] >> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >>Messages tab
Set “Limit number of messages per connection” at 20 or the value determined necessary for the site.
Perform for each SMTP virtual server.
Procedure: Exchange System Manager >> Administrative Groups >> [administrator group] >> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >>Messages tab
The “Limit number of messages per connection” should be set to 20.
Criteria: If “Limit number of messages per connection” is set to 20 (or other value with justifying documentation), this is not a finding.
EMG2-107 SMTP Virtual Server Msg. Recipient Count<GroupDescription></GroupDescription>EMG2-107 Exch2K3Message Recipient Count Limit is not limited on the SMTP virtual server. <VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. Global Message Recipient Limits determine the total number of recipients that can be addressed on a single message. At the virtual server level, this field is set to a limited size, and is used to control the maximum number of recipients who will receive a copy of this message at one time. It is intended to improve efficiency by forcing messages sent to a greater number of recipients to be sent out in multiple messages.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-107 Exch2K3</Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>The default value of 64000 will be appropriate for most environments. In some environments there may exist valid reason to modify this setting. If settings are changed to a lower value, is justified, authorized by the IAO, and documented in the System Security Plan, this is an acceptable solution and 'not a finding'.
</MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set the SMTP Virtual Server Message Recipient Count limit..
Procedure: Exchange System Manager >> Administrative Groups >> [administrator group] >> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >>Messages Tab
Select “Limit number of recipients per message" to 64000.Verify the SMTP Virtual Server Recipient Count Limit.
Procedure: Exchange System Manager >> Administrative Groups >> [administrator group] >> Servers >> [server] >> Protocols >> SMPT >> [specific SMPT server] >> Properties >>Messages Tab
The “Limit number of recipients per message” should be is set to a numeric value of 64000 (default) or less.
Criteria: If “Limit number of recipients per message” is set to a numeric value of 64000 (default) or less, and the System Security Plan documentation has a documented reason, this is not a finding.
EMG2-006 Global Recipient Count Limit<GroupDescription></GroupDescription>EMG2-006 Exch2K3The Global Recipient Count limit is set to “Unlimited”.<VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. The Global Recipient Count limit field is used to control the maximum number of recipients that can be specified in a single message sent from this server. Its primary purpose is to minimize the chance of an internal sender spamming other recipients, since SPAM messages often have a large number of recipients. SPAM prevention can originate from both outside and inside organizations. While inbound SPAM is evaluated as it arrives, controls such as this one help prevent SPAM that might originate inside the organization.
The Recipient Count Limit is global to the Exchange implementation. Lower-level refinements are possible; however, in this configuration strategy, setting the value once at the global level ensures a more available system by eliminating potential conflicts among multiple settings. A value of less than or equal to 5000 is probably larger than is needed for most organizations, but is small enough to minimize usefulness to spammers, and is easily handled by Exchange. Selecting the “no limit” radio button for this item is likely to result in abuse.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set the Recipient Count limit.
Procedure: Exchange System Manager >> Global Settings >> Message Delivery>> Properties >> Defaults tab
Set "Recipients" to a value (do not select Unlimited). The default value is 5000, but can be set lower if local site conditions warrant it and the reason is documented in the System Security Plan.
Ensure that Global Recipient Count is not set to "Unlimited".
Proceure: Exchange System Manager >> Global Settings >> Message Delivery>> Properties >> Defaults tab >> Recipient Limits
The "Recipient Count" should be set to a value, not "Unlimited".
Criteria: If "Recipient Count" is set to a value, not "Unlimited", this is not a finding.
EMG2-031 Non-existent Recipients - Perimeter<GroupDescription></GroupDescription>EMG2-031 Exch2K3The Exchange E-mail Services environment is not protected by an Edge Transport Server (E-Mail Secure Gateway) performing Non-existent recipient filtering at the perimeter. <VulnDiscussion>SPAM originators, in an effort to refine mailing lists, sometimes use a technique where they first create fictitious names, then monitor rejected E-mails for non-existent recipients.
Those not rejected, of course, are deemed to exist, and are therefore used in future SPAM mailings.
To prevent this disclosure of existing E-Mail accounts to SPAMmers, this feature should not be employed. Instead, it is recommended that all messages be received, then evaluated and disposed of without enabling the sender to determine recipients that are existing vs. non-existing. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-031</Mitigations><SeverityOverrideGuidance>Severity can be overridden to Category III if terms of the mitigation are met by configuring this SPAM protection on an Exchange Server processing inbound messages. </SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>Non-existent recipient filtering is configured on the MTA Server role (Exchange 2003 Bridgehead server) or Exchange 2003 Mailbox server where Recipient Filtering is configured.
Note: This mitigation is preferred to having no recipient filtering protection employed: however, it does not qualify as closing the open finding for perimeter protection.
Procedure: Exchange System Manager >> Global Settings >> Message Delivery>> Properties >> Recipient Filtering
Clear the “filter recipients who are not in the directory” check box.
</MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Implement perimeter-based protection in the form of an Edge Transport Server role (E-mail Secure Gateway) filtering mechanism that performs, among other protections, Non-Existent Recipient filtering that does not alert senders to non-existent recipients. Interview the E-mail Administrator or the IAO. Request documentation that indicates Nonexistent Recipient filters are in place and set to allow messages, on an Edge Transport Server role (E-mail Secure Gateway)at the network perimeter.
Criteria: If non-existent recipients' messages are received for evaluation, this is not a finding
EMG2-024 Archive Filtered Messages - Perimeter<GroupDescription></GroupDescription>EMG2-024 Exch2K3The Mailbox server is not protected by having filtered messages archived by the Edge Transport Role server (E-mail Secure Gateway) at the perimeter.<VulnDiscussion>By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment. This significantly reduces the attack vector for inbound E-mail-borne SPAM and malware.
As messages are filtered, it is prudent to temporarily host them in an archive for evaluation by administrators or users. The archive can be used to recover messages that might have been inappropriately filtered, preventing data loss, and to provide a base of analysis that can provide future filter refinements. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-024</Mitigations><SeverityOverrideGuidance>Severity can be overridden to Category III if terms of the mitigation are met by configuring this SPAM protection on an Exchange Server processing inbound messages. </SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>Filtered message archiving is configured on the Exchange 2003 Bridgehead server or Mailbox server where Sender Filtering is configured.
Note: This mitigation is preferred to having no sender filtering protection employed; however, it does not qualify as closing the open finding for perimeter protection.
Procedure: Exchange System Manager >> Global Settings >> Message Delivery>> Properties >> Sender Filtering
Procedure: Select the Archive Filtered Messages checkbox.
Note: If a reminder dialog appears advising that the sender filter must be enabled, click ‘ok’. There is a separate checklist item that requires filter enabling. A finding will be produced if the filter is not enabled, and can be addressed at the resolution of that finding.
</MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Implement perimeter-based protection in the form of a secure email filtering mechanism that performs, among other protections, filtered messages archiving for SPAM elimination prior to forwarding message traffic to mailbox servers inside the enclave.Interview the E-mail Administrator or the IAO. Request documentation that indicates Filtered messages are archived on a secure email gateway server outside the enclave at the perimeter.
Criteria: If inbound messages filtered by the sender filter are archived, this is not a finding.
EMG2-026 Filter Blank Sender Messages - Perimeter<GroupDescription></GroupDescription>EMG2-026 Exch2K3The Mailbox server is not protected by having blank sender messages filtered by the Edge Transport Role server (E-mail Secure Gateway) at the perimeter. <VulnDiscussion>By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment. Anonymous E-mail (messages with blank sender fields) cannot be replied to. Messages formatted in this way may be attempting to hide their true origin to avoid responses, or to SPAM any receiver with impunity while hiding their source of origination.
Rather than spend resource and risk infection while evaluating them, it is recommended that these messages be filtered immediately upon receipt and not forwarded to end users.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-026</Mitigations><SeverityOverrideGuidance>Severity can be overridden to Category III if terms of the mitigation are met by configuring this SPAM protection on an Exchange Server processing inbound messages.</SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>Messages with blank sender filter are configured on the MTA Server Role (Exchange 2003 Bridgehead Server) or Exchange 2003 Mailbox server where Sender Filtering is configured.
Note: This mitigation is preferred to having no sender filtering protection employed; however, it does not qualify as closing the open finding for perimeter protection.
Procedure: Exchange System Manager >> Global Settings >> Message Delivery>> Properties >> Sender Filtering
Select the “Filter Messages with Blank Sender” checkbox.
</MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Implement perimeter-based protection in the form of an Edge Transport Role server (E-mail Secure Gateway) filtering mechanism that performs, among other protections, filtering messages with blank sender and archiving them for SPAM elimination.Interview the E-mail Administrator or the IAO. Request documentation that indicates Messages with blank senders are filtered at the perimeter by an Edge Tranport Server role (E-mail Secure Gateway).
Criteria: If inbound messages with blank sender are filtered and archived, this is not a finding. EMG2-021 Drop Sender Connections - Perimeter<GroupDescription></GroupDescription>EMG2-021 Exch2K3The E-Mail server is not protected by having connections from “Sender Filter” sources dropped by the Edge Transport Server role (E-Mail Secure Gateway) at the perimeter. <VulnDiscussion>SPAM origination sites and other sources of suspected E-Mail borne malware have the ability to corrupt, compromise, or otherwise limit availability of E-Mail servers. Limiting exposure to unfiltered inbound messages can reduce the risk of SPAM and malware impacts.
It is recommended that “drop connections” action be taken when inbound requests are from addresses that match sender filters (such as those on Block List) and be performed in the perimeter network by an E-Mail Secure Gateway server, because eliminating threats there prevents them being evaluated inside the enclave where there is more risk they can do harm. If the other party has other messages to send, it must re-initiate the Simple Message Transfer Protocol (SMTP) connection to start sending the next message (as opposed to simply continuing the current connection). This will slow down the rate at which this blocked sender is able to send messages to the server, further mitigating the potential for a Denial of Service attack. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-021</Mitigations><SeverityOverrideGuidance>Severity can be overridden to Category III if terms of the mitigation are met by configuring this SPAM protection on an Exchange Server processing inbound messages. </SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>“Drop connections from ‘sender filter’ sources” is configured on the MTA Server Role (Exchange 2003 Bridgehead) server or Exchange 2003 Mailbox server where Sender Filtering is configured. Note: This mitigation is preferred to having no sender filtering protection employed; however, it does not qualify as closing the open finding for perimeter protection.
Procedure: Exchange System Manager >> Global Settings >> Message Delivery>> Properties >> Sender Filtering
Select the “Drop Connection if Sender Matches Filter” checkbox.
</MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Implement perimeter-based protection in the form of a Secure E-mail Gateway that performs, among other protections, dropping connections when the address matches “sender filter” sources, for SPAM elimination prior to forwarding message traffic to mailbox servers.Interview the E-mail Administrator or the IAO. Request documentation that indicates connections from sources matching sender filters are dropped on an Edge Transport Role (E-mail Secure Gateway) server outside the enclave at the perimeter.
Criteria: If incoming connections from “sender filter” sources are dropped, this is not a finding.EMG3-801 Unneeded Services Disabled<GroupDescription></GroupDescription>EMG3-801 Exch2K3FEE-Mail server has unneeded processes or services active.<VulnDiscussion>Unneeded, but running, services offer attackers an enhanced attack profile, and attackers are constantly watching to discover open ports with running services. By analyzing and disabling unneeded services, the associated open ports become unresponsive to outside queries, and servers become more secure as a result.
Exchange 2003 has role-based server deployment to enable protocol path control and logical separation of network traffic types.
For example, a server implemented in the Client Access role (i.e., Outlook Web Access [OWA]) is configured and tuned as a web server using web protocols. A client access server exposes only web protocols (HTTP/HTTPS) enabling System Administrators to optimize the protocol path and disable all services unnecessary for Exchange web services. Similarly, Back-End servers created to host mailboxes are dedicated to that task, and operate only the services needed for mailbox hosting. (Back-end servers must also operate some Web services, but only to the degree that Exchange 2003 requires the IIS engine in order to function).
To restrict attack vectors available with E-mail message access, the protocols on the E-mail servers should match offerings on the DoD standard desktop deployment. These include Microsoft Outlook using MAPI, S/MIME enabled clients, and secured connections. It also includes Outlook via VPN for offsite telework. Browsers may access OWA provided it uses PKI/CAC access brokered through a reverse proxy Application Server.
Because NNTP, POP3, and IMAP4 clients are not included in the standard desktop offering, they must be disabled. Guidance is not provided for these protocols in this document. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Disable unneeded services.
Procedure: Navigate to Start >> Settings >> Administrative Tools >> Services
Create correct configurations.
Microsoft Exchange IMAP4 – Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Microsoft Exchange Information Store
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Microsoft Exchange POP3
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Microsoft Search
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Microsoft Exchange Event
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Microsoft Exchange Site Replication Service
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Microsoft Exchange MTA Stacks
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Microsoft Exchange Routing Engine
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Network News Transfer Protocol (NNTP)
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Verify that unneeded Front End services are disabled.
Procedure:
Microsoft Exchange Information Store
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\MSExchangeIS Key: START Value: Reg_DWORD 0x00000004
Microsoft Exchange MTA Stacks
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\MSExchangeMTA Key: START Value: Reg_DWORD 0x00000004
Microsoft Exchange Routing Engine
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\RESVC Key: START Value: Reg_DWORD 0x00000004
Microsoft Exchange IMAP4
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\IMAP4SVC Key: START Value: Reg_DWORD 0x00000004.
Microsoft Exchange POP3
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\POP3SVC Key: START Value: Reg_DWORD 0x00000004
Microsoft Exchange Event
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\MSExchangeES Key: START Value: Reg_DWORD 0x00000004
Network News Transfer Protocol (NNTP)
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\NNTPSVC Key: START Value: Reg_DWORD 0x00000004
Microsoft Exchange Site Replication Service
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\MSExchangeSRS Key: START Value: Reg_DWORD 0x00000004
Criteria: If unnecessary services are disabled, this is not a finding. EMG3-801 Exch2K3BEE-Mail server has unneeded processes or services active.<VulnDiscussion>Unneeded, but running, services offer attackers an enhanced attack profile, and attackers are constantly watching to discover open ports with running services. By analyzing and disabling unneeded services, the associated open ports become unresponsive to outside queries, and servers become more secure as a result.
Exchange 2003 has role-based server deployment to enable protocol path control and logical separation of network traffic types.
For example, a server implemented in the Client Access role (i.e., Outlook Web Access [OWA]) is configured and tuned as a web server using web protocols. A client access server exposes only web protocols (HTTP/HTTPS) enabling System Administrators to optimize the protocol path and disable all services unnecessary for Exchange web services. Similarly, Back-End servers created to host mailboxes are dedicated to that task, and operate only the services needed for mailbox hosting. (Back-end servers must also operate some Web services, but only to the degree that Exchange 2003 requires the IIS engine in order to function).
To restrict attack vectors available with E-mail message access, the protocols on the E-mail servers should match offerings on the DoD standard desktop deployment. These include Microsoft Outlook using MAPI, S/MIME enabled clients, and secured connections. It also includes Outlook via VPN for offsite telework. Browsers may access OWA provided it uses PKI/CAC access brokered through a reverse proxy Application Server.
Because NNTP, POP3, and IMAP4 clients are not included in the standard desktop offering, they must be disabled. Guidance is not provided for these protocols in this document. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Disable unneeded services.
Procedure: Navigate to Start >> Settings >> Administrative Tools >> Services
Create correct configurations
Microsoft Exchange IMAP4
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Microsoft Exchange POP3
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Microsoft Exchange Event
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Network News Transfer Protocol (NNTP)
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Microsoft Exchange Site Replication Service
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to DisableVerify that Unneeded Services are disabled on Back-end. Both User Interface path and Registry path are included for convenience.
Procedure:
Microsoft Exchange IMAP4
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\IMAP4SVC Key: START Value: Reg_DWORD 0x00000004.
Microsoft Exchange POP3
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\POP3SVC Key: START Value: Reg_DWORD 0x00000004
Microsoft Exchange Event
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\MSExchangeES Key: START Value: Reg_DWORD 0x00000004
Network News Transfer Protocol (NNTP)
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\NNTPSVC Key: START Value: Reg_DWORD 0x00000004
Microsoft Exchange Site Replication Service
Right Click >> Stop Service, if running.
Right Click >> Properties >> Start Type change to Disable
Registry:
HKLM\CCS\Services\MSExchangeSRS Key: START Value: Reg_DWORD 0x00000004
Criteria: If unused services are disabled, this is not a finding.
EMG1-002 Outlook Mobile Access (OMA) Directory<GroupDescription></GroupDescription>EMG1-002 Exch2K3Unneeded OMA E-mail Web Virtual Directory is not removed.<VulnDiscussion> To reduce the vectors through which a server can be attacked, unneeded application components should be disabled or removed. By default, a virtual directory is installed for OMA, and the Exchange application default has OMA disabled. If an attacker were to intrude into an Exchange Front-End server and reactivate OMA, this attack vector could once again be open, provided the virtual directory were present. Once removed, the OMA functionality cannot be used without restoring the virtual directory, not a trivial process. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Delete the OMA virtual directory.
Procedure: IIS Manager >> [server name]>>Web Sites >> Default Web Site >>OMA
Delete the OMA virtual directory.
Verify that OMA Virtual Directory is removed.
Procedure: IIS Manager >> [server name]>>Web Sites >> Default Web Site
Identify the OMA virtual directory in the list.
Criteria: If the OMA virtual directory is deleted, this is not a finding. EMG1-004 Microsoft Active Sync Directory<GroupDescription></GroupDescription>EMG1-004 Exch2K3Unneeded Active Sync E-mail Web Virtual Directory is not removed. <VulnDiscussion>To reduce the vectors through which a server can be attacked, unneeded application components should be disabled or removed. By default, a virtual directory is installed for Active Sync, and the Exchange application default has Active Sync disabled. If an attacker were to intrude into an Exchange Front-End server and reactivate Active Sync, this attack vector could once again be open, provided the virtual directory were present. Once removed, the Active Sync functionality cannot be used without restoring the virtual directory, not a trivial process. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Delete the Active Sync virtual directory.
Procedure: IIS Manager >> [server name]>>Web Sites >> Default Web Site
Identify and delete the Microsoft Server-Active Sync virtual directory.
Verify that ActiveSync Virtual Directory is removed.
Procedure: IIS Manager >> [server name]>>Web Sites >> Default Web Site
Identify the Microsoft Server-Active Sync virtual directory.
Criteria: If the Active Sync virtual directory is deleted, this is not a finding.
EMG1-012 Public Folder Virtual Directory<GroupDescription></GroupDescription>EMG1-012 Exch2K3Unneeded "Public" E-mail Virtual Directory is not removed. <VulnDiscussion> To reduce the vectors through which a server can be attacked, unneeded application components should be disabled or removed. By default, a virtual directory is installed for Public Folders. If an attacker were to intrude into an Exchange Front-End server and be able to access the public folder web site, it would provide an additional attack vector, provided the virtual directory were present. Once removed, the Public functionality cannot be used without restoring the virtual directory, not a trivial process. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Delete the Public Folder virtual directory.
Procedure: IIS Manager >> [server name]>>Web Sites >> Default Web Site
Identify and delete the "Public" Virtual Directory. If Public Folders are in use at the site, this check is N/A.
Verify that "Public" Virtual Directory is removed.
Procedure: IIS Manager >> [server name]>>Web Sites >> Default Web Site
The "Public" virtual directory should be missing from the list.
Criteria: If the "Public" virtual directory is missing from the list, this is not a finding.
EMG2-713 Connectors Clearly Named<GroupDescription></GroupDescription>EMG2-713 Exch2K3Connectors are not clearly named as to direction or purpose. <VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. For connectors, unclear naming as to direction and purpose increases risk that messages may not flow as intended, troubleshooting efforts may be impaired, or incorrect assumptions made about the completeness of the configuration.
Collectively, connectors should account for all connections required for the overall E-Mail topology design. Simple Mail Transfer Protocol (SMTP) connectors, when listed, must name purpose and direction clearly, and their counterparts on servers to which they connect should be recognizable as their partners. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Revise connectors to ensure they are named clearly as to purpose and direction.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative groups] >> Routing Groups >> Connectors
Revise names to clearly show purpose and direction. Review connectors created for the site.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative groups] >> Routing Groups >> Connectors
List of connectors should be clearly named as to purpose and direction.
Criteria: If connectors are clearly named as to purpose and direction, this is not a finding. EMG2-710 Routing Group Message Size Restriction<GroupDescription></GroupDescription>EMG2-710 Exch2K3Message size restrictions are specified on routing group connectors. <VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. For message size restrictions, multiple places exist to set or override inbound or outbound message size. Failure to control the configuration strategy can result in loss of data or system availability.
This setting enables the administrator to control the maximum size of outgoing messages on a Routing Group connector. It is recommended that, in general, no limits are applied at the connector level. This is done so that connectors do not end up prohibiting the delivery of messages that would otherwise be permitted by the Exchange configuration at the virtual server level. Using connectors to control size limits at an enterprise-wide level is discouraged since the limits would need to be applied to every potential connector in order to create an effective enterprise-wide limit.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure Simple Mail Tranfer Protocol (SMTP) Connectors.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Routing Groups >> [routing group] >> Connectors>> [Routing Group connector] >> Properties >> Content Restriction tab >> Allowed Sizes
Clear the “Only messages less than (KB)” checkbox.
Validate Simple Mail Transfer Protocol (SMTP) connector configurations.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Routing Groups >> [routing group] >> Connectors>> [Routing Group connector] >> Properties >> Content Restriction tab >> Allowed Sizes
The “Only messages less than (KB)” checkbox should be cleared.
Criteria: If “Only messages less than (KB)” checkbox is cleared, this is not a finding.
EMG2-123 SMTP Outbound Delivery Retry <GroupDescription></GroupDescription>EMG2-123 Exch2K3The Outbound Delivery Retry Values are not at the Defaults, or do not have alternate values documented in the System Security Plan.<VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. This setting controls the rate at which delivery attempts from the home domain are retried, user notification is issued, and expiration timeout when the message will be discarded.
If delivery retry attempts are too frequent, servers will generate network congestion. If too far apart, then messages may remain queued longer than necessary, potentially raising disk resource requirements.
The default values of these fields should be adequate for most environments. Administrators may wish to modify the values as a result, but changes should be documented in the System Security Plan.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set Outbound Delivery Retry values. If alternate values are desired, they must also be documented in the System Security Plan.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >> Delivery tab >> outbound
Enter values as shown:
- the “First retry interval” (10 min)
- the “Second retry interval” (15 min)
- the “Third retry interval” (15 min)
- the “Subsequent retry interval” (15 min).
- the “delay notification” (12 hrs)
- the “expiration timeout” (2 days)
Access the Simple Mail Transfer Protocol (SMTP) Connection Retry configuration.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >> Delivery tab >> Outbound
The default values should be in use, or alternate values may be in use, but they should also be documented in the System Security Plan.
- the “First retry interval” (10 min)
- the “Second retry interval” (15 min)
- the “Third retry interval” (15 min)
- the “Subsequent retry interval” (15 min).
- the “delay notification” (12 hrs)
- the “expiration timeout” (2 days)
Criteria: If the message delivery retry settings are as shown above, or have alternate values justified in the System Security Plan, this is not a finding.
EMG2-130 SMTP Maximum Hop Count <GroupDescription></GroupDescription>EMG2-130 Exch2K3SMTP Maximum Hop Count is not 30.<VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. This setting controls the maximum number of hops (E-mail servers traversed) a message may take as it travels to its destination. Part of the original Internet protocol implementation, the hop count limit prevents a message being passed in a routing loop indefinitely. Messages exceeding the maximum hop count are discarded undelivered.
Recent studies indicate that virtually all messages can be delivered in fewer than 25 hops, well within the current default of 30. If the hop count is set too low, messages may expire before they reach their destinations. If set too high, an undeliverable message may cycle between servers, raising the risk of network congestion.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set the maximum hop count value.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> Delivery tab >> advanced button.
For "Enter maximum hop count", enter 30.
Access the SMTP Maximum Hop Count configuration.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> Delivery tab >> Advanced button
The “Enter maximum hop count” value should be 30.
Criteria: If the “Enter maximum hop count” value is 30, this is not a finding. EMG2-126 SMTP Outbound Connections Count Limit <GroupDescription></GroupDescription>EMG2-126 Exch2K3SMTP Maximum outbound connections are not at 1000, or an alternate value is not documented in System Security Plan.<VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. This setting controls the maximum number of simultaneous outbound connections allowed for a given SMTP Virtual Server, and can be used to throttle the SMTP service if resource constraints warrant it. If the limit is too low, connections may be dropped. If too high, some domains may use a disproportionate resource share, denying access to other domains. Appropriate tuning reduces risk of data delay or loss. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set the maximum outbound connection count.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >> Delivery tab >> Outbound Connections button
Enter 1000 for "Maximum Outbound Connections", or enter an alternate value if local site conditions warrant it, and document it in the System Security Plan.
Access the mail server outbound connection configuration.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> Delivery tab >> Outbound Connections button
The “Maximum Outbound Connections” should be set to 1000, or an alternate value that is documented in the System Security Plan.
Criteria: If the "Maximum Outbound Connections" is at 1000, or set to an alternate value that is explained in the System Securtiy Plan, this is not a finding. EMG2-114 Outbound Connection Timeout Limit <GroupDescription></GroupDescription>EMG2-114 Exch2K3Maximum outbound connection timeout limit is not at 10 minutes or less. <VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. This configuration controls the number of idle minutes before the connection is dropped. It works in conjunction with the Maximum Outbound Connections Count setting.
Connections, once established, may incur delays in message transfer. The default of 10 minutes is a reasonable window in which to resume activities without maintaining idle connections for excessive intervals. If the timeout period is too long, idle connections may be maintained for unnecessarily long time periods, preventing new connections from being established. Sluggish connectivity increases the risk of lost data. A value of 10 or less is optimal.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Procedure: Set the outbound connection timeout limit.
Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> Delivery tab >> Outbound Connections button.
Enter Outbound Connections Timeout value = 10 or less.Access the mail server outbound connection timeout configuration.
Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> Delivery tab >> outbound connections button.
Ensure that the “Outbound Connections Timeout” value is = 10 or less.
Criteria: If outbound connections timeout limit is at 10 or less, this is not a finding.
EMG2-120 Outbound Connections Per Domain <GroupDescription></GroupDescription>EMG2-120 Exch2K3Outbound Connection Limit per Domain Count is not 100 or less. <VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. This configuration controls the maximum number of simultaneous outbound connections from a domain, and works in conjunction with the Maximum Outbound Connections Count setting as a delivery tuning mechanism. If the limit is too low, connections may be dropped. If too high, some domains may use a disproportionate resource share, denying access to other domains. Appropriate tuning reduces risk of data delay or loss.
By default, a limit of 100 simultaneous outbound connections from a domain should be sufficient. The value may be adjusted downward if justified by local site conditions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set the Outbound Connections per Domain Count.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >> Delivery tab >> Outbound Connections button.
Enter Outbound Connections per Domain Count = 100 or less.
Access the mail server Outbound Connection configuration.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >> Delivery tab >> Outbound Connections button.
The “Outbound Connections per Domain Count” should be = 100 or less.
Criteria: If "Outbound connections per domain count" is 100 or less, this is not a finding. EMG2-125 SMTP Inbound Connections Count Limit<GroupDescription></GroupDescription>EMG2-125 Exch2K3Inbound Connection Count Limit is not set to "Unlimited". <VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. This configuration controls the maximum number of simultaneous inbound connections allowed to the SMTP server. By default, the number of simultaneous inbound connections is unlimited. If a limit is set and is too low, the connections pool may get filled. If attackers perceive there is a limit, they could deny service to the Simple Mail Transfer Protocol (SMTP) server using a limited connection count (set to unlimited), attackers would need many more connections to cause denial of service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set the Limit Inbound Connections limit.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> General tab
Clear the “Limit number of connections to” checkbox.
Access the SMTP Inbound Connections configuration.
Exchange System Manager >> administrative groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> General tab
The “Limit number of connections to” checkbox should be cleared.
Criteria:
If the "Limit Number of Connections to" is cleared, this is not a finding.
EMG2-117 SMTP Inbound Connection Timeout Limit <GroupDescription></GroupDescription>EMG2-117 Exch2K3Maximum Inbound Connection Timeout Limit is not 10 or less. <VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. This configuration controls the number of idle minutes before the connection is dropped. It works in conjunction with the Maximum Inbound Connections Count setting.
Connections, once established, may incur delays in message transfer. The default of 10 minutes is a reasonable window in which to resume activities without maintaining idle connections for excessive intervals. If the timeout period is too long, idle connections may be maintained for unnecessarily long time periods, preventing new connections from being established. Sluggish connectivity increases the risk of lost data. A value of 10 or less is optimal. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set the Inbound Connection Timeout limit.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> General tab
Enter "Connection timeout" value = 10. If a value less than 10 is desired for the site, and is documented in the System Security Plan, then enter a value less than 10.Access the mail server connection timeout configuration.
Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> General tab
Ensure the “Connection Timeout” value is = 10 or less.
Criteria: If the ‘Inbound Connections Timeout Limit’ value is at 10 or less, this is not a finding.
EMG2-250 SMTP Inbound Connection Restrictions <GroupDescription></GroupDescription>EMG2-250 Exch2K3SMTP Connection Restrictions do not use the "Deny All" strategy. <VulnDiscussion>E-mail is only as secure as the recipient. Recipient SMTP servers that accept messages from all sources provide a way for rogue senders (such as SPAMMERS) or malicious users to insert message batches (that may be SPOOFED or FORGED) into the message transfer path. This setting controls which IP addresses are allowed to connect to this Virtual Server to download messages.
Two strategies exist for this control, “Deny None” or “Deny All”. Exceptions can be listed in the form of IP addresses, which can also be wildcarded as subnet groups.
To significantly reduce the attack vector for unauthorized connections, the “Deny All” approach must be used, stating authorized connections from “only the list below”.
Depending on the server’s role in the infrastructure, the list of clients or other SMTP servers authorized to connect to this virtual server should be specified.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set the Inbound Connections configuration.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> Access tab >> Connection control >> Connection button
Select “Only the list below” and list addresses or subnets authorized to connect to this server.
Access the mail server inbound connections configuration.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> Access tab >> Connection control >> Connection button
"Only the list below” should be selected, with a list of addresses or subnets authorized to connect to this server.
Criteria: If "Only the list below” is selected, with a list of addresses or subnets authorized to connect to this server, this is not a finding. EMG2-272 SMTP Protocol Filters Engaged<GroupDescription></GroupDescription>EMG2-272 Exch2K3SMTP Sender, Recipient, or Connection Filters are not engaged. <VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. Careful tuning reduces the risk that system or network congestion will contribute to availability impacts.
Filters that govern inbound E-mail evaluation can significantly reduce SPAM, PHISHING, and SPOOFED E-mails. Messages from blank senders, known SPAMMERS, or 0-day attack modifications must be enabled to be effective.
Even if filtering is not being performed on the Exchange servers, there is no adverse effect from having them enabled (even if no configuration exist for the filter itself). It may prevent accidental omission in the event that a filter is configured in the future. If one of the filters does have configuration values, failure to enable the filter will result in no action taken. This setting should always be enabled. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Enable the Sender, Recipient, and Connection Filters.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> General tab >> Advanced >> Edit
Select checkboxes for “Apply Sender Filter” “Apply Recipient Filter” and “Apply Connection Filter”.
Verify that Exchange Filters are enabled.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> Servers >> [Server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> General tab >> Advanced >> Edit
The “Apply Sender Filter” “Apply Recipient Filter” and “Apply Connection Filter” checkbox should be selected.
Criteria:
If “Apply Sender Filter” “Apply Recipient Filter” and “Apply Connection Filter” checkboxes are selected, this is not a finding.
EMG2-251 ExAdmin Virtual Directory Authentication<GroupDescription></GroupDescription>EMG2-251 Exch2K3ExAdmin Virtual Directory is not Configured for Integrated Windows Authentication.<VulnDiscussion>Identification and Authentication provide the foundation for access control. The ExAdmin Virtual Directory is used by the Exchange System Manager to access mailboxes and Public Folders. This feature controls the authentication method used to connect to this virtual directory.
This setting should be set to Integrated Windows Authentication only. Anonymous access provides for no access control of this virtual directory, Basic authentication transmits the password in the clear, and the other methods are not recommended by Microsoft for this control.
Failure to configure this as per the recommendations may result in unrestricted access to this directory, passwords being sent in the clear, and/or the inability to correctly authenticate, depending on which change is made.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure the ExAdmin Virtual Directory Authentication.
Procedure: Exchange system Manager >> Administrator Groups>> [administrator group]>>Servers>> [server name]>>Protocols>>HTTP>Exchange Virtual Server>>ExAdmin>>Properties>>Access Tab>>Authentication Settings>>Authentication button
Select "Integrated Windows Authentication".
Validate ExAdmin Virtual Directory authentication settings.
Procedure: Exchange system Manager >> Administrator Groups>> [administrator group]>>Servers>> [server name]>>Protocols>>HTTP>Exchange Virtual Server>>ExAdmin>>Properties>>Access Tab>>Authentication Settings>>Authentication button
"Integrated Windows Authentication" should be selected.
Criteria: If "Integrated Windows Authentication" is selected, this is not a finding.
EMG2-730 SMTP Connector Scope (Routing Group)<GroupDescription></GroupDescription>EMG2-730 Exch2K3Routing Group is not selected as the SMTP connector scope.<VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. This setting determines which SMTP Servers are permitted to use this SMTP Connector, identifying those for which it is the most efficient link. Failure to control SMTP network connections risks slow or lost data due to inefficient links between SMTP connections.
Selecting “Entire Organization” allows any computer in the Exchange organization to use this connector. Selecting “Routing Group” means only those members of the connector's routing group may use the connector. Use of the connector should be limited to the Routing Group in order to limit and control general network connectivity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure the SMTP connector scope.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Routing Groups>> [routing group]>>Connectors>> [SMTP connector]>> >>Properties >> Address Space tab>>Connector Scope
Select the “Routing Group” checkbox.
Validate connector scope configuration.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Routing Groups>> [routing group]>>Connectors>> [SMTP connector]>> >>Properties >> Address Space tab>>Connector Scope
The “Routing Group” checkbox should be selected.
Criteria: If the “Routing Group” checkbox is selected, this is not a finding. EMG2-721 SMTP Connect to Smart Host<GroupDescription></GroupDescription>EMG2-721 Exch2K3The SMTP connectors do not specify use of a “Smart Host”.<VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. In the case of identifying a ‘Smart Host’ for the E-Mail environment, the connector level is the preferred location for this configuration because flow control in this routing group will be retained even if future changes occur at the virtual server level.
A ‘Smart Host’ (Edge Transport Server) Role acts as an Internet Facing Concentrator for other E-mail servers. Appropriate hardening can be applied to the Edge Transport Server (E-Mail Secure Gateway) role rather than at multiple locations throughout the enterprise. The ‘Smart Host’ performs all Domain Name Service (DNS) lookups to determine mail routing and offers some proxy-type benefits.
Failure to identify a ‘Smart Host’ could default to each E-mail server performing its own lookups (potentially through protective firewalls). Exchange 2003 servers should not be Internet facing, and should therefore not perform any ‘Smart Host’ functions. They must, however, be configured to identify the server that is performing the “Smart Host” function.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-721</Mitigations><SeverityOverrideGuidance>Note: Implementations may have this feature configured as pointing to a “Smart-Host” function on the Exchange 2003 Bridgehead or Mailbox Server where no E-mail Secure Gateway exists outside the enclave firewall. This configuration is preferred when no E-mail Secure Gateway server is in use; however, it does not qualify as closing the open finding for perimeter protection. If this configuration is in place, finding to be downgraded to a CAT III.</SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>Implementations may have this feature configured as pointing to a “Smart-Host” function on the Exchange 2003 Bridgehead or Mailbox Server where no E-mail Secure Gateway exists outside the enclave firewall. This configuration is preferred when no E-mail Secure Gateway server is in use; however, it does not qualify as closing the open finding for perimeter protection. If this configuration is in place, finding to be downgraded to a CAT III.
Configure the 'Smart Host'.
Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Routing Groups>> [routing group]>>Connectors>> [SMTP connector]>> >>Properties >> General tab>>Radio Group
The “Smart-Host” should be selected and the designated E-Mail server should be identified.
</MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure the “Smart-Host” on the SMTP connector.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Routing Groups>> [routing group]>>Connectors>> [SMTP connector]>> >>Properties >> General tab>>Radio Group
Select “Smart-Host” and specify the name of the E-mail Edge Transport Role Server (E-mail Secure Gateway) that performs the “Smart-Host” function.
Review the connector configuration.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Routing Groups>> [routing group]>>Connectors>> [SMTP connector]>> >>Properties >> General tab>>Radio Group
“Smart-Host” should be selected, and the "Smart Host" identified be an Edge Transport Role server (E-mail Secure Gateway).
Criteria:
If “Smart-Host” is selected, and the "Smart Host" named is the Edge Transport Role (E-mail Secure Gateway), this is not a finding.
EMG2-736 SMTP Connector Authenticated Relay <GroupDescription></GroupDescription>EMG2-736 Exch2K3SMTP connectors allow unauthenticated relay.<VulnDiscussion>Identification and Authentication provide the foundation for access control. The key to preventing SPAM insertion into the SMTP message transfer path is to require authentication at each ‘hop’ of the journey from sender to receiver. Allowing unauthenticated relaying on an internal host allows internal users or applications to submit unauthenticated mail messages, a form of internally spoofed SPAM that can be difficult to trace.
Allowing unauthenticated relaying on an “Internet Facing” host would enable any unauthenticated party to use your Exchange Server to resend mail. This practice is often employed by spammers to obfuscate the source of their messages. Allowing unauthenticated relaying will almost inevitably result in abuse of the relay by spammers and increased load on the connector. It can also result in the appearance of the host’s domain on Reputation Black Lists.
This setting controls whether unauthenticated computers are allowed to resend (relay) E-mail messages through this connector to external domains. (Authenticated users and computers can always relay messages regardless of this control's setting.) It is recommended that no unauthenticated connections be allowed in the SMTP path. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Prevent unauthenticated mail relaying.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Routing Groups>> [routing group]>>Connectors>> [SMTP connector]>> >>Properties >> Address Space tab
Clear the “Allow messages to be relayed to these domains” checkbox.
Validate SMTP Connector Relay authentication.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Routing Groups>> [routing group]>>Connectors>> [SMTP connector]>> >>Properties >> Address Space tab
The “Allow messages to be relayed to these domains” should be unchecked.
Criteria: If “Allow messages to be relayed to these domains” is unchecked, this is not a finding. EMG2-146 SMTP Virtual Server Relay Exclusions <GroupDescription></GroupDescription>EMG2-146 Exch2K3SMTP virtual Server does not Restrict Relay Access. <VulnDiscussion>E-mail is only as secure as the recipient. This control is used to limit the servers that may use this server as a relay. If an Simple Mail Transport Protocol (SMTP) sender does not have a direct connection to the Internet (for example, an application that produces reports to be E-mailed) then it will need to use an SMTP Virtual Server that does have a path to the Internet (for example, a local E-mail server) as a relay.
SMTP relay functions must be protected so that third parties are not able to hijack a relay service for their own purposes. Most commonly, hijacking of relays is done by SPAMMERS to disguise the source of their messages, and may also be used to cover the source of more destructive attacks.
Relays can be restricted in one of three ways; by blocking relays (restrict to a blank list of servers), by restricting use to lists of valid servers, or by restricting use to servers that can authenticate. A fourth configuration, ‘allow all except the list below’, should never be used. Because authenticated connections are the most secure for SMTP virtual servers, it is recommended that relays allow only servers that can authenticate. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure E-Mail relay exclusions.
Procedure: For servers that are authorized to relay messages, configure the following:
Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Servers>> [server]>>Protocols>> SMTP >> [specific SMTP virtual server]>> >>Properties >> Access Tab >> Relay restrictions >> Relay Button
Select “Allow all computers which successfully authenticate to it”.
For servers that are not authorized to relay messages, configure the following:
Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Servers>> [server]>>Protocols>> SMTP >> [specific SMTP virtual server]>> >>Properties >> Access Tab >> Relay restrictions >> Relay Button
Procedure: Select “Allow only the list below” and specify no servers in the list. Access the System Security Plan. Determine whether the server being reviewed is authorized to perform as a relay. Validate relay restriction configuration.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Servers>> [server]>>Protocols>> SMTP >> [specific SMTP virtual server]>> >>Properties >> Access Tab >> Relay restrictions >> Relay Button.
For servers authorized to perform as a relay:
“Allow all computers which successfully authenticate to it” should be selected.
Criteria: If “Allow all computers which successfully authenticate to it” is selected, this is not a finding.
For servers not authorized to perform as a Relay:
“Select only the List below” with no servers listed should be selected.
Criteria: If “Select only the List below” with no servers listed, this is not a finding. EMG2-131 SMTP Virtual Server as “Smart-Host” <GroupDescription></GroupDescription>EMG2-131 Exch2K3“Smart-Host” is specified at the Virtual Server level. <VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. This control determines whether the entire Virtual Server routes its outbound Simple Mail Transfer Protocol (SMTP) messages through a single “Smart-Host”.
“Smart-Hosts” can help secure communication, but configuring the virtual server level to use the same “Smart-Host” can lead to congestion problems and inflexibility. As such, it is recommended that administrators NOT use “Smart-Hosts” at the virtual server level. Instead, use of “Smart-Hosts” should be configured at the SMTP connector level. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure the SMTP Virtual Verver “Smart-Host” list.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Servers>> [server]>>Protocols>> SMTP >> [specific SMTP virtual server]>> >>Properties >> Delivery Tab >> Advanced button >> “Smart-Host”
Clear the list of any “Smart-Hosts”.
Validate “Smart-Host” configuration at the Virtual Server Level.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Servers>> [server]>>Protocols>> SMTP >> [specific SMTP virtual server]>> >>Properties >> Delivery Tab >> Advanced button>> “Smart-Host”
The list of “Smart-Hosts” should be cleared.
Criteria: If the list of “Smart-Hosts” is empty, this is not a finding.
EMG2-148 SMTP Delivery DNS Reverse Lookups <GroupDescription></GroupDescription>EMG2-148 Exch2K3The SMTP Virtual Server performs reverse DNS lookups for anonymous message delivery.<VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. This feature causes the server to use a Directory Naming Service (DNS) lookup to try to resolve the source of incoming E-mail for anonymous messages as part of the delivery feature.
While enabling this feature does not pose an attack hazard, it is recommended that this feature be disabled to avoid impacting resource availability. It is relatively easy to fool the DNS lookup, and therefore creates unnecessary risk to the E-mail system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure the anonymous delivery DNS option.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Servers>> [server]>>Protocols>> SMTP >> [specific SMTP virtual server]>> >>Properties >> Delivery Tab >> Advanced button
Clear the "Perform Reverse DNS lookup on incoming messages" checkbox.
Validate Reverse DNS lookup delivery configuration.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Servers>> [server]>>Protocols>> SMTP >> [specific SMTP virtual server]>> >>Properties >> Delivery Tab >> Advanced button
The "Perform Reverse DNS lookup on incoming messages" checkbox should be cleared.
Criteria: If the "Perform Reverse DNS lookup on incoming messages" checkbox is cleared, this is not a finding.
EMG2-803 SMTP Virtual Server Outbound Security<GroupDescription></GroupDescription>EMG2-803 Exch2K3Virtual Server default outbound security is not anonymous and TLS. <VulnDiscussion>Identification and Authentication provide the foundation for access control. The key to preventing SPAM insertion into the SMTP message transfer path is to require authentication at each ‘hop’ of the journey from sender to receiver. Failure to authenticate increases risk that an attacker can insert unauthenticated mail messages, a form of internally SPOOFED SPAM that can be difficult to trace. Encryption ensures confidentiality of data in motion as it traverses network connections. Failure to specify TLS encryption causes message transfer to be sent unencrypted, (including the authentication password), which makes it susceptible to eavesdropping.
This setting controls the default authentication and encryption algorithms used for outbound connections using this connector. (That is, the authentication used when delivering outbound mail to another SMTP Virtual Server.) Because E-Mail services environments typically support multi-directional message flow at the Connector level, it is preferred that specific requirements be set there, and let this configuration at the Virtual Server level serve as a default. Authentication type of Anonymous and use of TLS are recommended for this setting. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set Virtual Server outbound security.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP virtual server] >> Properties >> Delivery tab >> Outbound Security button
Select “Anonymous” and "TLS" encryption. Validate the Virtual Server outbound Security.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP virtual server] >> Properties >> Delivery tab >> Outbound Security button
“Anonymous” and "TLS" should be selected.
Criteria: If “Anonymous” and "TLS" are selected, this is not a finding. EMG2-143 SMTP Resolve Anonymous E-mail<GroupDescription></GroupDescription>EMG2-143 Exch2K3The SMTP Virtual Server is configured to perform DNS lookups for anonymous E-mails. <VulnDiscussion>E-Mail system availability depends in part on best practices strategies for setting tuning configurations. This feature causes the server to use a Directory Naming Service (DNS) lookup to try to determine the source of each anonymous E-mail message.
While enabling this feature does not pose an attack hazard, it is recommended that this feature be disabled to avoid impacting resource availability.
Anonymous E-mail is invariably SPAM and should be filtered when received at the perimeter. In this context, DNS lookup is not a reliable indicator of perpetrator information, due to its likelihood of SPAM content and therefore likelihood of altered DNS entries. The DNS lookup result does not add value, and therefore should not be an enabled feature.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure each SMTP virtual server.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> Access Control Tab >> Authentication button
Clear the “Resolve Anonymous E-mail” checkbox.
Validate anonymous E-mail resolution configuration.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> Access Control Tab >> Authentication button
The “Resolve Anonymous E-mail” checkbox should be cleared.
Criteria:
If the “Resolve Anonymous E-mail” checkbox is cleared, this is not a finding.
EMG2-333 E-mail Server Circular Logging<GroupDescription></GroupDescription>EMG2-333 Exch2K3BEE-mail Server "Circular Logging" is not set appropriately. <VulnDiscussion>Logging provides a history of events performed, and can also provide evidence of tampering or attack. Failure to create and preserve logs adds to the risk that suspicious events may go unnoticed, or the raise the potential that insufficient history will be available to investigate them.
This setting controls how log files are written. If circular logging is enabled, there is one log file for this storage group with a maximum size of (for example, 5MB). Once the size limit has been reached, additional log entries begin overwriting the oldest log entries. If circular logging is disabled, once a log file reaches the size limit, a new log file is created.
Back-End Servers should not use circular logging. Logs should be written to a partition separate from the operating system, with log protection and backups being incorporated into the overall System Security plan.
Front-End Servers may opt to use circular logging, as message content is significantly less, and not of a critical nature. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure E-mail servers’ circular logging to be disabled.
Procedure: Exchange system Manager >> Administrative Groups >> [administrative group] >> servers >> [server] >> [storage group] >> Properties >> General tab
Clear the ‘Enable circular logging’ checkbox.
Validate Logging configuration.
Procedure: Exchange system Manager >> Administrative Groups >> [administrative group] >> servers >> [server] >> [storage group] >> Properties >> General tab
The ‘Enable circular logging’ checkbox should be cleared.
Criteria: If the 'Enable circular logging’ checkbox is cleared, this is not a finding.
EMG2-333 Exch2K3FEE-mail Server "Circular Logging" is not set appropriately. <VulnDiscussion>Logging provides a history of events performed, and can also provide evidence of tampering or attack. Failure to create and preserve logs adds to the risk that suspicious events may go unnoticed, or the raise the potential that insufficient history will be available to investigate them.
This setting controls how log files are written. If circular logging is enabled, there is one log file for this storage group with a maximum size of (for example, 5MB). Once the size limit has been reached, additional log entries begin overwriting the oldest log entries. If circular logging is disabled, once a log file reaches the size limit, a new log file is created.
Back-End Servers should not use circular logging. Logs should be written to a partition separate from the operating system, with log protection and backups being incorporated into the overall System Security plan.
Front-End Servers may opt to use circular logging, as message content is significantly less, and not of a critical nature. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-333 FE</Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>If E-Mail circular logging is disabled everywhere, including the Exchange Front End E-Mail server, this is an acceptable solution and 'not a finding', provided that the logs are created and stored using the more secure log preservation methods. </MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure E-mail circular logging.
Procedure: Exchange system Manager >> Administrative Groups >> [administrative group] >> servers >> [server] >> [storage group] >> Properties >> General tab
Check the ‘Enable circular logging’ checkbox.Validate Circular Logging configuration.
Procedure: Exchange system Manager >> Administrative Groups >> [administrative group] >> servers >> [server] >> [storage group] >> Properties >> General tab
The ‘Enable circular logging’ checkbox should be checked.
Criteria: If the ‘Enable circular logging’ checkbox is checked, this is not a finding.
EMG2-811 E-mail Diagnostic Log Levels <GroupDescription></GroupDescription>EMG2-811 Exch2K3E-mail Diagnostic Logging is enabled during production operations. <VulnDiscussion>Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Diagnostic logging, however, characteristically produces large volumes of data and requires care in managing the logs to prevent risk of disk capacity denial of service conditions.
Exchange Diagnostic Logging is broken up into 14 main “services” each of which has anywhere from 2 to 26 “categories” of events to be monitored. Moreover, each category may be set to one of four levels of logging: None (logging disabled), Minimum, Medium, and Maximum, depending on how much detail one desires. The higher the level of detail, the more disk space required to store the audit material.
Diagnostic logging is intended to help administrators debug problems with their systems, not as a general purpose auditing tool. The diagnostic logs collect a great deal of information – diagnostic log files can grow huge very quickly. Diagnostic logs should be enabled for limited periods of time when attempting to debug relevant pieces of Exchange functionality. Once debugging has finished, diagnostic logging should be disabled again.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure diagnostic logging.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Diagnostic Logging
For each item, select logging level “none”.
Review Diagnostic Logging Level
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Diagnostic Logging tab
Each item in the left panel, should have a status of “none”.
Criteria: If Each item in the left panel, has a status of “none”, this is not a finding.EMG2-810 E-mail Subject Logging <GroupDescription></GroupDescription>EMG2-810 Exch2K3E-mail “Subject Line” logging is enabled during production operations. <VulnDiscussion>Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. When “message tracking” is enabled, only the sender, recipients, time, and other delivery information is included by default. Information such as the subject and message body is not included.
However, the absence of the message subject line can make it difficult to locate a specific message in the log unless one knows roughly what time the message was sent. To simplify searches through these logs, Exchange offers the ability to include the message “subject line” in the log files and in the Message Tracking Center display. This can make it significantly easier to locate a specific Message.
This feature creates larger log files and will contain information that may raise privacy and legal concerns - enterprise policy should be consulted before this feature is enabled. Also, since the log files may contain sensitive information in the form of the subject line, the log files will need to be protected, commensurate with the sensitivity level, as the content may be of interest to an attacker.
For these reasons, it is recommended that subject logging not be enabled during regular production operations, but instead treat this feature as a diagnostic that can be used if needed. The tradeoff of this is that finding the correct message in the message tracking logs will become more difficult since the administrator will need to search using only the time the message was sent and the message’s sender. This control will have no effect unless Message Tracking is enabled. That said, the setting should be disabled in case message tracking is perchance enabled at a future time. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure E-Mail subject line logging.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> General Tab
Clear the “Enable Subject logging and display” checkbox.Verify that e-mail subject line logging is disabled.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> General tab
The “Enable Subject logging and display” checkbox should be cleared.
Criteria: If “Enable Subject logging and display” checkbox is cleared, this is not a finding. EMG2-825 SMTP Virtual Svr. Audit Log Partition <GroupDescription></GroupDescription>EMG2-825 Exch2K3SMTP Virtual Server Audit Records are not directed to a separate partition. <VulnDiscussion>Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. This setting controls the location of the SMTP Virtual Server log file.
By default, these files will be stored in \WINNT\SYSTEM32\LOGFILES\SMPTVSx (where x is a number used to distinguish between virtual servers in this organization). The drop-down menu is used to select the format of the log file. The properties button next to this dropdown displays configuration information specific to the type of log format selected, but usually has some control to indicate the log rotation schedule (that is, how often the old log file should be closed and a new log file should be started).
It is required that all log files be written to separate partitions from those used by the Exchange Stores and separate also from the Operating System. Exchange will dismount its stores if it detects that it has run out of disk space, resulting in a complete loss of Exchange services. To minimize the chance of this happening, log files should write to a separate partition so that if the logs fill this partition it will not result in the failure of Exchange.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure SMTP Virtual Server log location.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group}>> Servers >> [server] >> SMTP >> [specific SMTP server] >> Properties >> General tab >> Properties button
Select the “Enable Logging” checkbox.
Enter the log file location. Ensure that the log file path is other than the operating system partition, and other than the Exchange 2003 Mailbox data partition. Interview the E-mail Administrator (EMA) or the System Administrator. Ascertain the partition identifier for the operating system and the Mailbox data partitions. Review the log file configuration.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group}>> Servers >> [server] >> SMTP >> [specific SMTP server] >> Properties >> General tab >> Properties button
The “Enable Logging” checkbox in the log file directory box should be selected.
The log file path should NOT be the default path (\WINNT\SYSTEM32\LOGFILES\SMPTSVCx (where x is a number used to distinguish between virtual servers in this organization) or on the Mailbox Data partition.
Criteria: If SMTP Virtual Servers log is written to a partition that is NOT \WINNT\SYSTEM32\LOGFILES\SMPTSVCx, and also NOT the Mailbox Data partition, this is not a finding. EMG2-831 Send Fatal Errors to Microsoft <GroupDescription></GroupDescription>EMG2-831 Exch2K3Exchange sends fatal errors to Microsoft.<VulnDiscussion>Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. This setting enables an automated log entry to be sent to Microsoft giving general details about the nature and location of the error. Microsoft, in turn, uses this information to improve the robustness of their product.
While this type of debugging information would not ordinarily contain sensitive information, it may alert eavesdroppers to the existence of problems in your Exchange organization. At the very least, it could alert them to (possibly) advantageous timing to mount an attack. At worst, it may provide them with information as to which aspects of Exchange are causing problems and might be vulnerable (or at least sensitive) to attack.
All system errors in Exchange will result in outbound traffic that may be identified by an eavesdropper. For this reason, the “Report errors to Microsoft” feature must be disabled at all times.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure the "send error message to Microsoft" option.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> General tab
Clear the “Automatically send fatal service error to Microsoft” checkbox.
Access the “send error message to Microsoft” configuration.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> General tab
The “Automatically send fatal service error to Microsoft” checkbox should be clear.
Criteria: If “Automatically send fatal service error to Microsoft” checkbox is clear, this is not a finding. EMG2-835 Warning/Critical State Disk Threshold <GroupDescription></GroupDescription>EMG2-835 Exch2K3Disk Space Monitoring is not Configured with Threshold and Action. <VulnDiscussion>Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion. If the server were ever to run out of disk space, the server could fail catastrophically, possibly with data loss.
This field allows the administrator to control notifications when a ‘warning’ or ‘critical’ trigger is issued in response to low disk availability. A good rule of thumb is to issue warnings when free space falls under 15% and critical messages when it falls under 5% of total disk space.
Notification choices include E-Mail alert to an E-Mail enabled account, for example, an E-Mail Administrator, or invoke a script to take other action, for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure disk space monitoring.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab
1) Add the monitor, if needed:
Click ADD, select Free Disk Space. Add one monitor for each disk.
2) Set the warning and critical thresholds
Set the warning value not less than 15% of available disk and critical value not less than 5% of available disk.
3) Create the notifications:
Exchange System Manager >> Tools >> Monitoring and Status >> Notifications
Specify E-mail to the E-mail Administrator or Incident Response Team account at minimum. Optionally, a script can be invoked to create a log message.
If disk monitoring is performed via a third party tool as part of an overall data center monitoring strategy, then using Exchange monitoring for disk space usage is an acceptable solution, and this check is N/A.
Review disk space monitoring.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab >> Disk Space Threshold >> Details button
For each disk, "Warning" should be 15% or more of available Disk Space, and "Critical" should be 5% or more of available Disk Space (not to exceed the "Critical" figure). At minimum, actions should include sending an E-mail alert an on-call Exchange Administrator or to an Incident Response Administrator.
Criteria: If "Warning" is set to 15% or more of available disk space, and "Critical" is set to 5% or more of available disk space (not to exceed the "Critical" figure), and minimum, actions include sending an E-mail to an on-call Exchange Administrator or to an Incident Response Administrator, this is not a finding. EMG2-807 Warning/Critical CPU Threshold <GroupDescription></GroupDescription>EMG2-807 Exch2K3CPU Monitoring Notifications are not configured with threshold and action. <VulnDiscussion>Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed. Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.
This field offers choices of alerts when a ‘warning’ or ‘critical’ threshold is reached on CPU utilization. A good rule of thumb (default) is to issue warnings when CPU utilization exceeds 70% for a duration of 10 minutes and critical messages when it exceeds 80% for a duration of 10 minutes, which should only exist occasionally. Frequent alerts against this counter may indicate that additional capacity is needed, or a network or other issue (such as inbound SPAMMER traffic) that directly impacts E-mail delivery.
CPU availability should be monitored. If the server were ever to exceed the maximum CPU threshold, the server could effectively experience a denial of service (DOS) condition. Notification choices include E-Mail alert to an E-Mail enabled account, for example, an E-Mail Administrator, or invoke a script to take other action, for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Ensure that CPU utilization monitoring and notification is enabled.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring Tab >> CPU Utilization Threshold >> Details button
1) Add the monitor, if needed:
Click ADD, select CPU Utilization Threshold.
2) Set the duration, warning and critical thresholds
Set (for a sustained duration of 10 minutes) Warning value not greater than 80% and Critical value not greater than 90%.
3) Create the notifications:
Exchange System Manager >> Tools >> Monitoring and Status >> Notifications:
Declare notifications and communication methods as required by local organization policy. At minimum, alert an on-call Exchange Administrator or Incident Response Administrator.
If CPU monitoring is performed via a third party tool as part of an overall data center monitoring strategy, then this check is N/A.
Review CPU utilization monitoring and notification.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab >> CPU Utilization Threshold >> Details button
"Warning" should be set (for a sustained duration of 10 minutes) at a value not greater than 80%. "Critical" should be set for a value of value not greater than 90%. At minimum, actions should E-mail an on-call Exchange administrator or Incident Response administrator.
Criteria: If CPU utilization monitoring "Warning" is set to (for a sustained duration of 10 minutes) 80% or less and "Critical" is set to 90% or less, with alert E-mail sent to an administrator, this is not a finding. EMG2-813 Warning / Critical State Virtual Memory<GroupDescription></GroupDescription>EMG2-813 Exch2K3Virtual memory monitoring notifications are not configured with threshold and action. <VulnDiscussion>Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.
This field offers choices of alerts when a ‘warning’ or ‘critical’ threshold is reached on low virtual memory. A good rule of thumb (default) is to issue warnings when virtual memory is less than 25% for a duration of 3 minutes, and critical messages when less than 10% for a duration of 3 minutes, which should only exist occasionally. Frequent alerts against this counter may indicate that additional capacity is needed, or a network or other issue (such as inbound SPAMMER traffic) that directly impacts e-mail delivery.
Virtual Memory availability should be monitored. Frequent alerts on this counter could indicate that the server is nearing capacity and that load mitigation measures may be needed. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure Virtual Memory utilization monitoring and notification.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab >> Virtual Memory Threshold >> Details button
1) Add the monitor, if needed:
Click ADD, select Virtual Memory Threshold.
2) Set the duration, warning and critical thresholds
Set (for a sustained duration of 3 minutes) Warning value not less than 25% and Critical value not less than 10%.
3) Create the notifications:
Exchange System Manager >> Tools >> Monitoring and Status >> Notifications:
Declare notifications and communication methods as required by local organization policy. At minimum, E-mail an on-call Exchange administrator or an Incident Response administrator.
If Virtual Memory Utilization monitoring is performed via a third party tool as part of an overall data center monitoring strategy, then this check is N/A.
Review virtual memory utilization monitoring and notification.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab >> Virtual Memory Threshold >> Details button
"Warning" should be set (for a sustained duration of 3 minutes) to a value not less than 25%. "Critical" should be a value not less than 10%. Minimum Action should be E-mail to an on-call Exchange Administrator or to an Incident Response administrator.
Criteria: If "Warning" is set (for a sustained duration of 3 minutes) to a value 25% or higher, and "Critical" is 10% or higher,and Action is an E-mail to an on-call Exchange Administrator, this is not a finding.
EMG2-806 Warning/Critical SMTP Queue Threshold <GroupDescription></GroupDescription>EMG2-806 Exch2K3SMTP Queue Monitor is not configured with a threshold and alert. <VulnDiscussion>Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed. Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.
This field offers choices of alerts when a ‘warning’ or ‘critical’ threshold is reached on the SMTP queue. A good rule of thumb (default) is to issue warnings when SMTP queue growth exceeds 10 minutes and critical messages when it exceeds 20 minutes, which should only exist occasionally. Frequent alerts against this counter may indicate a network or other issue (such as inbound SPAMMER traffic) that directly impacts E-mail delivery.
Notification choices include E-Mail alert to an E-Mail enabled account, for example, an E-Mail Administrator, or invoke a script to take other action, for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure SMTP queue monitoring and notification.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab >> SMTP Queue Threshold >> Details button
1) Add the monitor, if needed:
Click ADD, select SMTP queue Threshold. Add one monitor for each SMTP queue.
2) Set the warning and critical thresholds.
Set Warning value not less than 10 minutes and Critical value not less than 20 Minutes. Values should be realistic for the queue and site operational requirements.
3) Create the notifications: Exchange System Manager >> Tools >> Monitoring and Status >> Notifications:
Declare notifications and communication methods as required by the local organization policy. At minimum, E-mail an on-call Exchange administrator account or an Incident Response administrator. A script may be invoked to perform other actions.
If SMTP queue monitoring is performed via a third party tool as part of an overall data center monitoring strategy, then this check is N/A.
Review SMTP queue monitoring and notification.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab >> SMTP Queue Threshold >> Details button
'Warning" should be 10 or more minutes, and "Critical" should be 20 or more minutes. Minumim notification should be an E-mail alert to an administrator account.
Criteria: If 'Warning" is 10 or more minutes, and "Critical" is 20 or more minutes with minumim notification indicating an E-mail to an Administrator or Incident Response team account, this is not a finding.EMG2-815 Warning / Critical Windows 2003 Service <GroupDescription></GroupDescription>EMG2-815 Exch2K3FEWindows 2003 Services Monitoring Notifications are not configured with thresholds and actions.<VulnDiscussion>Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed. Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.
This setting allows the administrator to control notifications when a ‘warning’ or ‘critical’ trigger is issued in response to a selected Windows 2003 service being down. Exchange is dependent on certain Windows services being active: (Event Log, NT Lan Man (NTLM) Security Support Provider, Remote Procedure Call (RPC), Server, Workstation, Internet Information Service (IIS) Admin Services, and Hypertext Transfer Protocol (HTTP) Secure Sockets Layer (SSL). Failure in these services will cause Exchange to also fail in some way.
Once all the above services have been added, the “When service is not running change state to” field should be set to Critical. The trigger should be “Critical” because, if any of the services that the core Exchange services depend on stop, this will require immediate attention.
Notification choices include E-mail alert to an E-mail enabled account, (for example, an E-mail Administrator), or invoking a script to take other action (for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it).
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure Windows Services Monitoring.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab >> [Windows 2003 Service] >> Details button
1) Add the monitor, if needed:
Click ADD, select desired Windows 2003 Service. Add each service listed.
Event Log
NTLM Security Support Provider
Remote Procedure Call
Server
Workstation
IIS Admin Service
HTTP SSL
2) Set the warning and critical thresholds for each service
Set “When service is not running change state to” Critical.
3) Create the notifications for each service:
Exchange System Manager >> Tools >> Monitoring and Status >> Notifications:
Declare notifications and communication methods as required by the local organization policy. At minimum, send an E-mail to an on-call Exchange Administrator or Incident Response administrator.
If Windows Services Monitoring is performed via a third party tool as part of an overall data center monitoring strategy, then this is N/A.
Review Windows Services Monitoring and Notification.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab >> [Windows 2003 Service] >> Details button
The following Services should be monitored:
Event Log
NTLM Security Support Provider
Remote Procedure Call
Server
Workstation
IIS Admin Service
HTTP SSL
For each item, the "When Service is not Running, Change State to" should be "Critical"
Minimum action should be an E-mail sent to an E-mail Administrator or to an Incident Response team account.
Criteria: If, for each service the "When Service is not Running, Change State to" is"Critical", and the minimum action is to send an E-Mail to an Administrator or to an Incident Response Team account, this is not a finding. EMG2-815 Exch2K3BEWindows 2003 Services Monitoring Notifications are not configured with thresholds and actions.<VulnDiscussion>Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed. Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.
This setting allows the administrator to control notifications when a ‘warning’ or ‘critical’ trigger is issued in response to a selected Windows 2003 service being down. Exchange is dependent on certain Windows services being active: (Event Log, NT Lan Man (NTLM) Security Support Provider, Remote Procedure Call (RPC), Server, Workstation, Internet Information Service (IIS) Admin Services, and Hypertext Transfer Protocol (HTTP) Secure Sockets Layer (SSL). Failure in these services will cause Exchange to also fail in some way.
Once all the above services have been added, the “When service is not running change state to” field should be set to Critical. The trigger should be “Critical” because, if any of the services that the core Exchange services depend on stop, this will require immediate attention.
Notification choices include E-mail alert to an E-mail enabled account, (for example, an E-mail Administrator), or invoking a script to take other action (for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it).
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure Windows Services Monitoring.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab >> [Windows 2003 Service] >> Details button
1) Add the monitor, if needed:
Click ADD, select desired Windows 2003 Service. Add each service listed.
Event Log
NTLM Security Support Provider
Remote Procedure Call
Server
Workstation
IIS Admin Service
2) Set the warning and critical thresholds for each service
Set “When service is not running change state to” Critical.
3) Create the notifications for each service:
Exchange System Manager >> Tools >> Monitoring and Status >> Notifications:
Declare notifications and communication methods as required by the local organization policy. At minimum, send an E-Mail to an on-call Exchange Administrator or to an Incident Response administrator.
If Windows Services Monitoring is performed via a third party tool as part of an overall data center monitoring strategy, then this is N/A.
Review Windows Services Monitoring and Notification.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab >> [Windows 2003 Service] >> Details button
The following Services should be monitored:
Event Log
NTLM Security Support Provider
Remote Procedure Call
Server
Workstation
IIS Admin Service
For each item, the "When Service is not Running, Change State to" should be "Critical"
Minimum action should be an E-mail sent to an E-mail Administrator or to an Incident Response team account.
Criteria: If, for each service the "When Service is not Running, Change State to" is"Critical", and the minimum action is an E-Mail to an Administrato or Incident Response Team account, this is not a finding. EMG2-817 Warning / Critical Exchange Core Service<GroupDescription></GroupDescription>EMG2-817 Exch2K3Exchange Core Services Monitors are not configured with threshold and actions.<VulnDiscussion>Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Exchange 2003 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.
This field allows the administrator to control notifications when a ‘warning’ or ‘critical’ trigger is issued in response to an Exchange Core service being down. If exchange core services are down, the service status state should be set to critical, as this will require immediate attention.
Notification choices include E-Mail alert to an E-Mail enabled account, for example, an E-Mail Administrator, or invoke a script to take other action, for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure Exchange Core Services monitoring.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab >> [Windows 2003 Service] >> Details button
1) Add the monitor, if needed:
Click ADD, select desired Exchange core Service.
2) Set the warning and critical thresholds for each service
Set “When service is not running change state to” Critical.
3) Create the notifications for each service:
Exchange System Manager >> Tools >> Monitoring and Status >> Notifications
Declare notifications and communication methods as required by the local organization policy. At minimum, E-mail an on-call Exchange Administrator or an Incident Response administrator.
If Exchange Core Services monitoring is performed via a third party tool as part of an overall data center monitoring strategy, then this is N/A.
Review Exchange Core Services monitoring and notification. Note: List content may differ depending on specific Exchange components implemented.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring Tab >> [Default Microsoft Exchange Services] >> Details Button
For each item listed, the "When Service is not Running, Change State to" should be "Critical" and the minimum action should be an E-mail to an E-mail Administrator or to an Incident Response team account.
Criteria: If, for each service the "When Service is not Running, Change State to" is"Critical", and the minimum action is an E-mail to an Administrator or to an Incident Response Team account, this is not a finding. EMG2-266 Public Virtual Server User Permissions<GroupDescription></GroupDescription>EMG2-266 Exch2K3Users do not have correct permissions in the Public Virtual Server.<VulnDiscussion>The principle of Least Privilege ordinarily requires analysis to ensure that users and processes are granted only as much privilege as is required to function effectively, but no additional privileges that could enable mischief, either accidental or intentional.
The Pubic Virtual Server enables web access to public folder documents via browser. This control determines whether users will have read, write, script source access, and/or directory browsing capabilities under this virtual server.
Public Virtual Server requires that users have read, write, script source access, and directory browsing permissions since these are required for proper functioning Public Folders access. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure Public Virtual Server user permissions.
Procedure: Exchange system Manager >>Administrative Groups>> [administrative group]>> Servers >> [server name] >> protocols >> HTTP >> Exchange Virtual Server >> Public >> Properties >> Access tab
For Access Control, select ‘read, write, script source access, directory browsing’.
Validate that Public Virtual Server has correct user permissions.
Procedure: Exchange system Manager >>Administrative Groups>> [administrative group]>> Servers >> [server name] >> protocols >> HTTP >> Exchange Virtual Server >> Public >> Properties >> Access tab
For Access Control, ‘Read, write, Script source access, Directory browsing’ should be selected.
Criteria: If Access Control has ‘Read, write, Script source access, Directory browsing’ selected, this is not a finding. EMG2-030 Attachment Control - Perimeter <GroupDescription></GroupDescription>EMG2-030 Exch2K3BEE-mail servers are not protected by an Edge Transport Server role (E-mail Secure Gateway) removing disallowed message attachments at the network perimeter.<VulnDiscussion>By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the Mail server environment. Attachments have been known to carry malware, although the file type and malware types have changed over time.
Attachments must be controlled at the entry point into the E-mail environment to prevent successful attachment-based attacks. For outbound messages, the entry point is at E-mail creation, for example, in Outlook or Outlook Web Access (OWA). For inbound messages, it is at the perimeter. By using this practice, attachments that are disallowed or are found to be malware carriers can be stripped before the attachment is forwarded to the mailbox server. In the case of 0-day threats, attachment configuration can be modified to add specific attachment types if they are known to be associated with a newly devised attack.
For Microsoft E-Mail services, attachments are controlled by the E-mail client applications, in this case OWA or Outlook. The attachment file types list should be coordinated among other Microsoft client applications, such as OWA or Outlook, and with other E-mail services that may act upon message attachments, such as a perimeter-based attachment filter used by a non-Microsoft product. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-030BE</Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>Mitigation: None available. Exchange 2003 mailbox server does not offer the ability to perform attachment filtering. </MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Procedure: Deploy attachment filtering at the perimeter on an Edge Transport Server (E-mail Secure Gateway) that supports attachment filtering.
The following list suggests the minimum attachments that should be disallowed. Exceptions should be documented in the System Security Plan explaining the reason for addition or removal. As well, attachment filtering lists should align with client application direction such as Microsoft Outlook and Microsoft Outlook Web Access (OWA) or other platforms that perform attachment filtering.
For Level1FileTypes:
Value Data: ade, adp, app, asx, bas, bat, chm, cmd, com, cpl, crt, csh, exe, fxp, hlp, hta, inf, ins, isp, js, jse, ksh, lnk, mda, mdb, mde, mdt, mdw, mdz, msc, msi, msp, mst, ops, pcd, pif, prf, prg, reg, scf, scr, sct, shb, shs, url, vb, vbe, vbs, wsc, wsf, wsh
For Level2FileTypes:
Value Data: ade, adp, asx, bas, bat, chm, cmd, com, cpl, crt, exe, hlp, hta, htm, html, htc, inf, ins, isp, js, jse, lnk, mda, mdb, mde, mdz, mht, mhtml, msc, msi, msp, mst, pcd, pif, prf, reg, scf, scr, sct, shb, shs, shtm, shtml, stm, url, vb, vbe, vbs, wsc, wsf, wsh, xml, dir, dcr, plg, spl, swf
Interview the E-mail Administrator or the IAO. Review documentation that describes attachment filtering at the perimeter, as performed by the Edge Transport Server (E-mail Secure Gateway).
Criteria: If E-mail attachments are filtered by an Edge Transport Server (E-mail Secure Gateway) at the perimeter, this is not a finding.
EMG2-030 Exch2K3FEE-mail servers are not protected by an Edge Transport Server role (E-mail Secure Gateway) removing disallowed message attachments at the network perimeter.<VulnDiscussion>By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the Mail server environment. Attachments have been known to carry malware, although the file type and malware types have changed over time.
Attachments must be controlled at the entry point into the E-mail environment to prevent successful attachment-based attacks. For outbound messages, the entry point is at E-mail creation, for example, in Outlook or Outlook Web Access (OWA). For inbound messages, it is at the perimeter. By using this practice, attachments that are disallowed or are found to be malware carriers can be stripped before the attachment is forwarded to the mailbox server. In the case of 0-day threats, attachment configuration can be modified to add specific attachment types if they are known to be associated with a newly devised attack.
For Microsoft E-Mail services, attachments are controlled by the E-mail client applications, in this case OWA or Outlook. The attachment file types list should be coordinated among other Microsoft client applications, such as OWA or Outlook, and with other E-mail services that may act upon message attachments, such as a perimeter-based attachment filter used by a non-Microsoft product. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Create attachment control by ensuring the registry is populated with attachment file extensions to meet at least the default recommended list, with differences documented and approved by the IAO. Ensure that the OWA list aligns with the Outlook list on the desktop for consistency in attachment control for both client platforms.
Procedure: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: Level1FileTypes
Type: REG_SZ
Value: Level1FileTypes
Value Data: ade, adp, app, asx, bas, bat, chm, cmd, com, cpl, crt, csh, exe, fxp, hlp, hta, inf, ins, isp, js, jse, ksh, lnk, mda, mdb, mde, mdt, mdw, mdz, msc, msi, msp, mst, ops, pcd, pif, prf, prg, reg, scf, scr, sct, shb, shs, url, vb, vbe, vbs, wsc, wsf, wsh
Value: Level2FileTypes
Value Data: ade, adp, asx, bas, bat, chm, cmd, com, cpl, crt, exe, hlp, hta, htm, html, htc, inf, ins, isp, js, jse, lnk, mda, mdb, mde, mdz, mht, mhtml, msc, msi, msp, mst, pcd, pif, prf, reg, scf, scr, sct, shb, shs, shtm, shtml, stm, url, vb, vbe, vbs, wsc, wsf, wsh, xml, dir, dcr, plg, spl, swf
Access the server registry to review settings for OWA attachment control. The defaults are listed here for convenience and format guidance; however, site variations may exist. Variations should be identified in the System Security Plan (for example, if .zip files are temporarily prevented due to a specific attack). In general, attachment specifications should align between OWA and Outlook on the desktop, to provide consistency.
Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: Level1FileTypes
Type: REG_SZ
Value Data: ade, adp, app, asx, bas, bat, chm, cmd, com, cpl, crt, csh, exe, fxp, hlp, hta, inf, ins, isp, js, jse, ksh, lnk, mda, mdb, mde, mdt, mdw, mdz, msc, msi, msp, mst, ops, pcd, pif, prf, prg, reg, scf, scr, sct, shb, shs, url, vb, vbe, vbs, wsc, wsf, wsh
HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: Level2FileTypes
Type: REG_SZ
Value Data: ade, adp, asx, bas, bat, chm, cmd, com, cpl, crt, exe, hlp, hta, htm, html, htc, inf, ins, isp, js, jse, lnk, mda, mdb, mde, mdz, mht, mhtml, msc, msi, msp, mst, pcd, pif, prf, reg, scf, scr, sct, shb, shs, shtm, shtml, stm, url, vb, vbe, vbs, wsc, wsf, wsh, xml, dir, dcr, plg, spl, swf
Attachments listed should be separated by a comma with no space.
Criteria: If E-mail attachment control is specified to at least the default level, with differences documented, this is not a finding.
EMG2-340 Mailboxes Retained Until Backup Complete<GroupDescription></GroupDescription>EMG2-340 Exch2K3Mailboxes and messages are not retained until backups are complete. <VulnDiscussion>Backup and recovery procedures are an important part of overall system availability and integrity. Complete backups reduce the chance of accidental deletion of important information, and ensure that complete recoveries are possible.
It is not uncommon for users to receive and delete messages in the scope of a single backup cycle. This setting ensures that at least one backup has been run on the mailbox store before the message physically disappears. By enabling this setting, all messages written to recipients who have accounts on this store will reside in backups even if they have been deleted by the user before the backup has run.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure messages and mailboxes for backups.
Procedure: Exchange System manager >>Administrative Groups >> [administrative group] >> Servers >> [server name]>> [storage group] >> Mailbox store [server name] >> Properties >> Limits tab >> Deletion settings
Select “Do not permanently delete mailboxes and items until the store has been backed up”.
Ensure that mailbox retention for backups are complete.
Procedure: Exchange System Manager >>Administrative Groups >> [administrative group] >> Servers >> [server name]>> [storage group] >> Mailbox store [server name] >> Properties >> Limits tab >> Deletion settings
The “Do not permanently delete mailboxes and items until the store has been backed up” should be selected.
Criteria: If “Do not permanently delete mailboxes and items until the store has been backed up” is selected, this is not a finding.
EMG2-344 Public Retained Until Backup Complete<GroupDescription></GroupDescription>EMG2-344 Exch2K3Public Folder stores and documents are not retained until backups are complete. <VulnDiscussion>Backup and recovery procedures are an important part of overall system availability and integrity. Complete backups reduce the chance of accidental deletion of important information, and ensure that complete recoveries are possible.
It is not uncommon for users to receive and delete documents in the scope of a single backup cycle. This setting ensures that at least one backup has been run on the folder store before the message physically disappears. By enabling this setting, all messages written to recipients who have accounts on this store will reside in backups even if they have been deleted by the user before the backup has run.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure Public Folders for Backups.
Procedure: Exchange System manager >>Administrative Groups >> [administrative group] >> Servers >> [server name]>> [storage group] >> Public Folder store [server name] >> Properties >> Limits tab >> Deletion settings
Select “Do not permanently delete mailboxes and items until the store has been backed up”.
Valiate that Public Folders are retained until Backups are run.
Procedure: Exchange System manager >>Administrative Groups >> [administrative group] >> Servers >> [server name]>> [storage group] >> Public Folder store [server name] >> Properties >> Limits tab >> Deletion settings
The “Do not permanently delete Public Folders until the store has been backed up” should be selected.
Criteria: If “Do not permanently delete Public Folders until the store has been backed up” is selected, this is not a finding.
EMG2-307 Mailbox Overwrite Protection - Restore<GroupDescription></GroupDescription>EMG2-307 Exch2K3Mailbox Stores Restore Overwrite is enabled. <VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. Unauthorized or accidental restoration of mailbox data risks data loss or corruption.
This setting controls whether the mailbox store can be overwritten by a backup, which will cause loss of all information added after the backup was created. It should only be enabled during maintenance windows or following an outage (immediately before a restore is to be made), and cleared again immediately afterwards.
During production windows, this setting must be disabled. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Ensure that Mail Store Restore Overwrite Protection is enabled.
Procedure: Exchange System manager >>Administrative Groups >> [administrative group] >> servers >> [server name]>> [storage group] >> Mailbox store [server name] >> properties >> database tab
Clear the “This database can be overwritten by a restore” checkbox.
Ensure that Mail Stores Restore Overwrite is enabled.
Procedure: Exchange System manager >>Administrative Groups >> [administrative group] >> servers >> [server name]>> [storage group] >> Mailbox store [server name] >> properties >> database tab
The “This database can be overwritten by a restore” checkbox should be cleared.
Criteria: If “This database can be overwritten by a restore” checkbox is cleared, this is not a finding.
EMG2-311 Public Overwrite Protection - Restore<GroupDescription></GroupDescription>EMG2-311 Exch2K3Public Folder Stores Restore Overwrite is enabled. <VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. Unauthorized or accidental restoration of public folder data risks data loss or corruption.
This setting controls whether the public folder store can be overwritten by a restore from backup, which will cause loss of all information added after the backup was created. It should only be enabled during maintenance windows or following an outage (immediately before a restore is to be made), and cleared again immediately afterwards.
During production windows, this setting must be disabled. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Ensure that Public Folders Restore Overwrite Protection is enabled.
Procedure: Exchange System manager >>Administrative Groups >> [administrative group] >> servers >> [server name]>> [storage group] >> Public Folder store [server name] >> properties >> database tab
Clear the “This database can be overwritten by a restore” checkbox.
Ensure that Public Folder Restore Overwrite Protection is enabled.
Procedure: Exchange System manager >>Administrative Groups >> [administrative group] >> servers >> [server name]>> [storage group] >> Public Folder store [server name] >> properties >> database tab
The “This database can be overwritten by a restore” checkbox should be cleared.
Criteria: If “This database can be overwritten by a restore” checkbox is cleared, this is not a finding.
EMG2-317 E-mail Archive All Messages<GroupDescription></GroupDescription>EMG2-317 Exch2K3E-mail message copies are not archived. <VulnDiscussion>For E-mail environments with sufficiently sensitive requirements (either legal or data classification), local e-mail policy may require that all messages sent or received from a given server be preserved. If local policy requires it for historical or litigation purposes, this feature enables Exchange 2003 to retain a full copy of each message that is received by or sent from this mailbox store.
Additional setup is also needed, in that a user, distribution list, contact, or Public Folder to whom all messages will be copied, must be selected. Also known as “Journaling”, this setting is used to provide a “paper trail” of all correspondence that passes through the server. Journaled messages should always be stored on a separate dedicated journaling server, with protections similar to those granted log and audit files. The System Security plan should document the remote location, user account, and mailbox store that is used to host the message copy data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure Message Archiving.
Procedure: Exchange System manager >>Administrative Groups >> [administrative group] >> servers >> [server name]>> [storage group] >> Mailbox store [server name] >> properties >> General tab
Select the “Archive all message sent or received by mailboxes on this store” check box.
For sites that do not require full E-Mail Message Archiving, this check is N/A.
Procedure: Exchange System manager >>Administrative Groups >> [administrative group] >> servers >> [server name]>> [storage group] >> Mailbox store [server name] >> properties >> General tab
The “Archive all message sent or received by mailboxes on this store” should be checked.
Criteria: If “Archive all message sent or received by mailboxes on this store” is checked, this is not a finding.EMG3-115 E-mail dedicated partition<GroupDescription></GroupDescription>EMG3-115 Exch2K3E-mail application installation is sharing a partition with another application.<VulnDiscussion>In the same way that added security layers can provide a cumulative positive effect on security posture, multiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to the host system can most likely lead to a compromise of all applications hosted by the same system.
E-Mail services should be installed to a descrete set of directories, on a partition that does not host other applications. E-Mail services should never be installed on a Domain Controller / Directory Services server.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>DCPA-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Procedure: Install E-mail services on dedicated partitions. E-mail services software must not share a directory or partition with other software or the host operating system. Interview the E-mail Administrator.
Procedure: Start >> Programs >> All Programs.
Review all the programs listed to ensure that no E-mail servers, office programs, database programs, etc., are installed. If they are, ask the E-mail Administrator about their function and purpose.
Criteria: If E-mail services reside on dedicated directories or partitions and do not co-host other applications (without associated approval from the IAO), this is not a finding.EMG3-823 E-mail Logs and Audit Data Locations<GroupDescription></GroupDescription>EMG3-823 Exch2K3Audit data is sharing directories or partitions with the E-mail application.<VulnDiscussion>Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Audit log content must always be considered sensitive, and in need of protection.
Successful exploit of an application server vulnerability may well be logged by monitoring or audit processes when it occurs. By writing log and audit data to a separate directory or partition where separate security contexts protect them, it offers the ability to protect this information from being modified or removed by the exploit mechanism. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>DCPA-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Specify different host system disk partitions or directories for Exchange log files.
Procedure: Exchange System manager >>Administrative Groups >> [administrative group] >> Servers >> [server name]>> Properties >> General tab
Choose a location other than the default of "%systemroot%\program files\exchangesvr\servername.log" for the log file location.
Verify that audit file location is in a different directory than the default, or on a different partition than the default.
Procedure: Exchange System manager >>Administrative Groups >> [administrative group] >> servers >> [server name]>> Properties >> general tab
The location should not be the default of %systemroot%\program files\exchangesvr\servername.log. (where servername is the actual name of the server being reviewed.
Criteria: If E-mail logs or audit data are configured to a location other than the default of %systemroot%\program files\exchangesvr\servername.log this is not a finding. EMG1-110 Web E-mail Port/Protocol Compliance<GroupDescription></GroupDescription>EMG1-110 Exch2K3E-mail web applications are operating on non-standard ports. <VulnDiscussion>PPSM Standard defined ports and protocols must be used for all Exchange services. The standard port for HTTP connections is 80 and the standard port for HTTPS
Connections is 443.
Changing the ports to non-standard values provides only temporary and limited protection against automated attacks since these attacks will not likely connect to the custom port. However, a determined attacker may still be able to determine which ports are used for the HTTP and HTTPS protocols by performing a comprehensive port scan.
Negative impacts to using nonstandard ports include complexity for the system administrator, custom configurations for connecting clients, risk of port conflict with non-exchange applications, and risk of incompatibility with standard port monitoring applications. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>DCPP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Procedure: Enter Web compliant ports and protocols.
IIS Manager >> [server name]>>Web Sites >> Default Web Site >>Properties >> Web Site Tab >> Web site identification >> TCP port and SSL port
Enter 80 for TCP port and 443 for SSL port.
Verify that E-mail services are deployed on compliant ports and protocols
Procedure: IIS Manager >> [server name]>>Web Sites >> Default Web Site >>Properties >> Web Site tab >> Web site identification >> TCP port and SSL port
Port 80 for TCP and port 443 for SSL should be entered.
Criteria: If Port 80 for TCP and port 443 for SSL is entered, this is not a finding. EMG2-105 SMTP Port/Protocol Compliance<GroupDescription></GroupDescription>EMG2-105 Exch2K3E-mail SMTP services are using Non-PPSM compliant ports. <VulnDiscussion>Standard defined ports and protocols should be used for all Exchange services.
The standard port for regular SMTP connections is 25.
Changing the ports to non-standard values provides only temporary and limited protection against automated attacks since these attacks will not connect to the custom port. A determined attacker may still be able to determine which ports are used for the SMTP by performing a comprehensive port scan
Negative impacts of using non-standard ports include complexity for the system administrator, custom configurations for connecting clients, risk of port conflict with non-exchange applications, and risk of incompatibility with standard port monitoring applications.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>DCPP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Enter the SMTP compliant ports.
Procedure: Exchange system manager >> administrative groups >> [administrative groups]>>Servers >> [server]>>Protocols >> SMTP >> [specific SMTP server] >> Properties >> Delivery Tab >> Outbound Connections button >> TCP Port
For SMTP, enter 25.
Verify that SMTP services are deployed on compliant ports and protocols.
Procedure: Exchange system manager >> administrative groups >> [administrative groups]>>Servers >> [server]>>Protocols >> SMTP >> [specific SMTP server] >> Properties >> Delivery Tab >> Outbound connections button >> TCP Port
For SMTP, port 25 should be entered.
Criteria: If 25 is entered for the SMTP port, this is not a finding.
EMG2-109 SMTP Virtual Server Port Assignment<GroupDescription></GroupDescription>EMG2-109 Exch2K3SMTP Virtual Server is not bound to the PPSM Standard Port.<VulnDiscussion>PPSM Standard defined ports and protocols must be used for all Exchange services.
The default port for SMTP connections is 25.
Changing the ports to non-standard values provides only temporary and limited protection against automated attacks since these attacks will not likely connect to the custom port. A determined attacker may still be able to determine which ports are used for the SMTP by performing a comprehensive port scan.
Negative impacts of using non-standard ports include complexity for the system administrator, custom configurations required for connecting clients, risk of port conflict with non-exchange applications, and risk of incompatibility with port monitoring applications. Since changing the port introduces a large amount of complexity for a relatively small gain, the DoD PPSM requires that standard SMTP ports be used.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>DCPP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Enter 25 for SMTP on each SMTP Virtual Server
Procedure: Exchange system manager >> administrative groups >> [administrative groups]>>Servers >> [server]>>Protocols >> SMTP >> [specific SMTP server] >> properties >> General Tab >> Advanced >>Edit>> TCP Port
Enter 25 for SMTP.
Verify that E-mail Virtual server is bound on SMTP port 25.
Procedure: Exchange system manager >> administrative groups >> [administrative groups]>>Servers >> [server]>>Protocols >> SMTP >> [specific SMTP server] >> properties >> General Tab >> Advanced >>Edit>> TCP Port
Port 25 for SMTP should be entered.
Criteria: If 25 is entered for SMTP, this is not a finding.
EMG3-058 E-mail Software Monitored for Change<GroupDescription></GroupDescription>EMG3-058 Exch2K3E-mail software is not monitored for change on INFOCON frequency schedule.<VulnDiscussion>The INFOCON system provides a framework within which the Commander USSTRATCOM regional commanders, service chiefs, base/post/camp/station/vessel commanders, or agency directors can increase the measurable readiness of their networks to match operational priorities. The readiness strategy provides the ability to continuously maintain and sustain one’s own information systems and networks throughout their schedule of deployments, exercises and operational readiness life cycle independent of network attacks or threats. The system provides a framework of prescribed actions and cycles necessary for reestablishing the confidence level and security of information systems for the commander and thereby supporting the entire Global Information Grid (GIG) (SD 527-1 Purpose).
The Exchange software files and directories as well as the files and directories of dependent applications are vulnerable to unauthorized changes if not adequately protected. An unauthorized change could affect the integrity or availability of e-mail services overall. For this reason, all application software installations must monitor for change against a software baseline that is preserved when installed, and updated periodically as patches or upgrades are installed. Automated and manual schedules for software change monitoring must be compliant with SD527-1 frequencies. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>DCSL-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Procedure: Establish procedures to monitor any changes made to E-mail Services software. Identify files and directories to be included in the host system and provide these to the person responsible for backups. Verify that E-mail software libraries are monitored for change according to SD527-1 INFOCON levels. Verify the software change monitoring schedule.
Procedure: Interview the E-Mail Administrator or IAO to ascertain current INFOCON level history, and ask for software modification detection procedures in place. Review reports for inclusion of the Exchange 2003 executable and configuration files.
Criteria: If E-mail software is monitored for changes as required by the INFOCON levels, this is not a finding. EMG3-802 E-mail Support Data Separation <GroupDescription></GroupDescription>EMG3-802 Exch2K3Security support data or process is sharing a directory or partition with Exchange. <VulnDiscussion>The Security Support Structure is a security control function or service provided by an external system or application. For example, a Windows Domain Controller that provides Identification and Authentication Services (Active Directory) may be at risk of compromise if a co-resident application becomes compromised. The attacker can then use another system to control access to other parts of the domain.
The vulnerabilities and associated risk of Exchange 2003 installed on a system that provides a security support structure is significantly higher than when installed with other functions that do not provide security support. For this reason, applications such as Exchange 2003 should never be co-resident on a server with Active Directory. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>DCSP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Procedure: Install Exchange 2003 application to a dedicated host system. Review documentation and the E-mail host servers.
Procedure: Interview the E-mail Administrator or the IAO. Access System Security Plan documenation and the server being reviewed. Verify that Exchange 2003 is not installed on a Domain Controller or other Directory Services server.
Criteria: If Exchange E-mail application is installed on a server that separate from domain security services, this is not a finding.
EMG3-805 E-mail Software Baseline<GroupDescription></GroupDescription>EMG3-805 Exch2K3Exchange software baseline copy does not exist. <VulnDiscussion>Exchange 2003 software, as with other application software installed on a host system, must be included in a system baseline record and periodically reviewed, otherwise unauthorized changes to the software may not be discovered. This effort is a vital step to securing the host and the applications, as it is the only method that may provide the ability to detect and recover from otherwise undetected changes, such as those that result from worm or bot intrusions.
The Exchange 2003 software and configuration baseline is created and maintained for comparison during scanning efforts. Operational procedures must include baseline updates as part of configuration management tasks that change the software and configuration. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>DCSW-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Procedure: Implement E-mail software baseline process. Ensure that a plan exists for periodic comparison and is incorporated into the configuration management procedures. Interview the E-Mail Administrator or the IAO. Reference a copy of the System Security Plan.
Procedure: Review the application software baseline procedures and implementation evidence. Review the list of files and directories included in the baseline procedure for completeness.
Criteria: If E-mail software copy exists to serve as a baseline and is available for comparison during scanning efforts, this is not a finding. EMG2-327 Public Server Requires S/MIME Client<GroupDescription></GroupDescription>EMG2-327 Exch2K3E-mail Public Folders do not require S/MIME capable clients. <VulnDiscussion>Identification and Authentication provide the foundation for access control. The ability for receiving users to authenticate the source of Public Folder messages helps to ensure that they are not FORGED or SPOOFED before they arrive.
MIME (Multipurpose Internet Mail Extensions) is an Internet standard that extends the format of E-mail and other web content to support ASCII and other character sets in both the message and header, text and non-text attachments, and multi-part message bodies. All human-originating E-Mail messages are transmitted in MIME format.
S/MIME (Secure / Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of e-mail encapsulated in MIME. Participants in S/MIME message exchanges must obtain and install an individual key/certificate from the DoD. S/MIME clients will require that each participant own a certificate before allowing message encrypting to others.
To minimize attack vectors revealed by lack of signed or encrypted documents, all clients in the enterprise must be updated to support S/MIME, and all mail servers must require S/MIME capability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Require S/MIME capable clients.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> servers >> [server name] >> [storage group] >> Public Folder store [server name] >> properties >> General tab
Select the “clients support S/MIME signatures” checkbox. If Public Folders are not in use at the site, this is N/A.
Ensure that Public Folders require S/MIME capable clients.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server name] >> [storage group] >> Public Folder store [server name] >> Properties >> General tab
The “clients support S/MIME signatures” should be selected.
Criteria: If “clients support S/MIME signatures” is selected, this is not a finding.
EMG2-271 Forms-Based Authentication<GroupDescription></GroupDescription>EMG2-271 Exch2K3OWA Virtual Server has Forms-Based Authentication enabled. <VulnDiscussion>Identification and Authentication provide the foundation for access control. Access to E-Mail services applications in the DoD require authentication using DoD Public Key Infrastructure (PKI) certificates. The Exchange Virtual Server, which operates Outlook Web Access (OWA), is used to enable web access to user E-mail mailboxes. This setting controls whether Forms-based login should be used by the OWA web site.
Forms-based login enables a user to enter an Account and Password for the web session. The form stores the username and password information in browser cookies, and enables the user’s mailbox server to be located without user participation. The cookies persist throughout the OWA session after which they are destroyed.
Because the DoD requires Common Access Card (CAC)-based authentication to applications, OWA access must be brokered through a an application proxy (for example, Internet Security and Acceleration [ISA]), which performs CAC authentication using a proxy-hosted OWA form. The authenticated request is then forwarded directly to OWA, where authentication is repeated without requiring the user to repeat authentication steps. For this scenario to work, the Application Proxy server is must have Forms-based authentication enabled, and Exchange 2003 must have Forms-based Authentication disabled.
If Forms-based Authentication is enabled on the Exchange 2003 Front End server, it is evidence that the application proxy server is either not correctly configured, or it may be missing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>IATS-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure Forms-based Authentication.
Procedure: Exchange system Manager >> Administrator Groups>> [administrator group]>>Servers>> [server name]>>Protocols>>HTTP>Exchange Virtual Server >> Properties >> Settings tab
Clear the “Enable Forms-based Authentication” checkbox.
Note: This configuration presumes that an application proxy server such as Internet Security and Acceleration (ISA) 2006 is installed between the Internet and the Client Access Server to host the authentication form. Ensure that 'Forms-based' authentication is not active.
Procedure: Exchange system Manager >> Administrator Groups>> [administrator group]>>Servers>> [server name]>>Protocols>>HTTP>Exchange Virtual Server >> Properties >> Settings tab
The “Enable Forms-based Authentication” checkbox should be cleared.
Criteria: If the “Enable Forms-based Authentication” checkbox is cleared, this is not a finding. EMG1-007 HTTP Authenticated Access Default<GroupDescription></GroupDescription>EMG1-007 Exch2K3Default web site allows anonymous access. <VulnDiscussion>The Default Web site is the virtual server on which all Exchange virtual directories reside. This feature controls the authentication method used to connect to this virtual server and its virtual directories.
Ensure that this is set to Integrated Windows Authentication only. Anonymous access
provides for no access control of this virtual server, Basic Authentication transmits the password in the clear and risks exposure, and the other methods are not recommended by Microsoft for this control. Failure to configure this as per the recommendation may result in unrestricted access to this virtual server, passwords being sent in the clear, and/or the inability to correctly authenticate, depending on which change is made.
Because CAC authentication will be required and configured via a proxy server such as ISA, settings in this area must assume the presence of an application proxy (such as ISA) between the Public Internet and the Exchange Client Access (Front End) server role.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>IAIA-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Ensure that default authentication is set appropriately.
Procedure: IIS Manager >> [server name] >> Websites>>Default Web Site>> Properties >> Directory Security tab>>Authentication and Access Control>>Edit button
Select the "Integrated Windows Authentication" checkbox.Verify the default web site authentication type for Exchange access.
Procedure: IIS Manager >> [SERVER NAME] >> Websites>>Default Web Site>> Properties >> Directory Security tab>>Authentication and Access Control>>Edit button
Ensure that "Integrated Windows Authentication" is selected.
Criteria: If "Integrated Windows Authentication" is selected, this is not a finding. EMG2-256 OWA Virtual Directory Authentication<GroupDescription></GroupDescription>EMG2-256 Exch2K3OWA does not require only Integrated Windows Authentication. <VulnDiscussion>Identification and Authentication provide the foundation for access control. Access to E-mail services applications in the DoD require authentication using DoD Public Key Infrastructure (PKI) certificates.
The Exchange Virtual Server, which controls Outlook Web Access (OWA), is used to link Web Access for user E-mail accounts to the Exchange Mailbox store. OWA is designed to provide much of the same functionality provided by using an Outlook client, but through a web browser. This setting controls the authentication method used to connect to this virtual server.
OWA does not natively provide Common Access Card (CAC)-Authentication ability. For this reason, access to OWA must be brokered by an application proxy authentication point where CAC (certificate) authentication is available for Internet-based access to E-Mail services. It is the proxy server that must authenticate the user’s membership in domain directory services (for example, Microsoft Active Directory) before establishing an authenticated connection to the OWA server. For this reason, only Integrated Windows Authentication should be selected as the authentication method at this point in the process. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>IAIA-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure OWA Virtual Server Authentication.
Procedure: Exchange system Manager >> Administrator Groups>> [administrator group] Servers>> [server name]>>Protocols>>HTTP>Exchange Virtual Server>>Exchange>>Properties>>Access Tab>>Authentication Settings>>Authentication Button
Select "Integrated Windows Authentication".
Validate OWA Authentication Setting:
Procedure: Exchange system Manager >> Administrator Groups>> [administrator group] Servers>> [server name]>>Protocols>>HTTP>Exchange Virtual Server>>Exchange>>Properties>>Access Tab>>Authentication Settings>>Authentication Button
"Integrated Windows Authentication" should be selected.
Criteria: If "Integrated Windows Authentication" is selected, this is not a finding. EMG2-133 SMTP Server Valid Certificate<GroupDescription></GroupDescription>EMG2-133 Exch2K3One or more SMTP Virtual Servers do not have a Valid Certificate. <VulnDiscussion>Server certificates are required for many security features in Exchange, and without them the server cannot engage in many forms of secure communication.
Certificates must be manually installed on each virtual server. This means that installing a certificate on one SMTP Virtual Server does not give other SMTP Virtual Servers (or virtual servers of any other protocol) access to this certificate. However, once a certificate is installed on one virtual server, any other virtual server (regardless of protocol used) may easily be configured to use this certificate by selecting “Assign an existing certificate” in the first page of the Wizard.
Install certificates on this virtual server. Without it, many other recommendations in this
document concerning secure communication will be impossible. For highest security
assurance, each virtual server should have its own certificate that it does not share with other servers. This reduces the damage due to server compromises and provides per-server identification.
Failure to implement this recommendation makes it virtually impossible to secure Exchange's communications. Use of any virtual server that has not been given a certificate should be considered a highly insecure action.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>IAKM-2</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Obtain vaid DoD server certificates for SMTP services. For each SMTP virtual server, install a certificate.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >> Access Tab >> Secure Communication Tab
Select the “Wizard” button to install the certificate.
Validate that Virtual Server certificates are installed for each SMTP Virtual Server.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> Properties >> Access tab >> Secure Communication tab
Select the “Wizard” button to create and install a certificate. View the certificate details.
Criteria: If the SMTP virtual servers have a valid DoD-Issued certificate, this is not a finding.
EMG2-840 E-mail Audit Record Content<GroupDescription></GroupDescription>EMG2-840 Exch2K3Audit Records do not contain all required fields. <VulnDiscussion>Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. This item declares the fields that must be available in audit log file records in order to adequately research events that are logged.
Audit records should include the following fields to supply useful event accounting:
• Account
• Event Code and Type
• Success or Failure Indication
• Time/date
• Interface IP address
• Manufacturer-specific event name
• Source and destination IP addresses
• Source and destination port numbers
• Network Protocol</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECAR-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Ensure that E-mail audit records contain required fields, to the degree that Exchange 2003 is able to provide them.
Procedure: If logging levels are available that increase reported information, they should be used. Interview the e-mail administrator or IAO. Access the Exchange 2003 Server log files. Review log file examples.
Criteria: If E-mail audit records contain required events:
• Account
• Event Code and Type
• Success or Failure Indication
• Time/date
• Interface Internet Protocol (IP) address
• Manufacturer-specific event name
• Source and destination IP addresses
• Source and destination port numbers
• Network Protocol
This is not a finding. EMG2-833 Server Monitoring – Do Not Disable <GroupDescription></GroupDescription>EMG2-833 Exch2K3The “Disable Server Monitoring” feature is enabled.<VulnDiscussion>Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed. This setting controls whether all monitoring processes on this server are enabled or disabled.
Monitoring should never be disabled on the server during production hours. The processing cycles needed for monitoring should be incorporated into server sizing. If the configuration disables monitoring, it stops Exchange's built in safety checks to warn the administrators of malfunctions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECAR-2</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure monitoring.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab
Clear the “Disable Monitoring of this server” checkbox.
Review Exchange Monitoring.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> Properties >> Monitoring tab
The “Disable monitoring of this server” checkbox should be clear.
Criteria: If the “Disable monitoring of this server” checkbox is cleared, this is not a finding.EMG2-124 Audit SMTP Virtual Server <GroupDescription></GroupDescription>EMG2-124 Exch2K3SMTP Virtual Server Auditing is not active.<VulnDiscussion>Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. This setting controls the creation and format of log files used to monitor the interaction between this SMTP Virtual Server and other SMTP hosts. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECAT-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure SMTP Virtual Server auditing.
Procedure: Exchange System Manger >> Administrative Groups >> [administrative group}>> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> General tab
Select the “Enable Logging” checkbox.
Ensure that SMTP Virtual Server Auditing is active.
Procedure: Exchange System Manger >> Administrative Groups >> [administrative group}>> Servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> General tab
The “Enable Logging” checkbox should be checked.
Criteria: If the “Enable Logging” checkbox is checked, this is not a finding. EMG2-111 SMTP VS Authentication - Perimeter<GroupDescription></GroupDescription>EMG2-111 Exch2K3Exchange Server is not protected by an Edge Transport Server (E-mail Secure Gateway) that performs Anonymous Connections interaction with Internet-based E-mail servers. <VulnDiscussion>E-mail is only as secure as the recipient. By ensuring secured connections for all Simple Mail Transfer Protocol (SMTP) servers along the message transfer path, risk of “Anonymous” message transfers by rogue servers is reduced. If all message transfers were authenticated from server to server, most SPAM would be eliminated, because anonymous spammers would be more readily traceable.
However, the ability to authenticate a sender from another domain will not be possible until a common authentication method exists between the receiving domain and all of the sending domains that might wish to correspond. For that reason, the Edge Transport Server role (E-Mail Secure Gateway) should be the only role enabled for Anonymous connections (because it will also perform the sanitization steps) and all internal E-mail application server roles must authenticate to each other.
This setting controls the authentication method required to allow connection and message transfer to this virtual server (recipient). Authentication options include Anonymous, Basic authentication (with clear text password), and Integrated Windows Authentication.
Anonymous requires no authentication, and is therefore not acceptable. NT Lan Manager, or NTLM, (Integrated Windows Authentication checkbox) is negotiated, does not provide encryption of message bodies, and cannot sufficiently secure the connection in Exchange 2003. Risks include the potential of allowing message content to be sniffed over the wire.
"Basic authentication" and "Require SSL/TLS" should be selected in this panel. The use of SSL/TLS not only protects the username and password during authentication, but encrypts the mail messages as they are being transmitted, preventing eavesdroppers from reading messages. All Exchange 2003 servers should belong to this category.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-111</Mitigations><SeverityOverrideGuidance>Severity can be overridden to Category III if terms of the mitigation are met by configuring this
SPAM protection on an Exchange Server processing inbound messages.</SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>Exchange servers deployed at sites without an Edge Transport Server (E-mail Secure Gateway) role may need to receive inbound connections from remote domains using anonymous connections. If this situation exists, anonymous connections should be confined to one or more servers that perform E-mail sanitization steps on the same server before forwarding the messages to the Mailbox server role.
For these sites, "Anonymous" security (with TLS) may be configured on the MTA server role (Exchange 2003 Bridgehead server) or the Exchange 2003 Mailbox Server where SMTP virtual server receives connections from external mail servers. Note: This mitigation is necessary when no secure e-mail gateway server exists; however, it does not qualify as closing the open finding for perimeter protection.
For each SMTP virtual server that connects to an external E-mail domain, set authentication on the SMTP Virtual Server.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> Access tab >> Access Control >> Authentication button
Select “Basic authentication” and "Anonymous", with TLS encryption. </MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>EBBD-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Deploy an Edge Transport Server (E-mail Secure Gateway) role at the perimeter.
Then, for each Exchange 2003 SMTP virtual server (now internal to the enclave), set authentication.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> Access tab >>Access Control >> Authentication button
Select “Basic authentication” and "TLS encryption". Interview the IAO or E-mail Administrator. Access documentation that describes placement of an
E-mail Secure Gateway that receives inbound messages from Internet-based remote domains.
Verify the Exchange 2003 connector authentication configuration.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> servers >> [server] >> Protocols >> SMTP >> [specific SMTP server] >> properties >> Access tab >> Access Control >> Authentication button
“Basic authentication” with "TLS" should be selected.EMG2-144 SMTP Virtual Server Connection Security<GroupDescription></GroupDescription>EMG2-144 Exch2K3SMTP Virtual Servers do not Require Secure Channels and Encryption. <VulnDiscussion>The Simple Mail Transfer Protocol (SMTP) Virtual Server is used by the Exchange System Manager to send and receive messages from server to server using SMTP protocol. This setting controls the encryption strength used for client connections to the SMTP Virtual Server. With this feature enabled, only clients capable of supporting secure communications will be able to send mail using this SMTP server. Where secure channels are required, 128 bit encryption can also be selected.
The use of secure communication prevents eavesdroppers from reading or modifying communications between mail clients and servers. While sensitive message bodies should be encrypted by the sender at the client, requiring a secure connection from the client to the server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.
Individually, channel security and encryption have been compromised by attackers. Used together, E-mail becomes a more difficult target, and security is heightened. Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between the client and server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECCT-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222For each SMTP virtual server, set secure connection as follows:
Exchange System Manager >> Administrative Groups >> [administrative group] >> servers >> [server] >> Protocols >> SMTP >> [specific SMTP virtual server] >> properties >> Access Tab >> Communication button
Select “Require secure channel” and “require 128 bit encryption” checkboxes.
Verify the SMTP virtual server connection security.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> servers >> [server] >> Protocols >> SMTP >> [specific SMTP virtual server] >> properties >> Access Tab >> Communication button
“Require secure channel” and “Require 128 bit encryption” checkboxes should be checked.
Criteria: If “Require secure channel” and “Require 128 bit encryption” are checked, this is not a finding. EMG2-743 SMTP Connector Outbound - Perimeter<GroupDescription></GroupDescription>EMG2-743 Exch2K3SMTP Connectors perform outbound anonymous connections. <VulnDiscussion>Identification and Authentication provide the foundation for access control. The key to preventing SPAM insertion into the SMTP message transfer path is to require authentication at each ‘hop’ of the journey from sender to receiver. Failure to authenticate increases risk that an attacker can insert unauthenticated mail messages, a form of internally SPOOFED SPAM that can be difficult to trace. Encryption ensures confidentiality of data in motion as it traverses network connections. Failure to specify TLS encryption causes message transfer to be sent unencrypted, (including the authentication password), which makes it susceptible to eavesdropping.
This setting controls the authentication and encryption algorithms used for outbound connections using this connector. (That is, the authentication used when delivering outbound mail to another SMTP Virtual Server.)
When the SMTP connectors send messages from a locally controlled (internal to the organization) connector, Basic authentication and TLS should be used by the initiating end of the connection.
Because no Exchange 2003 servers should directly send to remote SMTP virtual servers, all SMTP outbound connectors should be secured in this way, including the outermost connectors, which should ideally be sending to an Edge Transport Server Role (E-mail Secure Gateway) at the enclave perimeter.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-743</Mitigations><SeverityOverrideGuidance>Severity can be overridden to Category II if terms of the mitigation are met by configuring this protection on an Exchange Server processing outbound messages where there is no E-Mail Secure Gateway at the perimeter. </SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>Because early Exchange 2003 servers may have been deployed as Internet-facing servers, some organizations may have SMTP connectors that must allow anonymous connections.
Both authentication and encryption require that the recipient of the outbound communication be capable of supporting the corresponding ID, password authentication and decryption steps. Connections to remote domains may not be securable in this way.
Anonymous connections may be allowed on the Exchange 2003 Bridgehead or Mailbox Server at sites where no Edge Transport Role Server (E-mail Secure Gateway) exists outside the enclave firewall, but only for connectors that must send to Internet-based remote domains. This configuration is preferred when no Edge Transport Role Server (E-mail Secure Gateway) is in use; however, it does not qualify as closing the open finding for perimeter protection.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Routing Groups >> [routing group] >> Connectors >> [SMTP Connector] >> Properties >> Advanced Tab >> Outbound Security button
Configure "Anonymous" and "TLS".
</MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECCT-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Implement perimeter protection in the form of an Edge Transport Role Server (E-mail Secure Gateway) that performs, among other protections, the ability to perform Anonymous connections to remote E-mail domains.
Configure outbound SMTP connectors.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Routing Groups>> [routing group]>>Connectors>> [SMTP connector]>> >>Properties >> Advanced tab>>Outbound Security button
For each connector, select “Basic Authentication” and “TLS”
Validate outbound connector security on Exchange servers.
Procedure: Exchange System Manager>>Administrative Groups>> [Administrative Group]>>Routing Groups>> [routing group]>>Connectors>> [SMTP connector]>> >>Properties >> Advanced tab >> Outbound Security button
The “Basic Authentication” and “TLS” choices should be selected.
Criteria: If “Basic Authentication” and “TLS” are selected, this is not a finding.
EMG1-103 Public Virtual Directory Security<GroupDescription></GroupDescription>EMG1-103 Exch2K3Public Folder access does not require secure channels and encryption. <VulnDiscussion>Failure to require secure connections on a web site increases the potential for unintended decryption and data loss. This setting controls whether client machines should be forced to use secure channels to communicate with this virtual directory. If this feature is enabled, clients will only be able to communicate with the directory if they are capable of supporting secure communication with the server. If secure channels are required, the server can also require the channel to be strongly secured by requiring Federal Information Processing Standard (FIPS) 140-2 encryption.
If Public Folders / Web is approved for use, secure channels and FIPS level encryption are required, as well as appropriate certificate setting. The use of secure communication prevents eavesdroppers from reading or modifying communications between servers and clients. The network and DMZ STIG identify criteria for OWA and Public Folder configuration in the network, including CAC enabled pre-authentication through an application firewall proxy, such as Microsoft ISA.
Note: if Public Folder is not approved for use, this control is not applicable and the Public Folder virtual directory should be removed to eliminate the possibility of attack through this vector.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECCT-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set Public Folders Web Security.
Procedure: IIS Manager>> [Server name]>>Web Sites>>Default Web Site >> PUBLIC >>Properties >> Directory Security tab >> Secure Communications >> Edit button
Select "Secure Channel" and "128 bit encryption". Under Client Certificates, select the “ignore client certificates” option. All other check boxes should be cleared.
If Public Folders are not in use at the site, the web directory should be deleted, and this check becomes N/A.
Validate Public Folder Web Security.
Procedure: IIS Manager>> [Server name]>>Web Sites>>Default Web Site >> PUBLIC >>Properties >> Directory Security tab >> Secure Communications >> Edit button
Secure Channel and 128 bit Encryption should be selected. Under "Client Certificates", the "ignore client certificates" option should be selected. All other checkboxes should be cleared.
Criteria: If "Secure Channel" and "128 bit Encryption" are selected, with "ignore client certificates", this is not a finding. EMG1-105 OWA Virtual Directory Security<GroupDescription></GroupDescription>EMG1-105 Exch2K3Outlook Web Access (OWA) does not require secure channels and encryption. <VulnDiscussion>Failure to require secure connections on a web site increases the potential for unintended decryption and data loss. This setting controls whether client machines should be forced to use secure channels to communicate with this virtual directory. If this feature is enabled, clients will only be able to communicate with the directory if they are capable of supporting secure communication with the server. If secure channels are required, the server can also require the channel to be strongly secure by requiring FIPS 140-2 encryption.
If Outlook Web Access is approved for use, secure channels and FIPS level encryption are required, as well as appropriate certificate setting. The use of secure communication prevents eavesdroppers from reading or modifying communications between servers and clients. The network and DMZ STIG identify criteria for OWA and Public Folder configuration in the network, including CAC enabled pre-authentication through an application firewall proxy, such as Microsoft ISA.
Note: if OWA is not approved for use, this control is not applicable and the OWA virtual directory should be removed to eliminate the possibility of attack through this vector.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECCT-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set Outlook Web Access security.
Proedure: IIS Manager>> [Server name]>>Web Sites>>Default Web Site >> Exchange >>Properties >> Directory Security tab >> Secure Communications >> Edit button
Select "Secure Channel" and "128 bit encryption". Under Client Certificates, select the “ignore client certificates” option. All other settings should be cleared.
If Outlook Web Access (OWA) is not approved for use at this site, this check is N/A.
Verify Exchange directory (OWA) security settings.
Procedure: IIS Manager>> [Server name]>>Web Sites>>Default Web Site >> Exchange >>Properties >> Directory Security tab >> Secure Communications >> Edit button.
"Secure Channel" and "128 bit encryption" should be selected. Under Client Certificates, the “ignore client certificates” option should be selected. All other settings should be cleared.
Criteria: If "Secure Channel" and "128 bit encryption" are selected, with the “ignore client certificates” option, this is not a finding. EMG2-305 ExAdmin Virtual Directory Security<GroupDescription></GroupDescription>EMG2-305 Exch2K3ExAdmin is configured for Secure Channels and Encryption. <VulnDiscussion>ExAdmin Virtual Directory is used by the Exchange System Manager to access mailboxes and Public Folders. Users do not directly access the ExAdmin Virtual Directory.
This feature controls the security setting used to determine whether client machines should be required to connect to this virtual directory using secure channels and encryption.
The services that use the ExAdmin Virtual Directory do not support the use of secure channels. Secure channels should not be configured on this virtual directory, as it will effectively disable the Exchange Mail and Public Folder functionality.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECCT-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure ExAdmin Security.
Procedure: IIS Manager>> [Server name]>>Web Sites>>Default Web Site >> ExAdmin >>Properties >> Directory Security Tab >> Secure Communications >> Edit Button
Clear all checkboxes.
Ensure that ExAdmin Virtual Directory is using correct security.
Procedure: IIS Manager>> [Server name]>>Web Sites>>Default Web Site >> ExAdmin >>Properties >> Directory Security Tab >> Secure Communications >> Edit Button
All checkboxes should be cleared.
Criteria: If all security checkboxes are cleared, this is not a finding.
EMG3-116 SMTP Automated Banner Response<GroupDescription></GroupDescription>EMG3-116 Exch2K3SMTP service banner response reveals configuration details.<VulnDiscussion>Automated connection responses occur as a result of FTP or Telnet connections, when connecting to those services. They report a successful connection by greeting the connecting client, stating the name, release level, and (often) additional information regarding the responding product. While useful to the connecting client, connection responses can also be used by a third party to determine operating system (OS) or product release levels on the target server. The result can include disclosure of configuration information to third parties, paving the way for possible future attacks.
For example, when querying the SMTP service on port 25, the default response looks similar to this one:
220 exchange.mydomain.org Microsoft ESMTP MAIL Service, Version: 6.0.3790.211 ready at Wed, 2 Feb 2005 23:40:00 -0500
Changing the response to hide local configuration details reduces the attack profile of the target. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECIC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Change the banner response text as follows:
CSCRIPT ADSUTIL.VBS get esmtpsvc/x/connectresponse "ESMTP"
Then, recycle the SMTP service by issuing the commands:
NET STOP SMTPSVC, followed by
NET START SMTPSVC.
Alternately, the value can be changed by accessing the Exchange user interface as follows:
Exchange System Manager >> Default SMTP Virtual Server >> Delivery >> Properties >>Advanced
Change the value to “ESMTP”.
Recycle the SMTP service:
NET STOP SMTPSVC, followed by
NET START SMTPSVC.
For each SMTP server (1 thru x) issue the following command:
CSCRIPT ADSUTIL.VBS get smtpsvc/x/connectresponse
(Where x is the relative number of SMTP virtual server identified on the machine).
Criteria: If a modified response is returned, for example: ESMTP …. (Time and date) message is returned, this is not a finding. EMG3-119 Service Accounts Restricted to a Service<GroupDescription></GroupDescription>EMG3-119 Exch2K3E-mail Services accounts are not restricted to named services.<VulnDiscussion>Applications introduce some of the most common database attack avenues, and can provide a pathway for an unlimited number of malicious users to access sensitive data. An account responsible for Service execution, if compromised, may subject the data to unauthorized exposure if it is granted more privileges than necessary.
Typically, service accounts must run only their designated services, and must not be shared with other applications or people. Audit Log Monitoring can then assume an ‘expected’ set of activities for each service account, and administrators can more readily recognize events that are unexpected. A discrete history of account activity is valuable if an attack of the host system needs to be investigated. If accounts are shared among multiple services or people, it increases the risk that firewall Administrators will not have an accurate history for investigation and troubleshooting purposes.
In the case of Microsoft Exchange Server 2003, attempting to run Exchange services on an alternate service account (rather than the default SYSTEM account) is not a supported Microsoft configuration. Due to the nature of the Exchange services access required within the server and the network, Exchange 2003 services must run under the Microsoft Windows SYSTEM account.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECLP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Ensure that E-mail services use only the SYSTEM account.
Procedure: Start >> Settings >> Control Panel >> Administrative Tools >> Services
For each "MS Exchange ..." service, look for Active Services in the list, Right Click >> Propterties >> LogOn tab
In the "Log On As" field, select "Local SYSTEM account".
Ensure the changes are reflected in the DIACAP Scorecard. Interview the E-mail Administrator or the IAO. Access the System Security Plan and verify the Exchange Services names active for the site.
View Exchange Services to verify service account scope.
Procedure: Start >> settings >> Control Panel >> Administrative tools >> Services
For each service beginning "MS Exchange…. "service, look for Active Services in the list:
Right Click >> Properties >> LogOn tab >> “Log on As” field.
Criteria: If E-mail service accounts are operating as SYSTEM, this is not a finding. EMG3-145 Service Accounts Least Privilege <GroupDescription></GroupDescription>EMG3-145 Exch2K3E-Mail service accounts are not operating at least privilege. <VulnDiscussion>Good security practice demands both the separation of duties and the assignment of least privilege. Role Based Access Control (RBAC) is the most accepted method for meeting these two criteria. A securely designed E-Mail Services implementation includes the definition of E-mail Roles (Servers and services, Users, Administrators, Installers) based on functional requirements for each, then assigning the fewest possible privileges to these roles. Roles are then assigned to people or services based on the application functions they are required to perform.
In the case of Microsoft Exchange Server 2003, attempting to run Exchange services on an alternate service account (rather than the default SYSTEM account) is not a supported Microsoft configuration. Due to the nature of the Exchange services access required within the server and the network, Exchange 2003 services must run under the Microsoft Windows SYSTEM account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECLP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Ensure that E-mail service accounts are operating with the SYSTEM account privilege.
Procedure:
Start >> settings >> control panel >> administrative tools >> services
For each "MSExch…." Active service in the list:
Right Click >> Properties >> LogOn >> Log On As field. Select "Local SYSTEM account".
View Exchange service permissions to verify service account privilege level.
Procedure: Start >> Settings >> Control Panel >> Administrative tools >> Services
For each "MSExch…." Active service in the list:
Right Click >> Properties >> LogOn >> Log On As field.
Criteria: If E-mail service accounts are operating with the SYSTEM account, this is not a finding. EMG3-828 Restrict Restore Permissions<GroupDescription></GroupDescription>EMG3-828 Exch2K3E-mail restore permissions are not restricted to E-mail administrators. <VulnDiscussion>Good security practice demands both the separation of duties and the assignment of least privilege. Role Based Access Control (RBAC) is the most accepted method for meeting these two criteria.
The right to restore e-mail applications or data following a service interruption must align with the E-mail Installation and E-mail Administration role, excluding all other user roles. Because this elevated privilege has the ability to change the application functionality or data from its initial version, it must be carefully assigned, monitored, and controlled. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><Responsibility>E-Mail Installer</Responsibility><IAControls>ECLP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Ensure that E-mail Restore Permissions are restricted to E-mail Administrators and Installers.
Procedure: Exchange System Manager >> Administrative Group >> [administrative group] >> servers >> [server name] >> [recovery storage group] >> Mailbox store >> properties >> security tab >> advanced tab
Select “Allow Exchange application administrator full control”. Nobody else should have ‘write’ permissions.
Verify that restore privilege is restricted to only E-mail Administrators and Installers.
Procedure: Exchange System Manager >> Administrative Group >> [administrative group] >> Servers >> [server name] >> [recovery storage group] >> Mailbox store >> Properties >> Security tab >> Advanced button
Exchange Administrators and Installers should have full control. No other group should have ‘write’ permissions.
Criteria: If Exchange Administrators and Installers have full control and No other group has ‘write’ permissions, this is not a finding.
EMG3-121 E-Mail Services Permissions <GroupDescription></GroupDescription>EMG3-121 Exch2K3Services permissions do not reflect least privilege.<VulnDiscussion>Good security practice demands both the separation of duties and the assignment of least privilege. Role Based Access Control (RBAC) is the most accepted method for meeting these two criteria. A securely designed E-mail Services Implementation includes the definition of E-mail Roles (Servers and services, Users, Administrators, Installers) based on functions required by each, then assigning the fewest privileges to these roles. Roles are then assigned to people or services on the application functions they are required to perform.
The Exchange GPO templates available from Microsoft enable the E-mail Administrator to easily set a Baseline Security Policy that hardens services permissions. Installations configured without use of policy templates must nevertheless meet vendor recommended minimums for service protection.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECLP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Correct the E-Mail Services permissions.
Procedure: The following table lists the recommended baseline settings you should start with when hardening the services for an Exchange back-end server (the Exchange_2003-Backend_V1_1.inf file configures these settings automatically).
The SDDL sets the following:
• Authenticated Users – Read
• System – Full Control
• Builtin Administrators – Full Control
• Auditing for failures against the Everyone security principal
For these listed services:
• MSExchangeMGMT - %systemroot%\program files\exchsvr\bin\exchmgmt.exe
• MSExchangeMTA - %systemroot%\system32\inetwrv\emsmta.exe
• MSExchangeSA - %systemroot%\program files\exchsvr\bin\mad.exe
• W3Svc - %systemroot%\system32\svchost.exe (IISSVCS)
• ISSAdmin - %systemroot%\system32\inetwrv\inetinfo.exeReview Permission Settings for Exchange 2003 Services.
Procedure:
The following permissions should be set:
• Authenticated Users – Read
• System – Full Control
• Builtin Administrators – Full Control
• Auditing for failures against the Everyone security principal
For these listed services:
• MSExchangeMGMT - %systemroot%\program files\exchsvr\bin\exchmgmt.exe
• MSExchangeMTA - %systemroot%\system32\inetwrv\emsmta.exe
• MSExchangeSA - %systemroot%\program files\exchsvr\bin\mad.exe
• W3Svc - %systemroot%\system32\svchost.exe (IISSVCS)
• ISSAdmin - %systemroot%\system32\inetwrv\inetinfo.exe
Criteria: If services have vendor recommended permissions, this is not a finding. EMG3-824 E-mail Application Directory Permissions <GroupDescription></GroupDescription>EMG3-824 Exch2K3Exchange application permissions are not at vendor recommended settings.<VulnDiscussion>Default product installations may provide more generous permissions than are necessary to run the application. By examining and tailoring permissions to more closely provide the least amount of privilege possible, attack vectors that align with user permissions are less likely to access more highly secured areas.
Vendor-supplied policies are available to assist in further hardening the permissions set for Exchange. Application file permissions on Exchange 2003 servers can be set by importing the group policy for Exchange Back-End or Front-End servers. To the extent of file permissions, both policies set the same directory permissions as shown here. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><Responsibility>E-Mail Installer</Responsibility><IAControls>ECLP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Procedure:
The following table lists the recommended baseline settings you should start with when hardening the services for an Exchange Back-end server (the Exchange_2003-Backend_V1_1.inf file and the Exchange_2003-Frontend_V1_1.inf file configure these settings automatically).
File ACL settings configured by Exchange_2003-Backend_V1_1.inf
The following permissions:
• System – Full Control
• Builtin Administrators – Full Control
Apply to these directories:
%systemdrive%\Inetpub\mailroot\
%systemdrive%\Inetpub\NNTPfile\
The following permissions:
• Everyone – Full Control
Applies to this directory:
%systemdrive%\Inetpub\NNTPfile\root
The following permissions:
• System – Full Control
• Builtin Administrators – Full Control
• Server Operators – Modify, Read/Execute, List, Read, Write
• Creator Owner – Full Control (subdirectories only)
Apply to these directories:
%systemdrive%\program files\exchsrvr and subs, but not ADDRESS, OMA, BIN, EXCHWEB, and RES subdirectories.
The following permissions:
• System – Full Control
• Builtin Administrators – Full Control
• Server Operators – Modify, Read/Execute, List, Read, Write
• Users – Read/Execute, List, Read
• Creator Owner – Full Control (subdirectories only)
Apply to these directories:
%systemdrive%\program files\exchsrvr (subs) >> ADDRESS, OMA, BIN, EXCHWEB, and RES subdirectories
The following table lists the recommended baseline settings you should start with when hardening the services for an Exchange back-end server (the Exchange_2003-Backend_V1_1.inf file and the Exchange_2003-Frontend_V1_1.inf file configure these settings automatically).
File ACL settings configured by Exchange_2003-Backend_V1_1.inf
The following permissions:
• System – Full Control
• Builtin Administrators – Full Control
Apply to these directories:
%systemdrive%\Inetpub\mailroot\
%systemdrive%\Inetpub\NNTPfile\
The following permissions:
• Everyone – Full Control
Applies to this directory:
%systemdrive%\Inetpub\NNTPfile\root
The following permissions:
• System – Full Control
• Builtin Administrators – Full Control
• Server Operators – Modify, Read/Execute, List, Read, Write
• Creator Owner – Full Control (subdirectories only)
Apply to these directories:
%systemdrive%\program files\exchsrvr and subs, but not ADDRESS, OMA, BIN, EXCHWEB, and RES subdirectories.
The following permissions:
• System – Full Control
• Builtin Administrators – Full Control
• Server Operators – Modify, Read/Execute, List, Read, Write
• Users – Read/Execute, List, Read
• Creator Owner – Full Control (subdirectories only)
Apply to these directories:
%systemdrive%\program files\exchsrvr (subs) >> ADDRESS, OMA, BIN, EXCHWEB, and RES subdirectories
Criteria: If files have vendor recommended permissions, this is not a finding. EMG2-259 OWA Virtual Server Scripts Permissions <GroupDescription></GroupDescription>EMG2-259 Exch2K3Scripts are permitted to execute in the OWA Virtual Server. <VulnDiscussion>Scripts on virtual servers are a frequent cause of server compromises. Since this virtual (web) server is the primary interface between Exchange and the web, it is particularly at risk of compromise. Therefore, attack vectors via scripts and executables running on the server, should be minimized.
The Exchange Virtual Server enables web access (OWA) for user mailbox stores. It is designed to provide much of the same functionality as the Outlook client, but through a web browser.
This control allows the administrator to specify whether scripts and/or executables may be run on this virtual server. Scripts and executables should be denied permissions to run, eliminating this attack vector from the security profile. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECLP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Ensure that OWA Virtual Server does not permit scripts to execute.
Procedure: Exchange system Manager >>Administrative Groups>> [administrative group]>> Servers >> [server name] >> protocols >> HTTP >> Exchange Virtual Server >> Exchange >> Properties >> Access tab
For Execute Permissions, select ‘None’. Verify that OWA Virtual Server does not permit script execution.
Procedure: Exchange system Manager >>Administrative Groups>> [administrative group]>> Servers >> [server name] >> protocols >> HTTP >> Exchange Virtual Server >> Exchange >> Properties >> Access tab
For Execute Permissions, ‘None’ should be selected.
Criteria: If "None" is selected for Execute Permissions, this is not a finding. EMG2-275 Public Virtual Server Script Permissions<GroupDescription></GroupDescription>EMG2-275 Exch2K3Scripts are permitted to execute in the Public Folder web server.<VulnDiscussion>Scripts on virtual servers are a frequent cause of server compromises. Since this virtual (web) server is the primary interface between Exchange and the web, it is particularly at risk of compromise. Therefore, attack vectors via scripts and executables running on the server, should be minimized. The Public Virtual Server enables web access for shared public folders.
This control allows the administrator to specify whether scripts and/or executables may be run on this virtual server. Scripts and executables should be denied permissions to run on this server, eliminating this attack vector from the security profile. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECLP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure the Public Virtual Server.
Procedure: Exchange system Manager >>Administrative Groups>> [administrative group]>> Servers >> [server name] >> protocols >> HTTP >> Exchange Virtual Server >> Public >> Properties >> Access tab
For Execute Permissions, select ‘None’.
Validate that scripts are not permitted to execute in the Public Virtual Server.
Procedure: Exchange system Manager >>Administrative Groups>> [administrative group]>> Servers >> [server name] >> protocols >> HTTP >> Exchange Virtual Server >> Public >> Properties >> Access tab
For Execute Permissions, ‘None’ should be selected.
Criteria: If Execute Permissions have ‘None’ selected, this is not a finding. EMG2-255 ExAdmin Virtual Directory Scripts<GroupDescription></GroupDescription>EMG2-255 Exch2K3Scripts are Permitted to Execute in the ExAdmin Virtual Server.<VulnDiscussion>The ExAdmin Virtual Server is used by the Exchange System Manager to access mailboxes and Public Folders. As such, it is a required part of the Exchange application. The Exchange System Manager is a central part of the Exchange application and without these capabilities it will be unable to function properly.
Scripts on servers are a frequent cause of server compromises. Since virtual servers are the primary interface between Exchange and the web, they are particularly at risk of compromise. Therefore, attack vectors via scripts and executables running on the server should be minimized.
The ExAdmin Virtual Server is used by the Exchange System Manager to access mailboxes and Public Folders. This control allows the administrator to specify whether scripts and/or executables may be run on this virtual server.
Scripts and executables should be denied the ability to run on this server. The Exchange System Manager is the only entity that interfaces with it, and since the default provides all of the capabilities needed, there should be no reason to change it. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECLP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure the ExAdmin Script Permissions.
Procedure: Exchange system Manager >>Administrative Groups>> [administrative group]>> Servers >> [server name] >> protocols >> HTTP >> Exchange Virtual Server >> ExAdmin >> Properties >> Access tab
Select ‘None’ on Execute Permissions.
Validate the ExAdmin script permissions.
Procedure: Exchange system Manager >>Administrative Groups>> [administrative group]>> Servers >> [server name] >> protocols >> HTTP >> Exchange Virtual Server >> ExAdmin >> Properties >> Access tab
For Execute Permissions, ‘None’ should be selected.
Criteria: If ‘None’ is selected for Execute Permissions, this is not a finding. EMG2-263 OWA Virtual Server User Permissions<GroupDescription></GroupDescription>EMG2-263 Exch2K3Users do not have correct permissions in the OWA Virtual Server.<VulnDiscussion>The principle of Least Privilege ordinarily requires analysis to ensure that users and processes are granted only as much privilege as is required to function effectively, but no additional privileges that could enable mischief, either accidental or intentional.
The Exchange Virtual Server (OWA) enables web access for user E-mail mailboxes, however, users to not access the virtual server directly. This control determines whether users will have read, write, script source access, and/or directory browsing capabilities under this virtual server.
The OWA Virtual Server requires that users have read, write, script source access, and directory browsing permissions since these are required for the proper functioning of OWA. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECLP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Set user permissions for the OWA virtual server.
Exchange system Manager >>Administrative Groups>> [administrative group]>> Servers >> [server name] >> protocols >> HTTP >> Exchange Virtual Server >> Exchange >> Properties >> Access tab
For Access Control, select ‘read, write, script source access, directory browsing’.Validate that users have correct OWA Virtual Server permissions.
Procedure: Exchange system Manager >>Administrative Groups>> [administrative group]>> Servers >> [server name] >> protocols >> HTTP >> Exchange Virtual Server >> Exchange >> Properties >> Access tab
For Access Control, ‘read, write, script source access, directory browsing’ should be selected.
Criteria: If Access Control has ‘read, write, script source access, directory browsing’ selected, this is not a finding.EMG2-269 ExAdmin Virtual Server User Permissions <GroupDescription></GroupDescription>EMG2-269 Exch2K3ExAdmin does not have correct permissions in the ExAdmin Virtual Server.<VulnDiscussion>The principle of Least Privilege ordinarily requires analysis to ensure that users and processes are granted only as much privilege as is required to function effectively, but no additional privileges that could enable mischief, either accidental or intentional.
The ExAdmin Virtual Directory enables web access to E-mail and public folder documents for the Exchange 2003 System Manager. No users access this part of the application. This control determines whether the ExAdmin user will have read, write, script source access, and/or directory browsing capabilities under this virtual server.
ExAdmin requires read, write, script source access, and directory browsing permissions since these are required for all of Exchange Web access. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECLP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure permissions in the ExAdmin virtual server.
Exchange system Manager >>Administrative Groups>> [administrative group]>> Servers >> [server name] >> protocols >> HTTP >> Exchange Virtual Server >> ExAdmin >> Properties >> Access tab >> Access control
Select ‘Read, write, script source access, directory browsing’.
Validate that user permissions to ExAdmin are set correctly.
Procedure: Exchange system Manager >>Administrative Groups>> [administrative group]>> Servers >> [server name] >> protocols >> HTTP >> Exchange Virtual Server >> ExAdmin >> Properties >> Access tab
For Access Control, ‘Read, write, script source access, directory browsing’ should be selected.
Criteria: If Access control is configured for ‘Read, write, script source access, directory browsing’ this is not a finding. EMG2-303 Zero Out Deleted Database Pages <GroupDescription></GroupDescription>EMG2-303 Exch2K3Exchange application memory is not zeroed out after message deletion.<VulnDiscussion>Residual data left in memory after a transaction is completed adds risk that it can be used for malicious purposes in the event that access to the data is achieved. Applications may perform ‘logical delete’ functions, which make the data invisible to the application user, but in fact leave it resident in memory (recoverable, for example, by a forensics tool). While not malicious, it has the effect of sacrificing security for performance.
This feature enables overwrite of memory storage before reuse to negate the potential disclosure of sensitive information that may reside in reallocated memory space. This means that by the time the memory is returned to the operating system, it essentially no longer contains any information that would allow the message to be retrieved.
Using this feature may make batch message deletion more time consuming (the server must actually overwrite the entire message). However, off-hours process performance degradation is not likely to be visible to users. Performance degradation should not be used as a reason to disable this feature, as the security benefit outweighs the risk. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECRC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Enable 'Memory Zero Overwrite' after deletion.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> Servers >> [Server] >> [storage group] >> properties >> General tab
Select the “Zero out deleted database pages” checkbox.
Verify memory zero overwrite configuration.
Procedure: Exchange System Manager >> administrative groups >> [administrative group] >> Servers >> [Server] >> [storage group] >> properties >> General tab
The “Zero out deleted database pages” checkbox should be checked.
Criteria: If “Zero out deleted database pages” checkbox is checked, this is not a finding.
EMG2-038 Signed Outbound Messages - Perimeter <GroupDescription></GroupDescription>EMG2-038 Exch2K3E-mail Services are not protected by having an Edge Transport Server (E-mail Secure Gateway) performing outbound message signing at the perimeter. <VulnDiscussion>Individual messages can be protected by requiring message signing at the creation point (Outlook), at the originator’s discretion, enabling integrity protection for their messages. However, messages can also be created by report generators and other applications using automated processes that do not typically sign messages.
By signing outbound messages as they exit into the public Internet, the sending SMTP server gives all receivers the opportunity to authenticate the sending domain and server as authentic. (using the DNS-based DKIM record), and validate the message content as unaltered in transit (using the DKIM public key to rehash). In this way, forgeries are prevented, SPAMMERs are more easily tracked. To be effective, it should be noted that unless both senders and receivers participate, sender authentication techniques are of limited effectiveness.
For receivers not configured to recognize signed messages, there is no impact to processing – they default to treating the messages as if from anonymous sender origin, and examine it with the evaluation methods that are available.
The DKIM (Domain Keys Identified Mail) process is not part of Exchange 2003 functionality; so inbound messages that reach an Exchange server as the first receiving touchpoint will not be able to perform this type of sender authentication. However, most e-mail Secure Gateway products now offer this feature.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>EMG2-038</Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>None. Exchange 2003 does not possess DKIM signing or validation features</MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECTM-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Implement an Edge Transport Server (E-mail Secure Gateway) that includes DKIM functionality.
Ensure that each domain creates mail server certificates and signs outbound messages at the perimeter.
NOTE: Each domain must also populate the Public DNS with the appropriate public keys to enable receiver validation. Interview the E-mail Administrator or the IAO. Access the System Security documentation that identifies perimeter protection in the form of an Edge Transport Server role ( E-mail Secure Gateway) offering outbound signed message transmissions.
Criteria: If an Edge Transport Server (E-mail Secure Gateway) role exists and performs outbound E-mail message signing at the perimeter, this is not a finding.EMG3-150 E-Mail Audit Data Protection <GroupDescription></GroupDescription>EMG3-150 Exch2K3E-Mail audit trails are not protected against unauthorized access. <VulnDiscussion>Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Audit log content must always be considered sensitive, and in need of protection. Audit data available for modification by a malicious user can be altered to conceal malicious activity. Audit data might also provide a means for the malicious user to plan unauthorized activities that exploit weaknesses.
The contents of audit logs are protected against unauthorized access, modification, or deletion. Only authorized auditors and the audit functions should be granted Read and Write to audit log data. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECTP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure E-mail audit trail protection against unauthorized access.
Procedure: Access the E-mail Services log files. Ensure that only E-mail Administators and System Administrators have "Read" and "Write" permissions, and that everyone else has only "Write".
Enumerate the access criteria into the System Security Plan. Verify that audit logs are protected from unauthorized access or modification.
Interview the E-mail Administrator or IAO.
Procedure: Access the System Security Plan documents that describe audit data location and protection measures. Included should be server locations and directory security that limits access to appropriate and authorized individuals or processes.
Only E-mail administrators and System Administrators should have both "read" and "write" ability. E-mail users should be restricted to "write" only.
Criteria: If E-mail users are authorized to "write", and only E-mail and System administrators may "read" and "write" to audit trails, this is not a finding.
EMG3-829 E-mail Aware Virus Protection <GroupDescription></GroupDescription>EMG3-829 Exch2K3E-mail servers do not have E-mail aware virus protection. <VulnDiscussion>With the proliferation of trojans, viruses, and SPAM attaching themselves to E-Mail messages (or attachments), it is necessary to have capable E-Mail Aware Anti-Virus (AV) products to scan messages and identify any resident malware. Because E-Mail messages and their attachments are formatted to the MIME standard, a flat-file AV scanning engine is not suitable for scanning E-Mail message stores.
E-mail aware Anti-Virus engines must use AntiVirus Application Program Interface (AVAPI) version 2.5 or higher, which is able to scan E-Mail content safely. Competent E-Mail scanners will have the ability to scan mail stores, attachments (including zip or other archive files) and mail queues, and to issue warnings or alerts if malware is detected. As with other AV products, a necessary feature to include is the ability for automatic updates.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECVP-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Install E-mail aware virus protection on mailbox servers. Ensure that mail stores are being scanned with products possessing AVAPI version 2.5 or higher. Interview the E-mail administrator or the IAO.
Procedure: Access the System Security Plan documentation that identifies the E-Mail Anti-Virus product resident on Exchange servers. Validate that the identified is one that offers AVAPI 2.5 or higher for safe scanning without risk of mail data corruption.
Criteria: If E-mail servers are using E-Mail aware AV product with AVAPI version 2.5 or higher, this is not a finding.
EMG2-863 Access Control Mechanism Audited<GroupDescription></GroupDescription>EMG2-863 Exch2K3Mailbox access control mechanisms are not audited for changes. <VulnDiscussion>Unauthorized or malicious data changes can compromise the integrity and usefulness of the data, Automated attacks or malicious users with elevated privileges have the ability to affect change using the same mechanisms as E-mail administrators. Auditing changes to access mechanisms supports accountability and non-repudiation for those authorized to define the environment but also enables investigation of changes made by others who may not be authorized. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECAT-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Ensure that access control mechanisms are audited.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> [storage group] >> Mailbox Store >> Properties >> Security tab >> Advanced button >> Audit tab
Select “change permissions”, “take ownership”, “add/remove self”, and “write properties”. Exchange System Manager >> Administrative Groups >> [administrative group] >> Servers >> [server] >> [storage group] >> Mailbox Store >> Properties >> Security tab >> Advanced button >> Audit tab
All listed items must be selected for “change permissions”, “take ownership”, “add/remove self”, and “write properties”.
Criteria: If all items are selected for “change permissions”, “take ownership”, “add/remove self”, and “write properties”, this is not a finding.
EMG2-718 SMTP Connector Message Size Restriction<GroupDescription></GroupDescription>EMG2-718 Exch2K3Message size restriction is specified at the SMTP connector level. . <VulnDiscussion>E-mail system availability depends in part on best practices strategies for setting tuning configurations. For message size restrictions, multiple places exist to set or override inbound or outbound message size. Failure to control the configuration strategy can result in loss of data or system availability.
This setting enables the Administrator to control the maximum size of outgoing messages on an SMTP Connector. It is recommended that, in general, no limits are applied at the connector level. This is done so that connectors do not end up prohibiting the delivery of messages that would otherwise be permitted by the Exchange configuration at the virtual server level. Using connectors to control size limits at an enterprise-wide level is discouraged since the limits would need to be applied to every potential connector in order to create an effective enterprise-wide limit.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Configure the SMTP connectors.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Routing Groups >> [routing group] >> Connectors >> [SMTP Connectors] >> Properties >> Content Restriction Tab >> Allowed Sizes
Clear the 'Only messages less than (KB)' checkbox. Review SMTP connectors.
Procedure: Exchange System Manager >> Administrative Groups >> [administrative group] >> Routing Groups >> [routing group] >> Connectors >> [SMTP Connectors] >> Properties >> Content Restriction tab >> Allowed Sizes
The 'Only messages less than (KB)' checkbox should be cleared.
Criteria: If the 'Only messages less than (KB)' checkbox is cleared, this is not a finding. EMG1-009 Unsupported Exchange Server Software<GroupDescription></GroupDescription>EMG1-009 Exch2K3Exchange Server Software that is no longer supported by the vendor for security updates must not be installed on a system.<VulnDiscussion>Exchange Server Software that is no longer supported by Microsoft for security updates is not evaluated or updated for vulnerabilities, leaving it open to potential attack. Organizations must transition to a supported Exchange Server Software to ensure continued support.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>E-Mail Administrator</Responsibility><IAControls>ECSC-1</IAControls>DPMS Target Microsoft Exchange Server 2003DISA FSODPMS TargetMicrosoft Exchange Server 20031222Upgrade Microsoft Exchange Server to a supported version.Microsoft Exchange Server 2003 mainstream support ended 14 April 2009, and extended support ended 8 April 2014. If Microsoft Exchange Server 2003 is installed on a system, this is a finding.