I have been saying for some time that Surf Control had a memory leak in the web filter service. Finally another customer also reported the same problems we have been having. Websense put a developer on it and they wrote a hotfix. So far so good. So if you have had to reboot your box to fix unexplained misblocking of users then contact their support and ask for the hotfix.
Don’t ask me why this is. BUT we have a rule that blocks webmail by category for anyone if the previous rule does not allow them to webmail category sites based on being in a special user group. Note that both these rules apply to the webmail category and ANY protocol. Yet, a lot of HTTPS webmail traffic gets through. So I added one more rule that blocks webmail https specifically. Strangely it works much better at stopping almost all webmail traffic now. Encrypted or not. Even though the category webmial protocol any rule should have been good enough.
If you work in an Enterprise and use Domain user groups in your rule set make sure you schedule the Network Groups Update. Just go into the SurfControl scheduler, add an item and pull down to pick the Network Groups Update. Pick the schedule that best fits your environment.
Rulescheck.exe is a tool to run through the rules database and ensure all data is valid. Like any database things can become inconsistent with lots of changes. The tool is located in your Program Files\SurfControl\WebFilter folder. Just stop the webfilter service first then run that program. Let it fix any found errors and restart your webfilter service.
If you have a need to run a surfcontrol tool like rulescheck.exe it requires you stop the web filter service. If you stop the service and the tool says it is still running this is an entry stuck in the local sql database. Here is how you quickly clear it out. Make sure you stopped the surfcontrol web filter service FIRST.
- On the surfcontrol box console, open the Microsoft SQL Server Management Studio Express console.
- Expand the databases tree, expand the SurfControl_WebFilter database
- Expand the Tables section and right click on dbo._REGISTERED_SERVER_C table
- Choose Open Table
- Right click ALL rows where you see an ID and Server name populated and choose delete.
- This table should be empty if the service is stopped. If it has a listing then it got stuck and any tools will think the service is still running.
- Once you clear out the rows close the console and run your desired tool again.
Today I was playing around with blocking the Ad and Popup category. By default uses your default blocking page. This made for an ugly web experience with odd looking parts of the text policy blocking page we have setup. So I made a new rule just for blocking ads and popups. Then you make a new HTTP Deny Page. Call it something like “Ad Block”. Now the trick. Put the below code into that page. Assign the new deny page to the ad block only rule and the result is a nice blank area everywhere you had ads that got blocked.
I promised over on In the Trenches that I would create some rules structure for anyone new to Surf Control. So if you need a place to start try out the attached files.
Remember it is not advisable to activate any Disallow Rules without planning and testing so you can undo them if they affect production.
The structure also assumes you tie to a domain with the Surf Control Enterprise User Manager so you can have various domain\groups.
The structure also allows for flexibility for multiple sites assuming they are sharing the Internet connection that the Surf Control is monitoring.
- Rules.xls has the Actual Rules. Do this one last. You need to make the other objects first.
- WhatConfiguration.xls is some sample protocols to block.
- WhereConfiguration.xls are the different Where objects you might model after to allow to everyone, disallow etc.
- WhoConfiguration.xls has all the various Who objects to help build this out.
Today I got my first new Surf Control box up and running at work. During the configuration I noticed a few things about some employees I did not want to know. So likely I will make it policy that one IT person per site is designated as the surf control admin with their backup being the designated admin from another site. Those folks will be trained that only if something is requested through Human Resources can personally identifiable reports be generated and given to management. Generic usage by volume, category etc is ok. I just do not want this to turn into a witch hunt by supervisors or managers.
If it stays an issue I may mandate we redo our installations to work only in Privacy Mode. This requires two passwords be entered to expose user details. This is expected to usually be a management and labor representative.