tor-relays

tor-relays@lists.torproject.org

38 participants
4819 discussions

90% of exits vulnerable to TCP off-path attack
by starlight.2016q3＠binnacle.cx 12 Aug '16

12 Aug '16

[second try here for clean DKIM authentication] [listsrv added a two spaces instead of one] RFC-5961 CVE-2016-5696 http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_comm… FYI all

1 2

Out of memory: Kill process (tor)
by Tristan 12 Aug '16

12 Aug '16

Last night I received my first abuse complaint on DigitalOcean. When I logged in, I saw Tor was no longer running because the system ran out of memory. Is it possible the system ran out of memory because of the abuse? My relay has 512MB of RAM running Tor and Unbound, and it's been running fine all month. How can I prevent this memory issue from happening in the future? Thanks -- Finding information, passing it along. ～SuperSluether

2 1

running a relay on a pi/pi2 and it stopped working after upgrading to 0.2.8.6/0.2.8.6-2 ? read this (bugfix)
by Hack-Tic 10 Aug '16

10 Aug '16

Hi, I ran into some tor restart loop issues after upgrading to 0.2.8.6 on my pi2 relay. In short, it takes too long to read router_parse_list_from_string and hits the systemd start timeout limit causing a restart (and loop) Full story in the ticket here: https://trac.torproject.org/projects/tor/ticket/19819 quick fix: edit /lib/systemd/system/tor(a)default.service and change TimeoutStartSec= from 120 to 300 Hope i'm not "spamming" the list, just trying to help. Have a good one.

4 4

DoS on my non-exit relay? Or just oversensitive DoS "protection"?
by Sebastian Niehaus 10 Aug '16

10 Aug '16

Hi, The provider of my non-exit "silentrocket" told me they temporarily disconnected the server from their network because of a DoS attack against the machine. https://atlas.torproject.org/#details/7A32C9519D80CA458FC8B034A28F5F6815649… They sent me some details of what they think is a DoS attack (date and time omitted ...): ########################################### Attack type: DoS_IN Attacked IP: 82.223.21.74 ########################################### Source Address Source Port Destination Address Destination Port Frames 193.171.202.146 TCP:9001 82.223.21.74 TCP:61078 21440736 176.10.104.243 TCP:443 82.223.21.74 TCP:25817 11203344 185.29.8.132 TCP:443 82.223.21.74 TCP:56708 8160360 58.58.170.2 TCP:443 82.223.21.74 TCP:61980 7840824 144.76.14.145 TCP:143 82.223.21.74 TCP:19866 6240664 195.154.209.91 TCP:443 82.223.21.74 TCP:20229 4808568 192.42.113.102 TCP:9001 82.223.21.74 TCP:62658 4328568 83.146.80.152 TCP:39898 82.223.21.74 TCP:9001 3041584 87.98.162.251 TCP:443 82.223.21.74 TCP:60948 2240040 188.138.9.49 TCP:9001 82.223.21.74 TCP:13349 2240000 93.145.122.187 TCP:60469 82.223.21.74 TCP:9001 1920016 104.236.92.66 TCP:1337 82.223.21.74 TCP:48838 1760248 5.248.227.163 TCP:9001 82.223.21.74 TCP:28976 1760240 109.104.12.92 TCP:9001 82.223.21.74 TCP:15808 1601224 46.101.237.246 TCP:9001 82.223.21.74 TCP:18393 1600784 212.47.239.187 TCP:443 82.223.21.74 TCP:6669 1600000 212.117.180.130 TCP:443 82.223.21.74 TCP:37114 1440000 37.187.17.67 TCP:38547 82.223.21.74 TCP:9001 1281176 37.157.193.107 TCP:49192 82.223.21.74 TCP:9001 804896 193.11.164.243 TCP:9001 82.223.21.74 TCP:62265 800040 I am not sure whether it really looks like a DoS attack or if is just many "normal" tor packets hammering on the small server which are misunderstood as a DoS. They are coming from a remote's maschines tor port and going to some random port om my server suggesting the packets are simply a reply to some connection my server opened. The server ran fine for several months but now I get a disconnection notice several times a day. Maybe there is really a DoS, maybe their automatic DoS protection reacts too fast, maybe they are just fed up with the traffic the relay causes and want to make things hard for me. Do you have any (educated) guesses what might be going on here? Thank you very much, Sebastian

2 2

Unsubscribe
by Jeremy 09 Aug '16

09 Aug '16

Unsub Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. -------- Original Message -------- Subject: tor-relays Digest, Vol 67, Issue 22 Local Time: August 8, 2016 2:00 AM UTC Time: August 8, 2016 12:00 PM From: tor-relays-request(a)lists.torproject.org To: tor-relays(a)lists.torproject.org Send tor-relays mailing list submissions to tor-relays(a)lists.torproject.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays or, via email, send a message with subject or body 'help' to tor-relays-request(a)lists.torproject.org You can reach the person managing the list at tor-relays-owner(a)lists.torproject.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tor-relays digest..." Today's Topics: 1. Re: tor-relays Digest, Vol 67, Issue 12 (grarpamp) 2. Re: is explicit DirPort needed anymore under Tor 0.2.8.6? (teor) 3. Re: [PATCH] debian package upgrade restart issue (nusenu) ---------------------------------------------------------------------- Message: 1 Date: Mon, 8 Aug 2016 01:40:59 -0400 From: grarpamp <grarpamp(a)gmail.com> To: tor-relays(a)lists.torproject.org Cc: flipchan(a)riseup.net Subject: Re: [tor-relays] tor-relays Digest, Vol 67, Issue 12 Message-ID: <CAD2Ti2-2R0KE+KA6EkMwVftA8G8Bi9OV4sYr0k=a-5CD=WeFtg(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On 8/5/16, Flipchan <flipchan(a)riseup.net> wrote: > [bad netiquette] When replying to digests... - At minimum, change the subject to the original subject. Optimally also include proper header threading. Repliers should subscribe to per message distribution instead. - Delete all content from the original except some minimum needed to establish context to which you are replying, instead of spamming out longquotes of already said longtext. - Reply inline below each piece of context to which you are replying, instead of top posting. ------------------------------ Message: 2 Date: Mon, 8 Aug 2016 17:33:42 +1000 From: teor <teor2345(a)gmail.com> To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] is explicit DirPort needed anymore under Tor 0.2.8.6? Message-ID: <6AABDA0A-4835-4B2C-A60D-A7A64568BE65(a)gmail.com> Content-Type: text/plain; charset="utf-8" > On 3 Aug 2016, at 10:29, teor <teor2345(a)gmail.com> wrote: > > Clients on 0.2.7.6 and earlier still use the IPv4 DirPort. > (Tor Browser is still 0.2.7.6, and apps in general may take some time to upgrade.) > > Authorities on0.2.7.6 and earlier will only assign the HSDir flag to relays with an IPv4 DirPort. > (Authorities may take some time to upgrade, because running different versions increases authority diversity.) For the record, even though the man page entry for HidServDirectoryV2 says the DirPort is not required to be a HSDir, authorities on 0.2.7 and earlier still check for it before assigning the HSDir flag. Authorities on 0.2.8 and later behave in a way that's consistent with HidServDirectoryV2, assigning the HSDir flag to any relay that wants to be a HSDir, and either supports being a directory cache, or has a DirPort. HidServDirectoryV2 0|1 When this option is set, Tor accepts and serves v2 hidden service descriptors. Setting DirPort is not required for this, because clients connect via the ORPort by default. (Default: 1) > Fallback directory mirrors must have a DirPort, and we'd only think about changing that when: > * all recommended relay versions are 0.2.8 and later, and > * relays no longer fetch documents using the DirPort (so maybe never). > > All relays running any Tor version will continue to use the IPv4 DirPort to fetch consensuses from other relays. > > So we haven't obsoleted the IPv4 DirPort yet. We've just made sure that clients fetch directory documents over an encrypted channel. Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org

2 1

is explicit DirPort needed anymore under Tor 0.2.8.6?
by Green Dream 08 Aug '16

08 Aug '16

The release notes for Tor 0.2.8.6 have this tidbit about the DirPort: "Previously only relays that explicitly opened a directory port (DirPort) accepted directory requests from clients. Now all relays, with and without a DirPort, accept and serve tunneled directory requests that they receive through their ORPort. You can disable this behavior using the new DirCache option. Closes ticket 12538." With this new behavior, is there any reason to keep an open DirPort on our relays? If I just use an ORPort on 443 (or another reachable TCP port) is this sufficient? Might it make sense to leave the DirPort up for a while for legacy clients? Will (up-to-date) authorities have any concerns with a ORPort-only relay? Thanks.

5 7

Re: [tor-relays] tor-relays Digest, Vol 67, Issue 12
by Flipchan 08 Aug '16

08 Aug '16

I would recommend port knocking if u run ssh tor-relays-request(a)lists.torproject.org skrev: (4 augusti 2016 19:30:11 CEST) >Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > >You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of tor-relays digest..." > > >Today's Topics: > > 1. Re: tor-relays Digest, Vol 67, Issue 11 (Flipchan) > 2. Re: Exit relay funding (I) > 3. Re: Exit relay funding (Petrusko) > 4. Re: Any security tips on running a TOR relay? (Green Dream) > 5. Re: Any security tips on running a TOR relay? (Tristan) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 04 Aug 2016 14:51:35 +0200 >From: Flipchan <flipchan(a)riseup.net> >To: tor-relays(a)lists.torproject.org >Subject: Re: [tor-relays] tor-relays Digest, Vol 67, Issue 11 >Message-ID: <A571C798-B2DE-4A1C-B2CA-EB58353A0D72(a)riseup.net> >Content-Type: text/plain; charset="utf-8" > >Auto update with cron, audit it like a normal server > >tor-relays-request(a)lists.torproject.org skrev: (4 augusti 2016 14:00:07 >CEST) >>Send tor-relays mailing list submissions to >> tor-relays(a)lists.torproject.org >> >>To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>or, via email, send a message with subject or body 'help' to >> tor-relays-request(a)lists.torproject.org >> >>You can reach the person managing the list at >> tor-relays-owner(a)lists.torproject.org >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of tor-relays digest..." >> >> >>Today's Topics: >> >> 1. Re: experiences with debian tor 0.2.8.6 package from >> deb.torproject.org (tor relay) >> 2. Any security tips on running a TOR relay? (Andrew) >> 3. Re: Exit relay funding (Petrusko) >> 4. Re: experiences with debian tor 0.2.8.6 package from >> deb.torproject.org (Peter Palfrader) >> >> >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Thu, 4 Aug 2016 08:01:32 +0200 (CEST) >>From: tor relay <torrelay3(a)mailbox.org> >>To: tor-relays(a)lists.torproject.org >>Subject: Re: [tor-relays] experiences with debian tor 0.2.8.6 package >> from deb.torproject.org >>Message-ID: <249633305.6901.1470290492290(a)office.mailbox.org> >>Content-Type: text/plain; charset="utf-8" >> >>https://trac.torproject.org/projects/tor/ticket/19825 >>

2 1

minor typos in tor-instance-create
by tor relay 07 Aug '16

07 Aug '16

https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-creat… is: systemctl tor@$name start should be: systemctl start tor@$name mailto:tor@$name https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-creat… brdige -> bridge

2 2

tor-instance-create users: beware all your instances are always started
by tor relay 07 Aug '16

07 Aug '16

This is only relevant for debian users. If you assume you can manage your instances with the usual systemctl commands like systemctl disable/enable tor@myinstance beware that they have no effect. Note: systemctl start/stop works as expected. This is important to know especially if you have multiple configurations and want to enable/disable some of them to avoid running them concurrently. I don't know the reasoning behind that design decision but all your instances are enabled due to [1], you cannot use the well known systemctl disable command like systemctl disable tor@myinstance to disable a specific instance. If you want to disable them you can use the 'mask' command: systemctl mask tor@myinstance this is less convenient because this way you wont be able to run systemctl start tor@myinstance (on a masked unit) or move configuration files away (also less convenient than native disable/enable) [1] https://gitweb.torproject.org/debian/tor.git/tree/debian/systemd/tor-genera…

1 0

debian: log messages when upgrading tor package
by tor relay 05 Aug '16

05 Aug '16

When upgrading the tor package on debian I get the following syslog messages: systemd[1]: Failed to reset devices.list on /system.slice: Invalid argument systemd[1]: Failed to reset devices.list on /system.slice/system-tor.slice: Invalid argument Should I be concerned?

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays