Re: [tor-relays] tor relay + sslh

[tor-relay]

Hi, if you run sslh on small vps you should use sslh-select which has
less overhead when many connections are handled.

see https://www.rutschle.net/tech/sslh/README.html

Am 12.06.21 um 10:26 schrieb Casper:
> Hello,
> 
> I recently discovered an SSL multiplexer called "sslh":
> 
> """
> sslh accepts connections on specified ports, and forwards them further
> based on tests performed on the first data packet sent by the remote
> client.
> 
> Probes for HTTP, SSL, SSH, OpenVPN, tinc, XMPP are implemented, and
> any other protocol that can be tested using a regular expression, can
> be recognized. A typical use case is to allow serving several services
> on port 443 (e.g. to connect to ssh from inside a corporate firewall,
> which almost never block port 443) while still serving HTTPS on that port.
> 
> Hence sslh acts as a protocol multiplexer, or a switchboard. Its name
> comes from its original function to serve SSH and HTTPS on the same port.
> """
> 
> Since many of my network services claims to listen on 433 (to bypass
> mobile network limitations), I'm thinking to configure and deploy
> sslh on large scale.
> 
> If tor handshake can be handled by sslh, could the process (of the tor
> relay) be listening on 127.0.0.1:12345 and publish good relay
> descriptor as well ?
> 
> Currently, in my relay config, I have the following:
> 
> """
> ORPort 26719
> ORPort [{{ ansible_default_ipv6.address }}]:26719
> DirPort 26720
> 
> and
> 
> Address 
> """
> 
> Tor will accept to be listening on the localhost interface only?
> 
> """
> ORPort 127.0.0.1:26719
> Address 
> """
> 
> Best regards,
> 
> 
> ___
> 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] tor crash on HUP only when SANDBOX is 1

[tor-relay]

just a little update:

I've reproduced this bug on my laptop with Debian Buster.

I've noticed that this problem occurs only with tor 0.4.2.5.  Tor 
0.4.1.6, from Debian buster backports repository, works properly.



Il 05/01/20 07:43, tor-re...@riseup.net ha scritto:

Hi,

I'm running an exit relay on a Debian Buster. I installed libseccomp 
and I've built tor 0.4.2.5 using debuild, like the wiki says.


Today I noticed that tor crashes on HUP signal, only when the Sandbox 
option is on. I never had this problem.



This is what my log says:

an 05 08:23:10.000 [notice] Received reload signal (hup). Reloading 
config and resetting internal state.
Jan 05 08:23:10.000 [notice] Read configuration file 
"/usr/share/tor/tor-service-defaults-torrc".

Jan 05 08:23:10.000 [notice] Read configuration file "/etc/tor/torrc".
Jan 05 08:23:10.000 [notice] Tor 0.4.2.5 opening log file.

 T= 
1578205390

(Sandbox) Caught a bad syscall attempt (syscall dup)
/usr/bin/tor(+0x1fc9fa)[0x561d896b29fa]
/lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f0bebf4bbc7]
/lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f0bebf4bbc7]
/usr/bin/tor(tor_log_update_sigsafe_err_fds+0x18b)[0x561d896c699b]
/usr/bin/tor(set_options+0x3c0)[0x561d89642f80]
/usr/bin/tor(options_init_from_string+0x17d)[0x561d896453dd]
/usr/bin/tor(options_init_from_torrc+0x404)[0x561d89645a74]
/usr/bin/tor(+0x5f961)[0x561d89515961]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22a6c)[0x7f0bec5a3a6c]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)[0x7f0bec5a4537] 


/usr/bin/tor(do_main_loop+0xff)[0x561d8952a3af]
/usr/bin/tor(tor_run_main+0x1105)[0x561d89517d55]
/usr/bin/tor(tor_main+0x3a)[0x561d8951523a]
/usr/bin/tor(main+0x19)[0x561d89514df9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f0bebe8509b]
/usr/bin/tor(_start+0x2a)[0x561d89514e4a]

I'm telling you because i think it could be a bug, but I'm not sure 
that It's not caused by something else.


At the moment I've disabled Sandbox. Please, let me know if I can fix 
this in some way, thanks.



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] tor crash on HUP only when SANDBOX is 1

[tor-relay]

Hi,

I'm running an exit relay on a Debian Buster. I installed libseccomp and 
I've built tor 0.4.2.5 using debuild, like the wiki says.


Today I noticed that tor crashes on HUP signal, only when the Sandbox 
option is on. I never had this problem.



This is what my log says:

an 05 08:23:10.000 [notice] Received reload signal (hup). Reloading 
config and resetting internal state.
Jan 05 08:23:10.000 [notice] Read configuration file 
"/usr/share/tor/tor-service-defaults-torrc".

Jan 05 08:23:10.000 [notice] Read configuration file "/etc/tor/torrc".
Jan 05 08:23:10.000 [notice] Tor 0.4.2.5 opening log file.

 T= 1578205390
(Sandbox) Caught a bad syscall attempt (syscall dup)
/usr/bin/tor(+0x1fc9fa)[0x561d896b29fa]
/lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f0bebf4bbc7]
/lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f0bebf4bbc7]
/usr/bin/tor(tor_log_update_sigsafe_err_fds+0x18b)[0x561d896c699b]
/usr/bin/tor(set_options+0x3c0)[0x561d89642f80]
/usr/bin/tor(options_init_from_string+0x17d)[0x561d896453dd]
/usr/bin/tor(options_init_from_torrc+0x404)[0x561d89645a74]
/usr/bin/tor(+0x5f961)[0x561d89515961]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22a6c)[0x7f0bec5a3a6c]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)[0x7f0bec5a4537]
/usr/bin/tor(do_main_loop+0xff)[0x561d8952a3af]
/usr/bin/tor(tor_run_main+0x1105)[0x561d89517d55]
/usr/bin/tor(tor_main+0x3a)[0x561d8951523a]
/usr/bin/tor(main+0x19)[0x561d89514df9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f0bebe8509b]
/usr/bin/tor(_start+0x2a)[0x561d89514e4a]

I'm telling you because i think it could be a bug, but I'm not sure that 
It's not caused by something else.


At the moment I've disabled Sandbox. Please, let me know if I can fix 
this in some way, thanks.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] forward relay connections

[tor-relay]

I think that a network based to much on remotes VMs, with closed source 
software running on the most deep machine level, is not very resilient 
and secure.


So the reason why I was thinking to do so is that I wanted to run a 
small exit relay on a device running only open source software, like 
Olimex Lime2 does, and under my direct control.


The latency from my home and the VM is not so high (45-50 ms), and I was 
pretty sure that with a proper configuration I didn't risk that users 
exit through my home connection.  But If you say that with a so small 
bandwidth It can't run properly, I trust you, so I keep a non-exit relay.


Anyway thanks for your advices

Il 22/05/19 11:05, nusenu ha scritto:


tor-re...@riseup.net:

I'm running a non exit relay on a debian machine (in the next few
months I will switch to *BSD) on a Lime2.

I assume you are referring to a relay run at home.


I'm running an exit relay
too on a remote VM.

I would turn my non-exit relay in an exit one, but for obvious
reasons, I don't want to run It from my shitty ISP IP. I could give
10-14 mbps from my home connection, so I think that the lime2 would
be  powerful enough to run It properly.

I would discourage such a setup for the following reasons:

- this setup includes the risk that users will exit
through your home broadband IP address (bad!) if tunnels break down
- such setups that introduce an additional hop decrease the user-experience
- most users will not be happy with an "10-14mbps" exit at a home broadband 
connection
- it is not clear to me why you would involve your home IP at all for your exit
if you have a VM in a datacenter


nonetheless, thanks for running relays,
nusenu




___
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] Become a Fallback Directory Mirror

[tor-relay]

2206C72ECC0D55593BC7B698F982533F1E141DD2

Il 21 maggio 2019 15:32:57 CEST, gus  ha scritto:
>Dear Relay Operators,
>
>Do you want your relay to be a Tor fallback directory mirror? 
>Will it have the same address and port for the next 2 years? 
>Just reply to this email with your relay's fingerprint.
>
>If your relay is on the current list, you don't need to do anything.
>
>If you're asking:
>
>Q: What's a fallback directory mirror?
>
>Fallback directory mirrors help Tor clients connect to the network. For
>more details, see [1].
>
>Q: Is my relay on the current list?
>
>Search [2] and [3] for your relay fingerprint or IP address and port.
>[2] is the current list of fallbacks in Tor.
>[3] is used to create the next list of fallbacks.
>
>Q: What do I need to do if my relay is on the list?
>
>Keep the same IP address, keys, and ports. Email tor-relays if the
>relay's details change.
>
>Q: Can my relay be on the list next time?
>
>We need fast relays that will be on the same IP address and port for 2
>years. Reply to this email to get on the list, or to update the details
>of your relay.
>
>Once or twice a year, we run a script to choose about 150-200 relays
>from the potential list [3] for the list in Tor [2].
>
>Q: Why didn't my relay get on the list last time?
>
>We check a relay's uptime, flags, and speed [4]. Sometimes, a relay
>might be down when we check. That's ok, we will check it again next
>time.
>
>It's good to have some new relays on the list every release. That helps
>tor clients, because blocking a changing list is harder.
>
>cheers,
>gus
>
>[1]
>https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
>[2] 
>https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc
>[3]
>https://gitweb.torproject.org/tor.git/tree/scripts/maint/fallback.whitelist
>[4]
>https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_2017-05-16-0815-09cd78886.log
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blocking outbound 22 or no?

[tor-relay . dirk]

Hello AMuse,

we faced the same about 1-2 month ago. Actuall people use fail2ban which
creates abuse mails to you provider.
Thats not new. But recently the abuse mails have risen to numbers which
lead us to believe there are acutally more people abusing ssh via tor
than people really using it.

In the end we disabled port 22. After all - any sysadmin who wants to
have peace and ever looked a ssh config will have its listen port
somewhere else than 22.

best regards

Dirk


On 05.10.2017 19:08, AMuse wrote:
> Hi all!  I'm getting a number of ISP Abuse complaints around outbound
> ssh brute-forcing from our exit relay.
>
> I'm personally of the opinion that people should run fail2ban (or
> equiv) and get on with life and I generally ignore the complaints -
> but wondered, what are other operators doing?
>
> Is anyone exit-policy blocking outbound 22 to make the internet a
> kinder place?  Is anyone refusing to on principle?
>
>
> ___
> 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] Two-step abuse management?

[tor-relay . dirk]

Hello Moritz,

we run such an setting since several years.

Whois records show our ripe object with abuse-r...@...as  abuse-mailbox
address.
This is connected to an auto-responder.

In auto-responder mail we explain what is going on and offer to write to
our abuse@ email address.
This really is then distributed to the abuse team for response.

There is not much coming in this way.
Some people directly go for our website our write to our office address.

Recently we received a lot of  automatic fail2ban messages due to ssh
abuse. The downside here is
they also wrote to our provider.

But this seems to be the setting of fail2ban which checks also the
network abuse record.

best regards

Dirk



On 13.09.2017 15:49, Moritz Bartl wrote:
> Hi!
>
> tl;dr: We're thinking about introducing an auto responder to abuse mail
> which then requires clicking a link or replying to the mail again before
> the complaint actually reaches a human. What do you think? Can you help
> us set this up?
>
> So far, we do not have any auto responder for abuse mails. I always
> thought it was important to be friendly and get back to everyone
> individually, even if at the core we're reusing mail templates. There is
> a difference if a human gets back to you within a few hours, or you
> immediately get clearly a auto-sent something that basically tells you
> there's not much that can be done.
>
> But actually, most of what we're seeing is automated notification mail,
> and lately we also see more and more spam that survives the
> spamassassin. An ideal system would track used addresses, and only send
> an auto-response from our end once per sender every few months.
>
> We have very limited resources for abuse management, and it would be
> great to filter out the noise better than we currently do.
>
> Did anyone set up an infrastructure like that before? How would you do it?
>
> Also, if you just want to help with our abuse management, let me know!
> We can always use one or two more hands, it's fun, and it teaches you a
> lot about Tor exit operation.
>

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Memory Problems with tor releay

[tor-relay . dirk]

Hello Roger,

I updated the ticket. You will find the output of the valgrind there as
well:
https://trac.torproject.org/projects/tor/attachment/ticket/22255/valgrind.txt

best regards

Dirk

On 23.05.2017 06:00, Roger Dingledine wrote:
> On Tue, May 23, 2017 at 03:01:10AM +, John Ricketts wrote:
>> Roger,
>>
>> I have whatever resources you need for testing.  Let me know if you would 
>> like them.
> 1)
> git clone https://git.torproject.org/git/tor
> cd tor.git
> ./autogen.sh && ./configure && make
>
> 2) edit /etc/security/limits.conf to have "tord hard nofile 65536" and
> "tord soft nofile 65536" lines, where tord is your user who will run it.
>
> 3)
> valgrind --leak-check=yes --error-limit=no --undef-value-errors=no src/or/tor 
> orport 9001 dirport 9030 nickname sorryitsslow geoipfile src/config/geoip
>
> (You might also want to set datadirectory, etc if you prefer, or point
> it to a torrc file if you prefer. Once you've got it working, you might
> run it with a datadirectory that has keys for an established relay.)
>
> Then watch the output for interesting valgrind complaints (I don't
> expect any, but if you find some, great!), and when you've let it
> run for a while, ^C it, let it close down, and see if Valgrind tells
> you about any "definite" memory leaks.
>
> Be aware that unless the CPU is super amazing, it will be totally cpu
> saturated and constantly failing to keep up with the requests it receives.
> So it is a fine thing to do for active bug hunting, but somewhat rude to
> do on real relays. :)
>
> --Roger
>
> ___
> 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] Memory Problems with tor releay

[tor-relay . dirk]

Dear all,

we are operating two exit nodes with each two tor processes out of
Switzerland.
The nodes worked quite stable until about 2-3 weeks ago.

Since then we experience frequent disruptions (Up to several times a
day). This is caused by a significant rise in memory consumption
by the tor processes and ends with a tor process being killed by the
Linux Kernel:

May 22 00:30:43 tor2 kernel: [2257156.134100] Killed process 40964 (tor)
total-vm:448088kB, anon-rss:0kB, file-rss:0kB

The systems are physical machines with Ubuntu 14.04.5 LTS with 4 GB of
memory. This was sufficient the last 2 years.

For more details a sample of this behavior is documented in a Ticket [1].
Tor project team is researching but until now no hints lead to an
improvement.

Due to a tweet last week [2] and the follow up discussion with another
operator I became suspicious that is not just
just us having a problem rather it cloud be more common.

Therefore here the question to you all - do you experience some strange
behavior like described in the ticket as well ?

Please let me know if so.

If not - maybe it is just an unfortunate coincidence and we will end up
make a clean install of both server hoping the problem will go away.


best regards

Dirk


[1] https://trac.torproject.org/projects/tor/ticket/22255

[2]https://twitter.com/FrennVunDerEnn/status/864583496072876034


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tornull

[tor-relay . dirk]

It was two days ago. Today I can not reach it as well.

best regards

Dirk


On 01.05.2017 08:08, scar wrote:
> I was unable to reach the site, is it still in operation?
>
> ___
> 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] minor typos in tor-instance-create

[tor relay]

> fixed, thanks.

https://gitweb.torproject.org/debian/tor.git/commit/?id=040fffc07b430d825e5acc88e6d2085a17b718fa
There is a little typo in the fix

tor@$name "
vs
tor@$name"
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] tor-instance-create users: beware all your instances are always started

[tor relay]

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-generator
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] minor typos in tor-instance-create

[tor relay]

https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create#n89

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-create.8.txt#n18

brdige -> bridge
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] debian: log messages when upgrading tor package

[tor relay]

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?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

made a ticket:
https://trac.torproject.org/projects/tor/ticket/19847
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

> So there is no way to disable the default instance using systemctl after all?

To answer my own question:
systemctl mask tor@default
disables the default instance for real.

..but I'm still curious why tor@default is a static unit (without [Install] 
section)
https://bbs.archlinux.org/viewtopic.php?id=147964
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

> > > > Also: you can not start/stop/restart tor.service separately without 
> > > > leaving all other tor instances untouched.
> > > 
> > > tor.service is *not* the default service.  tor.service is the collection
> > > of all service instances.
> > 
> > 
> > Gosh, you are right there is tor@default.service, so you are actually 
> > already doing what is being done in RPMs and there is no need to move away 
> > /etc/tor/torrc at all :)
> > (why didn't you mention that ;).

Ok, I wrote that before actually trying to disable the default instance via
systemctl disable tor@default

This does not work. I fail to disable tor@default without disabling tor.service.
After a reboot it is back and running. 

I noticed that this service is special since it says "static" instead of 
"enabled" or "disabled" on other services:

systemctl status tor@default
● tor@default.service - Anonymizing overlay network for TCP
   Loaded: loaded (/lib/systemd/system/tor@default.service; static)

So there is no way to disable the default instance using systemctl after all?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

> On August 5, 2016 at 1:24 PM Peter Palfrader <wea...@torproject.org> wrote:
> 
> 
> On Fri, 05 Aug 2016, tor relay wrote:
> 
> > Also: you can not start/stop/restart tor.service separately without leaving 
> > all other tor instances untouched.
> 
> tor.service is *not* the default service.  tor.service is the collection
> of all service instances.


Gosh, you are right there is tor@default.service, so you are actually already 
doing what is being done in RPMs and there is no need to move away 
/etc/tor/torrc at all :)
(why didn't you mention that ;).
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

> 
> Why this hack (disable a service by moving away its config) and not the 
> more clean approach like the one take by the RPM maintainer?
> 

 ..that allows one to manage (start/stop/enable/disable) each service 
separately using standard tools and methodologies (and not service specific 
ways like "if you want to disable it you have to move away its configuration 
file).

Simply moving away its configuration file will cause unnecessary logs since 
systemd will attempt to start tor.service every time:

Unable to open configuration file "/etc/tor/torrc".

[err] Reading config failed--see warnings above.

tor@default.service: control process exited, code=exited status=1
Failed to start Anonymizing overlay network for TCP.
Unit tor@default.service entered failed state.
tor@default.service start request repeated too quickly, refusing to start.
Failed to start Anonymizing overlay network for TCP.
Unit tor@default.service entered failed state.


If one monitors log for [err] log level events this isn't nice.


Also: you can not start/stop/restart tor.service separately without leaving all 
other tor instances untouched.


Please consider the RPM maintainer's approach, thank you!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

> 
> On August 4, 2016 at 10:23 AM Peter Palfrader <wea...@torproject.org> 
> wrote:
> 
> On Thu, 04 Aug 2016, tor relay wrote:
> 
> > > 
> > > > > 
> > > On August 3, 2016 at 11:51 PM Green Dream 
> > > <greendream...@gmail.com> wrote:
> > > 
> > > Sorry, I didn't understand that your daemon didn't restart 
> > > after the upgrade. I ran through the upgrade on 2 relays, and apt started 
> > > the service post-upgrade on both.
> > > 
> > > > > 
> > Since it is reproducible in my case as well I assume you do _not_ 
> > have the following constellation:
> > 
> > tor.service is disabled and stopped (I don't use the default 
> > instance)
> > 
> > > 
> You should not disable tor.service.
> 
> tor.service is what controls all tor instances. The default service is
> tor@default.service. If you don't want it to start, one option is to
> move away /etc/tor/torrc.
> 

It is even more uncomfortable than I thought since logrotate daily reload 
causes all tor instances to stop if tor.service is disabled, this has certainly 
not been the case with 0.2.7.6.


Why this hack (disable a service by moving away its config) and not the more 
clean approach like the one take by the RPM maintainer?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

https://trac.torproject.org/projects/tor/ticket/19825___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

> On August 3, 2016 at 11:51 PM Green Dream  wrote:
> 
> Sorry, I didn't understand that your daemon didn't restart after the 
> upgrade. I ran through the upgrade on 2 relays, and apt started the service 
> post-upgrade on both.
> 
> 
> 

Since it is reproducible in my case as well I assume you do _not_ have the 
following constellation:

tor.service is disabled and stopped (I don't use the default instance)

tor@1 mailto:tor@1 .service is enabled and running

tor@2.service mailto:tor@2.service is enabled and running
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

> On August 3, 2016 at 11:04 PM Green Dream  wrote:
> 
> 
> > When upgrading, all running tor instances are stopped (not restarted, 
> as expected)
> 
> > syslog shows:
> 
> > Interrupt: we have stopped accepting new connections, and will shut 
> down in 30 seconds. Interrupt again to exit now.
> 
> > Clean shutdown finished. Exiting.
> 
> > (problem is reproducible)
> 
> 
> I just had the same experience upgrading my relays, but I think this is 
> to be expected? New connections are blocked and there's 30 seconds to give 
> existing connections a chance to gracefully complete. The daemon is then 
> stopped while the packages upgrade, then it's restarted. I think it's been 
> handled like that for a while, although my memory is a little fuzzy since I 
> hadn't upgraded in the last 6 months.
> 

Well if your tor instance started again automatically after the upgrade then 
you didn't experience the same problem as I did, because it did NOT restart it 
simply stopped without starting again at all.

I expected it to restart (as it did during previous updates).
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] experiences with debian tor 0.2.8.6 package from deb.torproject.org

[tor relay]

Hi,

I'm running a relay on debian jessie using packages from deb.torproject.org.

I want to share the problems I had so others are aware of them when upgrading 
their relays.

While upgrading from 0.2.7.6 to 0.2.8.6 via apt-get, I did a

tail -f syslog

to make sure I notice problems during the upgrade. (I expected a simple restart 
of all running tor instances)

I use debian's multi instance systemd service file.

When upgrading, all running tor instances are stopped (not restarted, as 
expected)

syslog shows:

Interrupt: we have stopped accepting new connections, and will shut down in 30 
seconds. Interrupt again to exit now.

Clean shutdown finished. Exiting.


(problem is reproducible)


Side note (unrelated to the upgrade but also relevant for the debian tor 
package from deb.torproject.org repo):

Stopping the default instance stops all instances due to

/lib/systemd/system/tor@.service:

[...]

PartOf=tor.service
ReloadPropagatedFrom=tor.service


How about using the same way as the RPM maintainer does - so one can enable the 
default instance without affecting all others?

PartOf=tor-master.service
ReloadPropagatedFrom=tor-master.service
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] cheap unmetered non-exit VPS offers

[tor relay]

> On July 28, 2016 at 2:48 PM Markus Koch  wrote:
> 
> 
> exit allowed?

no, that is why I put "non-exit" in the subject of my email.

https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs#Italy1

And yes, their support is poor, but as long as your servers run you won't need 
them.

Another hoster with great bw/cost efficiency (non-exit!) 
https://itldc.com/en/vds/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] VPS for Exits

[tor relay]

> Well, I'm still sticking with CoolHousing/Virtual Server Lite because I 
> hardly ever get abuse
> complaints. For ITL, I may leave after my term expires.

> But a few other companies I found were:

> https://hostmaze.com/

tested it, made really bad experience with them, network performance was almost 
unusable <10MBit/s
lately, they had an outage of 2 days ("because voxility upstream added two new 
uplinks", than I canceled)

> https://blazingfast.io/

made also bad experience with them, like "fatal" said, their network 
performance isn't the best <20MBit/s (per direction) weekly average


If anyone can recommend any other hosters, please come forward.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] First Tech CU apparently blocking all Tor nodes

[Tor Relay @ WeFu.Org]

It appears that First Tech Federal Credit Union is blocking all Tor
nodes (including non-exit nodes) from connecting to their website,
http://www.firsttechfed.com 

This seems ... misguided on their part. Blocking exit nodes is one
thing, but preventing random people who happen to run a Tor middle node
from seeing anything on their website is rather over the top.

They do not appear to be listed on
https://trac.torproject.org/projects/tor/wiki/org/doc/ListOfServicesBlockingTor 
yet. If other people also observe the blocking, they should probably be added.

I wanted to check with the list to make sure it is not just me, and get
suggestions about the best way to approach First Tech and encourage them
to re-consider this overly broad blocking.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] NHS UK blocking Tor?

[Tor Relay]

Chris Whittleston wrote:

Can someone else running a relay from their home connection confirm that
they get an 'Access denied' error from http://www.nhs.uk? I've checked with
someone using the same ISP in the flat above me and they seem able to
access the site just fine, as can I via mobile internet so I'm down to
suspecting that they are blocking all Tor relay IPs. This is the exact
error I get:
Access DeniedYou don't have permission to access http://www.nhs.uk/; on
this server.

Reference #18.1f7f1002.1397514736.1fe2170c
The reference seems to change each time I visit. If this does turn out to
be them blocking Tor - advice on how to approach contacting them to resolve
this would be appreciated.

Thanks,

Chris

I am running both my relay, OnionTorte, and a vanilla machine from a 
home connection. Both get denied access, and the Ref# changes w/ each visit.


HTH,

P

--
Dirt kicked to the curb goes into the gutter.
Professionals kicked to the curb go into retail.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Lots of tor relays send out sequential IP IDs; please fix that!

[Tor Relay]

Could you please translate your instructions into XP that I might check 
and, if necessary, fix my relay?  (OnionTorte)


Thanks,

P


Jann Horn wrote:

Well, the subject line pretty much says it all: Lots of Tor relays send out
globally sequential IP IDs, which, as far as I know, allows a remote party to
measure how fast the relay is sending out IP packets with high precision,
possibly making statistical attacks possible that could e.g. pinpoint the entry
guard a user or hidden service uses.

This is how you can test whether a given relay has this issue:

$ sudo hping3 -r --syn -p 443 176.199.74.186 --count 10
HPING 176.199.74.186 (eth0 176.199.74.186): S set, 40 headers + 0 data bytes
len=46 ip=176.199.74.186 ttl=116 DF id=3025 sport=443 flags=SA seq=0 win=8192 
rtt=33.5 ms
len=46 ip=176.199.74.186 ttl=116 DF id=+38 sport=443 flags=SA seq=1 win=8192 
rtt=32.7 ms
len=46 ip=176.199.74.186 ttl=116 DF id=+42 sport=443 flags=SA seq=2 win=8192 
rtt=32.5 ms
len=46 ip=176.199.74.186 ttl=116 DF id=+34 sport=443 flags=SA seq=3 win=8192 
rtt=32.3 ms
len=46 ip=176.199.74.186 ttl=116 DF id=+36 sport=443 flags=SA seq=4 win=8192 
rtt=33.2 ms
len=46 ip=176.199.74.186 ttl=116 DF id=+36 sport=443 flags=SA seq=5 win=8192 
rtt=36.4 ms
len=46 ip=176.199.74.186 ttl=116 DF id=+35 sport=443 flags=SA seq=6 win=8192 
rtt=33.9 ms
len=46 ip=176.199.74.186 ttl=116 DF id=+56 sport=443 flags=SA seq=7 win=8192 
rtt=31.7 ms
len=46 ip=176.199.74.186 ttl=116 DF id=+46 sport=443 flags=SA seq=8 win=8192 
rtt=33.4 ms
len=46 ip=176.199.74.186 ttl=116 DF id=+34 sport=443 flags=SA seq=9 win=8192 
rtt=33.7 ms

In the last example, you can see that the id field has increased by 30-50 
every second.
That's an issue: It should be one of:

 - always 0
 - totally random

It can also be that it increments by one every time; that probably means that 
the relay
uses per-IP counters or so, and as far as I know, that should be fine.


After a bit of testing, I think that this issue is present on a lot of Tor 
relay nodes. Here
are the first few in the alphabet that look suspicious (didn't want to scan the 
whole Tor
network):


snip


Please, everyone, check whether your Tor relay node behaves this way, and if so,
either change the behavior or take it offline until you can fix the issue.

Tor is not designed to be secure if an attacker can measure traffic at both
ends of a circuit (for a proof of concept for that, see
http://seclists.org/fulldisclosure/2014/Mar/414), and if your relay has this
issue, you're already allowing anyone to measure at your relay.




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



--
Dirt kicked to the curb goes into the gutter.
Professionals kicked to the curb go into retail.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Best price/efficiency ratio

[Tor Relay]

Potential throttling notwithstanding, that you are willing to help out a 
great cause earns you the stars in your crown... but you'll still need 
to wait for your T-shirt.


P

--
Dirt kicked to the curb goes into the gutter.
Professionals kicked to the curb go into retail.


Rick Ross wrote:

Question how long you'll stay in the Top 50. Maybe you are lucky but
probably the ISP will end your contract for abusing fair use
policies/TOS. Best case they'll throttle you down. Let us know in 30 days :)

Am 22.03.14 21:51, schrieb Trigger Happy:

Hi list,

I'm running tor-relay (middle) on VPS from statnet.pl (reseller form
Hetzner)

https://globe.torproject.org/#/relay/C528972A915EEADE37F5B11A7AB7B571C89F46E7


Now i'm in top 50 of all relays for only 8,3 euro/month i think it's a
good deal . Do You know better options ?

___
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



--
Dirt kicked to the curb goes into the gutter.
Professionals kicked to the curb go into retail.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Effects of Rebooting?

[Tor Relay]

I am a n00b relay (OnionTorte) operator, and, as such, know lamentably 
little of what I'm doing.  (Yes, I'm one of *those* relay operators.) 
When I went to bed last night I had an HSDir flag, but it has since 
disappeared.  And since this A.M. my consensus was halved.  A bit of 
promiscuous pokings-about in relay metrics leads me to think that this 
happened in the wake of my having had to reboot my machine to unwedge 
it.  Speed Test shows that even on the worst of BadHair Days my u/l 
speed doesn't sink below 15Mb/s (1900KB/s), and almost always cruises at 
25Mb/s, so I don't think that it's so much a bandwidth issue as one of 
perceived reliability.  :(


I read
https://blog.torproject.org/blog/lifecycle-of-a-new-relay

but wasn't able to take away as much as I would have liked.  If somebody 
can explain to me, using small words and interpretive dance as befits a 
callow contributor, what happened I should certainly appreciate it.


Thanks,

P

--
Dirt kicked to the curb goes into the gutter.
Professionals kicked to the curb go into retail.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays