Re: [tor-relays] R: Re: Request for Feedback on Relay Node Update Management
You should tweak your web server as presented in this section: https://github.com/Enkidu-6/tor-ddos?tab=readme-ov-file#first-step-prep aring-your-system-for-high-number-of-connections This would most likely solve Out-Of-Memory problems I suspect you are experiencing. Denny On 04/02/2024 10:06 AM Alessandro Greco via tor-relays wrote .. My computer has: - 1 vCore CPU - 1 GB RAM - Maximum bandwidth: 1 GB/s So if I understand correctly, the problem should not be at the hardware level, right? Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays <[1]tor-relays@lists.torproject.org> ha scritto: Hello Aleff, That is up to you. I strongly suspect that the hardware is the bottleneck, but detailed specifications are required in order to determine a conclusion. Tor is currently bounded by single-thread CPU performance, with a minimum recommendation of 1 GB of RAM for non-exit relays faster than 40 Mbit/s. If your hardware does not meet these RAM requirements, upgrade it, then adjust the relay bandwidth rate limit as necessary. Frank Mar 27, 2024, 7:00 AM by tor-relays@lists.torproject.org: > I want to thank you for all the support replies you sent in response to my previous communication. I have carefully read through all your insights and appreciate your efforts in trying to find a solution to the issue. > > After thorough consideration of the matter, I have concluded that the problem may not be due to configuration errors in the automatic updates, as initially speculated. Rather, it seems that the issue could be hardware-related, with my VPS computer potentially unable to handle a certain amount of traffic. > > It's worth noting that there are no bandwidth issues, and the connection speed is high. However, I have set a RelayBandwidthRate limit of 250 Mbits. Interestingly, despite this configuration, the Tor Metrics site detects a speed of approximately 10/13 MBytes, equivalent to about 90/110 Mbits. This led me to speculate that the machine might experience an overload of operations or connections, causing it to crash temporarily. As a result, at the time of restart, Tor Statistics records the maximum speed reached up to that point (without ever reaching the set limit). Subsequently, following this theory, the Tor service restarts automatically without causing any anomalies in the service. > > To address this situation, I have decided to reduce the RelayBandwidthRate limit from 250 Mbits to 100 Mbits, which falls within the minimum limits proposed by torproject. If this is the case, however, it is also true that it would be best to impose an upper limit of 80% when considering the bandwidth magnitude involving the crash event as the maximum point. I honestly don't know how I would be able to verify this and acquire this kind of data, probably doing trial and error is the way. Perhaps the ideal would be to lower the maximum bandwidth further to verify for sure that this is what it is? > > Currently, I am closely monitoring the situation to assess whether this modification has a positive impact on the issue. > > I will keep you updated on any progress, and I thank you once again for your support and understanding. > > Best regards, > > Aleff. > > --- > > Browse my WebSite: aleff-gitlab.gitlab.io > Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 > Join to support: > - Free Software Foundation! (my.fsf.org/join?referrer=6202114) > - Electronic Frontier Foundation! (eff.org) > - Tor-Project (torproject.org) > - Signal (signal.org) > > martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays ha scritto: > >> Hi Alessandro, >> >> It's good to hear from you. I have a relay in a somewhat similar situation[1], although I've only just clocked it. If you're using Debian or one of its derivatives, then you can configure the unattended-upgrades package to perform a restart at a specific time if required. This means that your relay won't restart every time an upgrade is required, but will keep itself up to date. I think configuring a time for a daily restart (if upgrade required) would be a fairly good balance between stability and reliability. >> >> See what other people say or from your own experience, as Tor circuits are generally quite resilient and as long as you aren't a guard node I believe connections won't die because your relay is restarting. >> >> I would also note that Tor recommends [2] an uptime or 24/7 is nice, but not required and that restarts to the daemon or node are fine. Because of
[tor-relays] R: Re: Request for Feedback on Relay Node Update Management
My computer has:- 1 vCore CPU- 1 GB RAM- Maximum bandwidth: 1 GB/s So if I understand correctly, the problem should not be at the hardware level, right? Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays tor-relays@lists.torproject.org ha scritto: Hello Aleff, That is up to you. I strongly suspect that the hardware is the bottleneck, but detailed specifications are required in order to determine a conclusion. Tor is currently bounded by single-thread CPU performance, with a minimum recommendation of 1 GB of RAM for non-exit relays faster than 40 Mbit/s. If your hardware does not meet these RAM requirements, upgrade it, then adjust the relay bandwidth rate limit as necessary. Frank Mar 27, 2024, 7:00 AM by tor-relays@lists.torproject.org: I want to thank you for all the support replies you sent in response to my previous communication. I have carefully read through all your insights and appreciate your efforts in trying to find a solution to the issue. After thorough consideration of the matter, I have concluded that the problem may not be due to configuration errors in the automatic updates, as initially speculated. Rather, it seems that the issue could be hardware-related, with my VPS computer potentially unable to handle a certain amount of traffic. It's worth noting that there are no bandwidth issues, and the connection speed is high. However, I have set a RelayBandwidthRate limit of 250 Mbits. Interestingly, despite this configuration, the Tor Metrics site detects a speed of approximately 10/13 MBytes, equivalent to about 90/110 Mbits. This led me to speculate that the machine might experience an overload of operations or connections, causing it to crash temporarily. As a result, at the time of restart, Tor Statistics records the maximum speed reached up to that point (without ever reaching the set limit). Subsequently, following this theory, the Tor service restarts automatically without causing any anomalies in the service. To address this situation, I have decided to reduce the RelayBandwidthRate limit from 250 Mbits to 100 Mbits, which falls within the minimum limits proposed by torproject. If this is the case, however, it is also true that it would be best to impose an upper limit of 80% when considering the bandwidth magnitude involving the crash event as the maximum point. I honestly don't know how I would be able to verify this and acquire this kind of data, probably doing trial and error is the way. Perhaps the ideal would be to lower the maximum bandwidth further to verify for sure that this is what it is? Currently, I am closely monitoring the situation to assess whether this modification has a positive impact on the issue. I will keep you updated on any progress, and I thank you once again for your support and understanding. Best regards, Aleff. --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=getsearch=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org) martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays tor-relays@lists.torproject.org ha scritto: Hi Alessandro, It's good to hear from you. I have a relay in a somewhat similar situation[1], although I've only just clocked it. If you're using Debian or one of its derivatives, then you can configure the unattended-upgrades package to perform a restart at a specific time if required. This means that your relay won't restart every time an upgrade is required, but will keep itself up to date. I think configuring a time for a daily restart (if upgrade required) would be a fairly good balance between stability and reliability. See what other people say or from your own experience, as Tor circuits are generally quite resilient and as long as you aren't a guard node I believe connections won't die because your relay is restarting. I would also note that Tor recommends [2] an uptime or 24/7 is nice, but not required and that restarts to the daemon or node are fine. Because of this, it might not be worth worrying too much about this issue. I hope you find some of this useful, Seth [1] https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D87C1222177BB099E55AE [2] https://community.torproject.org/relay/relays-requirements/ Original Message On 26/03/2024 08:54, Alessandro Greco via tor-relays tor-relays@lists.torproject.org wrote: Dear Tor-Relays Mailing List Members, I hope this email finds you well. I'm reaching out to share some observations and pose some questions regarding the management of relay node updates, particularly concerning their impact on stability and security of the service provided. Recently, I've noticed an interesting pattern with my relay node (ID: 47B72187844C00AA5D524415E52E3BE81E63056B
Re: [tor-relays] User advisory to check for xz-utils backdoor
On Freitag, 29. März 2024 19:39:05 CEST pasture_clubbed242--- via tor-relays wrote: > > The near-universally used 'xz' compression library has been found to contain > a backdoor in certain code branches. This backdoor has made it into some > systems such as Debian Sid. > > Details regarding this backdoor are available here. > https://www.openwall.com/lists/oss-security/2024/03/29/4 Pretty unlikely that anyone uses testing or sid for productive servers. -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom! signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Backdoor in upstream xz/liblzma leading to ssh server compromise
On Samstag, 30. März 2024 01:02:54 CEST he...@relaymagic.org via tor-relays wrote: > Just wanted to bring this to everyone’s attention if you hadn’t seen it > already. Developer discovered a backdoor in xz-utils > https://www.openwall.com/lists/oss-security/2024/03/29/4 Pretty unlikely that anyone uses testing or sid for productive servers. -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom! signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] User advisory to check for xz-utils backdoor
Greetings, I do not normally use mailing lists such as this one to inform subscribers of security notices, but this issue is extreme enough where it may benefit the anonymity of Tor users if relay operators are aware of it sooner. The near-universally used 'xz' compression library has been found to contain a backdoor in certain code branches. This backdoor has made it into some systems such as Debian Sid. Details regarding this backdoor are available here. https://www.openwall.com/lists/oss-security/2024/03/29/4 It is suspected that if your OpenSSH server links to the xz library, which Debian appears to do so, then this backdoor is remotely exploitable. If your OpenSSH server does not link to this library, then your system still contains many processes that run xz actions as the root user, some input of which may be less than trusted. For those needing a patch, I recommend you research your distribution's security advisory page for further information. References: Debian Sid Advisory: https://security-tracker.debian.org/tracker/CVE-2024-3094 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Backdoor in upstream xz/liblzma leading to ssh server compromise
Just wanted to bring this to everyone’s attention if you hadn’t seen it already. Developer discovered a backdoor in xz-utils https://www.openwall.com/lists/oss-security/2024/03/29/4 -- Sent from Canary (https://canarymail.io) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Request for Feedback on Relay Node Update Management
Hello Aleff, That is up to you. I strongly suspect that the hardware is the bottleneck, but detailed specifications are required in order to determine a conclusion. Tor is currently bounded by single-thread CPU performance, with a minimum recommendation of 1 GB of RAM for non-exit relays faster than 40 Mbit/s. If your hardware does not meet these RAM requirements, upgrade it, then adjust the relay bandwidth rate limit as necessary. Frank Mar 27, 2024, 7:00 AM by tor-relays@lists.torproject.org: > I want to thank you for all the support replies you sent in response to my > previous communication. I have carefully read through all your insights and > appreciate your efforts in trying to find a solution to the issue. > > After thorough consideration of the matter, I have concluded that the problem > may not be due to configuration errors in the automatic updates, as initially > speculated. Rather, it seems that the issue could be hardware-related, with > my VPS computer potentially unable to handle a certain amount of traffic. > > It's worth noting that there are no bandwidth issues, and the connection > speed is high. However, I have set a RelayBandwidthRate limit of 250 Mbits. > Interestingly, despite this configuration, the Tor Metrics site detects a > speed of approximately 10/13 MBytes, equivalent to about 90/110 Mbits. This > led me to speculate that the machine might experience an overload of > operations or connections, causing it to crash temporarily. As a result, at > the time of restart, Tor Statistics records the maximum speed reached up to > that point (without ever reaching the set limit). Subsequently, following > this theory, the Tor service restarts automatically without causing any > anomalies in the service. > > To address this situation, I have decided to reduce the RelayBandwidthRate > limit from 250 Mbits to 100 Mbits, which falls within the minimum limits > proposed by torproject. If this is the case, however, it is also true that it > would be best to impose an upper limit of 80% when considering the bandwidth > magnitude involving the crash event as the maximum point. I honestly don't > know how I would be able to verify this and acquire this kind of data, > probably doing trial and error is the way. Perhaps the ideal would be to > lower the maximum bandwidth further to verify for sure that this is what it > is? > > Currently, I am closely monitoring the situation to assess whether this > modification has a positive impact on the issue. > > I will keep you updated on any progress, and I thank you once again for your > support and understanding. > > Best regards, > > Aleff. > > --- > > Browse my WebSite: aleff-gitlab.gitlab.io > Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 > Join to support: > - Free Software Foundation! (my.fsf.org/join?referrer=6202114) > - Electronic Frontier Foundation! (eff.org) > - Tor-Project (torproject.org) > - Signal (signal.org) > > martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays > ha scritto: > >> Hi Alessandro, >> >> It's good to hear from you. I have a relay in a somewhat similar >> situation[1], although I've only just clocked it. If you're using Debian or >> one of its derivatives, then you can configure the unattended-upgrades >> package to perform a restart at a specific time if required. This means that >> your relay won't restart every time an upgrade is required, but will keep >> itself up to date. I think configuring a time for a daily restart (if >> upgrade required) would be a fairly good balance between stability and >> reliability. >> >> See what other people say or from your own experience, as Tor circuits are >> generally quite resilient and as long as you aren't a guard node I believe >> connections won't die because your relay is restarting. >> >> I would also note that Tor recommends [2] an uptime or 24/7 is nice, but not >> required and that restarts to the daemon or node are fine. Because of this, >> it might not be worth worrying too much about this issue. >> >> I hope you find some of this useful, >> Seth >> >> >> >> [1] >> https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D87C1222177BB099E55AE >> [2] https://community.torproject.org/relay/relays-requirements/ >> Original Message >> On 26/03/2024 08:54, Alessandro Greco via tor-relays >> tor-relays@lists.torproject.org wrote: >> >> > Dear Tor-Relays Mailing List Members, >> > >> >> > I hope this email finds you well. I'm reaching out to share some >> > observations and pose some questions regarding the management of relay >> > node updates, particularly concerning their impact on stability and >> > security of the service provided. >> > >> >> > Recently, I've noticed an interesting pattern with my relay node (ID: >> > 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's >> > recommendations [2] and configured automatic updates, which has
Re: [tor-relays] Request for Feedback on Relay Node Update Management
No dice, this solution did not solve the problem for me either. My VPS holds up well to a maximum traffic of this magnitude and the hardware resources are not used more than 50% but nevertheless it keeps shutting down and restarting the tor service up to a maximum Uptime of 3 hours (but often restarts earlier). I want to specify that it does not restart the VPS but only the tor service. I also do not detect any files in the path "/var/log/tor". I would not know what else to check. --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org) mercoledì 27 marzo 2024 14:55, Alessandro Greco via tor-relays ha scritto: > I want to thank you for all the support replies you sent in response to my > previous communication. I have carefully read through all your insights and > appreciate your efforts in trying to find a solution to the issue. > > After thorough consideration of the matter, I have concluded that the problem > may not be due to configuration errors in the automatic updates, as initially > speculated. Rather, it seems that the issue could be hardware-related, with > my VPS computer potentially unable to handle a certain amount of traffic. > > It's worth noting that there are no bandwidth issues, and the connection > speed is high. However, I have set a RelayBandwidthRate limit of 250 Mbits. > Interestingly, despite this configuration, the Tor Metrics site detects a > speed of approximately 10/13 MBytes, equivalent to about 90/110 Mbits. This > led me to speculate that the machine might experience an overload of > operations or connections, causing it to crash temporarily. As a result, at > the time of restart, Tor Statistics records the maximum speed reached up to > that point (without ever reaching the set limit). Subsequently, following > this theory, the Tor service restarts automatically without causing any > anomalies in the service. > > To address this situation, I have decided to reduce the RelayBandwidthRate > limit from 250 Mbits to 100 Mbits, which falls within the minimum limits > proposed by torproject. If this is the case, however, it is also true that it > would be best to impose an upper limit of 80% when considering the bandwidth > magnitude involving the crash event as the maximum point. I honestly don't > know how I would be able to verify this and acquire this kind of data, > probably doing trial and error is the way. Perhaps the ideal would be to > lower the maximum bandwidth further to verify for sure that this is what it > is? > > Currently, I am closely monitoring the situation to assess whether this > modification has a positive impact on the issue. > > I will keep you updated on any progress, and I thank you once again for your > support and understanding. > > Best regards, > > Aleff. > > --- > > Browse my WebSite: aleff-gitlab.gitlab.io > Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get=0x7CFCE404A2168C85 > Join to support: > - Free Software Foundation! (my.fsf.org/join?referrer=6202114) > - Electronic Frontier Foundation! (eff.org) > - Tor-Project (torproject.org) > - Signal (signal.org) > > martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays > tor-relays@lists.torproject.org ha scritto: > > > Hi Alessandro, > > > It's good to hear from you. I have a relay in a somewhat similar > > situation[1], although I've only just clocked it. If you're using Debian or > > one of its derivatives, then you can configure the unattended-upgrades > > package to perform a restart at a specific time if required. This means > > that your relay won't restart every time an upgrade is required, but will > > keep itself up to date. I think configuring a time for a daily restart (if > > upgrade required) would be a fairly good balance between stability and > > reliability. > > > See what other people say or from your own experience, as Tor circuits are > > generally quite resilient and as long as you aren't a guard node I believe > > connections won't die because your relay is restarting. > > > I would also note that Tor recommends [2] an uptime or 24/7 is nice, but > > not required and that restarts to the daemon or node are fine. Because of > > this, it might not be worth worrying too much about this issue. > > > I hope you find some of this useful, > > Seth > > > [1] > > https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D87C1222177BB099E55AE > > [2] https://community.torproject.org/relay/relays-requirements/ > > Original Message > > On 26/03/2024 08:54, Alessandro Greco via tor-relays > > tor-relays@lists.torproject.org wrote: > > > > Dear Tor-Relays Mailing List Members, > > > > I hope this email finds you well. I'm reaching out to
