How do I connect Tor Exit List to Lodol?

Connect Tor Exit List once in your workspace and every action and trigger it supports can be added to a workflow, by you in the editor or by your AI.

All integrationsSecurity

Tor Exit List

Tell whether an IP address is a Tor exit node, using the list the Tor Project itself publishes and rebuilds about every half hour.

Start Free Browse all integrations

actions: 8

Actions

Steps a workflow can run in Tor Exit List.

Check an IP addressCheck whether one IP address is a Tor exit node, and get the answer in a sentence you can put straight into a ticket. A match comes back with the relays running at the address and when traffic was last confirmed leaving them; several relays commonly share one machine. Use the public address the visitor connected from (behind a proxy or CDN that is the forwarded address), and a private address in the result is the sign the wrong one was checked.
Check several IP addressesCheck up to 1,000 addresses at once: a day of sign-ups, the senders behind a spike of failed logins, or a list pulled from a log. Every address is answered individually, duplicates are collapsed, and anything that is not an IP address is reported rather than failing the step. The result also carries just the Tor addresses as a flat list and a single true or false for 'was any of this Tor', so a workflow can branch without counting.
List exit IP addressesGet the current exit addresses, in numeric order and nothing else attached. This is the blocklist feed: run it on a schedule to keep a firewall rule or a WAF list in step with the network. Narrow it to one address or one CIDR range to ask whether any exit runs inside a range you care about.
List exit relaysList the relays themselves rather than just their addresses: the fingerprint that identifies each one, every address it exits from, and when it was last confirmed. Filter to a range, or to the relays confirmed since a moment you give, so a scheduled run sees only what has appeared since the last one.
Get an exit relayLook up one relay by its fingerprint and get every address it exits from, when it published its descriptor, when it was last confirmed, and a link to its page on Tor Metrics. A fingerprint that has dropped off the current list is reported as such, with a link to its history, rather than coming back empty.
List exits that can reach your serviceEvery Tor relay publishes which destinations it will carry traffic to, and most will not carry all of it. Give your service's public address and port and get only the exits actually allowed to reach it, with what share of the network that is. Most exits allow web traffic and only a few allow mail, so blocking on port 25 is a far smaller job than blocking Tor outright.
Export the exit listWrite the current addresses out as text to put somewhere else: a plain list of one address per line for pasting into a firewall or deny list, or a spreadsheet with the relay count, the last confirmation time and the fingerprints behind each address. Narrow it to a range first if you only care about part of the network.
Get exit list detailsSee the shape of the network and how fresh the data is: how many relays and how many addresses, how many addresses have more than one relay behind them, which kinds of address the list covers, and when the Tor Project last rebuilt it. Also the one-step check that the connection works.

About Tor Exit List

Check one address at the moment someone signs up, logs in or places an order, or check a whole day of addresses out of your logs in a single step. Pull the current addresses to keep a firewall rule, a WAF list or a risk table in step with the network, look up the relays behind an address when you need to explain a decision, and ask which exits are even allowed to reach your service before you decide to block anything: on most ports that is a far smaller list than every exit there is.

Setup is a single click: the list is public, so there is no account, no API key and nothing to configure. Two things that quietly produce wrong answers elsewhere are handled here rather than passed on. The list covers IPv4, so an IPv6 address is refused with that explanation instead of being told it is not Tor; and a private address such as 10.0.0.5 is flagged, because seeing one almost always means a proxy's own address was checked rather than the visitor's.

Every result carries the timestamp the list was rebuilt, and a link to ExoneraTor (the Tor Project's own page for confirming whether an address was running a relay on a given day) which is the link to put in the ticket when someone disputes a block.