Re: [tor-relays] Receiving abuse reports for Non-Exit Relay

[mpan]

In the past 24 hrs, I have been receiving complaints from my hosting provider 
that they're receiving hundreds of abuse reports related to port scanning. I 
have no clue why I'm all of the sudden receiving abuse reports when this 
non-exit relay has been online for months without issues. In addition, I have 
other non-exit relays hosted by the same provider with no issues and more 
across other providers.

I proceeded to reinstall the OS and reconfigure Tor.  I was then quickly 
notified by my hosting provider again of more abuse reports all showing port 22 
as target port.

I have not changed my torrc at all and it's still setup as a non-exit relay. No 
other applications/services were installed alongside Tor. Tor Metrics does not 
show the relay as Exit either.

It feels like Tor Exit Traffic is leaking through my non-exit relay?

Hello,

  To me it seems like bogus or invalid reports. With certainity over 19 
in 20. The picture simply does not fit port scanning.


 1. Not only middle relays, but exit nodes can only perform complete 
TCP connections. Port scanning usually involves a SYN or UDP scan, which 
is technically not possible to be done using any Tor node.


 2. Even if we assume somebody is hurting oneself by performing a 
full-connection TCP scan, you mention only one port is being reported. A 
port scan involves many ports. And this is not merely pedanticism 
regarding naming. The detection of a port scan relies on this. In other 
words: there is no way to classify traffic as a port scan, if only one 
port is affected.


  Since only port 22 is affected and 22 is not a common port for Tor 
relays, you may simply block egress traffic to this port altogether. The 
same as IP address ranges for which reports come. If the reports 
continue coming, you can be almost sure they are false. The little 
uncertainity remains for some attacker having root (or above-root) 
access to your machine, but this is not coming from your Tor relay.


  Before blocking IP address ranges, check if they are not relays. I do 
not want to make positive statements about one trying to affect Tor 
network, but such a possibility should also not be excluded without 
checking.


Cheers


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Way to be notified when relay goes offline?

[mpan]

Is there a way to be notified when a relay goes offline?

Hello,

  If your relay is running as a systemd service, you may add any action 
to ExecStopPost.⁽¹⁾ That includes sending an email or any other means of 
notification.


Cheers

⁽¹⁾ 
https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#ExecStopPost=


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor non-exit list

[mpan]

First of all, thank you for your tools and other contributions. The mere
fact that your DNS blocklists are used by countless vendors should be a
compliment in itself, and I'd be happy to have that much impact with my
own projects. (…)
  Operating a non-exit Tor relay I face similar issues. I can’t trace 
them back to this particular blocklist, but with high confidence can 
tell the challenges we face are from indiscriminately using blacklists. 
Some of them do contain Tor non-exit relays. So I can do nothing more 
than I support Carsten’s plea.


  Over years no party blocking non-exit relays was able to provide me 
with a single example of an actual incident, despite continued claims 
it’s a “malicious traffic from *my* address”. After changes on their end 
that “malicious traffic” was magically no longer observed.


  I myself can’t conceive any actual attack coming from a non-exit 
relay with probability notably higher than from other machines on the 
internet. The relay itself isn’t designed to connect to machines other 
than Tor relays, so certainly its intended use doesn’t lead to higher 
risk. All other factors and attacks should at worst be the same as for 
the general population.


Cheers and thanks for providing the lists, mpan.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor non-exit list

[mpan]

I agree, maybe this open letter is better aimed at the security vendors 
that include DAN's (non-exit) Tor relays list on a blocklist by default, 
or without warning about potential impact to other legitimate services 
(universities, libraries, shared hosting providers, hobbyist email, etc)
  Security vendors are not the only users of such lists. There is much 
more entities and people, that use them without any intermediaries. 
Negotiating with every single of them is not only whack-a-moling, but 
also inefficient compared to addressing the issue at the source.


  The issue could be approached in other ways too, but I don’t find 
them satisfying. It would require things like changing the license, 
which is an idea I can’t stand behind. It would also demand more effort 
from Dan, which is unacceptable given he’s offering that free of charge, 
and likely lead to employing practices I despise.


Once the malware runs it will phone home over Tor to the .onion, from a 
network perspective this will look like a TCP connection to an entry 
node. I can see many reasons to maintain a list on known entry nodes to 
prevent unauthorized applications or users from connection out of a 
network. Those lists should not be enabled by default to block.

  That’s a good point, but there are things to note.

  Tor entry nodes are publicly known. An organization, that believes 
they need such a protection, may obtain the list directly from Tor 
Project. This requires additional effort, yes. But it should require 
effort. It’s not big, compared to how much it takes to make such a 
decision in a responsible manner. And it protects against blindly using 
blocklists without thinking.


  This is the same reasoning that was driving Polish internet operator 
(TP) to blanket block servers suspected of running IRC. Not merely 
connections to IRC, which is questionable on its own, but servers: so 
one couldn’t e.g. access websites of many FOSS projects. In my college I 
had to sign additional papers to be able to access some Wikipedia 
articles. URLs could contain a particular word also found on porn sites, 
so the college seen this as a risk of students committing the crime of 
exposing other students to inappropriate content. We see mandating 
backdoors in encryption, which use the same logic: encryption helps 
committing crimes. Finally, something probably most close to any Tor 
user’s heart: a requirement to be fully tracked everywhere or otherwise 
treated as a second class citizen. Yes, that is also commonly 
rationalized by protection against attacks. So it’s worth asking, if 
this is acceptable reasoning.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] New relay on dynamic IP address

[mpan]

> Is a really with a dynamic IP address useful at all?
  I’m running a node like that for over 5 years. Currently it is a guard
too. The IP address is relatively stable and the major interruptions are
due to kernel/tor upgrades or modem losing connection without the
address change. Even after those it recovers pretty fast. Unless you are
expecting to see downtime a few times a week, go ahead. The node is also
useful even if it is not having the guard flag yet.

  However, if you’re planning to run a node from your home, consider a
few things. Forget about running an exit node: you will experience a
heavy overblocking and hostility. And any node will bring some level of
harassment, because ignorance is widespread. A second thing is that from
time to time someone is trying to DoS nodes. In those 5 years I’ve seen
a few of those, so I assume the average is like once per year of
operation. Just accept the inevitable reality of running a node at home:
there will be a day or a week in which you will observe thousands
connections coming to your PC, all cores suddenly running at 100%
without no apparent reason &c. Treat it as a way to gain experience.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] (Без темы)

[mpan]

> TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies.  
> Check 
> SNMP counters.
> what it can mean? also my 2 relays go offline for a few hours once a day, 
> then 
> are restored.
  The TCP protocol builds a new connection by the client sending a SYN
packet to the server, the server responding with a SYN+ACK packet and
then the client responding with an ACK packet:

  Client Server
 | |
 | -SYN--> |
 | |
 | <---SYN+ACK |
 | |
 | -ACK--> |
  {connection established}

The server must somehow keep track of the connections during that
handshake and the naïve way of doing that is having a queue that hold
information on them. The client must do the same, by the way.

  Now imagine that someone sends a ton of SYN packets to the server,
without ever having intention of making a connection and therefore not
keeping track of them. The poor server responds with SYN+ACKs and keeps
half-open connections in the queue in a hope that the client will send
the final ACK packet: but that one will never arrive. That may fill up
the queue quickly and if a normal client tries to connect, it can’t
because the queue is full. That kind of an DoS attack is based on
assymetry between the resources needed by the attacker and the victim:
the victim will dedicate its resources to half-open connections, while
the attacker just sends SYN packets without ever storing anything.

  Attacker   Server  queue
 | | [ ][ ][ ][ ][ ][ ]
 | -SYN--> | [x][ ][ ][ ][ ][ ]
 | <---SYN+ACK | [x][ ][ ][ ][ ][ ]
 | -SYN--> | [x][x][ ][ ][ ][ ]
 | <---SYN+ACK | [x][x][ ][ ][ ][ ]
 | -SYN--> | [x][x][x][ ][ ][ ]
 | <---SYN+ACK | [x][x][x][ ][ ][ ]
 | -SYN--> | [x][x][x][x][ ][ ]
 | <---SYN+ACK | [x][x][x][x][ ][ ]
 | -SYN--> | [x][x][x][x][x][ ]
 | <---SYN+ACK | [x][x][x][x][x][ ]
 | -SYN--> | [x][x][x][x][x][x] full
 | <---SYN+ACK | [x][x][x][x][x][x] full
 ' | .
   | .
 Honest client | .
 | | .
 | -SYN--> | [x][x][x][x][x][x] full
 :(   :(

  Here the story of “Possible SYN flooding on port 80” ends. That is
what a SYN flood is.

  A way to prevent that type of an attack is to not store information on
the server. Instead, the server uses the protocol in a creative way to
store the information in the SYN+ACK packet itself (in the sequence
number, as SYN cookies). A honest client must then respond with an ACK
packet that contains a predictably modified information, which can be
used to reconstruct the original one. Only then actual resources are
assigned to the connection. Of course an attacker may till simply open a
ton of connections, but this way there is a symmetry between resources
required by both sides. Yes, the server may have their resources
exhausted by the attacker, but the attacker must allocate as much
resources to the attack. That method, however, has its drawbacks and
therefore is applied only if an actual attack is suspected. That’s what
“Sending cookies” means.

  What causes your nodes to go down is harder to tell. If both events
are clearly correlated, something may be actually making a large number
of connections, overloarding the nodes and making them unavailable to
honest clients. That has happened in the past, with hundreds and
hundreds of simulaneaous connections suddenly appearing from a limited
range of addresses. SYN cookies will not prevent that in any way (it’s
not their job), but the SYN flood prevention mechanism firing may be a
sign that a ton of TCP connections are being established fast.

  You may try to debug that by collecting information on connections to
you node. E.g. by executing `ss` (possibly `netstat` on some systems)
periodically (for example each 15s) to count connections to the node
(and only them), counting them and logging that information over many
days, including some unwanted events you have described, and then see if
you see any correlation.

  BTW: using Latin script and English for the title will increase
chances of getting attention. Otherwise people may even simply filter
out your messages “visually”, assuming it’s spam. :)



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [NYX_NOTICE] Relay unresponsive -- how to troubleshoot?

[mpan]

> I keep getting NYX_NOTICEs about "Relay unresponsive". They happen every
> few hours, and last for minutes or sometimes a couple of hours before I get
> a "relay resumed" message.
  As Damian Johnson has said, it is hard to guess the cause without more
clues. But keep in mind that 2MB/s with 7k connections puts a
considerable load on the operating system. Are you sure it’s not your
machine that is limiting performance of your relay? That could cause
temporary, short lockups, preventing nyx from receiving notifications
from the relay in time and considering it unresponsive.

  That’s my guess after seeing that your average traffic hovers under
200kB/s. This alone does not indicate any problems with your
configuration yet, because it’s also a matter of how much connections
you actually receive. But together with the “Relay unresponsive” warning
it reminds me of what I see when my own node is experiencing hiccups
during high load from other sources.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Authority Nodes

[mpan]

> I see the Authority Nodes are located only in North America and Europe.
> I would like to contribute to the TOR network as much as possible. I am
> currently running a node and I would like to make it an Authority Node as
> well.
> I am from Brazil and I believe it would possibly be a good idea to have a
> new Authority Node in South America.
> What are the requirements? What should I do to become one of them?
> FYI, the node I am running is 79DFB0E1D79D1306AF03A4B094C55A576989ABD1
Hello and thanks for running the exit node,

  If you mean the authorities like moria1, tor26 and so on, this is
unfortunately the part where we must put our trust in flesh machines
instead of clean algorithms. Therefore operators of those servers are
not just random people, who run nodes like you or me.

  I don’t know the exact selection process, but what I know is that
knowing the operator in person for a long time is one of the
prerequisities. That explains why authorities are located only in North
America and Europe. Another factor, but this is only my guess, may be
that the state must be perceived as relatively safe and non-interfering
in hidden, muddy or plainly illegal ways. This is why I would myself be
against running such an authority in my own country. But this is all I
can tell or guess.

Cheers



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released

[mpan]

  Great job, except one thing. Can’t providing *any* contact info be
obligatory? What’s the point of making specifically the email address
required? What are benefits of having it *over other contact info*?

 -  Automatic verification of some kind? No.
That would require client-side system coupled with email accounts.

 -  Limiting abuse by requiring an email? No.
Emails are cheap. Much cheaper than e.g. obtaining a domain and
having some specific DNS entry or web page provided. That at least
costs some money and confirms that the operator has control over
the domain.

 -  Increasing contact? No.
I was offering an email address for some time and the only
experience was no single message from a human actually contacting
me about Tor. Everything was only spam. Suggesting address rotation
or antispam filters is merely an attempt to dismiss the issue,
not an answer to it.

  I see it as putting more burden on operator for no good reason and
making yet another service require an easily abuseable information to be
released. I’m aware of of benefits of email (open, “everyone” uses it)
and downsides of other options (limited access, abusive or poorly
designed websites), but are those really the argument for making this
specific information trivially harvestable?

  As long as this is optional, it’s not a huge problem. But I do not
believe in ignoring stuff simply because temporarily it does not affect
me personally.

mpan



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released

[mpan]

> I'm also fine with making it optional in the upcoming version 2
> to lower the barrier for adoption.
  My goal is not to make contact info optional. I do understand value of
such information. The problem is choosing one specific means of
communication as mandatory, instead of letting the operators choose the
one that is most convenient to them.

  My primary gripe with email is not my privacy. I decided to remove it
from my ContactInfo upon noticing that I skim over the messages and
discard them in bulk as spam. At this point reaching me through email
became unlikely: I would probably delete the message.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How long does it take for a relay IP to stop being displayed in metrics and web service?

[mpan]

> Beyond the discussion of whether the owners of these services understand Tor 
> or not, it's a problem that the address is added to public lists, especially 
> for non-exit relays.
  The addresses have to be public, because other users need to be able
to connect to them. Public listing of bridge nodes is somewhat limited
at the cost of making access harder for honest users and the solution is
only shifting the problem a bit.

> My question is how long does it take for a relay to disappear ?
  Aside from what people have alrady said before me, the problem is
usually not on Tor Metrics side. There is a third player here: companies
that offer blocklists. It’s totally up to them when they think the IP
address is “clean”. It may be from a day to never, depending on how much
they care about quality of the lists they push to their customers. From
my experience and hearsay a day to a week is a typical time for most cases.

  You may use some anonimizing solutions (VPS) for the time being to
hide your identity, if accessing those services is urgent.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Log warning : possible (zlib) compression bomb on middle relays

[mpan]

  A similar observation on a middle+guard (times in UTC). Nothing since
then, no other issues observed:
--
Nov 02 04:11:12: Possible compression bomb; abandoning stream.
Nov 02 04:12:09: Possible zlib bomb; abandoning stream.
Nov 02 04:12:10: Possible compression bomb; abandoning stream.
Nov 02 04:12:10: Possible compression bomb; abandoning stream.
Nov 02 04:12:18: Possible compression bomb; abandoning stream.
Nov 02 04:13:09: Possible compression bomb; abandoning stream.
Nov 02 04:13:10: Possible compression bomb; abandoning stream.
--




signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 253 new exits - up and down

[mpan]

> It's even public! See:
> https://lists.torproject.org/pipermail/tor-consensus-health/2020-November/011602.html
> 
> Those nodes triggered an alarm on our side for being a potential sybil
> attack. So, we kicked them out.
  Isn’t there a time correlation with the “Possible compression bomb;
abandoning stream.” warnings operators are reporting today:
?
Perhaps related?



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Possible compression bomb, abandoning stream message received

[mpan]

> Suddenly received a message saying [warn] Possible compression bomb, 
> abdnoning 
> steam. Not sure what this means, but the bridge does appear running, saying 
> it 
> has pushed 3 GB within the last 7 days. It just seems odd as looking it has 
> logged this message a huge number of times within an hour or so.
  Hi,
,
cheers.




signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] I was banned from PayPal

[mpan]

Today I received a message from PayPal that paying for Tor relay server leases 
was a direct violation of my usage agreement. I have been paying off-shore VPS 
hosts for my Tor server leases with PayPal for at least ten years. Very 
interesting that they act now.
  How comes they determined what you are paying for? Unless the money 
were being sent to wehosttorrelaysonly.example.com, the payment should 
be opaque to PayPal.





OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] TOR relays killing internet speed

[mpan]

I am hosting 3 VM's limited at 10Mbps all together. Each VM is limited 
to 1Mbps via proxmox. I have noticed if i have these relays running it 
kills a 10Gbps fiber optic line. All the way down to 50Mbps or worse 
depending on what the time of day. Any idea what i can try? I noticed 
this happen over the past few months maybe its increased usage on the 
relays not sure. According to TOR relay search the demand has spiked 
recently. I wondering why/how it could bypass the limits on both proxmox 
and pfsense.
  I am experiencing a similar effect since a few months, often without 
filling even half of the available bandwidth. Like what Sebastian 
suggested earlier, I suspect the horrible quality ISP-supplied 
modem/router. It’s not like the bandwidth is actually used: in fact 
during the interruptions it falls to a negligible level. The situation 
is more about packets being dropped or experiencing extremely large 
processing times (hundreds to thousands msecs).


  If your situation is similar and you do not need the router function, 
does switching to bridge mode help in any way?




OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] owner of tor log file changes after reboot

[mpan]

I have a question and I don't know were I have to look at. I am running 


a relay (compiled from source) on Raspberry Pi OS Buster. Tor is runs 
under the user "pi", so the tor logfile has also the user permission 
(chown pi logfile).


Tor starts via crontab (@reboot) but after a reboot the user of the 
logfile changed to "debian-tor". After every reboot I have to change it 



back to "pi".
  Are you sure Tor is runnig under user “pi” and not “debian-tor”? What 
is the value of the “User” option in torrc? Who is the process owner: 
see in `htop`, `top` or similar?


  Another question is, what’s the reasoning behind switching from a 
dedicated user to the default system account⁽¹⁾ shared with other services?


¹ No Raspberry Pi OS Buster here, but googling indicates “pi”
  is the default user on a fresh install.



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] relay monitoring

[mpan]

   How would I continuously monitor the incoming traffic to my relay,
   both what's supposed to be there and what isn't.
  I’m don’t know, what do you mean by “supposed to be there and what 
isn’t”, but in general you can use nyx⁽¹⁾ to monitor your Tor node.


  If that’s for some research and finer control is needed, Tor nodes 
expose a control socket, which is what nyx uses. Available either 
directly⁽²⁾ or through a Python library — Stem⁽³⁾. If conducting 
research, please respect users’ privacy. In particular see the 
“Expectations for Relay Operators” draft⁽⁴⁾.


  Finally, all incoming connections arrive at the same port, so under 
Linux they are traceable using common tools: auditd, 
libcap/tcpdump/Wireshark, iproute2’s `ss` and so on.


 ¹ https://nyx.torproject.org/
 ² https://gitweb.torproject.org/torspec.git/tree/control-spec.txt
 ³ https://stem.torproject.org/
 ⁴ 
https://gitlab.torproject.org/tpo/community/team/-/wikis/Expectations-for-Relay-Operators




OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Block certain .onion websites

[mpan]

Hello, exit node operator here. I share the values of the TOR foundation, 
that’s why I’m operating an exit node but I can’t unsee all the bad it is used 
for. I know it would sound like censorship but wouldn’t it be possible for an 
exit relay to block certain (mainly cp) .onion websites so that they cannot be 
visited from certain exit nodes? Thanks in advance
  The two main concerns about people, who engage in sexual abuse of 
minors, using telecommunication is incentivization of content production 
and finding/grooming victims. If you have access to any hidden services, 
which are used by producers of videos/photos recording such acts, you 
may report it to your local law enforcement and relevant NGOs: 
background analysis, long-term observation and evidence acquisition are 
much more useful than you may expect. Keep in mind that, while products 
of this activity may be shared digitally, the production itself is 
taking place in meat-space. The second concern is not an issue for Tor: 
it’s unexpected for a potential victim to seek access to such a service.


  You should also be aware that, by blocking access to hidden services, 
you would be removing it to everyone: including people, who use that to 
protect children. By doing so you may be placing yourself in the role of 
a judge or — worse — trying to use the technology to introduce policing 
based on your own beliefs.


Thanks for running a node, mpan



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relays running an unsupported (EOL) Tor version

[mpan]

Relays running unsupported Tor versions is a problem we have never
really dealt with in a systematic way in the way. Some of you might
recall that we (with the help of volunteers) tried back in 2019/2020 to
get operators, running an unsupported Tor version, to upgrade[1] but
then we dropped the ball. Alas. […]
  Is there any data available that sheds light on why operators run 
outdated versions, so the situation could be addressed not only 
reactively, but also in a preventive manner?


mpan


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Recent rejection of relays

[mpan]

1. Asking all relay operators to list their email addresses in the public relay list is 
largely equivalent to asking them to invite tens of thousands of spam emails into their 
inboxes and having to either ignore most of them or set up aggressive filtering rules 
which can easily bounce legitimate messages. This also opens up a convenient channel for 
"adversaries" to harass or even coerce the relay operators.
  Contact info isn’t limited to email. CIISS currently allows⁽¹⁾ even a 
Twitter account or an XMPP JID, and in required fields you may provide a 
home page URL instead of a plain email.


  However, email addresses exposed that was see nearly no spam. While I 
see the issue and I am happy there are other options, in the current 
state of affairs I am less concerned about publishing the email address 
in my ContactInfo than revealing it in this particular message. Neither 
is very attractive to spammers, but the latter may trigger some people 
to spam me to just prove how wrong I am.



2. Middle relays can be used for attacking and the only defense being "list your email 
addresses or else we'll kick you out" throws a sizable wretch into the credibility and 
technical soundness of the whole project. If the "adversaries" are capable of 
de-anonymize tor users by simply running a middle relay that by design knows neither the real 
sources nor the real destinations of the traffic through it, I wonder how hard would it be for them 
to set up an email address?
  You are assuming those are adversaries, who do that intentionally. 
Instead of nodes being misconfigured and their operators not reachable 
to resolve the issues.


  For adversaries it is a noticeable cost. Deploying 500 nodes is cheap 
and automatic. Hiring people, to respond to email in a manner that 
doesn’t instantly reveal they are call center drones, is having neither 
of those properties.


⁽¹⁾ https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Please check if your relay has fallen out of the consensus

[mpan]

Have you tried checking what happens when you access the directory's 
port using a web browser or curl?


curl -I http://217.196.147.77:80

Where do you get redirected?
  Back then, no. I noticed the redirect only when investigating the 
issue now. For completness, *now* both Firefox and curl return an empty 
response.


  But please keep in mind the 302 may be a red harring. It likely 
happened around the moment ISP’s box was booting. It isn’t supposed to 
have any such feature, but it’s not hard to imagine it has an 
undisclosed service (a captive portal etc.) that gets activated by 
accident during boot and then is shut down, leading to a spurious 302. 
Hence I added it only as a side note.


  For now the node seems to be running fine. The addresses I mentioned 
earlier to be inaccessible (moria1, gabelmoo, maatuska, longclaw, 
faravahar) remain unresponsive from my end, last hop (83.1.5.194) being 
inside ISP’s infra. maatuska still responds to ICMP pings, but not TCP 
(including tracepath or connections): however the issue seems to be on 
matuuska’s end.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Please check if your relay has fallen out of the consensus

[mpan]

  NOTE: this email has been written around 2024-10-30 19:00 UTC, about 
2.5 hours ago. As I was testing stuff, suddenly I got flags and *some* 
traffic on my node. It also appeared back in atlas as mysteriously as it 
did disappear. Nonetheless I’m sending the email, hoping it is helpful, 
and will report back in a week.



Can you check to see if your relay is in a similar situation?

In particular, the situation to look for is "Tor process is
still running fine from your perspective, but, relay-search
(https://atlas.torproject.org/) says you are no longer running."

  Hello, I see the same with my node.

  Prompted by a fall in traffic I checked relay-search a few days ago 
and found the relay is no longer listed. Going through the logs it seems 
there is no new circuits being made since October 23. In Nyx I see at 
most a few incoming and outgoing connections.


  The node is mpan11 92A125B9AB491AFC084E4257B552D0FB56090CB3, and this 
is the first time in about 10 years I experience anything like that.



If your relay is in this situation, the next step is to check your Tor
logs, try to rule out other issues like firewall rules on your side,
and then (if you're able) to start exploring traceroutes to the directory
authority IP addresses vs other addresses. If you need more direct help,
we can help you debug or answer other questions on #tor-relays on IRC.
  Traceroutes from the node listed in [1]. From two other hosts 
(French, German VPS) all addresses except maatuska are accessible, and 
the final hops are similar. I asked a friend (same ISP, city) to ping 
all the addresses that don’t respond and they confirmed no ping 
responses. However, maatuska seems to respond to ICMP pings.


  If that helps, on October 23 I see some entries[2] I don’t recall 
ever seeing. This did happen when my network connection died for about 
10 minutes around 01:20. At 22 I had to reboot the system and since then 
the node reports 0 circuits. But that may be just a coincidence and the 
responses might’ve been ISP’s modem interfering in some way.



[1] Traceroutes, to 30 hops. ‘…’ indicates no more replies:
---
 # moria1
 $ tracepath -b 128.31.0.39
 1?: [LOCALHOST]  pmtu 1500
 1:  _gateway (192.168.1.1)0.499ms
 2:  war-bng10.neo.tpnet.pl (83.1.5.194)  15.434ms
 3:  no reply
 …

 # tor26
 $ tracepath -b 217.196.147.77
 1?: [LOCALHOST]  pmtu 1500
 1:  _gateway (192.168.1.1)0.359ms
 1:  _gateway (192.168.1.1)3.782ms
 2:  war-bng10.neo.tpnet.pl (83.1.5.194)   3.833ms
 3:  war-r21.tpnet.pl (80.50.19.25)2.383ms asymm  4
 4:  win-b2-link.ip.twelve99.net (62.115.153.224) 12.699ms
 5:  as33891-ic-331887.ip.twelve99-cust.net (62.115.13.142)  16.619ms 
asymm  6

 6:  ae5-2058.slz10.core-backbone.com (81.95.2.50)19.534ms asymm  9
 7:  core-backbone.conova.at (5.56.17.86) 17.129ms asymm 12
 8:  149.3.164.138 (149.3.164.138)18.783ms asymm 13
 9:  reliant-gw.noreply.org (185.69.162.222)  27.474ms asymm 13
10:  tor.cypherpunks.eu (217.196.147.77)  30.815ms !H

 # dizum
 $ tracepath -b 45.66.35.11
 1?: [LOCALHOST]  pmtu 1500
 1:  _gateway (192.168.1.1)0.739ms
 1:  _gateway (192.168.1.1)0.716ms
 2:  war-bng10.neo.tpnet.pl (83.1.5.194)   5.480ms
 3:  war-r21.tpnet.pl (80.50.19.25)4.162ms asymm  4
 4:  win-b2-link.ip.twelve99.net (62.115.153.224) 15.974ms
 5:  win-bb2-link.ip.twelve99.net (62.115.114.182)22.121ms asymm  6
 6:  ffm-bb2-link.ip.twelve99.net (62.115.138.22) 26.017ms asymm  8
 7:  adm-bb2-link.ip.twelve99.net (62.115.137.222)30.844ms asymm  9
 8:  no reply
 9:  novoserve-ic-354347.ip.twelve99-cust.net (62.115.188.167) 31.944ms 
asymm  8

10:  no reply
11:  no reply
12:  no reply
13:  tor.dizum.com (45.66.35.11)  34.349ms reached

 # gabelmoo
 $ tracepath -b 131.188.40.189
 1?: [LOCALHOST]  pmtu 1500
 1:  _gateway (192.168.1.1)2.812ms
 1:  _gateway (192.168.1.1)1.120ms
 2:  war-bng10.neo.tpnet.pl (83.1.5.194)  11.639ms
 3:  no reply
 …

 # dannenberg
 $ tracepath -b 193.23.244.244
 1?: [LOCALHOST]  pmtu 1500
 1:  _gateway (192.168.1.1)0.563ms
 2:  war-bng10.neo.tpnet.pl (83.1.5.194)   5.746ms
 3:  war-r22.tpnet.pl (80.50.20.25)6.182ms
 4:  win-b2-link.ip.twelve99.net (213.248.103.4)  13.986ms
 5:  win-bb1-link.ip.twelve99.net (62.115.114.184)16.536ms asymm  6
 6:  mcn-b1-link.ip.twelve99.net (62.115.

[tor-relays] Re: Mass-email sent to relay operators

[mpan via tor-relays]

Hello my fellow relay operators,
It doesn't seem like there's any malicious intent, maybe a bit of schizophrenia 
perhaps, but I've reached back out simply asking if he has any proof of 
anything actually going on just to appease my own curiosity.
(…)
I have no further comment about this.

Thanks, Zachary.

  Per the principle of not giving exposure, I avoided posting a 
message. After all, all of us are going to receive it. My only concern 
was, that perhaps only I got the email. Making that some weird kind of a 
phishing attack. Now it’s clear that’s not the case.


  It seems that the person harvested emails and indiscriminately 
spammed everybody: the recipients list contains @torproject.org too.


  I agree regarding this not being malicious. However. If we’re wrong, 
I see two options to be cautious about. It may be FUD against Tor: the 
network or the project. With the goal of either discouraging 
participation or presenting us to other observers as not caring. Or it 
may be an attempt to collect data on relay operators. What kind, I can’t 
tell, but this is the kind of message that triggers xkcd 386 and 
engaging in a mail exchange.


Cheers, keep relaying and carry on
___
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-le...@lists.torproject.org