In the right place Tor is a godsend, in the wrong it presents a significant problem.
Ever since The Onion Router (Tor) anonymity service started being used in the mainstream around five years ago, enterprise admins have been wondering whether it represents a risk worthy of blocking and, if it does, how this can be achieved.
UK case studies examining the risks issue are pretty much non-existent and the only sector that offers much anecdotal evidence has been in universities where Tor has, predictably, gained a following or sorts. It’s not hard to understand that Tor has plenty of perfectly legitimate uses (it is not our intention to stigmatise its use) but it also has plenty of troubling ones such as connecting to criminal sites on the ‘darknet’, as a channel for malware and as a way of bypassing network security. The anxiety for organisations is that it is impossible to tell which is which.
Tor is not the only anonymity network designed with ultra-security in mind, The Invisible Internet Project (I2P) being another example. On top of this, VPNs and proxies also create similar risks although these are much easier to spot and block.
Tor can live inside networks either as a browser that bundles the services into a piece of easy-to-use piece of software or, potentially more seriously, as a server node or network bridge that becomes parts of its network. Although network users can set up one or both of these, it’s important to grasp that neither is good news for an organisation for a variety of reasons. A related issue are web sites that don’t want Tor users connecting anonymously to whatever service they are offering although this is a specialised problem.
Risk 1: The darknet
The darknet is more than hyperbole. A Kaspersky Lab estimate from early 2014 put the number of criminal services using it at almost 1,000, almost certainly a sizable underestimate. Whatever the figure, the number that will have increased several fold by now. The darknet would exist without Tor, of course, which simply a way of reaching it without revealing the client’s IP address or browsing list.
Risk 2: Malware, botnets, DDoS
On top of this, criminals have also started using Tor as a communications channel for malware command and control (C&C), which means that its presence can indicate infection and compromise. For most organisations this will probably be the biggest worry of all. Although Tor C&C is slower it is a tempting place for malware to hide its communications. The bandwidth of some of the exit nodes has resulted in Tor being hijacked for DDoS attacks.
Risk 3: Blacklisting
Assuming that an organisation sets out to control Tor use, blocking this involves two elements that cover incoming/outgoing traffic, where someone has established a Tor node, and outgoing traffic, where a client PC is connecting to a Tor entry node. Most admins will focus on the latter, reasoning that it is the more likely problem but it is important to remember that setting up a Tor node inside a network isn’t that hard to do. This is a major potential headache because it runs a risk of an organisation’s IP being added to an Internet block list.
Blocking by port: As mentioned below, Tor is partial to common ports such as 443. But this offers little solace. That port if used by HTTPS and so it cannot be blocked completely or a network’s web access will grind to a halt. Tor will simply look like everything else.
Blocking at the endpoint: Thinking laterally, it should be possible to stop users from installing the Tor software in the first place by implementing application whitelisting or privilege management. However, Tor can also be run pre-installed from a USB stick which means it can in some cases bypass such controls.
Blocking – from IP ranges to DPI: From the network side, the first task is to identify Tor use on the LAN side to check the scale of the problem, which is not as easy as it sounds. Because Tor uses TLS encryption (the successor to SSL), the traffic won’t be easy to spot and its content will be impossible to interrogate. If a Tor node is set up inside a network then in principle this could be used as a bridge to the first Tor entry node. By time the traffic reaches the firewall it will be doubly difficult to see.
A common technique for spotting Tor is to correlate SIEM logs with a list of publically-known IP addresses used as entry nodes. This is where most admins start but unfortunately this can be a long and constantly-changing list and is highly unlikely to cover hidden nodes that are a feature of the system. Some of the servers acting as Tor entry nodes will also be used for legitimate purposes which raises the possibility of blocking innocent traffic and generating a false positive.
Another manual technique is to use the Deep Packet Inspection (DPI) interface on the firewall to look for signs of unusual certificates used by nodes, although this assumes you know which ports are being used. Tor uses 443, but also 80 (HTTP), 9001 and 9030 although it could be using almost any other port it can find so this is at best a starting point.
Coincidentally, it was the use of DPI that in 2012 made Tor blockable in countries such as Iran and Ethiopia for a period of weeks.
Tor and the enterprise 2016
Detecting Tor is no going to be easy although IP address filtering should reduce the risk. To us it doesn’t seem particularly fool-proof or easy and quick to manage on an ongoing basis. For that reason, a lot of firms will fall back on generalised detection policies backed up by tough penalties for running non-approved applications. Technology will only get you so far.
John E Dunn, IDG News Service
Subscribers 0
Fans 0
Followers 0
Followers