Wednesday, April 9, 2014

Statement: OpenSSL "Heartbleed" and Smoothwall

Some of our customers have been asking about Smoothwall's vulnerability to the "Heartbleed" issue in OpenSSL. We can confirm that our version of OpenSSL is not vulnerable to this issue, and our version of GnuTLS has also been upgraded as of update73 to resolve another possible, but unrelated, SSL vulnerability, of which OpenSSL's is the latest of 3 recent issues in SSL implementations.

Smoothwall users are protected from Apple's recent bug (link below) by browsing through the web filter, however they are not immune to the "Heartbleed" issue where present on other web sites and services (though a MITM filtered connection is perhaps marginally harder to attack).

More information on each issue can be found here:
OpenSSL "Heartbleed"
GNUTLS issue
Apple "Goto fail"

Tuesday, February 11, 2014

Safer Internet Day: 4 Things You Might Not Realise Your Webfilter Can Do

Since it's Safer Internet Day today, I thought i'd use it as an excuse to write a blog post. Regular readers will know I don't usually need an excuse, but I always feel better if I do.

Yesterday, I was talking to our Content Filter team about a post on the popular Edugeek forum, where someone asked "is it possible to block adult content in BBC iPlayer?". Well, with the right web filter, the answer is "yes", but how many people think to even ask the question? Certainly we hadn't thought much about formalising the answer. So I'm going to put together a list of things your web filter should be capable of, but you might not have realised...

1. Blocking adult content on "TV catch up" services like iPlayer. With use of the service soaring, it's important that any use in education is complemented with the right safeguards. We don't need students in class seeing things their parents wouldn't want them watching at home. There's a new section of the Smoothwall blocklist now which will deal with anything on iPlayer that the BBC deem unsuitable for minors.

2. Making Facebook and Twitter "Read Only". These social networks are great fun, and it can be useful to relax the rules a bit to prevent students swarming for 4G. A read-only approach can help reduce the incidence of cyber-bullying and keep users more focused.

3. Stripping the comments out of YouTube. YouTube is a wonderful resource, and the majority of video is pretty safe (use Youtube for Schools if you want to tie that down further — your filter can help you there too). The comments on videos, however, are often at best puerile and at worst downright offensive. Strip out the junk, and leave the learning tool - win win!

4. Busting Google searches back down to HTTP and forcing SafeSearch. Everybody appreciates a secure service, but when Google moved their search engine to HTTPS secure traffic by default, they alienated the education community. With SSL traffic it is much harder to vet search terms, log accesses in detain, and importantly force SafeSearch. Google give you DNS trickery to force the site back into plain HTTP - but that's a pain to implement, especially on a Windows DNS server. Use your web filter to rewrite the requests, and have the best of both.

Tuesday, January 28, 2014

A word about achieving PCI compliance on Smoothwall systems

Many people use security scanning software to audit the network. Either generally as part of day-to-day network operations, or when evaluating some new product.

These tools are fine and serve a useful purpose.  However, as with many tools, they are only as good as the person interpreting the scan results.  Oftentimes we will have customers contact our Managed Services department with an enquiry about the results from such scans.  Occasionally it looks as if the Smoothwall system is rife with issues; the scanning software occasionally highlighting "critical" problems which, on closer inspection, mean very little at all from an real-world threat perspective.

Some examples of the kind of output you might see when scanning:

  • "The web-server presents a self-signed certificate" - This "vulnerability" relates to the fact that the Smoothwall, in a standard shipping configuration, presents its' HTTPS connection with an automatically created self-signed certificate and not one you could purchase from a Certificate Authority. Generally these self-signed certs are adequate for small deployments, and indeed you should consider that the scanner is highlighting a configuration decision made on the part of the administrator, and not showing a real world vulnerability.
  • "TCP Timestamp response" - TCP timestamps are a performance feature for increasing the speed of TCP sessions (RFC1323). Nonetheless, the PCI scan will show a low-level vulnerability because the TCP timestamp can be used to determine the target system's uptime, which is (theoretically) useful to an attacker. In any case this option can be disabled using the Networking > Settings > Advanced page. Note that Smoothwall ships with this option enabled, because in the general case network performance is paramount.
  • "ICMP timestamp response"- Similar to the above. ICMP timestamps, while a feature of a standards-compliant TCP/IP stack, are not very useful to anyone and present a generally useless information leak to a potential attacker. A future update will add the ability to disable these responses through the admin interface all the same. In the mean time, this should not be considered a concern and disabling this feature's biggest benefit will be to succeed in giving you warm fuzzy feelings because your scanner now produces less output.
  • "Apache HTTPD: ETag Inode Information Leakage"- ETags are a mechanism used by browsers to know if URLs have changed on the server, so that the browser can know if it has to re-download the URL. A current Smoothwall will generate these tags, to assist the browser in caching images etc. However, in 2003 a vulnerability report was raised against this behaviour in the Apache webserver which Smoothwall incorporates. This vulnerability relates specifically to the use of ETags in file sharing (NFS) setups, something that Smoothwall has never and will never do. This vulnerability is therefore a prime candidate to be considered a false-positive. But nevertheless, the utility of these ETags is not high, so in a a future update ETags will be disabled just to quieten this report from PCI scanners.
  • "Weak Cryptographic Key" - This is the closest thing to a genuine issue so far listed. Over time, computers become faster. This PCI scanner message is an artefact of this and appears because the previously described self-signed certificate is signed with a 1024 bit key. Only a few years ago this was considered excessively long, but up-to-date PCI scanners now flag this as being not completely adequate. It should be pointed out that breaking a "mere" 1024 bit key still requires many years, even with thousands of computers working at the problem. But still, the NSA is rumoured to be able to crack 1024 bit encryption. And in keeping with PCI recommendations, Smoothwall will switch to using 2048 bit keys in all of it's internally generated certificates and keys.
I hope the reader finds this information useful. As the old saying goes "Security is a process". There are no magic bullets, or black and white answers, but the following is a good start:
  • Keep your systems up to date
  • Expose services only to the people who need, and use them
  • Perform regular audits

Thursday, January 2, 2014

5 New Year's Resolutions to Keep You Safe on the Internet

Happy New Year etc.! OK, now the pleasantries are out out of the way, we can get on with the usual cliche'd list of New Year's Resolutions. You can see I'm going well already with my drive to avoid cynicism in blog posts. These resolutions are aimed more at your personal IT needs than your work life, but you might find a spot of cross applicability in any case.

  1. Housekeeping! - Yes, it is a bit early for a spring clean, but since you've a while to go before you have to break out the washing up gloves and the hoover, you've got time for a bit of a clear-out in online accounts. Each login you have, even if it doesn't protect anything "interesting" or "valuable", is a potential route in for a "cross site privilege escalation" - an attacker could, for example use this to find your postal address or mobile number, which you gave on sign-up, and use these to gain entry to a more "interesting" site, which may have your credit card details. Take a look back at the marketing emails you received in December (they're all at it over the holidays so this is a great time for it) and close down anything you don't use. 

  2. Pesky Passwords - by following the first resolution, you've protected yourself some more against having your password stolen in a site-breach - there's been enough of these in 2013 to sink a battleship. Ideally, you're going to want a different password for each site or service, and there are 2 ways to help reduce your password re-use: First, federate login (eg. through google and facebook), which is very much putting all your eggs in one basket - so you had better watch that basket by following my other resolutions. The second method is to use a password service, such as lastpass. There's no reason not to have a little from column A, and a little from column B, of course. While you're at it, you might check to see if any of the passwords you've been naughtily re-using have been leaked to the world here:

  3. Backup: Half the Story - and I'm assuming you are halfway there, right? You should back up as much as possible as often as possible. I prefer "everything, all the time" for my files (I personally use backblaze, good value for money!) Other backup services/strategies exist. YMMV. The other side of the backup story is restore. Having your files sent to the great hard disk in the sky is all well and good, but you need to be sure you can get them back. At the very least, pick a few files and try to restore them. You might find a problem you never knew you had!

  4. No Pain, No Gain - 2 Factor Authentication. Yes, I mean you. Pay attention at the back. I know you've been putting this off because you think it will be a pain in the backside. Yes, it will, but once you're used to it, it's minor, and the protection afforded against keyloggers and brute force attacks are not to be understated. This isn't a panacea, but it's one more useful protection against the legion wrongdoers. Many sites & services now support this, a not-particularly-exhaustive list on a post over here.

  5. Finally, One Good Turn... - I'm quite sure you are already 100% on top of all of these suggestions, so I am going to leave you with resolution 5 - go help someone less fortunate (in the Info-security sense) than yourself. Parents, siblings, other-halves, whoever. I know, it's a pain, you're probably the person they'll come to when it all goes pear shaped in any case, and you do enough family tech support as it is, blah blah. Nut up, and go do a good turn. It's the new year, and you'll feel better for it. Not only that, but some of these resolutions will help reduce the calls you get in 2014 from panicking friends and family, and their security is, in many ways, allied to your own. Much like a compromise on a "less important" account that can be priv-esc'd, a security-compromised friend is a threat to your own online safety. On the subject of good turns - if you're after more resolutiony goodness, check out Graham Cluley's list here.
One last thing... thanks for reading the Smoothwall blog in 2013, hope we can keep you interested and entertained in 2014. -Tom

Wednesday, December 18, 2013

Gmail Users: Google Makes Your Data More Secure, Owns a Bit More of Your Life

The lovely people at Google have just quietly released a new feature. Google's mail client now automatically shows images from all senders.

Apparently, this is safe now - because all images you see in gmail will be proxied through google's own servers. Now we don't have to worry about viruses and malware in images. Well, we didn't often worry about those in the past - images containing viruses are most often a hoax, the odd PoC, and of course there are some targeted attacks at poorly written image libraries which would form the basis for a driveby. These concerns, and their validity or otherwise, aren't the real reason we turned off images are they?

No, we turned off images because we wanted to make the trade off between marketing people tracking us, and seeing the image. If the image was going to be useful, or worth seeing, we'd load images. If not, it was probably a "web bug" use to track opens and forwards by canny marketing types.

So, now you know that every image in your gmail is being definitely tracked by canny marketing types - except it is those at Google, rather than the guys who sent the email who are getting the full picture. Bear in mind also, that this is implicitly an HTTPS man-in-the-middle attack. This means that if an image was previously sent securely end-to-end between the email sender and you, it has now resided in the clear somewhere on Google's servers. Of course it's still encrypted in transit - but at some point that image stopped being secure, its origin stopped being verifiable in the same way, and Google served it to you fresh.

I know that Google already know what you are doing with your gmail, but this is one more fragment of your web browsing that's now hitting their servers before it hits the origin.

Yes, I fully appreciate the irony that this blog post resides on Google's infrastructure. They already know what I had for breakfast anyway.

Wednesday, December 4, 2013

Don't Complain About Social Media Bores

Some of my older readers will remember a time before social media, when we had real friends, and talked about real things. They'll remember it fondly, and talk about those halcyon days of pints down the pub, phone calls and lovingly crafted snail mail. To be honest, we are probably better off with social media, but there's still a few things that we might miss. In the "good old days", you could easily avoid the boring guy who had only one topic of conversation (like how rotten his shifts at the mill were). Now we're stuck listening to "social media bores" because we know if we unfriend/unfollow them, they'll know, and it'll just be even worse.

After an in-depth meta analysis, and extensive survey (OK, I hit google and had a chat with 4 colleagues), it can be revealed that the top 5 "Social Media Bores" are:

1. The Braggart: This guy can't buy a replacement lightbulb without telling you why he's got the best. Expect: Holiday bookings and new-car photos

2. "Guess where I am?": She can't help but tell you where she is, regardless of how dull it is.
Expect: "In Slough", "At the local shop", "Entering purgatory... where to next?"

3. The cat bore: Yes, we know you've got a cat, you use him as your profile picture.
Expect: Pictures considerably less funny/cute/well captioned than those already littering facebook

4. The Cliffhanger: An Unspecified emote - and we're all supposed to guess what's wrong?
Expect: "Feeling really sad", "Great news!" (and then nothing)

5. Captain Gullible: Is there a hoax this chap hasn't swallowed hook line & sinker?
Expect: "Did you know water drains anticlockwise in Australia?"

Now comes the hard part. I want you to forgive these guys. I ask you this, not in the spirit of the holiday season, but because I have discovered that it is virtually impossible not to be a social media bore. Observe:

So, if you do want to say something you might think twice about tweeting, maybe hang on, and do it over a beer - or don't say it at all!

If you are interested, here's some of the research I didn't do:

Legal issues:

Workplace issues:

Family issues:

  • Try not to follow escort agencies on twitter if anyone might be watching you
  • I'm told one of my colleagues once got told off by his mother for something he said on Facebook - didn't even make the local news though!


Wednesday, September 18, 2013

7 Ways To Deal With HTTPS traffic

HTTPS traffic. It's a bunch of encrypted zeroes and ones flying through our firewalls and web filters, and frankly many people haven't got much of an idea what it's doing or why it's there. There are business critical apps aplenty that require you to let this impenetrable traffic march on, but what can we do to gain a bit of visibility? In a rare moment of caffeine-induced lucidity, I lay out your options:

1. Do Nothing

This is one of my favourite options - complete inaction. Whilst it might seem like it is a safe bet, after a while things start to go wrong. Sometimes, I take this approach to household chores: it's liberating to not do the laundry for a while, but the day you run out of socks is a dark day indeed.
User Impact: *****
Blocking Efficacy: (that's no stars!)
Advice: Only if you like to have problems

2. Block it ALL!

Not a great idea this one. Might have worked in the deep and distant past, but today's Internet will have no truck with that. Back to doing laundry, it's the equivalent of putting up with prodigious and vile body odour because you can't be bothered to wash your smalls. Might have worked in 200BC, but in 2013 you will likely find it a social faux-pas. Apologies to any readers who were eating breakfast while reading that :)
User Impact: (that's no stars!)
Blocking Efficacy: *****
Advice: Don't do it!

3. Look for Reverse DNS

So I want to allow HTTPS traffic through, but I want to be selective. I know - I'll take the destination IP and do a reverse lookup on it, then I can use that to match... I'll be able to control everything. I don't have a sock analogy here - sorry folks (well I do, but it would be stretched thinner than even the most ardent fans of my blogging would take - an exercise for the reader to build their own!). Reverse DNS is basically pretty unreliable. It's OK for spotting some of the big stuff, so you might whitelist based on it, but conversely it's terrible as a whitelist because it is inclined to miss bits. Yes, more of the internet than ever has reverse lookup, but this still sucks.
User impact: *****
Blocking efficacy: **
Advice: Don't do it!

4. Use Plaintext header information to domain block

This is more like it. Anyone using a "traditional" proxy, where you set up the computer to use an HTTPS proxy, can already do this.

Modern SSL implementations are actually TLS implementations - SSL went out of fashion when flared trousers and wearing a baseball cap backwards were the hottest news. TLS is what we are really using when we refer to SSL. Anyhow, there's a cute little extension to TLS called SNI. This method won't work with really ancient browsers.

For those of you still awake, these methods let your web filter block accurately by destination domain. Not URL, domain. Just the first bit. Everything after the / is still mystery meat. This is a reasonable option for blacklist, and a great option if you're whitelisting.
User impact: *****
Blocking efficacy: ***
Advice: No brainer, get it turned on

5. Verify Certificates

You can, and should, check certificate validity on your web filter. It's that simple, really. There's a few gotchas - in that sites with self signed certificated will need explicitly allowing, but otherwise, this is a great idea. One of the main advantages to this method is the blocking of HTTPS proxy anonymizers, which rarely go to the financial trouble of a full, CA signed certificate.
User Impact: ****
Blocking Efficacy: *
Advice: Use in conjunction with another method, but do use it

6. Full Inspection

If you're really keen to protect against the threats of web-borne malware, and you want the best filtering, then this is the gold standard. A "Man in the Middle" decryption allows your filter to see the full URL and content, so you can do fine grained blocking, search term analysis and anti-malware scanning, among other things. Of course your users will see a certificate warning if you do this, as you'll be re-signing a certificate claiming to be or whatever. The only way round this is to install your Certificate Authority (CA) on your users' systems. Don't install one that's not got your organisation name in it - some vendors just produce a "standard" CA, and this is really dangerous, allowing the vendor unfettered backdoor access to your clients' browsing. Full inspection can be tricky for BYOD as you have no easy way to push out the CA - so  bear that in mind when deciding how to filter.
User Impact: **
Blocking Efficacy: *****
Advice: Definitley use for machines you can push policy to, advise caution on BYOD

7. The NSA Option

If you are the US government, there's always the option of spending a whole heap of your billions of dollars in black budget breaking everyone's crypto. While this is highly effective, people will then tend to avoid you at social functions, and may talk about you behind your back. But at least you'll know what they are saying.
Blocking Efficacy: BLOCKED
Advice: Be afraid