- tor-relays - lists.torproject.org

Save the date! Thursday, Dec 07 - Tor Meetup in NYC
by isabela＠riseup.net 04 Dec '17

04 Dec '17

Hello community! We are sending this 'save the date' note to let you know that on Thursday December 7th on the 20th floor of 150 Broadway in the LMHQ shared meeting space at 6:45 PM. There are a lot of folks from the community in NYC so we thought it would be cool to have some time share skills, learn new things, and be a place for new folks who want to get involve to come and meet folks. For this first one we will be talking about our community of relay operators. You can read more at this blog post: https://blog.torproject.org/explore-tor-new-york-city-new-meetup-starting-d… So if you are in the area, come and join us! cheers, Isabela

3 2

Please disregard 'excessive bounce' notice
by Damian Johnson 01 Dec '17

01 Dec '17

Hi all. Everyone with a gmail account not a notice that their subscription was suspended due to excessive bounces. You can ignore this notice, no action is needed on your part. I'm not entirely sure of the root cause but something similar happened a few years back with another list too. I've disabled automated bounce processing and re-enabled everyone's subscription. Cheers! -Damian

1 0

do the 800+ UbuntuCore relays constitute a Sybil attack?
by starlight.2017q4＠binnacle.cx 01 Dec '17

01 Dec '17

The population of these has been climbing for more than a week and no-one has commented, which seems odd. No contact provided. https://atlas.torproject.org/#search/UbuntuCore

4 4

Tor security releases coming tomorrow
by Nick Mathewson 30 Nov '17

30 Nov '17

I'm sending this message to announce that we will be releasing new stable and versions of Tor tomorrow, to fix 5 security bugs. I apologise for the short notice; we've had to move up our intended release date in order to try to match with release deadlines for downstream projects. We have classified 3 of these bugs as Medium and 2 as High, per draft security process at https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Securit… . The most serious bugs are a pair of denial-of-service issues, which we treat as high security because of the possibility of escalating them for traffic-analysis purposes. Note that only the following series are supported, and only they will receive updates: 0.2.5, 0.2.8, 0.2.9, 0.3.0, 0.3.1, and 0.3.2. 0.2.8 and 0.3.0 will become unsupported in January; 0.2.5 will become unsupported in May. best wishes, -- Nick

1 0

Screening DNS
by Dr Gerard Bulger 29 Nov '17

29 Nov '17

The DNS 9.9.9.9 https://www.theregister.co.uk/2017/11/20/quad9_secure_private_dns_resolver/ At least is not blocking my exit node IP, simply because it is TOR! Nice. So far. Gerry

6 7

ymkeo offline
by René Ladan 28 Nov '17

28 Nov '17

Hi, due to hardware problems my node ymkeo 4E8CE6F5651E7342C1E7E5ED031E82078134FB0D will be offline for an undetermined amount of time. René

1 1

Re: [tor-relays] Detecting Network Attack [re: exit synflooded]
by Dhalgren Tor 26 Nov '17

26 Nov '17

>Well, it's still going on, and is pretty much ruining Libero :( . Running CentOS 6, here. > >When it's happening it can look like this: > ># netstat -n | grep -c SYN >17696 I run a fast exit and can offer some advice: 1) mitigate bug #18580 (also #21394); is a DNS denial-of-service and could be the problem. either upgrade to 0.3.2.4+ or edit resolve.conf per https://trac.torproject.org/projects/tor/wiki/doc/DnsResolver#Tuningeventdn… also check out https://arthuredelstein.net/exits/ 2) if you continue to experience excessive outbound scanning SYNs, I've found that simply enabling connection tracking helps by implicitly limiting the rate a which connections can originate. If an iptables "-m state --state ESTABLISHED,RELATED -j ACCEPT" rule exists it will turn it on or you could modprobe the module if you don't want to configure incoming connection rules. some useful sysctl.conf changes, run sysctl -p after or reboot # Tor Exit tuning. net.ipv4.ip_local_port_range = 1025 65535 net.ipv4.tcp_synack_retries = 2 net.ipv4.tcp_max_tw_buckets = 4194304 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_keepalive_time = 300 net.ipv4.tcp_keepalive_intvl = 10 net.ipv4.tcp_keepalive_probes = 3 net.netfilter.nf_conntrack_tcp_timeout_established = 1000 net.netfilter.nf_conntrack_checksum = 0 you might see many messages: kernel: nf_conntrack: table full, dropping packet which indicates no connection table slots were available for an outbound connection and that rate limiting is effected state of connection tracking appears in /proc/net/nf_conntrack

4 5

Re: [tor-relays] Pretty sure our exit was being synflooded
by tor＠t-3.net 26 Nov '17

26 Nov '17

I spoke too soon, it seems - the exit is struggling again, with some time spent destroyed today. As I look at what it's doing, it's clear that someone is relaying SYN packets to random ports and also random destination addresses that aren't even alive. The destination hosts and ports continually vary - it never hits multiple destinations on 1 port, and it does not hit multiple ports on 1 host. I presume it is an attack that is intended to degrade this relay's service quality, or otherwise more broadly, degrade Tor. I'm going to reject a few more trojan listen ports, it might help but it isn't a real fix. My thought btw was for Tor to rate-limit syn scanning activity between the client and the first onion router, with the function taking place in that first-hop router, not at the exit.

2 1

Re: [tor-relays] Pretty sure our exit was being synflooded
by tor＠t-3.net 26 Nov '17

26 Nov '17

Thanks for the configuration suggestions. I intentionally set the conntrack limit high, maybe that was not the best thing. I think I'll be putting it back. Removing my extra IPTables code plus adding a reject for :8888 has made the exit behave properly again. I wonder if the best possible course of action for this sort of thing would be within Tor itself. I don't know that it was a single client connection into Tor that was causing all this trouble, but maybe it was. One would think that one client should not be allowed to do something so severe with the TCP that it can single-handedly ruin a fast exit. Maybe a code change that forces a rate-limit that significantly slows down the ability of a single client to roll port scans should be considered by the devs.

2 1

Re: [tor-relays] Detecting Network Attack [re: exit synflooded]
by tor＠t-3.net 26 Nov '17

26 Nov '17

Well, it's still going on, and is pretty much ruining Libero :( . Running CentOS 6, here. Actually, I think from what I'm seeing that it may not exactly be a synflood targeting Libero. I think Libero may be being (ab)used to do massive portscanning or similar. Image should be visible below - it's normal statistics for the 18th through say, part of the 21st, messed up 22ed - 24th and on the 24th me trying different things in an attempt to mitigate (graph is from yesterday). Look at the SYN_SENT2 maximum. When it's happening it can look like this: # netstat -n | grep -c SYN 17696 # Also one tiny part of the netstat looked like this: tcp 0 1 64.113.32.29:33354 <external IP munged>:81 SYN_SENT tcp 0 1 64.113.32.29:39659 <external IP munged>:8888 SYN_SENT tcp 0 1 64.113.32.29:44247 <external IP munged>:87 SYN_SENT tcp 0 1 64.113.32.29:42038 <external IP munged>:8888 SYN_SENT tcp 0 1 64.113.32.29:42077 <external IP munged>:83 SYN_SENT tcp 0 1 64.113.32.29:36282 <external IP munged>:8888 SYN_SENT tcp 0 1 64.113.32.29:46023 <external IP munged>:8888 SYN_SENT Port 8888 is supposedly opened up for listen by a virus.

3 3