General Troubleshooting Guidelines
Regardless of the type of problem you are experiencing, you should first make sure that the necessary services are started and set to automatic on both IPSec peers. On computers running Windows Server 2003, the IPSec Services service must be started. On computers running Windows 2000, the IPSec Policy Agent service must be started. Sometimes, especially after making significant changes, you might be able to resolve a problem by restarting IPSec services. This completely clears the IKE negotiation state. You can restart IPSec services from a command prompt by running the following commands:
net stop policyagent
net start policyagent
This is simply a quick way to restart IPSec without restarting the computer. After restarting the IPSec services on both computers, attempt to establish a secure connection. If the problem persists, restart the operating systems on both IPSec peers and try again.
Kerberos Authentication Problems :
Kerberos authentication is the default IPSec authentication method. You can quickly identify whether IPSec connectivity problems are caused by authentication by temporarily changing the IPSec authentication method on both IPSec peers to Preshared Key. If IPSec communications succeed with Preshared Key, Kerberos authentication is probably the source of the problem.
For Kerberos authentication to be successful, both IPSec peers must have valid computer accounts in trusted domains, and they must be able to authenticate the remote computers. Each IPSec peer must be able to communicate with domain controllers without having the authentication requests filtered. In earlier versions of Windows, IPSec automatically allowed Kerberos traffic. However, the Kerberos protocol is no longer a default exemption in Windows Server 2003.
Certificate Authentication Problems :
Certificates are a common method for authenticating computers that are not in a trusted domain environment. If you are experiencing problems with IPSec and want to verify that the problem is related to authentication, temporarily change the IPSec authentication method on both IPSec peers to Preshared Key. If IPSec communications succeed with Preshared Key but fail with certificates, the problem is almost certainly related to certificates.
If you have multiple rules in a policy, double-check that those rules will use the same authentication method consistently for any single remote computer. It is acceptable to have a policy that configures Kerberos authentication for hosts on an internal network and uses certificates for hosts on an external network. However, you cannot create one rule that uses Kerberos to authenticate just Transmission Control Protocol (TCP) data and a second rule that authenticates User Datagram Protocol (UDP) traffic by using certificates, for example. The IP Security Policy Management snap-in will not prevent you from creating these rules, but they will not work properly. All rules that apply to a single remote host must use a single authentication method.
Troubleshooting Firewalls, Routers, and Packet Filtering :
Packet filtering at firewalls is a common source of IPSec problems because IPSec cannot be permitted or blocked by applying the techniques used for most applications. First, your firewall must allow two-way traffic with a UDP destination port of 500. If the firewall is also a NAT server and you will be using Network Address Translation Traversal (NAT-T), you must also allow UDP traffic with a destination port of 4500. Second, the firewall must allow traffic with an IP protocol ID of 50, which is used by ESP. If you are using AH instead of ESP, you must allow IP protocol 51.
Network Address Translation Problems :
Network Address Translation (NAT) is a common technique for connecting a privately numbered internal network to a public network such as the Internet. As Chapter 8 discussed, earlier implementations of IPSec were not compatible with NAT. This makes sense, because NAT’s purpose is to modify the source or destination IP address in a packet without the client or server being aware, and part of IPSec’s purpose is to discard packets that have been modified in transit.
Affichage des articles dont le libellé est IPSec. Afficher tous les articles
Affichage des articles dont le libellé est IPSec. Afficher tous les articles
Lesson 3: Troubleshooting IPSec
Lesson 2: Monitoring IPSec
Monitoring IPSec is important for verifying that IPSec is working correctly in your organization.
You will also need to closely monitor IPSec if you are having a problem implementing it or if you experience network connectivity problems that might be related to IPSec. This lesson will describe the various tools that you can use to monitor IPSec.
IP Security Monitor Snap-In :
IP Security Monitor is a Windows XP and Windows Server 2003 snap-in used to monitor and troubleshoot IPSec. If an IPSec policy is active, you can use this console to examine the policy and its operations.
Information in the IP Security Monitor snap-in is divided into three nodes: Active Policy, Main Mode, and Quick Mode. The Active Policy node, as shown in Figure 9.4, displays information about the currently assigned policy. This information includes the policy’s name, last modified date, and origin. If you are unsure about how a particular policy was applied to a computer, check this node to identify the GPO that assigned the policy.
Event Viewer :
As with many features of Windows Server 2003, you can configure IPSec to add events to the event logs. This is useful for verifying that IPSec is functioning correctly, for troubleshooting problems with IPSec, and for detecting successful or unsuccessful intrusion attempts. IPSec can generate events for two types of actions: successful and unsuccessful negotiations and dropped packets.
Auditing IPSec negotiations
The creation and deletion of IPSec SAs are audited as network logon events. To audit these events, enable success or failure auditing for the Audit Logon Events audit policy for your domain or local computer. IPSec records the success or failure of each Main Mode and Quick Mode negotiation and the establishment and termination of each negotiation as separate events. The IKE event category is also used for auditing user logon events in services other than IPSec, so you won’t see just IPSec events.
Logging dropped packets
IPSec is capable of adding events to the System event log when packets are filtered, as shown in Figure 9.8. The types of packet processing errors that the IPSec driver records in the System event log depend on the level of logging that is provided. IPSec driver logs can record inbound and outbound per-packet drop events during computer startup mode and operational mode. IPSec driver event logging is disabled by default, and it should not be used for extended periods. Depending on the logging level that you set, many events might be generated that will fill the System event log very
quickly.
IKE Tracing :
Some troubleshooting scenarios require a more detailed analysis than you can do by using Event Viewer. The IKE tracing log is a detailed log intended for troubleshooting IKE interoperability under controlled circumstances. Keep in mind that the details of this tracing log are not well documented and that advanced knowledge of ISAKMP RFC 2408 and IKE RFC 2409 is required to interpret this log. However, experienced IPSec administrators might find it useful. You can enable tracing for IKE negotiations if the audit failure events do not provide enough information.
To enable tracing on a computer running Windows 2000 or Windows XP, create the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\Oakley\ EnableLogging registry value and set it to 1. Then either restart the computer or run the net stop policyagent and net start policyagent commands at the command prompt.
In Windows Server 2003, you can enable or disable the IKE tracing log dynamically while the IPSec service is running by using the Netsh commands for IPSec. To do this, open a command prompt and run the command netsh ipsec dynamic set config ikelogging 1. Alternatively, you can disable IKE tracing by running the command netsh ipsec dynamic set config ikelogging 0.
The IKE tracing log appears as the %systemroot%\Debug\Oakley.log file. A new Oakley. log file is created each time the IPSec service is started, and the previous version of the Oakley.log file is saved with the file name Oakley.log.sav. The log is limited to 50,000 lines. When the Oakley.log file becomes full, the current file is saved as Oakley. log.bak, and a new Oakley.log file is created.
Because many IKE negotiations can occur simultaneously, you should minimize the number of negotiations and enable the IKE tracing log for as briefly as possible to capture a more easily interpreted log. Use the IP addresses, SPI, timestamps, and SA identifiers to identify messages related to one security negotiation or IPSec SA processing session.
Netsh :
Netsh was first introduced in Chapter 8 as a tool for configuring IPSec policies at the command line. It can also be used to monitor and troubleshoot IPSec on computers running Windows Server 2003, however. It provides access to several key pieces of information that are not accessible by means of graphical tools. Monitoring consists of displaying policy information, getting diagnostics and logging IPSec information, or both. By running Netsh, you can find any information that you can find by running the IP Security Monitor snap-in.
To quickly get a detailed snapshot of IPSec information on a computer, run the following commands from a command prompt:
Netsh ipsec dynamic show all > ipsec.txt
Notepad ipsec.txt
These two commands will output all dynamic IPSec information to a text file and then open it in Notepad. You can, of course, view the information at a command prompt. However, the output from the command is so long that it will quickly scroll off the default command prompt.
Performance Console :
The most flexible way to monitor IPSec is to use the Performance console. The Performance console has two snap-ins: System Monitor and Performance Logs And Alerts. System Monitor allows you to monitor the real-time statistics of a wide variety of system counters by using a bar graph, a test report, or a line graph, as shown in Figure 9.9. Performance Logs And Alerts stores specified performance counters in a log file and allows you to later analyze the history of those counters by using the System Monitor snap-in. Performance Logs And Alerts can also send an e-mail message or other kind of alert when a counter reaches a specified threshold.
Network Monitor :
Network Monitor is a protocol analyzer—a type of tool more commonly referred to as a sniffer. Network Monitor is an optional component included with Windows 2000 Server and Windows Server 2003 that can capture and analyze network traffic as it is sent to and from a computer. The version of Network Monitor included for free with the Windows operating systems is a limited version of the Network Monitor tool included with Microsoft Systems Management Server (SMS). The primary limitation is that the version included with Windows will capture only traffic sent directly to and
from the co mputer it runs on. To capture traffic sent to or from other computers, you must use SMS.
The Network Monitor parser in Windows 2000 cannot interpret ESP traffic. In Windows Server 2003, the parser can interpret ESP traffic if an IPSec hardware acceleration adapter performs encryption or decryption of this traffic, or if you use ESP without encryption. Otherwise, as shown in Figure 9.10, you will only be able to see that ESP traffic is being exchanged with a remote computer. You cannot interpret the Application layer data within the ESP header because it is encrypted.
Netcap :
Netcap.exe is a command-line utility that you can use to capture network traffic to a capture file. You can then load the file in Network Monitor to view the captured traffic. You do not have to install the Network Monitor tool on the computer running Windows Server 2003 to use Netcap. You can also use Netcap on computers running Windows XP, which makes it an extremely attractive way to capture traffic for later review. The tool is available after the Windows Server 2003 Support Tools have been installed. When you first run the command, the Network Monitor driver is automatically installed.
Ping :
The favorite tool for troubleshooting network connectivity, ping, might or might not be useful for troubleshooting IPSec. First, if you use IPSec filters to block Internet Control Message Protocol (ICMP) traffic, neither ping nor Tracert will work because IPSec will filter the incoming requests. Second, ping requests do not initiate a security negotiation if you are using the default security policies. Both Server (Request Security) and Server (Require Security) explicitly permit ICMP traffic, but neither require ICMP traffic to negotiate security, If you create an IP security rule with the All ICMP Traffic filter list that uses a filter action set to Negotiate Security, and ICMP traffic is not being blocked by Internet Connection Firewall (ICF) or a firewall, ping can be a useful tool. In these cases, the ping client will show "Negotiating IP Security" during the IKE negotiation process. After negotiati on succeeds, you will see the standard ping reply messages, and the successful negotiation will be reflected in the IPSec monitoring tools.
IPSecMon :
Computers running Windows 2000 do not include the IP Security Monitor snap-in. Instead, there is a graphical tool named IP Security Monitor. To start this tool on a computer running Windows 2000, click Start, click Run, type ipsecmon, and then click OK. The Windows 2000 IP Security Monitor tool shows much of the same information as the IP Security Monitor snap-in, including a list of active SAs, and statistics such as confidential and authenticated bytes sent and the total number of bad SPI packets.
IPSecCmd :
As mentioned in Lesson 1, IPSecCmd can be used to display IPSec information at the command line on computers running Windows XP. The syntax used to view all available IPSec information is simply Ipseccmd show all. IPSecPol lacks IPSecCmd’s query mode, and, as a result, you cannot display IPSec information from the Windows 2000 command line.
Netdiag :
Netdiag.exe is a command-line tool that you can use to display IPSec information on computers running Windows 2000 and Windows XP. Netdiag is also available for Windows Server 2003, but the IPSec capabilities of Netdiag have been disabled. For Windows 2000, Netdiag is included with the Windows 2000 Support Tools that you can also download from the Internet. It is also available on the Windows XP Installation CD-ROM. You can install it by running Setup.exe from the Support\Tools folder and choosing the complete installation.
You will also need to closely monitor IPSec if you are having a problem implementing it or if you experience network connectivity problems that might be related to IPSec. This lesson will describe the various tools that you can use to monitor IPSec.
IP Security Monitor Snap-In :
IP Security Monitor is a Windows XP and Windows Server 2003 snap-in used to monitor and troubleshoot IPSec. If an IPSec policy is active, you can use this console to examine the policy and its operations.
Information in the IP Security Monitor snap-in is divided into three nodes: Active Policy, Main Mode, and Quick Mode. The Active Policy node, as shown in Figure 9.4, displays information about the currently assigned policy. This information includes the policy’s name, last modified date, and origin. If you are unsure about how a particular policy was applied to a computer, check this node to identify the GPO that assigned the policy.
Event Viewer :
As with many features of Windows Server 2003, you can configure IPSec to add events to the event logs. This is useful for verifying that IPSec is functioning correctly, for troubleshooting problems with IPSec, and for detecting successful or unsuccessful intrusion attempts. IPSec can generate events for two types of actions: successful and unsuccessful negotiations and dropped packets.
Auditing IPSec negotiations
The creation and deletion of IPSec SAs are audited as network logon events. To audit these events, enable success or failure auditing for the Audit Logon Events audit policy for your domain or local computer. IPSec records the success or failure of each Main Mode and Quick Mode negotiation and the establishment and termination of each negotiation as separate events. The IKE event category is also used for auditing user logon events in services other than IPSec, so you won’t see just IPSec events.
Logging dropped packets
IPSec is capable of adding events to the System event log when packets are filtered, as shown in Figure 9.8. The types of packet processing errors that the IPSec driver records in the System event log depend on the level of logging that is provided. IPSec driver logs can record inbound and outbound per-packet drop events during computer startup mode and operational mode. IPSec driver event logging is disabled by default, and it should not be used for extended periods. Depending on the logging level that you set, many events might be generated that will fill the System event log very
quickly.
IKE Tracing :
Some troubleshooting scenarios require a more detailed analysis than you can do by using Event Viewer. The IKE tracing log is a detailed log intended for troubleshooting IKE interoperability under controlled circumstances. Keep in mind that the details of this tracing log are not well documented and that advanced knowledge of ISAKMP RFC 2408 and IKE RFC 2409 is required to interpret this log. However, experienced IPSec administrators might find it useful. You can enable tracing for IKE negotiations if the audit failure events do not provide enough information.
To enable tracing on a computer running Windows 2000 or Windows XP, create the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\Oakley\ EnableLogging registry value and set it to 1. Then either restart the computer or run the net stop policyagent and net start policyagent commands at the command prompt.
In Windows Server 2003, you can enable or disable the IKE tracing log dynamically while the IPSec service is running by using the Netsh commands for IPSec. To do this, open a command prompt and run the command netsh ipsec dynamic set config ikelogging 1. Alternatively, you can disable IKE tracing by running the command netsh ipsec dynamic set config ikelogging 0.
The IKE tracing log appears as the %systemroot%\Debug\Oakley.log file. A new Oakley. log file is created each time the IPSec service is started, and the previous version of the Oakley.log file is saved with the file name Oakley.log.sav. The log is limited to 50,000 lines. When the Oakley.log file becomes full, the current file is saved as Oakley. log.bak, and a new Oakley.log file is created.
Because many IKE negotiations can occur simultaneously, you should minimize the number of negotiations and enable the IKE tracing log for as briefly as possible to capture a more easily interpreted log. Use the IP addresses, SPI, timestamps, and SA identifiers to identify messages related to one security negotiation or IPSec SA processing session.
Netsh :
Netsh was first introduced in Chapter 8 as a tool for configuring IPSec policies at the command line. It can also be used to monitor and troubleshoot IPSec on computers running Windows Server 2003, however. It provides access to several key pieces of information that are not accessible by means of graphical tools. Monitoring consists of displaying policy information, getting diagnostics and logging IPSec information, or both. By running Netsh, you can find any information that you can find by running the IP Security Monitor snap-in.
To quickly get a detailed snapshot of IPSec information on a computer, run the following commands from a command prompt:
Netsh ipsec dynamic show all > ipsec.txt
Notepad ipsec.txt
These two commands will output all dynamic IPSec information to a text file and then open it in Notepad. You can, of course, view the information at a command prompt. However, the output from the command is so long that it will quickly scroll off the default command prompt.
Performance Console :
The most flexible way to monitor IPSec is to use the Performance console. The Performance console has two snap-ins: System Monitor and Performance Logs And Alerts. System Monitor allows you to monitor the real-time statistics of a wide variety of system counters by using a bar graph, a test report, or a line graph, as shown in Figure 9.9. Performance Logs And Alerts stores specified performance counters in a log file and allows you to later analyze the history of those counters by using the System Monitor snap-in. Performance Logs And Alerts can also send an e-mail message or other kind of alert when a counter reaches a specified threshold.
Network Monitor :
Network Monitor is a protocol analyzer—a type of tool more commonly referred to as a sniffer. Network Monitor is an optional component included with Windows 2000 Server and Windows Server 2003 that can capture and analyze network traffic as it is sent to and from a computer. The version of Network Monitor included for free with the Windows operating systems is a limited version of the Network Monitor tool included with Microsoft Systems Management Server (SMS). The primary limitation is that the version included with Windows will capture only traffic sent directly to and
from the co mputer it runs on. To capture traffic sent to or from other computers, you must use SMS.
The Network Monitor parser in Windows 2000 cannot interpret ESP traffic. In Windows Server 2003, the parser can interpret ESP traffic if an IPSec hardware acceleration adapter performs encryption or decryption of this traffic, or if you use ESP without encryption. Otherwise, as shown in Figure 9.10, you will only be able to see that ESP traffic is being exchanged with a remote computer. You cannot interpret the Application layer data within the ESP header because it is encrypted.
Netcap :
Netcap.exe is a command-line utility that you can use to capture network traffic to a capture file. You can then load the file in Network Monitor to view the captured traffic. You do not have to install the Network Monitor tool on the computer running Windows Server 2003 to use Netcap. You can also use Netcap on computers running Windows XP, which makes it an extremely attractive way to capture traffic for later review. The tool is available after the Windows Server 2003 Support Tools have been installed. When you first run the command, the Network Monitor driver is automatically installed.
Ping :
The favorite tool for troubleshooting network connectivity, ping, might or might not be useful for troubleshooting IPSec. First, if you use IPSec filters to block Internet Control Message Protocol (ICMP) traffic, neither ping nor Tracert will work because IPSec will filter the incoming requests. Second, ping requests do not initiate a security negotiation if you are using the default security policies. Both Server (Request Security) and Server (Require Security) explicitly permit ICMP traffic, but neither require ICMP traffic to negotiate security, If you create an IP security rule with the All ICMP Traffic filter list that uses a filter action set to Negotiate Security, and ICMP traffic is not being blocked by Internet Connection Firewall (ICF) or a firewall, ping can be a useful tool. In these cases, the ping client will show "Negotiating IP Security" during the IKE negotiation process. After negotiati on succeeds, you will see the standard ping reply messages, and the successful negotiation will be reflected in the IPSec monitoring tools.
IPSecMon :
Computers running Windows 2000 do not include the IP Security Monitor snap-in. Instead, there is a graphical tool named IP Security Monitor. To start this tool on a computer running Windows 2000, click Start, click Run, type ipsecmon, and then click OK. The Windows 2000 IP Security Monitor tool shows much of the same information as the IP Security Monitor snap-in, including a list of active SAs, and statistics such as confidential and authenticated bytes sent and the total number of bad SPI packets.
IPSecCmd :
As mentioned in Lesson 1, IPSecCmd can be used to display IPSec information at the command line on computers running Windows XP. The syntax used to view all available IPSec information is simply Ipseccmd show all. IPSecPol lacks IPSecCmd’s query mode, and, as a result, you cannot display IPSec information from the Windows 2000 command line.
Netdiag :
Netdiag.exe is a command-line tool that you can use to display IPSec information on computers running Windows 2000 and Windows XP. Netdiag is also available for Windows Server 2003, but the IPSec capabilities of Netdiag have been disabled. For Windows 2000, Netdiag is included with the Windows 2000 Support Tools that you can also download from the Internet. It is also available on the Windows XP Installation CD-ROM. You can install it by running Setup.exe from the Support\Tools folder and choosing the complete installation.
MCP 70-299 : Deploying andTroubleshooting IPSec
Lesson 1: Deploying IPSec
Deploying IPSec by Using Active Directory :
If your organization has an Active Directory domain, you should almost always use Active Directory to deploy IPSec. The primary tool for building IPSec policies is the graphical user interface provided by the IP Security Policy Management snap-in. You can use the IP Security Policy Management snap-in to create, modify, and activate IPSec policies, and then assign them to a domain, site, or organizational unit (OU) in Active Directory by using the Group Policy Object Editor snap-in.
If you decide to deploy IPSec policies by using GPOs, you must understand how IPSec policies differ from other types of security settings. Most settings in a security template can be combined by importing them into a single GPO. If multiple GPOs with overlapping settings are assigned to a single computer, the computer will automatically resolve any conflicting settings. Because multiple security templates and sets of Group Policy settings can be applied to a single computer, role-based security templates work perfectly when a computer serves multiple roles.
Only one IPSec policy can be applied to any single computer. If multiple GPOs assign multiple IP security policies to a computer, only the GPO with the highest precedence will be applied. IPSec policy uses the same precedence sequence as other Group Policy settings, which is from lowest to highest: Local GPO, site, domain, OU.
Deploying IPSec Using Scripts :
If a computer is not a member of a Windows 2000 domain or a Windows Server 2003 domain, it cannot retrieve IPSec policy from Active Directory. However, as Chapter 8 described, you can use the Netsh, Ipseccmd.exe, and Ipsecpol.exe command-line tools to create IPSec scripts. You can then include these scripts as startup scripts for each computer on your network. You can use Ipsecpol.exe only on computers running Windows 2000, Ipseccmd.exe only on computers running Windows XP, and the Netsh commands for IPSec only on computers running Windows Server 2003.
Although having three separate scripting tools for the three operating systems makes managing a typical network challenging, the three tools are similar in functionality. Although the exact parameters vary, each tool provides separate static and dynamic configuration modes and the ability to display existing IPSec configuration information. For each tool, the dynamic configuration mode changes the currently running IPSec settings, although static configuration mode changes the persistent configuration. In other words, dynamic configuration changes are lost after you restart your computer,but static configuration changes will remain.
Deploying Certificate Services for IPSec :
Although Kerberos is the simplest way to authenticate IPSec peers, certificates provide greater flexibility for authenticating non-Windows IPSec peers and other computers that are not members of an Active Directory domain. In Windows 2000 and Windows Server 2003, you can use Certificate Services to automatically manage computer certificates for IPSec authentication. IPSec also supports the use of a variety of non-Microsoft X.509 public key infrastructure (PKI) systems. Windows Server 2003 IKE has basic compatibility with several certificate systems, including those offered by Microsoft, Entrust, VeriSign, and Netscape. If you are using a non-Microsoft PKI system, the PKI
system must be able to issue certificates to computers and store their certificates in the Windows Cryptographic Application Programming Interface (CryptoAPI) computer certificate store.
IPSec’s use of certificate authentication is compatible with many different PKI architectures, and IKE places relatively few requirements on the contents of a certificate. Typically, computers that have a common trusted root, or whose certificates can chain through a cross-certification trust relationship, can successfully use certificatebased authentication for IPSec. To use certificates for IPSec authentication, you define an ordered list of acceptable root certification authority (CA) names in the
authentication method.
Deploying IPSec by Using Active Directory :
If your organization has an Active Directory domain, you should almost always use Active Directory to deploy IPSec. The primary tool for building IPSec policies is the graphical user interface provided by the IP Security Policy Management snap-in. You can use the IP Security Policy Management snap-in to create, modify, and activate IPSec policies, and then assign them to a domain, site, or organizational unit (OU) in Active Directory by using the Group Policy Object Editor snap-in.
If you decide to deploy IPSec policies by using GPOs, you must understand how IPSec policies differ from other types of security settings. Most settings in a security template can be combined by importing them into a single GPO. If multiple GPOs with overlapping settings are assigned to a single computer, the computer will automatically resolve any conflicting settings. Because multiple security templates and sets of Group Policy settings can be applied to a single computer, role-based security templates work perfectly when a computer serves multiple roles.
Only one IPSec policy can be applied to any single computer. If multiple GPOs assign multiple IP security policies to a computer, only the GPO with the highest precedence will be applied. IPSec policy uses the same precedence sequence as other Group Policy settings, which is from lowest to highest: Local GPO, site, domain, OU.
Deploying IPSec Using Scripts :
If a computer is not a member of a Windows 2000 domain or a Windows Server 2003 domain, it cannot retrieve IPSec policy from Active Directory. However, as Chapter 8 described, you can use the Netsh, Ipseccmd.exe, and Ipsecpol.exe command-line tools to create IPSec scripts. You can then include these scripts as startup scripts for each computer on your network. You can use Ipsecpol.exe only on computers running Windows 2000, Ipseccmd.exe only on computers running Windows XP, and the Netsh commands for IPSec only on computers running Windows Server 2003.
Although having three separate scripting tools for the three operating systems makes managing a typical network challenging, the three tools are similar in functionality. Although the exact parameters vary, each tool provides separate static and dynamic configuration modes and the ability to display existing IPSec configuration information. For each tool, the dynamic configuration mode changes the currently running IPSec settings, although static configuration mode changes the persistent configuration. In other words, dynamic configuration changes are lost after you restart your computer,but static configuration changes will remain.
Deploying Certificate Services for IPSec :
Although Kerberos is the simplest way to authenticate IPSec peers, certificates provide greater flexibility for authenticating non-Windows IPSec peers and other computers that are not members of an Active Directory domain. In Windows 2000 and Windows Server 2003, you can use Certificate Services to automatically manage computer certificates for IPSec authentication. IPSec also supports the use of a variety of non-Microsoft X.509 public key infrastructure (PKI) systems. Windows Server 2003 IKE has basic compatibility with several certificate systems, including those offered by Microsoft, Entrust, VeriSign, and Netscape. If you are using a non-Microsoft PKI system, the PKI
system must be able to issue certificates to computers and store their certificates in the Windows Cryptographic Application Programming Interface (CryptoAPI) computer certificate store.
IPSec’s use of certificate authentication is compatible with many different PKI architectures, and IKE places relatively few requirements on the contents of a certificate. Typically, computers that have a common trusted root, or whose certificates can chain through a cross-certification trust relationship, can successfully use certificatebased authentication for IPSec. To use certificates for IPSec authentication, you define an ordered list of acceptable root certification authority (CA) names in the
authentication method.
MCP 70-299 : 8 - Planning and Configuring IPSec
Lesson 3: Configuring IPSec
IP Filters :
IP filters describe network traffic and are used by IPSec policies to determine whether an IP security rule should apply to an individual packet. IP filters can specify traffic to or from a set of IP addresses, WINS servers, DNS servers, DHCP servers, or a default gateway. You can also configure an IP filter to match a packet’s source or destination port number, or even a packet’s IP protocol number. Each of the following examples can be specified by either a single IPSec IP filter or a combination of multiple filters:
■ All traffic to or from IP address 10.4.22.17
■ All Internet Control Message Protocol (ICMP) traffic to or from the default gateway
■ All traffic sent to TCP port 80, except traffic sent from the internal network
■ All outbound connections, except those to specific servers
Multiple IP filters can be combined into an IP filter list. In fact, adding an IP filter to an IP filter list is the only thing you can do with an IP filter, because IPSec policies only allow you to specify IP filter lists. If your needs are simple, you can make an IP filter list that consists of a single IP filter. However, most IP filter lists will consist of multiple IP filters.
Filter Actions :
You use filter actions, also referred to as security methods, to define how an IPSec policy should handle traffic that matches an IP filter. A filter action responds in one of three ways: it drops the traffic, it allows the traffic, or it attempts to negotiate security. If you choose the Permit or Block options for a filter action, there is nothing left to configure. In fact, you never need more than one filter action for each of the Permit and Block options.
There are several additional settings to consider when you configure a filter action to negotiate security. First, you must choose whether the server will allow communications with clients that do not support IPSec by selecting or clearing the Allow Unsecured Communication With Non-IPSec-Aware Computers check box. You can only require IPSec when you have only IPSec-enabled all client computers. Otherwise, clients without IPSec will be denied access to the server. Generally, this setting is enabled only when Active Directory is used to deploy IPSec configuration settings to all networked computers.
You should use the Filter Action Wizard to configure filter actions whenever possible, because configuring integrity and encryption settings can be complicated. The IP Traffic Security page of the wizard enables you to specify the protection suites associated with the filter action. You can choose Integrity And Encryption, Integrity Only, or Custom. If you select Integrity And Encryption, the wizard configures the filter action with ESP-based integrity verification (using Secure Hash Algorithm 1 [SHA1] by default) and encryption (using 3DES by default). If you select Integrity Only, Triple-Data Encryption Standard (3DES) encryption is disabled.
IP Security Rules :
An IP security rule consists of an IP filter list, a filter action, and, optionally, a connection type and tunnel endpoint. You can specify only one IP filter list and one filter action per rule. If the rule pertains to traffic traveling between networks across an IPSec tunnel, you should provide the IP address of the tunnel endpoint. This does not conflict with your ability to add IP filter lists; you can configure an endpoint and apply the rule only to traffic on a specific subnet within the destination network accessible through the IPSec tunnel.
The default response rule is used to configure the computer to respond to requests for secure communication when no other rules match the traffic. If an active policy does not have a rule defined for a computer that is requesting secure communication, the default response rule is applied and security is negotiated. For example, when Computer A communicates securely with Computer B, and Computer B does not have an inbound filter defined for Computer A, the default response rule is used.
Configuring IP Security Policies with Graphical Tools :
IP filters, filter actions, and IP security rules are only useful when added to an IP security policy. When configuring IP security policies on the local computer, you can use the IP Security Policy Management snap-in. You can also use the Group Policy Object Editor snap-in to edit either local or domain GPOs. In the Group Policy Object Editor, expand Computer Configuration, Windows Settings, Security Settings, and then click either IP Security Policies On Local Computer or IP Security Policies On Active Directory. Because this node might have several different labels, this chapter will refer to it
as simply IP Security Policies.
To create a new security policy, right-click the applicable IP Security Policies node in the Group Policy Object Editor or IP Security Policy Management snap-in, and then click Create IP Security Policy. This opens the IP Security Policy Wizard, which guides you through the process of creating a security policy.
During the configuration process, you will be prompted to activate the default response rule. In most cases, you should enable the default response rule. If you do, you will be prompted to select an authentication method. For more information about rules, see the section "IP Security Rules" in this lesson.
Configuring IP Security Policies with Command-Line Tools :
Though you should usually use graphical tools to configure IP security policies, Windows Server 2003 also provides the Netsh command-line tool for scripting IPSec configuration. Netsh is a native Windows Server 2003 command-line scripting tool that you can use to display or modify the local or remote network configuration. The Netsh IPSec commands cannot be used on any other version of Windows.
To use the command line to configure IPSec policies on computers running Windows XP, use Ipseccmd.exe, which is provided on the Windows XP CD, in the \Support\Tools folder. To use the command line to configure IPSec policies on computers running Windows 2000, use Ipsecpol.exe, which is provided with the Windows 2000 Server Resource Kit.
To use Netsh interactively to view or modify IPSec settings, open a command prompt and run the command Netsh with no parameters. This starts the Netsh interactive command prompt. Then type Ipsec static or Ipsec dynamic to set the context for Netsh. For example, the following commands launch Netsh and set the context to Ipsec dynamic:
C:\>netsh
netsh>ipsec
netsh ipsec>static
netsh ipsec static>
Static mode allows you to create, modify, and assign policies without affecting the active IPSec policy. Dynamic mode allows you to display the active state and immediately implement changes to the active IPSec policy. Dynamic Netsh commands affect the service only when it is running. If it is stopped, dynamic policy settings are discarded.
MCP 70-299 : 8 - Planning and Configuring IPSec
Lesson 2: Planning an IPSec Infrastructure
Active Directory Considerations :
For organizations with large numbers of computers that must be managed in a consistent way, it is best to distribute IPSec policies by using Group Policy objects (GPOs). Although you can assign local IPSec policies to computers that are not members of a trusted domain, distributing IPSec policies and managing IPSec policy configuration and trust relationships is much more time-consuming for computers that are not domain members. Another advantage of using Active Directory–based IPSec policy is that you can delegate permissions on the IP Security Policies On Active Directory container to enable specific administrators to manage IPSec throughout your organization.
Active Directory Considerations :
For organizations with large numbers of computers that must be managed in a consistent way, it is best to distribute IPSec policies by using Group Policy objects (GPOs). Although you can assign local IPSec policies to computers that are not members of a trusted domain, distributing IPSec policies and managing IPSec policy configuration and trust relationships is much more time-consuming for computers that are not domain members. Another advantage of using Active Directory–based IPSec policy is that you can delegate permissions on the IP Security Policies On Active Directory container to enable specific administrators to manage IPSec throughout your organization.
These administrators do not necessarily need permissions to directly manage the individual computers
that will receive the IPSec policy, however. This capability is vital to organizations that divide responsibility for security tasks between various groups. To delegate permissions on the IP Security Policies container, you must use an Active Directory editing tool, such as ADSI Edit. ADSI Edit is a Windows support tool that uses the Active Directory Service Interfaces (ADSI). The Windows support tools can be installed from the \Support\Tools folder on the Windows 2000 and Windows Server
2003 operating system CDs.
Authentication for IPSec :
Peer authentication is the process of ensuring that an IPSec peer is the computer it claims to be. By using peer authentication, IPSec can determine whether to allow communications with another computer before the communication begins. You can choose from three authentication methods: Kerberos v5, public key certificates, and preshared keys.
If you have deployed a Windows 2000 or Windows Server 2003 Active Directory environment, and all hosts that will be using IPSec are part of that domain (or a member of a trusted domain), then you should use Kerberos. If you are communicating with outside organizations, and your partners use a Web-based CA, you can use public key certificates. If neither of these methods is available, you can use a preshared key.
Public key certificates authentication :
A public key infrastructure (PKI) can be used to authenticate and encrypt communications for a wide variety of applications, including Web applications, e-mail, and IPSec.
Although using public key certificates is not as convenient as using Kerberos, there are specific circumstances for which certificates are the logical choice for authentication in IPSec. Specifically, you should use public key certificates when you need to communicate privately with external business partners or other computers that do not support the Kerberos v5 authentication protocol.
IPSec’s use of certificate authentication is compatible with many different PKI architectures, and IPSec places relatively few requirements on the contents of a certificate. Typically, computers that have a common trusted root, or whose certificates can chain through a cross-certification trust relationship, can successfully use IPSec authentication. To use certificates for IPSec authentication, you define an ordered list of acceptable root CA names in the authentication method. This list controls the certificates that IPSec can select and the certificates that IPSec will select.
Preshared key authentication :
If both IPSec peers are not in the same domain and do not have access to a CA, a preshared key can be used. For example, a standalone computer on a network that does not connect to the Internet might need to use a preshared key, because neither Kerberos authentication through the computer’s domain account nor access to a CA on the Internet is available. A preshared key is a shared secret key (basically a password) that has been agreed upon by administrators who want to secure the computers’ communications by using IPSec. Administrators must manually configure their systems to use the same preshared key.
The preshared key authentication method uses symmetrical encryption to authenticate the hosts, which itself is very secure, but which requires that any two hosts communicating have been configured with a predefined password. Unfortunately, this key is not stored securely on the IPSec hosts. The authentication key is stored in plaintext format in the system registry and hex-encoded in Active Directory–based IPSec policy. If attackers can access your registry, they can find your preshared key, which would allow them to decrypt your traffic or impersonate one of the hosts. Use preshared key authentication only when no stronger method can be used.
Testing IPSec
As a rule, you should perform extensive testing before making any changes to your infrastructure. This rule certainly holds true when planning to use IPSec. IPSec has the potential to interfere with all network communications and, as a result, can break any network applications that your organization uses.
Begin testing IPSec in a lab environment. Configure computers with the client- and server-side of your critical applications, and verify that the lab is functional and accurately simulating the production environment. Your lab environment should have computers with each of the potential IPSec client operating systems, because different operating systems support different IPSec functionality. Develop performance metrics for each of your applications, and gather baseline performance data that you can use for comparison after IPSec has been implemented. Then implement IPSec policies on the lab computers.
Not all network equipment provides the same IPSec capabilities, and you should use the testing phase to determine which network devices need configuration changes or upgrades. Add firewalls, proxy servers, and routers to the lab environment to simulate the potential for those devices to interfere with IPSec communications in the production environment. If you plan to use IPSec for remote access, be sure to include a remote access client in your lab environment, and have that client connect from a typical remote network. If employees will use IPSec to connect to your internal network from home, test IPSec across a variety of commonly used home routing equipment. Test non-IPSec-enabled clients with IPSec-enabled servers. Even if you plan to deploy IPSec to every computer, there will be a transition period during which some computers will not yet have received the IPSec configuration.
After IPSec clients and network equipment have been configured in the lab environment, test the application functionality. If you identify problems, document the problems and solutions so that they can be quickly resolved if they appear in the production environment. Besides verifying that applications function, verify IPSec functionality. If you allow IPSec clients to use unsecured communications if IPSec negotiations fail, it is possible for applications to appear to be compatible with IPSec when the computers were unable to establish an IPSec session.
that will receive the IPSec policy, however. This capability is vital to organizations that divide responsibility for security tasks between various groups. To delegate permissions on the IP Security Policies container, you must use an Active Directory editing tool, such as ADSI Edit. ADSI Edit is a Windows support tool that uses the Active Directory Service Interfaces (ADSI). The Windows support tools can be installed from the \Support\Tools folder on the Windows 2000 and Windows Server
2003 operating system CDs.
Authentication for IPSec :
Peer authentication is the process of ensuring that an IPSec peer is the computer it claims to be. By using peer authentication, IPSec can determine whether to allow communications with another computer before the communication begins. You can choose from three authentication methods: Kerberos v5, public key certificates, and preshared keys.
If you have deployed a Windows 2000 or Windows Server 2003 Active Directory environment, and all hosts that will be using IPSec are part of that domain (or a member of a trusted domain), then you should use Kerberos. If you are communicating with outside organizations, and your partners use a Web-based CA, you can use public key certificates. If neither of these methods is available, you can use a preshared key.
Public key certificates authentication :
A public key infrastructure (PKI) can be used to authenticate and encrypt communications for a wide variety of applications, including Web applications, e-mail, and IPSec.
Although using public key certificates is not as convenient as using Kerberos, there are specific circumstances for which certificates are the logical choice for authentication in IPSec. Specifically, you should use public key certificates when you need to communicate privately with external business partners or other computers that do not support the Kerberos v5 authentication protocol.
IPSec’s use of certificate authentication is compatible with many different PKI architectures, and IPSec places relatively few requirements on the contents of a certificate. Typically, computers that have a common trusted root, or whose certificates can chain through a cross-certification trust relationship, can successfully use IPSec authentication. To use certificates for IPSec authentication, you define an ordered list of acceptable root CA names in the authentication method. This list controls the certificates that IPSec can select and the certificates that IPSec will select.
Preshared key authentication :
If both IPSec peers are not in the same domain and do not have access to a CA, a preshared key can be used. For example, a standalone computer on a network that does not connect to the Internet might need to use a preshared key, because neither Kerberos authentication through the computer’s domain account nor access to a CA on the Internet is available. A preshared key is a shared secret key (basically a password) that has been agreed upon by administrators who want to secure the computers’ communications by using IPSec. Administrators must manually configure their systems to use the same preshared key.
The preshared key authentication method uses symmetrical encryption to authenticate the hosts, which itself is very secure, but which requires that any two hosts communicating have been configured with a predefined password. Unfortunately, this key is not stored securely on the IPSec hosts. The authentication key is stored in plaintext format in the system registry and hex-encoded in Active Directory–based IPSec policy. If attackers can access your registry, they can find your preshared key, which would allow them to decrypt your traffic or impersonate one of the hosts. Use preshared key authentication only when no stronger method can be used.
Testing IPSec
As a rule, you should perform extensive testing before making any changes to your infrastructure. This rule certainly holds true when planning to use IPSec. IPSec has the potential to interfere with all network communications and, as a result, can break any network applications that your organization uses.
Begin testing IPSec in a lab environment. Configure computers with the client- and server-side of your critical applications, and verify that the lab is functional and accurately simulating the production environment. Your lab environment should have computers with each of the potential IPSec client operating systems, because different operating systems support different IPSec functionality. Develop performance metrics for each of your applications, and gather baseline performance data that you can use for comparison after IPSec has been implemented. Then implement IPSec policies on the lab computers.
Not all network equipment provides the same IPSec capabilities, and you should use the testing phase to determine which network devices need configuration changes or upgrades. Add firewalls, proxy servers, and routers to the lab environment to simulate the potential for those devices to interfere with IPSec communications in the production environment. If you plan to use IPSec for remote access, be sure to include a remote access client in your lab environment, and have that client connect from a typical remote network. If employees will use IPSec to connect to your internal network from home, test IPSec across a variety of commonly used home routing equipment. Test non-IPSec-enabled clients with IPSec-enabled servers. Even if you plan to deploy IPSec to every computer, there will be a transition period during which some computers will not yet have received the IPSec configuration.
After IPSec clients and network equipment have been configured in the lab environment, test the application functionality. If you identify problems, document the problems and solutions so that they can be quickly resolved if they appear in the production environment. Besides verifying that applications function, verify IPSec functionality. If you allow IPSec clients to use unsecured communications if IPSec negotiations fail, it is possible for applications to appear to be compatible with IPSec when the computers were unable to establish an IPSec session.
MCP 70-299 : 8 - Planning and Configuring IPSec
Negotiating IPSec Connections :
Unfortunately, IP was not originally designed with authentication or encryption in mind. As the internet grew and TCP/IP became the network protocol of choice, this unsecured form of communication became the standard. IPSec allows computers to continue using IP, while adding authentication and encryption.
However, most computers on IP networks today do not have IPSec enabled. As a result, computers with IPSec enabled are usually configured to politely ask remote computers to use IPSec to improve the security of the connection. If the two computers determine that they both have IPSec configured, and can agree upon a set of security standards, they can begin to use IPSec. This process is known as IPSec negotiation.
Not all IPSec negotiations are successful. Often the negotiations will fail because one of the two computers is not capable of using IPSec. Alternatively, the computers might not have the same security protocols enabled, which would mean that they wouldn’t be able to agree on a set of standards. In these cases, the computers will either revert to unprotected IP communications or determine that they will not communicate at all if they cannot use IPSec.
Internet Key Exchange (IKE) is the algorithm by which the first secure Security Association, or SA (a secure channel), is negotiated. IKE is a combination of the Internet Security Association Key Management Protocol (ISAKMP) and the Oakley Key Determination protocol and performs a two-phase negotiation: Main Mode and Quick Mode.
Main Mode
The initial long form of the IKE negotiation (Main Mode or Phase 1) performs the authentication and generates the master key material to establish an ISAKMP SA between machines. The result is referred to as an ISAKMP SA or an IKE SA. After the ISAKMP SA is established, it will remain in place for the period of time defined on the host computers—by default, it will last for 8 hours on computers running Windows. If data is actively being transferred at the end of the 8 hours, the Main Mode security association (SA) will be renegotiated automatically.
Main Mode negotiation occurs in three parts:
1. Negotiation of protection suites
2. Diffie-Hellman exchange
3. Authentication
Quick Mode
Quick Mode (also known as Phase 2) IKE negotiation establishes a secure channel between two computers to protect data. Because this phase involves the establishment of SAs that are negotiated on behalf of the IPSec service, the SAs created during Quick Mode are called the IPSec SAs. Two SAs are established, each with its own Security Parameter Index (SPI) label. One IPSec SA is used for inbound traffic, and the other is used for outbound traffic. During Quick Mode, keying material is refreshed or, if necessary, new keys are generated. A protection suite that protects specific IP traffic is also selected.
IPSec hosts will perform IKE Quick Mode negotiation on a regular basis to reduce the risk of an attacker using brute force methods to determine the keys used in the communications. Each renegotiation re-establishes two new IPSec security associations with new keys and SPIs. By default, computers running Windows will perform Quick Mode negotiation every hour (3600 seconds) or after 100 megabytes have been transferred.
Either side of the connection can start the renegotiation process. Therefore, the site that first reaches the defined session key limit will initiate renegotiation. Lesson 3 describes how to specify session key limits.
Authentication Header and ESP :IPSec can use two protocols: Authentication Header (AH) and ESP. The protocols canbe used either separately or together. AH provides data origin authentication, dataintegrity, and anti-replay protection for the entire packet, including the IP header andthe data payload carried in the packet. Naturally, AH does not provide protection forthe fields in the IP header that are allowed to change in transit, such as the hop count.AH does not encrypt data, which means it does not provide privacy. Attackers can readthe contents of packets if they can intercept them, but the packets cannot be modified.ESP is more commonly used than AH because it provides data origin authentication,data integrity, anti-replay protection, and the option of privacy. While AH and ESP canbe used together, you will use ESP alone in most circumstances. You should chooseAH over ESP only when the data and header in the packet need to be protected frommodification and authentication but not encrypted. You might do this if you have anintrusion detection system, firewall, or quality of service (QoS) router that needs toinspect the contents of the packet. Otherwise, take advantage of the privacy providedby encryption, and use ESP. If IPSec traffic must traverse a NAT server, you must useESP, because ESP is the only IPSec protocol that supports NAT-T.
IPSec in Windows :
IPSec is natively available and can be used to protect network communications for Windows 2000, Windows XP Professional, and Windows Server 2003. Additionally, a legacy client is available for Microsoft Windows NT 4.0, Windows 98, and Windows Millennium Edition (ME). You can download the legacy client from
Unfortunately, IP was not originally designed with authentication or encryption in mind. As the internet grew and TCP/IP became the network protocol of choice, this unsecured form of communication became the standard. IPSec allows computers to continue using IP, while adding authentication and encryption.
However, most computers on IP networks today do not have IPSec enabled. As a result, computers with IPSec enabled are usually configured to politely ask remote computers to use IPSec to improve the security of the connection. If the two computers determine that they both have IPSec configured, and can agree upon a set of security standards, they can begin to use IPSec. This process is known as IPSec negotiation.
Not all IPSec negotiations are successful. Often the negotiations will fail because one of the two computers is not capable of using IPSec. Alternatively, the computers might not have the same security protocols enabled, which would mean that they wouldn’t be able to agree on a set of standards. In these cases, the computers will either revert to unprotected IP communications or determine that they will not communicate at all if they cannot use IPSec.
Internet Key Exchange (IKE) is the algorithm by which the first secure Security Association, or SA (a secure channel), is negotiated. IKE is a combination of the Internet Security Association Key Management Protocol (ISAKMP) and the Oakley Key Determination protocol and performs a two-phase negotiation: Main Mode and Quick Mode.
Main Mode
The initial long form of the IKE negotiation (Main Mode or Phase 1) performs the authentication and generates the master key material to establish an ISAKMP SA between machines. The result is referred to as an ISAKMP SA or an IKE SA. After the ISAKMP SA is established, it will remain in place for the period of time defined on the host computers—by default, it will last for 8 hours on computers running Windows. If data is actively being transferred at the end of the 8 hours, the Main Mode security association (SA) will be renegotiated automatically.
Main Mode negotiation occurs in three parts:
1. Negotiation of protection suites
2. Diffie-Hellman exchange
3. Authentication
Quick Mode
Quick Mode (also known as Phase 2) IKE negotiation establishes a secure channel between two computers to protect data. Because this phase involves the establishment of SAs that are negotiated on behalf of the IPSec service, the SAs created during Quick Mode are called the IPSec SAs. Two SAs are established, each with its own Security Parameter Index (SPI) label. One IPSec SA is used for inbound traffic, and the other is used for outbound traffic. During Quick Mode, keying material is refreshed or, if necessary, new keys are generated. A protection suite that protects specific IP traffic is also selected.
IPSec hosts will perform IKE Quick Mode negotiation on a regular basis to reduce the risk of an attacker using brute force methods to determine the keys used in the communications. Each renegotiation re-establishes two new IPSec security associations with new keys and SPIs. By default, computers running Windows will perform Quick Mode negotiation every hour (3600 seconds) or after 100 megabytes have been transferred.
Either side of the connection can start the renegotiation process. Therefore, the site that first reaches the defined session key limit will initiate renegotiation. Lesson 3 describes how to specify session key limits.
Authentication Header and ESP :IPSec can use two protocols: Authentication Header (AH) and ESP. The protocols canbe used either separately or together. AH provides data origin authentication, dataintegrity, and anti-replay protection for the entire packet, including the IP header andthe data payload carried in the packet. Naturally, AH does not provide protection forthe fields in the IP header that are allowed to change in transit, such as the hop count.AH does not encrypt data, which means it does not provide privacy. Attackers can readthe contents of packets if they can intercept them, but the packets cannot be modified.ESP is more commonly used than AH because it provides data origin authentication,data integrity, anti-replay protection, and the option of privacy. While AH and ESP canbe used together, you will use ESP alone in most circumstances. You should chooseAH over ESP only when the data and header in the packet need to be protected frommodification and authentication but not encrypted. You might do this if you have anintrusion detection system, firewall, or quality of service (QoS) router that needs toinspect the contents of the packet. Otherwise, take advantage of the privacy providedby encryption, and use ESP. If IPSec traffic must traverse a NAT server, you must useESP, because ESP is the only IPSec protocol that supports NAT-T.
IPSec in Windows :
IPSec is natively available and can be used to protect network communications for Windows 2000, Windows XP Professional, and Windows Server 2003. Additionally, a legacy client is available for Microsoft Windows NT 4.0, Windows 98, and Windows Millennium Edition (ME). You can download the legacy client from
http://www.microsoft.com /windows2000/server/evaluation/news/bulletins/l2tpclient.asp.
MCP 70-299 : 8 - Planning and Configuring IPSec
Lesson 1: IPSec Fundamentals
IPSec in the Windows Server 2003 operating system protects networks from active and passive attacks by securing IP packets through the use of packet filtering, cryptography, and the enforcement of trusted communication. IPSec is useful for improving the privacy and integrity of host-to-host, host-to-network, and network-to-network communications. IPSec can also be used as a host-based firewall to harden clients and servers by using packet filtering.
IPSec Overview :
IPSec is a framework of open standards for helping to ensure private, secure communications over Internet Protocol (IP) networks through the use of cryptographic security services. IPSec supports network-level data integrity, data confidentiality, data origin authentication, and replay protection. Because IPSec is integrated at the Internet layer (layer 3), it provides security for almost all protocols in the TCP/IP suite, and because IPSec is applied transparently to applications, there is no need to configure separate security for each application that uses TCP/IP.
IPSec can be used to provide packet filtering, to encrypt and authenticate traffic between two hosts, and to create a virtual private network (VPN). Using these capabilities of IPSec helps to provide protection against:
■ Network-based denial-of-service attacks from untrusted computers.
■ Data corruption.
■ Data theft.
■ User-credential theft.
■ Administrative control of servers, other computers, and the network.
Besides simply improving security, IPSec can be used to save money by enabling communications
between remote offices and remote access clients across the public Internet, rather than more costly dedicated circuits that offer privacy at the physical level.
Securing Host-to-Host Communications :
You can use IPSec to encrypt and validate the integrity of communications between two computers. For example, IPSec can protect traffic between domain controllers in different sites, between Web servers and database servers, or between Web clients and Web servers. When an IPSec client attempts to initiate a connection to an IPSec server, the client and server negotiate IPSec integrity and encryption protocols. After the IPSec connection is established, the application’s data is transported within the IPSec connection.
For example, consider the common scenario of a user downloading e-mail from a server using Post Office Protocol version 3 (POP3). If IPSec is not enabled, the e-mail client software initiates a connection directly to the e-mail server software. The user name and password will be transmitted in clear text, so that anyone with a protocol analyzer such as Network Monitor can intercept the user’s credentials. An attacker who has control of a router can modify the contents of the user’s e-mail messages as they are downloaded without being detected.
Securing Host-to-Network Communications :
IPSec is often used to authenticate and encrypt traffic sent directly between two hosts. However, IPSec can also protect traffic traveling from a single host to an entire network, as illustrated in Figure 8.2. This is most commonly used in remote access scenarios. In the past, many organizations required users to dial in to remote access servers connected to the organization’s private network. Today, organizations can eliminate the cost of maintaining dial-in servers by using IPSec to allow remote users to connect to an organization’s private network across the Internet. Most security experts agree that IPSec provides a level of security similar to that of dial-up remote access.
Securing Network-to-Network Communications :
IPSec can also be used to connect two remote networks. Before Internet connectivity was common, remote offices were connected with private links provided by communications companies. These links would typically consist of a circuit (such as a T1 in the United States or an E1 in Europe) from each of the remote offices that connected to a switched frame relay network that would carry the traffic over long distances.
Today, many organizations still use private links to connect offices. Private links offer some distinct advantages, most notably predictability and stability. Although the Internet continues to become more reliable, performance factors such as usable bandwidth, latency, and jitter fluctuate unpredictably. Private links dedicate bandwidth to a communication link and always follow the same path—guaranteeing that performance will always stay the same.
IPSec is a framework of open standards for helping to ensure private, secure communications over Internet Protocol (IP) networks through the use of cryptographic security services. IPSec supports network-level data integrity, data confidentiality, data origin authentication, and replay protection. Because IPSec is integrated at the Internet layer (layer 3), it provides security for almost all protocols in the TCP/IP suite, and because IPSec is applied transparently to applications, there is no need to configure separate security for each application that uses TCP/IP.
IPSec can be used to provide packet filtering, to encrypt and authenticate traffic between two hosts, and to create a virtual private network (VPN). Using these capabilities of IPSec helps to provide protection against:
■ Network-based denial-of-service attacks from untrusted computers.
■ Data corruption.
■ Data theft.
■ User-credential theft.
■ Administrative control of servers, other computers, and the network.
Besides simply improving security, IPSec can be used to save money by enabling communications
between remote offices and remote access clients across the public Internet, rather than more costly dedicated circuits that offer privacy at the physical level.
Securing Host-to-Host Communications :
You can use IPSec to encrypt and validate the integrity of communications between two computers. For example, IPSec can protect traffic between domain controllers in different sites, between Web servers and database servers, or between Web clients and Web servers. When an IPSec client attempts to initiate a connection to an IPSec server, the client and server negotiate IPSec integrity and encryption protocols. After the IPSec connection is established, the application’s data is transported within the IPSec connection.
For example, consider the common scenario of a user downloading e-mail from a server using Post Office Protocol version 3 (POP3). If IPSec is not enabled, the e-mail client software initiates a connection directly to the e-mail server software. The user name and password will be transmitted in clear text, so that anyone with a protocol analyzer such as Network Monitor can intercept the user’s credentials. An attacker who has control of a router can modify the contents of the user’s e-mail messages as they are downloaded without being detected.
Securing Host-to-Network Communications :
IPSec is often used to authenticate and encrypt traffic sent directly between two hosts. However, IPSec can also protect traffic traveling from a single host to an entire network, as illustrated in Figure 8.2. This is most commonly used in remote access scenarios. In the past, many organizations required users to dial in to remote access servers connected to the organization’s private network. Today, organizations can eliminate the cost of maintaining dial-in servers by using IPSec to allow remote users to connect to an organization’s private network across the Internet. Most security experts agree that IPSec provides a level of security similar to that of dial-up remote access.
Securing Network-to-Network Communications :
IPSec can also be used to connect two remote networks. Before Internet connectivity was common, remote offices were connected with private links provided by communications companies. These links would typically consist of a circuit (such as a T1 in the United States or an E1 in Europe) from each of the remote offices that connected to a switched frame relay network that would carry the traffic over long distances.
Today, many organizations still use private links to connect offices. Private links offer some distinct advantages, most notably predictability and stability. Although the Internet continues to become more reliable, performance factors such as usable bandwidth, latency, and jitter fluctuate unpredictably. Private links dedicate bandwidth to a communication link and always follow the same path—guaranteeing that performance will always stay the same.
Inscription à :
Articles (Atom)
