Roger Dingledine wrote:
Btw, all of these UbuntuCore relays are from snap packages run by Tor enthusiasts
Do you indeed mean "all"? Since there have also been other hypothesis about at least some of these "UbuntuCore" relays in the past (see bad-relays ML archive from 2017-11-13), it would be great if you could elaborate on how you came to that conclusion.
thanks, nusenu
On Sat, Nov 24, 2018 at 11:32:00PM +0000, nusenu wrote:
Roger Dingledine wrote:
Btw, all of these UbuntuCore relays are from snap packages run by Tor enthusiasts
Do you indeed mean "all"? Since there have also been other hypothesis about at least some of these "UbuntuCore" relays in the past (see bad-relays ML archive from 2017-11-13), it would be great if you could elaborate on how you came to that conclusion.
All I've got is Chad's original mail: https://lists.torproject.org/pipermail/tor-relays/2016-August/010046.html where he describes his snap.
--Roger
If someone is spoofing them, then I reckon they are doing a good job updating them to match the (ever-increasing) revision number, now at 249-252.
Downloads are anonymous, but the dashboard I have says it should be about 6000 nodes wishing to join (though failed connectivity might remove some) and metrics.torproject.org says "at least 2000".
If someone has an idea for a veracity experiment, contact me.
On Sat, Nov 24, 2018 at 3:32 PM nusenu nusenu-lists@riseup.net wrote:
Roger Dingledine wrote:
Btw, all of these UbuntuCore relays are from snap packages run by Tor enthusiasts
Do you indeed mean "all"? Since there have also been other hypothesis about at least some of these "UbuntuCore" relays in the past (see bad-relays ML archive from 2017-11-13), it would be great if you could elaborate on how you came to that conclusion.
thanks, nusenu
-- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Chad MILLER:
If someone is spoofing them, then I reckon they are doing a good job updating them to match the (ever-increasing) revision number, now at 249-252.
I don't think anyone is "spoofing" the nickname behavior of your snap. I think these are actual running snap installations.
Downloads are anonymous, but the dashboard I have says it should be about 6000 nodes wishing to join
these are scary high numbers and the fact that no operator appears to be asking why any of these >5600 failing installations do not come online is making this even more odd-looking to me.
are these actual 6000 unique deployments? how are they counted? are endpoints submitting a unique ID to the update endpoint for the counter to work? (or are these counters just based on counting unique source IPs hitting the update endpoint? [within a day?]) do you have AS or country break downs for that number?
(though failed connectivity might remove some) and metrics.torproject.org says "at least 2000".
There are currently[1] 359 running relays with a nickname starting with "UbuntuCore" (that is more than 0.5% of the tor network's consensus weight fraction). That would be the 10th biggest tor relay operator if it were a single operator.
If someone has an idea for a veracity experiment, contact me.
What would you like to verify with an experiment?
We were in contact about this before, but maybe you could add a simple check for the existence of a file where the operator needs to add the ContactInfo and if it is not there the snap exits + adding that new requirement prominently to the snap documentation.
Then we can observe how many - disappear? - get a ContactInfo? - get the same ContactInfo? - get a random ContactInfo? - get an actual working ContactInfo?
[1] onionoo data from 2018-11-24 23:00 UTC [2] https://medium.com/@nusenu/is-this-a-ubuntu-based-botnet-deploying-tor-relay...
On Sat, Nov 24, 2018 at 5:10 PM nusenu nusenu-lists@riseup.net wrote:
Chad MILLER:
Downloads are anonymous, but the dashboard I have says it should be about 6000 nodes wishing to join
these are scary high numbers and the fact that no operator appears to be asking why any of these >5600 failing installations do not come online is making this even more odd-looking to me.
I have assumed that 95% of users don't have public addresses or have port forwarding. It's a connectivity problem, I think.
are these actual 6000 unique deployments? how are they counted?
are endpoints submitting a unique ID to the update endpoint for the counter to work? (or are these counters just based on counting unique source IPs hitting the update endpoint? [within a day?]) do you have AS or country break downs for that number?
I think it's a count of update checks within a normal update-check window.
I DO have country information. Attached. (I removed the countries with fewer than 3 in case that could be used to identify them.) Countries greater than 100 are 613 Germany 539 France 530 United States 455 Russian Federation 373 Brazil 332 Italy 315 India 288 Spain 217 Iran, Islamic Republic of 172 United Kingdom 140 Mexico 131 Ukraine 125 Poland 119 Canada
Chad MILLER:> I have assumed that 95% of users don't have public addresses or have port
forwarding. It's a connectivity problem, I think.
Yes, understood. And >5k deployments without anyone(?) asking about why it does not work is the crucial part that makes it odd (makes it look like bots).
are these actual 6000 unique deployments? how are they counted?
are endpoints submitting a unique ID to the update endpoint for the counter to work? (or are these counters just based on counting unique source IPs hitting the update endpoint? [within a day?]) do you have AS or country break downs for that number?
I think it's a count of update checks within a normal update-check window.
do you have the possibility to find out? (via authoritative documentation?) It would be great to have some affirmative data.
any comment about this?
maybe you could add a simple check for the existence of a file where the operator needs to add the ContactInfo and if it is not there the snap exits + adding that new requirement prominently to the snap documentation.
Then we can observe how many
- disappear?
- get a ContactInfo?
- get the same ContactInfo?
- get a random ContactInfo?
- get an actual working ContactInfo?
I DO have country information. Attached. (I removed the countries with fewer than 3 in case that could be used to identify them.)
thanks for providing this data, interesting to see that there are even instances in China trying to come online.
Do you have any other additional stats like hw architecture? or even hw arch per country?
tor-relays@lists.torproject.org