35

We work in an organisation which is supposed to be HIPAA compliant. Security is a big concern for us. We've been tasked to find out if any user is using anonymous proxy in the network.

Is there a way we can find if Tor is being used inside our corporate network domain? We're using Symantec client protection. VPN is provided using Cisco.

  • 125
    HIPPA compliance does not require checking whether any of your employees are using Tor, as far as I am aware. I suggest you go ask whoever tasked you with that to justify their requirement. Are you sure you want to be monitoring your employees like this? Perhaps you would do better to think more carefully about what your threat model is, what exactly you're trying to achieve, and whether this is truly the best way to achieve that. A checklist mentality is rarely the best way to achieve real security. – D.W. Sep 5 '16 at 17:05
  • 53
    "We've been tasked to find out if any user is using anonymous proxy in the network." I'd suggest asking whoever tasked you with doing that to let you know what the approved methods for doing so are. If they don't know, ask them to ask whoever told them to tell you to do that what methods are approved for doing so. If you can't get an answer, send an email out to all users asking them to report any such usage. – David Schwartz Sep 5 '16 at 23:48
  • 19
    Keep in mind that tor is being actively developed to bypass state level detection mechanisms - i.e. the great firewall of China I don't know what your technical level is, but I'd take a small bet that you're not at the resources or technical ability of the Chinese Government - if tor can get around them still... Well, I'll just say good luck :) – Michael B Sep 6 '16 at 19:30
  • 14
    Is it possible for a user to copy-and-paste patient personally identifiable information into a webform hosted on an external server? Then why are you worrying about complicated methods of accessing external resources? – Eric Towers Sep 7 '16 at 0:06
  • 1
    Tor still requires software on the client computer, does it not! Your corporate computers don't contain enterprise-spyware that lets the admin run automated remote scans? – Damon Sep 8 '16 at 10:29
81

You can use a list of Tor (uplink) nodes, add this to the outgoing firewall, setup a task to update this once a day and you'll be good. But Tor can also be used over a HTTP(S) proxy, so you will have to detect proxies as well.

I am not sure if this is going to help you secure anything. As long as there is a connection to the internet, it would be possible to bypass these kind of security measures. You could end up spending endless time and energy to prohibit all kinds of proxies, VPN's, SSL tunnels and such. The advice is to just make sure they cannot do any harm by protecting whats important to your business, and leave users be. For example separate the network in compartments, use subnets, VLANs, DMZs and require authentication and authorization on private networks. Keep the important stuff in one zone, while allowing networking without restrictions on another. And so on...

  • 40
    @mgjk So does a site-2-site VPN, which can be run over 443. Just blocking things because you fear them doesn't solve the underlying problem. – Yorick de Wid Sep 5 '16 at 13:58
  • 6
    If an employee went to those lengths to expose the internal network, it's the difference between me calling their manager, or involving the police. – mgjk Sep 5 '16 at 14:09
  • 10
    @mgjk This will become a holy crusade, Tor has many forks which all work different with their own internal networks and uplinks, and Tor is certainly not the only anonymous network, what about i2p for example? – Yorick de Wid Sep 5 '16 at 14:16
  • 23
    Tor has bridges, which are relays that don't advertise as being on the Tor network, and thus might not show up on the list that you have. They exist precisely for this reason: to allow people to access Tor from locations where Tor is blocked. – dave Sep 6 '16 at 0:26
  • 5
    @dave +1... furthermore if the user has set the connection to use a pluggable transport layer so that requests are relayed through popular sites such as Microsoft or Amazon. See trac.torproject.org/projects/tor/wiki/doc/meek – Celeritas Sep 6 '16 at 5:15
53

I believe your major concern should be that:

using anonymous proxy in the network

Is a bad assumption. I would straight away ask:

In which network?

Yorick already touched this point but I'll be more blatant.

HIPAA is mostly about privacy of the data in your production system and therefore in the network that is used to connect to the production system. You should have the control of what all machines connecting to this network can do. In other words, these should be company machines managed by the company, and provide the software that is needed to deal with the production system. No other machines should connect to this network, this includes VPN to the production network (which should be best avoided if possible).

A network for your employees that do not connect to the production system, e.g. a development network or office wifi shall be separate from the production network. You only need to explicitly show that the networks are separate (preferably with separate hardware, 802.1Q VLANs are subjects to a couple of attacks if badly configured). The machines in these networks are of no concern for the production system as long as they never connect to it (they should not!). Moving anything into production shall anyway have a QA/QC procedure in which the security of the code/configuration/another change is evaluated.

It is worth noting that the development network containing the development machines shall never see any production data. If your production data is to be safeguarded (e.g. for patient privacy as in HIPAA) you must anonymise all data in development/test setups. Having a secured production environment and then dumping production data into an unsecured network would be just silly.

  • 5
    I knew someone was going to make the remark about VLANs ^^ – Yorick de Wid Sep 5 '16 at 13:39
  • 1
    @YorickdeWid We all hate VLANs, don't we? :) Ethernet just can't be fixed. – grochmal Sep 5 '16 at 13:49
  • 1
    Except for that one network admin who tries to do half-duplex by splitting the cable :P. Anyway, good point nonetheless. – Yorick de Wid Sep 5 '16 at 13:56
  • 4
    On your last point, I imagine that no data should be moved back from production into those environments as well. (Moving production dumps back into a development/testing environment isn't uncommon, after all. In some ways, it can be considered a good practice.) Maybe that's worth adding? I dunno. – jpmc26 Sep 6 '16 at 16:46
  • 1
    @jpmc26 - Very good point, I've updated the answer. – grochmal Sep 7 '16 at 1:15
13

The only way you can be relatively sure Tor is not in use on the network is to inspect every device on the network and ensure that Tor is not installed or running on any of them. This could require so many man-hours that it may as well be impossible. And you might miss it anyway.

You can attempt to detect the use of Tor by watching for traffic to any of the hardcoded directory authorities, to which all Tor clients will always connect (with an exception, see below). There are usually less than a dozen of these.

You could also attempt to detect traffic to any of the thousands of guard nodes, but that may put a lot of strain on your IDS. Detecting directory authority traffic requires watching for only a few IPs and there will be traffic to these authorities even for otherwise idle clients.

The big exception is when Tor has been configured to use a bridge. These are explicitly designed so that Tor does not communicate directly with any of the normal Tor nodes or directory authorities. Instead they communicate with an unpublished bridge address. Nation states have difficulty detecting these connections; if one is in use on your network, you have pretty much no chance.


What you should be doing instead is more carefully controlling access to and from the network in general. Only traffic which is actually needed should be allowed to and from any device where PHI may be accessed or stored. This means you need to default-deny in both directions, incoming and outgoing, also segregating networks where PHI is present from other networks. It sounds like your current firewall egress policy is default-allow, and blocking things in a default-allow configuration is like punching holes in the sky.

7

Preventing the user from installing/using software that has not been approved by the company, by enforcing software policies on employees machine will suffice, combined to network authentication such as only those policy-compliant machines can access the network. This makes the workstation nearly a simple kiosk machine. In finance and healthcare industry, it should not be considered inappropriate to enforce a kiosk mode to operational employees.

The inability to run a software that may connect to Tor is the key to prevent users from using Tor, if browser (e.g. onion.to proxying) is not part of the threat. But normally you would have a whitelisted list of sites available in protected environments.

This, in the real world, often collides with the needs of IT staff. In most companies, the ability for the IT, who are not necessarily software developers/engineers, to run any software or to write custom scripts is a requirement. For sake of discussion, let's assume that is the case.

Of course you cannot prevent your sysadmin to run Tor and you can't also lock his machine down to a kiosk for just that "threat", otherwise you will prevent extraordinary out-of-process activities such as fixing problems with machines or network. In this case, I would recommend to employ a policy such as the sysadmin machines with privileged software configuration are normally connected to a non-sensitive network, and eventually Internet. If a sysadmin needs to access the sensitive network where protected information is stored, then he/she shall phisically connect his/her laptop to a different plug, and record the event into an audit trail. Such audit may also be accomplished by a comment on a support ticket "I am gaining access to machine 10.100.200.10 in order to complete the task".

In short words, preventing anyone from using Tor is a strict requirement that is difficult to enforce, however a reasonable reinterpretation of the requirement should satisfy any regulator by adopting the security principle that users must be able to run only the least minimum set of software programs to accomplish their duties (a variation of the least minimum privileges principle).

And anyway Tor itself is not a threat, it is a medium that can either be abused by insider traders or other unfaithful employees or pose a risk to existing untrained employees.

  • 1
    This ^ is the correct solution ... fighting it from a network level is going to be a fruitless endeavor ... setup a group policy to prevent tor from being installed or tor portable from being executed. – CaffeineAddiction Sep 7 '16 at 17:05
  • That assumes that both your OS and every application you've approved cannot be hacked to run unapproved instructions. You don't even have a chance at getting this to work, unless you're willing to lock down employee machines to the point where they run like a hardened Internet kiosk (a minimal web browser on a stripped down Linux OS and nothing else, with all hardware sealed inside a box). You'd be hurting employee productivity and still have the risk that something could be exploited. – slang Sep 10 '16 at 23:37
  • 1
    What about banks? Should they surrender to the fact that someone could use Tor to leak their private data? Of course every system is capable of being hacked, but a sysadmin shouldn't surrender. We are just talking about some compliance requirements, not that we approve or disapprove Tor itself (I approve and support it), but we have to understand that some tools should not be used, especially by people without proper experience and knowledge, in critical workplaces. – usr-local-ΕΨΗΕΛΩΝ Sep 12 '16 at 7:23
  • This is indeed the correct answer for any regulated industry and for most everyone else as well. It provides a very high level of assurance and is extremely common in both health and finance. It is also a very powerful method of reducing the attack capabilities of malware. – Julian Knight Sep 12 '16 at 8:36
  • 2
    I want to thank @slang for using the internet kiosk expression. That is the answer in most protected environments. And it shouldn't be considered evil against employees productivity. Operational employees (e.g. bank cashiers) should only use a minimum and efficient set of products in order to accomplish their tasks. If they, for their normal operations, require 35+ softwares (like in MPS bank a few years ago) I think their productivity is highly impacted by the number of tools they need to learn. Even if you should not perform non-business tasks during biz hours, there are tablets for those – usr-local-ΕΨΗΕΛΩΝ Sep 21 '16 at 10:00
5

Tor is by-design difficult to block. Yorick's measures will keep the honest employees honest. I would go that route unless HIPAA demands more* Adding detection to the blocking measures means you can identify Tor users and go through management to discipline them. IMHO, forbidding this kind of behaviour should be in the employee's annual certification of business policies and part of your security training program.

If you must rule with an iron fist, blocking everything by default and installing an interception proxy is a common method. This means you will be intercepting, decrypting, inspecting, categorizing and re-encrypting all client TLS traffic. This is common in banks and secure institutions... along with all the privacy implications, deployment complexity and performance issues.

*(I don't know... I haven't done HIPAA)

  • 5
    As soon as you allow BYOD, all bets are off (which may not be the case in this topic). Packet analysis on TLS traffic sounds nice in theory but have severe consequences in practice. – Yorick de Wid Sep 5 '16 at 14:21
  • 1
    Like that's going to work on a tablet, or phone. – Yorick de Wid Sep 5 '16 at 15:57
  • 6
    I have not done HIPPA (I'm not in the US) but I need to argue that that is a health policy. Therefore it is a patient data privacy thing. If you allow patient data to be downloaded onto a personal machine of an employee (which can then be stolen) you're already liable for that. I'd argue that BYOD is out of question. – grochmal Sep 5 '16 at 16:08
  • 1
    @YorickdeWid - MDM == "Mobile Device Management." Unless you're a very, very small shop, if you use mobile devices, you need some kind of solution to enforce encryption, access control, and remote wipe. For BYOD, you have the requirement in the acceptable use policy (AUP) and deal with the fact that personal data will get wiped along with the corporate data on exit (and that their pictures of their kids will get backed up to the corporate servers... ). Many MDM solutions let you add certificates to the device certificate store, which is why I mention it. – mgjk Sep 5 '16 at 16:45
  • 2
    @Erbureth - because in environments that have users accessing personal information while not necessarily at assigned desks, smartphones or tablets are probably the best bet for an appropriate terminal to allow those users to get that access. – Periata Breatta Sep 6 '16 at 3:34
2

Since the title refers to detecting such activity I would configure a firewall rule to log but not block connections to known anonymisation services/servers of various types. Obviously this does mean having someone monitoring the firewall logs or some type of flagging system.

There is a slight risk that data may get out but if someone encounters a block they're likely to find other methods/services (which you may not have logging in place for) to get data out of your system.

Allowing a limited amount of data egress gives you targets within your network that allow you to audit their systems access and find out what they're actually doing - such as attempting to access material that's outside of their job scope.

This also gets you around any BYOD issues in environments which permit them as to get to the sensitive data they'd still need their authentication (logins etc.) so you can see what might be at risk.

The downside of this approach is that risks are proportional to how closely the firewalls are being monitored and any flags acted upon so it really depends on the resources available.

  • 3
    Once you allow Internet access, even with just port 80, there will ALWAYS be ways to exfiltrate data unless to block access to ALL endpoints except limited known ones and that is infeasible. The way to prevent it is to only allow corporately managed devices to access HIPAA related data and for those devices to be prevented from running code unless whitelisted. This is a very common and very secure practice. – Julian Knight Sep 12 '16 at 8:41
  • 1
    Permitted applications can be manipulated to get data out too and even DNS can be used to relay data so connections don't even need to be direct, but discussion of all those avenues take us outside the scope of the question that was asked. To which the answer is arguably not block, but capture and neutralise the threat from your organisation. – James Snell Sep 12 '16 at 10:11

protected by Community Sep 7 '16 at 15:40

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.