Hello everyone,
I would like to propose that IPs of pool-members should not be allowed to host security-relevant services simultaneously under the same IP.
For example 185.248.141.34 is also hosting a Tor Exit Node which triggers automated blocks on firewalls, IPS-devices etc. making the pool difficult to use as this might cause NTP problems.
A blacklist API of a service like Abuse IPDB or Criminal IP could be used to check IPs on registration and periodically afterwards.
Kind regards
No. Flat out, no. Such databases are far from accurate. Who is the ISP to make such judgements by arbitrarily blocking addresses? Just, no.
Even then, the redundancy recommendations and the algorithm of NTP clients will sift out such addresses automatically.
By using the pool, you’re trusting random volunteers to tell you the time. Most of the servers are presumably only serving time to the pool on the side; it’s not their primary purpose.
Personally, I have two servers in the pool. One is hosting a couple websites that nobody ever visits, and the other holds my email.
What other services the volunteers are running on their servers isn’t really anyone’s concern, I figure, so long as they serve time reliably.
If it is of concern to you, I suggest you consider trustworthy alternatives, such as Google’s or Cloudflare’s NTP servers.
@jappi, welcome to the community! 
Tor is good thing, noone should think about blocking its exit IP addresses.
I concur. Many consider Tor a legitimate and useful service, despite its abuse potential. I think it would be inappropriate for the Pool to police and censor who gets into the Pool, or even the Internet itself (through the chilling effect of not being able to run an NTP Pool server while also running a Tor exit node), on behalf of those who disagree.
Also, Tor and NTP are two entirely different things technically. The Pool is concerned with good timekeeping, and has mechanisms in place to exclude servers that do not keep good time, or are unreachable. A host also running a Tor exit node does not inherently provide more or less good time than any other random server in the Pool that a user implicitly trusts to get time from. When a server is in the Pool, it means it has passed the same timekeeping quality criteria as any other server in the Pool. What the Pool can assess is obviously limited, thus as has been pointed out above, it is the responsibility of the client, or its user, to assess whether time received is sensible, and meets one’s criteria, or not.
If people think they need to block NTP from a host just because the host is also running a Tor exit node, and create products that do, or use such products, I don’t think it is the Pool’s job to fix the issues arising from not being able, or not wanting to distinguish the two things. And people should consider whether the Pool is the right thing for them at all, whether they should trust any random anonymous host in the Pool. Or perhaps rather use “known” and trusted (to the extent possible/desired) servers instead (reinforcing what has been mentioned before).
Once upon a time, I ran a Tor relay node. I didn’t have the bandwidth to host an exit node. Regardless, that was enough for my address to end up in one of those lists as a Tor exit node. Netflix even blocked my address as a proxy’s. That’s how such bogus lists are compiled and used.
I would like to propose that operators of firewall software learn how to use it and not expect the volunteers of other projects such as the NTP Pool to save them from their lack of familiarity with their own firewall.
If your firewall complains at you when you try to talk to an IP that hosts a Tor exit node, learn how to turn off that functionality.
If you aren’t able to turn off that functionality because there is no way to turn off that functionality, complain to your vendor about their lack of features.
If you aren’t able to turn off that functionality because your organisation’s policy is to not talk to IPs that are also Tor exit nodes, do your job and block Tor exit nodes in your firewall. The IP addresses of all of them are publicly listed and constantly updated. Figure out how to use a computer to get that list and pre-emptively add blocks. You will never again send a packet there and your firewalls will not complain at you.
Your use of the NTP pool will continue to be fine since it’s unlikely that every IP handed to you will be a Tor exit node.
It’s not anyone else’s job to rate and judge IP addresses by their taste and reputation. If you want to do it, you have to do it yourself.
There’s no question that Tor exit nodes, while having their merits, are also a source of plenty of malicious activity.
That said, blacklisting Tor exit node IPs and preventing them from participating in the pool is probably not the right way forward.
A partial solution might be to finally fix the pool documentation and recommend using the pool directive instead of the server directive. That way, blocked and unresponsive IP addresses are discarded much more quickly.
Do you have more details on what malicious activity at the IP/TCP or application level emanates from Tor exit nodes, e.g., how other hosts are being attacked from Tor exit nodes at those levels, and through the Tor network?
I know that Tor is used for shady, or even criminal activities, but Tor is mostly the communication medium that is used due to its privacy and confidentially. Nothing that blocking an IP address would solve.
Also, Tor can be used to circumvent geo-blocking, and it may prevent a service owner from knowing the IP address of a service user/requestor. Thus companies like MaxMind are in the business of detecting Tor nodes, just as they try to detect other VPNs, and sell that information to interested parties. If an interested party wants to preclude users of Tor, or other VPNs, from using their services, they can obviously block traffic at the IP level. But so far, it seemed more common to me that service would be refused at the application level, e.g., access to web site content denied.
Other than that, I was not aware that Tor exit nodes would be used for IP/TCP level attacks (because that is what would require an address-based traffic block, rather than an application-level “refusal of service”) through the Tor network any more than other hosts, e.g., that are part of a bot-net.
Unfortunately, search engines so far only spat out infos on how Tor itself is being attacked (e.g., de-anonymisation), but I’ve not yet had the patience to work around them trying to outsmart me, and get them to answer the actual question I had, how Tor is used to execute attacks on the IP/TCP level. So any pointers would be appreciated. Thanks!
It’s indeed important to distinguish between abuse originating through Tor exit nodes at the application level - which happens a lot, and Tor exit nodes being the source of malicious activity at a lower network level, something that it theoretically possible, but less common.
Take for example this or this. At first glance mainly application level attacks.
That said, quite a few organizations ignore this nuance and still treat Tor exit nodes as a legitimate reason for preventive IP-level blocking. And when such blocks are in place, any other service running on the same IP (for instance an NTP pool server) will be blocked as well.
To be clear, I’m not advocating for that approach - I’m merely observing it.
It’s possible, but that is not even the point. Companies block them completely nevertheless, whether that makes sense or not.
The question (and @jappi’s proposal) was essentially: “Given this reality, should we allow NTP pool servers to operate on such IP addresses?”
In my view we should, though I do understand the concern that motivated the question. Hence my suggestion of using the pool directive rather than the server directive as an alternative that could at least partially solve the problem.
I do not agree.
As people use it to abuse things like forums and chatboxes.
Just like they abuse VPN’s for that.
I block them by default at my systems.
TOR as well as VPN have no ways to block abusers, nor do they respond on abuse messages.
I had my share of abusers of those systems. No thanks, I block them.
I think the issue your described is valid. However, I do not think that it is specific to the tor exit nodes. There are zombie systems, even systems on the AWS that show mailicous activites. By my opinion blocking all the IP addresses of the torexit nodes straight is like dropping the baby with the bathwater.
There is no other way, because TOR uses a different exit all the time. As soon as a TOR-user gives a new request, the exit is different. You simply can’t keep up other them blocking them all.
They have many thousants of exit-IP’s, good luck keeping abuse out of your system.
From what I’ve observed, it will reuse the same exit node for the same site in the same session, though the user can request a new circuit which also changes the exit node. But I guess your point is, they’re not tied any one exit node, which is true.
Not that it particularly matters to the pool itself, since Tor doesn’t carry NTP traffic. For other services, it will suffice to block incoming TCP traffic from Tor exit nodes if you don’t want Tor traffic.
Depends on what the (ab)user wants, you can set it to rotate constantly.
Typical when it’s used for abuse it’s set to rotate but does allow cookies, so e.g. it keeps you logged into a forum and start spamming etc.
For an admin it’s then impossible to block that user as the IP changes with every request.
I have ran forums for years, big ones with millions of users, TOR has always been a big problem. No other way then block it in total.
In fact, TOR offers an exit-database that is updated all the time, you can use it to block them.
I do believe in the good intensions of TOR, sadly it’s abused all the time.
You’ve just contradicted yourself – another way to block an abuser is based on their login, which the cookie is enabling across sessions.
You can use cookies but you can also block them via TOR.
You have various options to abuse TOR.
If they use cookies, yes you can block them on cookie, l but then they change it to non-cookie etc.
You can not stop abuse via TOR.
If you block cookie then they simply register a new account with a new email-account and you keep bussy chasing them.
I have a websdr with a chatbox that requires no registration, without blocking TOR and VPN the only option is to shutdown the chatbox.
Good luck chasing them….I won’t.