Re: [tor-relays] DDoS’d offline
Update from our upstream— “It was hitting each IP in the /24. Here's the history of the attacks and when they first started. We didn't see much for a couple of days, then all the IPs got lit up simultaneously. The attack seems to have come mostly from Eastern Europe/Russia.” 2019-08-14 05:10:55 -0700 23.129.64.154 1686 mbps 2019-08-18 04:21:41 -0700 23.129.64.207 1554 mbps 2019-08-23 02:47:57 -0700 23.129.64.200 15888 mbps 2019-08-23 22:42:38 -0700 23.129.64.162 10301 mbps 2019-08-25 19:11:46 -0700 23.129.64.183 2521 mbps 2019-08-26 09:10:21 -0700 23.129.64.151 7887 mbps 2019-08-27 15:47:06 -0700 23.129.64.213 3534 mbps 2019-08-28 06:08:28 -0700 23.129.64.216 7477 mbps 2019-08-30 01:25:53 -0700 23.129.64.152 1987 mbps 2019-09-06 10:37:28 -0700 23.129.64.161 1676 mbps 2019-09-11 14:53:07 -0700 23.129.64.162 26970 mbps 2019-09-15 11:05:54 -0700 23.129.64.102 1227 mbps 2019-09-24 14:58:30 -0700 23.129.64.168 2104 mbps 2019-09-28 13:01:21 -0700 23.129.64.156 5646 mbps 2019-09-28 17:30:33 -0700 23.129.64.182 2141 mbps 2019-09-29 23:36:35 -0700 23.129.64.201 2187 mbps 2019-10-03 03:51:08 -0700 23.129.64.161 2504 mbps 2019-10-05 17:21:26 -0700 23.129.64.161 1610 mbps 2019-10-05 17:49:05 -0700 23.129.64.195 3020 mbps 2019-10-06 11:17:05 -0700 23.129.64.193 7043 mbps 2019-10-15 09:28:19 -0700 23.129.64.212 1624 mbps 2019-10-19 22:15:05 -0700 23.129.64.207 9468 mbps 2019-10-27 00:47:17 -0700 23.129.64.211 2367 mbps 2019-10-28 09:19:22 -0700 23.129.64.182 1811 mbps 2019-10-28 16:31:13 -0700 23.129.64.190 2525 mbps 2019-10-30 11:58:51 -0700 23.129.64.2 1235 mbps 2019-10-30 11:58:51 -0700 23.129.64.101 1313 mbps 2019-10-30 11:58:51 -0700 23.129.64.107 1347 mbps 2019-10-30 11:58:51 -0700 23.129.64.109 1184 mbps 2019-10-30 11:58:51 -0700 23.129.64.111 1326 mbps 2019-10-30 11:58:51 -0700 23.129.64.117 1374 mbps 2019-10-30 11:58:51 -0700 23.129.64.121 1132 mbps 2019-10-30 11:58:51 -0700 23.129.64.124 1336 mbps 2019-10-30 11:58:51 -0700 23.129.64.129 1390 mbps 2019-10-30 11:58:51 -0700 23.129.64.132 1239 mbps 2019-10-30 11:58:51 -0700 23.129.64.136 1179 mbps 2019-10-30 11:58:51 -0700 23.129.64.138 1268 mbps 2019-10-30 11:58:51 -0700 23.129.64.141 1351 mbps 2019-10-30 11:58:51 -0700 23.129.64.143 1214 mbps 2019-10-30 11:58:51 -0700 23.129.64.151 1335 mbps 2019-10-30 11:58:51 -0700 23.129.64.159 1161 mbps 2019-10-30 11:58:51 -0700 23.129.64.174 1206 mbps 2019-10-30 11:58:51 -0700 23.129.64.175 1386 mbps 2019-10-30 11:58:51 -0700 23.129.64.179 1159 mbps 2019-10-30 11:58:51 -0700 23.129.64.188 1237 mbps 2019-10-30 11:58:51 -0700 23.129.64.192 1445 mbps 2019-10-30 11:58:51 -0700 23.129.64.201 1100 mbps 2019-10-30 11:58:51 -0700 23.129.64.204 1083 mbps 2019-10-30 11:58:51 -0700 23.129.64.214 1340 mbps 2019-10-30 11:58:51 -0700 23.129.64.217 1750 mbps 2019-10-30 11:58:51 -0700 23.129.64.218 1453 mbps 2019-10-30 11:58:51 -0700 23.129.64.223 1162 mbps 2019-10-30 11:58:52 -0700 23.129.64.225 1327 mbps 2019-10-30 11:58:52 -0700 23.129.64.233 1250 mbps 2019-10-30 11:58:52 -0700 23.129.64.240 1081 mbps 2019-10-30 11:58:52 -0700 23.129.64.12 1429 mbps 2019-10-30 11:58:52 -0700 23.129.64.19 1394 mbps 2019-10-30 11:58:52 -0700 23.129.64.18 1317 mbps 2019-10-30 11:58:52 -0700 23.129.64.22 1682 mbps 2019-10-30 11:58:52 -0700 23.129.64.26 1292 mbps 2019-10-30 11:58:52 -0700 23.129.64.27 1313 mbps 2019-10-30 11:58:52 -0700 23.129.64.24 1198 mbps 2019-10-30 11:58:52 -0700 23.129.64.29 1361 mbps 2019-10-30 11:58:52 -0700 23.129.64.35 1237 mbps 2019-10-30 11:58:52 -0700 23.129.64.39 1373 mbps 2019-10-30 11:58:52 -0700 23.129.64.41 1287 mbps 2019-10-30 11:58:52 -0700 23.129.64.43 1377 mbps 2019-10-30 11:58:52 -0700 23.129.64.44 1267 mbps 2019-10-30 11:58:52 -0700 23.129.64.48 1343 mbps 2019-10-30 11:58:52 -0700 23.129.64.71 1273 mbps 2019-10-30 11:58:52 -0700 23.129.64.72 1633 mbps 2019-10-30 11:58:52 -0700 23.129.64.77 1191 mbps 2019-10-30 11:58:52 -0700 23.129.64.80 1243 mbps 2019-10-30 11:58:52 -0700 23.129.64.82 1190 mbps 2019-10-30 11:58:52 -0700 23.129.64.98 1289 mbps 2019-10-30 11:58:52 -0700 23.129.64.3 1243 mbps 2019-10-30 11:58:52 -0700 23.129.64.105 1201 mbps 2019-10-30 11:58:52 -0700 23.129.64.110 1422 mbps 2019-10-30 11:58:52 -0700 23.129.64.115 1562 mbps 2019-10-30 11:58:52 -0700 23.129.64.128 1263 mbps 2019-10-30 11:58:52 -0700 23.129.64.131 1131 mbps 2019-10-30 11:58:52 -0700 23.129.64.146 1164 mbps 2019-10-30 11:58:52 -0700 23.129.64.176 1168 mbps 2019-10-30 11:58:52 -0700 23.129.64.187 1233 mbps 2019-10-30 11:58:52 -0700 23.129.64.198 1269 mbps 2019-10-30 11:58:52 -0700 23.129.64.28 1298 mbps 2019-10-30 11:58:52 -0700 23.129.64.45 1221 mbps 2019-10-30 11:58:52 -0700 23.129.64.62 1444 mbps 2019-10-30 11:58:52 -0700 23.129.64.96 1215 mbps 2019-10-30 11:58:53 -0700 23.129.64.31 1228 mbps 2019-10-30 11:58:53 -0700 23.129.64.0 1323 mbps 2019-10-30 11:58:53 -0700 23.129.64.7 1206 mbps 2019-10-30 11:58:53 -0700 23.129.64.173 1555 mbps 2019-10-30 11:58:53 -0700 23.129.64.185 1257 mbps 2019-10-30 11:58:53 -0700 23.129.64.203 1226 mbp
Re: [tor-relays] DDoS’d offline
Christopher Sheats writes: > fyi > > https://twitter.com/EmeraldOnion/status/1189668679752900608 > > Calyx appears to have been hit also, but not offline > > https://twitter.com/calyxinstitute/status/1189693027192840192 > Thanks for letting us know. Did you experience any interesting log messages at the time of the DoS? Just want to make sure it's not exploiting any protocol mechanisms. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Issues reaching gigabit relay speeds
On 10/30/19 16:30, Mitar wrote: > Hi! > > I have a gigabit connection and I am trying to utilize it as much as > possible as a Tor relay. When I try various speed tests I get on the > machine speeds close to gigabit, but when running Tor, I do not > achieve anything close to it. I even started two Tor nodes on the same > machine/connection, see here: > > https://metrics.torproject.org/rs.html#details/567E9785458C605E59202755C74898E3C96FB1CC > https://metrics.torproject.org/rs.html#details/4CF9BAEB0DE6D7230D6B7DA0FF420C7CFD863885 > > The utilization of the machine is pretty low, top returns: > > top - 20:27:33 up 4 days, 23:01, 1 user, load average: 0.32, 0.28, 0.23 > Tasks: 167 total, 1 running, 97 sleeping, 0 stopped, 0 zombie > %Cpu(s): 1.6 us, 0.6 sy, 0.0 ni, 97.3 id, 0.0 wa, 0.0 hi, 0.5 si, 0.0 > st > KiB Mem : 3772912 total, 931336 free, 1574676 used, 1266900 buff/cache > KiB Swap: 3900412 total, 3900412 free,0 used. 1915568 avail Mem > > In configuration I have: > > RelayBandwidthRate 125 MB > RelayBandwidthBurst 125 MB > > Interesting is that it seems each Tor daemon on same machine runs > always around 5 MiB/s, when I started the second one, it just added to > it with another 5 MiB/s. So it is somewhere else where is the > bottleneck? > > What could I do to improve things here? To me it looks like more > throughput should be possible? > > > Mitar > You've done everything correctly. Well ... setting RBR and RBB was probably unnecessary, but it's fine. The problem isn't on your end, if there's even a problem. - In an ideal world you won't get more load than your fair share. Consider a hypothetically large Tor network with loads of high-capacity relays. Every relay may be capable of 1 Gbps but only see 10 Mbps, yet there is absolutely no problem. - That's not to say the current network is anything like this. It's true exits are the bottleneck right now, but maybe you should expect more traffic as a non-exit. - Relays get measured by bandwidth authorities and then load is balanced across the network based on their measurements. The whole bandwidth measuring system is a complex mess that produces confusing and unsatisfying results. Maybe you've gotten unlucky here. - It's not ideal to be going full tilt all the time. You want to have some headroom for bursts without causing congestion. Obviously you aren't even close to that yet. Thanks for running Tor relays. Sorry I don't have satisfying answers. Please stick with it and avoid worrying too much about the specific numbers :) -- Matt ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Issues reaching gigabit relay speeds
Just to second Matt's answer - I am running a relay in Moldova that's clocked at an average of 26 Mbit/s this month. In June it had a peak month of 35 Mbit/s. Your relay throughput looks very normal to me. --Torix Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, October 30, 2019 4:30 PM, Mitar wrote: > Hi! > > I have a gigabit connection and I am trying to utilize it as much as > possible as a Tor relay. When I try various speed tests I get on the > machine speeds close to gigabit, but when running Tor, I do not > achieve anything close to it. I even started two Tor nodes on the same > machine/connection, see here: > > https://metrics.torproject.org/rs.html#details/567E9785458C605E59202755C74898E3C96FB1CC > https://metrics.torproject.org/rs.html#details/4CF9BAEB0DE6D7230D6B7DA0FF420C7CFD863885 > > The utilization of the machine is pretty low, top returns: > > top - 20:27:33 up 4 days, 23:01, 1 user, load average: 0.32, 0.28, 0.23 > Tasks: 167 total, 1 running, 97 sleeping, 0 stopped, 0 zombie > %Cpu(s): 1.6 us, 0.6 sy, 0.0 ni, 97.3 id, 0.0 wa, 0.0 hi, 0.5 si, 0.0 st > KiB Mem : 3772912 total, 931336 free, 1574676 used, 1266900 buff/cache > KiB Swap: 3900412 total, 3900412 free, 0 used. 1915568 avail Mem > > In configuration I have: > > RelayBandwidthRate 125 MB > RelayBandwidthBurst 125 MB > > Interesting is that it seems each Tor daemon on same machine runs > always around 5 MiB/s, when I started the second one, it just added to > it with another 5 MiB/s. So it is somewhere else where is the > bottleneck? > > What could I do to improve things here? To me it looks like more > throughput should be possible? > > Mitar > > - > > http://mitar.tnode.com/ > https://twitter.com/mitar_m > > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Issues reaching gigabit relay speeds
Hi! On Thu, Oct 31, 2019 at 6:21 AM Matt Traudt wrote: > - In an ideal world you won't get more load than your fair share. > Consider a hypothetically large Tor network with loads of high-capacity > relays. Every relay may be capable of 1 Gbps but only see 10 Mbps, yet > there is absolutely no problem. Thank you. Yes, I understand that if there is more capacity then the load will be not fully saturate the available capacity. So it might be simply that there are so much relays but not enough exits. Then my question is different: how could I test and assure that my nodes are able to utilize full gigabit if such demand would be required? So that I can assure that they are ready and available? And that there is not some other bottleneck somewhere on nodes themselves? Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] The Onion Box v19.2: Dashboard to monitor Tor node operations
Hello Matt, thank you for this question. For a share of the information displayed you are right. This is due to the fact that the metrics page and The Onion Box both display data from Onionoo. The relevant difference yet is that the Box attaches to the node to monitor it, whereas the metrics view is based on data that the node releases to the Tor network. As there's no demand for the Box to ensure anonymity (the dashboard is - usually - operated by s/o trustful), it does display as well enhanced and more detailled data that metrics shall not distribute. Thus the Box shows - as some examples - the configuration data of the node (as the node understood it), a live view of the up-/downloaded bandwidth (resolution 1/s vs 1/24h @ metrics), the messages that the node emits - and provides a mean to switch message levels with just one click. Some of those data - perhaps even all of it - may be found somewhere ... and the Box does what a dashboad does: It displays information from different sources in context for easier access - to support analysis and understanding. The ControlCenter creates an even more focused survey and allows (family) operators to verify the healthyness of a number of nodes (of his / her family) on a single page - displaying for each node e.g. live bandwith data and the status flags, as well as giving access to the detail dashboard (if necessary in case of trouble). I don't think this is a feature elsewhere available in the Tor universe. I yet know that these words just express my personal opinion. If you still have concerns I'd be happy to discuss with you - perhaps off list - what you would demand to get additonal value from an Onion Box. Greetings, Ralph Gesendet: Donnerstag, 31. Oktober 2019 um 01:16 Uhr Von: "ECAN - Matt Westfall" An: tor-relays@lists.torproject.org, "Tor Relay Mailinglist" Betreff: Re: [tor-relays] The Onion Box v19.2: Dashboard to monitor Tor node operations As far as I can tell, this just gives you a graphical representation of the data available from metrics.torproject.. which already has graphs... I'm confused. Can you elaborate as to why someone should look into running this? Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: theonion...@gmx.com To: "Tor Relay Mailinglist"Sent: 10/30/2019 5:39:10 PM Subject: [tor-relays] The Onion Box v19.2: Dashboard to monitor Tor node operations Good evening to the list! It's been a while since you've heard news about The Onion Box. This was due to the fact that I spent some time to implement the ControlCenter, as ability to monitor several (better: as many as you like) Tor nodes in parallel. This picture gives you an impression of a ControlCenter in action. The latest version is still labeled 'beta', yet seems stable enough to be released for broader testing. Documentation is not finalized so far, but I'm convinced it is supportive enough to lead you over the low hurdles to setup your box. To upgrade your installation via pip, please use 'pip install theonionbox==19.2b3 --upgrade' ... as it would otherwise still pull the latest stable release (v4.3.1). Please note that the support for Python 2 was dropped, so you have to use Python 3.6 or higher to operate your Onion Box. Any feedback ist highly appreciated. Enjoy! Greetings, Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] First time configuring a bridge - no log - doesnt work
Hi, I want to configure a tor obfs4 bridge on a raspberry pi 3B+. My system is Kali Linux. I followed this documentation: https://community.torproject.org/relay/setup/bridge/debian-ubuntu/ Actually, when i want to check the log in /var/log/tor, the folder is empty. TOr is running but nothing happens. here's my torrc file : RunAsDaemon 1 BridgeRelay 1 Log notice file /var/log/tor/notices.log Log debug file /var/log/tor/debug.log Log notice syslog Log debug stderr # Replace "TODO1" with a Tor port of your choice. This port must be externally # reachable. Avoid port 9001 because it's commonly associated with Tor and # censors may be scanning the Internet for this port. ORPort 4433 ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy # Replace "TODO2" with an obfs4 port of your choice. This port must be # externally reachable and must be different from the one specified for ORPort. # Avoid port 9001 because it's commonly associated with # Tor and censors may be scanning the Internet for this port. ServerTransportListenAddr obfs4 0.0.0.0:1234 # Local communication port between Tor and obfs4. Always set this to "auto". # "Ext" means "extended", not "external". Don't try to set a specific port number, nor listen on 0.0.0.0. ExtORPort auto # Replace "" with your email address so we can contact you if there are problems with your bridge. # This is optional but encouraged. ContactInfo # # Pick a nickname that you like for your bridge. This is optional. Nickname RageAgainstTheMachine ExitPolicy reject *:* I've tried to check everything but i can't find why it doesn't work. Any help / advice would be appreciated. Sent with [ProtonMail](https://protonmail.com) Secure Email.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Issues reaching gigabit relay speeds
Hi, > On 1 Nov 2019, at 02:44, Mitar wrote: > > On Thu, Oct 31, 2019 at 6:21 AM Matt Traudt wrote: >> - In an ideal world you won't get more load than your fair share. >> Consider a hypothetically large Tor network with loads of high-capacity >> relays. Every relay may be capable of 1 Gbps but only see 10 Mbps, yet >> there is absolutely no problem. > > Thank you. Yes, I understand that if there is more capacity then the > load will be not fully saturate the available capacity. So it might be > simply that there are so much relays but not enough exits. > > Then my question is different: how could I test and assure that my > nodes are able to utilize full gigabit if such demand would be > required? So that I can assure that they are ready and available? And > that there is not some other bottleneck somewhere on nodes themselves? Most tor instances are limited to 200-400 Mbps, because tor is only partly multithreaded. So you may need to run 3-4 instances to max out a gigabit. You can run chutney in bandwidth testing mode, to get an idea of the CPU and RAM limits on your relay: https://gitweb.torproject.org/chutney.git/tree/README#n98 You might need to adjust CHUTNEY_DATA_BYTES depending on the speed of your machine. The speed may also be limited by chutney's ability to send traffic. If you want to test network speed, you can configure a tor client with: EntryNodes And then download a few very large files at the same time. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays