In the last post we saw a basic firewall using Ubuntu’s iptables/netfilter. We have our router host ready. Let’s see how to set up snort in packet sniffer, packet logger, Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) modes on the network.
Packet sniffer mode: snort -v
Packet logger mode: snort -l <logging dir> By default the logging directory is /var/log/snort
Intrusion detection mode (IDS) mode: Also known as alert mode, Snort requires configuration file, rule set and the path to these files. The default location for the configuration file is /etc/snort/snort.conf. We don’t have to change many variables in this file other than RULE_PATH to the path of your rules file. “include $RULE_PATH/mynew.rules. mynew.rules is the file where I have defined my rules. Coming to rule set, the default location to rules is /etc/snort/rules. Rules include: 1. Alert when icmp pings are detected in both directions. 2. Alert when connection to facebook.com is done on a web browser by host 10.0.0.4 (Ubuntu-VM Clone)
Fig 1: Snort rules
Let me remind the network that was set up earlier. See Fig 2. Note that snort is running on router host (Ubuntu-VM)
Fig 2: Snort is running on router host
To see if snort alerts us on pinging Router host or modem from 10.0.0.4. See Fig 3. The syntax for IDS mode is snort -c <path to conf file> -l <path to log file> -I <interface snort should be listening to>. -A console is to display alerts on screen while snort is running. -q is to quiet mode (avoids banners and status report)
Fig 3: 10.0.0.4 is pinging 192.168.1.1=> Ping detected alerts for both ingress and egress pings.
Let’s check what happens when 10.0.0.4 tries to access facebook.com. See Fig 4. Going bak to Fig 1, the rule option used is “content”. Therefore snort checks the content of IP packet to look for a match.
Fig 4: facebook.com is opened on web browser, snort alerts the event.
The last mode is the IPS mode. I will write about it next week.
For this purpose, I have two VMs – Ubuntu-VM and Ubuntu-VM Clone.
Let’s say we want to turn Ubuntu-VM into a router. To be able to do that, two NICs have to be enabled and put in two different subnets and ip-forwarding should be enabled on Ubuntu-VM. Remember to have the interfaces on VMs in bridged mode.
Fig 1: Two Ubuntu-VMsFig 2: On Ubuntu-VM, turn on Adapter 2; Enable bridged mode on all interfaces
Network setup should look something like this, see Fig 3:
Fig 3: Network Diagram
Once you configure all the interfaces, check internet connectivity on the host (Ubuntu-VM Clone)
Fig 4: Shows that the host has no Internet
At this point, we have to enable ip forwarding on our router host and add some rules to netfilter/iptable.
Fig 5: On Router host, enable ip forwarding by setting /proc/sys/net/ipv4/ip_forward to 1Fig 6: Firewall rules on router host
It is convenient to make a bash script like the one above. Host might not still have DNS. You would have to edit /etc/resolv.conf to add “nameserver 8.8.8.8” (8.8.8.8 being Google’s public DNS). Let’s see if our host has internet now.
Fig 7: Host is setup successfully.
It also means that router host is forwarding packets from its external interface to internal interface. One of the functions of a router has been accomplished.
References: 1. Jungwoo Ryoo’s topic on LinkedIn Learning – Host as a router
When you try to reach www.apple.com, you are making use of Content Delivery Network. In fact, there are chances your request would not have to reach origin at all. Instead a cached host on CDN serves your request. To know if a domain is making use of CDN, you can type host $domain_name on terminal.
Figure 1: www.apple.com is hosted in Akamai’s CDN
To explain briefly, CDN is a distributed network of hosts that acts as proxy for the origin servers. For example, we now know www.apple.com is hosted on Akamai’s CDN. The intension of using CDN is to reduce latency, increase efficiency in uploads and downloads, decrease load on origin, quicker and secure transactions and so on. Akamai achieves this by maintaining highly-distributed network all over the globe. In Figure 1, you will see the domain www.apple.com has a canonical name (CNAME) record to it- www.apple.com.edgekey.net. DNS does its thing, when the request comes to third-level domain while resolving, the nameserver will present this canonical name, the resolver then restarts the process with this cname all over again. Akamai is authoritative of the cname, its nameservers, now with the cname follow the mapping protocols/alogorithms that will point your resolver to the nearest host. If you are in San Jose, California, you’d be served by a host in San Jose. If you are in Bangalore, India, you’d be served by a host in Bangalore. CDNs can be so vast.
CDNs provide various services to customers. CDNs host e-commerce, health-care and government websites along with less secure domains. Secure transactions between clients and origins happen via CDNs. This brings us to a few questions- how CDNs manage customers’ digital certificates or how TLS handshake is completed between clients and the edge hosts (belonging to CDN) or when you say the request doesn’t reach the origin, how does client know what domain is the request for (because some CDNs like Akamai host thousands of domains on a single machine and the ClientHello does not have domain name information).
In this article, I will try to write down two important types of TLS technologies used by Cloudflare and Akamai Technologies (Two of major CDNs in the industry today).
Internet traffic is moving faster towards HTTPS. According to Google’s report, 73% of pages loaded in US use HTTPS up from 59% last year. Cloudflare introduced Keyless SSL to the world. CDNs or cloud vendors should posses customer’s private key in order to accomplish SSL/TLS encryption. This also means that the vendor can read the content in transit raising security concerns.
Keyless SSL:
Keyless SSL technology used by Cloudflare is a workaround to storing private keys on vendor’s platform. Cloudflare does this by transferring the steps in the handshake that require private key over to customer’s key server. Compare client-server TLS handshake and Figure 2.
Figure 2: Keyless SSL Handshake (RSA)
As you can see in Figure 2, decryption of pre-master key is the step where origin’s private key is required. Cloudflare makes a roundtrip to origin to get this done. Even though private key is used, vendor is not in possession of the private key. Hence the word “keyless”.
TLS SNI:
Akamai achieves this by taking advantage of combination of Domain Validated (DV) and Organization Validated (OV) certificates and Server Name Identification (SNI).
Akamai uses two certificates – Origin server certificate and Akamai network server certificate. Origin server cert secures content in transit from origin to Akamai machines (This is used when edge machines are not cached, as a result request hits the origin). Akamai network server certs secure content in transit from Akamai machines to clients.
Onboarding and Configuration Assistant (OCA) process on Akamai’s web portal enables customers to create two certificate for their origin domain. DV certificate is just like you get digital certificate for domains owned by you (Eg. from Let’s Encrypt) but an additional step is to add DNS redirects pointing to Akamai CNAMEs. OV certificate involves CA calling up origin domain owner to verify if the request is legitimate once Akamai sends certificate signing request form to CA. Both these certificates form Akamai network server certificate.
Now we have certificates ready. Akamai has huge number of customers and with IPv4 being scarce, it is difficult to assign one IP to each hostname. With IPv6 scalability will not be a problem but not all websites support IPv6 yet. SNI lets CDNs use IPv4 IPs/VIPs very efficiently. It lets a single host shelter thousands of certificates and be successful in responding the clienthello packet with valid certificate. Without SNI, ClientHello packet in TLS handshake does not have hostname. Edge will not be able to identify customer with IP address as there is no 1-1 mapping. But clients with SNI enabled, send hostname in the ClientHello packet allowing the edge server to reply with valid certificate back in ServerHello packet enabling virtual hosting.
What are your views on security issues involving these two technologies?
While following the above, I faced “404 error” and the verification of my domain wouldn’t go through. I read solutions on some forums and got an idea that basically I have to let my cPanel know to read any file without an extension as a .txt file. This change can be added in MIME settings on cPanel. But my MIME types already had an entry for file without extension:
text/pain as txt
But my verification wouldn’t succeed. So what I did was to save the file without .txt in ~/.well-known/acme-challenge on cPanel.
Adding files generated by Let’s Encrypt to cPanel without .txt
This worked!
Please let me know if there are other ways to this.
HTTPS (HyperText Transfer Protocol Secure) is such an amazing protocol that does most of the heavy lifting on Internet. Yet, I feel we do not give enough credits to it. It is an interesting concept that involves quite a few components.
HTTPS is based on SSL/TLS (Secure Sockets Layer/Transport Layer Security) encryption. TLS encryption protocol is used to encrypt network data. The protocol uses encryption, hashing, digital certificates to provide confidentiality, integrity and authentication for data in transit.
Encryption (Confidentiality):
The main difference between symmetric and asymmetric encryption is the way keys are incorporated for encryption and decryption. Symmetric encryption like AES and 3DES use single key for both encryption and decryption. In other words, one key is generated that encrypts data on one end and the same key decrypts data on the other end. That means, the symmetric key used in this process must be transported, over a medium, to end-users that are intended to view the data. Asymmetric encryption such as RSA and Diffie Hellman use two different keys – one for encryption and one for decryption. The key used to encrypt data cannot be used to decrypt. Asymmetric encryption has a key pair, public key and private key, that are mathematically related. If public key is used to encrypt data, then private key is used for decryption and the other way around. Symmetric encryption suffers key management problem. It is difficult to transport key before a secure tunnel has been established. This calls for use of asymmetric encryption where no actual keys are transported. Only the pre-required key material essential to generate session keys is transported over the network. Session keys never travel on the network. But symmetric ciphers are preferred over asymmetric ciphers for encrypting/decrypting large amount of data as the symmetric ciphers are computationally much faster than asymmetric ciphers. Therefore, conjunction of both symmetric and asymmetric encryption is preferred. Asymmetric encryption is used to generate or exchange the secret keys that are used to derive session keys. Session keys which are also called symmetric keys will be used to encrypt and decrypt large data. Session keys can be one time use keys, they are discarded once the session is completed. This achieves the goal of securing keys, keep it computationally faster, hence making the system robust.
Before we proceed, let’s have a look at TLS handshake:
Fig. 1.1: TLS Handshake
“Key Exchange” in the above figure is where the asymmetric encryption comes to picture.
Going back to encryption, let’s look at “Key Exchange” in detail.
We now know public (asymmetric) key encryption is used in key exchange during TLS handshake. When using RSA or DSA encryption, client generates pre-master key and this is used on both sides to generate master keys and eventually the session keys. This will be the essential component to arrive at the final keys used to encrypt/decrypt. Now, pre-master key must remain private to protect confidentiality of the session. Client encrypts this key with server’s public key (obtained from servers digital certificate). Only server that has private key of the key-pair can decrypt the message. Both sides now have the pre-master key. Using the parameters exchanged during TLS session and the pre-master key, both sides apply pseudo random function to generate master secret. Sessions keys are eventually derived from master keys on both ends. Master secrets or session keys are never transported on the session. After both the sides have the session keys, data sent back and forth is encrypted and this is going to be symmetric encryption. Because both client and server use the same key (session key). Fig 1.2 shows the steps involved in Key Exchange with RSA(Rivest–Shamir–Adleman).
Fig. 1.2: Key Exchange with RSA
When using Diffie-Hellman, only the public DH components are sent back and forth. The private components remain remain private to each side. No secret keys essential to produce session keys are shared on the network, therefore these components are not encrypted at all. The term “key exchange” doesn’t make sense when referring to DH algorithm. Sometimes this process is called key generation. DH algorithm works in such a way that whatever components are shared in public domain cannot by themselves be used to compromise the session. That is why the key generation process does not use encryption. Fig. 1.3 depicts the steps involved in Key Exchange with DH.
Fig. 1.3: Key Exchange with DH
Wireshark is a strong tool to capture and analyze packets. Let’s see how TLS handshake actually looks when you open up your browser and try to connect an https website.
2. Dissecting TLS with Wireshark
Fig. 2.1: TLS Handshake
Fig. 2.1 shows the entire TLS handshake. Let’s look at each message closely.
[NB: After capturing this session and working on it, I realized DH encryption is used and therefore Fig. 1.1 changes slightly. Fig 1.4 shows TLS Handshake when DH encryption is used]
Fig. 1.4: TLS Handshake with DH
In Fig. 1.4 you will notice that in most cases Server Key Exchange happens before Client Key Exchange. That is because both client and server generate their DH components independently.
Let’s get back to our Wireshark packets.
Fig. 2.2: Client Hello
In this capture (Fig. 2.2), we see that the client prefers TLS 1.2 but the minimum it can offer is TLS 1.0. Which means, if server prefers 1.0, client can support that. You also see that client hello record contains random data that the server will need later for authentication of the keys (or handshake in general). Next is the Cipher Suites – this will be the list of ciphers that my browser, safari 12.1, can offer.
Fig. 2.3: Client Hello Cipher Suites
Client Hello sends server all ciphers that it supports. Fig. 2.3. This is followed by Server Hello.
Fig. 2.4: Server Hello
The data sent out to client in Server Hello are the TLS version and the cipher chosen by the server and the random string that client will use later for authentication.
Cipher Suite chosen is: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Breaking this down:
TLS – This simply indicates the protocol
ECDHE – Ephemeral Elliptic-Curve Diffie-Hellman public key encryption is used for key exchange
SHA384 – MAC (Message Authentication Code) Algorithm.
Next packet to follow is Server Certificate (Authentication).
Fig 2.5: Server Certificate
Server sends its certificate to the client. Certificate has information such as the Certificate Authority (CA) or the intermediate CA that has signed it. The domain name, authentication and hashing algorithm that it can support.
Fig. 2.6: Digital certificate
You can see that Google Internet Authority G3 is the intermediate authority that issues certificates for all of google domains which are in turn signed by GlobalSign – Root Certificate Authority. When a certificate is signed by intermediate authority, all intermediate CAs must attach the Root CA digitally signed certificate to complete certificate chain.
When client receives this certificate, it checks for three things:
The digital certificate itself
The Certificate chain (Intermediate CAs and Root CA)
Validity of the certificate
The revocation status of the certificate
We will see key exchange messages next.
We saw that the chosen encryption algorithm is DH, so the server sends the public DH components to client in Server Key Exchange packet and that is followed by Server Hello done through which server conveys it is done passing all the parameters.
Fig. 2.7: Server Key Exchange and Server Hello Done
Once the client checks out the certificate (authentication accomplished), it sends the public DH components just like server did. This is followed by Change Cipher Spec which indicates all the messages sent by client from on now will be encrypted using the session key. The last message from client to server is the Finished message that has the hash of handshake components encrypted with session key. This will be used by server to ensure integrity of the handshake process. Since it is encrypted, Wireshark labels it as Encrypted Handshake Message. See Fig. 2.8.
The last message of the handshake from server to client will be Change Cipher Spec indicating that the following messages will be encrypted using session key and the encrypted Finished message. Like client, server sends the hash of the handshake components encrypted with session key to ensure integrity. If both client and server determine the other’s finished message is correct, this will open a secure tunnel for bulk data exchange. See Fig. 2.9.
