- tor-relays - lists.torproject.org

An easy self-DoS and how to avoid it
by j4c4l4 28 Jun '19

28 Jun '19

Hi there, I have been operating a non-exit relay and a bridge for about one week now. I discovered by chance a quite silly self-DoS which could be triggered by using a NIDS (Network Intrusion Detection System) on relays. I don't know if it is known, but I thought it was worth reporting it here. In many Linux distributions, several NIDSs come with a default policy that blocks all the traffic from offending IPs after they have reached a threshold score. The offending IPs are normally put into a separate firewall chain/table that DROPs all the traffic originating from them, and then re-enabled after a period that could vary between 30 minutes and a few hours (again, depending on the config). Now, this could be potentially used to periodically shut down relays. In fact, an attacker could perform something as simple as an ssh login scan *through tor*, which is among the "attacks" monitored by most of the NIDS out there. But since the login attempts appear to originate from the tor exit relay, this effectively flags *the exit* as an "offending" host, and triggers the corresponding firewall rule (which is normally a blind "DROP", to save on rule processing). Once an exit node is flagged as "offending" and put in the firewall rule, any traffic between the relay and the exit node is effectively forbidden, until the firewall rule is removed or the tables flushed. If performed on a large scale, this can potentially shut down all the relays which run a NIDS with such policy on ssh logins. The same is true for other simulated attacks on other protocols (but ssh monitoring and blind DROPs are so much common to be the ones of most concern, maybe). I don't know how many relays run a NIDS (I suspect several do, actually), but it would be better to be aware of this potential self-DoS attack. The easy solution (apart from not using any IDS on relays) is to make sure that all the incoming traffic to the ORPort is always accepted, e.g. introducing an ad-hoc firewall first rule that accepts all TCP stuff from the ORPort, before processing NIDS-managed rules. Sorry if this was known already, but I couldn't find anything related by looking at the recent topics in the ML archives, and I thought it coud be useful to share. Regards

1 0

Best practice for tor-exit node when I switch internet providers?
by Chris Dagdigian 28 Jun '19

28 Jun '19

Hello, I've been running a tor exit node in the US since 2014 when I paid way too much for a comcast business internet circuit that came with static IPs and a TOS that allowed me to run servers at home. It looks like I'm going to switch providers in a month or so as there is a fiber service I can get with symmetric bandwidth, the static IP count I want and theoretically also a TOS that is also amenable to server hosting. What is the best practice if I want to keep my tor exit going but switch upstream carriers and IP addresses? I'm guessing this is going to trip a bunch of tor monitoring alerts if I just bring the server up at a new IP address. Should I change the nickname? Totally wipe and reinstall tor itself? The goal is to bring back the same exit node but not set off any alarms when the exit node with the same IP for many years suddenly shows up with a new address. -Chris

2 1

torrelays have no bandwith
by TorGate 28 Jun '19

28 Jun '19

Hi to all, i have issues with my 3 relays, there is no bandwith ?! i have not changed the config only updatet the tor software. In nyx can i see there are smal bandwith connections 1-100 kbs. All 3 relays have a 5mbit up/down connection. https://metrics.torproject.org/rs.html#search/torgate

3 3

Interesting Reddit Post for Tor Relay Operators on Verizon FiOS (Verizon blocks Verizon.com on Tor Relay IP Addresses Including Non-Exit Relays)
by neel＠neelc.org 26 Jun '19

26 Jun '19

Hi tor-relays@ mailing list, If you are running Tor relays on FiOS, or run Tor relays and are considering joining FiOS, here's an interesting Reddit Post: Title: Verizon blocks Verizon.com on Tor Relay IP Addresses (Including Non-Exit Relays) URL: https://www.reddit.com/r/privacy/comments/c5whh5/verizon_blocks_verizoncom_… -Neel Chauhan === https://www.neelc.org/

1 0

TCP SACK PANIC type kernel vulnerabilities: logging some packets
by tor＠t-3.net 25 Jun '19

25 Jun '19

As of last week there wasn't a new kernel out for our relay's distro, so I implemented an IPTables-based mitigation in our relay as such: -A INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j LOG --log-prefix "TCP_SACK_PANIC: " -A INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP Over the weekend we logged hits to this rule. I checked a few of the source hosts, and they were not relays at least as they are listed in https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1 . I'll pull the rule out once the kernel is patched, but yeah. Things that make you go hmm.

2 1

Re: [tor-relays] Tor memory leak (0.3.5.7)?
by starlight.2018q2＠binnacle.cx 25 Jun '19

25 Jun '19

Hi, No leaks. The VM has 1GB, very light for moderate busy relay. Should be 4GB, perhaps 3DB would do. Settings should include: AvoidDiskWrites 1 DisableAllSwap 1 MaxMemInQueues 1024MB # perhaps 1536MB My relays run about 800MB to 1.2GB. A nice way to view memory usage is with egrep '^Vm' /proc/$(cat /var/run/tor.pid)/status which might show something like VmPeak: 871696 kB VmSize: 710152 kB VmLck: 710148 kB VmHWM: 810872 kB VmRSS: 649328 kB VmData: 492052 kB VmStk: 93 kB VmExe: 4704 kB VmLib: 104724 kB VmPTE: 1044 kB Notice that current VmSize usage is less than VmPeak, indicating that memory was release by glibc malloc. Tor consumes substantial skbuf memory in the kernel, which accounts for some of the difference in reported size for VmRSS and VmSize and total memory consumption.

3 2

Build problem
by dns1983＠riseup.net 25 Jun '19

25 Jun '19

Hello, I'm trying to build tor for from source on a x86 Debian stretch machine. I first installed all dependencies, but when I launch the "./configure" command I see the following error: configure: WARNING: Unable to find liblzma. configure: WARNING: Unable to find libzstd I installed, among the others liblzma-dev, lzma, libzstd-dev and zstd. I'm working through ssh. What I'm doing wrong? Could It be caused by a wrong environment variables settings? Cheers Gigi

2 2

obfs4proxy installation from deb.torproject.org says Release file expired
by s7r 25 Jun '19

25 Jun '19

Hello, Trying to spin some new obfs4bridges. I am using: deb.torproject.org/torproject.org obfs4proxy main in /etc/apt/sources.list -- I hope this is correct. I get this: E: Release file for https://deb.torproject.org/torproject.org/dists/obfs4proxy/InRelease is expired (invalid since 1d 15h 7min 11s). Updates for this repository will not be applied. Just recently saw Yawning's release notification, is it somehow related? Thanks.

2 1

fresh assault on Tor network
by starlight.2018q2＠binnacle.cx 25 Jun '19

25 Jun '19

https://metrics.torproject.org/userstats-relay-country.html?start=2017-06-2…

3 3

Become a Fallback Directory Mirror
by gus 25 Jun '19

25 Jun '19

Dear Relay Operators, Do you want your relay to be a Tor fallback directory mirror? Will it have the same address and port for the next 2 years? Just reply to this email with your relay's fingerprint. If your relay is on the current list, you don't need to do anything. If you're asking: Q: What's a fallback directory mirror? Fallback directory mirrors help Tor clients connect to the network. For more details, see [1]. Q: Is my relay on the current list? Search [2] and [3] for your relay fingerprint or IP address and port. [2] is the current list of fallbacks in Tor. [3] is used to create the next list of fallbacks. Q: What do I need to do if my relay is on the list? Keep the same IP address, keys, and ports. Email tor-relays if the relay's details change. Q: Can my relay be on the list next time? We need fast relays that will be on the same IP address and port for 2 years. Reply to this email to get on the list, or to update the details of your relay. Once or twice a year, we run a script to choose about 150-200 relays from the potential list [3] for the list in Tor [2]. Q: Why didn't my relay get on the list last time? We check a relay's uptime, flags, and speed [4]. Sometimes, a relay might be down when we check. That's ok, we will check it again next time. It's good to have some new relays on the list every release. That helps tor clients, because blocking a changing list is harder. cheers, gus [1] https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors [2] https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc [3] https://gitweb.torproject.org/tor.git/tree/scripts/maint/fallback.whitelist [4] https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_…

13 19