Re: [tor-relays] monitoring the relay : zabbix?

[Green Dream]

> How do you monitor the tor relay server and the relay itself, on a remote
> box?


I like https://www.statuscake.com/ for this and their free plan is
sufficient. I'm not affiliated with them, I just like the service. It
constantly checks for a response from both the Dir and OR ports of my
relays, using monitoring endpoints around the world, and notifies me
of downtime. It also has a nice feature where it can look for a
specific response from the Dir port (i.e, parse
http://relay1.example.com/tor/server/authority and make sure the
fingerprint matches).
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ISP, Abuses , Intrusion Prevention etc.

[Green Dream]

>> I set up my own ISP (AS28715) so I could run Tor exits etc without any
>> trouble.
>
> Could you share a bit more about what is involved in doing that?


I'd also be very interested in learning more about setting up an ISP
for Tor. Is it a non-profit? How many man hours did it take (roughly)
to get the structure in place? How much money (roughly) did it take?
How much legal consultation did it require to setup?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Politically correct?

[Green Dream]

Tor is not perfect and everyone would be wise to learn as much as
possible about its limitations (I'd start here:
https://www.torproject.org/download/download.html.en#warning). It's
still a very useful privacy tool though.

Snowden: "I think Tor is the most important privacy-enhancing
technology project being used today. I use Tor personally all the
time. We know it works from at least one anecdotal case that’s fairly
familiar to most people at this point. That’s not to say that Tor is
bulletproof. What Tor does is it provides a measure of security and
allows you to disassociate your physical location."
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] new warn message: Duplicate rendezvous cookie in ESTABLISH_RENDEZVOUS.

[Green Dream]

One of my guard relays has a few entries on Oct 06 also:

  Oct 06 09:04:00.000 [warn] Duplicate rendezvous cookie in
ESTABLISH_RENDEZVOUS.
  Oct 06 09:04:00.000 [warn] Duplicate rendezvous cookie in
ESTABLISH_RENDEZVOUS.
  Oct 06 10:17:30.000 [warn] Duplicate rendezvous cookie in
ESTABLISH_RENDEZVOUS.

Times are in UTC. Logs on this machine go back to Oct 03 but those are
the only occurrences. My other guard relay with nearly identical specs
and CW doesn't have these entries.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata

[Green Dream]

@oconor:

> Let me ask you a short question. Have you ever worked with IPS?


Yes. Please see my later email in this thread. I have experience with
Snort, Bro and proprietary IPS/IDS systems from Cisco and Palo Alto. I
also worked at a university's network operations helpdesk, where we
received hundreds of DCMA and abuse requests every week. I'm entirely
aware of the work required. I understand fully you have a job to do,
and I'm not immune to your or other provider concerns. I just don't
think IPS is the right solution for Tor exits.

If we're going to change anything I think it needs to happen within
Tor software. Operators could leverage the existing "Exitpolicy
reject" rules, or Tor could add functionality there if it's missing.
Whatever we do, I think it needs to be uniform and transparent.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata

[Green Dream]

>> >   for i in subdir/*; do ssh host mkdir -p "$i"; done
>> >
>> > with an ssh-agent would look pretty exactly the same to the exit node.
>>
>> OK, so I left out the "Permission denied, please try again." bits :)
>
> The exit node doesn't see that - that's the point of ssh. It can
> at best look at the session length and timing and infer flakily
> from that.


Exactly. There isn't a 100% effective way to accurately filter out
"bad ssh" on the wire. It's a good example of where intrusion
prevention systems fail.

I worked at a public university where Bro (https://www.bro.org/) was
in use. One of the enabled rules was for ssh brute-force /
failed-login. It was mostly false positives. Bro was flagging
legitimate ssh traffic. Turns out Bro is notorious for this (ref:
http://mailman.icsi.berkeley.edu/pipermail/bro/2013-September/006026.html
and many other similar posts).

I've also worked with Snort and Cisco and Palo Alto IPS/IDS systems,
and I've come to hate all of them for a couple of reasons:

1) The rulesets are finicky, always in flux, highly variant between
vendors, and wildly inaccurate.

2) At the end of the day they are just tools for censorship.

The way these systems work: the admin is presented with an assortment
of rulesets, usually broadly categorized, and you just go through and
start checking off boxes with labels like "adult content", "violence",
"hacking", "tor", or if you're using an open source variant it may be
a bit more refined like "ssh brute force", "syn flood", "tcp scan",
etc.

At the end of the day though someone is just checking off boxes. The
underlying regex applied to packets may or may not have even been
looked at.

Multiply that chaos by the number of Tor exit operators who might
implement such a thing. Think about the different experience levels of
operators too; how many would know that the Bro rule for ssh was
mostly going to block legitimate ssh traffic?

We have technical and highly qualified Exit operators who could
install an IPS, sure. But we have others fairly new to being
sysadmins.

One other huge problem -- where there's IPS there are IPS logs. Every
IPS tool I know of has an option to log, and they're all going to log
by default. That's bad. I'd vote BadExit flag (if I had a vote, ha).
There's too much metadata that this would leave behind, and it may
open up the operator to legal liabilities.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata

[Green Dream]

> I'm being to think there is no real solution to the problem. As long as Tor
> serves its purpose of providing uncensored access to the Internet, bad guys
> will always abuse it, and the operators will almost always be at odds with
> their ISP. Anything we try to do to block abuse will destroy the very
> concept of Tor.


Ding ding ding. You're getting it now. :-)

Criminals using Tor is not a new problem. It's addressed as the first
question in the Abuse FAQ, here:

https://www.torproject.org/docs/faq-abuse.html.en#WhatAboutCriminals

and it's discussed by the EFF here:

https://www.eff.org/deeplinks/2014/07/7-things-you-should-know-about-tor

There are a lot of smart people who have been talking about this for a
long time. I won't list more sources but they are easy to find.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata

[Green Dream]

@Markus

Okay, so you are offended by the phrase "it's that simple". Sorry, if
I could remove that sentence I would. I didn't mean to imply that
running an exit was trivial or easy.

Otherwise, I stand by my argument -- automated filtering or blocking
is not the right answer. The co-founder of Tor already said as much in
this thread: "it would seem that using an IPS is fundamentally
dangerous for relay operators".
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata

[Green Dream]

> You are ignoring completely reality, aren't you?

No, I'm describing the status quo, how Tor already operates. "Don't
run IPS/Snort on exits" has been a long standing response from the Tor
folks. It looks to me like that response is essentially unchanged.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata

[Green Dream]

@Tristan:

> there must be something we can do about this as relay
> operators.


No, we don't need to do anything. Tor has been running under these
principles of uncensored access for a long time. Find an ISP that
understands Tor, appreciates the nature of the service and its value,
and is willing to work with you in a reasonable manner on abuse
complaints. It's that simple.


> If you get caught doing something illegal on your home Internet
> connection, there are warnings, and eventually consequences (like being
> disconnected). Just because you run a Tor relay doesn't mean the rules don't
> apply to you, and if we can't do anything to stop illegal activity,
> eventually relays are going to be disconnected.


Apples and oranges; the logic doesn't work for me. The rules (laws)
*are* different for relay operators. See Roger's earlier comments in
this thread. Relay operators are closer to common carrier / ISP laws,
in that there is some degree of legal immunity if you're just passing
bits. This is why an ISP in the United States isn't liable for illegal
activity from a customer (broadly speaking, IANAL, etc). Yes we need
to be responsive to abuse complaints, but no, we don't have to
implement IPS systems or proactively block traffic just to appease an
ISP who gets stressed out by automated abuse complaints.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata

[Green Dream]

@Mirimir:


>> IPS aren't perfect - they let some unwanted traffic through, and
>> block other traffic that is totally ok.


> That is an issue. But there are many exits, so eventually users should
> find one that works well enough for their purposes.


Re-read what you said and think about this from the user's
perspective. This is a recipe for disaster when it comes to Tor user
experience. Perhaps it seems suitable to you, as a technical person
and a relay operator, but just think about this problem for a barely
technical user, or someone new to Tor. What will actually happen is
people will try Tor, hit a shitty exit with random performance
problems from an IPS, log off and never use Tor again.

Tor needs all the help it can get with regards to usability and
reliability. It's gotten better over the years but I still get
circuits that are borderline unusable. Adding a hodgepodge of blocking
IPS systems into the mix isn't going to help this problem.

No offense to the ISP here (I do think they are within their rights to
take this position), but I think relay/exit operators should find ISPs
that understand Tor and don't demand an IPS.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata

[Green Dream]

@keb:

> It is not our problem if someone uses
> the telecom network to read/write data to a vulnerable server - it is
> the vulnerable server's problem to fix.


Sounds great, but this is not how it works in the real world.


> The ISP (and Tor network) are
> only responsible for delivering the packets and handling abuse of
> *network* resources such as DDoS - content is irrelevant.


Again, not how it works, at least not in all parts of the world. In
the US in particular, there is the Digital Millennium Copyright Act
(DMCA), under which the ISP does have obligations regarding content.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Question about relay speed

[Green Dream]

You could also turn the old relay into a bridge. I've read that low
bandwidth machines are often better serving the network as bridges,
although I don't know what the cutoff value for "low bandwidth" is in
this case.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] help #3

[Green Dream]

Have you double-checked the ulimit was applied correctly? Including
making sure it's applied to the user account running Tor? Here's how I
do that on Ubuntu/Debian, assuming the user account is "debian-tor":

  sudo su debian-tor --shell /bin/bash --command "ulimit -Sn"
  sudo su debian-tor --shell /bin/bash --command "ulimit -Hn"

Those should return the actual hard and soft limits being applied to
the debian-tor user. In my case it returns 64000, but you'll just want
to make sure it's what you're expecting.

> nothing works and now I am running out of ideas

It would be easier for people to help if you elaborate a bit --
perhaps the exact commands you've already tried and the log messages
(if there are any other error or warning messages besides the one you
already listed).
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] log message: [WARN] Failing because we have X connections already.

[Green Dream]

> I'm limited to 1360 tcp sockets.

That's really bad for a Tor node, and I'm not sure you'll be able to
work around it effectively. Even my non-exit nodes routinely have 7000
- 8000 established sockets.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Node families and guard flags

[Green Dream]

The Advertised Bandwidth is is significantly lower on TorRelay02HORUS
too. Let me quote teor from another recent thread, I think the same
info is helpful here:

-- begin quote --

Your relay reports a bandwidth based on the amount of traffic it has
sustained in any 10 second period over the past day.
You can also set a maximum advertised bandwidth on your relay. (Don't
do this if you're trying to pick up more traffic.)
Five bandwidth authorities measure each relay each week, and report
how fast it is.
Each of these factors can restrict the amount of bandwidth that the
network assigns to your relay.

Here's one way of testing what your relay is capable of:

Run a Tor client as close to your relay as possible:
tor DataDirectory /tmp/tor.$$ SOCKSPort [IPv4:]1 EntryNodes your-relay-name

Then download a large file using port 1 as a socks proxy.

That will give you some idea of how much traffic your relay can
sustain, but it's worth noting that each client is limited to about 1
Mbps (I think - I can't find the manual page entry).

-- end quote --

From a quick glance, it seems that TorRelay02HORUS just isn't
providing the same bandwidth as TorRelay01HORUS. There could be many
reasons for this, including hardware, other nodes on the same network
rack at your host, upstream bandwidth for the datacenter, peering
between the node and the bandwidth authorities, etc.

None of this is unusual. As I have said many times, when spinning up
new relays, I often find it helpful to bring up many at the same time
(ideally using automation like Ansible), find which ones perform best,
keep those and tear down the others.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tomhek - the (new) biggest guard relay operator

[Green Dream]

Yep, there's no enforcement or extra billing for network traffic... at
all. They have said this will change in the future.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor and Diplomatic Immunity

[Green Dream]

The whole idea doesn't sit right with me.

For one, I'm not sure I'd want any more Five Eyes entities running
Exit nodes. Most embassies are already a haven for espionage activity.
You'd pretty much have to assume they'd be sniffing the exit traffic.

Also, with all the other priorities, I kinda doubt most embassies have
any interest in the general work involved, not to mention the
liability, of running an Exit.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Guard vs Exit Bandwidth

[Green Dream]

Don't forget that some traffic enters through guards but lands on
hidden services, skipping Exits.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] #torstrike

[Green Dream]

Well said grarpamp.

> there are plenty of other already existing, interesting, and
> upcoming anonymous overlay networks for transporting IP, messaging,
> storage and so on.

Mind sharing some names here so I can research further?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Accounting and the 'Stable' flag

[Green Dream]

> I just want to make sure that... the ISP is not throttling traffic without 
> notification.


Yeah, that's a valid concern. Aside from running through some of the
M-LAB tests (https://www.measurementlab.net/tests/), it can be hard to
predict or detect this.

Another issue that can crop up is poor peering capacity between your
ISP and the rest of the Internet. In particular, in order to get a
good consensus weight, the Tor bandwidth authorities need a good path
to your relay. This can be really hard to measure. I have run into at
least one provider that had great bandwidth when measured with nearby
hosts or localized CDNs, but somewhere in the path to the bandwidth
authorities there was congestion or some other issue preventing good
connectivity.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Accounting and the 'Stable' flag

[Green Dream]

@Ralph

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

It is normal to experience a dip in traffic. Just keep the relay
running and let things play out. It can take weeks for utilization to
peak.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] #torstrike

[Green Dream]

I'm not switching off my relays. I'd prefer to leave the politics to
other people.

> Fact: The investigation done by Tor Inc, was run by the primary accusers
> of Jacob Applebaum.

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

Re: [tor-relays] relay on a vps not exclusively used for tor?

[Green Dream]

> Most AUPs ban the use of programs designed to use 100% CPU

A well-utilized Tor node will max out CPU...
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Guard Flag without stable Flag

[Green Dream]

Looks like the guard flag already fell off. In any case I wouldn't worry
about this. I think clients probably wouldn't choose a guard without the
stable flag?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Web server and TOR bridge at same IP:port

[Green Dream]

I don't think you will be able to bind two daemons to the same TCP port
(443).

Maybe you could have something else listening on TCP port 443 and passing
the requests onto both places?

You might be able to put a single reverse proxy in front on that port, and
have that proxy send the requests to the correct daemon on the backend, but
I have no idea how to actually set that up. Most common reverse proxy
software (like nginx) isn't designed to understand or handle Tor or
pluggable transports like obfs4.

There may be some application aware ("layer 4") firewalls that could do
something like this too, but I don't think it would be straightforward.
Also I'm not sure inspecting Tor packets (in order to determine they're Tor
packets) is a good idea... or if that could even work since the packets
will be obfuscated.

Just thinking out loud... but this seems like a difficult to implement idea.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Pi3 mid relay dropping lil bit of packets

[Green Dream]

Counter-point... transmission errors are not a certainty:

  RX packets:323526978271 errors:0 dropped:0 overruns:0 frame:0
  TX packets:249565709357 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:285274358053849 (285.2 TB)  TX bytes:287754558279252
(287.7 TB)

Ideally there should be no errors. :)

11 dropped packets isn't a big deal, but I wouldn't be quick to dismiss
these errors by default. In certain cases things might be improved with
driver updates, or sysctl tweaks, or a new ethernet cable, etc.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] High speed Tor relay advice

[Green Dream]

Hi i3,

Thanks for running relays! Agreed you will want to run multiple instances
to make the most of your host.

The Xeon E5-2620v3 does have AES-NI, which is good.

Other items to consider:

- On most linux/unix systems the ulimits will be set too low by default. On
debian-like linux, higher limits for Tor might look like the following in
/etc/security/limits.conf:

debian-tor softnofile  64000
debian-tor hardnofile  64000

- There are a lot of possible syctl tweaks. You could check out
https://raw.githubusercontent.com/torservers/server-config-templates/master/sysctl.conf.
I use these values on my non-exit relays:

net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.all.send_redirects = 0
kernel.sysrq = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 4
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.ip_local_port_range = 1025 65530
net.core.somaxconn = 20480
net.ipv4.tcp_timestamps = 0
fs.file-max = 64000

- You should install ntp make sure your clock is synced.

- You should install a local DNS resolver (unbound, named, dnsmasq,
something along those lines).

This guide has a lot of helpful info:
https://www.torservers.net/wiki/setup/server
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How to exclude a CDN ?

[Green Dream]

You could probably enumerate most (if not all) of the subnets for Akamai or
CloudFlare or $InsertCDN, but blocking all of them seems like it would be
terrible for Tor users since they host so much of the web at this point.

So yeah... I think you're out of luck.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Any security tips on running a TOR relay?

[Green Dream]

P.S. Tristan, here's the explanation from that mailing list... just in case
people can't access the link or it goes away:

"Yes, it has everything to do with those flag bits. For TCP connections,
Linux tends to use a "half-duplex" close sequence where either side of the
session can initiate connection termination via a single 2 way FIN-ACK
handshake (which puts the connection into the CLOSE_WAIT state), instead of
a full 4 way FIN-ACK handshake. When one also includes routers and such, it
is not uncommon, indeed common, that one side might think the connection
has been terminated, while the other side thinks it has still open or not
fully terminated. Your log file is, most probably, showing entries for
cases where your computer thinks the tcp had been closed and it has
forgotten about it, but the client is trying to close the session. In the
case where you got a RST bit, it can be because the client gave up trying
the FIN method and now is just trying to reset the connection. By
observation only, rather than authoritative reference, it seems that Apple
computers tend to use FIN and FIN-ACK more, and MS windows computers tend
to use RST more.

Conclusion: Everything is fine."
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Any security tips on running a TOR relay?

[Green Dream]

Hey Tristan,


> Any ideas what in-addr.arp is


Yes, this is the standard format for reverse DNS lookups for IPv4 addresses.

I'm not sure what command(s) you were using, but in-addr.arpa is an
expected result (or intermediate step) of doing something like "host
8.8.4.4" on Linux. The IP octets are reversed and appended to the domain
suffix in-addr.arpa (ex: 4.4.8.8.in-addr.arpa for 8.8.4.4) to create a
hostname. Then to continue the same example, the host tool finds a PTR
record for that hostname (ex: google-public-dns-b.google.com). You can read
more about this here:

https://en.wikipedia.org/wiki/Reverse_DNS_lookup
https://tools.ietf.org/html/rfc2317

So... those in-addr.arpa references don't really tell you anything. It's
just a distraction. My hunch is that the IP addresses in your log are going
to be a random selection of IPv4 addresses from Tor clients and relays.


> why the firewall would block it even on allowed ports?


I was trying to explain earlier but did a poor job. I don't have a specific
explanation for Tor, but it's common to see the same behavior with denied
packets to port 80 and 443 on a web server, even when there is a UFW
(iptables) allow rule. It has to do with the state of the connection.
There's an explanation for web servers and port 80 blocks here:

https://ubuntuforums.org/showthread.php?t=2138691 (see the 2nd post)

I am making an assumption that we're seeing the same behavior on the Tor
ports. It would be good if someone with a better understanding of the
protocols could confirm or deny the theory. I'm not 100% certain.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Any security tips on running a TOR relay?

[Green Dream]

That's my setup as well. My UFW looks like:

To Action  From
-- --  
80/tcp ALLOW   Anywhere
443/tcpALLOW   Anywhere
xxx/tcp   ALLOW   Anywhere

I have my DirPort set to 80 and ORPort on 443. The last line is my ssh port
(I didn't want to broadcast it).

I also see the same type of blocked incoming packets. It's never been a
problem. I think it's just the nature of the stateful firewall. Once
connections are closed and no longer in the state table, additional packets
are getting denied. That's my lazy/gut explanation, I don't have more time
to think about it at the moment, but I don't think it's anything to worry
about.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Any security tips on running a TOR relay?

[Green Dream]

Tristan: yep, I was assuming a non-exit. Although sure, you can block
incoming traffic without affecting outbound traffic with a stateful
firewall like iptables.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Any security tips on running a TOR relay?

[Green Dream]

I'd say the normal server hardening precautions apply. Off the top of my
head:

- keep software/packages up to date
- only use public-key authentication for ssh / disable password-based auth
- optionally change the ssh port (it just avoids the worst of the port
scanning / brute force attempts)
- limit the number of services running on your relays (ideally only run Tor
and supporting services (i.e., maybe dns)
- firewall off (deny) everything except DirPort/ORPort/ssh
___
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

[Green Dream]

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.
___
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

[Green Dream]

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

[tor-relays] is explicit DirPort needed anymore under Tor 0.2.8.6?

[Green Dream]

The release notes for Tor 0.2.8.6 have this tidbit about the DirPort:

"Previously only relays that explicitly opened a directory port
(DirPort) accepted directory requests from clients. Now all
relays, with and without a DirPort, accept and serve tunneled
directory requests that they receive through their ORPort. You can
disable this behavior using the new DirCache option. Closes
ticket 12538."

With this new behavior, is there any reason to keep an open DirPort on our
relays? If I just use an ORPort on 443 (or another reachable TCP port) is
this sufficient? Might it make sense to leave the DirPort up for a while
for legacy clients? Will (up-to-date) authorities have any concerns with a
ORPort-only relay?

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

Re: [tor-relays] Syslog: Kernel TCP: Too many orphaned sockets

[Green Dream]

It's related to /proc/sys/net/ipv4/tcp_max_orphans

"Maximal number of TCP sockets not attached to any user file handle, held
by system. If this number is exceeded orphaned connections are reset
immediately and warning is printed."

So, I'd start by checking the value of tcp_max_orphans (with "cat
/proc/sys/net/ipv4/tcp_max_orphans"). The widely distributed sysctl.conf
tweaks for Linux relays suggests a value of 262144. I think the default in
many distros may be 4096, perhaps too low for an Exit.

Some references:

https://serverfault.com/questions/624911/what-does-tcp-too-many-orphaned-sockets-mean
https://raw.githubusercontent.com/torservers/server-config-templates/master/sysctl.conf

If you need help making the sysctl tweaks let me know.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Best bandwidth setup for exit node

[Green Dream]

How do the bandwidth authorities treat a hibernated relay? Does hibernation
effectively lower the consensus weight (CW)? If so, and even if the lower
CW is temporary, would it then take longer for the CW to climb back up once
the relay is out of hibernation?

IMHO it seems simpler to just throttle it evenly over the month
(RelayBandwidthRate).
Then you have a nice, even CW throughout the month, and the relay is
consistently utilized to its potential.


On Thu, Jul 14, 2016 at 1:38 PM, Moritz Bartl  wrote:

> On 07/14/2016 08:44 PM, SuperSluether wrote:
> > Personally I think throttling a relay is better for the network as a
> > whole. I'd rather have a slow, reliable connection than a fast and
> > spotty connection.
>
> Hibernation using AccountingMax won't result in "spotty" client service.
> The relay will not accept any new connections, and thus slowly "fade
> out" for the period.
>
> There is no one valid answer to this question. I would say limiting it
> so it stays around for 15-20 days per month is a good compromise.
>
> --
> 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
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] wubthecaptain1 relay is no longer an exit

[Green Dream]

> IMO it is not necessary to open all 65535 ports, 1 or 2 dozen
> are enough to cover a majority of the needs of the users.


For a minimal exit, you really only need "at least two of the ports 80,
443, and 6667" to qualify. Ref:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2133
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BoingBoing Says Running Exits Is No Trouble re: LEA

[Green Dream]

Except the operators at BoingBoing have the privilege of corporate
liability (instead of personal liability), and very likely corporate
counsel (i.e., a nice legal team) as well.

It seems easier to say "don't worry about it, it's not really a problem"
from that perspective.

For the average Tor volunteer operator, all that comfort, protection and
privilege is gone. _My_ ass is on the line. Or at least it feels that way.

I guess I'm saying, I wouldn't get too comfortable. Definitely not to the
point of breaking rule #1 of running an exit -- don't do it from home.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] suspicious "Relay127001" relays

[Green Dream]

> It's up to directory authority operators to deal with
> suspicious/rogue/misconfigured relays by marking them as
> invalid/rejected/badexit.

So... what's going on in this particular case and what are the directory
authorities going to do, if anything?

As a relay operator near the top of the CW list, I continue to be somewhat
uncomfortable with the lack of transparency regarding the directory
authority decisions. It would be nice if the decision making process around
these types of events was a bit more transparent.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] which DirPort should be advertised ?

[Green Dream]

See:
https://lists.torproject.org/pipermail/tor-talk/2016-January/040074.html

My takeaway is that there's little point to setting an IPv6 DirPort at this
point. Clients will rarely connect to it, and relays won't connect to it at
all. Furthermore, "In 0.2.8, clients assume that the IPv6 DirPort is the
same as the IPv4 DirPort" already. If that's still true, might as well
leave the v4 port advertised, and if a v6 client comes along it will try
the (non-advertised) v6 port anyway.

It seems like all of this is in flux though. Perhaps someone can provide an
update on the current progress.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] arm and non-default control port

[Green Dream]

>> don't run arm as the tor user

> Does this apply only to Debian, or Linux in general?


Linux in general. It's really just a matter of giving the process the least
amount of privilege necessary.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Usability Improvements for Atlas (was Re: Globe is now retired)

[Green Dream]

> What would be handy with dozens of VPSs would be to control them as one
> for numerous things.  Do you know of anything which does that from
Windows?


This is "server automation". Ansible, Chef and Puppet are popular
solutions. Ansible seems to be popular for Tor relays, with several
existing playbooks available (search for "tor ansible"). I'm really not
much of a Windows guy so I'm not sure about the extent of Windows support.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Usability Improvements for Atlas (was Re: Globe is now retired)

[Green Dream]

A server monitoring tool. :-)

https://www.google.com/search?q=server+monitoring

There are many good options. I like StatusCake because they have a free
tier which does everything you'd need for monitoring Tor relays. You can
have it verify the fingerprint of your relay (via the information exposed
by your DirPort) at the same time it checks if it's running.

There are a lot of other choices for hosted monitoring. Pingdom is a
popular commercial choice.

There's also a wide variety of open source tools if you want to do it
yourself and not rely on a third party. Icinga is a popular open source
choice.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Usability Improvements for Atlas (was Re: Globe is now retired)

[Green Dream]

> I meant, since I have a number of relays, for Atlas to tell me which ones
> are not going without having to look into each in detail first.


As far as I can tell, relays that are not running are not included in the
search results. You'll only see relays that are active in the consensus.
I'm not sure how long they take to drop off though.

What is the use case here though? Monitoring? If so, I think Atlas isn't
the best tool for the job.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Usability Improvements for Atlas (was Re: Globe is now retired)

[Green Dream]

> On a relay's page could you show whether it is running or not?

That information is already there. Look under "Current Status" on the
right; it shows both "Uptime" and "Running" (as true or false).
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Usability Improvements for Atlas (was Re: Globe is now retired)

[Green Dream]

Minor issue: there's no need to have the Show XXX entries dropdown on the
"Top 10 Relays" page (https://irl.github.io/atlas/#/top10) since it's
designed to show only 10. In fact changing the selection does nothing.


On Wed, Jun 29, 2016 at 1:05 PM, Iain R. Learmonth 
wrote:

> Hi All,
>
> On 29/06/16 09:56, Karsten Loesing wrote:
> > tl;dr: Globe is now retired in favor of an improved Atlas.
>
> Atlas is improved, but I'd like to improve it further. I've been
> tackling #6787 looking to improve the homepage and make Atlas easier to
> use for someone that isn't already a Tor expert.
>
> The changes I'm proposing in my fix for #6787 [1] do make some
> noticeable UI changes and I just want to gather some opinions on whether
> or not Atlas users feel that this is taking it in the right direction.
>
> The "Top 10 Relays" page was added to Atlas in order to make sure that
> functionality was not lost when shutting down globe. (See #5430 [2])
>
> In my proposed patch, I'm also adding an "Authorities" page and adding
> text to both of these pages to explain what you're seeing. These are
> linked from the homepage, and from the top navbar.
>
> I'm also moving the introduction and explanation of the Atlas features
> from the About page to the homepage and introducing a new Help page that
> explains the details that are found in the relay details pages.
>
> You can find a live example of this patch at:
>
>   https://irl.github.io/atlas/#/
>
> and a full list of changes are detailed in #6787.
>
> Please let me know if you can see any reason to not merge this, or if
> you have any suggestions for small changes before merging.
>
> Thanks,
> Iain.
>
> [1]: https://trac.torproject.org/projects/tor/ticket/5430
> [2]: https://trac.torproject.org/projects/tor/ticket/6787
> ___
> 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] DDOS

[Green Dream]

I have relays on Digital Ocean as well, and occasionally get the same
emails. Notice the contradiction in the email:

"Once the attack subsides, networking will be automatically
reestablished to your droplet. The networking restriction is in place
for three hours and then removed."

Which one is it? Do you automatically reconnect my node when the attack
subsides, or do you just wait three hours? (It's always the latter.)

"Please note that we take this measure only as a last resort when other
filtering, routing, and network configuration changes have not been
effective in routing around the DDoS attack."

That seems to be disingenuous as well. They have never, ever done anything
other than shut of my node for 3 hours. Requests for more information about
the nature of the attack go unanswered.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Weather has been discontinued

[Green Dream]

As I already said 4 days ago in this thread, all indications are the
t-shirt program is no longer active.

It turns out one of the other things that takes time and effort is keeping
the website up to date!

If someone here really cares about the false promise of t-shirts, that
person could submit a pull request to update the website accordingly.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Weather has been discontinued

[Green Dream]

Do you guys really run relays just for the t-shirt? Aren't there more
important reasons to run a relay, like serving the community, being an
advocate for privacy, and acting against surveillance and censorship?

Is this t-shirt issue *really* a problem that needs to be solved? The Tor
Project has many other problems that need attention, and their time is a
limited resource. Can we please just stop worrying and complaining about
the damn t-shirts?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Question on warnings

[Green Dream]

Hi. Thanks for running a relay. These notice messages are from the
monitoring tool Arm, and should not affect the Tor process.

If you don't care about Arm and Tor seems to be working okay otherwise, you
could safely ignore these messages. In case you want to look into them
further, I'll share some thoughts below. It looks like you're running on a
Unix or Linux system, I'll assume Debian or Ubuntu for the moment.

> 20:42:57 [ARM_NOTICE] Unable to prepopulate bandwidth information
> (unable to read the state file)


This is normal in my experience. Arm is trying to read your node's
bandwidth history to populate the graphs with data collected before you
started Arm. I don't know why it fails, but you could squelch it by adding
the following config line to ~/.arm/armrc:

  features.graph.bw.prepopulate false


> 20:42:56 [ARM_WARN] Unable to read tor's log file:
> /var/log/tor/log [1duplicate hidden]


It looks like Arm doesn't have permission to read /var/log/tor/log. I
normally start Arm with something like this, so it has the same permissions
as the Tor daemon:

  sudo -u debian-tor arm


> 20:42:56 [ARM_NOTICE] Tor is preventing system utilities like netstat
>  and lsof from working. This means that arm can't provide you with
> connection information. You can change this by adding
> 'DisableDebuggerAttachment 0' to your torrc and restarting tor. For
> more information see... https://trac.torproject.org/3313


You need to add the following to /etc/tor/torrc if you want to utilize all
the features of Arm:

  DisableDebuggerAttachment 0

It's disabled by default for security (with a value of '1'), so think
carefully before doing this. It "reduces security by enabling debugger
attachment to the Tor process. This can be used by an adversary to extract
keys." (Quoting from https://trac.torproject.org/projects/tor/ticket/13880).
If you do enable the deubgger attachment for Arm, make sure your control
port is locked down (not reachable from the Internet or from other hosts
you don't control, etc.)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] TOR router install without access to root

[Green Dream]

@Paul: sure. Nils pointed out that a lot of relays using the same hosting
provider could be an attack vector, because the provider would be a single
point where all the relays' secret keys could be collected. My point is
that if you look at the AS (Autonomous System) Number, it's normally the
same for all the hosting provider's servers in that country. So if Tor path
selection looks at the AS, and avoids building a circuit that uses two
nodes from the same AS, this attack vector basically goes away. It's worth
noting if you weren't already aware, both Atlas and Globe display the AS
Number for every relay.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] TOR router install without access to root

[Green Dream]

@Nils

Tor path selection avoids using relays from the same /16 subnet, and I
thought it considered the Autonomous System (AS) as well. However now I'm
not finding concrete evidence that path selection looks at AS. I found some
older academic papers on the subject [1], but nothing in the current
specification [2].

Avoiding using two nodes from the same AS would seemingly go a long way
toward mitigating the attack vector you mentioned though.

1) http://freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf

2) https://gitweb.torproject.org/torspec.git/plain/path-spec.txt
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Monitoring multiple relays

[Green Dream]

I use a third-party monitoring service to monitor the Dir and OR ports of
all my relays. It's especially useful now that Tor Weather isn't
maintained. The service constantly checks for a response from both ports,
using several monitoring endpoints around the world, and notifies me of any
downtime. It also has a nice feature where I can look for a specific
response from the Dir port (i.e, parse
http://relay1.example.com/tor/server/authority and look for the
fingerprint).

https://www.statuscake.com/ (the free tier is sufficient for this use case)

I don't know of an easy way to aggregate the Tor stats in one place, but
over time I've realized those stats don't matter too much anyway. :) As
long as the nodes are running well and providing service I don't really
need to know how many circuits or the bandwidth at any given moment.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Port scanning via exit node

[Green Dream]

There's really nothing to do. Based on the limited logs, it looks like
someone was just looking for open TCP port 22 (ssh). You can't really block
the scans by source since you don't know the source address (because Tor).
You could prevent connections to port 22, but that would prevent everyone
else from using ssh through your exit, and also, it wouldn't stop port
scanning of any other ports allowed through the exit.

I'd just explain you're running a Tor exit, and thus you cannot identify
the source of the scan.

As common as port scanning is (and has been for as long as the Internet has
been around), I'm surprised providers still worry about it this much.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] What's this Abuse

[Green Dream]

I'm questioning the competency of the ISP for several reasons. 1) They
should be clear in communicating about whatever they view as abuse. Just
telling you to "stop" without explanation is unprofessional at best. 2)
This doesn't even look like abuse worth reporting (i.e., "welcome to the
Internet"). 3) They sent you non-redacted logs containing what looks like
browsing history of other customers? Wow.

I would personally just explain you are running a Tor relay. If they
object, that's within their right really, but it might be time to find a
new ISP in any case.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Handling possible abuse requests

[Green Dream]

You should start with the FAQ, if you haven't already seen it:

https://www.torproject.org/docs/faq-abuse.html.en

The topic has been addressed many times on the list as well, so I'd suggest
searching the archives. You can easily do that via Google with a search
like:

abuse site:lists.torproject.org/pipermail/tor-relays

You can reduce the abuse to some extent by using the recommended reduced
exit policy. You'll probably get a decent amount of reports anyway. Don't
run an exit from your home.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor buddy is not checking

[Green Dream]

Not sure why anybody would need that script, but if you're asking about the
error, you'd likely need root access to modify ulimits.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Using your own Relay as Entry Node

[Green Dream]

I'd say it's a tradeoff. You may have more trust of your own entry guard,
but you're losing the benefits of guard rotation and possibly making it
easier for de-anonymizing attacks to occur. From the man page: "We
recommend you do not use these — they are intended for testing and may
disappear in future versions. You get the best security that Tor can
provide when you leave the route selection to Tor; overriding the entry /
exit nodes can mess up your anonymity in ways we don't understand."
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] NPR story: When A Dark Web Volunteer Gets Raided By The Police

[Green Dream]

Who said Tor was against the police?

The fact is, in the United States, the FBI and other law enforcement
agencies have been known to plant malware, modify hardware, etc., in order
to maintain persistent access to machines they wish to monitor. Whether or
not you think this is valid in some cases or all cases is really beside the
point. The question is whether exit node hardware can be trusted after a
search warrant is served and the police are given full and unmonitored
access to said hardware. As a matter of due diligence, I'd argue the
hardware and OS can no longer be trusted in such cases.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] NPR story: When A Dark Web Volunteer Gets Raided By The Police

[Green Dream]

@ Tristan re: "What happened to "innocent until proven guilty?" Please note
I already said "This particular case is perhaps not so clear cut"

@ Markus re: "How do you know a exit server is compromised?" You don't
always know. With any skill on the attacker's part, you will NOT know.
Still, sometimes attackers do stupid things, like run sslstrip, otherwise
try to man-in-the-middle SSL, etc.

As I already said, this particular case is not so clear cut. However
letting the police poke around on the hardware is a really good reason not
to trust it! I mean, I'd personally burn it all down and start over. Looks
like that's what the Seattle operators are already doing, so this is
perhaps a moot discussion.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] routing script

[Green Dream]

> I spoke with an VPN provider and
> they are okay with routing tor traffic over their VPN as long I have
> exit rulez etc. The only thing I need is a routing script for Debian
> to route all the Tor traffic over the VPN. Anyone can help me out with


If I understand correctly you are hoping to setup an exit node where the
outbound user traffic that would normally go to the clearnet winds up going
through a VPN first instead?

I'm not sure this is a very friendly idea for the Tor network. At the very
least, it's introducing an extra hop and additional latency. The average
Tor user has no ability to easily detect or opt-out of this situation. At
the worst, depending on how the VPN is implemented, you might introduce
other performance issues (TCP over TCP tunnels comes to mind) or security
issues (DNS leaks, VPN provider now has the ability to sniff traffic, etc.).
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] DDoS attack on relay

[Green Dream]

My hosting provider alerted me of a DDoS attack on one of my relays. It
started around 2016-01-26 12:42 UTC. They claim they tried "filtering,
routing, and network configuration changes" to mitigate the attack, but as
a last resort they temporarily disconnected the host from the network for 3
hours.

I know such attacks are not uncommon, but I'm curious if any other
operators experienced a DDoS around the same time?

I'm also curious to know more about the nature of such attacks -- what type
of attack was it, what is the general end goal of attacking a random Tor
(non-exit) relay, etc. My hosting provider is unable or unwilling to share
additional information.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Debugging my small relay

[Green Dream]

Is there really a reason to continue running this relay, even as a bridge?
It has a consensus weight of 9. Before the upgrade and subsequent
fingerprint reset, it was only at cw 16. The mean middle probability
fraction was 0.000103%. The mean on the read/write was less than half a
kilobyte per second. It's not really being used.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Allow user to provide feedback?

[Green Dream]

Typically users are routed through multiple relays (guard, middle and
exit), so the proposed feedback would really be a generic "this circuit is
slow" signal, which doesn't help narrow down the problematic relay.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Very unbalanced inbound/outbound connections

[Green Dream]

"I see a little bit more than twice as much inbound than outbound
connections on my (non-exit, non-guard) relay [0]."

"looking at the graphs in atlas (as well in arm) shows no significant (=
something like twice as much) difference between the inbound and outbound
traffic"

I'm not sure if you mean the literal number of connections, or if you're
talking about bandwidth utilization. In either case, if arm isn't showing
the increase, the additional traffic might not be coming from Tor.

Have you considered other services running on the host?

You could always take a look at the traffic. You could use something like
'iftop' on Linux (turn on the port display) to get a really quick picture.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Running an exit? Please secure your DNS with DNSCrypt+Unbound

[Green Dream]

> Weasel and velope on #tor-project suggested that I remove DNSCrypt
> entirely and let Unbound be a recursive resolver against the root DNS
> servers, which I have now done.


Jesse would you mind sharing how you configured this?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] uptime "algorithm"

[Green Dream]

I'm not sure why operators care so much about the HSDir flag. It naturally
comes and goes. Try not worry about it. :)

I've noticed that it can take 30+ minutes after a version upgrade before
the directory service on my nodes is fully responsive again [1]. I'm not
entirely sure what's happening in this timeframe, but it might be a good
reason not to leave the HSDir flag in place.



1) To monitor the health of my relays I periodically query the directory
service via a GET request to a URI. For example:

http://197.231.221.211:1080/tor/server/authority

(That's not my relay. I picked a top relay from Globe).

The monitoring software looks for a 200 response and validates the
fingerprint.

After the upgrade to 0.2.7.6 all my relays returned a 404 on that URI for
at least 30 minutes.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Actions required after update?

[Green Dream]

> is there any action required for somebody running the relay
> on a pretty bog-standard Ubuntu 12.04 Linux dedi?
> other than sudo apt-get update && sudo apt-get dist-upgrade


There is a new OfflineMasterKey feature you can read about here:


https://lists.torproject.org/pipermail/tor-relays/2015-November/008190.html

If you want to enable OfflineMasterKey read before upgrading. Otherwise I'd
say go for it. Don't forget:

sudo service tor restart

You might see a prompt about a new torrc from the package update. I chose
to keep my existing version. There was no noticeable change once the
service was back up.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Weather not working?

[Green Dream]

It seems to be working at least some of the time, as I did receive a
notification to the same email address for another node, back in
mid-October.

If it's not maintained and not expected to work reliably, it should be
taken down. I have a hard time believing this is the case though.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] unlisted exit relay

[Green Dream]

While visiting https://torstatus.blutmagie.de/ in Tor Browser, I noticed it
wasn't detecting the exit node I was being routed through as a relay.
Curious, I tried looking up the same IP in both Atlas and Globe, but
neither knows of a relay at this IP. The IP of this exit is 104.156.228.115.

What scenarios might cause this situation? As a Tor user, should I care? At
the very least, it seems desirable to always be able to research the nodes
you are using.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor Weather not working?

[Green Dream]

I took a relay offline 2 days ago and still haven't received a notification
from Tor Weather. The preferences page confirms everything is configured,
but yet, it doesn't seem to be working for me. I checked the spam folder.
Is there someplace to file tickets for this, or some other contact info for
the maintainers of this service? I'd be happy to share additional details
if someone wants to look into it.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Weather not working?

[Green Dream]

I just received the Tor Weather notifications. They were over 2 days late.

The email headers show Tor Weather just sent them, and it only took a few
seconds for Gmail's MX to receive and accept. I.e., the delay appears to be
somewhere on the Tor Weather server side.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30

[Green Dream]

> The authorities should be rejecting the relays
> dropping their traffic soon, I assume now they're
> trying to contact the operator before doing that


Is there somewhere we can follow the conversation and decisions of the
authorities when there are incidents like this? IRC? Another mailing list?
As an operator, I would appreciate more transparency into how
this "open" network is administered.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] HoneyPot?

[Green Dream]

Mirimir: aside from the nickname, do you have any reason to believe it was
out of the ordinary? The exit policy mostly only seems to allow
non-encrypted services (80 but not 443, 143

On Thu, Oct 29, 2015 at 1:22 PM, Mirimir  wrote:

> Anyone know what HoneyPot was/is?
>
>
> https://atlas.torproject.org/#details/F77FD005BF74CD0B4C611389C3006452AEC60CA3
> ___
> 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] HoneyPot?

[Green Dream]

(Oops, sorry, an errant keyboard shortcut sent the email too early.)

Mirimir: aside from the nickname, do you have any reason to believe it was
out of the ordinary? The exit policy mostly only seems to allow
non-encrypted services (80 but not 443, 143 but not 993), but that alone
isn't enough to give it the BadExit flag:

https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays#Whatisabadrelay
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] HoneyPot?

[Green Dream]

> BTW the exit policy includes 443.

My mistake. I didn't realize the policy view on Atlas is truncated.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] HoneyPot?

[Green Dream]

> I cannot imagine how any TOR operator would block encrypted services
> and not be what most reasonable people consider a "Bad exit".


It turns out this "HoneyPot" node is NOT blocking encrypted services. They
allow ports 443, 993, and other encrypted services. Unfortunately that line
of the exit policy isn't displayed on Atlas. You can see the full policy on
Globe:

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

Re: [tor-relays] MyFamily format

[Green Dream]

The correct format for MyFamily is documented here:
https://www.torproject.org/docs/faq.html.en#MultipleRelays

I'm not sure how important it is to set at this point though?
https://trac.torproject.org/projects/tor/ticket/6676
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] too many circuit creation requests

[Green Dream]

> # lsof -Pn | grep "^tor" | grep ESTABLISHED | wc -l
> 3169
> # netstat -nt | wc -l
> 1599


These values are normal for a relay; exactly what I'd expect from a Pi.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Faravahar messing with my IP address

[Green Dream]

Sina, the ticket 16205 regarding incorrect IPs coming from Faravahar is 5
months old [1].

Have you had a chance to look into the possible explanation Nick Suan
mentioned earlier in the thread?

It's not exactly confidence-inspiring to see multiple unresolved tickets
about Faravahar going back several months.

1) https://trac.torproject.org/projects/tor/ticket/16205#comment:3
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ntpd problems explanation

[Green Dream]

"ntp/time sync peculiarities in relays"

Can you please elaborate? I may have missed an earlier discussion, and a
quick Google search isn't providing too much help. I found the ticket
below, which is interesting reading, but I'm not sure what specific
peculiarities you're referring to.

https://trac.torproject.org/projects/tor/ticket/8170

On Wed, Oct 21, 2015 at 9:35 PM, I  wrote:

> Could this be related to the ntp/time sync peculiarities in relays?
>
> http://www.cs.bu.edu/~goldbe/NTPattack.html
>
>
> http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20151021-ntp
>
> Robert
>
> ___
> 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] Faravahar messing with my IP address

[Green Dream]

I see this from time to time as well. Here's another example:

  Oct 17 23:02:44.000 [notice] Our IP Address has changed from
52.64.142.121 to [CORRECT IP]; rebuilding descriptor (source: 86.59.21.38).

52.64.142.121 appears to be an instance on Amazon's EC2. I don't run any
nodes on EC2. 86.59.21.38 resolves to tor.noreply.org.

I'm unable to find any occurrences of this happening from Faravahar,
however the issue seems to be fairly common. What's going on?


On Thu, Oct 22, 2015 at 1:48 PM, Pascal Terjan  wrote:

> On 22 October 2015 at 19:22, Logforme  wrote:
> > I run the relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC34)
> >
> > Saw this in yesterday's log file:
> > Oct 22 03:17:55.000 [notice] Our IP Address has changed from
> > 84.219.173.60 to 154.35.32.5; rebuilding descriptor (source:
> > 154.35.175.225).
> > Oct 22 03:17:55.000 [notice] Self-testing indicates your ORPort is
> > reachable from the outside. Excellent. Publishing server descriptor.
> > Oct 22 03:17:56.000 [notice] Performing bandwidth self-test...done.
> > Oct 22 03:26:55.000 [notice] Our IP Address has changed from 154.35.32.5
> > to 84.219.173.60; rebuilding descriptor (source: 194.109.206.212).
> >
> > 84.219.173.60: <- My real IP address
> > 154.35.32.5: faravahar.rabbani.jp <- No idea
> > 154.35.175.225: faravahar.redteam.net <- Authority server
> > 194.109.206.212: tor.dizum.com <- Better authority server
> >
>
> I just got something strange too:
>
> Oct 22 20:42:24.000 [notice] Guessed our IP address as 77.206.60.235
> (source: 154.35.175.225).
> Oct 22 20:42:25.000 [notice] Our IP Address has changed from
> 77.206.60.235 to 149.18.2.82; rebuilding descriptor (source:
> 199.254.238.52).
>
> faravahar guess my ip wrongly to be 77.206.60.235 which is a French IP
> totally unrelated to my connection
>
> > So if I read it right my relay asked the authority server Faravahar what
> > my IP address is and got the wrong answer. 9 minutes later my relay
> > asked another authority server and got the right answer. My relay show
> > an uptime starting from this time and if the relay did a full restart it
> > meant all the circuits got dropped? Inconvenient for users.
> >
> > My relay have "restarted" like this a few times the last weeks (only Tor
> > daemon "restarting", not the machine). Don't know if Faravahar is behind
> > the other "restarts". This time I just caught it in the log file before
> > it got archived.
> >
> > Is this a know issue with Faravahar? If so, should it be fixed?
> > ___
> > 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 mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] TCP: too many orphaned sockets

[Green Dream]

> On the new VPS I get the following message (from time to
> time lots of them):

> "kernel: [XX.XX] TCP: too many orphaned sockets"


I'd look at "net.ipv4.tcp_max_orphans". Some VPS providers add their own
defaults to /etc/sysctl.conf, so you might want to check there and see if
it's already set, or otherwise add your own value. The Mozilla relays use a
value of 262144.

https://github.com/XioNoX/moz-tor-relays/blob/master/roles/kernel-tuning/tasks/main.yml
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tools for managing multiple relays

[Green Dream]

Due to the variance of performance of VPS instances, the last time I
decided to add another single relay, I turned up 4 instances, waited a few
days to see which one performed the best, then shut down the others. This
only cost a few extra USD, at most, and greatly improved the value of the
remaining node, which quickly became a guard.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] new relay - not working right

[Green Dream]

Pardon the bad copy/paste in the last email. The third listing on Atlas is:

https://atlas.torproject.org/#details/3FE1025A1E779CAFD21F593AC200C7447703343D
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] new relay - not working right

[Green Dream]

ClydeBoy is listed three times on Atlas. It appears to be running from the
same server, as the IP/port are the same for all 3 nodes, however the
fingerprint is different for each instance on Atlas:

https://atlas.torproject.org/#details/68F162C50F22205FB3B728ACE67470B17D7430D6
https://atlas.torproject.org/#details/53C1C1A27F9CD0A87383FB473ABD7E8D4378F703
https://atlas.torproject.org/#details/53C1C1A27F9CD0A87383FB473ABD7E8D4378F703

I'm guessing that during your testing and config changes, the existing Tor
processes weren't getting killed and so you wound up with multiple Tor
processes fighting for attention and resources. That's not going to work
very well. ;-)

I'm not sure how you installed Tor. For Ubuntu or Debian, I normally follow
the instructions here:

https://www.torproject.org/docs/debian.html.en#ubuntu

If you go this route, you should wind up with Tor installed as a proper
service, which can then be controlled via the standard methods, like:

  sudo service tor start
  sudo service tor stop
  sudo service tor restart

This will also take care of running the Tor process as the debian-tor user.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tools for managing multiple relays

[Green Dream]

You could use something like Puppet or Chef to manage multiple nodes.
However, the compute resources and time involved with setting up either
solution are high enough that it probably wouldn't make sense to do this
for only 3 nodes.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tools for managing multiple relays

[Green Dream]

> An alternative to Puppet or Chef (and I'm a fan of both) would be
> Ansible; it's much simpler to pick up, and uses SSH to connect to
> machines to manage them -- no master server needed.


You just changed my life. I just hadn't looked into Ansible yet. It took
about 5 minutes to setup, and seems ideal for managing a handful of nodes.
Thank you!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] new relay - not working right

[Green Dream]

Hi. Thanks for running a relay.

> For several days now its bandwidth, according to ARM, is in the
> bits/second and there seems to be some problem reading its own
> torrc file.  Also, while it had four connections for a while, there are
> none now.

Regarding the low bandwidth and a low number of connections, this could be
typical for a new relay. Reference
https://blog.torproject.org/blog/lifecycle-of-a-new-relay

> [ARM NOTICE] Read last day of bandwidth history from state file
> (-7502 seconds is missing)

This is normal in my experience. Arm is trying to read your node's
bandwidth history to populate the graphs with data collected before you
started Arm. I don't know why it fails, but you can squelch it by adding
the following config line to ~/.arm/armrc (or wherever you keep your armrc
file):

  features.graph.bw.prepopulate false

> [ARM WARN] The torrc differs frm what tor's using.  You an issue a
> sighup to reload the torrc values by pressing x.

Pretty much what it sounds like; you edited torrc after starting up Arm. To
bring in the chages such that Arm is in sync, just press 'x' in Arm twice
and it will issue a HUP signal to the Tor process, which reloads the config.

> [ARM NOTICE] Tor is preventing system utiliites like netstat and lsof
> from working.  This means arm can't provide you with connection
> information

You need to add the following to /etc/tor/torrc if you want to utilize all
the features of Arm:

  DisableDebuggerAttachment 0

It's disabled by default for security (with a value of '1'), so think
carefully before doing this. It "reduces security by enabling debugger
attachment to the Tor process. This can be used by an adversary to extract
keys." (Quoting from https://trac.torproject.org/projects/tor/ticket/13880).
If you do enable the deubgger attachment for Arm, make sure your control
port is locked down (not reachable from the Internet or from other hosts
you don't control, etc.)

It does seem a little odd you're still at 0 bandwidth with no connections.
Without more data, it's hard to say what else might be going wrong (if
anything). What does /var/log/tor/log have to say? There should be some
lines in there that indicate if it's reachable from the internet.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit Node with Onion Pi

[Green Dream]

> If you're just after something that's
> cheap and Pi-sized, you'd probably have better luck with something like
> the ODROID C1[0]; you still may not saturate the link though.

>From experience, an ODROID box won't help too much. It just doesn't have
enough CPU.

For a little over $100 (USD), you can get a tiny box with an Intel chip,
with a gigabit ethernet interface, like this one:

http://www.newegg.com/Product/Product.aspx?Item=N82E16856501007

It's more straightforward to run standard Linux distributions on this
hardware. The Raspberry Pi and ODROID are using ARM or Exynos chipsets;
distribution choices are limited and security updates often lag behind.
This particular Intel chip doesn't have AES-NI, but I'm running a relay on
one of these boxes that averages about 40 Mb/s, and has no problem spiking
up to 80 to 120 Mb/s when the load from Tor is higher.

If you want a box with AES-NI and a gigabit ethernet interface, cost starts
jumping up to several hundred US dollars or more, so I find the lack of
AES-NI to be an acceptable compromise for the value.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Legal status of operating Tor exit in UK?

[Green Dream]

> "I'm still not convinced that ToR isn't just an incredibly clever US
> government scheme where the US government stealthily operate a majority of
> the ToR (exit and intermediate) nodes, leading themselves to be able to
> anonymously inspect / MITM traffic from any exit node
> they operate, as well as correlate flows between non exit nodes to be able
> to find the original source of a flow."


If the ISP really feels this way, a logical solution would be to allow
exits from their network, thereby increasing the capacity of non-government
nodes. The irony.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] I.P. being Blocked?

[Green Dream]

Or just search Google for your relay's IP. You'll find several blacklists
that contain it and all the other relays. It's not FUD. Here are some more
examples:

https://www.dan.me.uk/torlist/
https://github.com/ktsaou/blocklist-ipsets/blob/master/dm_tor.ipset
https://github.com/ktsaou/blocklist-ipsets/blob/master/et_tor.ipset
https://panwdbl.appspot.com/lists/ettor.txt
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Guard flag flapping

[Green Dream]

 A simple test you could run on your server is fetching directory info
 from nodes that have directory functionality enabled.

Thanks for the idea. blutmagie offers a CSV list of its current result set,
so this ended up being quite easy to automate.

I fetched a copy of the CSV to the server:

  wget https://torstatus.blutmagie.de/query_export.php/Tor_query_EXPORT.csv

Then I picked out the columns I cared about, included only Exits with a
Dirport, then sorted by the bandwidth column, and grabbed the fastest 50:

   awk -F \, '{if ($10 == 1  $8 != None) print $3, $5, $8}'
Tor_query_EXPORT.csv | sort -nr | head -50  top-50-exits-with-dirport.txt

That file now looks like:

34994 37.130.227.133 80
33134 176.126.252.11 443
30736 176.126.252.12 21
30720 77.247.181.164 80
26958 77.247.181.166 80
snip

So we now have the bandwidth, IP, and dirport of the fastest exits. With
this list in hand, I just needed to form a proper URL, wget each one, and
grep out the transfer speed:

   for URL in $(awk '{print http://; $2 : $3 /tor/server/all}'
top-50-exits-with-dirport.txt); do printf $URL   wget $URL -O /dev/null
21 | grep -o [0-9.]\+ [KM]*B/s; done

The output ends up looking like this (only displaying the first 10 for
brevity):

http://37.130.227.133:80/tor/server/all 1.17 MB/s
http://176.126.252.11:443/tor/server/all 4.54 MB/s
http://176.126.252.12:21/tor/server/all 666 KB/s
http://77.247.181.164:80/tor/server/all 111 KB/s
http://77.247.181.166:80/tor/server/all 330 KB/s
http://195.154.56.44:80/tor/server/all 3.65 MB/s
http://77.109.141.138:80/tor/server/all 2.20 MB/s
http://96.44.189.100:80/tor/server/all 13.4 MB/s
http://197.231.221.211:1080/tor/server/all 347 KB/s
http://89.234.157.254:80/tor/server/all 295 KB/s

I'm not seeing anything immediately, although I need to run it on a larger
set. There's no smoking gun so far though. Some of the speeds are a bit
slow, but nothing low enough to explain the extremely low measured
bandwidth these relays are getting. I think I'll clean this up a bit, put
it into an actual script, and try running it on another server on a
different AS for comparison.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] clarification on what Utah State University exit relays store (360 gigs of log files)

[Green Dream]

 If you can confirm that the comment is authentic I'd be interested
 what kind of tor related data you are logging at your exit relays and
why.

 It's most likely netflow logs. Quite popular in Uni / regional ISP
 environments. People collect them for network stats, and to track
 down security incidents.

Yep. I worked as a network engineer for a large public university in the
US. They logged everything they could. There was at least 30 days of
netflow, plus packet inspection of certain flows.

There was little to no policy regarding access to the logs by staff. Law
enforcement requests went through the university's legal counsel.

I would expect most US universities to be logging netflow in the very
least. Even if the Tor operator isn't keeping logs, it seems safe to assume
the network operator is.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Guard flag flapping

[Green Dream]

On Sat, Aug 8, 2015 at 1:41 AM, tor...@safe-mail.net wrote:


 I ran some tests against your node. While performance is generally very
 good, it has very low performance connecting to some exit nodes.


Thanks for running the tests. Which exit nodes led to poor performance? I
would like to try to reproduce any performance problems.

How would you measure performance between my node and a given exit without
being influenced by the properties of the middle relay? You can only set me
as an entrynode, and you can't pick a specific middle, so how would you
know that the low performance was my node and not the random middle relay?

The problem is likely that your ISP is routing some traffic via an
 overloaded peering point.


This is certainly possible! It's the most compelling theory for me at the
moment, although I'm not convinced.


 Some ISPs have been know to do that on purpose, e.g. to make connections
 to Netflix or Youtube extremely slow while claiming not to do throttling.


Fortunately those practices are mostly coming to end in the US, with the
FCC's Open Internet rules adopted earlier this year. There is a way to
file complaints about it, but I'd need more data.

The bandwidth auths probably downrate the measurement results of your
 server severely because of those slow connections.


Probably? How can we investigate further?

As I write this one of the relays has the Guard flag again and is averaging
around 2 Mb/s. That still stinks, but the measured bandwidth shows only
15.0 Kb/s! Something is still ridiculously off. I'll continue digging. I
appreciate all the help thus far.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Guard flag flapping

[Green Dream]

I have two relays on the same Gb/s connection. I followed the optimization
tips offered in another thread, and think I have things running reasonably
well. What I don't understand is why the Guard flag keeps flapping back and
forth on both relays.

https://atlas.torproject.org/#details/89B9AE4C778DE44AFFAB791093E19979616E69C4

https://atlas.torproject.org/#details/11A579CC6CEE644A390704977B70CBA8D8347783

If you look at the 1 week graph of weights, you'll see what I mean.

I haven't been able to find any documentation or explanation for this
behavior. Anyone have any thoughts on why this might be happening, or any
pointers on how to further investigate?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Guard flag flapping

[Green Dream]

Thanks for the reply.

I had already run tests with both speedtest-cli and iperf3. This server
consistently achieves 200 to 300 Mb/s in both directions, with both relays
still running, and on some runs is hitting over 800 Mb/s.

The BWauth and self-measured bandwidths make no sense to me. Watching arm,
the averages are always in the X Mb/s range. I've watched these relays
serve 10 - 15 Mb/s each, 20 - 30 Mb/s in parallel, during busy times. Right
now one is running 1.6 Mb/s average and the other at 2.5 Mb/s, having
started these two arm instances about 2 hours ago. I don't find these
numbers to be very impressive given the capacity of the connection, but
they're still several orders of magnitude better than the measured
bandwidth. I don't understand the discrepancy.

I'm not using the ISP-provided router. It's not a consumer-grade router
either. I hesitate to list the specific model here, but according to its
specifications it shouldn't have a problem with the load, and indeed it
doesn't appear to be struggling at all.

In terms of optimizing the server, I've followed Moritz's guide. It doesn't
appear to be dropping connections. At one point I had 5000+ established
connections. The CPU and RAM are getting a work-out for sure, but neither
is maxed.

If there's a bottleneck on my side, I'm not sure where it is. What else
should I be checking? And why is actual performance in Mb/s so much higher
than the measured bandwidth? By the way, where are you finding the
historical BWauth and self-measured bandwidths?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays