- tor-relays - lists.torproject.org

>30% of the Tor network runs outdated version: Consider enabling auto-updates
by nusenu 27 Jan '18

27 Jan '18

Hi, when writing the content for the Tor Relay Guide we also collected steps to enable auto updates for various Linux distributions. The motivation for this is that there are a lot of relays (>3000) running outdated tor releases. If more operators enable auto-updates the number of outdated tor relays hopefully decreases. https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#AutomaticSoftwa… Debian: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DebianUbuntuUpd… RPM Distros: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/RPMUpdates thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

7 11

debugging unbound on 'torexit' failing DNS queries
by nusenu 26 Jan '18

26 Jan '18

<tor-admin(a)portaltodark.world> wrote: > Resent under the correct alias. > > I'm having high amounts of failures on this VPS (PulseServers). I run a > local unbound instance, and see an incredible amount of: > Jan 17 19:27:33 torexit unbound: [559:0] notice: sendto failed: Operation > not permitted > Jan 17 19:27:33 torexit unbound: [559:0] notice: remote address is > 198.97.190.53 port 53 > Jan 17 19:27:33 torexit unbound: [559:0] notice: sendto failed: Operation > not permitted > Jan 17 19:27:33 torexit unbound: [559:0] notice: remote address is > 192.42.93.30 port 53 > Jan 17 19:27:33 torexit unbound: [559:0] notice: sendto failed: Operation > not permitted > Jan 17 19:27:33 torexit unbound: [559:0] notice: remote address is > 192.35.51.30 port 53 > Jan 17 19:27:33 torexit unbound: [559:0] notice: sendto failed: Operation > not permitted > > To give proportion to "incredible amount", > Jan 17 19:21:32 torexit rsyslogd: imjournal: 9897 messages lost due to > rate-limiting > Jan 17 19:22:02 torexit journal: Suppressed 1216 messages from > /system.slice/unbound.service > Jan 17 19:22:32 torexit journal: Suppressed 1209 messages from > /system.slice/unbound.service > Jan 17 19:23:02 torexit journal: Suppressed 1827 messages from > /system.slice/unbound.service > Jan 17 19:23:32 torexit journal: Suppressed 2333 messages from > /system.slice/unbound.service > Jan 17 19:24:02 torexit journal: Suppressed 3029 messages from > /system.slice/unbound.service > Jan 17 19:24:32 torexit journal: Suppressed 2822 messages from > /system.slice/unbound.service > Jan 17 19:25:02 torexit journal: Suppressed 2715 messages from > /system.slice/unbound.service > Jan 17 19:25:32 torexit journal: Suppressed 3166 messages from > /system.slice/unbound.service > Jan 17 19:26:02 torexit journal: Suppressed 4093 messages from > /system.slice/unbound.service > Jan 17 19:26:32 torexit journal: Suppressed 45878 messages from > /system.slice/unbound.service > Jan 17 19:27:02 torexit journal: Suppressed 30125 messages from > /system.slice/unbound.service > Jan 17 19:27:32 torexit journal: Suppressed 31764 messages from > /system.slice/unbound.service > Jan 17 19:28:02 torexit journal: Suppressed 31229 messages from > /system.slice/unbound.service > > Could it be limits from the VPS provider on the amount of outbound udp/53 > connections? To me this looks more like a local problem? Are you doing any packet filtering on the host (outbound)? Does DNS work on that host if you try manual queries? From the IPs in your logs I assume your unbound is configured to query recursively itself (no upstream forwarding) that is good, can you confirm that and provide your unbound config + iptalbes -vnL? -- https://mastodon.social/@nusenu twitter: @nusenu_

4 13

Re: [tor-relays] A lot of Warn messages when bootstrapping
by Dark Matter 26 Jan '18

26 Jan '18

Thanks for the fast reply! > Your relay has probably chosen some overloaded guards. > The problem comes from the extra load on those machines, not your relay. > Your relay will eventually try other guards. > > Are you sure it's not overloaded? > It might be worth checking the logs, inbound connections, RAM, and CPU > after it has been running for a few days. Yes, the relay is working fine - the only problem was the connection limit due to some OS-level limits.which is why I had to restart the relay in the first place. > Ignore the warning messages unless your relay is having problems. Ok, I'll do :) Once one successful circuit was established, there were no warnings any more. It just took some time - but I cannot tell if the relay switched guards or if the guard nodes finally managed to accept a connection request, since I didn't check the guard node set prior to restarting. Regards, Dark

1 0

No graph update for my relay in ATLAS
by Peter Ott 26 Jan '18

26 Jan '18

Hi, it seems that the graph in ATLAS (1 month and 3 months) for my relay isn't updated any longer for the graph 'read.' and 'written bytes per second' (last info was of 2018-01-01). The graph for 'consensus weight', 'middle probability' etc. seems to be ok. During startup of TOR (running it on Windows 10 / x64) the DirPort and the ORPort is reachable. Any idea? Btw how long must the relay be 'up' to get the 'stable' or 'guard' flag granted. My relay is now online for 46 days -only restarted for a TOR release upgrade-. A change of the IP-adress seems to be handled fine by TOR. This change by the ISP occurs at least every 3 days or so). Thanks in advance and best regards Peter Relay TRUMPER FP: 12DFC9D1852979939D9317F57A857C80BC73165E

4 6

Advertised Bandwidth
by MarkIt8Dude 25 Jan '18

25 Jan '18

Hi all, I’d like to understand something about Advertised Bandwidth. I set up my Tor Relay 3 months ago. With the following settings : RelayBandwidthRate 1250 KBytes RelayBandwidthBurst 1450 KBytes But i only get and Advertised Bandwidth of 83.79 KiB/s. Very far from my settings. And also it makes me think that my relay is completely useless …☹ Any suggestions ? Thx,

3 2

Upgraded relay non show in ATLAS
by MLTor Node 25 Jan '18

25 Jan '18

Hi to all! i have a little relay running in my home LAN on Windows 2016 server (MLTorNode, FE4033D750831C32A957174ADD11E40F558A14A9). A few days ago, i create two VLan on my home network, one dedicated for my Tor relay. Today i updated service to 3.2.9 release. After starting tor service, log say that Orport and DIRport are reachable from outside, so it seems to be working without problems. But if i query Atlas, my node seems to be down from 5 days. The IP showed in Atlas is old (i have dynamic IP and dynamic DNS). I stop and start several times service with no luck. Anyone can help me? My node is small, but i like very much Tor and i want to continue contributing to the project. -- Marlenio (MLTorNode) FE4033D750831C32A957174ADD11E40F558A14A9

2 3

Middle relays stopping because of "SYN flood"?
by Christian Krbusek 25 Jan '18

25 Jan '18

Dear list, recently I´m facing issues with my 4 middle relays: B1E889E8EA604D81326F5071E0ABF1B2B16D5DAB FC9AC8EA0160D88BCCFDE066940D7DD9FA45495B BDB9EBCB1C2A424973A240C91EEC082C3EB61626 ACD889D86E02EDDAB1AFD81F598C0936238DC6D0 All of them running v0.3.2.9 on Debian stretch (kvm, 2 cores, 2GB RAM) and stopping with the log entries below. I can´t remember when this started but I´m quite sure it did not happen a few month ago. There have not been any recent changes on the hardwarenode or on the VMs. All of them running the "same" configuration created by ansible-relayor - one example below. The VMs are running at the time the relays go offline and even a network restart doesn´t fix the issue so I have to restart the VM to get the relays up and running again. Any hints would be much appreciated, if any more infos are needed just ask. Cheers, Christian >>>>> CONFIG START <<<<< # ansible-relayor generated torrc configuration file # Note: manual changes will be OVERWRITTEN on the next ansible-playbook run OfflineMasterKey 1 RunAsDaemon 0 Log notice syslog OutboundBindAddress 188.118.198.244 SocksPort 0 User _tor-188.118.198.244_443 DataDirectory /var/lib/tor-instances/188.118.198.244_443 ORPort 188.118.198.244:443 DirPort 188.118.198.244:80 SyslogIdentityTag 188.118.198.244_443 ControlSocket /var/lib/tor-instances/188.118.198.244_443/controlsocket Nickname ph3x Sandbox 1 ExitRelay 0 ExitPolicy reject *:* ContactInfo 4096R/0x73538126032AD297 Christian Krbusek <abuse AT ph3x DOT at> - 1NtneNxb8awwH8woJ7oL7UVj1SJDpAn8Kc RelayBandwidthRate 15 MB RelayBandwidthBurst 30 MB NumCPUs 2 MyFamily acd889d86e02eddab1afd81f598c0936238dc6d0,b1e889e8ea604d81326f5071e0abf1b2b16d5dab,bdb9ebcb1c2a424973a240c91eec082c3eb61626,fc9ac8ea0160d88bccfde066940d7dd9fa45495b # end of torrc >>>>> CONFIG END <<<<< >>>>> LOGS START <<<<< at-vie01a-tor01.ph3x.at: Jan 25 17:58:24 at-vie01a-tor01 Tor-86.59.119.83_443[540]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 8629 v4 connections; and receiv ed 60 v1 connections, 4568 v2 connections, 9249 v3 connections, and 403685 v4 connections. Jan 25 18:00:17 at-vie01a-tor01 kernel: [64938.876706] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.773119] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.774838] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786154] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786189] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786235] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786250] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786315] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786333] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786391] TCP: too many orphaned sockets Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786411] TCP: too many orphaned sockets Jan 25 18:01:15 at-vie01a-tor01 kernel: [64997.053055] net_ratelimit: 2 callbacks suppressed Jan 25 18:01:15 at-vie01a-tor01 kernel: [64997.053056] TCP: too many orphaned sockets Jan 25 18:01:16 at-vie01a-tor01 kernel: [64998.301030] TCP: too many orphaned sockets Jan 25 18:01:16 at-vie01a-tor01 kernel: [64998.365099] TCP: too many orphaned sockets Jan 25 18:01:17 at-vie01a-tor01 kernel: [64998.557033] TCP: too many orphaned sockets Jan 25 18:01:18 at-vie01a-tor01 kernel: [64999.805082] TCP: too many orphaned sockets Jan 25 18:01:27 at-vie01a-tor01 kernel: [65009.277179] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.533307] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.533678] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.533697] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.533820] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.534615] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.535200] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.535460] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.535708] TCP: too many orphaned sockets Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.536685] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.677629] net_ratelimit: 11 callbacks suppressed Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.677661] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.677910] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.677989] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.680478] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.680857] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.682767] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.682832] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.682953] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.683033] TCP: too many orphaned sockets Jan 25 18:01:34 at-vie01a-tor01 kernel: [65015.683041] TCP: too many orphaned sockets Jan 25 18:02:13 at-vie01a-tor01 kernel: [65054.590190] net_ratelimit: 6 callbacks suppressed Jan 25 18:02:13 at-vie01a-tor01 kernel: [65054.590194] TCP: too many orphaned sockets Jan 25 18:02:13 at-vie01a-tor01 kernel: [65054.597927] TCP: too many orphaned sockets Jan 25 18:05:15 at-vie01a-tor01 kernel: [65237.086196] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters. Jan 25 18:17:01 at-vie01a-tor01 CRON[24416]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 18:57:09 at-vie01a-tor01 systemd[1]: Stopped target Timers. at-vie01a-tor02.ph3x.at: Jan 25 10:17:01 at-vie01a-tor02 CRON[19123]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 11:17:01 at-vie01a-tor02 CRON[23992]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 11:59:10 at-vie01a-tor02 Tor-86.59.119.88_443[509]: Heartbeat: Tor's uptime is 11:59 hours, with 38342 circuits open. I've sent 218.94 GB and received 192.87 GB. Jan 25 11:59:10 at-vie01a-tor02 Tor-86.59.119.88_443[509]: Circuit handshake stats since last time: 88566/90206 TAP, 12299213/12353484 NTor. Jan 25 11:59:10 at-vie01a-tor02 Tor-86.59.119.88_443[509]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 6295 v4 connections; and receiv ed 60 v1 connections, 3085 v2 connections, 6040 v3 connections, and 300693 v4 connections. Jan 25 12:17:01 at-vie01a-tor02 CRON[28856]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 12:18:28 at-vie01a-tor02 kernel: [44384.957658] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters. Jan 25 13:17:01 at-vie01a-tor02 CRON[28998]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 14:17:01 at-vie01a-tor02 CRON[29061]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 14:36:57 at-vie01a-tor02 ntpd[490]: Soliciting pool server 185.144.161.170 Jan 25 14:37:05 at-vie01a-tor02 ntpd[490]: Soliciting pool server 2a02:1748:0:1500:3::2005 Jan 25 14:37:16 at-vie01a-tor02 ntpd[490]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3) Jan 25 14:37:36 at-vie01a-tor02 ntpd[490]: error resolving pool 0.debian.pool.ntp.org: Temporary failure in name resolution (-3) at-vie01a-tor03.ph3x.at: Jan 24 13:21:18 at-vie01a-tor03 systemd[1]: apt-daily.timer: Adding 9h 35min 45.841113s random time. Jan 24 13:24:24 at-vie01a-tor03 kernel: [62694.054136] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters. Jan 24 13:59:57 at-vie01a-tor03 Tor-78.142.140.242_443[517]: Heartbeat: Tor's uptime is 17:59 hours, with 0 circuits open. I've sent 314.59 GB and received 317.28 GB. Jan 24 13:59:57 at-vie01a-tor03 Tor-78.142.140.242_443[517]: Circuit handshake stats since last time: 35924/36525 TAP, 10006455/10027375 NTor. Jan 24 13:59:57 at-vie01a-tor03 Tor-78.142.140.242_443[517]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 11906 v4 connections; and received 47 v1 connections, 4092 v2 connections, 8578 v3 connections, and 409960 v4 connections. Jan 24 14:17:01 at-vie01a-tor03 CRON[21604]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 24 15:17:01 at-vie01a-tor03 CRON[21670]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 24 15:41:25 at-vie01a-tor03 ntpd[492]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3) at-vie01a-tor04.ph3x.at: Jan 25 12:00:52 at-vie01a-tor04 Tor-188.118.198.244_443[510]: Heartbeat: Tor's uptime is 11:59 hours, with 36596 circuits open. I've sent 192.29 GB and received 194.32 GB. Jan 25 12:00:52 at-vie01a-tor04 Tor-188.118.198.244_443[510]: Circuit handshake stats since last time: 84713/86100 TAP, 11892935/11941101 NTor. Jan 25 12:00:52 at-vie01a-tor04 Tor-188.118.198.244_443[510]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 5938 v4 connections; and rec eived 44 v1 connections, 2949 v2 connections, 5395 v3 connections, and 287856 v4 connections. Jan 25 12:17:01 at-vie01a-tor04 CRON[29820]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 12:29:17 at-vie01a-tor04 kernel: [44936.694001] hrtimer: interrupt took 12598111 ns Jan 25 13:17:01 at-vie01a-tor04 CRON[2275]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 14:17:01 at-vie01a-tor04 CRON[7180]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 14:27:14 at-vie01a-tor04 kernel: [52013.316026] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters. Jan 25 15:17:01 at-vie01a-tor04 CRON[7920]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 16:17:01 at-vie01a-tor04 CRON[8023]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 25 16:42:38 at-vie01a-tor04 ntpd[492]: Soliciting pool server 81.16.38.161 Jan 25 16:42:46 at-vie01a-tor04 ntpd[492]: error resolving pool 3.debian.pool.ntp.org: Temporary failure in name resolution (-3) >>>>> LOGS END <<<<<

3 4

Tor 0.3.0.x end-of-life date in one week (2018-02-01)
by nusenu 25 Jan '18

25 Jan '18

This is a quick reminder that in one week, Tor 0.3.0.x will reach its end of life date (2018-02-01). >300 relays are still running that major version. https://nusenu.github.io/OrNetStats/#major-versions list of affected relays: https://atlas.torproject.org/#search/version:0.3.0.%20running:true https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… Consider enabling auto-updates to keep your relays safe https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#AutomaticSoftwa… -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

nyx no connections shown
by TorGate 23 Jan '18

23 Jan '18

Hi, i have 2 new relais running and have also installed nyx. When i go to the page 2 in nyx is there no connection. But my network show me over 4000 tor connections . What is the issue with nyx on my torservers ? TorGate torgate(at)linux-hus.dk

5 16

kelihos infection
by scar 22 Jan '18

22 Jan '18

Hello fellow relay operators, I have received word from my ISP that they detected malicious traffic from my account. I'm running the exit node "cave" with reduced exit policy, https://atlas.torproject.org/#details/3875c9c843d33762fa733bcaf128f26a10bc7… The information received from my ISP was: infection => 'kelihos', subtype => 'kelihos.e', port => '52935', asn => '209', family => 'kelihos', sourceSummary => 'Drone Report' Typically they will also provide an IP address related to the infection, which is usually a sinkhole. The solution is to block the IP in my exit policy. However no IP was provided in this report and there is not one available, since my ISP is just relaying information they receive from a 3rd party detection agency. Furthermore, the port mentioned, 52935, is not allowed in my exit policy, so I'm guessing that port is somewhere else... Any ideas about this "infection" and how we could prevent it from using our exit nodes? Thanks

2 1