SonicWALL SonicWALL UTM Appliance manual Configuring a SSL Blacklist and Whitelist

Page 31

ever decreasing cost and complexity of SSL, however, has also spurred the growth of more dubious applications of SSL, designed primarily for the purposes of obfuscation or concealment rather than security. An increasingly common camouflage is the use of SSL encrypted Web-based proxy servers for the purpose of hiding browsing details, and bypassing content filters. While it is simple to block well-known HTTPS proxy services of this sort by their IP address, it is virtually impossible to block the thousands of privately-hosted proxy servers that are readily available through a simple Web-search. The challenge is not the ever- increasing number of such services, but rather their unpredictable nature. Since these services are often hosted on home networks using dynamically addressed DSL and cable modem connections, the targets are constantly moving. Trying to block an unknown SSL target would require blocking all SSL traffic, which is practically infeasible. SSL Control provides a number of methods to address this challenge by arming the security administrator with the ability to dissect and apply policy based controls to SSL session establishment. While the implementation (as of this writing, SonicOS 5.2) does not decode the SSL application data, it does allow for gateway-based identification and disallowance of suspicious or undesirable SSL traffic.

Configuring a SSL Blacklist and Whitelist

An SSL blacklist and whitelist allows the administrator to define strings for matching common names in SSL certificates. Entries are case-insensitive, and will be used in pattern-matching fashion, for example:

A.67.115.118.67 is currently the IP address to which sslvpn.demo.sonicwall.com resolves, and that site uses a certificate issued to sslvpn.demo.sonicwall.com. This will result in a match to “sonicwall.com” since matching occurs based on the common name in the certificate.

B.This is the decimal notation for the IP address 63.208.219.44, whose certificate is issued to www.megaproxy.com.

C.www.freeproxy.ru will not match “prox” since the common name on the certificate that is currently presented by this site is a self-signed certificate issued to “-“. This can, however, easily be blocked by enabling control of self-signed or Untrusted CA certificates.

31

Page 30 Page 32
Image 31
Page 30 Page 32
Contents Contents Page Integrating LDAP/Active Directory with Sonicwall UTM Configuring the CA on the Active Directory ServerImporting the CA Certificate onto the SonicWALL Configuring the SonicWALL Appliance for LdapPage Page Page Page Page Page Page Enable Radius to Ldap Relay Enables this feature Authentication Page Page Page Creating Firewall Rules with Ldap Groups/Users SonicOS Options That Leverage Groups/UsersPage Page Firewall Rules with Bandwidth Management & Logging Page Blocking Domains with Firewall Rules Blocking Websites Domain Names for Groups/UsersPage Page Navigate to Firewall Access Rules Create a rule to allow Http traffic for your allowed lists Do the same for Https Create the deny rules for Http and Https Firewall rules should now look like the below picture Blocking Https SSL Domains with SSL Control Configuring a SSL Blacklist and Whitelist Page Applying Different CFS Policies to Groups Page Creating Custom CFS Policies Navigate to the Policy tab and add a new CFS policy Page Page Page Http//$$fwinterface$$/$#SWLSTYLESCSS#$ Variables for Custom Block Page in SonicOSAdvanced Sample Code for SonicOS Basic Sample Code for SonicOSPage Page Sample Code for SonicOS 5.1 or Earlier Sample JavaScript Code for SonicOSApplying Application Firewall Polices to Groups/Users Page Page Page Page Tightening Control over the Browsing Behavior of Users Blocking IM Traffic Categorically Applying Granular IM Policies Global VPN Client GVC Applying VPN Access Policies to Groups/UsersPage SSL-VPN NetExtender Guest Services Wireless Guest Services
Top Page Image Contents