第 10 章网络安全模式

CHAPTER 10 Security Patterns for Networks

Thus, what is of supreme importance in war is to attack the enemy’s strategy.

Sun Tzu

As network administrator I can take down the network with one keystroke. It’s just like being a doctor but without getting gooky stuff on my paws.

Scott Adams (‘Dogbert’)

10.1 Introduction

The Internet protocol suite, also referred to as TCP/IP, defines a reference model for networks that includes four layers [Sta03]: Application, Transport, Internet and Link. One can apply security to any of these layers, where two secure protocols are commonly used:

The IPSec protocol, which provides cryptographic functions at the Internet (IP) layer [For04b][sta06].
The Transport Layer Security (TLS) protocol, which provides similar functions at the transport (TCP) layer [For04b][sta06]. This protocol is based on the Secure Sockets Layer (SSL) protocol.

Figure 10.1 shows the layers and the security protocols used in each of the layers. The Application layer has different protocols based on the type of application. The Transport layer uses TLS as the security protocol, while the IP layer uses IPSec as the security protocol. Application protocols such as HTTP, LDAP and SOAP need to use the lower layers to support typical application tasks such as displaying web pages or running e-mail services; they use their own version of security protocols such as HTTPS, LDAPS (Secure LDAP) and WSS (Web Service Security) respectively.

Figure 10.1: Network layers and security protocols

These secure protocols can be used directly in applications, or can be prepackaged to provide secure channels, in the form of virtual private networks (VPN).

Figure 10.2 shows a pattern diagram that puts the different types of secure network protocols into perspective. The ABSTRACT VIRTUAL PRIVATE NETWORK pattern defines the basic functions and threats of a VPN, independently of the protocol over which it operates. An abstract pattern defines only fundamental, implementation-independent functions and threats [Fer08a]. Concrete patterns add functionalities and threats and take into account the characteristics of their specific concrete environment. In this case, the abstract functions are realized by concrete VPNs which operate according to the rules of specific protocols: IPSec VPN and TLS VPN.

Figure 10.2: Pattern diagram for network security patterns

We present here patterns for the Abstract VPN, IPSec VPN and TLS VPN. Figure 10.2 also shows patterns for the TLS and IPSec protocols, which in turn use patterns for authentication ([Sch06b] and page 52) and Secure Channel [Bra00] (not shown in the figure).

One can also apply security defenses at the network boundaries, where networks enter the computational nodes. Two security mechanisms are normally used at network boundaries:

Firewalls, which filter input and output traffic according to predefined rules. We have previously written patterns for firewalls at the IP (packet filter) and TCP (proxy firewall) layers [Sch06b], as well as the (User) Application layer [Del04]. See also Chapter 11.
Intrusion detection systems (IDS), which try to detect attacks in real time [Bie01]. IDSs can be signature-based or behavior-based.

We present the VPN patterns first, followed by the TLS protocol pattern, and finally the IDS patterns. These patterns have been coauthored with Ajoy Kumar and have been published in [Fer05d][kum10] [Kum12a][kum12b].

10.2 Abstract Virtual Private Network

The ABSTRACT VIRTUAL PRIVATE NETWORK pattern describes how to set up a secure channel between two endpoints using cryptographic tunneling, with authentication at each endpoint. An endpoint is an interface exposed by a communicating unit (user site or network).

EXAMPLE

Our company has employees all over the world. Because of cost, we decided to use the Internet to communicate. However, we are having problems because their orders are hacked and the attackers get access to customers’ credit card numbers and other details. Our staff want to be sure they are talking to other employees, and must be able to send secure messages to discuss prices, discounts and so on.

CONTEXT

Users scattered in many fixed locations, who need to communicate securely with each other using the Internet or some other insecure network. In such a network attackers may intercept messages and try to read, modify or replay them.

PROBLEM

In today’s world, companies have offices all over the world and a lot of people work remotely. They need a secure connection to other specific nodes so that confidential work can be performed securely. Their communication can be intercepted by attackers, who may get access to private information and may even modify the messages. How can we establish a secure channel for the end users of a network so that they can exchange messages through fixed points using an insecure network?

The solution to this problem must resolve the following forces:

We need to use the Internet or other insecure networks to reduce cost, but in turn subjecting our network to numerous threats.
Only registered users should access the institution’s endpoints.
We need to make sure that the users with which we are communicating are the right ones, otherwise confidentiality may be compromised.
The number of users remotely connected may be growing: the system should be scalable.
Because different users or institutions require different levels of security, the system should be flexible enough to accommodate different ways of providing security and different degrees of security.
In some cases we also need to support authorization to access specific resources in the endpoints.
The system should be easy to set up and use, otherwise users and administrators will not want to use it.
The system should not impose a heavy performance penalty, otherwise it will not be used all the time.
The pattern should be adaptable to the needs and constraints of different protocol layers.

SOLUTION

Protect communications by establishing a cryptographic tunnel between endpoints on one of the layers of the communication protocol. Add authentication functions at each endpoint. Figure 10.3 shows the case in which site A is talking to site B over the Internet using routers R1 and R2, respectively. The secure connection is established through one of the Internet layers.

Figure 10.3: Two sites communicating through the Internet [For04b]

STRUCTURE

Figure 10.4 shows the class diagram for the ABSTRACT VIRTUAL PRIVATE NETWORK pattern, in which a SecureChannel can be established between a Client and a NetworkEndPoint. EndPoints communicate with other EndPoints. A user is authenticated by an AUTHENTICATOR pattern (page 52). AUTHENTICATOR and Secure Channel [Bra00] are patterns, composed typically of several classes, and are shown using the UML symbol for package.

Figure 10.4: Class diagram for the ABSTRACT VIRTUAL PRIVATE NETWORK pattern

DYNAMICS

The sequence diagram of Figure 10.5 shows a use case in which an end user tries to access an endpoint in a network, endPoint2, from another endpoint, endPoint1. The Authenticator at endPoint1 authenticates the user. The Authenticator creates a Token as proof of authentication, which can be used to establish a SecureChannel. This channel allows secure access to endPoint2.

Figure 10.5: Sequence diagram for accessing an endpoint

IMPLEMENTATION

First define the endpoints which the VPN will reach. Consider the architectural layer where the communications should be secured, according to the needs of the applications.
After this decision, use the concrete VPN pattern at the corresponding level, IP or TCP. See the corresponding patterns (IPSEC VPN, page 200, and TLS VPN, page 202) for help in making this decision. Both endpoints must share a public key system for authentication and must have appropriate software packages running on them.

EXAMPLE RESOLVED

Now the users can be authenticated at the endpoints, which ensures that they are communicating with their own employees. User messages are now protected from external attacks when sent over the secure channel.

CONSEQUENCES

The ABSTRACT VIRTUAL PRIVATE NETWORK pattern offers the following benefits:

We can use the Internet or other insecure networks to reduce cost.
Cryptography can protect our messages from being read or modified by attackers.
Authentication at endpoints ensures that only registered users can access the secure channel.
Mutual authentication between end users is possible.
The system can accommodate new links for new users by just replicating the access software.
We can use any cryptographic algorithm to establish the secure channel, which allows us to make trade-offs between security and cost.
We can add authorization to access specific resources at each endpoint.
We can add a logging system for the users logging in at the endpoints for use in audits.
The VPN is transparent to the users, who are authenticated by their local endpoints.
The VPN is a client-server architecture that is easy to configure.
We can have different versions of the pattern that can use the specific features of each protocol layer.

The pattern also has the following potential liabilities:

If the VPN connection is compromised, the attacker could get full access to the internal network. Authorization can restrict this access, however.
Because of encryption, VPN traffic is invisible to IDS monitoring. If the IDS probe is outside the VPN server, as is often the case, then the IDS cannot see the traffic within the VPN tunnel. Therefore, if a hacker gains access to the end node of the VPN, they can attack the internal systems without being detected by the IDS.
In the case of VPN with a private end user, the remote computer used by the private user is vulnerable to outside attacks, which in turn can attack the network to which it is connected.
There is some overhead in the encryption process.

VARIANTS OR CONCRETE PATTERNS

Virtual private networks can be established at the application layer (XML or application VPN); TLS (SSL) VPNs are established at the transport layer. IPSec VPNs are established at the IP layer. Because of their importance, we describe the latter two below as separate patterns.

KNOWN USES

Citrix provides a site-to-site SSL VPN connection for remote users to log into the secure network, as well as access applications on the company (secure) network [Cit].
Cisco VPN uses an IPSec VPN and provides authorization [Cisb].
Nokia provides a VPN connection for Nokia mobile users.

10.3 IPSec VPN

The IPSEC VPN pattern describes how to set up a secure channel between two endpoints using cryptographic tunneling through the IP layer, with authentication at each endpoint.

CONTEXT

Users scattered in many predefined locations, who need to communicate securely with each other, using the Internet or another insecure network.

PROBLEM

Assuming that we need to communicate using the IP protocol, how can we establish a secure channel for the end users of a network so that they can exchange messages through some fixed points?

The solution to this problem must resolve the following forces:

The number and required speed of the communications must decide the type of protection we use. The use of IPSec would provide higher speed between fixed physical locations [Sta03].
Communication at the IP level includes the network, servers and routers. Messages should be protected while going through all of them.

SOLUTION

Implement the cryptographic tunnel at the IP level using the facilities of IPSec.

STRUCTURE

The class diagram for the IPSEC VPN pattern is similar to the one shown in Figure 10.4 on page 197.

IMPLEMENTATION

Designing the architecture of the IPSec protocol includes appropriate host placement (for host-to-host architectures) and/or gateway placement (for host-to-gateway and gateway-to-gateway architectures)[Qu02]. Both sides must share a public key system for authentication and must have appropriate software packages running on them.

The packet filter firewall determines which types of traffic should be permitted and denied, and what protection and compression measures (if any) should be applied to each type of permitted traffic (for example, ESP tunnel using AES for encryption and HMACSHA-1 for integrity protection; LZS for compression). HMAC stands for Hash-based Message Authentication Code, and SHA-1 is a specific hash algorithm [For04b][sta06]; they are used for protecting message integrity.

Encapsulating Security Payload (ESP) is a sub-protocol of IPSec that provides confidentiality, data origin authentication, integrity and replay protection [Sta03]. AES is the Advanced Encryption Standard [For04b].

CONSEQUENCES

The IPSEC VPN pattern offers the following benefits:

IPSec is supported by most operating systems.
The VPN is transparent to clients in gateway-to-gateway architectures.
We can use a variety of authentication protocols.

The pattern also has the following potential liabilities:

It can only protect IP-based communications.
It requires client software to be configured (and installed on hosts without a built-in client) for host-to-gateway and host-to-host architectures.
It does not protect communications between clients and the IPSec gateway in gateway-to-gateway architectures.
IPSec VPNs require large software packages, typically 6–8 MB, and may be difficult to configure.

VARIANTS

We can add authorization for the end users.

KNOWN USES

Cisco has an IPSec VPN and they also provide authorization [Cisb].
Cyberoam offers an identity-based IPSec VPN [Cyb].
Check Point’s VPN Software Blade is an IPSec VPN that integrates access control, authentication and encryption [Che].

10.4 TLS Virtual Private Network

ALSO KNOWN AS SSL VPN

The TLS VIRTUAL PRIVATE NETWORK pattern describes how to set up a secure channel between two endpoints using cryptographic tunneling through the transport layer, with authentication and authorization at each endpoint.

EXAMPLE

Our company has a web-based e-commerce site. We need to assure the customers that they are interacting with the proper application and that they can send their financial information securely when buying items.

CONTEXT

A large number of users, in many locations, need to communicate securely with each other, using the Internet or another insecure network. Most of the interactions occur through web sites.

PROBLEM

How can we establish a secure channel through the transport layer for the end users of a network so that they can exchange messages through fixed points?

The solution to this problem must resolve the following forces:

Messages will go from one process to another process, through servers and routers. A message should maintain its security during this communication.
The performance should be good at both normal and peak loads.

SOLUTION

Use TLS reverse proxy servers (commonly referred to as SSL proxy servers) to connect remote users. A remote user who needs to access the organization’s applications uses the main URL for the proxy server in their web browser, and connects to it through TLS-protected HTTP. The user then authenticates to the proxy server. Once authenticated, the user can access designated applications, as specified in the proxy server’s access controls.

STRUCTURE

Figure 10.6 shows the class diagram for the TLS VIRTUAL PRIVATE NETWORK pattern. A Proxy represents the endpoint and has the functions of authentication, secure channel and access control (authorization).

Figure 10.6: Class diagram for the TLS VIRTUAL PRIVATE NETWORK pattern

IMPLEMENTATION

An authentication algorithm is implemented at the server which authenticates the server to the client [Hey07b]. A secure channel is established over the public network using a suitable cryptographic algorithm that allows users to communicate securely with the servers. Some TLS VPNs provide hardware accelerators. Both the client and the server must have preloaded VPN software.

EXAMPLE RESOLVED

The SSL proxy server can authenticate the server to the user and establishes a secure channel so that remote users can send their financial information in encrypted form, thus protecting it from eavesdropping attacks.

CONSEQUENCES

The TLS VIRTUAL PRIVATE NETWORK pattern offers the following benefits:

If access is needed only for web-based applications, the solution is very convenient for users, and easier to deploy and maintain than remote access solutions that involve client installation or configuration.
The proxy server can authenticate users before they can gain any access to applications, as opposed to allowing users to connect directly to individual applications’ login screens. This adds another layer of security by only allowing authenticated users to see what applications are being served.
Since the client systems connect above the network layer, they are not on the same network layer as the IPSec client. This severely reduces their ability to attack or misuse systems in the organization’s networks.
The proxy server can authenticate itself to the user by means of a certificate.
Logging is now more convenient: it is just another function of the proxy.

The pattern also has the following potential liabilities:

Non-web-based applications, and applications that are more challenging to proxy, (such as those that use multiple dynamic ports) typically require additional software and services such as terminal servers and special client software. This makes the solution more resource-intensive to deploy and less convenient to use.
Compromise of the proxy server could allow an attacker to intercept data and authentication credentials for many different applications at once.
TLS (SSL) is a complex protocol that has been found to have security problems in some implementations. This means that the degree of security achievable with this pattern may not be as high as with the IPSEC VPN pattern.

KNOWN USES

Citrix provides a site-to-site SSL VPN connection for remote users to log into the secure network and access applications on the company’s (secure) network [Cit].
Sonic WALL acquired Aventail and its TLS VPN. This product includes authentication and network access control [Son 10].
Cyberoam has an identity-based TLS VPN [Cyb].
Aventail, Cisco, Juniper, Microsoft and Nokia also provide TLS VPNs.

10.5 Transport Layer Security

The TRANSPORT LAYER SECURITY pattern describes how to provide a secure channel between a client and a server by which application messages are communicated over the transport layer of the Internet. The client and the server are mutually authenticated and the integrity of their data is preserved.

EXAMPLE

A bank customer may want to check their account balance on line. The bank uses the transport layer to transfer its confidential data. We need to protect this communication, as this confidential data is vulnerable to attack. The customer also has to ensure that the transactions are with the bank and not with an imposter, while the bank may need to verify that access is by a legitimate customer.

CONTEXT

Users using applications that exchange sensitive information, such as web browsers for e-commerce or similar activities. The transport layer in TCP/IP provides end-to-end communication services for applications within a layered architecture of network components and protocols, and specifically convenient services such as connection-oriented data stream support, flow control and multiplexing.

PROBLEM

The messages communicated between applications and servers on the transport layer are vulnerable to attack by intruders, who may try to read or modify them. Either the server or the client may be imposters.

The solution to this problem must resolve the following forces:

Confidentiality and integrity. The data transferred in the transport layer between the client and the server could be intercepted and read, or modified illegally.
Authenticity. Either the server or the client could be an imposter, which may allow security breaches. A ‘man-in-the-middle’ attack is also possible, in which an attacker poses both as the client to the server and as the server to the client.
Flexibility. Security protocol should be flexible and configurable, to be able to handle new attacks.
Transparency. The security measures of the protocol should be transparent to users.
Configurability. The protocol should allow users to select different degrees of security.
Overhead. The overhead should be minimal, or users will not want to use the protocol.

SOLUTION

Establish a cryptographic secure channel between the client and the server using algorithms that can be negotiated between the client and the server. Provide the means for client and server to authenticate each other. Provide a way to preserve the integrity of messages.

STRUCTURE

Figure 10.7 shows a class diagram for the basic architecture of the TRANSPORT LAYER SECURITY pattern. A Client requests some Service from the Server. The TLSProtocol controller conveys this request using an Authenticator to mutually authenticate the Server and the Client, and creates a Secure Channel between them. AUTHENTICATOR and Secure Channel are patterns (see Variants on page 212).

Figure 10.7: Class diagram for the TRANSPORT LAYER SECURITY pattern

DYNAMICS

We describe the dynamic aspects of the TRANSPORT LAYER SECURITY pattern using a sequence diagram for the following use case:

Use Case: Request a Service – Figure 10.8 Figure 10.8: Sequence diagram for the use case ‘Request a service’


Summary	A Client requests a service and the TLSProtocol authenticates the request and creates a secure channel.
Actors	Client, Server.
Precondition	The security parameters of the secure exchange have been predefined.
Description	1 The Client makes a service request to the Server.
	2 The TLSProtocol authenticates the Server to the Client and the Client to the Server.
	3 The TLSProtocol creates a secure channel between the Server and the Client.
Alternate Flows	The authentication can fail.
	The creation of a secure channel can fail.
Postcondition	The Server accepts the request and grants the service.

IMPLEMENTATION

One of the protocols that is dominant today for providing security at the transport layer is Secure Sockets Layer (SSL). The SSL protocol is a transport layer security protocol that was proposed and developed Netscape Communications in the 1990s. Transport Layer Security (TLS) is an IETF version of the SSL protocol, which has become a standard [Yas04]. Much implementation advice can be found in [Sel 12].

The TLS protocol is partitioned into two main protocol layers, the TLS Record Protocol and the TLS Handshake Protocol, executing above the TCP transport layer protocol, as shown in Figure 10.9 [Elg06][sta 12]. There are other minor protocols at the handshake protocol layer, such as the Cipher Change Protocol, Alert Protocol and Application Protocol.

Figure 10.9: TLS layers

Record Protocol. The TLS Record Protocol provides encryption and message authentication for each message. A connection is created using symmetric cryptography data encryption. The keys for this symmetric encryption are generated uniquely for each connection and are based on a secret negotiated by another protocol (such as the TLS Handshake Protocol). Messages include a message integrity check using a keyed message authentication code (MAC), computed using hash functions [Sta03].
Handshake Protocol. A TLS handshake supplies the authentication and key exchange operations for the TLS protocol. The security state agreed upon in the handshake is used by the TLS Record Protocol to provide session security. This protocol allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives any data. The TLS Handshake Protocol provides connection security where the peers’ identities can be authenticated using asymmetric cryptography. This authentication can be made optional, but is generally required for at least one of the peers.

A TLS session is an association between a client and a server, created by the handshake protocol. Sessions define a set of cryptographic security parameters, which can be shared among multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection.

A session state is defined by the following parameters:

Session identifier. This is generated by the server to identify a session with a chosen client.
Peer certificate. The X.509 certificate of the peer.
Compression method. A method used to compress data prior to encryption.
Algorithm specification or CipherSpec. Specifies the encryption algorithm that encrypts the data and the hash algorithm used during the session.
Master secret. 48-byte data, being a secret shared between the client and server.
‘resumable’. A flag indicating whether the session can be used to initiate new connections.

The handshake protocol consists of the following four phases:

In the first phase, an initial connection is established to start the negotiation. The client and server exchange ‘hello’ messages that are used to establish security parameters used in the TLS session, and settings used during the handshake, such as the key exchange algorithm.
During the second phase, authentication, the server sends a certificate message to the client: this may include a server certificate when an RSA key exchange is used, or Diffie-Hellman parameters when a Diffie-Hellman key exchange is used. The server may also request a certificate from the client, using the certificateRequest message.
During the third phase, the client, if asked, may send its certificate to the server in a certificate message, along with a certificate Verify message, so that the server can verify certificate ownership (if the server requested a client certificate during the second phase). This phase includes the establishment of the security parameters such as the encryption key. The client must send either a pre-master secret encrypted using the server’s public key, or public Diffie-Hellman parameters in the clientKeyExchange message, so that the client and server can compute a shared master secret.
In the fourth phase, the client and server finish the handshake, which implies that the client and server are mutually authenticated and have completed the required key exchange operations.

STRUCTURE AND DYNAMICS OF THE HANDSHAKE PROTOCOL

The structure of the handshake protocol is shown in the class diagram in Figure 10.10. The Client requests a service from the Server at the Transport layer. The TLSHandshakeProtocolController uses client and server certificates to mutually authenticate the Client and the Server, then performs the clientKeyExchange.

Figure 10.10: Class diagram for the TLS handshake protocol.

We describe the dynamic aspects of the TLS handshake using the sequence diagram shown in Figure 10.11.

Figure 10.11: Sequence diagram for the TLS handshake use case


Summary	A TLS handshake supplies the authentication and key exchange operations for the TLS protocol.
Actors	Client, Server.
Precondition	The Client has made a request for a service from the host Server and an initial connection has already been established. The Client and Server need to have a digital certificate, issued by some Certificate Authority.
Description	1 The Client and Server exchange initial Hello messages.
	2 The ProtocolController requests the certificate from the Server and the Server sends the certificate.
	3 The server certificate is verified.
	4 The Server requests the certificate from the Client (optional).
	5 If asked, the Client sends the certificate to the Server.
	6 The client certificate is verified.
	7 The Client sends the predefined secret encrypted using the Server’s public key which is the client key exchange.
	8 The Client and the Server complete mutual handshake and the initial encryption parameters.
Alternate Flows	Authentication of the Server or Client can fail. A certificate can be expired or outdated.
	The Client could lose the encryption key while exchanging with the Server.
Postcondition	Client and Server can start exchanging data at the transport layer.

The other minor protocol layers from Figure 10.9 are discussed below:

Cipher Change Protocol. This protocol signals transitions in cipherSpec, which is a session parameter explained above.
Alert Protocol. This protocol raises alerts for the communication. This record should normally not be sent during normal handshaking or application exchanges. However, this message can be sent at any time during the handshake and up to the closure of a TLS session. If this record is used to signal a fatal error, the session will be closed immediately after sending the record. If the alert level is flagged as a warning, the remote partner can decide whether or not to close the session.
Application Protocol. Now the handshake is completed and the application protocol is enabled. This marks the start of data exchange between the server and the client.

EXAMPLE RESOLVED

When a request is made to the bank’s server by an online client at the transport layer, the bank’s server is authenticated to the customer, the customer is authenticated to the server and a secure channel is created between them. Now the client knows that online bank transactions are secure.

CONSEQUENCES

The TRANSPORT LAYER SECURITY pattern offers the following benefits:

Confidentiality and integrity. A secure channel is established between the server and the client, which can provide data confidentiality and integrity for the messages sent. We could add a logging system for the client at its endpoint for future audits.
Authenticity. Both client and server can be mutually authenticated. Man-in-the-middle attacks can be prevented by mutual authentication.
Flexibility. We can easily change the algorithms for encryption and authentication protocols.
Transparency. The users don’t need to perform any operation to establish a secure channel.
Configurability. Users can select algorithms to obtain different degrees of security. The pattern also has the following potential liabilities:
Overhead. As seen from Figure 10.11, the overhead is significant for short sessions: many messages are needed.
SSL/TLS is a two-party protocol; it is not designed to handle multiple parties. However the MTLS variant can handle multiple parties.

VARIANTS

WTLS. A modified version of TLS, called WTLS (Wireless TLS protocol) has been used in mobile systems. WTLS is based on TLS and is similar in some aspects [Bad04]. WTLS has been superseded in the WAP (Wireless Application Protocol) 2.0 standard by the End-to-End Transport Layer Security specification.
MultipleTLS (MTLS). This is an application-level protocol running over the TLS Record protocol. The MTLS provides application multiplexing over a single TLS session. Therefore, instead of associating a TLS session with each application, this protocol allows several applications to protect their communication over a single TLS session [Bad09].

Some different versions of TLS are given below.

TLS 1.0. TLS 1.0 is an upgrade of SSL Version 3.0 and is an IETF version of SSL. The differences between this protocol and SSL 3.0 are not large, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate. TLS 1.0 does include a means by which a TLS implementation can downgrade the connection to SSL 3.0, but this weakens security.
TLS 1.1. TLS 1.1 is an update of TLS version 1.0. Significant differences include:
Added protection against cipher block chaining (CBC) attacks. In CBC mode, each block of plaintext is XORed with the previous cipher text block before being encrypted.
The implicit Initialization Vector (IV) was replaced with an explicit IV.
Change in handling of padding errors.
Support for registration of parameters.
TLS 1.2. This is a revision of the TLS 1.1 protocol, which contains improved flexibility, particularly for negotiation of cryptographic algorithms. The major changes are:
The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs. All cipher suites in this document use P_SHA256.
The MD5/SHA-1 combination in the digitally-signed element has been replaced with a single hash. Signed elements now include a field that explicitly specifies the hash algorithm used.
Substantial cleanup to the client’s and server’s ability to specify which hash and signature algorithms they will accept.
Addition of support for authenticated encryption with additional data modes.
Tightening up of a number of requirements.
Verification of data length now depends on the cipher suite (default is still 12) [wik3].
EAP-TLS is a wireless authentication protocol for TLS [EAP].

KNOWN USES

Mozilla Firefox versions 2 and above support TLS 1.0 [Moz].
Internet Explorer (IE) 8 in Windows 7 and Windows Server 2008 support TLS 1.2 [MS].
Presto 2.2, used in Opera 10, supports TLS [Rut].

10.6 Abstract IDS

The ABSTRACT IDS pattern allows monitoring of all traffic as it passes through a network, and its analysis it to detect possible attacks and trigger an appropriate response.

EXAMPLE

Our company has a firewall to control traffic from the Internet. However we are still plagued by viruses and other attacks that penetrate the firewall. The attacks can be existing attacks or new attacks. We need to improve our defense against such attacks.

CONTEXT

Nodes for local systems that need to communicate with each other using the Internet or another insecure network.

PROBLEM

An attacker may try to infiltrate our system through the Internet and misuse our information by reading or modifying it. We need to know when an attack is happening and take appropriate response.

The solution to this problem must resolve the following forces:

Communication. The system is usually more secure if we have a closed network. However in today’s world it is better and more realistic to use the Internet or other insecure network to reduce costs, which may subject our network to security threats.
Real time behavior. Attacks should be detected before the attack completes its purpose, so that we can preserve our assets and save time and money. It is difficult to detect an attack when it is happening, but such detection is imperative if we are to react timely and appropriately.
Incomplete security. Security measures such as encryption, authentication and so on may not protect all our systems, because they do not cover all possible attacks.
Non-suspicious users. Protecting our system through a firewall is quick and easy. However, request coming from a non-suspicious address (that is, one permitted by a firewall) could still be harmful and should be monitored further.
Flexibility. Hard-coding the type of attack can be done easily. But it will be hard and time-consuming to adapt to attack patterns that change constantly.

SOLUTION

Each request to access the network is analyzed to check whether it conforms to the definition of an attack. If we detect an attack, an alert is raised and some countermeasures maybe taken.

The ABSTRACT IDS pattern defines the basic features of any intrusion detection system (IDS). An abstract pattern defines only fundamental, implementation-independent functions and threats [Fer08a]. Concrete patterns add functionalities and threats, and take into account the characteristics of their specific concrete environment. In this case, the abstract functions are realized by concrete IDSs that operate based on known attack signatures, or based on abnormal behavior or anomaly in the network: SIGNATURE-BASED IDS or BEHAVIOR-BASED IDS. We present here patterns for all these three types of IDS.

Figure 10.12 shows the typical placement of an IDS in a network, complementing a firewall. The firewall filters requests for services, and the IDS further checks for suspicious patterns in request sequences. If a suspicious pattern is detected, the network operator is alerted and the firewall may block some or all traffic.

Figure 10.12: Possible placement of network IDS to complement a firewall

STRUCTURE

Figure 10.13 shows the class diagram for the ABSTRACT IDS pattern. A Client requests some service from the Server. The IDS intercepts this request and sends it to an EventProcessor. The EventProcessor processes the event so that the AttackDetector can analyze the event and implement some method of detection using information from AttackInformation. When an attack is detected, a Response is created.

Figure 10.13: Class diagram for the ABSTRACT IDS pattern

DYNAMICS

We describe the dynamic aspects of the ABSTRACT IDS pattern using a sequence diagram for the following use case.

Use Case: Detect an Intrusion – Figure 10.14


Summary	The Client requests a service from the Host. The IDS intercepts the message and checks whether the request is an attack or not and raises a response.
Actors	Client, Server.
Precondition	We have attack information available.
Description	1 A Client makes a service request to the Host.
	2 The IDS send the request event to an EventProcessor.
	3 The EventProcessor processes the event data so that the AttackDetector can interpret the event.
	4 The AttackDetector tries to detect whether this request is an attack or not by comparing with the available information in the AttackInformation.
	5 If an attack is detected, a Response is created.
Alternate Flows	The AttackInformation may not be able to detect an attack (a false negative).
	The AttackInformation may indicate an attack when no attack is present (a false positive).
Postcondition	If an attack is detected, suitable preventive measures may be applied.

Figure 10.14: Sequence diagram for the use case ‘Detect an intrusion’

IMPLEMENTATION

We need to create a database with attack information so that we can check against this database and decide whether an attack is happening. The incoming event is compared against the database and a decision is made whether the incoming event is an attack or not. The concrete versions of this pattern use different types of information to detect attacks.

The Common Intrusion Detection Framework (CIDF) is a working group created by DARPA in 1998 that is mainly oriented towards creating a common framework in the IDS field. CIDF defined a general IDS architecture based on the consideration of four types of functional modules as shown in Figure 10.15 [Gar09].

Figure 10.15: General CIDF architecture for IDS systems (from [Gar09])

E blocks (‘event-boxes’). This block is composed of sensor elements that monitor the target system, thus acquiring information events to be analyzed by other blocks.
D blocks (‘database-boxes’). These are elements intended to store information from E blocks for subsequent processing by A and R boxes.
A blocks (‘analysis-boxes’). Processing modules for analyzing events and detecting potential hostile behavior.
R blocks (‘response-boxes’). The main function of this type of block is the execution, if any intrusion occurs, of a response to thwart the detected menace.

CONSEQUENCES

The ABSTRACT IDS pattern offers the following benefits:

Communication. If we can detect most attacks, we can safely use the Internet or other insecure networks to access other systems.
Real time behavior. Attacks can be detected when the attack happens and the system alerted, which saves the both time and money in recovery measures, and may prevent misuse of assets. Attacks can be detected in real time if they have sufficient and appropriate information.
Incomplete security. The IDS provides be an added layer of security in addition to encryption, authentication and so on.
Non-suspicious users. A request coming from a non-suspicious address (permitted by a firewall) is further inspected and analyzed.
Flexibility. The detection information can be modified to include new attacks or new behavior.

The pattern also has the following potential liabilities:

Some attacks may be so fast that it may be hard to recognize them in real time.
Attack patterns are closely tied to a given environment (operating system, hardware architecture and so on) and cannot be applied easily to other systems. This means we need to define detection information tailored to an environment.
There is some overhead in the addition of IDSs to a system.
The concrete versions of these systems have additional liabilities.

VARIANTS (CONCRETE PATTERNS)

IDS can be either behavior (rule) based or can be based on anomalies (abnormal behavior). There are significant differences in the use and effectiveness of these two approaches. The patterns for both the SIGNATURE-BASED IDS and BEHAVIOR-BASED IDS are described next.
A hybrid model of both the signature based and behavior based IDS together is now available: a behavior-based IDS detects the anomalies in traffic and then compares the anomalies with an attack signature in a signature-based IDS.
According to the resources they monitor, IDS systems are divided into two categories: host-based IDS systems and network-based IDS systems. Host-based IDS systems are installed locally on host machines and evaluate the activities and access to key servers within the host. Network-based IDS systems inspect the packets passing through the network [Ozg05]. This classification is out of the scope of this book and is not discussed here.

KNOWN USES

NID is a freely-available hybrid intrusion detection package. It monitors network traffic and scans for the presence of known attack signatures, as well as deviations from normal network behavior [Gra00].

10.7 Signature-Based IDS

ALSO KNOWN AS RULE BASED IDS, KNOWLEDGE-BASED IDS The SIGNATURE-BASED IDS pattern describes how to check every request for access to the network against a set of existing attack signatures, to detect possible attacks and trigger an appropriate response.

EXAMPLE

Our company has a firewall to control traffic from the Internet. However we are still plagued by viruses and other attacks that penetrate the firewall. We need to improve our defense against such attacks.

CONTEXT

Distributed systems executing applications that may provide services to remote nodes. Access to the network can be from the Internet or from other external networks.

PROBLEM

Whenever data is accessed from the distrusted networks, there is always a possibility that this access can be harmful to the local node. We need to detect possible attacks while they are occurring. Security techniques such as authentication and firewalls are usually implemented to provide security, but we need additional defenses to detect whether an access request is a possible attack or not. The solution to this problem must resolve the following forces:

Known attacks. It is easier to protect the system against known attacks. Many attacks are new instances of known attacks and have a well-defined attack signature.
Completeness. If we have a complete collection of known attacks and their signatures, it is easier to detect an attack exhibiting one of these signatures.
Flexibility. Hard-coding the type of attack can be done easily, but it will be hard and time-consuming to adapt to attack patterns that keep changing constantly.

SOLUTION

Detect the occurrence of attacks by matching the current attack signature against the signature of previously known attacks.

STRUCTURE

Figure 10.16 shows the class diagram of this pattern. The IDS intercepts an access request for a service. An EventProcessor processes the information and feeds this processed information to a AttackDetector, which tries to match the sequence of requests to the signatures in the AttackSignatureInformation and decides whether or not the request is an intrusion. If an attack is detected by getting a match of signatures, some appropriate Response is raised.

Figure 10.16: Class diagram for the SIGNATURE-BASED IDS pattern

DYNAMICS

We describe the dynamic aspects of the SIGNATURE-BASED IDS pattern using a sequence diagram for the following use case.

Use Case: Detect an Intrusion – Figure 10.17


Summary	The Client requests a service from the Host. The Signature-Based IDS intercepts the message and determines whether the signature of the event matches an existing attack signature. If the request is an attack, appropriate response is raised.
Actors	Client, Server.
Precondition	Information about attack signatures is available.
Description	1 A Client makes a service request for a service to the Host.
	2 The IDS send the request event to an EventProcessor.
	3 The EventProcessor processes the event as required by the AttackDetector and passes the processed event data to the AttackDetector.
	4 The AttackDetector tries to detect whether this request is an attack or not by comparing the signature of the event with the available signatures in the AttackSignatureInformation.
	5 If a match is detected, a Response is created.
Alternate Flows	The AttackSignatureInformation may not be able to detect an attack (a false negative).
	The AttackSignatureInformation can match and may indicate an attack when no attack is present (a false positive).
Postcondition	If an attack is detected while it is happening, suitable preventive measures can be adopted.

Figure 10.17: Sequence diagram for the use case ‘Detect an intrusion’

IMPLEMENTATION

We first need to create a database with a set of all the known or expected attack patterns. We then select a detection algorithm. Some possible detection algorithms are:

Expression matching. The simplest form of misuse detection involves searching the event stream for known attack pattern expressions [Ver02].
State transition analysis. The whole process is a network of states and transitions. Every observed event is applied to finite state machine instances (each representing an attack scenario), possibly causing transitions[Ver02].
Dedicated languages. Some IDS implementations describe intrusion signatures using specialized languages varying from compiled expressions to programming languages such as Java. A signature takes the form of a specialized program, with raw events as input. Any input triggering a filtering program, or input that matches internal alert conditions, is recognized as an attack [Ver02].
Genetic algorithms. A genetic algorithm is used to search for the combination of known attacks (expressed as a binary vector, each element indicating the presence of a particular attack) that best matches the observed event stream [Ver02].

EXAMPLE RESOLVED

We added an intrusion detection system beside the existing firewall to the system. Now any request authorized by the firewall is checked against known attack signatures to detect whether the access request is a possible attack. If we detect an attack, an alert can be raised and the firewall can block the request.

CONSEQUENCES

The SIGNATURE-BASED IDS pattern offers the following benefits:

Known attacks. Detection can be effective against known attacks.
Completeness. If all known attack signatures are available in the database, attacks can be detected in real time.
Flexibility. It is relatively easy to add new attacks to the detection set.

The pattern also has the following potential liabilities:

It only works for known attacks: a new attack will not be detected. We have to constantly update the database with new attack signatures.
Some attacks don’t have well-defined signatures, or the attacker may disguise the signatures. This may lead to false positives and false negatives.
Some attacks may be so fast that it may be hard to recognize them in real time.
Attack patterns are closely tied to a given environment (operating system, hardware architecture, and so on) and cannot be applied easily to other systems.

KNOWN USES

An IDS can be combined with a firewall, as is done in Nokia’s network systems [Nok01].
Cisco IDS utilizes detection techniques including stateful pattern recognition, protocol parsing, heuristic detection and anomaly detection [Cisb].
LIDS is a signature-based intrusion detection/defense system for the Linux kernel [Lid].
RealSecure [Rs] by Internet Security Systems is an IDS adapted by IBM for intrusion detection packages. It can monitor TCP, UDP and ICMP traffic and, if a match is found, countermeasures can be implemented along with read/write server locking, IP blocking and other measures. This product is bundled with CheckPoint Software’s Firewall [Che].

10.8 Behavior-Based IDS

ALSO KNOWN AS ANOMALY-BASED IDS

The BEHAVIOR-BASED IDS pattern describes how to check every request for access against patterns of network traffic in order to detect possible deviations from normal behavior (anomaly) that may indicate an attack and trigger appropriate responses.

EXAMPLE

A company uses a public network for its applications. The network is exposed to security threats, especially a variety of unknown attacks. Their business could be in jeopardy if their customers realize that their system is not secure enough.

CONTEXT

Any network application where the temporal behavior of network traffic is repetitive and predictable.

PROBLEM

Whenever data is accessed from the Internet or other external networks, there is always a possibility that this access can be harmful to the network. We need to detect possible attacks while they are occurring.

The solution to this problem must resolve the following forces:

New attacks. In today’s world networks are constantly bombarded with new attacks that do not have a specific attack signature. We need to detect these kinds of attacks.
Real-time. We need to detect attacks in real time while they are happening, and not after the attack has happened and it is too late to recover from it.
Increased vulnerability. Some networks, such as mobile networks, are more vulnerable to unknown attacks because of their mobile nature.

SOLUTION

Observe the traffic over a network and try to find deviations from normal or expected behavior. Any deviation from normal behavior is treated as a sign of intrusion.

STRUCTURE

Figure 10.18 shows the class diagram for this pattern. A Client requests some service from the system. The IDS intercepts this request and sends it to an EventProcessor. The EventProcessor processes the event data as needed by the AttackDetector, which involves establishing profiles of normal behavior that can be compared with the current behavior in BehaviorProfileInformation, and passes the processed data to the AttackDetector. When an attack is detected, a Response is created.

Figure 10.18: Class diagram for the BEHAVIOR-BASED IDS pattern

DYNAMICS

We present the dynamic aspects of the BEHAVIOR-BASED IDS pattern using sequence diagrams for the following use case.

Use Case: Detect an Intrusion – Figure 10.19


Summary	The Client requests a service from the Host. The behavior-based IDS intercepts the message and determines whether the behavior of the request matches a normal behavior profile. If it does not, an attack is suspected and a response is raised.
Actors	Client, Server.
Precondition	A set of normal behavior profiles is available.
Description	1 Client makes a service request to the Host.
	2 The IDS send the request event to an EventProcessor.
	3 The EventProcessor processes the event as required by the AttackDetector and passes the processed event data to the AttackDetector.
	4 The AttackDetector tries to detect whether this request is an attack or not by comparing the behavior profile of the request with the available behavior profiles in the BehaviorProfileInformation.
	5 If a match is detected, a Response is created.
Alternate Flows	The BehaviorProfileInformation may not be able to detect an attack (a false negative).
	The BehaviorProfileInformation can match and may indicate an attack when no attack is present (a false positive).
Postcondition	If an attack is detected while it is happening, suitable preventive measures can be adopted.

Figure 10.19: Sequence diagram for the use case ‘Detect an intrusion’

IMPLEMENTATION

Examples of techniques used for anomaly detection in practice are:

Genetic algorithms. In this approach, applications are modeled in terms of system calls for different conditions, such as normal behavior, error conditions and attack conditions. A typical genetic algorithm involves two steps. The first step involves coding the input population of the algorithm. The second step involves finding a fitness function to test each individual of the population against some evaluation criteria. In the learning process each event sequence of node behavior forms a gene. Fitness is calculated for a collection of genes. If genes with required fitness cannot be found in the current generation, new sets of genes are evolved through crossover and mutation. The process of evolution continues until genes with the required fitness are found. The detection process involves defining vectors for event data and methods of testing whether the vector indicates an intrusion or not [Kis 10].
Protocol verification. The basis for this approach is the fact that most intruders use irregular or unusual protocol fields, which are not handled properly by application systems [Ver02].
Statistical models. These can be either multivariate models or models based on available statistics such as threshold measures, or mean and standard deviations of the profile. Clustering analysis where clusters represent similar activities or user patterns is also sometimes used [Ver02].

EXAMPLE RESOLVED

We added an intrusion detection system to our network. Now all traffic is checked against a normal behavior profile to see whether the access request is an anomaly and hence a possible attack. We are now able to detect many new attacks that do not have a known signature and prevent them.

CONSEQUENCES

The BEHAVIOR-BASED IDS pattern offers the following benefits:

New attacks. Detection can be effective against new attacks that could cause abnormal behavior in the network traffic. For example, we can identify an attack with a specific behavior, such as when a usually passive web server tries to connect to a large number of addresses, it could be the result of a worm attack.
Real time. This kind of IDS works well with network traffic that exhibits a normal behavior and where it will be easier to detect an abnormal behavior pattern for the network.
Increased vulnerability. This kind of IDS is usually good in wireless networks, which are more vulnerable due to their mobile nature.

The pattern also has the following potential liabilities:

It generates a lot of false positives. Many anomalies detected are not attacks, but could be just unusual behaviors of users.
It cannot be implemented in networks that do not have a predictable traffic pattern.
The technology adopted for one network is not easily portable to another system, and can be different from system to system in a network, as normal behavior for one system is usually not the normal behavior for another system.
If the attacker carries out an attack by mimicking regular traffic or normal behavior, the attack may go undetected.

KNOWN USES

Cisco IPS 4200 Series utilizes detection techniques including stateful pattern recognition, protocol parsing, heuristic detection and anomaly detection [Cisb].
AirTight’s wireless IPS automatically detects, classifies, blocks and locates wireless threats using behavior analysis. They use a genetic algorithm to establish normal behaviors [Air].

Some other uses of anomaly-based IDSs are given in Table 10.1 [Gar09].

Table 10.1 Network-based IDS platforms with anomaly detection functionalities, according to the manufacturer’s information [Gar09]

The Hybrid column indicates hybrid detection, and the Response column indicates that some kind of response mechanism is also available.

Files

ch10.md

Latest commit

History

ch10.md

File metadata and controls

第 10 章 网络安全模式

10.1 Introduction

10.2 Abstract Virtual Private Network

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

IMPLEMENTATION

EXAMPLE RESOLVED

CONSEQUENCES

VARIANTS OR CONCRETE PATTERNS

KNOWN USES

SEE ALSO

10.3 IPSec VPN

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

IMPLEMENTATION

CONSEQUENCES

VARIANTS

KNOWN USES

SEE ALSO

10.4 TLS Virtual Private Network

ALSO KNOWN AS SSL VPN

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

IMPLEMENTATION

EXAMPLE RESOLVED

CONSEQUENCES

KNOWN USES

SEE ALSO

10.5 Transport Layer Security

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

IMPLEMENTATION

STRUCTURE AND DYNAMICS OF THE HANDSHAKE PROTOCOL

EXAMPLE RESOLVED

CONSEQUENCES

VARIANTS

KNOWN USES

SEE ALSO

10.6 Abstract IDS

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

Use Case: Detect an Intrusion – Figure 10.14

IMPLEMENTATION

CONSEQUENCES

VARIANTS (CONCRETE PATTERNS)

KNOWN USES

SEE ALSO

10.7 Signature-Based IDS

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

Use Case: Detect an Intrusion – Figure 10.17

IMPLEMENTATION

EXAMPLE RESOLVED

第 10 章网络安全模式