- tor-relays - lists.torproject.org

Fwd: Thailand block
by BRBfGWMz 28 Nov '20

28 Nov '20

What provider do you use? How much does it cost? \---------- Forwarded message ---------- From: Dr Gerard Bulger <gerard(a)bulger.co.uk> Date: On Tue, Nov 24, 2020 at 08:29 AM Subject: [tor-relays] Thailand block To: BRBfGWMz <brbfgwmz(a)concealed.company> I have been running an exit (mythaicontribution) in Thailand for 3 Years (the exit has narrow port 80 range but full 443 and all other less risky ports open. It has never been that busy as an exit, unlike my other UK and USA exits of similar profile. I noticed it was off line last week. The ISP was slow to work out what was going on, to discover that the upstream ISP has blocked the IP “due to DOS attack” I think that is unlikely for such a long block, and assume the hand of MICT. I gather the do not give reasons. (https://en.wikipedia.org/wiki/Internet_censorship_in_Thailand) In some ways surprising it took them so long. Is there a way on Tor’s web pages and data base to look at historical data. I am curious to know when it off line and removed from Tor metrics. Gerry \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online communication For everyone. https://www.msgsafe.io

2 1

Call for Testing - New Feature: Relay IPv6 Address Discovery
by David Goulet 28 Nov '20

28 Nov '20

Greetings everyone! We've very recently merged upstream (tor.git) full IPv6 supports which implies many many things. We are still finalizing the work but most of it is in at the moment. This is a call for help if anyone would like to test either git master[1] or nightly builds[2] (only Debian) to test for us a specific feature. The feature we would love for some of you to test is the IPv6 address discovery. In short, with this new feature, specifying an ORPort without an address will automatically bind tor to [::]:<port> and attempt to find the IPv6 address by looking at (in this order): 1. "Address" from torrc 2. "ORPort address:port" from torrc 3. Interface address. First public IPv6 is used. 4. Local hostname, DNS AAAA query. If all fails, the relay will simply never publish an IPv6 in the descriptor but it will work properly with the IPv4 (still mandatory). The other new thing is that now tor supports *two* "Address" statement which can be a hostname or IPv4 or IPv6 now. Thus this is now valid: Address 1.2.3.4 Address [4242::4242] ORPort 9001 Your Tor will bind to 0.0.0.0:9001 and [::]:9001 but will publish the 1.2.3.4 for the IPv4 address and [4242::4242] for IPv6 in the descriptor that is the address to use to reach your relay's ORPort. Now, if you happen to have this configuration which I believe might be common at the moment: ORPort 9001 ORPort [4242::4242]:9001 The second ORPort which specifies an IPv6 address will supersede the "ORPort 9001" which uses [::] and thus you will bind on 0.0.0.0:9001 and [4242::4242]:9001. You should get a notice log about this. Thus the recommended configuration to avoid that log notice would be to bind to specific addresses per family: ORPort <IPv4>:9001 ORPort <IPv6>:9001 And of course, if you want your relay to _not_ listen on IPv6: ORPort 9001 IPv4Only In your notice log, you will see which address is used to bind on the ORPort and then you will see the reachability test succeed or not on the address that tor either used from the configuration or auto discovered that is the address you are supposedly reachable from. Man page has NOT been updated yet, it will arrive once we stabilize the IPv6 feature and everything around it. Please, do report (on this thread) _anything_ even slightly annoying about this like logging or lack of logging and so on. This is a complex feature and errors can be made thus any testing you can offer is extremely appreciated. Thanks!! David [1] https://gitweb.torproject.org/tor.git/ [2] https://2019.www.torproject.org/docs/debian.html.en -- EeJVrrC/dHQXEXYB1ShOOZ4QuQ8PMnRY2XGq4BYsFq4=

8 12

Thailand block
by Dr Gerard Bulger 24 Nov '20

24 Nov '20

I have been running an exit (mythaicontribution) in Thailand for 3 Years (the exit has narrow port 80 range but full 443 and all other less risky ports open. It has never been that busy as an exit, unlike my other UK and USA exits of similar profile. I noticed it was off line last week. The ISP was slow to work out what was going on, to discover that the upstream ISP has blocked the IP "due to DOS attack" I think that is unlikely for such a long block, and assume the hand of MICT. I gather the do not give reasons. (https://en.wikipedia.org/wiki/Internet_censorship_in_Thailand) In some ways surprising it took them so long. Is there a way on Tor's web pages and data base to look at historical data. I am curious to know when it off line and removed from Tor metrics. Gerry

3 3

Fwd: Re: Bridges under DDoS
by William Kane 23 Nov '20

23 Nov '20

Forwarding to mailing list since OP has replied to my e-mail address, and not the list. ---------- Forwarded message ---------- From: William Kane <ttallink(a)googlemail.com> Date: Mon, 23 Nov 2020 16:07:39 +0000 Subject: Re: Re: [tor-relays] Bridges under DDoS To: BRBfGWMz <brbfgwmz(a)concealed.company> Dear BRBfGWMz, you can use this script I made a while ago - please read the entire message carefully or you risk locking yourself out of the system. Here you go: #!/bin/bash IPTABLES="/usr/sbin/iptables" # Flush all old rules and tables. $IPTABLES -F $IPTABLES -X $IPTABLES -t nat -F $IPTABLES -t nat -X # Establish default policies. $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT ACCEPT # Unconditionally allow local traffic. $IPTABLES -A INPUT -i lo -j ACCEPT # Allow already established connections. $IPTABLES -A INPUT -i <NETWORK_INTERFACE> -m state --state ESTABLISHED -j ACCEPT # Allow Tor ORPort traffic. $IPTABLES -A INPUT -i <NETWORK_INTERFACE> -p tcp --dport <YOUR_ORPORT> -j ACCEPT Note that this is for a normal Tor relay, not a bridge - for a bridge, just opening the inbound obfs4proxy port is enough, though. You will have to make adjustments, namely specifying the name of your public network interface ("ip addr" or "ifconfig", either one will work on modern distributions). Make sure to also open the port sshd, your SSH daemon, bound to or you will be locked out from the system after executing the script (!). If you are on Arch Linux, you can save the script to /etc/iptables/iptables.rules (execute the script and then run "iptables-save > /etc/iptables/iptables.rules", after that the only thing left to do is to enable the according systemd service unit to automatically load the rules on boot ("systemctl enable iptables"). If on Debian, you can specify a script to run as soon as your public network interface reaches the "up" state, directly in your network configuration. Note that this will just drop unknown incoming connections (ICMP traffic as well, so you won't be able to ping your server anymore), usually the best measure, you could also configure it to reject unknown TCP packets but this will generate additional outbound traffic (which is what an attacker might want). Please also note that if you are running a IPv6 enabled relay, you will have to use ip6tables instead of iptables - you will also have to allow all incoming ICMPv6 traffic through ip6tables, with plain IPv4 you don't really need to allow ICMP packets, with IPv6, it's absolutely required. Hope I helped, never be afraid to ask questions, I am here to help. 2020-11-22 21:12 GMT, BRBfGWMz <brbfgwmz(a)concealed.company>: > Are the locations for the relays that are set up during the process of > setting > up relays for a single machine truely random (or pseudorandom), or is there > any dependence on the ip/location of my desktop? > > On Tue, Nov 17, 2020 at 08:48 AM, William Kane <ttallink(a)googlemail.com> > wrote: > >> If your server is not responding, no harm done (likely already done if > >> you have iptables set up to drop unknown (established flag not set) > >> incoming traffic.). > >> > >> If it's somehow maxing out your connection speed, then time to talk to > >> your upstream provider / hosting company - very likely they already > >> have anti dos equipment on their network, and many would just re-route > >> a customer through it until the attack stops, but it might cost you > >> some money. > >> > >> 2020-11-13 17:03 GMT, Jonas <jonasdietrich(a)ctemplar.com>: > >> > According to packetflow traces, roughly 26,000 unique IPv4 from 85 >> countries > >> > executing a SYN flood attack on TCP/9001. None of my bridges have 9001 >> open > >> > nor respond to this port. The attacks continue to this day. > >> > > >> > Danke. > >> > > >> > Jonas > >> > _______________________________________________ > >> > tor-relays mailing list > >> > tor-relays(a)lists.torproject.org > >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >> > > >> _______________________________________________ > >> tor-relays mailing list > >> tor-relays(a)lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >> > > \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online > communication > For everyone. https://www.msgsafe.io > > >

1 0

Bridges under DDoS
by Jonas 14 Nov '20

14 Nov '20

Grüezi, Over the past seven days, all of my bridges are under DDoS attack. Other servers hosted with adjacent IP addresses are not under attack. Any one else seeing such attacks lately? Curious that all of my bridges are under attack, meaning someone altogether knows they exist. Thanks.

4 4

Re: [tor-relays] tor-relays Digest, Vol 118, Issue 16
by Mark Murray 13 Nov '20

13 Nov '20

I've been getting emails from OVH about "Detection of an attack" on my relays, it happened very occasionally but has been a bit more frequent recently. Anything I could/should do? Also is my first time replying to a mailing list ever, hopefully I replied to the right address? On 13/11/2020 12:00, tor-relays-request(a)lists.torproject.org wrote: > 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: So my relay is apparently being attacked (Will Shackleton) > 2. Re: So my relay is apparently being attacked (Keifer Bly) > 3. Re: So my relay is apparently being attacked (Anders Burmeister) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 12 Nov 2020 19:16:25 +0000 > From: "Will Shackleton" <w.shackleton(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] So my relay is apparently being attacked > Message-ID: <3c5ee106-6233-4086-bd35-a445e8e6383e(a)www.fastmail.com> > Content-Type: text/plain > > My non-exit relays are being DDoS'ed too - I've received similar emails from my hosting provider. > > https://metrics.torproject.org/rs.html#search/family:B42C797CC8CD63C60FB643… > > -Will > > On Thu, 12 Nov 2020, at 7:09 PM, Roman Mamedov wrote: >> On Thu, 12 Nov 2020 10:52:47 -0800 >> Keifer Bly <keifer.bly(a)gmail.com> wrote: >> >>> I am wondering, are relays being ddosed a normal thing? Thank you. >>> --Keifer >> DDoS'ing opponents in an argument is common on some IRC networks, so it could >> have to do with the IRC exiting that you allow. >> >> I don't remember relays on their own getting DDoS'ed in years, but could >> remember a couple of cases of DDoS which could be correlated to IRC >> discussions I participated in right prior to that. >> >> -- >> With respect, >> Roman >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > ------------------------------ > > Message: 2 > Date: Thu, 12 Nov 2020 17:26:49 -0800 > From: Keifer Bly <keifer.bly(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] So my relay is apparently being attacked > Message-ID: > <CADqUGAO5udgNs6TF=McZemdRBLYVCXodcsi5RW0-PpbjZhXXnw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Thanks all. > --Keifer > > > On Thu, Nov 12, 2020 at 11:56 AM Will Shackleton <w.shackleton(a)gmail.com> > wrote: > >> My non-exit relays are being DDoS'ed too - I've received similar emails >> from my hosting provider. >> >> >> https://metrics.torproject.org/rs.html#search/family:B42C797CC8CD63C60FB643… >> >> -Will >> >> On Thu, 12 Nov 2020, at 7:09 PM, Roman Mamedov wrote: >>> On Thu, 12 Nov 2020 10:52:47 -0800 >>> Keifer Bly <keifer.bly(a)gmail.com> wrote: >>> >>>> I am wondering, are relays being ddosed a normal thing? Thank you. >>>> --Keifer >>> DDoS'ing opponents in an argument is common on some IRC networks, so it >> could >>> have to do with the IRC exiting that you allow. >>> >>> I don't remember relays on their own getting DDoS'ed in years, but could >>> remember a couple of cases of DDoS which could be correlated to IRC >>> discussions I participated in right prior to that. >>> >>> -- >>> With respect, >>> Roman >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >

1 0

So my relay is apparently being attacked
by Keifer Bly 13 Nov '20

13 Nov '20

Hi, So twice this week I've gotten this email from OVH: Dear Customer, We have just detected an attack on IP address 51.68.197.220. In order to protect your infrastructure, we vacuumed up your traffic onto our mitigation infrastructure. The entire attack will thus be filtered by our infrastructure, and only legitimate traffic will reach your servers. At the end of the attack, your infrastructure will be immediately withdrawn from the mitigation. For more information on the OVH mitigation infrastructure: http://www.ovh.com/world/anti-ddos/ Regarding the relay at https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… I am wondering, are relays being ddosed a normal thing? Thank you. --Keifer

6 7

Re: [tor-relays] Bridges under DDoS
by rush23＠gmx.net 12 Nov '20

12 Nov '20

1 0

Cheap Servers? There MUST be a catch
by Dr Gerard Bulger 10 Nov '20

10 Nov '20

Worried about dominance of OVH for relays and exits? How about Google! Setting up a fast server is SO cheap on their https://cloud.google.com/ platform, it is tempting to set up relays, if not exits there. Looking at their T&Cs they do not seem to mention TOR or banning running a proxy, but a generic list of don't do bad things. I have two ubuntu servers doing running other programmes on there now, and so far cost me $0.78 with fixed IP4 addresses. I have not worked out how to attach IPv6 yet. Of course set DNS of the machines not to be Google's So tell me why this is such a bad idea. Gerry

6 5

A way to reduce spam and brute attacks...
by rush23＠gmx.net 10 Nov '20

10 Nov '20

Hello guys, is there any way to stop or if not reduce the spam, brute force attacks that are leaving my exit? Well port blocking or destination IP blocking is one way but without any relevant information except this hard, right? => https://cleantalk.org/blacklists/51.15.80.14 Stopped my exit for about 2-3 weeks awaiting lower number of complaints but nothing changed. In the end I have to migrate from exit to relay unfortunately. Regards Torproxy

2 1