Protecting Your Computer Online For Free

Protecting your computer online is a minefield of choices for a user to contemplate; should you trust the software you install not to be riddled with backdoors, the websites you visit to make sure their code isn’t riddled with malicious scripts or linked to malicious third-party sites, the ISP who provides your connection to stop the bad guys before they get to your home connection, or a combination of all to make sure you don’t get hacked/compromised/infected, become hijacked and join a botnet or lose your private information?

For my day job, I often see company networks relatively well protected with Next Generation Firewalls which inspect protect corporate networks from attack using advanced IDS/IDP/Content Filtering/Application Inspection features, but these devices cost a lot of money. So how to add some much needed protection to your computer, for free?

If you checkout my other posts here, you’ll notice I’m a bit of a Blue Coat fan. I’ve worked with their products for 10 years and have always been mightily impressed with their capability of protecting corporate users from websites which want to install malicious code or steal information. As with the Next Generation Firewalls, those Blue Coat products cost money, however there’s one product Blue Coat provides which is designed with home users in-mind and is free; K9 Web Protection.

K9 is specifically designed to allow Parental Control of children’s internet browsing, restricting which website categories your child can visit, how much time they can spend online and whether Search Engine Safe Search is enabled. Whilst this is great, K9 can also provide highly effective protection for everyone’s computer whether you have children or not.

K9 uses Blue Coat’s ‘Web Pulse‘ collaborative online rating system. Web Pulse is a global network maintained by Blue Coat which provides an almost instant rating of categorised and uncategorised web pages using many different methods such as page content, links on the page to other websites, DNS information, hosting history (e.g is the server hosting the website also hosting content from a known malicious source) and historical reputation. It rates 1 Billion+ requests per-day from 75+ million users worldwide. The ‘collaborative’ part of this system is that all of the Blue Coat corporate devices (the ProxySG, ProxyAV and PacketShaper), and existing K9 users feed uncategorised URLs to Web Pulse for it to rate. The effect of this is that any URL one user sends to Web Pulse for categorisation, other users of Web Pulse get the benefit of that categorisation. Thats very cool, no?!

I won’t go into getting the software install, there are some very good instructions on the K9 website on how it’s done, instead I’ll show you what you need to do to protect yourself from the bad guys online.

First, login to the K9 Web Protection (usually in Program Files / Blue Coat for Windows or Applications / K9 Web Protection if you use a Mac), and navigate to the ‘Setup’ section.

By default, when you install and activate K9, it blocks a number of categories out of the box.

You may want to keep those as is, however if you want a less restrictive, but still protected level of categories, choose ‘Custom’ then check the following.

Make sure you click ‘Save’ at the bottom of the page to finish the changes.

Finally, under ‘Other Settings’ (on the left), ensure that ‘Enable HTTPS Filtering’ is checked (this is the default).

Why enable HTTPS filtering? See below at the end of the document for more information.

A Real Life Use Case

As an example of how K9 can protect users online, lets take my wife’s internet browsing habits. She’s what I’d class as a ‘regular’ internet user, browsing shopping sites, checking her email, and watching TV online. My wife is a Filipino, so likes to keep up-to-date with programs from the Philippines. There are a few places online which allow this, but she primarily uses just one. That site is packed with advertisements, popups, and links to other external sites as I guess they have to pay for it some how, however, here’s a snapshot of the K9 Web Protection report from her Macbook.

So, as a ‘regular’ internet user, with no intention of visiting a site which is malicious, she’s visited something which is clearly classified as Suspicious or Spyware/Malware Source according to K9!

Why HTTPS?

I mentioned above that you should ensure ‘Enable HTTPS Filtering’ is enabled in K9; the reason why is that malicious content is more and more often distributed over HTTPS. I recently came across some clients which were attempting to do just this when inspecting a Blue Coat ProxySG appliance. The following domains were those which clients were attempting to connect too –

baoh7q0me83hg.www5.jub.cc
mojp2e.oul.su
h53afv15zv6diw6xx.jub.cc
8enqzskkkn4kn061ee.oul.su
uyx0v0en.ioh.cc
3kvte9y6i.vng.su
7hlaxwh4.vng.su
6e7ezku4z7142l.oul.su
m6hot8f.www5.ioh.cc
ek9hsz4kpw.sge.su
9usu4uw3hf9nynrr.jub.cc

Those domain name look suspicious straight off, no? Here’s a screen capture of those connection attempts. In this case, the client computer is attempting to make a HTTPS  ‘CONNECT’ to the sites listed above. ‘CONNECT’ is the method used by HTTPS communication to setup the session between your client and the server on the internet.

In this case, as the customer was protected by a ProxySG appliance, the requests were blocked, however it is a good demonstration of why HTTPS, as well as HTTP should be inspected if you use K9.

So there it is, protect your computer (or Mac) online, for free. Install it now, before its to late!

DHCP IP Addresses with Blue Coat ThreatPulse/Juniper SRX

A problem landed on my desk the other day from a customer in relation to using the excellent Blue Coat ThreatPulse cloud SaaS product when the Juniper SRX sits behind a DHCP assigned public IP Address. Worse, due to the location of some sites and the ISP offering available, the SRX was itself behind a home broadband NAT router doing IPSec pass-through in order to establish a connection back to the corporate network.

ThreatPulse is Blue Coat’s SaaS which has been around for a couple of years and leverages the use of their existing Web Pulse(TM) dynamic rating system to categorise unknown URL’s on-the-fly or return previous categorisation. With Data POD’s located strategically around the world, it’s possible to control web access for HQ, home or roaming workers in a single place using one of several methods –

• Explicit Proxy – Configuring client browsers to use ThreatPulse directly
• IPSec Forwarding – Configuring an edge firewall to transparently intercept requests and send them to ThreatPulse using a LAN-to-LAN tunnel
• Proxy Forwarding – Utilising an on-site proxy to forward requests to ThreatPulse.
• Client Connector – A software package which sits on a client machine (Laptop/Mac) which transparently intercepts requests and sends them to ThreatPulse
• Mobility Connector  – An iOS client which creates a VPN tunnel to ThreatPulse to control what apps and browsers can do on iDevices.

This particular problem, and the solution I came up with relates to the first three connection methods, Explicit Proxy, IPSec Forwarding and Proxy-Forwarding. Each of these methods requires that you setup a ‘Location’ within the ThreatPulse dashboard.

Selecting the IPSec (Firewall/VPN) location brings up its configuration section.

As you can see, there’s no place to update this dynamically, and ThreatPulse doesn’t support Aggressive mode VPN which can sometimes help to mitigate such problems. In this case, however, we have to do something at the SRX end.

There’s some useful information on Blue Coat’s Knowledge Base for making changes to ThreatPulse using the built-in API. The API is designed for situations like this where administrators need an automated way of updating ThreatPulse, but without having to login to the administration dashboard. Unfortunately, the documentation doesn’t specifically cover Juniper SRX (or SSG for that matter), it covers Cisco IOS and using ‘ip ddns’ commands to update the ThreatPulse service settings. All that said, the API can be used in-conjunction with the SRX and what follows is how I did it.

In some of my previous posts I’ve used the underlying BSD cli to update things like Firewall Filters. Using this method again, we can update ThreatPulse Location settings without having to login.

When in the shell of JunOS, there are several useful commands available – CP, CuRL, Diff, and Cat. These are used in the following script –

#!/bin/sh
cp ipnow.txt ipprev.txt
curl http://andymillett.co.uk/rip.php > ipnow.txt
IPN=`cat ipnow.txt`
if diff ipnow.txt ipprev.txt >/dev/null ; then
else 
 curl "http://<user>:<password>@portal.threatpulse.com:8080/api/locations?name=<location>&type=<type>&ip=<NEWIPADDRESS>&key=<PRE-SHARED-KEY>"
fi

Basically, the script copies the last IP Address check results from ‘ipnow.txt’ to ‘ipprev.txt’, uses CuRL to get the Public IP Address at the time the script is run, and copies the output to a new ‘ipnow.txt’ file after which it performs a ‘diff’ against the two files within an ‘if’ statement. If the ‘if’ statement evaluates that the two files are the same, it does nothing, however if it evaluates that there is a difference, it performs a ‘cat’ against the new ‘ipnow.txt’ file and uses it as part of the new CuRL string sent to ThreatPulse API which updates the location.

The other end of this is a simple PHP page which returns the IP Address in text form.

<?php
function getIP() {
$ip;
if(getenv("REMOTE_ADDR"))
$ip = getenv("REMOTE_ADDR");
else
$ip = "UNKNOWN";
return $ip;
}
$client_ip=getIP();
echo $client_ip;
?>

All it needs is to be on a public Web Server somewhere the SRX can get too.

With both ends in place (the script on the SRX, and the PHP script on the Web Server), you can run the script manually if you like by running – ‘sh <script_name>’.

To test that the script would work properly, I setup two additional scripts on the SRX in our Lab. Both simply do a ‘load replace’ from a pre-defined file (script 1/2 data below) –

Script 1

{
echo "configure"
echo "load replace if15.txt"
echo "commit check"
echo "commit"
echo "exit"
} | /usr/sbin/cli

Script 1 data

interfaces {
replace:
fe-0/0/7 {
 unit 0 {
 family inet {
 address 94.17.248.15/27;
 }
 }
}

Script 2

{
echo "configure"
echo "load replace if16.txt"
echo "commit check"
echo "commit"
echo "exit"
} | /usr/sbin/cli

Script 2 data

interfaces {
replace:
fe-0/0/7 {
 unit 0 {
 family inet {
 address 94.17.248.16/27;
 }
 }
}

Following this, three cron entries were required to kick things off

*/5 * * * * (cd /cf/var/home/cronadmin; sh checkip.sh)
5 1,3,5,7,9,11,13,15,17,19,21,23 * * * (cd /cf/var/home/cronadmin; sh uif15.sh)
5 2,4,6,8,10,12,14,16,18,20,22 * * * (cd /cf/var/home/cronadmin; sh uif16.sh)

Line 1 executes my script to check the external IP address.

Line 2 executes the change IP ‘load replace’ script at odd hours.

Line 3 executes the change IP ‘load replace’ script at even hours.

Having left this running for a week, the results are pretty good (below is from my ThreatPulse account under the Services / Account Maintenance section which gives a full audit of what has been happening under the account) –

Sweet! Simple Unix commands and a cron script save the day!

Unfortunately, I don’t have a DSL connection which I can put an SRX onto behind a NAT router, however this script will work irrespective of this (e.g it will pickup the public IP of the NAT router).

The above script is for IPSec Forwarding (Firewall/VPN in ThreatPulse speak), however the script above will work in just the same way if you choose to use the Proxy-Forwarding or Explicit Proxy method. For example –

Proxy-Forwarding

https://<username>:<password>@portal.threatpulse.com/api/location?name=<location_name>&ip=<IP_address>&type=proxy-forwarding

Explicit Proxy

https://<username>:<password>@portal.threatpulse.com/api/location?name=<location_name>&ip=<IP_address>&type=explicit-proxy

Now, you might perhaps notice that the above examples use HTTPS, whereas my script uses HTTP over port 8080. Weeeeeeell, unfortunately, when Juniper compiled JunOS and it’s associated libraries, the didn’t include HTTPS in ‘libcurl’ which leads to the following error if you attempt to use HTTPS –

curl: (1) Protocol https not supported or disabled in libcurl

This, despite the fact that the options are available under ‘–help’. For example –

-1/--tlsv1 Use TLSv1 (SSL)
-2/--sslv2 Use SSLv2 (SSL)
-3/--sslv3 Use SSLv3 (SSL)

That strikes me as a bit shoddy, but we have to work with what we get. Perhaps Juniper will fix it in later releases.

So there it is, if you have purchased Blue Coats excellent ThreatPulse SaaS (and, oh boy should you) and you have an SRX which is sat on a DHCP assigned IP address somewhere on your network, the above will help you keep ThreatPulse updated with any changes in the IP.