|
Tuesday, January 26. 2010
Its been brought to our attention by one of our customers (thanks Eric!) that the latest release of Firefox includes a known bug relating to windows Authentication.
If you are using Firefox 3.6 and you persistently get a login box appearing, you've been affected by this bug. As the problem's in the browser, there is nothing we can do to fix this. The only option is to downgrade to Firefox 3.5 until Mozilla fix the issue.
For those who want more detail, please read:
https://bugzilla.mozilla.org/show_bug.cgi?id=533467
UPDATE: It appears this issue has been flagged as major and is currently being worked on by Mozilla, so we expect a fix soon. Please see https://bugzilla.mozilla.org/show_bug.cgi?id=542318
Thursday, January 21. 2010
Here on the tech support desk, we get a chance to remotely administer many of the customers CensorNet servers. I've been noticing recently that a lot of people are making a common mistake, so I thought I'd try to clarify it for everyone.
The Filter Bypass in censornet is something which should be used only in exceptional circumstances. It is a blanket bypass, which means that any site in this, will pass through CensorNet without authentication, filtering or logging taking place. This means that any sites in the bypass are effectively invisible to CensorNet.
You should add sites to the filter bypass only if:
1. You are told to do so by tech support.
2. If its a site you want machines to be able to connect to, without authenticating through the proxy. Examples include Anti-Virus updates and Windows updates, which may happen when there is no-one logged into the machine.
3. The site contains software which does not comply with the NTLM or Transparent Kerberos Authentication mechanisms, and you trust the site.
4. You have thoroughly checked the site and you want it to be allowed through with no filters or logging taking place.
For sites that you just want to allow access to because they are blocked by some part of CensorNet, you just need to add them to a custom URL category that's set to "Allow" in the user policy. Sites in the custom URL filters are logged and filtered by CensorNet as per your policy setup.
Friday, January 8. 2010
We've recently had reports of a couple of sites that have been timing out when accessed through CensorNet. 999 times out of 1000, when this happens, there's a simple cause within your CensorNet policy setup, however occasionally there's more to it than that. In these cases, even adding the URL to the filter bypass cannot get the pages to download. Instead, all that they get is an "Upstream proxy did not respond in time" message.The reason for this is a misbehaving webserver at the remote end. The brief explanation is that the remote end (ie the website) isn't playing nicely with the proxy information being sent from the CensorNet server. What happens is that instead of closing one connection, and continuing loading the page, the remote site is waiting for CensorNet to close the connection. Which makes no sense. It would be like expecting a user to hit "Stop" when loading a webpage when they think the remote server has finished sending them all the information they need. The only solution is to add the URL to the client browser's "Do not use proxy for" URL list. For a more technical explanation, please read http://wiki.censornet.com/foswiki/bin/view/Main/SitesTimeOutEvenIfTheyAreInTheFilterBypass
Monday, December 21. 2009
Dear CensorNet customers, partners and friends,
As the year draws to a close we just wanted to wish everyone a very happy Christmas and New Year. We appreciate all the custom, suggestions and support from our customers and partners. We are really looking forward to an exciting 2010 together.
During the Christmas period we will be available for support right up until Christmas Eve lunch time and then from the 28th to the 31st. As always, emails sent to us after hours will be responded to as quickly as possible.
That leaves nothing else to say except to enjoy the festivities and the snow (if you're lucky enough to get a white Christmas).
Kind regards,
CensorNet Team
Friday, November 13. 2009
Whilst most companies seem to have a pretty solid strategy for filtering computers that don't move around (e.g. your desktop PC), there seems to be an issue emerging with corporate laptops that operate outside the network. These laptops (or indeed computers, if it is a home worker) may or may not be using a VPN and may be using a 3G, Wi-Fi or wired connection to the Internet. The problem comes when you want to reach out and apply the same policy that the employees in the office have to those out and about or working from home.
Our RemoteWorker client is the answer. This is a lightweight piece of software that installs onto Windows 2000, XP, Vista, etc and runs in the background. It cannot be stopped or removed without administrator privileges and there's nothing visible to the user that indicates it is running. The software, which runs as a system service, intercepts port 80 and 443 and tunnels the request to the CensorNet server at your head office (or data centre). It uses whatever Internet connection is available and doesn't require a VPN. The client identifies the user based on their Windows login name and their laptop by IP/MAC address. These tokens of information are used to apply the correct level of filtering for the user based on the group they belong to on the Active Directory server. Armed with this information, CensorNet filters the web request and either denies or or allows it based on the standard rules set up by the business.
This diagram illustrates an example:
Where might this be useful?
1. For a business that supplies their teleworkers with laptops or computers they can now control what Web sites are accessible from their equipment and apply the same rules and schedules that they do with employees in the office.
2. For companies that have roaming users on 3G connections but are getting stung by huge 3G data bills. You can now filter out bandwidth intensive sites such as iPlayer and YouTube thus reducing the data bill and also reporting on user activity and bandwidth usage.
3. For a business with remote offices that aren't part of a VPN back to head office but they still require filtering. Perhaps standalone PC's with USB ADSL connection. The client can bring these remote computers back under control of the central filtering policy.
4. For a school that supplies its students with Internet enabled laptops but wants to ensure that they are filtered inline with the schools Internet Access Policy.
I am sure there are many more applications but this should give you a flavour of what is possible.
For further information please contact our pre sales team or our online support desk.
Friday, October 30. 2009
I am pleased to announce that a beta version of release 1.5.37 is now available. This is a really important release for me because our development team has been working hard on a feature that has long been requested - automatic Active Directory synchronisation. Yes, it's finally here and I can't wait for you all to try it.
The automation is accomplished via the CensorNet Synchronisation Service which is installed on your primary domain controller (Windows Server 2003 and above only, I'm afraid). When initialised, the service sends the AD structure to CensorNet immediately and then it goes to sleep, polling the AD for changes every 60 seconds. With the service running, you will not need to add any new groups, users, move users or delete users in CensorNet any more - just alter them on the AD and the rest is automatic. The synchronisation can work based on Organisational Units (OU) or Primary Group.
In addition to the synch feature, we have addressed the issue of Microsoft phasing out NTLM authentication in Vista and Windows 7. Prior to this release, the only workaround was to downgrade the NTLM compatibility level by means of a registry change. Not the most elegant solution! You'll be pleased to know that there is a new authentication mode called Transparent Kerberos, which is compatible with Vista and Windows 7, and all versions of Windows Server above 2003. The good news is that this authentication method is a lot lighter than NTLM so there is far less overhead on the domain controller itself, which means faster sessions for end users.
There are a couple of prerequisites. You must be running Internet Explorer 7 or above, Firefox 2 or above or Safari on Mac OSX 10.4 or above on all your client machines. After turning on Transparent Kerberos, you must reference the CensorNet proxy with its fully qualified domain name in the browser proxy settings rather than IP address. Please refer to the Getting Started guide page 17 for configuration guide.
What else is new? We've updated the image filter technology so it is faster and more accurate and we've also further optimised the URL database memory requirements and real-time raters. There's also a fix to a known problem with Google Image searches being incorrectly blocked by CensorNet.
We are hoping to release this to the masses towards the middle of November so please do get in touch with us if you would like to try it out before then. Those that have are very happy with the results.
Tim
Thursday, October 22. 2009
Unbelievably, in a short space of time, two major data centres in the US have suffered from catastrophic power outages. Our servers are effected which means that anyone using the California update source should switch immediately to Virginia by going to Filters -> URL database update, selecting "Virginia" from the drop down list and pressing "Set Options".
Power is slowly being restored to the cabinets within the data centres and we are hoping for full service to be restored within 72 hours.
We apologise for the inconvenience.
Monday, October 12. 2009
Please can everyone update their address books with our new office address:-
CensorNet Ltd
Vallon House
Vantage Court Office Park
Winterbourne
Bristol
BS16 1GW
Many thanks
Tim
Wednesday, October 7. 2009
It has come to our attention that the data centre in Virginia, USA where we host our second US update server for URL (CSRV) database updates has had a very serious power problem effecting approximately 2,000 servers. We advise all customers currently using the Virginia update source to swap to California to avoid interruptions to the overnight CSRV downloads. To do this, please go to Filters -> URL Database Updates and select California as the update source and press Set Options to confirm.
We are in constant contact with the data centre and will advise when service has been returned to normal.
08/10/2009 - The service has now been restored. We apologise for the inconvenience and we are investigating the cause with Peer1.
Thursday, August 20. 2009
Our Development Team have been looking into making the CensorNet fault tolerant. This means that the failure of a device does not need to lead to the complete loss of the service.
The system works by having two servers, one is deemed to be a master, with the other a slave. Each server has its own IP address and there is an additional IP address for the cluster as a whole. Users point their browsers at the cluster’s IP address. In that way, if the system switches to the backup node, there is no loss of service and it is all transparent to the users.
During normal operation, the CensorNet writes lots of transactions to its database. It also writes configuration changes to this same database. In the event of a fail-over you would want this data to be up to date.
We achieve this by using some readily available third party software which effectively turns the secondary node into a mirror of the first. As a result, if the node currently acting as the master suddenly fails, the secondary node takes over exactly where the primary left off with no loss of data.
Now you can repair the old primary in your time and bring it back into the cluster when ready. When bought back in, it will be quietly bought up to date before the system switches back again.
Obviously, there is some cost involved in having this fault tolerant service. Interested users should speak to our Sales Team for further details.
Thursday, July 30. 2009
We have just released version 1.5.25 of CensorNet. A lot of the changes are internal but there are some visible new features, in particular, we have included system alerts.
If you visit System->Configuration->Email Notification you will find that we have added a couple of new fields.
One of them is Enable System Alerts by e-mail and if you enable this and do nothing else you will at least be notified whenever you exceed your license count.
However, this field is also crucial to receiving alerts about other system features which you configure on a different screen. If you go to System->Configuration->System Alerts you can configure which alerts you want to be notified of and in certain cases, set a threshold.
Lets discuss these thresholds first.
You can set a value for Load. The Load value shows how busy your CensorNet is and if it gets too high it can cause everything to run slowly. So you can set a value which if exceeded will cause the system to send you an alert. The system is sensitive enough that even a brief exception will cause a mail to be sent, so if you just receive one, but then no more alerts for ages, you can ignore the warning. However, if you keep receiving alerts it is a sure sign that your system is overloaded. You need to take the load alerts in conjunction with any other alerts you may be receiving. If load is the only one, then you might just need a bigger processor, but if other alerts are being received you should consult Technical Support for advice.
The next threshold you can set is the amount of free RAM. As you are probably aware, we recommend at least 2G of RAM in your CensorNet. The threshold you set is the amount (in percentage terms) of free RAM available and if that falls below your set threshold you will receive an alert. Again, if you receive one alert and then nothing more for some time, you can ignore the odd mail, but should you receive multiple alerts you know your system is busy. If you should receive this alert in conjunction with the load alert, and if both keep coming, you have a good idea that your system is seriously underpowered.
The third threshold you can set is that of free disk space. It used to be that people would let their logs grow to enormous size until it slowed the system down and so we introduced the auto-archive system, which takes an archive once your current log exceeds a certain number of records. So now what happens is people just leave the system to generate archives, never deleting old ones, until the disk gets full and everything breaks. So now you can set a threshold which, should free disk space fall below this value, you will receive an alert. The first check, on receipt of this email, should be to check archives and delete if you no longer have a need for them. If doing this does not fix your problem then contact Technical Support for other suggestions.
With the thresholds out of the way, the other things you can monitor are the system processes. These are :
- CensorNet Proxy Server
- Category Server (CSRV)
- Web Cache Service
- License Server
- Database Server
If any of these services fail you will receive an alert. The mails you receive will advise you as to what actions you can take to try and remedy the situation, but if those remedies fail, then of course, you can contact Technical Support for additional advice.
One last word, if you are knowingly stopping and starting services or rebooting the CensorNet then you are likely to receive alerts. You will also receive them during system upgrades, so please ignore these mails as the reason is obvious.
Tuesday, June 16. 2009
We often come accross customers who want to deploy CensorNet Pro in a similar way to SurfControl/WebSense and the answer is no we don't do it the same way and there are two perfectly good reasons why - security and performance.
The aforementioned products use a technique called a "mirror port". On some of the better quality switches there is a mirror port which replicates all the traffic from all the other ports, so anything plugged into the mirror port can effectively see all the packets buzzing through the switch. The server running the software also has two NIC's, a dedicated one for the mirror port and a separate NIC for issuing blocked messages if required.
The fundamental problem with this scenario is that it relies on the SurfControl/WebSense software intercepting, scanning and blocking a web request faster than it takes for the web page to get back to the workstation that requested it via its normal route. On a slightly congested network or on an overloaded proxy server, there is a good chance that the requested page will not be blocked in time. This was confirmed to me in a meeting on Monday whereby one of our resellers with experience of SurfControl, told me that quite often the first request for a pornographic web site would be allowed but the second visit would be blocked. This unreliability is surely not acceptable - what if that happened in a school, or if the web site contained malware which on the first visit infected the machine?
With CensorNet Pro, there are two deployment options - both of which ensure that no request goes unfiltered, if that is your chosen policy.
Sideways mode - this is the traditional and default mode, whereby browser proxy settings point to the CensorNet server. The browser settings can be configured automatically using Active Directory group policy or WPAD (Web Proxy Auto Detection). By using the browser proxy settings you are ensuring that all web requests get handled by CensorNet before they are displayed in the web browser.
Inline mode - this mode requires two NIC's in the CensorNet server. The two NIC's will form a bridge between your corporate switch and your gateway/router/firewall. All packets will be transparently intercepted if they are destined for port 80 or 443, in either direction. You do not have to configure browser proxy settings, however, if you want to report on usernames then you will need to install a small client on each computer (using Group Policy updates). Once again, in this mode, no web requests will get back to the browser until they have been inspected by CensorNet.
So if complete security is one of your tick boxes when implementing a web security device, then it may be worth giving some thought to how it is deployed and even if the "mirror port" sounds like the quickest and easiest it might just cause you a whole heap of problems further down the line.
Thursday, June 11. 2009
If you ask many people why they install a filtering proxy they will first of all roll off the old adages of they want to block pornographic or other obscene web sites from being viewed and follow up with the need to control people.
The CensorNet can, of course, be used in such a negative way, but we prefer to see it in a more positive light.
I think we can all agree that web sites showing pornographic images or other material do get in the way of the working day, whether you be in an educational or office based environment.
But as an interview with Tim Lloyd, our CEO, shows we don’t intend the filter to be something that is just there to block the negative, to the contrary, it is there to enable people to be able to visit the sites they should be viewing in order to do their work whilst blocking those sites that might otherwise pose too thrilling a view to some colleagues.
If only the employers of the person described in this article had had such a positively discriminating filter in place, they would still have an employee, and more importantly, that employee would not have gone to jail, nor have been charged restitution fees.
As this article goes on to make clear, you should have a rock solid Acceptable Use Policy (AUP) in place as part of your security armoury. Make your statements of acceptable use therein and then use the CensorNet to enforce them. That way, not only you, but your users, will come to see it as a benefit and not something that they consider as something that gets in the way.
Saturday, May 16. 2009
In the latest releases of CensorNet (1.4.20 and 1.5.7 at the time of writing)[1] we have introduced time based quotas.
In one sense these have always been available as you could have defined a specific policy with specific rules which you could then schedule into the day at a set time. However, this did not cover the fact where you were happy to allow your users to browse certain sites for a certain time, but did not want to specify exactly when that usage should occur within the working day.
Time based quotas resolve this by working in exactly that way. When you create a new policy, or modify an existing one, there is a Time Quota setting field immediately under the Block/Allow rules and Dynamic sites modifiers. The default value is 15 minutes, but you can select a time limit from a wide range of values available in the drop down selector.
Having specified the quota limit that applies for that policy, for any category set to “Allow” in either the Custom URL module or Content Classifier module, you can check the quota box.
URLs that fall within categories under quota control can then only be browsed for the time limit you set. When the quota is exceeded the user receives a block message explaining that the site is now blocked because the quota has been reached.
Each user has their own quota so the fact one user on a policy is suddenly being blocked due to quota exception, another may still be able to reach a site. The quotas for each user are reset at Midnight.
For a URL that falls into multiple categories, the quota will apply if any one category is quota controlled, even if the other categories are not.
[1] For the time being we are keeping the 1.4.x and 1.5.x versions of CensorNet synchronised. They are functionally identical, only the underlying operating system is different. If you are still running CensorNet 1.3.x we recommend that you upgrade to CensorNet 1.5.x by following the migration instructions. If you are running 1.4.x you will eventually have to upgrade to 1.5.x. We will announce when this is necessary.
Monday, May 4. 2009
Those of you who have been using our products since the Open Source version will remember that installation simply involved downloading an ISO which contained both the underlying operating system and the CensorNet code. You will be pleased to hear that we have reverted to this method of distribution with CensorNet 1.5.x.
The reason for bringing this out in such an easy to use package is because we were forced to change the underlying operating system we used in our VMA package (the ready to go VMWare instance you can install on top of your hypervisor). As a consequence we decided to provide CensorNet with the Ubuntu operating system in an easy to use ISO.
This means that users who wish to install CensorNet for the first time on bare metal can now just download the ISO from the nearest download mirror. Users who want to install on top of VMWare software can download a pre-built VMA. Alternatively, they can download the ISO and use it to install into a VMWare instance they have prepared to receive an operating system.
If you just want to try out this package and see if our product will work for you, you can license your download for 24 hours immediately. If, as most people do, you need longer than this to conduct a full test then you can request a trial license which typically runs for 14 days.
All of the traditional filters are present and of course there are all the hooks you need to use our optional modules (Malware Prevention, Phising Protection and On-Demand Anti-Virus) providing your license supports them.
All of this should mean that new users can get from download to functioning system even more quickly.
|
