Tor (The Onion Router) is an internet communication network built on privacy and anonymity. Much of the attention that Tor receives comes from the malicious segment of users that leverage the Tor network to conduct attacks while concealing their location. This negative association and challenge in attribution have led most organizations to block traffic coming from the Tor network.
Proofpoint Emerging Threats has many security feeds and intrusion detection system (IDS) signatures that help defenders detect cyber threats. We will be utilizing the Tor IDS alert rules provided by Emerging Threats (ET) for this blog post.
The ET Tor rules detect ingress source address anonymization using Tor exit nodes. However, what if you want to know if potentially compromised hosts on your network communicate outbound to a Tor relay?
There are several ways to solve this problem using the ET Tor rules. We will only cover one solution.
The text below is an excerpt of the ET Tor rules before modification:
alert tcp [184.108.40.206,220.127.116.11,18.104.22.168,22.214.171.124,126.96.36.199,188.8.131.52,184.108.40.206,220.127.116.11,18.104.22.168,22.214.171.124] any -> $HOME_NET any (msg:"ET TOR Known Tor Exit Node Traffic group 1"; reference:url,doc.emergingthreats.net/bin/view/Main/TorRules; threshold: type limit, track by_src, seconds 60, count 1; classtype:misc-attack; flowbits:set,ET.TorIP; sid:2520000; rev:4293; metadata:affected_product Any, attack_target Any, deployment Perimeter, tag TOR, signature_severity Audit, created_at 2008_12_01, updated_at 2020_12_28;)
The source and destination in the Suricata rule above are the portions that we need to swap globally. We also need to ensure that our $HOME_NET is configured correctly and represents our actual local network subnet(s).
The following steps will create an inverse version of the ET Tor rules we can use in our detection software.
Step one: Download the rules
wget -qN https://rules.emergingthreats.net/open/suricata-5.0/rules/tor.rules
Step two: use sed and regular expression substitution to swap the relevant bits around
sed -E s'/(\[.*\])([^\$]+)(\$HOME_NET)/\3\2\1/gm' < tor.rules > tor-inverse.rules
The same rule we saw earlier now looks like the following:
alert tcp $HOME_NET any -> [126.96.36.199,188.8.131.52,184.108.40.206,220.127.116.11,18.104.22.168,22.214.171.124,126.96.36.199,188.8.131.52,184.108.40.206,220.127.116.11] any (msg:"ET TOR Known Tor Exit Node Traffic group 1"; reference:url,doc.emergingthreats.net/bin/view/Main/TorRules; threshold: type limit, track by_src, seconds 60, count 1; classtype:misc-attack; flowbits:set,ET.TorIP; sid:2520000; rev:4293; metadata:affected_product Any, attack_target Any, deployment Perimeter, tag TOR, signature_severity Audit, created_at 2008_12_01, updated_at 2020_12_28;)
Notice the $HOME_NET variable is now the source. When the conversion is complete, place the file where appropriate for your IDS.
The ET rules are updated regularly. We recommend that you automate the conversion if you need to adapt this or any other signature for your environment.
Thanks for reading.
2 thoughts on “Detecting Tor communication”
I thought those were only exit nodes. How come this is not included with ET rules?
Hello, the ET rules do include the tor exit nodes.
However, the ET rules only consider traffic coming from a tor exit node to a system in your $HOME_NET. If you manage a network where tor isn’t filtered, the default rules could be sufficient. However, suppose the traffic originates from your network outbound to a tor exit node and is filtered. In that case, you may never see the default ET rule fire. That specific use case provides information on hosts that may need to be investigated. I hope that helps.