Verification
It’s time to test your configurations and see the magic—how a threat defense analyzes encrypted traffic and blocks a file despite its transfer over an encrypted session. This section assumes that your lab environment has a web server with the TLS protocol enabled. The web server is located at the outside zone of your threat defense installation, as shown in Figure 18-20. The site displays a file directory, where one of the files is of the executable file type (.exe extension).
Figure 18-20 Lab Environment Used in This Chapter to Demonstrate Traffic Decryption
- First, log in to the internal end-user computer (IP: 192.168.1.100) and open a browser.
- Using the browser, access an external website (IP: 203.0.113.10). Because the TLS protocol is enabled on the website, you should enter https://203.0.113.10 in the URL bar.
- Attempt to download the EXE file from the site. (The file was uploaded previously as a part of the lab preparation.)
The file download attempt should be unsuccessful due to the file policy you deployed earlier (refer to Figure 18-17). To give you a better understanding, Figure 18-21 shows the capture of an HTTPS session where an end user’s attempt to download an executable file from an external website is blocked by an intermediate threat defense. The capture shows the beginning of the TCP three-way handshake, followed by the TLS handshake, and finally, a reset packet that terminated the encrypted session.
Figure 18-21 Capture of an Encrypted Session Shows the Blocking of a File Transfer
For blocking a file, a connection event should be triggered. The event should also indicate that the connection is decrypted. Navigate to Analysis > Connections > Events to view the connection events (see Figure 18-22). Similarly, if you go to the Connection Summary dashboard, you can view various decryption-related statistics in widgets (see Figure 18-23).
Figure 18-22 Connection Events Show the Blocking of a File Transfer Through a TLS Session
Figure 18-23 Dashboard Widgets Show the Blocking of a File Transfer Through a TLS Session
To understand the benefit of the SSL policy, let’s perform another test: remove the association of the SSL policy from the access control policy. You can do it by entering the access control policy editor and changing the SSL policy selection from Decryption Policy to None (the navigation and option are displayed in Figure 18-19). After you change the selection, save the access control policy and redeploy it to the threat defense.
Now, attempt to access the same external website (IP: 203.0.113.10) once again from your browser. Enter https://203.0.113.10 in the URL bar. Attempt to download the EXE file from the site. This time, the file should be downloaded successfully. On the Analysis > Connections > Events page, you will notice that the connection events are no longer decrypted. Hence, the file transfer was not blocked per the file policy (see Figure 18-24). The application protocol is now considered HTTPS (HTTP over TLS). Notably, the destination port number 443 remains unchanged in both tests—with and without decryption.
Figure 18-24 Encrypted and Decrypted Connections Are Distinguishable on the Connection Events Page
For additional clarification, if you go to Analysis > Files > File Events to view the file events, you will notice that the file was blocked only during the first test (see Figure 18-25). The event was logged when the SSL policy was deployed on the threat defense. However, no file event was triggered during the second test because the file policy was ineffective without traffic decryption.
Figure 18-25 The File Event Confirms the Blocking of an Executable File
Leave a Reply