VPN and Tor IP data

as a subscription to one of the commercial blocking lists is required

• Project Honey Pot’s Directory of Malicious IPs: Registration required to view more than 25 IPs
• FireHOL IP Lists: Combines several blocklists from other sources

• StrictBlockPAllebone URL Table (IPs): based on StrictBlockPAllebone manually curated IP Blocklist. 

• IPsum : based on 30+ different publicly available lists of suspicious and/or malicious IP addresses 
• Malc0de List: identified distributing malware during the past 30 days IP Blacklist 

The list of Tor exit node IP addresses is actively maintained by the Tor Project’s Exit List Service, which offers both real-time query and bulk download interfaces (see https://blog.torproject.org/changes-tor-exit-list-service). Organizations preferring bulk download may consider automated data ingest solutions, given the highly dynamic nature of the Tor exit list, which is updated hourly. Network defenders should closely inspect evidence of substantial transactions with Tor exit nodes—revealed in netflow, packet capture (PCAP), and web server logs—to infer the context of the activity and to discern any malicious behavior that could represent reconnaissance, exploitation, C2, or data exfiltration.

Using a behavior-based approach, network defenders can uncover suspicious Tor activity by searching for the operational patterns of Tor client software and protocols. Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports commonly affiliated with Tor include 9001, 9030, 9040, 9050, 9051, and 9150. Highly structured Domain Name Service (DNS) queries for domain names ending with the suffix torproject.org is another behavior exhibited by hosts running Tor software. In addition, DNS queries for domains ending in .onion is a behavior exhibited by misconfigured Tor clients, which may be attempting to beacon to malicious Tor hidden services.

Most restrictive approach: Block all web traffic to and from public Tor entry and exit nodes. Organizations that wish to take a conservative or less resource-intensive approach to reduce the risk posed by threat actors’ use of Tor should implement tools that restrict all traffic—malicious and legitimate—to and from Tor entry and exit nodes. Of note, blocking known Tor nodes does not completely eliminate the threat of malicious actors using Tor for anonymity, as additional Tor network access points, or bridges, are not all listed publicly.  

Less restrictive approach: Tailor monitoring, analysis, and blocking of web traffic to and from public Tor entry and exit nodes. There are instances in which legitimate users may leverage Tor for internet browsing and other non-malicious purposes. For example, deployed military or other overseas voters may use Tor as part of the voting process to escape monitoring by foreign governments. Such users may use Tor when visiting elections-related websites, to check voter registration status, or to mark and then cast absentee ballots via email or web portal. Similarly, some users may use Tor to avoid tracking by advertisers when browsing the internet. Organizations that do not wish to block legitimate traffic to/from Tor entry/exit nodes should consider adopting practices that allow for network monitoring and traffic analysis for traffic from those nodes, and then consider appropriate blocking. This approach can be resource intensive but will allow greater flexibility and adaptation of defensive.

Blended approach: Block all Tor traffic to some resources, allow and monitor for others. Given the various licit and illicit uses of Tor, a blended approach may be an appropriate risk mitigation strategy for some organizations (i.e., intentionally allowing traffic to/from Tor only for specific websites and services where legitimate use may be expected and blocking all Tor traffic to/from non-excepted processes/services). This may require continuous re-evaluation as an entity considers its own risk tolerance associated with different applications. The level of effort to implement this approach is high.