- Internet & the Web
Sonicwall firewall. Some training notes, protocol and features with network security essentials.
CIA - Confidentiality Integrity and Availability. Palo Alto Firewall. (An application signature based firewall).
We discuss IPSec, NAT, SSL and application proxies.
I will assume that you are familiar with the OSI 7-layer model. This is a very common start for training courses and even job interviews.
The Sonicwall operates at layer-3 : the network layer.
IPv4 is the long-standing Internet Protocol which uses addresses like A.B.C.D and an associated netmask. IPv6 is a new open standard - long suffering to get to popular use. There are many differences between IPv4 and IPv6 but one worth noting is that Internet Protocol Security (IPSec) is built in to IPv6 while it is added into IPv4 by specifying protocol 41 in the header packets.
Inside a header:
An organization called The Internet Assigned Numbers Authority (IANA) defines a particularly interesting field in the header of an Internet Protocol (IP) packet. This is the field that defines the protocol in play for that packet.
Here are some codes:
- 1 - ICMP
- 2 - IGMP
- 4 - IP encapsulated
- 6 - Transmission Control Protocol (TCP)
- 17 - User Datagram Protocol (UDP)
- 41 - IPv6
- 47 - Point to Point protocol uses this (PPTP) Generic Router Encapsulation Protocol (GRE).
- 50 - IPSec Encapsulated Security Header (ESP)
- 51 - IPSec - Authentication Header (AH)
When using IPSec, there are many permutations to enable a particular feature set. For example, authentication and encryption are not only independently available, the method that each uses may be specified at the time of setup. It's commonly known that any particular cryptographic primitive can be broken at an unexpected time. So the ability to plug-in a new primitive is a huge advantage.
Although people associate a VPN with encryption, this is not a necessary requirement. A VPN is a way to use a shared network to create a link which behaves like it is dedicated. Of course, adding authentication and encryption is a common desire.
There are several ways to set up a virtual private network. A VPN is a VPN independently of the method used. If IPSec is used, then this provides authentication and encryption and integrity while another protocol tunneled inside could join two Local Area Networks (LANs) together. Typically this is done by using GRE. (See my article http://hubpages.com/hub/fundamental-digital-security for more information on Confidentiality, Integrity and Availability (CIA).
IPSec mostly operates at layer-3 in the OSI model, while other VPN solutions operate at higher levels. Secure Socket Layer (SSL), Transport Level Security (TLS), Secure SHell (SSH).
Note that IPSec connections use 'mutual authentication'. This means that the client and the server check each other's identity before proceeding. IPSec also encapsulates everything that is sent over the tunnel independently of the application that uses it. SSL, TLS and SSH are controlled by the application so that, for example your browser may hold a particular SSL session open in an encrypted communication with a banking site, while another tab in the same browser is using non-encrypted links to the internet. WIth IPSec, everything that is routed over the tunnel is encrypted. Split tunneling as applied to a tunnel like IPSec, is where some traffic is routed through the tunnel and some through an unencrypted path. Normally, split-tunneling is considered a security risk.
IPSec operates in tunnel mode or transport mode.
Tunnel mode is often used between gateways, or at an end-station to a gateway where the gateway is a proxy for its hosts. The entire packet is encrypted and a new header is attached. The original IP addresses are not visible and only the tunnel endpoints (gateways) are visible. Unless an authentication header is also used, NAT will work. When a gateway terminates a tunnel, it is typical to do so onto a virtual interface so that the rest of the routing and applications which use the data coming from that interface need do nothing special apart from choose the correct virtual interface name. The data entering the physical interface is encrypted, but it comes out (inside the gateway) as an unencrypted packet without any IPSec headers; it looks like normal data.
Transport mode is used between hosts - that is, individual machines. In this case, the original IP addresses are included in the authentication check. This prevents NAT from working because when NAT alters the IP address, the integrity check fails.
Whenever an Authentication Header is used, it breaks NAT.
Transport mode is NOT a VPN. Call it a 'secured connection'. A VPN implies a tunnel. Transport mode does not provide a tunnel.
What in the packet specifies which mode is used?
There is no 'mode' flag so the current mode has to be deduced. This is fairly easy. When the field called 'Next Header' is literally "IP", then this means that the encapsulated packet is a complete IP-datagram. Since this includes the original IP addresses, they are obfuscated and it must be in 'tunnel mode'.
If the next-header field does not specify an entire IP datagram then it is in 'transport mode'.
Values for next header can be, for example:
IP, UDP, TCP, ICMP...
IP is the 'IP' in TCP/IP, UDP/IP... so you can see that TCP and UDP are transmission controls while IP is the transport used in each case. It's the IP layer that handles addresses.
In tunnel mode with AH applied, or in transport mode, NAT is not possible but there is a further encapsulation method called NAT-T (for NAT-traversal) which uses UDP 4500 to apply a routable UDP packet where the payload contains the encrypted packets. Both endpoints must be capable of NAT-T and configured to use it. Before NAT-T is applied, the endpoints check that each can do NAT-T, and they test the path to see if NAT-T is required. If not, then the UDP encapsulation is not used.
Port address Translation (PAT) is also an issue with AH in VPNs because the ports are modified by PAT, and the AH hash includes the port numbers. When the ports are modified, the hash cannot match and the protocol marks it as a failed packet.
In firewall terms - a proxy either operates at layer-4 as SOCKS, or at the application layer as an application which acts as a server to the client, and a client to the server. These are specialised applications and so are limited in number. You are likely to find a legacy program or even a mainstream popular program that cannot use SOCKS or does not have an application level proxy. When a proxy is used, the IP address exposed to the internet is that of the firewall and NAT as IP masquerade is not required for the purpose of hiding internal addresses - or allowing the traffic to route on the internet. The proxy provides a hide-NAT function. But if there is no SOCKS version of the application, or if there is no specific proxy, then you will need to use a NAT function to hide the address.
NAT in more depth
A shortage of IP addresses is one reason to use NAT. Two others are:
Network Masquerading (or IP masquerading)
Hides an entire internal address space behind a single external public address.
Incoming data is only allowed to existing sessions that are in a state table. The state table entry is created when the internal client first makes the connection outbound. The contents of the state table are removed when the link becomes inactive (or it terminates naturally). Those outbound packets leave with the public address as the source address in the header. As the packet flows though the NAT device, its target becomes the original inside-address that initiated the packet.
NAT discretionary forwarding.
A normal router only makes decisions about routing, that is whether to forward a packet as it just follows the information in the header. However, a NAT router can choose to deny or allow and alter packets according to a policy which looks very much like a layer-3 firewall policy. Even the direction (inbound/outbound) is relevant.
A limited range of available addresses for NAT is called a pool of addresses. For example, if you arranged to have 12 externally addressable public IP addresses, then this would be a pool of addresses that are available for outbound connections or inbound connections. This small pool of addresses is successfully shared among a large number of internal users because at any given time, there are only a relatively small number of concurrent sessions. You need a slightly larger pool than the peak number of concurrent sessions.
In the header, the fields that make up the addressing information is checked with a redundancy checksum. It does this to detect errors in the header that could be caused by in-flight interference or data loss. Since NAT changes items in the header field, it must also recalculate and insert a new checksum.
An application proxy acts as a server to the original client, and as a client to the intended server, so it automatically provides an IP masquerading style function. SOCKS does a similar thing, but operates at layer-5.
As mentioned above, there are only a limited number of proxy applications, and therefore, NAT may still be required for applications that have no security proxy.
Only IP addresses are translated
PAT (Port Address Translation) a.k.a NAT Overloading" a.k.a. "Network Address Port Translation” (NAPT).
Both IP addresses and port numbers are translated which tends to break some implementations of IPSec.
Port translation limitations
For example: ICMP packets have no port numbers. But TCP and UDP both have port numbers.
Source NAT (SNAT)
The source IP address and/or source port is translated.
Destination NAT (DNAT)
The destination address and/or destination port is translated.
SNAT and DNAT can be applied at the same time.
Simple traversal of UDP over NATs (STUN)
Old terminology classifies it as:
Full cone NAT, (address)
restricted cone NAT,
port restricted cone NAT or
This is deprecated. The methods have proven faulty and
inadequate but for completeness, here are some definitions:
A confusing and inadequate terminology for NAT. Since NAT combines many of the 'types' described by cone NAT, it has fallen out of use.
This is the least restrictive NAT. It binds a local address and port to a public address and port. Once configured, it can be used by any remote host on any remote port address. It is unlikely to see a firewall configured this way.
Here, only the current external target host can return packets to the designated port. The remote host can use any source port.
Any external target host can return packets to the designated port. The remote host can only use the source port established by the NAT mapping.
This is most restrictive NAT implementation where the source address and port and destination address and port are tied down. Any applications that do referral and handover fail to work over symmetric NAT
Session Traversal Utilities for NAT. (STUN)
RFC 5389 (2008)
This is the modern STUN implementation.
IP Header checksum
Each header has a checksum which is re-calculated. The checksum is only for the header.
If an IP packet becomes fragmented it might be necessary for NAT to reassemble the fragments. Then it can do a recalculation of higher level checksums and track which packets belong to each connection.
MTU Path discovery.
The algorithm in (RFC 1191) experiments with the network path to find out the packet size that can be transmitted without fragmentation. When found, it sets the "don't fragment" bit in the appropriate packet header field.
NAT is a problem for some protocols.
FTP and SIP are examples of applications that send IP addresses within their data stream. Both these use multiple ports and therefore simple NAT will break the IP address and port number relationship between the client and the server.
Unfortunately, NAT is implemented differently by separate vendors and sometimes even within a particular vendor's product range. This means that applications need to dynamically work around the various implementations, and of course this is difficult.
Application Layer Gateway (ALG)
An ALG provides hide-NAT style function and there may be a specific FTP or SIP proxy. If so, then the proxy knows how to be a client to the server, and a server to the client without introducing NAT issues.
Network Address Translation is defined by RFC 3022.
Its purpose is to extend the life of IP version 4 since IPv4 uses a 32 bit address which, although has 4 billion combinations, is comparable to the number of people on Earth. IPv4 addressing would have been fully allocated but for the invention of NAT.
There are some addresses that are not routed on the internet. These are defined as RFC 1918 addresses.
When an organisation uses addresses from these ranges, they are not exposed in the internet. This means that other organisations can use the same addresses, but they cannot directly connect to one another.
To use the internet, an RFC 1918 addressing scheme needs to somehow convert an internal address to a routable intenet-compaitble address. It does this by mapping some unique characteristic of a particular session to an IP address.
RFC 1918 addresses
A NAT 'device' provides translation between the IP address mapping. An organisation can use a NAT device to share a public IP address with the entire internal network.
This makes the edge device look to the internet like a single very busy host because all traffic has the source address of the NAT device. The NAT device works by storing a mapping between the internal address and the source port used by that internal host. It can do this because the source ports are generated at random. It also knows to refuse a connection in the unlikely event that two independent machines generate the same source address at the same time.
When a packet is returned from the internet to the internal device, the NAT device looks up the original IP address in its 'state table'. It can do this because the random port is preserved throughout the session.
Instead of sharing an internet-routable address, it can be mapped to a single internal address. This allows the administrator to have an internal address which could change, while advertising a permanent address to the internet. This also allows a network which uses internal addressing to serve various services (like www) to the internet. The idea can be extended so that different internal addresses are chosen based on other criteria like the arriving packet's destination port and originating address. In this way, multiple internal servers hosting www, ftp, mail all separately could be known to the internet as a single external IP address, but the NAT device directs port 80 traffic to the www server, and port 25 to the mail server, and port 21 traffic to the ftp server.
NAT is quite flexible. Good implementation allow NAT to be applied based on very specific conditions. This provides flexibility. What gets NAT applied can depend on:
Direction though the NAT device – by this, we mean 'who' made the original connection-request.
You can also draw from a specific pool of reserved addresses to control the range over which NAT is used.
Each IP header has a checksum which is used to detect random changes to the packet in transit (errors), so the NAT device must recalculate the checksum
Transport Layer Security (TLS)
TLS encrypts but operates at layer 4 and does not mask the port number so it can solve a problem, for example, when multiple SIP phones are behind a NAT device. Where IPSec won't work, TLS could be used instead for security.
The lifetime of a NAT device's state table is quite short which demands 'keep-alive' messages. Unfortunately battery-powered devices using keep-alive run down quicker when maintaining an active-connection.
NAT Traversal (NAT-T) RFC 3947, RFC 3948
Where NAT causes problems, a NAT traversal technique can help.
These protocols add an extra encapsulation layer onto the affected traffic to protect the contents from the effects of NAT.
NAT-T is available for IPSec. It protects the original authorised packet by encapsulating it using new UDP and IP headers.
UDP port 500 is used for IKE by default.
If NAT is detected between the endpoints, and both endpoints can do NAT-T, and they are configured to use it, then UDP port 4500 is used for IKE and also the ESP data.
Various notes about VPN related stuff
If you have access to a trusted and physically protected network (not the internet), then it may be an Actual Private Network (APN). In that case, encryption is not necessary.
Microsoft's SSTP tunnels Point to Point Protocol (PPP) or L2TP traffic through an SSL 3.0 channel.
The Layer Two Tunnelling (session) Protocol uses registered UDP port 1701. It does not directly provide confidentiality. Instead, it uses a separate encryption protocol, for example L2TP/IPSec
Tunneling Protocol version 3 provides better security and other advantages compared to the older L2TP.
Multi-Protocol Label Switching (MPLS)
An MPLS Wide Area Network (WAN) uses efficient tags to make routing decisions. It is much quicker than conventional routing because header analysis is done only once. It works over several types of network traditionally in the category of APNs - like frame relay and ATM. When VPN is applied to MPLS, then additional efficiency, flexibility and security is obtained. The efficient MPLS network carries the VPN traffic. MPLS combines the performance and capabilities of Layer 2 switching with the scalability of Layer 3 routing.
Secure Socket Layer and Transport Layer Security normally gives a web-browser session-based encryption but OpenVPN uses it to encrypt the whole OSI stack. Since SSL uses port 443 which is normally permitted outbound from any organization, it has this advantage over IPSec. OpenVPN can run over UDP and it enjoys wide operating system support.
Datagram Transport Layer Service (DTLS) is good for securing applications that are delay
sensitive. For example, for VOICE, the Session Initiation Protocol (SIP) is often preferably run over UDP but since TLS demands a reliable transport (i.e. TCP) this means that TLS is not always good choice for tunneling SIP. DTLS is a datagram version of TLS.
A few words about hashes and encryption. (IPSec)
A hash is a number derived from a message which is in-practice unique to that message. Therefore, if a message is changed in transit, then a re-calculation of the hash will reveal a difference and expose the interception. MD5 and SHA-1 are commonly used hashes. The hash is known as Integrity Check Value (ICV).
Computation of the ICV in IPSec depends upon a shared secret and if the secret has been shared in a secure manner then it effectively authenticates the parties involved. The ICV thus inherits the capability to authenticate the end-points.
The AH always provides authentication, and ESP optionally provides it.
ESP provides encryption by use of a peer-reviewed strong
encryption algorithm like the Advanced Encryption Algorithm (AES) or
triple-Defence Encryption Standard (3-DES).
To share a key, and to frequently refresh keys, IPSec uses an Internet Key Exchange (IKE) protocol. For testing purposes, manual keying is permitted but it is not considered a solid method to use in production.
Within IKE, you will find some modes.
Main mode is slow but secure. - six packets are exchanged and all are encrypted.
Aggressive mode is fast but less secure – only three packets are
exchanged, and some information is in plain text. The aggressive mode with a fixed pre-shared key is possibly subject to a dictionary attack, so make the pre-shared key very strong if you have to use that combination.
A Security Association (SA) is little more than a database record in a security Association Database (SADB). In it, you find details of the negotiated algorithms, timings, destination address and other parameters which have been agreed upon for a particular IPSec exchange. There is a pair of agreeing SA records in the sender and the receiver for both outbound and inbound data. Therefore, for any tunnel, you will find a total of four SAs. Each of these SA records is indexed by a Security Parameter Index (SPI). In this way, multiple tunnels and tunnels that independently link different networks are allowed on a single unit. In fact, multicast is allowed by duplicating the SA across all members of a group.
AH (protocol 51)
AH runs a hash over the contents of the packet - excluding so called 'mutable' fields like the Time To Live (TTL) field. AH permits mutual authentication, tamper detection and message integrity. AH does not provide encryption but it does guard against a replay attack.
The AH includes five interesting fields.
- Next header
- SPI - 32-bit identifier
- length of the AH
- Sequence number
- Authentication data (The ICV)
If IP addresses are part of an integrity check, then a
protocol like Network Address Translation (NAT) can look like a
malicious attack. In that case, you need to hook in NAT-Tas discussed above.
ESP (protocol 50)
ESP surrounds the payload with a header and a trailer and encrypts the payload. This provides confidentiality and protects against a replay attack. ESP provides tunnel and transport modes.
In the trailer is:
- 'next' header
- Authentication Data (optional)
Although ESP independently provides authentication separately to encryption, to use encryption without authentication is an insecure configuration
ESP calls in an external encryption algorithm and does not directly implement it. It is interesting and perhaps useful only for testing, that ESP allows a 'null' encryption algorithm. Thus ESP could be configured without AH or an effective encryption method.
HMAC (RFC 2104)
The HMAC ICV is constructed as follows. (Please refer to the diagram).
- Given a message...
- A magic number (random digits) is padded to a fixed block size by appending nulls. (ipad)
- Given a pre-shared key, or a fresh key...
- 1 and 3 are combined with the XOR function.
- 4 and 1 are appended
- 5 is hashed
- The key (3) is combined with another fixed block padded magic number. (opad)
- 7 and 6 are hashed
This gives an HMAC of the message. Note that although the HASH can be applied by an onlooker, the onlooker does not know the key and so cannot reproduce the particular hash result. Also, the magic numbers are padded to a fixed block size to thwart particular kinds of crytpanalysis and to fit in with algorithms that use a fixed block size. The magic numbers provide a variation in result even when the same message is re-sent. Otherwise a statistical cryptanalysis attack could be performed on similar data or known plain-text. Since the sender and receiver share the key, they can extract the magic numbers and the message. The fact that the sender and receiver were authenticated during the key exchange, the message is also authenticated.
What is the difference between customer and service provider provisioned VPNs?
There is a marked difference between a VPN provisioned by a customer and one at a provider. When the customer does it, the providers end-point devices are unaware of the VPN and the customer's equipment terminates the VPN. When the provider manages the VPN, the provider's equipment terminates the VPNs for one or more customers.