LDAP Leveraging LDAP Groups/ Users with SonicWALL UTM Appliance Contents Contents .............................................................................................................................................................. 1 Integrating LDAP/Active Directory with Sonicwall UTM ...................................................................................... 3 LDAP over SSL ...............................................................................................................
Blocking IM Traffic Categorically ............................................................................................................... 51 Applying Granular IM Policies ................................................................................................................... 52 Applying VPN Access Policies to Groups/Users............................................................................................... 53 Global VPN Client (GVC) ...............................................
Integrating LDAP/Active Directory with Sonicwall UTM SonicOS supports a range of different LDAP servers, the most popular being Active Directory (AD). AD is also an LDAP implementation. Please refer to the following paper as a supplement on how to configure LDAP settings. http://www.sonicwall.com/downloads/LDAP_Integration_Feature_Module.
Exporting the CA Certificate from the Active Directory Server To export the CA certificate from the AD server: Step 1: Launch the Certification Authority application: Start > Run > certsrv.msc. Step 2: Right click on the CA you created and select Properties. Step 3: On the General tab, click the View Certificate button. Step 4: On the Details tab, select Copy to File. Step 5: Follow through the wizard, and select the Base-64 Encoded X.509 (.cer) format.
Step 5: On the Settings tab of the LDAP Configuration window, configure the following fields: • • • • • • • • Name or IP Address – The FQDN or the IP address of the LDAP server against which you wish to authenticate. If using a name, be certain that it can be resolved by your DNS server. Also, if using TLS with the ‘Require valid certificate from server’ option, the name provided here must match the name to which the server certificate was issued (i.e. the CN) or the TLS exchange will fail.
• • • Send LDAP ‘Start TLS’ Request – Some LDAP server implementations support the Start TLS directive rather than using native LDAP over TLS. This allows the LDAP server to listen on one port (normally 389) for LDAP connections, and to switch to TLS as directed by the client. Active Directory does not use this option, and it should only be selected if required by your LDAP server.
• • • • • Selecting any of the predefined schemas will automatically populate the fields used by that schema with their correct values. Selecting ‘User Defined’ will allow you to specify your own values – use this only if you have a specific or proprietary LDAP schema configuration. Object class – Select the attribute that represents the individual user account to which the next two fields apply.
• • • • Primary Domain – The user domain used by your LDAP implementation. For AD, this will be the Active Directory domain name, e.g. yourADdomain.com. Changes to this field will, optionally, automatically update the tree information in the rest of the page. This is set to mydomain.com by default for all schemas except Novell eDirectory, for which it is set to o=mydomain. User tree for login to server – The location of where the tree is that the user specified in the settings tab.
trees are best ordered with those on the primary server first, and the rest in the same order that they will be referred. NOTE: When working with AD, to determine the location of a user in the directory for the ‘User tree for login to server’ field, the directory can be searched manually from the Active Directory Users and Settings control panel applet on the server, or a directory search utility such as queryad.vbs in the Windows NT/2000/XP Resource Kit can be run from any PC in the domain.
Step 10: On the LDAP Users tab, configure the following fields: • • • • Allow only users listed locally – Requires that LDAP users also be present in the SonicWALL local user database for logins to be allowed. User group membership can be set locally by duplicating LDAP user names – Allows for group membership (and privileges) to be determined by the intersection of local user and LDAP user configurations.
In the LDAP Import User Groups dialog box, select the checkbox for each group that you want to import into the SonicWALL, and then click Save. Having user groups on the SonicWALL with the same name as existing LDAP/AD user groups allows SonicWALL group memberships and privileges to be granted upon successful LDAP authentication.
Step 11: On the LDAP Relay tab, configure the following fields: The RADIUS to LDAP Relay feature is designed for use in a topology where there is a central site with an LDAP/AD server and a central SonicWALL with remote satellite sites connected into it via older low-end SonicWALL security appliances that may not support LDAP.
configurable. Step 12: Select the Test tab to test the configured LDAP settings: The Test LDAP Settings page allows for the configured LDAP settings to be tested by attempting authentication with specified user and password credentials. Any user group memberships and/or framed IP address configured on the LDAP/AD server for the user will be displayed. Authentication There are two mechanisms available for having a user authenticate to the SonicWALL firewall.
Logon to Appliance – Configuring User Level Authentication Settings This is the other method of authenticating users, and requires the user to login to the appliance. Please refer to the following paper for more details on ULA: http://www.sonicwall.com/downloads/SonicOS_Standard_2.1_User-Level_Authentication.pdf In this example, the LAN zone will be configured for ULA: Step 1: Go to Network>Interfaces>X0 (or appropriate interface). Step 2: Under General enable HTTPS User Login.
Step 5: Click Add, then create the following two rules as depicted below. The order is important. The new first rule allows any DNS queries out. The new second rule forces all users (Everyone) to be challenged before accessing the Internet for HTTP only. NOTE: This configuration will allow any traffic out other than HTTP, even without first authenticating. If you want to block ALL traffic before authenticating for HTTP, then disable the default ‘Any, Any, Any, Allow’ rule as depicted in rule 3 below.
NOTE: The difference between “All” and “Everyone” in a policy rule. Selecting “All” will allow all matching traffic, regardless from an authenticated user or not. Selecting the “Everyone” user group will allow traffic from any logged in user, but not from a user who has not logged in.
If everything is working correctly, you should then see users authenticated on the Log>View page.
• • Rule processing stops as soon as there is a match (with some caveats – see below) Rule logic first looks at Source, then Destination, Service, and Action. If there is a match there, rule processing stops and then further subset rule processing can happen (rules set for schedules, users/groups, or BWM) for that specific rule. o What cannot occur is two overlapping rules for the same service for different groups.
allowed access through it. Matching traffic from the user or members of the user group will be given access, and matching traffic from anyone else will be denied access. For multiple user groups to be allowed access, create a single parent group user containing all of them as members and set a single rule specifying that parent group as the users allowed. A shortcoming in the rule configuration does allow rules to be created that are identical in all but the user group information.
Firewall Rules with Bandwidth Management & Logging It is possible to leverage FW rules simply for logging and/or bandwidth management (BWM). To enable BWM, it is first necessary to go to Network > Interfaces and configure the WAN interface. Click the Advanced tab, and then enable ingress and egress rates for your network. These rates should correspond with what your Internet provider is capable of providing you.
After BWM is enabled on the WAN interface, a new tab is displayed within FW rule creation: the Ethernet BWM tab. You can now enable BWM on a rule by rule basis setting a guaranteed bandwidth rate (Kbps) or %, a maximum rate or %, priority, and tracking of bandwidth usage. In the below screenshot, we have restricted POP email to maximum of 100 Kbps for downloads: If you wanted to also restrict the download and upload to a maximum of 100kbps, change the rule according to the following example.
NOTE: You can create a firewall rule for any given user/group and restrict that group’s overall bandwidth for any network service/protocol. Consider also using Application Firewall which allows more granular control of bandwidth policies.
Step 2: Create an AO for yahoo.com. Step 3: Now, create an AO Group and add the appropriate AOs to this group.
Step 4: Next, create an FW rule that will deny traffic to the Blocked Sites AO Group. Allowing Specific Domains and Blocking All Others with Firewall Rules With firewall rules you can block HTTP/HTTPS traffic for all traffic except for the defined list you’ve created. First, create the address objects of the websites you want to allow. In the following example, we will allow http://www.sonicwall.com and https://www.mysonicwall.com and deny all other HTTP/HTTPS traffic.
Step 2: Create an AO for Mysonicwall.com. While using a FQDN is often more “friendly”, in this example we’ve chosen the IP address. Step 2: Create an AO Group for the Allowed sites. Step 3: Navigate to Firewall > Access Rules.
Step 4: Create a rule to allow HTTP traffic for your allowed lists.
Step 5: Do the same for HTTPS.
Step 6: Create the deny rules for HTTP and HTTPS.
The firewall rules should now look like the below picture: NOTE: that the downside to using FW rules to block/allow websites is that if a user is a member of different groups in LDAP, and if different rules are created for different groups, it can cause undesirable behavior for a given user. Firewall rules are processed from top down and rule processing stops as soon as there is a match. This is why it’s critical to order your rules appropriately.
Blocking HTTPS (SSL) Domains with SSL Control With Secure Socket Layer (SSL) Control it is possible to whitelist and blacklist HTTPS domains, as well as other SSL services, based on keywords in their certificate. SSL control cannot be enforced at the group/user level, only at the ZONE level. For example, if you enabled SSL control on the LAN zone, all users in the LAN would have the same enforcement policies.
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.
Step 1: To configure the Whitelist and Blacklist navigate to Firewall > SSL control > click the Configure button to bring up the following window: Entries can be added, edited and deleted with the buttons beneath each list window. List matching will be based on the subject common name in the certificate presented in the SSL exchange, not in the URL (resource) requested by the client.
Applying Different CFS Policies to Groups It is important to understand what CFS is capable of (as of SonicOS 5.2). CFS is a subscription based service that allows administrators to block domains based on category ratings. The Premium CFS features over 50 different categories to choose from. SonicWALL maintains and categorizes a list of over 16 million URLs and continually classifies additional URLs.
CFS has the ability to allow or block domains by their fully qualified domain name (FQDN) or by keywords in their FQDN. This functionality does not require a subscription to CFS. This list is a single master list that can be enforced on any given CFS policy. As you create additional CFS policies, each policy has the ability to leverage the same master list for allowed/forbidden domains, keyword blocking, and safe search enforcement.
NOTE: If you wish to forbid or allow HTTPS domains, use of their IP address must be used in CFS. FQDN does not work for HTTPS sites in the CFS Custom List. For example, I was able to forbid paypal.com with the use of these 3 IP addresses. (This list may not be representative of all IPs for paypal) Using the forbidden domains list doesn’t require the use of CFS categories. For example, if you wanted to block myspace.com for the entire organization, or a given group, you would enter myspace.
Step 1: Under the CFS tab, enable the IP based HTTPS content filtering. This enables CFS for HTTPS domains. This is important if you wish to block sites such as HTTPS://www.facebook.com or proxy sites such as HTTPS://megaproxy.com. Step 2: Navigate to the Policy tab and add a new CFS policy.
Step 3: Create a friendly name for the new policy. Step 4: Navigate to the URL List tab and select the categories you want to block or allow for this policy. Step 5: Navigate to the Settings Tab and select if you want to enforce allowed domains, forbidden domains, or keywords in domains. You can also choose to enforce Safe Search (Safe Search enforcement is included with SonicOS 5.2 or higher. NOTE: Previous versions of SonicOS will require a custom Application Firewall policy.
default of “moderate” to “strict” filtering on Google however. Step 6: Select if you want the CFS Policy to only run at certain times of the day. For example, you might allow access to social networking sites between 12-1 for lunch break, but restrict access the remainder of the time.
Step 7: Next navigate to Users > Local Groups and configure the Group you want the new CFS policy to apply to. Step 8: Select the CFS policy you created under the CFS Policy tab. Repeat this same process for every group that requires custom CFS settings. Enforcing CFS Policies without Requiring All Users to Authenticate There is one more trick you can do with CFS involving user authentication.
Step 1: Navigate to Network > Network Interfaces. Configure the respective interfaces you wish to support local authentication on by enabling HTTPS user login. Step 2: Navigate to Security Services > Content Filter. At the bottom of the page is the html code that can be customized. Provided below is some sample code that you can modify for your deployment. Variables for Custom Block Page in SonicOS 5.2 SonicOS 5.2 introduced variables allowing administrators to customize their block page even further.
Basic Sample Code for SonicOS 5.2 ----*snipped*---- (with virtual scissors ☺ )
If you believe the below web site is rated incorrectly click here Click here to login and apply your personal filter policy |
After injecting this piece of code the block page will now display the following. Advanced Sample Code for SonicOS 5.NOTE: Use caution the website you are redirecting isn’t on the CFS list or blocked domains. It would create a looping situation.
SonicWALL - Web Site Blocked
