A filter action defines the security requirements for the data transmission. Filter actions can be defined when you create a policy or before you create a policy. Filter lists are available to any policy. To define a filter list, right-click the IP Security Policy node and select Manage filter lists and filter actions.
A filter action can be configured to:
IPsec passes this traffic to and from the TCP/IP driver without modification or the requirement for security. This is appropriate for traffic from computers that are not IPsec-capable. Be sure to limit the IP filter list to a minimal scope when using this type of filter action, so that you do not permit traffic that should be secured.
Consider allowing ICMP traffic for troubleshooting purposes. You might also need to allow a computer that is not in your domain (for example, a consultant's computer) access to another computer in your domain. You can use the permit filter action to allow this access.
The permit filter action allows access without authentication, data integrity, or encryption. Anyone using a computer with the IP address specified in the filter list is given the access. All traffic between the computers is done in plaintext; no integrity checks are performed.
IPsec silently discards blocked traffic. When using a blocking filter action, be sure to use an IP filter list that defines the correct scope of IP addresses. Using larger scopes increases the chance of blocking traffic between valid computers.
If you enable the Accept unsecured communication, but always respond using IPSec option, IPsec attempts to negotiate security associations (SAs) and the sending or receiving of IPsec-protected traffic. However, if the peer cannot use IPsec, the communication will be allowed without IPsec protection. After you choose this filter action, you can also configure the following:
- Security methods and their order. This list of methods defines in which order the methods will be attempted. The first successful method will be used and the remaining methods will not be attempted. Typically, the list should be ordered from highest security to lowest security, so that the most secure method is used.
- Acceptance of initial incoming unsecured traffic (Accept unsecured communication, but always respond using IPSec). IPsec allows an incoming packet that matches the configured filter list to be unsecured (that is, not protected by IPsec). However, the outgoing response to the incoming packet must be protected. This setting is useful when you are using the default response rule for clients. When a group of servers are configured with a rule that secures communications with any IP address and accepts unsecured communication, responding with only secured communications, enabling the default response rule on client computers ensures that the clients will respond to the server request to negotiate security. To prevent denial-of-service attacks, this option should be disabled for secure computers connected to the Internet.
- Enabling of communication with non-IPsec-enabled computers (Allow unsecured communication if a secure connection cannot be established). IPsec falls back to unsecured communication, if necessary. Again, you should limit the IP filter list to a minimal scope. Otherwise, if negotiation fails for any reason, any communications affected by the rule in which this filter action resides could result in data being sent without security. If you are concerned about unsecured communication, you might consider disabling these settings. However, communication with computers that cannot initiate IPsec, such as legacy systems, might be blocked. To prevent denial-of-service attacks, this option should be disabled for secure computers connected to the Internet.
- Generation of quick mode session keys from new main mode keying material (Session key perfect forward secrecy (PFS)). Enabling session key PFS ensures that main mode master keying material cannot be used to derive more than one quick mode session key. When quick mode PFS is enabled, a new Diffie-Hellman key exchange is performed to generate new main mode master keying material before the new quick mode key is created. Session key (quick mode) PFS does not require main mode reauthentication and uses fewer resources than master key (main mode) PFS.
IPsec security methods
Each security method defines the security requirements of any communications to which the associated rule applies. Creating multiple security methods increases the chance that a common method can be found between two computers. The Internet Key Exchange (IKE) component reads the list of security methods in descending order and sends a list of allowed security methods to the other peer. The first method in common is selected. Typically, the most secure methods appear at the top of the list; the least secure methods appear at the bottom of the list.
Predefined security methods
The following security methods are predefined:
Encryption and Integrity
Uses the ESP protocol to provide data confidentiality (encryption) with the triple Data Encryption Standard (3DES) algorithm, data integrity and authentication with the Secure Hash Algorithm 1 (SHA1) integrity algorithm, and default key lifetimes (100 megabytes (MB), 1 hour). If you require both data and addressing (IP header) protection, you can create a custom security method. If you do not require encryption, use Integrity only.
Uses the ESP protocol to provide data integrity and authentication with the SHA1 integrity algorithm and default key lifetimes (100 MB, 1 hour). In this configuration, ESP does not provide data confidentiality (encryption).
Custom security methods
If the predefined Encryption and Integrity or Integrity only settings do not meet your security requirements, you can specify custom security methods. For example, you can use custom methods when encryption and address integrity, stronger algorithms, or key lifetimes must be specified. When configuring a custom security method, you can configure the following:
Both AH (data and address integrity without encryption) and ESP (data integrity and encryption) can be enabled in a custom security method when you require IP header integrity and data encryption. If you chose to enable both, you do not need to specify an integrity algorithm for ESP.
The AH protocol cannot be used over network address translation (NAT) devices because it uses a hash of the header. NAT devices alter the header, so the packet will not authenticate properly.
Message Digest 5 (MD5), which uses a 128-bit key. This algorithm is no longer considered secure and should be used only when interoperability requires its use.
SHA1, which uses a 160-bit key. SHA1 is a stronger hash than MD5 and is compliant with the Federal Information Processing Standard (FIPS).
3DES is the most secure of the DES combinations and somewhat slower in performance. 3DES processes each block three times, using three unique 56-bit keys.
DES uses a single 56-bit key and is used when the higher security and overhead of 3DES is not required. This algorithm is no longer considered secure and should only be used when interoperability requires it.
Session key (quick mode) settings determine when, not how, a new key is generated. You can specify a lifetime in kilobytes (KB), seconds, or both. For example, if the communication takes 10,000 seconds and you specify the key lifetime as 1000 seconds, 10 keys will be generated to complete the transfer. This ensures that, even if an attacker manages to determine one session key and decipher part of a communication, the attacker cannot decipher the entire communication. By default, new quick mode keys are generated for every 100 MB of data or every hour. Any time a key lifetime is reached, the SA, in addition to the key refresh or regeneration, is also renegotiated.
|To create a filter action using the New Rule Properties dialog box|
On the Rules tab of the IP Security Policy Properties dialog, clear the Use Add Wizard check box if you want to create the filter action in the property dialog box. If you want to use the wizard, leave the check box selected. Click Add. The following instructions are for creating a filter list using the dialog box.
On the Filter Action tab of the Rule Properties dialog box, clear the Use Add Wizard checkbox and click Add.
On the Security Methods tab, select the method (action) that the rule will use.
(Optional) On the Description tab, type a description of the filter action. This description can help you sort through filter actions and allows you to quickly identify the filter action without having to open its properties.
Repeat steps 4 through 8 to add additional filter actions to the list.
Although the rule can list several filter actions, only one filter action can be used per rule.
On the Filter Action tab, select the appropriate filter action for the rule and click OK.
|To create a filter action using the Manage filter lists and filter actions dialog box|
Right-click the IP Security Policy node and select Manage IP filter lists and filter actions.
On the Manage Filter Actions tab, clear the Use Add Wizard check box if you want to create the filter action using the property dialog box. If you want to use the wizard, leave the check box selected. Click Add. The following instructions are for creating a filter list using the dialog box. The directions below do not use the wizard.
On the Security Methods tab, select the method and click OK.
If you selected the Negotiate security option, you can add multiple methods and specify the order they will be attempted. To do this click Add.
(Optional) On the Description tab, type a description of the filter. This description can help you sort through filters and allows you to quickly identify the filter without having to open its properties.
Repeat steps 4 through 8 to add filter actions to the list.