As data travels across a network wire, it might become vulnerable to inspection or interception. To design end- to-end security for the transmission of data between hosts on your network, it is important to examine how different network tools can intercept network data. It is also important to examine the relationship between network hardware topology and data visibility. This module covers strategies for protecting communication channels on your Microsoft® Windows® 2000 network by guarding against packet-level impersonation and by encrypting network data transmissions.
At the end of this module, you will be able to: Assess potential risks to transmitted data on the network wire in the local area network (LAN). Design a strategy for providing authentication and data privacy by applying security at the application layer. Design a strategy for providing authentication and data privacy by applying security at the Internet Protocol (IP) layer. Design an Internet Protocol Security (IPSec) strategy for encrypting private network data transmissions.
Identifying Risks with Network Communications Identifying Risks Associated with the Physical Network Evaluating the Cost of Network Encryption Assessing Network Data Visibility Risks
Network data visibility is the risk that attackers may view data as it travels across a network wire. Factors that affect data visibility include: Whether transmitted data is clear text or encrypted. Whether large portions of the network are visible at a single interception point. A plan for securing communication channels will depend on the current level of data visibility risk on your network. Assessing this risk involves reviewing the likelihood of specific attacks against network traffic and examining your network topology and how it affects security. Your communications security goals outline the level of encryption that is required for network communications. You need to identify specific areas of concern and evaluate the costs associated with implementing encryption.
In this lesson you will learn about the following topics: Identifying risks with network communications. Identifying risks associated with the physical network. Evaluating the cost of network encryption.
Identifying Risks with Network Communications Network Monitoring Data Modification Identity Spoofing Man-in- the-Middle Password- based Password- based
Even when stored data is secured through the NTFS file system or Encrypting File System (EFS) encryption, it may still be susceptible to interception on the network wire. As data travels across a network wire, it can be subjected to passive attacks, in which data is simply observed, or active attacks, in which data is altered. Some of the potential attacks on transmitted data include: Network monitoring Data modification Identity spoofing (IP address spoofing) Man-in-the-middle attack Password-based attacks
Network monitoring The majority of network traffic passes along the network wire in clear-text format, which allows an attacker to gain access to the data by monitoring and interpreting network traffic. The most common monitoring tool, known as a network sniffer, is a program or device that monitors data traveling over a network. Without network encryption, this type of monitoring is very difficult to detect or prevent. Note: Microsoft System Management Server (SMS) Network Monitor 2.0 Service Pack 2 includes a feature that allows the detection of other clients running the Microsoft Network Monitor.
Data modification Attackers who can read data may also alter data. For example, when exchanging purchase information, you do not want the quantities or pricing information to be modified in transit.
Identity spoofing (IP address spoofing) After an attacker has learned network traffic patterns, it is possible for the attacker to generate packets on the network wire that appear to originate from a trusted computer or user.
Man-in-the-middle attack An attacker may intercept both sides of a network data exchange. In this attack, the attacker assumes the identity of the client and the server. By modifying responses, the attacker can view communications that the sender and receiver believe is secure.
Password-based attacks Many protocols pass clear-text authentication packets across the network. By intercepting these packets, an attacker may acquire valid user credentials and access to restricted resources by posing as another user. There are tools that can use information gathered from the network wire to help determine passwords.
Identifying Risks Associated with the Physical Network Hub Segment 1 Segment 2 SnifferSniffer All connections to hub visible Only segment 2 visible Switch May Affect Data Visibility Segment 1Segment 2 Only permits access from Segment 3 TelnetTelnet Segment 3 Router Telnet Server May Allow Improper Remote Administration
Some risks to transmitted data are a direct result of the physical network topology. As data passes between two computers, it crosses several physical devices including hubs and bridges, switches, and routers. Each network device on the path from source to destination is a potential point of interception.
May Affect Data Visibility Hubs and bridges do not separate network traffic between segments and therefore, might allow network sniffers to view all areas of the network connected to the hub or bridge. A switch segments traffic to reduce bandwidth. Typically, a network sniffer can only view traffic that is destined to, or originates from, the local network segment.
May Allow Improper Remote Administration Some servers are protected by only allowing specific network segments to connect. If a client that is not connected to a preferred segment attempts to connect, the connection attempt is blocked. An attacker can bypass this security by first using Telnet to connect to a router on an approved network segment and then attempting to connect to the server from the router. To prevent this attack, ensure that strong passwords are used when granting remote administration to network devices. Note: Some switches and routers have ports through which you can connect a hardware network sniffer and monitor all traffic. You must physically secure switches and routers to prevent unauthorized monitoring.
Evaluating the Cost of Network Encryption Performance Degradation C=EK 3 [D k2 [E k1 [P]]] Help Desk Support Design, Testing, and Deployment Loss of Packet Filtering Abilities Potential Costs of Encrypting Data Transmissions ? ? Lost Productivity Administration and Maintenance User Education
Assess the costs of security solutions to determine which ones provide reasonable security benefits at acceptable costs and performance for your organization. The cost to implement and maintain security systems by using Windows 2000 distributed security technologies can vary considerably, and depends on your security goals and requirements.
Even though encryption can protect data as it is crosses a network, there are financial and performance costs associated with encrypting transmitted data. These financial and performance costs include: Performance degradation Administration and maintenance User education Help desk support Loss of packet filtering abilities Lost productivity Design, testing, and deployment
Performance degradation The computation of cryptographic functions during the encryption and decryption processes may degrade performance. Most computers have sufficient processing power to handle software-based encryption without causing a noticeable delay in overall end-to-end communications. However, high-speed networks can often carry data faster than the CPU can encrypt. Hardware-based encryption can increase performance by offloading the encryption process. However, there are also some financial costs associated with hardware, such as IPSec acceleration network cards.
Administration and maintenance After deploying network encryption, there will be costs associated with maintaining the security settings that control the encryption and ensuring that new deployments are properly configured and encrypted.
User education Some encryption mechanisms, such as secure e-mail, will require you to educate users in the best use of encryption.
Help desk support When deploying network data encryption, you may face situations in which users are unable to communicate due to mismatched security policies and incorrect configuration. Trained help desk personnel must be deployed to assist the user community in troubleshooting these ongoing problems.
Loss of packet filtering abilities If specific content or protocols are disallowed from entering the network, IPSec encryption may prevent the recognition of these traffic protocols because they are encrypted when passing through a firewall.
Lost productivity Productivity will be lost if a user is unable to perform a task. For example, if an application requires the use of a smart card for encryption services, there is a cost associated with the loss of work if a user leaves their smart card at home.
Design, testing, and deployment Deploying data and network security architecture requires careful design and testing to ensure that the plan will meet all requirements.
Designing Application-Layer Security Planning Protocols for Application- Layer Security Planning Secure File Transmissions Planning Secure Communications for Web Applications Planning Security for E-mail Applications Requires That Applications Support the Encryption Application SSL/TLS TCP/UDPTCP/UDP IP/IPSecIP/IPSec Link Layer Physical Layer
You can protect network traffic at the application layer, the IP layer, or at both layers. Protection at either layer provides authentication, data privacy, and data integrity services. To design application-layer security, you need to examine the available encryption protocols, understand the considerations when securing file transfers, and plan security for Web and e-mail applications. With application-layer security, you do not need to define security associations at each computer; however, you must code each application to implement the application encryption. You can use application- layer security to deploy applications with uniform, preconfigured encryption.
There are several encryption protocols available in Windows 2000 networks that provide secure encryption and authentication at the application layer. The following application-layer security methods can be used in a Windows 2000 network: Server Message Block Secure Sockets Layer Transport Layer Security Secure Multipurpose Internet Mail Extensions Pretty Good Privacy
Planning Protocols for Application-Layer Security Secure Sockets Layer Secure Multipurpose Internet Mail Extensions Pretty Good Privacy Server Message Block Signing Transport Layer Security
Server Message Block A Server Message Block (SMB) transports file data between a client and a Windows 2000-based server. SMB (also known as the Common Internet File System [CIFS]) mutually authenticates a client and server for a communication session by placing a digital signature into each server message block. This ensures that the client is connecting to the proper server and not to a server that is impersonating the original server. SMB Signing allows for mutual authentication to occur with both Windows 2000-based and Microsoft Windows NT® version 4.0-based computers (with Service Pack 3 [SP3] or later installed). Note: The Kerberos protocol also provides mutual authentication, but it is only supported between Windows 2000 clients. There is no Kerberos support for Windows NT 4.0, Microsoft Windows 95, or Microsoft Windows 98 clients.
Secure Sockets Layer Secure Sockets Layer (SSL) is a protocol that is used to secure a variety of applications that include Web browsing, Lightweight Directory Access Protocol (LDAP) queries, and newsreaders. SSL is also used for the authentication and retrieval of e-mail by e-mail clients. The SSL protocol provides communications privacy, authentication, and message integrity through a combination of public key and symmetric encryption. You can also use SSL for Web applications requiring a secure link, such as e?commerce applications, or for controlling access to Web-based subscription services. Note: To open an SSL connection between a Web browser and Web server, you must enter Hypertext Transfer Protocol Secure (HTTPS) rather than Hypertext Transfer Protocol (HTTP) in the Uniform Resource Locator (URL). By default, HTTPS instructs the Web browser to use Transmission Control Protocol (TCP) port 443 instead of TCP port 80.
Transport Layer Security Transport Layer Security (TLS) is very similar to SSL in that it provides communications privacy, authentication, and message integrity by using a combination of public key and symmetric encryption. TLS supports the option of reverting to SSL support if needed. However, there are some important differences between TLS and SSL. TLS supports different encryption algorithms from SSL and is an Internet Engineering Task Force (IETF) draft standard. Many people view TLS as the likely successor to SSL in the long term. Because TLS is designed to be a replacement for SSL, using either protocol will be transparent to the user. However, the software must be TLS aware and SSL aware.
Secure Multipurpose Internet Mail Extensions Secure Multipurpose Internet Mail Extensions (S/MIME) is a MIME extension that provides the ability to encrypt and digitally sign e-mail messages during transport between e-mail clients. The S/MIME standard is an IETF standard designed to extend the MIME standard to provide secure e-mail functions. MIME defines a method for including binary data in a text format e-mail message. The S/MIME standard enables the digital signing and encryption of confidential e-mail between clients on any platform or operating system. The encryption process is performed at the client computers and does not require the mail servers to support S/MIME.
Pretty Good Privacy Like S/MIME, Pretty Good Privacy (PGP) is a protocol that provides the ability to encrypt and digitally sign e- mail messages during transport between e-mail clients. PGP provides confidentiality and authentication service based on private/public key pairs. PGP is free for personal use. Unlike S/MIME, PGP is not controlled by a centralized standards organization. Note: Both S/MIME and PGP provide similar functionality. The decision as to which protocol to implement will depend greatly on the e-mail solution that is implemented on your network, and the encryption protocols supported by that e-mail product.
Planning Secure File Transmissions Enhancements Offered by SMB Signing Mutual authentication of client and server Message authentication Considerations When Implementing SMB Signing Configure at both client and server Centralize implementation with Group Policy Available for Windows 2000–based computers and Windows NT 4.0 clients (SP3 or later) When Windows 95 or Windows 98 clients are present, configure servers to request SMB Signing
When a client on a Windows 2000 network connects to a server computer, the client and the server use SMBs to package the data as it is transferred between the server and the client. By default, only the client is authenticated for the data exchange. SMB Signing provides mutual message authentication of both client and server by placing a digital signature into each server message block. SMB Signing is implemented by enabling security signatures at both the client and server computers. You can enforce SMB Signing by configuring Group Policy to have servers enforce the use of SMB Signing, and by configuring clients to use SMB Signing only if requested by a server.
SMB Signing Enhancements SMB Signing improves the security of file transmissions by providing the following improvements to the default SMB data exchanges: Mutual authentication of client and server Message authentication
Mutual authentication of client and server This mutual authentication prevents a man-in-the- middle attack, in which an attacker hijacks data transmissions between a client and server and modifies the contents. SMB Signing allows the client or server to recognize that it is not communicating with the desired target for file transmission.
Message authentication SMB Signing places a digital signature into each SMB packet that is exchanged between the client and the server, thereby preventing the contents of the SMB packets from being modified in transit.
SMB Signing Considerations When planning to implement SMB Signing, consider the following design points: You must configure SMB Signing at both the client and the server locations. Communications cannot occur if a server requires SMB Signing and the client is not configured to enable SMB Signing. Use Group Policy to centralize SMB implementation by configuring all computers in the same site, domain, or organizational unit (OU) to use the same SMB Signing configuration. You can also implement SMB Signing on Windows NT 4.0 clients (with SP3 or later installed) to protect data transmitted between Windows NT 4.0-based clients and Windows 2000-based clients. If Windows 95 or Windows 98 clients exist on the network, configure servers to request SMB Signing rather than require SMB Signing. Requiring SMB Signing prevents Windows 95 and Windows 98 clients from connecting to the server. Note: There is no SMB Signing option for Windows 95 and Windows 98 clients.
Planning Secure Communications for Web Applications Obtain a Server Certificate for the Web Server Implement Basic Authentication over SSL Determine the Encryption Level Consider Using Your Own CA or a Recognized Third- Party CA Decide Which Data Requires Secure Channels
When connecting to a Web server, the data transmissions between the Web server and the Web client are generally passed in clear text. The use of clear text introduces the risk of revealing confidential or sensitive information to a network sniffer. Although you can protect data authenticity by implementing integrated Windows authentication or digest authentication, all Web browsers do not support these methods. You can also encrypt Web server communications by deploying encryption technologies, such as TLS or SSL. These encryption technologies will ensure the integrity and confidentiality of Web communications when communicating with the Internet Information Services (IIS) server. Note: SSL or TLS can also be used to secure Internet Message Access Protocol version 4 (IMAP4), LDAP, Network News Transport Protocol (NNTP), and Post Office Protocol version 3 (POP3) applications, in addition to HTTP. The common ports that these protocols use for standard transmissions and SSL-protected or TLS- protected transmissions are listed in appendix A, "SSL Port Assignments."
Your Web application security design needs to include the following planning points: If it is determined that secure Web communications must take place, obtain a server certificate for the Web server hosting the Web application. If support must be provided for all Web browsers, implement basic authentication over SSL to ensure that all authentication information is encrypted. Note: Optionally, certificate mapping can be used to associate a certificate with a specific user for authentication at Web sites. The certificate replaces the entering of the account and password for authentication.
Determine the level of encryption that will be required when communicating with the Web server. Configure the Web server to allow the client to determine the encryption level (40 bit or 128 bit), or enforce strong encryption by requiring the client to use 128-bit encryption (subject to export and import laws). For internal Web sites, consider using your own certification authority (CA) to reduce the costs of certificate services. For externally-available Web sites, consider using a certificate from a recognized third-party certification authority, such as Verisign, Inc. or RSA Security, Inc. Consider which data will require secure channels for transmission. Secure areas of a Web site can be protected with SSL or TLS, whereas public areas continue to use standard HTTP. Performance gains can be achieved by selecting which information to protect, such as personal information and credit-card numbers.
Planning Security for E-mail Applications Plaintext Plaintext and Digest Sender’s Private Key Digital Signing SenderRecipient Altered Content Plaintext Sender’s Public Key Plaintext Ciphertext Recipient’s Public Key Encryption SenderRecipient Exposed Content Plaintext Recipient’s Private Key
E-mail allows communications to occur between two clients over a network. During the transmission of an e-mail message, there is a risk that the content might be altered or viewed. You can use public key technology to protect e-mail messages.
Altered Content The content of an e-mail message can be changed in a way that alters the meaning of the message. Digital signatures protect against a message being changed in transit by creating a digest against the original message. The recipient will also create a digest against the plaintext message that he or she receives. If the digests do not match, the content has changed in transit.
Exposed Content The content of an e-mail message is sent across the network in clear text. The clear-text transmission allows a network sniffer to view the content. Mail encryption protects the contents of the message by encrypting the message so that only the intended recipient of the message can decrypt the message.
Design Considerations Both digital signatures and mail encryption use public key technology to ensure that e-mail messages are protected. When determining a security plan for e-mail applications, consider the following planning points: Document all e-mail packages that are in use. The decision to use S/MIME or PGP will be determined by which security protocol your primary e-mail system supports. Determine which users can implement secure e-mail. To do this, you must establish a method for distributing the user's public key to other users. Establish a CA for the distribution of private/public key pairs to internal e?mail users. Establish guidelines for the distribution of public keys to external e-mail recipients if secured e-mail is required between organizations. Train users when to use digital signatures, encrypted messages, or both, when sending e-mail messages.
Designing IP-Layer Security Planning IPSec Protocol Usage Selecting IPSec Modes Reviewing the Predefined IPSec Policies Planning Authentication for IPSec Planning IPSec Filters Discussion: IPSec Planning IPSec Is Transparent to ApplicationsApplicationApplicationSSL/TLSSSL/TLS TCP/UDPTCP/UDP IP/IPSec Link Layer Physical Layer
Unlike application-layer security, IP-layer security can encrypt data for any application. By performing encryption at the IP layer, applications do not need to be aware that data encryption is occurring between the client and the server. Windows 2000 provides IP-layer security through IPSec. Although IPSec deployment requires considerable planning and configuration, it results in an encryption mechanism that is transparent to both users and applications. IPSec deployment can protect data across the entire path, from before the sender sends the data to after the receiver receives the packet. Note: For additional information about IPSec, see the IETF link on the Web Resources page at www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp
Planning IPSec Protocol Usage Data authenticity Data integrity Anti-replay Anti-spoofing protection IP Header AH TCP/UDPHeaderTCP/UDPHeader Application Data Signed Authentication Headers New IP Header ESP Hdr Encrypted Signed Source authentication Data encryption Anti-replay Anti-spoofing protection Encapsulating Security Payloads Original IP Header TCP/UDPHeaderTCP/UDPHeader Application Data ESP Trailer ESP Auth
IPSec can be deployed by using one of two protocols: Authentication Headers (AHs) or Encapsulating Security Payloads (ESPs). By using these two protocols, IPSec provides the following types of security: Data authenticity Data integrity Data encryption Anti-replay and anti-spoofing protection
Data authenticity AH provides authentication, integrity, and anti-replay protection for both the IP header and the data payload carried in the packet. The IP header and data are readable, but are protected from modification during transport through the network. Note: IPSec provides authentication of the computers involved in a data transmission. It does not provide authentication of the users performing the data transmission.
Data integrity AHs provide authentication, integrity, and anti-replay protection for both the IP header and the data payload carried in the packet. The data is readable, but is protected from modification during transport.
Data encryption Only ESP provides data confidentiality through encryption of the contents of the IP packet. However, ESP also has an option to provide only integrity and authenticity (and not privacy), which makes it very similar to what AH provides. ESP is not able to protect the IP header from modification, whereas AH can protect at least the address information in the IP header. ESP can be used alone or in combination with AH.
Anti-replay and anti-spoofing protection Both AH and ESP formats provide, in each packet, sequence numbers that are checked when the packet is received. Thus the receiver knows that the packets were not captured in the past and are not being retransmitted by an attacker. Without this protection, some computers and applications are vulnerable to a replay attack, in which the attacker seeks to gain entry as a valid user by using packets captured when a legitimate user obtains access to the system.
When configuring IPSec on the network, determine what role IPSec will play on the network. If you are ensuring that only authorized users are allowed to communicate with a specific server by using a predetermined protocol, you can configure AHs. If the client cannot use AHs, communication will not occur. Likewise, if it is determined that the actual data flow must be encrypted between a client and a server, configuring the IPSec filter actions to use ESP ensures that all data transmitted between the client and the server that matches the filter list will be encrypted.
Ultimately, you must define your scenario and determine what level of IP-layer security is required. Note: To allow IPSec traffic to pass through a firewall, set the following firewall rules: allow User Datagram Protocol (UDP) 500, allow protocol identifier (ID) 51 for AH, and allow protocol ID 50 for ESP.
Selecting IPSec Modes Transport Mode Provides encryption/authentication from endpoint to endpoint Encrypted Tunnel Mode Provides encryption/authentication only between tunnel endpoints Encrypted
When IPSec is implemented, you can encrypt data from endpoint to endpoint or only when traversing a specific portion of the network. You can deploy IPSec in transport mode or tunnel mode to provide these methods of encryption.
Transport Mode All traffic that meets an IPSec filter-for example, all Telnet traffic-is encrypted between the client and the server computers. Transport mode is most commonly implemented on the LAN by defining a common IPSec policy between the two endpoint systems. Transport mode is best deployed in the following circumstances: Communication is taking place between two hosts on the same private network. Communication is taking place between two hosts and does not cross a firewall that is performing network address translation (NAT).
Tunnel Mode IPSec encrypts all traffic transmitted between the client and server systems as it traverses between the two endpoints of the tunnel. Data is decrypted when it reaches the endpoint nearest the destination computer. Tunnel mode is best deployed when you only require encryption of data over an unsecure portion of a network. For example, if two partner organizations want to encrypt all File Transfer Protocol (FTP) data between their offices on the Internet, configure IPSec to only encrypt between the firewall computers at each office.
Reviewing the Predefined IPSec Policies Client (Respond Only) Server (Request Security) Secure Server (Require Security)
Windows 2000 contains predefined IPSec policies. In the case of smaller networks, these predefined IPSec policies may meet the network's security needs. The predefined IPSec policies include: Client (Respond Only) Server (Request Security) Secure Server (Require Security) Note: Only a single IPSec policy can be assigned to any one computer. If you require a mix of solutions, create a custom IPSec policy.
Client (Respond Only) This predefined policy is best assigned to the domain group security policy to ensure that all client computers can respond as needed to requests for secure communications. The client will not initiate a request to use IPSec for transmission of data, but will enter a negotiation for Internet Key Exchange (IKE) when requested. If you require IPSec protection on the network, it is a good idea to assign this IPSec policy at the domain level.
Server (Request Security) This predefined policy is assigned to servers that will communicate with both Windows 2000 and non- Windows 2000 clients. If the client can use IPSec, all defined communications will use IPSec. If the client does not support IPSec, communication can occur by using standard data transmissions. This policy is most appropriate when in a mixed network in which both Windows 2000 and non-Windows 2000 clients will communicate with the server.
Secure Server (Require Security) This predefined policy is assigned to ensure that outgoing communication never reverts to unsecured communications if negotiations fail or the other computer is not IPSec capable. Even communication with domain controllers is negotiated and secured. This policy is most appropriate when a predefined data stream must be encrypted. Due to the strictness of this policy, you may need to add exemptions for special traffic types, such as Simple Network Management Protocol (SNMP) traffic.
Planning Authentication for IPSec Kerberos V5—easiest to deploy in Active Directory environment Certificate based—offers the most interoperability Preshared Keys—easy to implement, but less secure Authentication and Encryption Policy Kerberos V5 Certificate Pre-Shared Key
IPSec policies can define different authentication methods to ensure that two IPSec partners can negotiate a common method for authenticating each other. IPSec supports the following authentication methods: Kerberos version 5 authentication Certificate-based authentication Preshared key authentication Note: The preshared key is for authentication protection only; it is not used to encrypt the data. For higher security, use Kerberos or certificate-based authentication. In preshared key authentication, the actual shared key can be read in the IPSec policy's property pages.
Kerberos version 5 authentication The Kerberos V5 authentication protocol is the default authentication technology in Windows 2000. This authentication method can be used for any clients running the Kerberos V5 protocol (whether or not they are Windows-based clients) that are members of a trusted domain.
Certificate-based authentication You can use public key certificates to authenticate computers and users in IPSec communications between computers on the Internet, external business partners, any Layer Two Tunneling Protocol (L2TP)-based communications, or computers that do not run the Kerberos V5 authentication protocol.
Preshared key authentication A preshared key is a shared, secret key upon which two users agree. It is quick to use and does not require the client to run the Kerberos V5 protocol or have a public key certificate. Both parties must manually configure their IPSec policies to use this preshared key.
Planning IPSec Filters 1. Define Filters Create a filter for each protocol that will be protected or dropped 2. Determine Filter Actions Pass-through Block Negotiate 3. Define Connection Types Local Network Remote Access All Network Connections 11 22 33
IPSec filters define which traffic IPSec will protect. You must decide how to handle traffic that matches your IPSec filter rules. You must also decide whether the filters apply to all or only specific interfaces. Defining the correct filters and filter actions is crucial for ensuring that the correct traffic streams are protected.
Defining Filters An IPSec filter provides the ability to trigger security negotiations for communication based on the characteristics of a protocol. An administrator must create filters that define what network traffic will be protected by characterizing the protocol that the network traffic uses. An IPSec filter will contain defining information for the protocol. This information includes source and destination IP address information, transport protocol, and source and destination ports for the data transmission. Retaining this information ensures that the IPSec filter list can accurately describe each protocol involved in a data transmission.
Determining Filter Actions After all necessary IPSec filters have been defined, you then define the filter actions. The filter action sets the security requirements for the communication. The following list describes allowable filter actions: Pass through. This filter action is generally defined when network traffic exists that must not be encrypted. No IPSec security will be applied to network traffic that matches the associated filter. Block. This filter action is often used as a method to secure Internet servers and to ensure that protocols commonly associated with hacking attempts are discarded, such as the Finger protocol. If the IPSec filter is matched, the packets will be discarded. Negotiate. In this filter action, if the IPSec filter is matched, the two participating clients negotiate the type and level of IPSec policy that will be applied to the transmission of data. This can include not using IPSec if working with non-IPSec clients.
Defining Connection Types Each IPSec filter can be applied to only specific types of network connections. You can define that an IPSec filter protect network connections, remote access connections, or both types of connections.
Discussion: IPSec Planning Accounting Server Local Clients Router Remote Client
This scenario covers IPSec policy alternatives for a department in an organization. You must determine how to apply IPSec policy to provide the necessary level of security for network data transmissions.
Scenario You are the consultant for a large firm with a centralized accounting department that allows consultants to upload their timesheets by using a Web-based application. All accounting department personnel communicate with the accounting server by using a variety of programs. Among the programs are an accounting program, the Web-based timesheet program, and general Windows 2000 file sharing.
Requirements Management wants to ensure that network traffic is protected when communicating with the Accounting department's server. Specifically: Management wants to ensure that all consultant timesheet information is encrypted as it is transmitted from client computers to the Accounting server. Management wants to ensure that consultants can only communicate with the Accounting server by using the timesheet Web page. Consultants must not be allowed to connect to the Accounting server by using other protocols. All data transmissions between the Accounting department's computers and the Accounting server should be protected by using encryption.
Deploying Network Traffic Encryption Auto-Deploying Computer Certificates Centralizing IPSec Configuration with Group Policy Verifying IPSec Communications
After you have developed a strategy for encrypting network transmissions, you need to plan your deployment. A secure deployment of IPSec requires that all computers be able to authenticate for IPSec communications and that they have appropriate and consistent polices applied. Finally, you must verify that successful IPSec communications are occurring.
In this lesson you will learn about the following topics: Auto-deploying computer certificates Centralizing IPSec configuration with group policy Verifying IPSec communicatios
Auto-Deploying Computer Certificates Group Policy Object in Active Directory CA Name Certificate Type Auto-Enrolling Policy Setting
Certificates provide a secure method for authenticating computers for IPSec transmissions. By default, domain controllers automatically receive certificates, but client computers must request certificates from a local CA.
By configuring automatic certificate deployment, you ensure that all computers within the site, domain, or OU will automatically receive a computer certificate and be able to participate in IPSec transmissions that use certificate-based authentication. When defining Automatic Certificate Request Settings in Group Policy, you must provide the: Certificate template. Both IPSec certificates and computer certificates can be used to allow certificate-based authentication for IPSec. IPSec certificates can only be used for IPSec authentication, whereas computer certificates are multifaceted and can be used for other purposes, such as Web services. Certification authority. Defines the CA to which automatic certificate requests will be sent.
Apply the Automatic Certificate Request Settings in Group Policy at a container that contains all client computers requiring a certificate for IPSec authentication. Note: For more information about configuring automatic computer certificate deployment, please see www.microsoft.com/windows2000/techinfo/howitworks/ security/ip_security.asp This link references the "IP Security for Windows 2000 Server" whitepaper.You can also reference www.microsoft.com/windows2000/techinfo/planning/ security/ipsecsteps.asp, the "Step-by-Step Guide to Internet Protocol Security (IPSec)" www.microsoft.com/windows2000/techinfo/howitworks/ security/ip_security.asp www.microsoft.com/windows2000/techinfo/planning/ security/ipsecsteps.asp
Centralizing IPSec Configuration with Group Policy If multiple policies are applied, the policy assigned at the OU closest to the user will take precedence. Domain Assign the Computers: Client (Respond Only) policy to ensure that all domain computers will use IPSec when required. OU Place servers that will require the same IPSec configuration into a single OU.
You can use the Active Directory structure to define a standardized IPSec configuration in the Group Policy settings at the site, domain, or OU level. Standardized IPSec configuration ensures that all computers within a specific container have the same IPSec policy applied. Without consistent IPSec configuration, client connections may fail. Note: IPSec configuration is located in Computer Configuration\Windows Settings\Security Settings\IP Security Policies on Active Directory within Group Policy.
When designing your OU structure, consider the following for IPSec deployment: Gather computers that will use similar IPSec settings within the same OU or OU structure so that a single Group Policy can be applied. Assign the Computers: Client (Respond Only) policy at the domain level to ensure that all Windows 2000-based client computers will use IPSec when requested for any IPSec transmissions. Remember that computers can only be assigned a single IPSec policy. If multiple policies are defined in an OU hierarchy, the policy assigned at the OU closest to the user will take precedence.
After designing and implementing an IPSec communication structure, you must verify that IPSec communications are taking place. Use the following tools to verify successful IPSec communications between two hosts:
PING PING the server computer from the client computer to determine whether successful IPSec negotiations are occurring. You should initially see that IPSec is being negotiated before the ping attempt completes successfully. Ensure that you have created an IPSec filter that encrypts Internet Control Message Protocol (ICMP) packets.
IPSec Monitor The IPSec Monitor indicates whether IPSec is enabled at a client computer. If an IPSec policy is negotiated for communication, the IPSec policy will be listed in the utility. If no IPSec policies are listed in the IPSec Monitor Security Association list, the IPSec filter lists or IPSec filter actions are not defined correctly for the security association.
Network Monitor During an IPSec-secured session, use Network Monitor to determine whether IPSec is being used between two hosts. Filter out all protocols except Internet Security Association and Key Management Protocol (ISAKMP), AH, and ESP. If these protocols do not appear in the Network Monitor capture, the transmission is not using IPSec.
Event Viewer Enable security auditing and check the event log for events related to the IPSec transmission.
Oakley logs If all other tools have failed to resolve an IPSec communications problem, use Oakley logs to determine the cause of the IPSec failure. Oakley logs provide detailed logging of the ISAKMP negotiation process. Note: To enable the Oakley log, add the value EnableLogging (type REG_DWORD ) with a value of 1 to HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \PolicyAgent \Oakley in the registry.
Objectives After completing this lab, you will be able to: Determine whether to use application-layer or IP-layer security for data transmissions. Create a network transport security design. Analyze potential weaknesses in a network transport security design.
Prerequisites Before working on this lab, you must have: Knowledge of application-layer security. Knowledge of IP-layer security. In this lab, you are the security administrator for Rogue Cellars, a small but well-funded high-tech firm based in Vancouver. Rogue Cellars has recently purchased Northwind Traders in an effort to expand its customer base. In this lab, you are the administrator for Rogue Cellars' user accounts, and your task is to secure data as it is transmitted over the network. Each exercise describes a particular aspect of the design.
Exercise 1: Determining Network Transport Security Goal In this exercise, you will identify whether the company needs application-layer security or IP-layer security to provide the required level of encryption on the network wire.
Scenario Rogue Cellars is developing a new version of its most popular gaming software. They plan to sell the product by using the catalog expertise of Northwind Traders. Recently, confidential details of the game have appeared in a gaming magazine. The details are stored on the local network on an intranet Web server in the Game Design department. The Game Design department wants to protect against further details being divulged to the press.
Exercise 2: Protecting with Internet Protocol Security Goal In this exercise, you will determine the IPSec configuration required to protect network transmissions in the Accounting department.
Scenario The Accounting department wants to restrict which computers are allowed to even attempt to connect to the Accounting file server. Sensitive information on sales and internal salary structure are stored on the file server, and access can only be granted to members of the Accounting department. All client computers in the Accounting department run Windows 2000 Professional, and the Accounting department file server runs Windows 2000 Server. The accounting department is entirely located on its own switched segment to prevent network sniffers from seeing traffic that is local to the Accounting department's switched segment. The following diagram represents the network.
Criteria The following criteria need to be satisfied for securing communications in the Accounting department: Only members of the Accounting department are allowed to communicate with the Accounting file server. The Accounting department is connected to the corporate network and wants to prevent other departments' portable computers from connecting to the Accounting department's switched segment and connecting to the Accounting file server. The Information Technology (IT) department wants to minimize the configuration that must be done locally at each of the Accounting department's client computers.
Exercise 3: Analyzing an IPSec Deployment Goal In this exercise, you will analyze the organization's IPSec deployment to determine whether it meets all defined criteria.
Scenario The Finance department is protected from the rest of the organization's network by an internal firewall. The firewall was implemented to ensure that only limited access is granted to the Finance database server due to the confidential nature of all data managed by the department. The firewall restricts which computers are allowed to even attempt to connect to the Finance file server.
Currently, only members of the Auditing team are allowed to connect to the Finance database server through the firewall. The clients are using a SQL client program that connects to Microsoft SQL Server™ by using a connection to TCP port 1433. Due to concerns with the information that the auditors have been querying, a decision has been made to encrypt all data that is transported across the firewall when connections are made to the Finance database server. All network traffic on the Finance network segment is encrypted by using IPSec ESP encryption. The Finance office is protected by a security system that uses retinal scans to allow access to the office.
Proposed Configuration The following configuration has been proposed to secure all transmissions to and from the Finance department's network segment: The Finance database server is located in a dedicated OU in Active Directory. Group Policy is applied to the OU to assign the following IPSec policy to protect transmissions from the Finance network segment. IPSec policy filter Setting Source address 192.168.2.0/24 Destination address 192.168.2.10 Protocol Any Filter action Require security Authentication method Require security Connection type All network connections
The Finance department's computers are located in an OU that has the following IPSec policy defined within Group Policy. IPSec policy filter Setting Source address My IP Address (the IP address of the client) Destination address 192.168.2.10 Protocol Any Filter action Require security Authentication method Kerberos Connection type All network connections
The auditors' computers are located in an OU that has the following IPSec policy defined within Group Policy. IPSec policy filter Setting Source address My IP Address (the IP address of the client) Destination address 192.168.2.10 Protocol Any Filter action Require security Authentication method Kerberos Connection type All network connections
The following firewall rules have been configured on the internal firewall to secure traffic to and from the Finance network. Source IP Source port Destination IP Destination port/protocol ID Allow/disallow 192.168.4.0/24 Any192.168.2.10UDP 500Allow 192.168.4.0/24 Any192.168.2.10Protocol ID 50Allow 192.168.4.0/24 Any Disallow