Configuring Firewall Access Rules

Enabling SonicWall SSO affects policies on the Firewall > Access Rules page of the SonicOS management interface. Rules set under Firewall > Access Rules are checked against the user group memberships returned from a SSO LDAP query, and are applied automatically.

Topics:

Automatically Generated Rules for SonicWall SSO

When a SonicWall SSO agent or TSA is configured in the SonicOS management interface, a Firewall access rule and corresponding NAT policy are created to allow the replies from the agent into the LAN. These rules use either a SonicWallSonicWall SSO Agents or SonicWall Terminal Services Agents address group object, which has a member address object for each configured agent. The member address objects are automatically added to and deleted from the group object as agents are added or deleted. The member address objects are also updated automatically as an agent’s IP address changes, including when an IP address is resolved via DNS (where an agent is given by DNS name).

If SonicWall SSO agents or TSAs are configured in different zones, the Firewall access rule and NAT policy are added to each applicable zone. The same SonicWall SSO Agents or SonicWall Terminal Services Agents address group is used in each zone.

NOTE: Do not enable Guest Services in the same zone where SonicWall SSO is being used. Enabling Guest Services will disable SSO in that zone, causing users who have authenticated via SSO to lose access. Create a separate zone for Guest Services.

Accommodating Mac and Linux Users

Mac and Linux systems do not support the Windows networking requests that are used by the SonicWall SSO agent, and hence require Samba 3.5 or newer to work with SonicWall SSO.

Topics:

Using SSO on Mac and Linux With Samba

For Windows users, SonicWall SSO is used by a SonicWall appliance to automatically authenticate users in a Windows domain. It allows the users to get access through the appliance with correct filtering and policy compliance without the need to identify themselves via any additional login process after their Windows domain login.

Samba is a software package used by Linux/Unix or Mac machines to give their users access to resources in a Windows domain (via Samba’s smbclient utility) and/or to give Windows domain users access to resources on the Linux or Mac machine (via a Samba server).

A user working on a Linux PC or Mac with Samba in a Windows domain can be identified by SonicWall SSO, but it requires proper configuration of the Linux/Mac machine, the SSO Agent, and possibly some reconfiguration of the appliance. For example, the following configuration is necessary:

SonicWall SSO is supported by Samba 3.5 or newer.

NOTE: If multiple users log into a Linux PC, access to traffic from that PC is granted based on the most recent login.

Using SSO on Mac and Linux Without Samba

Without Samba, Mac and Linux users can still get access, but will need to log in to the SonicWall appliance to do so. This can cause the following problems:

To avoid these problems, the Don't invoke Single Sign On to Authenticate Users check box is available when configuring Firewall access rules by clicking Add on the Firewall > Access Rules page (with View Style set to All Rules). This check box is visible only when SonicWall SSO is enabled and when the Users Allowed field on the Add Rule page is not set to All. If this check box is selected, SSO will not be attempted for traffic that matches the rule, and unauthenticated HTTP connections that match it will be directed straight to the login page. Typically, the Source field would be set to an address object containing the IP addresses of Mac and Linux systems.

In the case of CFS, a rule with this check box enabled can be added “in front of” CFS so that HTTP sessions from Mac and Linux systems are automatically redirected to log in, avoiding the need for these users to log in manually.

NOTE: Do not select the Don't invoke Single Sign On to Authenticate Users option for use with devices that are allowed to bypass the user authentication process entirely. Any devices that may be affected by an access rule when this option is enabled must be capable of logging in manually. A separate access rule should be added for such devices, with Users Allowed set to All.

White Listing IP Addresses to Bypass SSO and Authentication

If you have IP addresses that should always be allowed access without requiring user authentication, they can be white-listed.

To white-list IP addresses so that they do not require authentication and can bypass SSO:

The default CFS policy will be applied to users at these IP addresses, and no IPS policies or App Control policies that include particular users will be applied to them.

This method is appropriate for small numbers of IP addresses or to white-list subnets or IP address ranges. It will work for large numbers of separate IP addresses, but could be rather inefficient.

Forcing Users to Log In When SSO Fails with CFS, IPS, App Control

You can use Access Rules to force users to log in via the Web UI when they cannot be identified via Single Sign-On (SSO). Users need to be identified for CFS, IPS, App Rules, or other policies to be correctly applied. An Access Rule can make the SonicWall prompt the user for username and password.

If there are multiple CFS policies, or if IPS, App Rules, App Control, Anti-Spyware or DPI-SSL have policies that are set to include/exclude certain users/user groups, then SSO is initiated to identify users. By default, if SSO fails to identify a user, the user is given access through the firewall while constrained by the default CFS policy or without the IPS policy, App Rule, or other policy being applied.

You can use Access Rules in conjunction with the above services to force all users to log in via the Web UI with username/password when SSO fails, before they are allowed access through the firewall. Set an access rule that requires users to be authenticated, and that rule will initiate SSO. In this case, if SSO fails to identify the user they are blocked and, in the case of HTTP, redirected to the login page.

That can be done in one of two ways. The source zone is shown as LAN here, but can be any applicable zone(s):

You can also include other services along with HTTP/HTTPS if you do not want those being used by unauthenticated users.

Of these, option 1 is the more secure option, but is also the more likely to cause problems by blocking unforeseen things that should be allowed access without authentication.

Allowing ICMP and DNS Pings from a Terminal Server

In Windows, outgoing ICMP pings from users on the Terminal Server are not sent via a socket and so are not seen by the TSA, and hence the appliance will receive no notifications for them. Therefore, if firewall rules are using user level authentication and pings are to be allowed through, you must create separate access rules to allow them from “All”.

Similarly, outgoing user requests using Fully Qualified Domain Names (FQDN) rather than IP addresses require that DNS traffic be allowed through. To allow Terminal Server users to use FQDNs, you must create a firewall access rule that allows DNS traffic from “All”.

About Firewall Access Rules

Firewall access rules provide the administrator with the ability to control user access. Rules set under Firewall > Access Rules are checked against the user group memberships returned from a SSO LDAP query, and are applied automatically. Access rules are network management tools that allow you to define inbound and outbound access policy, configure user authentication, and enable remote management of the SonicWall security appliance. The SonicOS Firewall > Access Rules page provides a sortable access rule management interface.

NOTE: More specific policy rules should be given higher priority than general policy rules. The general specificity hierarchy is source, destination, service. User identification elements, for example, user name and corresponding group permissions, are not included in defining the specificity of a policy rule.

By default, SonicWall security appliance’s stateful packet inspection allows all communication from the LAN to the Internet, and blocks all traffic to the LAN from the Internet.

Additional network access rules can be defined to extend or override the default access rules. For example, access rules can be created that block certain types of traffic such as IRC from the LAN to the WAN, or allow certain types of traffic, such as Lotus Notes database synchronization, from specific hosts on the Internet to specific hosts on the LAN, or restrict use of certain protocols such as Telnet to authorized users on the LAN.

NOTE: The ability to define network access rules is a powerful tool. Using custom access rules can disable firewall protection or block all access to the Internet. Use caution when creating or deleting network access rules.