Module 7. Securing Communication Channels
Download
Report
Transcript Module 7. Securing Communication Channels
Module 7: Securing
Communication
Channels
Overview
Assessing Network Data Visibility Risks
Designing Application-Layer Security
Designing IP-Layer Security
Deploying Network Traffic Encryption
As data travels across a network wire, it might become
vulnerable to inspection or interception. To design endto-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.
Assessing Network Data Visibility Risks
Identifying Risks with Network Communications
Identifying Risks Associated with the Physical Network
Evaluating the Cost of Network Encryption
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
Identity
Spoofing
Data
Modification
Network
Monitoring
Man-inthe-Middle
Passwordbased
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
May Affect Data Visibility
Segment 1
Segment 1
Hub
All connections to hub visible
Switch
Segment 1
Sniffer
Segment 2
Only segment 2 visible
May Allow Improper Remote Administration
Only permits access
from Segment 3
Telnet
Segment 1
Segment 2
Router
Segment 3
Router
Telnet Server
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
C=EK3[Dk2[Ek1[P]]]
Performance
Degradation
Design, Testing,
and Deployment
?
Administration
and Maintenance
Potential Costs
of Encrypting Data
Transmissions
Lost Productivity
User Education
Loss of Packet
Filtering Abilities
Help Desk Support
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
Application
SSL/TLS
TCP/UDP
Planning Protocols for ApplicationLayer Security
IP/IPSec
Planning Secure File Transmissions
Link Layer
Planning Secure Communications for
Web Applications
Planning Security for E-mail
Applications
Physical
Layer
Requires That
Applications Support
the Encryption
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
Server Message Block Signing
Secure Sockets Layer
Transport Layer Security
Secure Multipurpose Internet Mail Extensions
Pretty Good Privacy
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 email 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-themiddle 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 ThirdParty 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 TLSprotected 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
Altered Content
Sender’s
Private Key
Plaintext
Sender
Digital
Signing
Sender’s
Public Key
Plaintext
Recipient
Plaintext
and Digest
Exposed Content
Recipient’s
Public Key
Plaintext
Sender
Encryption
Recipient’s
Private Key
Ciphertext
Plaintext
Recipient
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
Application
SSL/TLS
Planning IPSec Protocol Usage
TCP/UDP
Selecting IPSec Modes
IP/IPSec
Reviewing the Predefined IPSec
Policies
Planning Authentication for IPSec
Planning IPSec Filters
Discussion: IPSec Planning
Link Layer
Physical
Layer
IPSec Is
Transparent
to Applications
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
Planning IPSec Protocol Usage
Authentication Headers
Data authenticity
Signed
Data integrity
Anti-replay
Anti-spoofing protection
IP
TCP/UDP
AH
Header
Header
Application
Data
Encapsulating Security Payloads
Source authentication
Data encryption
Anti-replay
Anti-spoofing
protection
New IP ESP
Header Hdr
Encrypted
Original
TCP/UDP Application ESP ESP
IP
Header
Data
Trailer Auth
Header
Signed
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 nonWindows 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
Certificate
Pre-Shared Key
Authentication
and Encryption
Policy
Kerberos V5—easiest to deploy in Active Directory environment
Certificate based—offers the most interoperability
Preshared Keys—easy to implement, but less secure
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
1. Define Filters
Create a filter for each protocol
that will be protected or
dropped
2
2. Determine Filter Actions
Pass-through
Block
Negotiate
3. Define Connection Types
Local Network
Remote Access
All
Network Connections
3
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
Remote Client
Router
3 Com
Remote Client
Local Clients
Remote Client
Accounting Server
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
Auto-Enrolling
Policy Setting
Certificate Type
CA Name
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)"
Centralizing IPSec Configuration with Group Policy
Domain
OU
Assign the Computers:
Client (Respond Only)
policy to ensure that all
domain computers will use
IPSec when required.
Place servers that will require
the same IPSec configuration
into a single OU.
If multiple policies are applied, the policy assigned
at the OU closest to the user will take precedence.
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.
Verifying IPSec Communications
PING
IPSec Monitor
Network Monitor
Event Viewer
Oakley Logs
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.
Lab A: Planning Transmission Security
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
Destination address
My IP Address (the IP address of the
client)
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
Destination address
My IP Address (the IP address of the
client)
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
Any
192.168.2.10
UDP 500
Allow
192.168.4.0/24
Any
192.168.2.10
Protocol ID 50
Allow
192.168.4.0/24
Any
Any
Any
Disallow
Review
Assessing Network Data Visibility Risks
Designing Application-Layer Security
Designing IP-Layer Security
Deploying Network Traffic Encryption