About Trend Micro Deep Security on this blog I wrote many times, but I have not mentioned yet one of the features of this solution, ie SSL traffic inspection. According to recent Google statistics, more than 70% of network traffic is already encrypted. This means that all IDS/IPS/WAF solutions that can not sniff SSL traffic and inspect it are immune to attacks! For Deep Security, we have the ability to enable SSL inspection at the Intrusion Prevention module level. Of course, we will not achieve such efficiency and effectiveness as in the case of BIG-IP F5 , but we will clearly increase the level of security of the protected services.
Auditing SSL traffic has some limitations, and turning it on thoughtlessly can lead to a full service (web) blocking. In this post I will describe, on Apache HTTPD example, how to do it safely and effectively. These limitations are due to the way that is handled by Trend Micro Deep Security about SSL: which is unable to decrypt, is blocked. Therefore, in addition to turning on ssl inspecting, the service must be properly prepared (Apache Httpd in this case). We will start with the conditions that must be fulfilled. Deep Security supports SSL 3.0, TLS 1.0-1.2, not support ssl compression and Diffie-Hellman as authentication protocols for handshake. We also have a limited number of supported ciphers:
RC4-MD5
RC4-SHA
DES-CBC-SHA
DES-CBC3-SHA
AES128-SHA
AES256-SHA
AES128-SHA256
AES256-SHA256
CAMELLIA128-SHA
CAMELLIA256-SHA
DES-CBC3-MD5
By using these protocols you will not get a green icon in any “SSL Check” test, which does not mean that AES256-SHA256 is a protocol to crack (I know). On the issue of security is always the balance of the principles, what is more important? Strong encryption or inspection of encrypted traffic? I am interested in inspection and protection against attacks on my blog. The proper configuration is that we add the appropriate directives to the configuration file:
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite AES128-SHA:AES256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:DES-CBC3-MD5:AES128-SHA256:AES256-SHA256:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!DH:!EDH:!ADH
SSLHonorCipherOrder on
SSLCompression off
SSLOptions +StrictRequire
The use of the AES128-SHA as the first is also a compromise between security and speed. In the “heavier” cipher we need more power for decryption and time to carry it. To decrypt traffic, we need to upload the key and certificate to Deep Security in the Intrusion Prevention module in the Advanced section.
During configuration we have to specify port, interface, indicate IP (selected, list or all) and load set of certificate key with password.
In the case of a specific, familiar Deep Security service that is exposed on a custom port. We need to modify the appropriate IPS rule or port list in the “Policies” tab. For Apache this would be the “Web Server Common” rule, without specifying the proper port this rule would not work.
Also keep in mind that the VMware NSX for vSphere license does not support unmanaged traffic auditing for IPS, here we need to apply agent protection. If everything is configured correctly, then service (Apache) and IPS works.
Interpretation of this image is very interesting, what we see means that there are specific scans coming from the Internet trying to force the use of a cracked, weak, unsupported cipher. In situation that Apache returns a list of protocols and ciphers that it can handle! And according to the tests I have conducted (SSL Check), the AES128-SHA itself is supported by 99% browsers in the market.
