- tor-relays - lists.torproject.org

Outdated GeoIP DB
by Martin Gebhardt (Die LINKE.) 06 Feb '22

06 Feb '22

Hi, in the past I had already written with someone about it. At that time the entries were not up to date. There was a Gitlab issue about this, but I can't find it now. Anyway, the data is not up to date again. Example: https://apps.db.ripe.net/db-web-ui/query?searchtext=89.58.17.76 vs https://metrics.torproject.org/rs.html#details/6A0A9C3B3381C89CCB85C64BBCF6… The IP address is currently located in Austria. But in the metrics Germany is displayed. This is a "correct" but outdated information. Since I don't know if this can have any effects on the routing, which I don't assume, but is theoretically possible, I just want to target it again.

6 6

Relay operators meetup @ FOSDEM
by Stefan Leibfarth 05 Feb '22

05 Feb '22

Greetings relay operators, the next Tor relay operators meetup will be online @ FOSDEM. Date: 2022-02-05 Time: 1500 UTC Room: https://lecture.senfcall.de/rin-2tx-xcy-g5r No need for a registration or anything else, just use the room-link above. There will be a agenda, but everyone is free to bring up additional questions or topics at the meeting itself. Looking forward to meeting you Leibi [0] https://fosdem.org/2022/fringe/

3 2

Recommended IPv6 Configuration
by t.duellmann+torrelays＠gmail.com 04 Feb '22

04 Feb '22

Dear list, I read here [1] that IPv6 is on the rise and support for it is growing. Are there any recommendations or best-practices how to configure a Tor relay with IPv6? Alternatively, could anybody who got it set up already, post their experiences and maybe even the relevant parts of their torrc? Thanks! [1] https://blog.torproject.org/state-of-ipv6-support-tor-network/

3 2

Exit relays abused to attack Google services
by UDN Tor 03 Feb '22

03 Feb '22

Google is now sending abuse reports complaining of DDoS attacks against their services. While they believe the IPs are participating in a botnet, it is clear that they are Tor exit relays. I don't know why they are sending us the report after the attacks have ended. Besides, since Google services are unusable over Tor, this should not have caused them much damage. I suspect the attacker is trying to get relays shut down by triggering Google reports that would scare off the ISPs. If you are an ISP and you have received the same report, please let me know. I'd like to know if this was global or if we've been "selected". > From: ddos-reports(a)google.com > To: abuse(a)urdn.com.ua > Subject: [#zMto] DDoS from your IPs to Google from 2022-01-28 to > 2022-01-31 > Date: Tue, 01 Feb 2022 20:22:42 +0000 > > We observed IPs under your control participating in DDoS attacks > targeting Google services, including a prolonged DDoS attack from > January 28-31 against the Google Search Console. > > The attacks were Layer 7 / HTTP request floods. Your participating > IPs are listed below, along with the stop time in UTC and targeted > Google IPs. We request that you enforce your Acceptable Use Policy > against these customers. > > +-----------------+-----------------+----------+---------------------+ > | Source | Destination | DestPort | Time_UTC | > +-----------------+-----------------+----------+---------------------+ > | 193.218.118.62 | 142.250.180.227 | 443 | 2022-01-31 15:55:01 | > | 193.218.118.90 | 142.250.180.195 | 443 | 2022-01-31 15:53:28 | > | 193.218.118.100 | 172.217.19.99 | 443 | 2022-01-31 14:43:09 | > | 193.218.118.101 | 142.250.180.227 | 443 | 2022-01-31 17:32:54 | > | 193.218.118.125 | 142.250.180.227 | 443 | 2022-01-31 15:55:28 | > | 193.218.118.145 | 142.250.180.195 | 443 | 2022-01-31 15:55:30 | > | 193.218.118.147 | 142.251.39.35 | 443 | 2022-01-31 15:41:36 | > | 193.218.118.155 | 142.250.180.195 | 443 | 2022-01-31 13:45:43 | > | 193.218.118.156 | 142.250.180.227 | 443 | 2022-01-31 15:57:52 | > | 193.218.118.158 | 142.250.180.227 | 443 | 2022-01-31 18:41:34 | > | 193.218.118.167 | 142.250.201.195 | 443 | 2022-01-31 15:56:53 | > | 193.218.118.182 | 142.251.39.3 | 443 | 2022-01-31 17:31:57 | > | 193.218.118.183 | 142.250.180.227 | 443 | 2022-01-31 17:42:40 | > | 193.218.118.231 | 142.250.180.227 | 443 | 2022-01-31 17:43:08 | > +-----------------+-----------------+----------+---------------------+ > > Note we believe some of these IPs are part of the Meris or Dvinis > botnets. If you are a residential Internet service provider, it is > possible that your customers' routers themselves have been > compromised. You should research the Meris botnet and take > appropriate actions to have them secure their CPE (customer-premises > equipment). > > -- > Security Reliability Engineering :: Google :: AS15169

4 3

reminder: tor 0.3.5 reaches end of life on 2022-02-01
by nusenu 02 Feb '22

02 Feb '22

Reminder: tor 0.3.5 reaches it's end of life on 2022-02-01 (in 3 weeks from now). Over 700 relays - about 7% of the network's guard capacity currently still run this soon unsupported tor version. https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele… kind regards, nusenu -- https://nusenu.github.io _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 1

Introduction message from me :)
by Miryam Webb 02 Feb '22

02 Feb '22

Hello all, I am a new relay operator and I am glad to make your acquaintance. Currently my nodes are not processing traffic because they are being rejected by the directory nodes but I hope that gus will reply soon and that we can get this working. I have been administrating linux servers for more than 8 years but I have no experience with running tor nodes. So if you have tips and tricks a noob should know feel free to write me. :) Miryam

3 2

OVHcloud does not allow Tor exit relays on VPS/cloud services
by Neel Chauhan 02 Feb '22

02 Feb '22

Hi, I was running a pair of Tor exit relays on OVH, and when I sent an response, I got this as a reply: === As provided in our Service Specific Terms, Anonymization services, such as TOR, are not permitted on OVHcloud's VPS or Public Cloud services. We request that you immediately cease utilizing your current subscriptions as a TOR exit node. Failure to comply with this request may result in the suspension and/or termination of your servers and/or account in accordance with our Terms of Service. https://us.ovhcloud.com/legal/service-specific-terms === It seems OVH does not allow Tor exit relays on "cloud" or "VPS" subscriptions anymore. In the past when I used OVH for exits I had no issues, so they must have changed their TOS. I am assuming OVH dedicated servers are fine. I guess I'm moving the two exit relays to Terrahost. Terrahost is more expensive but I already have exits there and they are excellent. I never had a great experience with OVH. -Neel

2 1

wrong iptables rules? / no inbound traffic in nyx
by ax8eaz7z3g 27 Jan '22

27 Jan '22

Hi! I noticed that after I have set up my ip(+6)tables up to filter unwanted incoming traffic all "inbound" and "directory" connections in nyx disappeared, only lot of "outbound" connections are there. I am running exit relay (IPv4+IPv6) on ORPort 443 and DIRPort 80. Is there someone willing to check my iptable rules? I am starting to lose it... > My iptables: > -P INPUT DROP > > -P FORWARD DROP > > -P OUTPUT DROP > > -A INPUT -i lo -j ACCEPT > > -A INPUT -p tcp -m conntrack --ctstate NEW,ESTABLISHED -m tcp --dport 22 -j ACCEPT # SSH running there > > -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT # allow incoming comm to ORPort > > -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT # allow incoming comm to DIRPort > > -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # allow all already established incoming connections > > -A OUTPUT -o lo -j ACCEPT # allow all outgoing connections > > -A OUTPUT -o eth0 -j ACCEPT > My ip6tables: > > -P INPUT DROP > > -P FORWARD DROP > > -P OUTPUT DROP > > -N ICMPv6_IN > > -N ICMPv6_OUT > > -A INPUT -i lo -j ACCEPT > > -A INPUT -p tcp -m conntrack --ctstate NEW,ESTABLISHED -m tcp --dport 22 -j ACCEPT # SSH running there > > -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT # allow incoming comm to ORPort > > -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT # allow incoming comm to DIRPort > > -A INPUT -p ipv6-icmp -j ICMPv6_IN #pass all icmpv6 related traffic to new chain > > -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # allow all already established incoming connections > > -A OUTPUT -o lo -j ACCEPT > > -A OUTPUT -p ipv6-icmp -j ICMPv6_OUT #pass all icmpv6 related traffic to new chain > > -A OUTPUT -o eth0 -j ACCEPT # allow all outgoing connections > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 133 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 134 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j ACCEPT > > -A ICMPv6_IN -p ipv6-icmp -m icmp6 --icmpv6-type 136 -j ACCEPT > > -A ICMPv6_IN -j DROP > > -A ICMPv6_OUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT > > -A ICMPv6_OUT -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT > > -A ICMPv6_OUT -p ipv6-icmp -m icmp6 --icmpv6-type 133 -j ACCEPT > > -A ICMPv6_OUT -p ipv6-icmp -m icmp6 --icmpv6-type 134 -j ACCEPT > > -A ICMPv6_OUT -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j ACCEPT > > -A ICMPv6_OUT -p ipv6-icmp -m icmp6 --icmpv6-type 136 -j ACCEPT > > -A ICMPv6_OUT -j DROP Thank you all for any replies! Have a nice day. Bye

2 2

We need bridges with iat-mode set to 1 and especially 2 as well!
by juckiuscaesar＠web.de 27 Jan '22

27 Jan '22

5 9

tor prometheus metrics -> expected label value, got "INVALID"
by Fran 25 Jan '22

25 Jan '22

Hej, I just found out about the integrated prometheus exporter in tor - yay, thanks for that! I can scrape it with curl: $ curl http://<ip>:9035/metrics # HELP tor_hs_rdv_num_total Total number of rendezvous circuit created # TYPE tor_hs_rdv_num_total counter tor_hs_rdv_num_total{onion=<onionv3adr>} 4 # HELP tor_hs_app_write_bytes_total Total number of bytes written to the application # TYPE tor_hs_app_write_bytes_total counter tor_hs_app_write_bytes_total{onion=<onionv3adr>,port=80} 15211 # HELP tor_hs_intro_num_total Total number of introduction received # TYPE tor_hs_intro_num_total counter tor_hs_intro_num_total{onion=<onionv3adr>} 4 # HELP tor_hs_rdv_established_count Total number of established rendezvous circuit # TYPE tor_hs_rdv_established_count gauge tor_hs_rdv_established_count{onion=<onionv3adr>} 1 # HELP tor_hs_app_read_bytes_total Total number of bytes read from the application # TYPE tor_hs_app_read_bytes_total counter tor_hs_app_read_bytes_total{onion=<onionv3adr>,port=80} 319667 # HELP tor_hs_intro_established_count Total number of established introduction circuit # TYPE tor_hs_intro_established_count gauge tor_hs_intro_established_count{onion=<onionv3adr>} 18 Which looks like proper data for me. Unfortunately prometheus thinks otherwise. In the prometheus webGUI under "/targets" it complains: > expected label value, got "INVALID" The Prometheus config part is: - job_name: tor_metrics metrics_path: /metrics static_configs: - targets: - <server1>:9035 - <server2>:9035 Servers are running Debian 11, Prometheus 2.32.1 and tor 0.4.6.9-1~d11.bullseye+1 I searched the relays mailinglist and tried to find something in the internet, unfortunately not very successfully. Any ideas? Thanks a lot! fran

2 3