IPsec Framework

IPSEC, short for IP Security, is a suite of protocols, standards, and algorithms to secure traffic over an untrusted network, such as the Internet. IPSEC is supported on both Cisco IOS devices and PIX Firewalls.
IPsec is not a single protocol, but a framework for securing IP communications.

IPsec Overview

• We can add IPsec to IPv4 or IPv6 by using additional headers.
• IPsec can then both encrypt and authenticate each IP packet of a session between hosts on a LAN or across the internet.
• If we look at security tools in the TCP/IP stack, we see that IPsec provides security at the network layer and can protect a much wider range of application than SSL.

IPsec has four main components:

• Security protocols:
• The security protocols include the Authentication Header (AH). Now this provides support for data integrity and authentication of IP packets.
• And the Encapsulating Security Payload (ESP) provides a combination encryption and authentication of IP packets.
• Key Management:
• Key management can either use manual, which is practical for small static environments, or automated using the Internet Key Exchange (IKE) in an enterprise network.
• Security Associations:
• Security Associations is a relationship between two entities and describes the components for the entities including the security protocols, algorithms, and keys required for the services requested for either the Encapsulating Security Payload protocol or the Authentication Header process.
• Algorithms:
• Now, within the security association, you see several different algorithms.
• Algorithms are essential in providing the following: Key exchange, integrity, encryption, and authentication.

IPsec Benefits

• IPsec provides flexibility in how it’s set up and what level of security is required.
• IPsec can protect one or more paths that include host to host, gateway to gateway, and outside host to the gateway.
• Services IPsec can provide include access control, integrity, authentication, preventing replay attacks, and confidentiality.
• IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services.
• IPsec can be used to protect one or more "paths" between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.

IPsec Framework

• On the left-hand side, we see the encapsulating security payload protocol which includes encryption algorithms such as AES cipher-block chaining mode.
• On the right, we see the authentication header protocol, which includes authentication algorithms such as SHA-256.
• And because cryptographic techniques and algorithms rely on keys, encompassing all of this thing is key management.

IPsec is an internet exchange taskforce standard that outlines how we can configure a VPN to secure traffic across an insecure network.
Because IPsec works at the network layer, it can then protect upper layer traffic.

The IPSEC standard is outlined in RFC 2401.

IPsec services

IPsec provides many services. IPSEC provides below four core services:

• Confidentiality – prevents the theft of data, using encryption. By encrypting our data, nobody except the sender and receiver will be able to read our data.
• Integrity – ensures that data is not tampered or altered, using a hashing algorithm. We want to make sure that nobody changes the data in our packets. By calculating a hash value, the sender and receiver will be able to check if changes have been made to the packet.
• Authentication – confirms the identity of the host sending data, using pre-shared keys or a Certificate Authority (CA). The sender and receiver will authenticate each other to make sure that we are really talking with the device we intend to.
• Anti-replay – prevents duplication of encrypted packets, by assigning a unique sequencing number. Even if a packet is encrypted and authenticated, an attacker could try to capture these packets and send them again. By using sequence numbers, IPsec will not transmit any duplicate packets.

It provides:

• Confidentiality using encryption
• Integrity using hash algorithms
• Authentication using key exchange
• Secure key exchange using Diffie-Hellman.

Confidentiality and Encryption

Data sent in clear text across the Internet can easily be intercepted and stolen. Because of this, sensitive data should be encrypted when sent across an untrusted network or domain. Keys are generated values used to both encrypt and decrypt data. The longer the key, the more secure that key is. The length of a key is measured in bits.

Two types of keys exist:

• Symmetric keys can be used to both encrypt and decrypt data. More specifically, the same key is used to both encrypt a packet (at the sending device) and then decrypt that packet (at the receiving device). 
• Symmetric key encryption is efficient but does not scale well in large environments.
• Symmetric keys are not openly shared during data transmit and must instead be installed on each machine prior to the transfer of data. 
• This can be accomplished using a variety of (inefficient and insecure) methods: email, sneaker-net, and even snail-mail. 
• Each device on a network would require every other device’s symmetric key, and thus the lack of scalability.
• Asymmetric keys require a separate key for encryption (the public key) and decryption (the private key). 
• Public keys are openly exchanged between devices to encrypt data during transfer. 
• Private keys are never exchanged. Only the private keys can decrypt the data.
• Thus, even if the data and the public keys were intercepted, confidentiality is ensured.

Diffie-Hellman (D-H) Public Key Exchange is the most common standard used to create and exchange keys across insecure mediums. D-H is not used to encrypt data, but rather to generate the keys that are used to encrypt and decrypt data.
A variety of popular standards and protocols utilize D-H key exchange, including SSL (Secure Socket Layer), SSH (Secure Shell), and IPSEC.
The generated public keys encrypt data payload using one of several available encryption algorithms:

• DES (Data Encryption Standard) – 56-bit key
• 3DES (Triple Data Encryption Standard) – 168-bit key
• AES (Advanced Encryption Standard) - 128, 192, or 256-bit key
• Blowfish – up to a 448-bit key

Additionally, the strength of a key is determined by the D-H group used to generate that key. There are several D-H groups:

• Group 1 – 768 bits
• Group 2 – 1024 bits
• Group 5 – 2048 bits

Data Integrity and Hashing

Data sent across the Internet can not only be stolen but can also be maliciously altered.
To combat this, a hashing algorithm computes and appends a specific hash value as each packet is sent. Once the data is received, it is run through the hashing algorithm again. If the hash value is different, the packet was altered in transit.
Hashed Message Authentication Code (HMAC) is used to perform this hashing function. HMAC utilizes a secret key when computing the hash value, thus preventing an attacker from altering the packet and then recomputing the correct hash.
Two HMAC algorithms are commonly used:

• HMAC-MD5 (Message-Digest 5) – 128-bit hashed key
• HMAC-SHA1 (Secure Hash Algorithm) – 160-bit hashed key

Authentication using key exchange

Another concern when sending data across the Internet is the source or origin of that data. 

It is possible to masquerade or spoof one’s identity or address.
For an IPSEC VPN tunnel to be established, both sides of the tunnel must be authenticated. 
To accomplish this, either pre-shared keys or RSA digital signatures are used.

• When using pre-shared keys, a secret string of text is used on each device to authenticate each other. This string must be pre-agreed upon and identical on each device. This string is then hashed into a digital signature.
• When using RSA Digital signatures, a Certificate Authority (CA) is used to apply a verified digital signature. 

One of the above options must be correctly configured before the VPN tunnel will become active.

Certificate Authorities

Remember, two methods exist to authenticate an IPSEC tunnel:

• When using pre-shared keys, a secret string of text is used on each device to authenticate each other. This string must be pre-agreed upon and identical on each device. This string is then hashed into a digital signature.
• When using RSA Digital signatures, a Certificate Authority (CA) is used to apply a verified digital signature. This provides a more scalable solution than pre-shared keys.

The certificate process works as follows:

1. First, a client creates a “blank” or unsigned certificate, and sends it to the CA. Included on this blank certificate is the client’s ID. This communication is secured using a D-H private/public key exchange.
2. Next, the CA computes an encrypted hash, which is applied to the blank certificate. Thus, the certificate is now signed with the CA’s digital signature. The signed certificate is sent back to the client, where it is stored until it is deleted or expires.
3. The client then sends the signed certificate, along with its keys, to any VPN peers, “authenticating” its origin.

REMEMBER: Digital signatures, and Certificate Authority servers, are not used to encrypt data. Instead, the digital signatures are used to authenticate a device’s keys. Essentially, the digital signature gives the key a stamp of authenticity.

Obviously, one must “trust” the CA that signs these digital certificates. This is why third-party CAs are often used, such as VeriSign or Entrust.
Cisco IOS devices can function with several CA vendors:

• Microsoft Windows Certificate Services
• Entrust
• VeriSign

Regardless of the vendor chosen, the CA must support the Simple Certificate Enrollment Protocol (SCEP) to work with Cisco IOS devices.
This is available on the server Resource Kit for Windows Certificate Servers.

Configure IPsec

• The network administrator has flexibility in the way they can configure IPsec.
• During configuration, when preparing the site for IPsec, the device will list the most current options. And then once the network administrator has made the selection, IPsec will then create the security association.
• A security association is a relationship between two entities and describes the components for the entities, including the security protocols, algorithms and key required for the services requested.
• And then both sides must share the same security association.

Final IPsec Frameworks

As a framework, IPsec uses a variety of protocols to implement the features as described above. Here’s an final overview:

IPsec can be used on many different devices, it’s used on routers, firewalls, hosts and servers. Here are some examples how you can use it:

• Between two routers to create a site-to-site VPN that “bridges” two LANs together.
• Between a firewall and windows host for remote access VPN.
• Between two linux servers to protect an insecure protocol like telnet.

Key Management

Now, key management is also another consideration, and, in most cases, the network administrator will opt for dynamic key exchange, and this allows the VPN servers on each end of the connection to negotiate new keys at specified intervals using internet key exchange.
Now, Internet Key Exchange (IKE) is a protocol used to setup security association in IPsec.
This provides a standard method for dynamically authenticating IPsec peers, negotiating security services and generating shared keys.

IKE Functions
Internet Key Exchange (IKE) has two distinct functions.

• ISAKMP (Internet Security Association and Key Management Protocol, defines procedures for authenticating a communicating peer, and the creation and management of security association key generation techniques.
• Oakley is a key distribution process that supports perfect forward secrecy. Oakley allows the devices to exchange keys using Diffie-Hellman key exchange algorithm.

Now you have an idea of the basics of IPsec.
Now, in later section will take a closer look at each of the different components.

DNS Security

DNS Cache Poisoning Attack

DNS cache poisoning attack, which is also known as DNS spoofing attack.

• If you recall from our previous lesson on caching in the name resolution section, caching is used extensively in the DNS, with the aim to save network bandwidth and reduce lookup latency.
• The purpose of the DNS cache poisoning attack is to abuse the way DNS caches work by poisoning the resolver’s cache with the goal of achieving DNS spoofing.
• So that name lookups originated from a client, answered by a malicious actor who redirects, then use it to a fraudulent web page.
• That website would typically be a mirror of a legitimate site so that once the end users are redirected that they are tricked into taking a specific set of actions engineered by the attacker.
• Some of those actions could involve presenting authentication problems, encouraging the victim to supply their credentials, or luring the user into downloading files infected with malware.
• The impact of this attack can be substantial, since it can lead to stolen credentials, data theft, critical data encrypted with ransomware, compromised hosts that become bots as part of a botnet and much more.
• If done correctly, not only the attacker would be able to accomplish their aims, but also the end user would remain completely unaware of the fact that they fell victim to this cyber-attack.

The DNS cache poisoning attack has four main threat vectors.

• Man in the middle attack: Whereby the attacker places themselves between the client and the server by using tools such as OPS tool and can modify the Mac addresses in the DNS resolvers table, causing it to think that the attacker's computer belongs to the client.
• At the same time, by utilizing the same tool, the client is also tricked into thinking that the system controlled by the attacker is the DNS server.
• At the end of this process, the attacker can then use a tool, such as DNS spoof to direct all DNS requests to the fake sites designed by the attacker.
• DNS server hijacking: This entails compromising the DNS resolver directly with a goal of injecting false data into its cache to achieve DNS spoofing and redirect the client to the attacker's site.
• Client machine hijacking: Just like with DNS server hijacking, this factor involves compromising the client directly. Once the attacker has gained access to the client, they can proceed to injecting false DNS data in the host's file, which, as you remember from the local name resolution section, is consulted by the operating system before DNS kicks in by poisoning the host file. Therefore, the attacker can accomplish DNS spoofing again without even having to worry about the DNS resolver.
• Birthday attack: This is when the attacker tries to get the transaction id of the client's DNS request, so that it can respond to it with a false response of their own, thus poisoning the cache of the DNS resolver, which from that point on will be saving the attacker's IP address.

Mitigation measures:

• DNSSEC: The DNSSEC is short for Domain name system security extensions, and it is a means of verifying DNS data integrity and origin. DNS uses public key signature to verify and authenticate data, thus preventing forgery. The downside to using DNSSEC, is that when the DNS resolver needs to verify the signature with the authoritative DNS server, the entire process of name resolution slows down. This is the reason why a DNSSEC is still not widely adopted.
• DNS over HTTPs (DoH) and DNS over TLS (DoT): These standards are competing specifications designed to keep DNS requests secure without sacrificing speed like DNSSEC.
• Unlike DNSSEC, which verifies the identity of the DNS root service, an authoritative name service in communication with DNS resolvers, the DoH and DoT encrypt DNS traffic, making it harder for attackers to tamper with DNS requests and responses while in transit.
• The most important difference between the two standards is that DoH chooses Port 443, whereas DoT uses Port 853.
• Patching DNS software: So, if, for example, you have configured your DNS resolver with bind, make sure that you're using bind latest version and that you keep up to date with all the latest security patches.
• Applying endpoint security: Do not forget to harden your client systems by applying appropriate endpoint security to reduce the attack surface to prevent client machine hijacking attacks.

NXDOMAIN Attack

The NXDOMAIN attack is a DNS based denial of service attack, which aims at disrupting the availability of the DNS server by flooding it with requests for invalid or non-existent records.

• Using a tool, the attacker can generate and transmit large volumes of unique subdomains for each request sent to the DNS resolver. As a result, the DNS resolvers continued attempts to resolve the fake domains in the attacker's name lookup requests lead to high resource utilization on the DNS resolver itself, which finds it more difficult to respond to legitimate requests.
• On top of that, since the records queried by the attacker do not exist, the DNS resolvers’ cache is being filled up with an NXdomain replies, slowing down the service response time for legitimate requests even further. When the cache gets filled up with an NXDOMAIN response, valid. cache entries get pushed out, resulting in further service degradation.

The two main symptoms of an NXDOMAIN attack.

• The cache of the DNS server gets filled with NXDomain records, while at the same time resource utilization increases, which makes it more difficult for legitimate regime requests to be answered by the same server.

Mitigation Measures

• Restrict DNS queries to trusted clients.
• Block the offending source IP addresses.
• Flush the cache on the DNS resolver.
• Use dedicated solutions by specialized vendors.

DNS Query Flood Attack

The DNS Query flood attack is another DNS based denial of service attack, which aims at disrupting the availability of the DNS server by flooding it with name requests.

Mitigation Measures

• Restrict DNS queries to trusted clients
• Block the offending source IP addresses
• Rate limiting
• Deploy a Cache-only DNS server
• Overprovision bandwidth on the name server

Phantom Domain Attack

But what about attacks that take the form of requests against real domains whose name servers simply do not respond?
Well, there is just such an attack that is known as phantom domain attack.

• In a phantom domain attack, the malicious actor lays the groundwork by first configuring several domains. Then they configure the authoritative name servers of those domains to either respond to requests very slowly or not respond at all.
• Once they have done this work, the attacker then proceeds to sending a huge number of queries to the victim DNS resolver, which must spend time and resources doing the recursion against the records of the phantom domains, whose name servers will simply not respond.
• As such, the phantom domain attack is yet another type of DNS based denial of service attack, since its goal is to exhaust the resources of the DNS resolver and disrupt its availability for legitimate uses.

Mitigation Measures

• Rate limiting
• Restricting recursive queries per server and per zone
• Using dedicated solutions by specialized vendors
• So, for example, if F5 Big IP is designed to time out the connection and release the requests in the queue so that the resolver doesn't need to wait for responses that will never come.