Sonic Wall Content Filtering

Hi Lockdown32,

I think you know what I'm going to say about SonicWALL (I'm a big fan)...lol. To me two generations back I was ready to hop off the train. The performance was just not there but since then the bugs, performance and security features/functions have grown so much I don't look back to that time I was ready to jump ship. Currently, they have one of the fastest deployments of security clouds on the market and their countermeasures are first to near first in market.

Whitelisting Overview

In terms of Content Filtering, there is not a great understanding of it foundational as it relates to web 2.0. I'm currently writing an article about it because of this gap in the thought process. Web 2.0 changes things because whitelisting becomes more strenuous when you have to investigate the website sources due to the heavy use of external services, CDN, analytics, etc.

Content Filtering Engines

With SonicWALL you have three (3) different engines to utilize; two within the SonicWALL and one third-party integration: a) CFS via Users & Zones (Security Services > Content Filter > SonicWALL CFS); b) Websense Enterprise (Security Services > Content Filter > Websense Enterprise (third-party)); and CFS via App Rules (Security Services > App Rules).

How to know when to use each Engine

User Assignments

You have five (5) different methods to apply these to your user base:

Versions

What is your SonicOS version? CFS 4.0 greatly differs from CFS 3.0 among other items URI listings. Also, CFS 4.0 does not allow usage of CFS Via App rules, which need to be reconfigured to work in CFS 4.0. Until the release of SonicOS Enhanced 5.8.0.0, HTTPS filtering was exclusively IP-based meaning IP addresses must be used rather than domain names in the Allowed or Forbidden lists. You can use the nslookup command in a CMD window to convert a domain name to its IP address(es). Keep in mind there may be more than one IP address associated with a domain, and if so, all must be added to the Allowed or Forbidden list, respectively. However, if you are running SonicOS 5.8 or higher HTTPS filtering has changed to both IP & hostname based.

Are you filtering HTTPS content, which almost all most major websites are now running?

Some items to keep in mind:

• Allowed or Forbidden Domains list interpret domains & handle wildcarding differently than the Custom List. The Allowed or Forbidden Domains list wildcard by default so you should only put the domain (domain.com) in the entry opposed to subdomain.domain.com or *.domain.com.
• Do not include the prefix http:// or https:// in your entry.
• Remove redundant objects - they only cause issues. e.g. if you have mail.domain.com, *.domain.com & domain.com, remove all but "domain.com".
• CFS inspects the header packet therefore domain.com:8080 will not be filtered and would need to be added as such in the Allowed or Forbidden Domains list, respectively.
• The Custom List is an exception in that it is explicit in nature meaning wildcarding does not take place by default therefore, mail.domain.com does not equal domain.com & vice versa.

FYI: HTTPS sites are silently blocked without displaying a CFS block page by design.

I hope this helps. Let me know if you have any other questions!

The biggest problem I have found and seem to always be fighting is the Authentication via the SSO Agent. The CFS is so simple. People either have full internet or have nothing. It is only a 30 user network. I remember using Barracuda and it was virtually flawless.

   I look at SonicWall and can't help but feel it is a fighter/bomber scenario. They just have too much built in to it at this point trying to do everything and as a result it doesn't do anything real well. Then it went from SonicWall to Dell to yet someone else.

   So your vote would be to ditch SonicWall?

I think I updated my post while you were submitting your reply. Please re-fresh to see my changes.

No, I am not saying to ditch your SonicWALL unless it is an EOL in which case I'd upgrade and stay with SonicWALL. We have all of our clients almost exclusively on SonicWALL and the user-bases range drastically from companies like your to 55,000 user environments. In Web 2.0 testing is critical and like I said previously there can be many caveats meaning things aren't straight forward because of the third-party service provider model heavily used in Web 2.0.

I'd have to see your config to determine why you are having so many issues/frustrations. When you say, "fighting Authentication via SSO Agent" how is that relating to having issues with CFS? I understand that if users can't login due to some issue with SSO then the correct policy will not apply but I don't see the direct connection to CFS issues but rather indirect or subsequent of.

Let me know.

Have you implemented an SSO ByPass Group to reduce SSO Agent errors?

It is a very simple setup. There are two AD groups. "Full Internet" and "No Internet". All users fall in to one of these groups and the two groups and brought in to the Sonic Wall via LDAP. The users are brought in to the Sonic Wall through their SSO agent. So yesterday a user by the name of tdragoo couldn't get internet. As it turns out she did not authenticate via the SSO agent so the SonicWall had no idea who she was or what group she belonged to hence no internet. Always something going on along these lines.

   Then..... I call in one week with and issue. The tech says to allow everything in the Default CFS Policy. Still issues so I call in again and this tech says "oh... the previous tech told you wrong. You have to block everything in the Default CFS Policy". Still issues so I call in again and guess what? Right back to "the previous tech told you wrong. Allow everything in the Default CFS Policy". I kind of jumped his at that point and told him he damn well better be sure. He put me on hold and came back and apologized. He was incorrect. So I can't tell you how many time this has happened. Just spinning my wheels being told different things every time I call in.

   I told them it isn't rocked science. If they belong to "Full Inter" they get it all. If they belong to "No Internet" they get nothing. I just can't believe the amount of time I have to spends on the phone the them.

   It has to be approach EOL. It is a TZ205. Services expire April of 2018. Maybe time to move up to a more supported model?

Sorry. I missed your previous. "SSO Bypass Group"? Do you mean if all my users are between 100-200 (IP) to exclude (1-99) and (200-254) from being scanned by the SSO Agent? Yes...

I see...that help clarify things for me. I will try to address each of your points:

So yesterday a user ... couldn't get internet. As it turns out she did not authenticate via the SSO agent so the SonicWall had no idea who she was or what group she belonged to hence no internet.

This is the default behavior meaning if a user doesn't login to Windows with their username (e.g. they login anonymously or under another username that has no group) they will not gain access to the Internet based on the Principal of Least Privilege. To clarify did she not authenticate or did the SSO agent fail? The way you worded it seems that "...she did not authenticate...".

The tech says to allow everything in the Default CFS Policy.

Unequivocally, your default CFS policy should be the most restrictive (block all) for the least privileged users (for everyone). The proof and reason behind this is that "Allows" always win using "OR" logical statements which is how SonicWALL processes and determines what wins when a user has multiple CFS policies. Furthermore, if you set the Default CFS policy to allow all; there is no way to block anything. SonicWALL and all good security relies on the Principal of Least Privilege method of access so this means if a user doesn't end up in a group for whatever reason, isn't part of a group (rogue or otherwise) or a service on a port is not defined the action is blocked...that function is a security Best Practice. So, in your case when you actually defined a group to allow everything the Principal of Least Privilege model is already broken because it means that the least privilege or default has access to everything when in fact it should have no access until authenticated. Now in terms of security no user should ever be in an actual "everything allowed" state because even the least restrictive group should still have the following categories blocked:

I told them it isn't rocked science. If they belong to "Full Inter" they get it all. If they belong to "No Internet" they get nothing. I just can't believe the amount of time I have to spends on the phone the them.

Your setup seems very black/white so I completely understand your frustration and eagerness to reduce if not remove your support call volume/time on this aspect. CFS is one of the worst aspects of security IMO because it typically interjects, falsely, the idea that the company or IT are taking a moral position when in fact CFS is not about morals at all; its about productivity (which could be a part of company ethics but not morals) and security. This falsehood pretense seems to enrage users more so than if they can't access something for a seemingly "technical" reason. Also, most of the time they report ambiguously like "I can't use the internet" when they can but one or two sites are being blocked, etc.

So the root of the issue sounds like an SSO agent one. Windows firewall, endpoint AV and local services failing to run can block SSO queries from communicating from he SSO agent and the user machine. Where is the SSO agent, e.g. on a DC on a designated server, etc? I would put out a GPO specifically for SonicWALL SSO, if you haven't already, that makes sure NETAPI or WMI (depending on which you are using to query) services are running, file & print sharing is enabled, overrides for local firewall rules allowing access to the required services, etc. This would service as your override for SSO so that in the event a machine has exceptions the override takes care of them.

How are you currently probing the users? When the SSO agent attempts to identify a user in a Windows domain, if the agent uses NetAPI or WMI then that tries to communicate directly with the user's PC from which the traffic is originating. This can cause problems when traffic is coming from non-Windows devices that do not respond to these Windows messages, or with Windows PCs if personal firewalls on them are blocking it. The result can be that the agent may get overloaded with multiple threads waiting for requests that are not getting replied to.

Enabling Probe users for either NetAPI over NetBIOS, NetAPI over TCP, or WMI (and selecting the correct NetAPI/WMI protocol that the SSO agent is configured to use) can avoid these problems. Before sending a request to the agent to identify a user via NetAPI or WMI, SonicWALL will probe the machine from which the traffic originated to check if it responds on the port used by the NetAPI or WMI protocol. If it does not then the device will fail SSO immediately without the agent getting involved. However, this setting will not affect an agent that reads user login information from the domain controller/s. NetAPI will provide faster, though possibly slightly less accurate, performance and WMI will provide slower, though possibly more accurate, performance.

CFS Policies by IP Address Range Option

I don't know how your DHCP/IP Pooling schema is setup in relation to your CFS Groups and how you are determining if a user ends up in a particular CFS group (allow/deny all) or not but if you can't get this SSO issue resolved you may consider implementing CFS via Users & Zones and assigning CFS Policies by IP Address Range. You could essential have two ranges for both policies and as long as they are in the specified range it would simplify your CFS issues thereby removing your SSO altogether. Just a thought.

Sorry. I missed your previous. "SSO Bypass Group"? Do you mean if all my users are between 100-200 (IP) to exclude (1-99) and (200-254) from being scanned by the SSO Agent? Yes...

Yes, assuming non-user devices, IP phones, servers, etc are included in the IPs being excluded, but you should also be including traffic from particular users such as Windows Service Users: IUSR_* and IWAM_* in the bypass as well. Also add Local User under the SSO Agent (Action > Windows Service Users). I'd recommend checking Log user name as Unknown (SSO Bypassed) for SSO bypass under SSO > Enforcement in the SonicWALL that way during troubleshooting the logs will show this for all SSO bypassed traffic and you can more easily dismiss via sorting, etc.

I hope this helps!

When someone or something does not authenticate it inherits the Default CFS Policy which blocks everything. All I can tell you is that she did not show up in the list of users.

   The problem support had was exactly as you pointed out. Users have multiple CFS policies and they kept going back and forth between "the first block it hits it quits processing and is blocked" and "the first allow it hits it quits processing and is allowed". I couldn't believe it to a week and four techs to finally come up with concurrency. So the policies are set right at this point. The CFS Default Policy is block everything.

   The SSO agent is on the one and only DC. The AV does not have a firewall (it does but it is disabled). The Windows Firewall is in effect but they never went through the ports I needed to open.

   The CFS Policies are assigned by group membership. The DHCP range is 100-200 but also includes cell phones which won't authenticate. There are only 30 computers so static IPing wouldn't be a big deal but that would only allow me to search a smaller SSO range wouldn't it?

Did that make sense with regards to the exclusions? Any other questions?

Thanks Blue Streak Tech. I had the right ports open and everything was configured properly. I don't have much choice. The SSO agent must be run on the AD. It is the only computer they have that is up 24/7. I think what was missing was the SSO Exclude Range. I had to go back and static IP all the workstations but right now the ones that need authentication are grouped together in a tight little 40 IP range. Thanks for all your help!

You're welcome...my pleasure!