Re: [tor-relays] Port not rechable
> On 4 Mar 2018, at 17:50, peter.zehet...@liwest.at wrote: > > OK, but what is this: > > Mar 03 21:36:31.000 [warn] Failed to start child process "tor-fw-helper" in > state 9: No such file or directory > Mar 03 21:51:46.000 [warn] Failed to start child process "tor-fw-helper" in > state 9: No such file or directory > Mar 03 21:56:51.000 [warn] Failed to start child process "tor-fw-helper" in > state 9: No such file or directory > Remove the PortForwarding* options from your torrc. You don't need them, because your ports are reachable. > Tor is now online for about 36 hours, the log says 6 hours because the > computer was restarted. > > This is the latest log: > > … > > How long does it last until the relay will be in use? > https://blog.torproject.org/lifecycle-new-relay > What do the "flags" in tor-arm mean? Sometimes it says "Running, V2Dir, Valid" > https://metrics.torproject.org/glossary.html#relay-flag T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Port not rechable
OK, but what is this: Mar 03 21:36:31.000 [warn] Failed to start child process "tor-fw-helper" in state 9: No such file or directory Mar 03 21:51:46.000 [warn] Failed to start child process "tor-fw-helper" in state 9: No such file or directory Mar 03 21:56:51.000 [warn] Failed to start child process "tor-fw-helper" in state 9: No such file or directory Tor is now online for about 36 hours, the log says 6 hours because the computer was restarted. This is the latest log: Mar 03 23:45:12.000 [notice] Bootstrapped 0%: Starting Mar 03 23:45:24.000 [notice] Bootstrapped 80%: Connecting to the Tor network Mar 03 23:45:24.000 [notice] Signaled readiness to systemd Mar 03 23:45:24.000 [notice] Opening Socks listener on /var/run/tor/socks Mar 03 23:45:24.000 [notice] Opening Control listener on /var/run/tor/control Mar 03 23:45:25.000 [notice] Guessed our IP address as 81.10.248.112 (source: 154.35.175.225). Mar 03 23:45:25.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Mar 03 23:45:26.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Mar 03 23:45:27.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Mar 03 23:45:27.000 [notice] Bootstrapped 100%: Done Mar 03 23:45:27.000 [notice] Now checking whether ORPort 81.10.248.112:443 and DirPort 81.10.248.112:80 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Mar 03 23:45:33.000 [notice] New control connection opened. Mar 03 23:46:49.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Mar 03 23:46:52.000 [notice] Performing bandwidth self-test...done. Mar 03 23:47:03.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Publishing server descriptor. Mar 04 05:45:24.000 [notice] Heartbeat: Tor's uptime is 5:59 hours, with 0 circuits open. I've sent 8.65 MB and received 15.91 MB. Mar 04 05:45:24.000 [notice] Average packaged cell fullness: 12.249%. TLS write overhead: 13% Mar 04 05:45:24.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 1107/1107 NTor. Mar 04 05:45:24.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 454 v4 connections; and received 0 v1 connections, 0 v2 connections, 0 v3 connections, and 635 v4 connections. Mar 04 07:35:06.000 [notice] Received reload signal (hup). Reloading config and resetting internal state. Mar 04 07:35:06.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". How long does it last until the relay will be in use? What do the "flags" in tor-arm mean? Sometimes it says "Running, V2Dir, Valid" Yours -Peter Am 03.03.2018 um 10:31 schrieb teor: > >> On 3 Mar 2018, at 18:32, peter.zehet...@liwest.at wrote: >> >> Mar 03 00:05:38.000 [notice] Self-testing indicates your ORPort is reachable >> from the outside. Excellent. >> Mar 03 00:05:45.000 [notice] Performing bandwidth self-test...done. >> Mar 03 00:09:29.000 [notice] Self-testing indicates your DirPort is >> reachable from the outside. Excellent. Publishing server descriptor. > > It is ok. > >> … >> Mar 03 00:52:47.000 [warn] Controller gave us config lines that didn't >> validate: RelayBandwidthBurst must be at least equal to RelayBandwidthRate. > > You should check these options have the values you want. > > T > ___ > 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] FreeBSD 11.1 ZFS Tor Image
On 03/03/2018 04:27 AM, Moritz Bartl wrote: > On 03.03.2018 07:11, Roger Dingledine wrote: >> Apparently the link from my blog post, to >> https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines >> no longer has any mention pro or con disk encryption. I wonder if that >> was intentionally removed by the torservers.net folks (maybe they have >> even changed their mind on the advice?), or if it just fell out because >> it's a wiki. > I added the recommendation for "no disk encryption" back then, and it > wasn't me who removed it. > > My own opinion has changed slightly: My general advice would still be to > not do disk encryption, to reduce the amount of hassle and allow easier > 'audits'. For additional protection, you better move the relay keys to a > RAM disk. > > However, in our case, we don't really care how long they keep the > machines for analysis, and we do not reuse hardware that was seized (it > goes back into the provider pool, so some other customer might be in for > a surprise...). In that case, a relay operator may decide to use disk > encryption for integrity reasons: They at least have to ask you for the > decryption key and cannot silently copy content or easily manipulate the > file system. > Personally, I think entire disk encryption just to protect the keys is way too much of a hassle. I completely agree with your solution - place the keys in a ramdisk, that's actually a great idea. I'll put that into what I'm building up right now. Regards, Conrad Rockenhaus 0x424F4C61.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] One pubblic IP, two or more relay on different ports
MLTorNode: > Is it possibile? I have one dynamic public IP with one relay server published > on > ORPort 443 and DIRport 80 (with IPv6 ORPort too). > Can i add a second relay with OR and DIR natted on other ports published on > the > same IP of the first server? you can run up to two tor relay instances on a single public IPv4. You can not run more than 2 instances per public IPv4. -- https://mastodon.social/@nusenu twitter: @nusenu_ signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] One pubblic IP, two or more relay on different ports
Is it possibile? I have one dynamic public IP with one relay server published on ORPort 443 and DIRport 80 (with IPv6 ORPort too). Can i add a second relay with OR and DIR natted on other ports published on the same IP of the first server? Thanks in advance, -- Marlenio (MLTorNode) FE4033D750831C32A957174ADD11E40F558A14A9 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] tor26 dir auth differences
consensus-health (https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-consensus-health) wrote: > WARNING: The following authorities are missing from the consensus: tor26, > dizum > NOTICE: tor26 had 6216 Guard flags in its vote but the consensus had 1855 > NOTICE: tor26 had 0 Exit flags in its vote but the consensus had 777 > NOTICE: tor26 had 7086 Stable flags in its vote but the consensus had 4541 interesting -- https://mastodon.social/@nusenu twitter: @nusenu_ signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] less than 3 bw auths available: self-measurement (with 10k cap in effect)
On 03/02/2018 01:17 PM, Roger Dingledine wrote: > Turns out the issue was that the default bwauth backend (the server that > serves the bandwidth files) went offline during our efforts to shuffle > things around so www.torproject.org could survive this week's 15-20gbps > ddos attack on our website. > > Faravahar and moria1 were still using the default bwauth backend, but > we've moved to a different one and things are looking fine again. > > Never a dull moment, > --Roger Thanks for all of your hard work; Tor has good back office. I've been off-line for a while myself because I've been trying to upgrade equipment (& Tor itself -Error 2...?!?), and I'd rather not run relays unless I'm running them according to Hoyle, i.e. up-to-date and secure. 0xDD79757F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] New releases today: please consider upgrading.
Hi! There are new security releases today. The official announcement just went to tor-announce, but I want to make sure that people on this list see it too. In brief: * Directory authorities should upgrade. * Relays running 0.3.2.1-alpha through 0.3.2.9 should upgrade. * Relays running 0.3.3.1-alpha should upgrade. * All other relays may wish to upgrade in order to improve their resistance to denial-of-service attacks. If you build Tor from source, the source code is available at https://dist.torproject.org/ . Packages should be available over the coming days. For the complete announcement, including changelogs, see https://lists.torproject.org/pipermail/tor-announce/2018-March/000152.html best wishes, -- Nick ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] memory requirements
‐‐‐ Original Message ‐‐‐ On February 21, 2018 10:37 AM, nusenu wrote: > notatorserver: > > > Hi, > > > > I have just setup a tor-relay and I am wondering if the resource > > requirements are still current:> "A non-exit relay faster than 40MBit/s > > should have at least 1 GB of RAM."\[1\] > > Yes, I still believe that you can run a relay if you have just 1 GB of RAM. > > (this is a lower boundary) > > > My relay is sitting at ~2.77G currently. > > assuming we talk about: > > https://metrics.torproject.org/rs.html#details/8BB171D82DDEC2CC751C5B63BA5439FB448A24B2 > > I consider that a lot of memory for a relay added on 2018-02-15 and > > not being guard yet. > > You are currently running version 0.3.1.9 which is lacking the latest > > denial of service mitigations, > > it will get a lot better with the upcoming stable releases > > or if you upgrade to tor 0.3.3.2-alpha or newer. I upgraded and replaced musl's malloc with tcmalloc. Now memory feels stable (currently at ~1.3G). I also ran with heap profiling enabled for a day. Nothing interesting there. I do see messages printed: DoS mitigation since startup: 1632 circuits rejected, 6 marked addresses. 557 connections closed. 900 single hop clients refused. Whether it was an attack or just my unfamiliarity with musl I guess we will never know... > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] FreeBSD 11.1 ZFS Tor Image
On 03.03.2018 07:11, Roger Dingledine wrote: > Apparently the link from my blog post, to > https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines > no longer has any mention pro or con disk encryption. I wonder if that > was intentionally removed by the torservers.net folks (maybe they have > even changed their mind on the advice?), or if it just fell out because > it's a wiki. I added the recommendation for "no disk encryption" back then, and it wasn't me who removed it. My own opinion has changed slightly: My general advice would still be to not do disk encryption, to reduce the amount of hassle and allow easier 'audits'. For additional protection, you better move the relay keys to a RAM disk. However, in our case, we don't really care how long they keep the machines for analysis, and we do not reuse hardware that was seized (it goes back into the provider pool, so some other customer might be in for a surprise...). In that case, a relay operator may decide to use disk encryption for integrity reasons: They at least have to ask you for the decryption key and cannot silently copy content or easily manipulate the file system. -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Disk encryption for relays [was: FreeBSD 11.1 ZFS Tor Image]
Roger Dingledine: > Capturing the on-disk keys from a relay will let them impersonate the > relay in the future To limit possibility to impersonate a relay in the future, operators can run in OfflineMasterKey mode with a short SigningKeyLifetime (i.e. 5 days) and push key material via SSH to the relay. This will limit the ability of an attacker to impersonate the relays to 5 days in the worst case, iff the attacker does not also compromise the host storing the Ed25519 master keys. And if you actually want to do it: ansible-relayor does it by default (with 30 days SigningKeyLifetime). -- https://mastodon.social/@nusenu twitter: @nusenu_ signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Port not rechable
> On 3 Mar 2018, at 18:32, peter.zehet...@liwest.at wrote: > > Mar 03 00:05:38.000 [notice] Self-testing indicates your ORPort is reachable > from the outside. Excellent. > Mar 03 00:05:45.000 [notice] Performing bandwidth self-test...done. > Mar 03 00:09:29.000 [notice] Self-testing indicates your DirPort is reachable > from the outside. Excellent. Publishing server descriptor. It is ok. > … > Mar 03 00:52:47.000 [warn] Controller gave us config lines that didn't > validate: RelayBandwidthBurst must be at least equal to RelayBandwidthRate. You should check these options have the values you want. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
