[tor-relays] Dutch Relays

[Christopher Sheats]

Hello,

Emerald Onion is looking for co-location and IP transit opportunities in 
the Netherlands for deploying new exit relays. We have our own ASN, v4 
and v6 IP space.


Priorities are:
- Free or cheap transit
- Free or cheap cross-connects
- Free or cheap colo
- Amsterdam Internet Exchange
- Netherlands Internet Exchange

Working with collectives, or starting a new one, is interesting too. 
Please share your thoughts!


--
yawnbox
https://disobey.net/@yawnbox
https://digitalcourage.social/@EmeraldOnion



OpenPGP_0x4D3394A723A57C0A.asc
Description: OpenPGP public key


OpenPGP_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] obfs4 bridge management

[Christopher Sheats]

Hello,

I've has published a shell script for deploying and managing obfs4 
bridges, I hope its useful to others.


https://github.com/emeraldonion/bridge-management/

Feedback welcome!

--
yawnbox
https://disobey.net/@yawnbox
https://digitalcourage.social/@EmeraldOnion



OpenPGP_0x4D3394A723A57C0A.asc
Description: OpenPGP public key


OpenPGP_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] inet_csk_bind_conflict

[Christopher Sheats]

I am happy to report that we have upgraded all our relays to Tor 
0.4.8.0-alpha-dev and for the pst 8 days since the upgrade the bind conflict 
has ceased. No firewall rules are being used. No sysctl settings helped.

--
Christopher Sheats (yawnbox)
Executive Director
Emerald Onion
Signal: +1 206.739.3390
Website: https://emeraldonion.org/
Mastodon: https://digitalcourage.social/@EmeraldOnion/




> On Dec 12, 2022, at 1:18 PM, Anders Trier Olesen 
>  wrote:
> 
> > It is surprising, isn't it? It certainly feels like calling connect
> > without first binding to an address should have the same effect as
> > manually binding to an address and then calling connect, especially if
> > the address you bind to is the same as the kernel would have chosen
>  > automatically. It seems like it might be a bug, but I'm not qualified to
> > judge that.
> Yes, I'm starting to think so too. And strange that Cloudflare doesn't 
> mention stumbling upon this problem in their blogpost on running out of 
> ephemeral ports. [1]
> If I find the time, I'll make an attempt at understanding exactly what is 
> going on in the kernel.
> 
> > If I am interpreting your results correctly, it means that either of the
> > two extremes is safe
> Yes. That is what I think too.
> 
> > Anyway, thank your for the insight. I apologize if I was inconsiderate
> > in my prior reply.
> Likewise!
> 
> Best regards
> Anders Trier Olesen
> 
> [1] 
> https://blog.cloudflare.com/how-to-stop-running-out-of-ephemeral-ports-and-start-to-love-long-lived-connections/
> 
> On Mon, Dec 12, 2022 at 4:16 PM David Fifield  <mailto:da...@bamsoftware.com>> wrote:
>> On Mon, Dec 12, 2022 at 12:39:50AM +0100, Anders Trier Olesen wrote:
>> > I wrote some tests[1] which showed behaviour I did not expect.
>> > IP_BIND_ADDRESS_NO_PORT seems to work as it should, but calling bind 
>> > without it
>> > enabled turns out to be even worse than I thought.
>> > This is what I think is happening: A successful bind() on a socket without
>> > IP_BIND_ADDRESS_NO_PORT enabled, with or without an explicit port 
>> > configured,
>> > makes the assigned (or supplied) port unavailable for new connect()s (on
>> > different sockets), no matter the destination. I.e if you exhaust the 
>> > entire
>> > net.ipv4.ip_local_port_range with bind() (no matter what IP you bind to!),
>> > connect() will stop working - no matter what IP you attempt to connect to. 
>> > You
>> > can work around this by manually doing a bind() (with or without an 
>> > explicit
>> > port, but without IP_BIND_ADDRESS_NO_PORT) on the socket before connect().
>> >
>> > What blows my mind is that after running test2, you cannot connect to 
>> > anything
>> > without manually doing a bind() beforehand (as shown by test1 and test3 
>> > above)!
>> > This also means that after running test2, software like ssh stops working:
>> >
>> > When using IP_BIND_ADDRESS_NO_PORT, we don't have this problem (1 5 6 can 
>> > be
>> > run in any order):
>> 
>> Thank you for preparing that experiment. It's really valuable, and it
>> looks a lot like what I was seeing on the Snowflake bridge: calls to
>> connect would fail with EADDRNOTAVAIL unless first bound concretely to a
>> port number. IP_BIND_ADDRESS_NO_PORT causes bind not to set a concrete
>> port number, so in that respect it's the same as calling connect without
>> calling bind first.
>> 
>> It is surprising, isn't it? It certainly feels like calling connect
>> without first binding to an address should have the same effect as
>> manually binding to an address and then calling connect, especially if
>> the address you bind to is the same as the kernel would have chosen
>> automatically. It seems like it might be a bug, but I'm not qualified to
>> judge that.
>> 
>> If I am interpreting your results correctly, it means that either of the
>> two extremes is safe: either everything that needs to bind to a source
>> address should call bind with IP_BIND_ADDRESS_NO_PORT, or else
>> everything (whether it needs a specific source address or not) should
>> call bind *without* IP_BIND_ADDRESS_NO_PORT. (The latter situation is
>> what we've arrived at on the Snowflake bridge.) The middle ground, where
>> some connections use IP_BIND_ADDRESS_NO_PORT and some do not, is what
>> causes trouble, because connections that do not use
>> IP_BIND_ADDRESS_NO_PORT somehow "poison" the ephemeral port pool for
>> connections that do use IP_BIND_ADDRESS_NO_PORT (and for connection

Re: [tor-relays] inet_csk_bind_conflict

[Christopher Sheats]

> May I ask what your set up is?
> Are you running your relays on separate VMs on the main system or are
> you using a different set up like having all IP addresses on the same OS
> and using OutboundBindAddress , routing, etc... to separate them? If I
> know more, I might be able to make a script specific to your set up.

Thank you. Yes, of course.

Ubuntu server 22.04 runs on bare metal. Ansible-relayor manages 20 exit relays 
on each system. Netplan has each IP individually listed (sub-divided as a /25 
per server from within a dedicated /24, similarly for v6 addresses). I believe 
an available IP is randomly picked by ansible-relayor and used statically in 
each torrc file.

Here is an example torrc:

# ansible-relayor generated torrc configuration file
# Note: manual changes will be OVERWRITTEN on the next ansible-playbook run

OfflineMasterKey 1
RunAsDaemon 0
Log notice syslog
OutboundBindAddress 23.129.64.130
SocksPort 0
User _tor-23.129.64.130_443
DataDirectory /var/lib/tor-instances/23.129.64.130_443
ORPort 23.129.64.130:443
ORPort [2620:18c:0:192::130]:443
OutboundBindAddress [2620:18c:0:192::130]

DirPort 23.129.64.130:80
Address 23.129.64.130

SyslogIdentityTag 23.129.64.130_443

ControlSocket /var/run/tor-instances/23.129.64.130_443/control GroupWritable 
RelaxDirModeCheck

Nickname ageis
ContactInfo url:emeraldonion.org proof:uri-rsa ciissversion:2 
t...@emeraldonion.org

Sandbox 1
NoExec 1

# we are an exit relay!
ExitRelay 1
IPv6Exit 1
DirPort [2620:18c:0:192::130]:80 NoAdvertise
DirPortFrontPage /etc/tor/instances/tor-exit-notice.html


ExitPolicy reject 23.129.64.128/25:*,reject6 [2613:18c:0:192::]/64:*,accept 
*:*,accept6 *:*


MyFamily 
# end of torrc


--
Christopher Sheats (yawnbox)
Executive Director
Emerald Onion
Signal: +1 206.739.3390
Website: https://emeraldonion.org/
Mastodon: https://digitalcourage.social/@EmeraldOnion/




> On Dec 4, 2022, at 10:08 PM, Chris  wrote:
> 
> Sorry to hear it wasn't much help. Even though the additions I suggested
> didn't help they certainly couldn't cause any harm and can't be
> responsible for the drops in traffic.
> 
> As for the torutils scripts, I'm sure toralf would be able to better
> investigate that but I have a feeling you have a certain set up that
> might not have worked with the script. May I ask what your set up is?
> Are you running your relays on separate VMs on the main system or are
> you using a different set up like having all IP addresses on the same OS
> and using OutboundBindAddress , routing, etc... to separate them? If I
> know more, I might be able to make a script specific to your set up.
> 
> On 12/3/2022 2:07 PM, Christopher Sheats wrote:
>> Hello,
>> 
>> Thank you for this information. After 24-hours of testing, these
>> configurations brought Tor to a halt.
>> 
>> At first I started with the sysctl modifications. After a few hours
>> with just that, there was no improvement in ~75%
>> inet_csk_bind_conflict utilization. I then installed Torutils for both
>> IPv4 and IPv6. After only a couple of hours, Tor dropped to below 15
>> Mbps across both servers (40 relays). 16 hours later, Tor dropped
>> below 2 Mbps.
>> 
>> I've removed all of these new settings and restarted.
>> 
>> --
>> Christopher Sheats (yawnbox)
>> Executive Director
>> Emerald Onion
>> Signal: +1 206.739.3390
>> Website: https://emeraldonion.org/
>> Mastodon: https://digitalcourage.social/@EmeraldOnion/
>> 
>> 
>> 
>> 
>>> On Dec 2, 2022, at 7:30 AM, Chris  wrote:
>>> 
>>> Hi,
>>> 
>>> As I'm sure you've already gathered, your system is maxing out trying to
>>> deal with all the connection requests. When inet_csk_get_port is called
>>> and the port is found to be occupied then inet_csk_bind_conflict is
>>> called to resolve the conflict. So in normal circumstances you shouldn't
>>> see it in perf top much less at 79%. There are two ways to deal with it,
>>> and each method should be complimented by the other. One way is to try
>>> to increase the number of ports and reduce the wait time which you have
>>> somehow tried. I would add the following:
>>> 
>>> net.ipv4.tcp_fin_timeout = 20
>>> 
>>> net.ipv4.tcp_max_tw_buckets = 1200
>>> 
>>> net.ipv4.tcp_keepalive_time = 1200
>>> 
>>> net.ipv4.tcp_syncookies = 1
>>> 
>>> net.ipv4.tcp_max_syn_backlog = 8192
>>> 
>>> The complimentary method to the above is to lower the number of
>>> connection requests by removing the frivolous connection requests out of
>>> the equation using a few iptables rules.
>>> 
>>> I'm assuming the increased load you're experi

Re: [tor-relays] inet_csk_bind_conflict

[Christopher Sheats]

server1:~$ ss -s
Total: 454644
TCP:   465840 (estab 368011, closed 36634, orphaned 7619, timewait 11466)

Transport Total IPIPv6
RAW   0 0 0
UDP   48480
TCP   42920641381515391
INET  42925441386315391
FRAG  0 0 0

81% inet_csk_bind_conflict

server2:~$ ss -s
Total: 460089
TCP:   477026 (estab 367786, closed 42817, orphaned 7456, timewait 17239)

Transport Total IPIPv6
RAW   0 0 0
UDP   71710
TCP   43420941823515974
INET  43428041830615974
FRAG  1 1 0

80% inet_csk_bind_conflict

(total combined throughput at the time of measurement was ~650 Mbps symmetrical 
per transit provider metrics, this low throughput volume is common when 
inet_csk_bind_conflict is this high)

Re OutboundBindAddress - yes, for both v4 and v6

Re kernel version - 5.15.0-56-generic (jammy). Foundation for Applied Privacy 
recommended that we try the nightly repo which apparently includes the 
IP_BIND_ADDRESS_NO_PORT change. However that merge request mentions a 
workaround of modifying net.ipv4.ip_local_port_range, which we've already 
performed.

--
Christopher Sheats (yawnbox)
Executive Director
Emerald Onion
Signal: +1 206.739.3390
Website: https://emeraldonion.org/
Mastodon: https://digitalcourage.social/@EmeraldOnion/




> On Dec 3, 2022, at 3:02 AM, Anders Trier Olesen 
>  wrote:
> 
> Hi Christopher
> 
> How many open connections do you have? (`ss -s`)
> Do you happen to use OutboundBindAddress in your torrc?
> 
> What I think we need is for the Tor developers to include this PR in a 
> release: https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/579
> Once that has happened, I think the problem should go away, as long as you 
> run a recent enough Linux kernel that supports IP_BIND_ADDRESS_NO_PORT (since 
> Linux 4.2).
> 
> - Anders
> 
> 
> 
> 
> fre. 2. dec. 2022 kl. 09.24 skrev Christopher Sheats 
> mailto:yawn...@emeraldonion.org>>:
>> Hello tor-relays,
>> 
>> We are using Ubuntu server currently for our exit relays. Occasionally, exit 
>> throughput will drop from ~4Gbps down to ~200Mbps and the only observable 
>> data point that we have is a significant increase in inet_csk_bind_conflict, 
>> as seen via 'perf top', where it will hit 85% [kernel] utilization.
>> 
>> A while back we thought we solved with with two /etc/sysctl.conf settings:
>> net.ipv4.ip_local_port_range = 1024 65535
>> net.ipv4.tcp_tw_reuse = 1
>> 
>> However we are still experiencing this problem.
>> 
>> Both of our (currently, two) relay servers suffer from the same problem, at 
>> the same time. They are AMD Epyc 7402P bare-metal servers each with 96GB 
>> RAM, each has 20 exit relays on them. This issue persists after upgrading to 
>> 0.4.7.11.
>> 
>> Screenshots of perf top are shared here: 
>> https://digitalcourage.social/@EmeraldOnion/109440197076214023
>> 
>> Does anyone have experience troubleshooting and/or fixing this problem?
>> 
>> Cheers,
>> 
>> --
>> Christopher Sheats (yawnbox)
>> Executive Director
>> Emerald Onion
>> Signal: +1 206.739.3390
>> Website: https://emeraldonion.org/
>> Mastodon: https://digitalcourage.social/@EmeraldOnion/
>> 
>> 
>> 
>> 
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org <mailto: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



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

Re: [tor-relays] inet_csk_bind_conflict

[Christopher Sheats]

Hello,

Thank you for this information. After 24-hours of testing, these configurations 
brought Tor to a halt.

At first I started with the sysctl modifications. After a few hours with just 
that, there was no improvement in ~75% inet_csk_bind_conflict utilization. I 
then installed Torutils for both IPv4 and IPv6. After only a couple of hours, 
Tor dropped to below 15 Mbps across both servers (40 relays). 16 hours later, 
Tor dropped below 2 Mbps.

I've removed all of these new settings and restarted.

--
Christopher Sheats (yawnbox)
Executive Director
Emerald Onion
Signal: +1 206.739.3390
Website: https://emeraldonion.org/
Mastodon: https://digitalcourage.social/@EmeraldOnion/




> On Dec 2, 2022, at 7:30 AM, Chris  wrote:
> 
> Hi,
> 
> As I'm sure you've already gathered, your system is maxing out trying to
> deal with all the connection requests. When inet_csk_get_port is called
> and the port is found to be occupied then inet_csk_bind_conflict is
> called to resolve the conflict. So in normal circumstances you shouldn't
> see it in perf top much less at 79%. There are two ways to deal with it,
> and each method should be complimented by the other. One way is to try
> to increase the number of ports and reduce the wait time which you have
> somehow tried. I would add the following:
> 
> net.ipv4.tcp_fin_timeout = 20
> 
> net.ipv4.tcp_max_tw_buckets = 1200
> 
> net.ipv4.tcp_keepalive_time = 1200
> 
> net.ipv4.tcp_syncookies = 1
> 
> net.ipv4.tcp_max_syn_backlog = 8192
> 
> The complimentary method to the above is to lower the number of
> connection requests by removing the frivolous connection requests out of
> the equation using a few iptables rules.
> 
> I'm assuming the increased load you're experiencing is due to the
> current DDos attacks and I'm not sure if you're using anything to
> mitigate that but you should consider it.
> 
> You may find something useful at the following  links
> 
> [1](https://github.com/Enkidu-6/tor-ddos)
> 
> [2](https://github.com/toralf/torutils)
> 
> [background](https://gitlab.torproject.org/tpo/community/support/-/issues/40093)
> 
> Cheers.
> 
> On 12/1/2022 3:35 PM, Christopher Sheats wrote:
>> Hello tor-relays,
>> 
>> We are using Ubuntu server currently for our exit relays.
>> Occasionally, exit throughput will drop from ~4Gbps down to ~200Mbps
>> and the only observable data point that we have is a significant
>> increase in inet_csk_bind_conflict, as seen via 'perf top', where it
>> will hit 85% [kernel] utilization.
>> 
>> A while back we thought we solved with with two /etc/sysctl.conf settings:
>> net.ipv4.ip_local_port_range = 1024 65535
>> net.ipv4.tcp_tw_reuse = 1
>> 
>> However we are still experiencing this problem.
>> 
>> Both of our (currently, two) relay servers suffer from the same
>> problem, at the same time. They are AMD Epyc 7402P bare-metal servers
>> each with 96GB RAM, each has 20 exit relays on them. This issue
>> persists after upgrading to 0.4.7.11.
>> 
>> Screenshots of perf top are shared
>> here: https://digitalcourage.social/@EmeraldOnion/109440197076214023
>> 
>> Does anyone have experience troubleshooting and/or fixing this problem?
>> 
>> Cheers,
>> 
>> --
>> Christopher Sheats (yawnbox)
>> Executive Director
>> Emerald Onion
>> Signal: +1 206.739.3390
>> Website: https://emeraldonion.org/
>> Mastodon: https://digitalcourage.social/@EmeraldOnion/
>> 
>> 
>> 
>> 
>> 
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



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

[tor-relays] inet_csk_bind_conflict

[Christopher Sheats]

Hello tor-relays,

We are using Ubuntu server currently for our exit relays. Occasionally, exit 
throughput will drop from ~4Gbps down to ~200Mbps and the only observable data 
point that we have is a significant increase in inet_csk_bind_conflict, as seen 
via 'perf top', where it will hit 85% [kernel] utilization.

A while back we thought we solved with with two /etc/sysctl.conf settings:
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1

However we are still experiencing this problem.

Both of our (currently, two) relay servers suffer from the same problem, at the 
same time. They are AMD Epyc 7402P bare-metal servers each with 96GB RAM, each 
has 20 exit relays on them. This issue persists after upgrading to 0.4.7.11.

Screenshots of perf top are shared here: 
https://digitalcourage.social/@EmeraldOnion/109440197076214023

Does anyone have experience troubleshooting and/or fixing this problem?

Cheers,

--
Christopher Sheats (yawnbox)
Executive Director
Emerald Onion
Signal: +1 206.739.3390
Website: https://emeraldonion.org/
Mastodon: https://digitalcourage.social/@EmeraldOnion/






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

[tor-relays] problem with new obfs4 bridge

[Christopher Sheats]

 (conn): Connecting to a relay
Mar 26 11:38:37.000 [notice] Opening Socks listener on /run/tor/socks
Mar 26 11:38:37.000 [notice] Opened Socks listener connection (ready) on 
/run/tor/socks
Mar 26 11:38:37.000 [notice] Opening Control listener on /run/tor/control
Mar 26 11:38:37.000 [notice] Opened Control listener connection (ready) on 
/run/tor/control
Mar 26 11:38:37.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Mar 26 11:38:37.000 [notice] Bootstrapped 14% (handshake): Handshaking with a 
relay
Mar 26 11:38:37.000 [notice] Bootstrapped 15% (handshake_done): Handshake with 
a relay done
Mar 26 11:38:37.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough 
directory info to build circuits
Mar 26 11:38:37.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake 
finished with a relay to build circuits
Mar 26 11:38:37.000 [notice] Bootstrapped 95% (circuit_create): Establishing a 
Tor circuit
Mar 26 11:38:38.000 [notice] Bootstrapped 100% (done): Done
Mar 26 11:38:38.000 [notice] Now checking whether IPv4 ORPort 23.129.64.194:80 
is reachable... (this may take up to 20 minutes -- look for log messages 
indicating success)
Mar 26 11:38:38.000 [notice] Now checking whether IPv6 ORPort 
[2620:18c:0:192::194]:80 is reachable... (this may take up to 20 minutes -- 
look for log messages indicating success)
Mar 26 11:38:39.000 [notice] Self-testing indicates your ORPort 
[2620:18c:0:192::194]:80 is reachable from the outside. Excellent.
Mar 26 11:38:39.000 [notice] Self-testing indicates your ORPort 
23.129.64.194:80 is reachable from the outside. Excellent. Publishing server 
descriptor.
Mar 26 11:40:32.000 [notice] Performing bandwidth self-test...done.

A prior torrc config set the IPs explicitly, but had the same result:

ServerTransportListenAddr obfs4 23.129.64.194:443
ServerTransportListenAddr obfs4 [2620:18c:0:192::194]:443

I can provide debug logs as necessary. Possibly of note, our firewall does not 
use connection tracking and applies the same rules as our exit relays which use 
the same ports.

Pro-active note: The bridge shares the same 23.129.64.0/24 subnet as Emerald 
Onion's Tor exit relays, so there is no risk of a user entering and exiting our 
physical network (see "2.2. Path selection and constraints"): 
https://github.com/torproject/torspec/blob/master/path-spec.txt

Cheers,

--
Christopher Sheats
Executive Director for Emerald Onion
Email: yawn...@emeraldonion.org
Phone: +1 206-739-3390
Web: https://emeraldonion.org/

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

Re: [tor-relays] DDoS’d offline

[Christopher Sheats]

 -0700 23.129.64.183 1810 mbps
2019-10-30 13:26:23 -0700 23.129.64.187 1786 mbps
2019-10-30 13:26:24 -0700 23.129.64.184 1870 mbps
2019-10-30 13:26:24 -0700 23.129.64.189 1796 mbps
2019-10-30 13:26:24 -0700 23.129.64.182 1868 mbps
2019-10-30 13:26:24 -0700 23.129.64.186 1872 mbps
2019-10-30 13:26:24 -0700 23.129.64.190 1751 mbps
2019-10-30 13:26:24 -0700 23.129.64.192 1828 mbps
2019-10-30 13:26:24 -0700 23.129.64.194 1891 mbps
2019-10-30 13:26:24 -0700 23.129.64.196 1801 mbps
2019-10-30 13:26:24 -0700 23.129.64.195 1814 mbps
2019-10-30 13:26:24 -0700 23.129.64.201 1849 mbps
2019-10-30 13:26:24 -0700 23.129.64.203 1894 mbps
2019-10-30 13:26:24 -0700 23.129.64.206 1885 mbps
2019-10-30 13:26:24 -0700 23.129.64.208 1801 mbps
2019-10-30 13:26:24 -0700 23.129.64.210 1840 mbps
2019-10-30 13:26:24 -0700 23.129.64.211 1853 mbps
2019-10-30 13:26:24 -0700 23.129.64.212 1776 mbps
2019-10-30 13:26:24 -0700 23.129.64.213 1818 mbps
2019-10-30 13:26:24 -0700 23.129.64.216 1945 mbps
2019-10-30 13:26:24 -0700 23.129.64.215 1729 mbps



--
Christopher Sheats
Executive Director for Emerald Onion
Email: yawn...@emeraldonion.org
Office (& Signal): +1-206-739-3390
Website: https://emeraldonion.org/

From: tor-relays  on behalf of 
Christopher Sheats 
Sent: Wednesday, October 30, 2019 5:26:21 PM
To: tor-relays@lists.torproject.org 
Subject: [tor-relays] DDoS’d offline

fyi

https://twitter.com/EmeraldOnion/status/1189668679752900608

Calyx appears to have been hit also, but not offline

https://twitter.com/calyxinstitute/status/1189693027192840192


--
Christopher Sheats
Executive Director for Emerald Onion
Email: yawn...@emeraldonion.org
Office (& Signal): +1-206-739-3390
Website: https://emeraldonion.org/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] DDoS’d offline

[Christopher Sheats]

fyi

https://twitter.com/EmeraldOnion/status/1189668679752900608

Calyx appears to have been hit also, but not offline

https://twitter.com/calyxinstitute/status/1189693027192840192


--
Christopher Sheats
Executive Director for Emerald Onion
Email: yawn...@emeraldonion.org
Office (& Signal): +1-206-739-3390
Website: https://emeraldonion.org/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Emerald Onion's new relays

[Christopher Sheats]

Hello,

Just a report-back: https://twitter.com/EmeraldOnion/status/1160694122069422080

"It took us 128 days to go from 1Gbps to 10Gbps advertised bandwidth with the 
progressive deployment of up to 56 relays (April 2 to August 8, 2019). In terms 
of actual bandwidth, we have a sustained throughout of roughly 5-6Gbps. We can 
sustain up to 15Gbps and burst to 20Gbps."

Currently we're the fifth largest exit family at 1.2220% consensus weight, 
1247.67 MiB/s advertised bandwidth, and 5.5546% exit probability. It 
costs us $1,600 per month, in donations, to manage this service. As you may 
know, we are all volunteers.

There was some additional feedback that we got from Nusenu regarding capping 
bandwidth of individual Tor processes, and using a second IP for exit traffic. 
We are still trying to determine the per-process max bandwidth on our two 
hardware platforms, but we are planning on enabling these caps for quality of 
the service.

When we originally deployed many new relays using Ansible-Relayor, we used a 
second IP per process. However, due to routing troubleshooting and relays not 
showing up on Relay Search, we removed the second IPs. We are still using only 
one per relay. We also found it challenging to manage this many relay IPs with 
Ansible-Relayor. Ansible-Relayor uses sequential IPs based on the listing from 
ifconfig. This presents a challenge because it is difficult to setup forward 
and reverse DNS in a predictable way.

The second issue we have with running a secondary IP per Tor process is system 
load. Having more IPs opens more sockets, and we are already putting a lot of 
load on these multi-core servers. The third issue is that when people block our 
IPs, they block the scope. Should we use a secondary IP per relay if the IP is 
in the same scope? Should we then use two /24 scopes, and wouldn't both scopes 
end up getting blocked? If we were to use a second /24 for relays, how will 
Ansible-Relayor know to use a second IP scope for exiting?

IPv4 dependency is a real burden. We would like to see Tor Project help Tor 
network operators more directly, both financially and securing IPv4 scopes for 
nonprofit organizations to take ownership of. The latter is needed until we can 
stop using IPv4 completely and operate only with IPv6.

It is discouraging to see so many small and large network operators not using 
IPv6. Why is this such a problem? Tor Project, please increase your #IPv6 
awareness/outreach similar to how ARIN and the other RIRs try very hard to do.

Cheers,

--
Christopher Sheats
Executive Director for Emerald Onion
Email: yawn...@emeraldonion.org
Office (& Signal): +1-206-739-3390
Website: https://emeraldonion.org/

-Original Message-
From: tor-relays  On Behalf Of grarpamp
Sent: Thursday, April 4, 2019 12:45 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Emerald Onion's new relays

On 4/4/19, Conrad Rockenhaus  wrote:
>> when ISPs are ordered to BGP blackhole some exit IP addresses

> I've been assigning a second set of IP addresses to my servers in case 
> I want to run another instance of Tor. Would it be more prudent to use 
> that second set of IP addresses as an OutboundBindAddressExit instead 
> and use different ports as a better practice?

ISP traffic filtering sinks,  from the tor browser perspective, affecting 
traffic exiting a relay out through its exitpolicy to clearnet, can be...

- dst based "sink traffic to there", appears as "cnn.com down", a minor issue, 
depending on scope of the sink.

- src based "sink traffic from there", appears as "Internet down", a major 
issue, depending on scope of the sink.

Unlike websites, and unless they're tied playing [geo]politics, ISP's really 
don't like to keep these sinks in place for a long time.


Relay management such as OS updates, ssh, wget could get blocked if those 
addresses are in consensus.

Then there is relay-to-relay traffic types that don't "exit", but can still get 
found and blocked.

And the OR IP must be obviously not be blocked, else depending on scope, the 
relay won't receive traffic to move out any horizon.

Tor should still allow config of 2 tor instances on one IP.

If IP's are "free", and if operator survey says the exit functions are getting 
knocked off the tor network more often than entire OR's, try putting out the 
OutboundBindAddressExit on IP for sacrifice, instead of burning entire OR's 
which could otherwise be used more quietly as middle relays etc.

An operators own cost, management, and ISP relationships may show running more 
relays is better IP, or net traffic pushed, wise than enduring a few sinks now 
and then.

Probably every situation is different. Or try both and see.


Common options from the manpage...

   Address address
   ORPort [address:]PORT|auto [flags]
   OutboundBindAddress IP
   OutboundBindAddressOR IP

[tor-relays] Emerald Onion's new relays

[Christopher Sheats]

Hello,

Beginning this Wednesday, 2019-Apr-03, Emerald Onion will be starting 40 new 
uncapped and unfiltered exit relays using HardenedBSD in Seattle. We will turn 
on 10 new relays per day and be monitoring performance. In tandem, we will be 
publishing our updated edge routing and Tor relay configurations on our Github. 
We'll also publish an updated transparency report (spoiler: zero new requests). 
This work is part of our efforts to saturate our new unmetered 10Gbps transit 
link in the Westin data center. There we peer with the Seattle Internet 
Exchange with a separate 10Gbps connection. We'll be using our existing IP 
scopes:

2620:18C::/36
23.129.64.0/24

We are in the process of creating an RPKI ROA for our prefixes, and we are 
still rebuilding our DNS resolver (thanks nusenu for the feedback). These 
things will be completed before we turn on the new relays.

If you donated to Emerald Onion (a 501(c)(3)) nonprofit), thank you! We'll be 
naming the relays accordingly. We will still accept new donations for relay 
naming rights-- email me directly for more information. Lastly, and If you're 
unaware, I spoke about our work at DEFCON 26: 
https://www.youtube.com/watch?v=cs6a1i4Owic

Cheers,

--
Christopher Sheats
Executive Director for Emerald Onion
Email: yawn...@emeraldonion.org
Office (& Signal): +1-206-739-3390
Website: https://emeraldonion.org/

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

Re: [tor-relays] About relay size

[Christopher]

Hi IPonU, Thanks for running a relay.

As I understand it, running one larger relay may be better. Traffic
correlation attacks by a global persistent adversary might have a harder
time due to the fact that more circuits are using one IP, rather than less
circuits spread across multiple IPs. In no way is this a cure-all, but it
might help.

Cheers


On Fri, Sep 29, 2017 at 12:37 AM IPonU  wrote:

> Hi Tor list,
>
> I'm already running a small exit node (100Mbps bandwidth) and I'm ready
> to spend more money on it, so have a question for you guys :
>
> Is it better if I run other small ones (100Mbps too) or only 1 big exit
> relay (1 Gbps) ? What's best for the network stability/security ?
>
> Thanks a lot
>
> IPonU
>
>
> ___
> 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] Individual Operator Exit Probability Threshold

[Christopher]

Hey John!

In Seattle, as you know, Emerald Onion is now online. We're at about
1.5% right now. We're grant writing, too, and hopefully within the
next year we will be able to support 5-10%.

Have you published any Warrant Canaries? We're working with Calyx on a
generic template for relay operators and hope to start publishing one
every month, soon. Also, we've been working closely with HardenedBSD.
Are you able to increase either software or hardware (not Intel)
capacity?

If you have time, Emerald Onion is working on material to help others
become their own ISP like Quintex and Emerald Onion have. We'll be
focusing on sustainable nonprofit ISPs. One of our drivers is finding
people near IXPs in the USA to help get started:
https://emeraldonion.org/internet-exchange-points-in-the-united-states/

Like Teor mentioned, it's important for operators to increase capacity
and stability, while still meaningfully supporting diversity. Emerald
Onion is not going to surpass 10% of exit capacity without first
helping ~10 other groups set up and manage their own 1%+ relays. As
more and more high-capacity groups come online, I think orgs like
Quintex and Emerald Onion can slowly increase capacity but stick
around the 10% line.

I applaud you for your work!

Cheers,

yawnbox


On Fri, Sep 22, 2017 at 6:26 AM, teor  wrote:
>
>> On 22 Sep 2017, at 23:04, John Ricketts  wrote:
>>
>> All,
>>
>> I have brought this question  up in meetings in Seattle and other places so 
>> some of you may have already heard me ask this question.  So, at risk of 
>> repeating the question for some... here goes.
>>
>> I am about to fire up more Exit Relays  and if I do so I will jump from my 
>> roughly 3% of Exit Probability to what technically could easily reach 6-8%.
>>
>> I would like to know everyone’s opinion on having an individual operator 
>> have that much exit share.  In my case, all the traffic would be coming from 
>> the same AS as well, but distributed over four different cities with 
>> different upstream carriers.
>>
>> Please chime in, if I get the a green light from the discussion it will 
>> happen within a month.
>
> Thank you for supporting Tor!
> And thank you for asking in advance.
>
> More exit relays are good, and we should encourage people who want to
> help the network.
>
> This is a reminder that we need more exit operators, running more large
> exits. If we think your exit share is a problem, the best way to make
> that problem go away is to add other exits.
>
> We're also working on better geographic diversity in bandwidth
> authorities, and this may cause relay weights to shift a bit. So that's
> another way we could end up resolving this issue :-)
>
> T
>
> --
> Tim Wilson-Brown (teor)
>
> teor2345 at gmail dot com
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> ricochet:ekmygaiu4rzgsk6n
> xmpp: teor at torproject dot org
> 
>
>
>
>
> ___
> 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] Any IP allocations available out there?

[Christopher]

Hi,

On Wed, Aug 23, 2017 at 5:29 PM, Paul Templeton  wrote:
> Thanx to all here on the list for input to earlier posts. Helped a lot.
>
> Question I have is there anywhere where you can get a block of IP address or 
> lease as I'm in the process of getting a 10/10Mb SHDSL service(No flaming 
> data cap :-)) here in AU but I want an IP range that abuse questions can be 
> forwarded to me. The service provider doesn't provide ARIN registration but 
> said if I have my own block I can update the BG and manage it my self.

If you're interested in becoming your own ISP (obtaining your own ASN,
IPv6 and IPv4 scopes), you'll need to apply via APNIC, as I did in the
US with ARIN. Here is an example:

1. Find co-location space in AU with good prices. Be transparent and
educational about what you plan on doing so your provider isn't
surprised. You would need to get a quote from them for 2U of space, 2
amps of power, 100Mbps commit on a 1G port, and a /28 or greater. You
need two low power systems, one router (pfsense, opnsense, etc) for
BGP and general routing, and one system for Tor processes. You will
run middle relays until you get your own IP scopes -- rDNS and SWIP is
not enough to get all abuse to come directly to you.

2. Once you have your /28 (etc) IPv4 scope (Tor still depends on v4),
you can apply to APNIC for ASN and IP scopes. I encourage you to
prioritize IPv6, but v4 is still required. You need to show current IP
usage in order to apply for, and be granted, your own IP scopes
(chicken before the egg). ARIN is $550 for ASN, and $500 each for v6
(/36) and v4 (/24) scopes. Each item is $100 recurring annually, but I
don't know what APNIC charges for any of those things.

3. Once you have your own AS and IPs, you'll need to sign a BGP Letter
of Agency (LOA) with your transit provider so they can announce your
IP scopes upstream. Then you can then change your IPs and begin exit
relaying if you're comfortable with that.

So, there's lots of details that I didn't go into, obviously this
example depends on many things and also requires knowledge of certain
systems and legality. Doing all of this will require a couple thousand
dollars and fortitude, especially if you are new to networking. Happy
to help further if needed.

Cheers,

Yawnbox
https://emeraldonion.org/


>
> Regards,
>
> Paul
> PS - the best price I can do at the moment is $550pm - *SIGH* - but worth it.
> ___
> 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] IXPs in the United States

[Christopher]

Hello,

Emerald Onion (https://twitter.com/EmeraldOnion) is researching
Internet Exchange Points in the United States in order to bolster Tor
relay deployments within our legal jurisdiction. We have blogged a
list of IXPs we've identified so far:

https://emeraldonion.org/internet-exchange-points-in-the-united-states/

Please note that Emerald Onion would not be the org to deploy more
relays in other cities. We are interested in helping others in those
regions become their own ISP. (See
https://emeraldonion.org/development/ for related education.)

1. Are there any Tor routers connected to any United States-based
IXPs? If so, which ones and who operates them?

We know of at least four:

a. Calyx Institute on NYIIX https://www.peeringdb.com/net/4594
b. XMission on Equinix Ashburn, SIX Seattle, and SLIX
https://www.peeringdb.com/net/789
c. Riseup Networks on SIX Seattle https://www.peeringdb.com/net/9021
d. Emerald Onion on SIX Seattle https://www.peeringdb.com/net/14010

2. Is this IXP friendly to Tor?

3. What is the organizational structure of this IXP? Such as
corporate-run or community-driven, etc.

Please let me know if you have any helpful information. I'm also
reachable via Signal.

https://yawnbox.com/contact/

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

[tor-relays] my provider null routed my exit. advice?

[Christopher Yeager]

Hello,

I run a 100mb exit hosted at server.lu since sometime in late 2013. There
have been a couple dozen abuse reports but normally they forward them to me
to deal with and nothing much happens. However a week or so ago, while I
was travelling, there was an abuse report that made them decide to file a
ticket which then led to them suspending my IP as I 'ignored' it while I
was gone. So now I'm trying to convince them to turn the system back on and
they are pushing back, and after some back and forth they say they want me
to run an exit policy consisting of ports 53, 80, and 443. I've been
running the suggested reduced exit policy since day one and am very
reluctant to pare it down further, and certainly not to just 3 ports. I
wrote a short note explaining my point of view and I wonder if any of you
would do me the courtesy of telling me if I am likely to convince them to
let me leave the exit policy alone. I'm very willing to edit my response as
required. I think it bears mentioning that I am several messages in and I
did not get a good sense that whoever I am talking to understands Tor very
well at all - I was repeatedly asked to find and block my customer, and
told I must have logs if I provide a service, etc. I can show you the
longer exchange if you think it might be helpful. Thanks in advance and
here goes:

---
Hello,

We have nothing against Tor but IP is listed at 11 blacklists including
Spamhaus ZEN.
So we have to ask you block all ports except 80, 53 and 443 to prevent
scan, spam and other infringing activity from your IP.
Hope such proposal will be suitable for you.

Regards,
ROOT S.A.

---

Hello again,

I would rather not block any more ports that are already blocked. The
system is already set up to use the reduced exit policy detailed at
https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy which
allows as many Internet services as possible while still blocking the
majority of TCP ports. Currently, the policy allows approximately 65 ports.
I am reluctant to further reduce the ports because there is vastly more to
the internet than just the world wide web. Email, chat, remote desktop,
cache, and vpn services are all valid uses of the network that would not be
allowed by such a restrictive exit policy. I'm also afraid that it will not
help much in getting this IP off the various blocklists that it is on, as
2/3rds of the abuse reports I've been sent were due to traffic on ports 80
or 443. Several of the lists such as SECTOOR and Dans TOREXIT and related
are simply reporting to the world that this system is a Tor node. The
system is only in the Spamhaus Zen list due to its listing in the CBL for
being infected with, or is NATting for a machine infected with s_vawtrak
which is a Microsoft Windows virus that connected to their sinkhole IP on
port 80. Being on blocklists is something that happens when you are running
a Tor exit node and supporting Tor means putting up with them and
explaining why Tor is worth supporting even though abuse is guaranteed to
happen.

Naturally if you require this change I will be forced to make it. I hope,
however, that you can be persuaded that it is not helpful to Tor and will
not solve the problem of abuse and blacklists even if it were. Thanks again.

--

Thanks for getting this far. I await your replies with interest. :)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Contacting Apple About a Block IP Address

[Christopher Burg]

Hey fellow relay operators,

While searching for a solution to a problem I've been having I learned that my 
IP has been blocked from accessing discussions.apple.com. The message that I 
get is the same message I get whenever I attempt to access a website known to 
block IP addresses operating Tor relays. I am running a non-exit relay, which 
I'm assuming is the reason I'm now blocked from access the site.

Has anybody else run into this problem and, if so, have you been able to get 
your IP address unblocked by Apple? If you have managed to get your IP 
unblocked what steps did you take? Unfortunately due to my work I am in a 
position where I have to access Apple's discussion forums from time to time.

Thanks,




Christopher Burg


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Why is UFW bllocking allowed TOR traffic?

[Christopher Sheats]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Jeff

On 06/22/2014 12:43 PM, Jeff Odell wrote:
 I was monitoring UFW today and noticed that it was periodically blocking 
 allowed TOR traffic.  any
ideas why from those with more experience than I?


 toradmin@IrvineTorExit:~$ sudo ufw status
 Status: active

 To Action  From
 -- --  
 22 ALLOW   Anywhere
 9001/tcp   ALLOW   Anywhere
 9030/tcp   ALLOW   Anywhere
 80 ALLOW   Anywhere
 22 (v6)ALLOW   Anywhere (v6)
 9001/tcp (v6)  ALLOW   Anywhere (v6)
 9030/tcp (v6)  ALLOW   Anywhere (v6)
 80 (v6)ALLOW   Anywhere (v6)


 toradmin@IrvineTorExit:~$ sudo tail -f /var/log/syslog | grep DPT=9001

 Jun 22 15:38:12 IrvineTorExit kernel: [ 2159.246977] [UFW BLOCK]
IN=eth0 OUT= MAC=04:01:1b:5e:9a:01:28:8a:1c:64:cf:f0:08:00
SRC=92.108.200.200 DST=188.226.199.250 LEN=52 TOS=0x00 PREC=0x00 TTL=120
ID=10392 DF PROTO=TCP SPT=52000 DPT=9001 WINDOW=16652 RES=0x00 ACK URGP=0
 Jun 22 15:38:12 IrvineTorExit kernel: [ 2159.246988] [UFW BLOCK]
IN=eth0 OUT= MAC=04:01:1b:5e:9a:01:28:8a:1c:64:cf:f0:08:00
SRC=92.108.200.200 DST=188.226.199.250 LEN=52 TOS=0x00 PREC=0x00 TTL=120
ID=10396 DF PROTO=TCP SPT=52000 DPT=9001 WINDOW=16652 RES=0x00 ACK URGP=0

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

I see a considerable amount of these in my logs (Ubuntu 14.04 server,
UFW). Some time ago I asked about this on IRC with no resolve. I'm
afraid of it affecting Tor users (I don't know if it is), and I'm afraid
of these logs being created and stored on my exit relay. Because I have
received no answer, yet need to protect my relay with a manageable
firewall, I took the advice of someone on IRC and disabled my UFW logs
(my exit relay isn't used for anything else, and UFW will keep doing
it's job, while protecting the privacy of Tor users).

You can do this too via:

sudo ufw logging off

By the way, you may wish to limit port 22 instead, to prevent SSH
brute force attacks.

sudo ufw limit 22/tcp

(I don't allow 22/udp)

hope this helps a little.

- -- 
Christopher Sheats
yawn...@gmail.com
GnuPG: 8397 7B9F D8BA 3EE5 71EF FDF3 C761 02B0 A531 D73D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTtJnGAAoJEMdhArClMdc9eSUP/2XrazjtRQm1Z9rZrGOnWwe1
pJpVuLcsVq34yFIz9xonRnV6DohF+p4Ra1Umq/hnxxJU9X2LOcF44sekhVxguwIO
+LJ/hIE+FGuR1U0nlJiILiLO8vrwYUdfNcZ4EpOO4ZgSe1lG2gC2efeFdYZbXREO
xqmdunUv6bAHpOoWYrWPwG7R0dTQU9Zzf9HbJrjjY+ubQepHr9Wj+FDNp0iRXZYw
V+VFhdGk2FWODQrpbPfX0G7+uf2itM4ONBf76DNbyudefA5E091YjuTUiQhuIal1
Kdb59YsUME0Nxc8apl0WTUbOW0DmCJtIsYKgPlyNoz9/6R7Bi9VTqLWcsrz8xRGa
Z09j1/bzpQ8Cp6HWG92RpfCQfA3KUYKN2jUh/IeQRZfZtIc+viCHNys76PRv209T
hHgjLiNfzWv2PYKoko/ZrB5ZH8OvG8fWtIY2cinc/1rSBobAD88/oWn39EIVeUHu
JfYXBmc3WhYghGPbl4y4bczuKtdcItldLH8RAABTDZ8bFpxqgA1vRbT7oyFOuU+V
iZtbY3EB7CUkN9X8E7DbQoLQxMDXEE36RJ5hnJLe68VE5wMQx8vGwFzoOG125d23
xB8CYIkp+VB5bUDaTD5JHghEmeKH+RKGLpX+ICBy+Bp6/AK4WjXg9I4zERrLAQWL
KdYf6bA/ZUwLrFCZYI6o
=04+T
-END PGP SIGNATURE-


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

[tor-relays] Thanks for the advice on handling DMCA complaints.

[Christopher Jones]

Hey all,

I just wanted to thank the list members for giving me some great advice on 
working with my ISP to deal with the DMCA nastygrams. I restricted my exit 
policy to allow most legitimate TCP services and block the rest, which should 
hopefully disincentivize those damn P2P users from picking my relay as an exit 
in most cases. 

Does the Tor project run a database to track abuse complaints? Could be useful 
in terms of uncovering who the largest pains in the ass are (mine was from 
Irdeto on behalf on NBC Universal), as well as organizing targeted campaigns to 
put pressure on companies like Irdeto to at least perform some due diligence 
and not send out DMCA originating from exit relays. If not, maybe I’ll start 
working on a project to do so if there isn’t something else like it elsewhere.

On another note, I discovered I prefer running Tor on FreeBSD over Linux. Ran 
CentOS for a bit, but somehow encrypting /tmp blew it up and the NOC had to 
re-install the OS. I went with FreeBSD instead and dig it immensely. Pf is much 
less of a headache than IPTables — I actually got port forwarding from 80 to 
9091 and 43 to 9090 working. Administration is more straightforward. I like the 
clear separation of the base system from additional software added from ports. 
Compiling ports, while more time consuming, is a delight compared to some of 
the binary package management issues I’ve had in the past with Linux. FreeBSD 
also appears to manage memory more efficiently. I run Linux as a desktop OS, 
but for a server OS, FreeBSD has won me over with its simplicity, less 
convoluted security (no SELinux — yes I know you can turn it off, but I’m the 
masochist who leaves it on), better support for chroot jails. Just my opinion.

One more question and I’ll probably feel stupid after reading the answers, but 
does “RelayBandwidthRate” apply separately to rx and tx rates or the combined 
throughput of them both? The server I run has an unmetered 100Mb/s connection. 
I’ve got RelayBandwidthRate set to 5MB and RelayBandwidthBurst set to 10MB. 
12.5MB/s being the theoretical max, if I bumped up my bandwidth rate to, say, 
8, would my relay overload the NIC or would it continue to behave?

My server specs are as follows:

FreeBSD 9.2
Dual Core Atom D2500
4GB RAM
2TB SATA drive (encrypted swap and /tmp)
100Mbit unmetered traffic
5 usable IPv4 addresses

At last check, I had 1140 TCP connections according to lsof and vnstat is 
showing throughputs of 13-18Mbit/s rx and 14-19Mbit/s tx. Tor CPU usage is 
about 22-27% according to top.

Does this look reasonable or should I tweak some things like max connections?

Thanks,
Chris

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

Re: [tor-relays] Problems with Debian package and low ports

[Christopher Baines]

On Wed, 2013-02-13 at 17:44 +0100, Wessel Nieboer wrote:
 Op 13-2-2013 17:41, Chris Baines schreef:
  I am having some problems with tor (version 0.2.3.25-1), I get
  warnings when it resumes form hibernation:
  Feb 11 00:00:00.000 [warn] Could not bind to 0.0.0.0:80: Permission denied
  Feb 11 00:00:00.000 [notice] Opening OR listener on 0.0.0.0:443
 
  Can anyone help?
  ___
 Does it work when you've just booted your computer?
 

Yes.


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] Problems with Debian package and low ports

[Christopher Baines]

On Wed, 2013-02-13 at 17:51 +0100, t...@caber.nl wrote:
 Hi Chris,
 
 This is docemented in
 https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#HowcanImakemyrelayaccessibletopeoplestuckbehindrestrictivefirewalls
 
 I hope those instructions will help you.

I have seen those instructions, and as far as I am aware, followed them.
It says that if you use the Debian package, you just set the ports in
the torrc, but this causes the errors mentioned on my system.


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