Hey!
I'm planning to try the "ansible-relayor" to deploy some Tor relay
instances.
If I'm not wrong, it's a main goal ?
2 instances / IP...
(soooory for being really noob about this!!!)
But I'm lost... not found a tutorial, step by step, you know the
tutorial so loved by all noobs!
For now, on a fresh Debian8 install,
there are :
- tor 0.2.9.8 (fresh install from depo, client is ok when opening log file)
- ansible
- ansible-galaxy install nusenu.relayor
- git clone https://github.com/nusenu/…
[View More]ansible-relayor
(the folder is stored in my /home...)
Will it configure (automatically) many torrc file per instance ? +every
key files /relay ? (I'm not too much lost!)
Do have I to do this install on every server built ? Or relayor can
manage few servers on different locations ?
Command lines list use this tool if available ?
Many thx for help !!! (and hard work for this tool :)
--
Petrusko
C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5
[View Less]
Hello everyone!
Since July 2017, there has been a steady decline in relays from ~7k to now
~6.5k. This is a bit unusual that is we don't see often such a steady behavior
of relays going offline (at least that I can remember...).
It could certainly be something normal here. However, we shouldn't rule out a
bug in tor as well. The steadyness of the decline makes me a bit more worried
than usual.
You can see the decline has started around July 2017:
https://metrics.torproject.org/networksize.…
[View More]html?start=2017-06-01&end=2017-1…
What happened around July in terms of tor release:
2017-06-08 09:35:17 -0400 802d30d9b7 (tag: tor-0.3.0.8)
2017-06-08 09:47:44 -0400 e14006a545 (tag: tor-0.2.5.14)
2017-06-08 09:47:58 -0400 aa89500225 (tag: tor-0.2.9.11)
2017-06-08 09:55:28 -0400 f833164576 (tag: tor-0.2.4.29)
2017-06-08 09:55:58 -0400 21a9e5371d (tag: tor-0.2.6.12)
2017-06-08 09:56:15 -0400 3db01d3b56 (tag: tor-0.2.7.8)
2017-06-08 09:58:36 -0400 64ac28ef5d (tag: tor-0.2.8.14)
2017-06-08 10:15:41 -0400 dc47d936d4 (tag: tor-0.3.1.3-alpha)
...
2017-06-29 16:56:13 -0400 fab91a290d (tag: tor-0.3.1.4-alpha)
2017-06-29 17:03:23 -0400 22b3bf094e (tag: tor-0.3.0.9)
...
2017-08-01 11:33:36 -0400 83389502ee (tag: tor-0.3.1.5-alpha)
2017-08-02 11:50:57 -0400 c33db290a9 (tag: tor-0.3.0.10)
Note that on August 1st 2017, 0.2.4, 0.2.6 and 0.2.7 went end of life.
That being said, I don't have an easy way to list which relays went offline
during the decline (since July basically) to see if a common pattern emerges.
So few things. First, if anyone on this list noticed that their relay went off
the consensus while still having tor running, it is a good time to inform this
thread :).
Second, anyone could have an idea of what possibly is going on that is have
one or more theories. Even better, if you have some tooling to try to list
which relays went offline, that would be _awesome_.
Third, knowing what was the state of packaging in Debian/Redhat/Ubuntu/...
around July could be useful. What if a package in distro X is broken and the
update have been killing the relays? Or something like that...
Last, looking at the dirauth would be a good idea. Basically, when did the
majority switched to 030 and then 031. Starting in July, what was the state of
the dirauth version?
Any help is very welcome! Again, this decline could be from natural cause but
for now I just don't want to rule out an issue in tor or packaging.
Cheers!
David
--
HiTVizeJUSe9JPvs6jBv/6i8YFvEYY/NZmNhD2UixVY=
[View Less]
I'm sending this message to announce that we will be releasing new
stable and versions of Tor tomorrow, to fix 5 security bugs. I
apologise for the short notice; we've had to move up our intended
release date in order to try to match with release deadlines for
downstream projects.
We have classified 3 of these bugs as Medium and 2 as High, per draft
security process at
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Securit…
. The most serious bugs are a pair of denial-…
[View More]of-service issues, which
we treat as high security because of the possibility of escalating
them for traffic-analysis purposes.
Note that only the following series are supported, and only they will
receive updates: 0.2.5, 0.2.8, 0.2.9, 0.3.0, 0.3.1, and 0.3.2. 0.2.8
and 0.3.0 will become unsupported in January; 0.2.5 will become
unsupported in May.
best wishes,
--
Nick
[View Less]
>Well, it's still going on, and is pretty much ruining Libero :( . Running CentOS 6, here.
>
>When it's happening it can look like this:
>
># netstat -n | grep -c SYN
>17696
I run a fast exit and can offer some advice:
1) mitigate bug #18580 (also #21394); is a DNS denial-of-service and
could be the problem. either upgrade to 0.3.2.4+ or edit resolve.conf
per https://trac.torproject.org/projects/tor/wiki/doc/DnsResolver#Tuningeventdn…
also check out https://…
[View More]arthuredelstein.net/exits/
2) if you continue to experience excessive outbound scanning SYNs,
I've found that simply enabling connection tracking helps by
implicitly limiting the rate a which connections can originate. If an
iptables "-m state --state ESTABLISHED,RELATED -j ACCEPT" rule exists
it will turn it on or you could modprobe the module if you don't want
to configure incoming connection rules.
some useful sysctl.conf changes, run sysctl -p after or reboot
# Tor Exit tuning.
net.ipv4.ip_local_port_range = 1025 65535
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_max_tw_buckets = 4194304
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3
net.netfilter.nf_conntrack_tcp_timeout_established = 1000
net.netfilter.nf_conntrack_checksum = 0
you might see many messages:
kernel: nf_conntrack: table full, dropping packet
which indicates no connection table slots were available for an
outbound connection and that rate limiting is effected
state of connection tracking appears in /proc/net/nf_conntrack
[View Less]
I spoke too soon, it seems - the exit is struggling again, with some
time spent destroyed today.
As I look at what it's doing, it's clear that someone is relaying SYN
packets to random ports and also random destination addresses that
aren't even alive. The destination hosts and ports continually vary -
it never hits multiple destinations on 1 port, and it does not hit
multiple ports on 1 host. I presume it is an attack that is intended
to degrade this relay's service quality, or …
[View More]otherwise more broadly,
degrade Tor.
I'm going to reject a few more trojan listen ports, it might help but
it isn't a real fix.
My thought btw was for Tor to rate-limit syn scanning activity between
the client and the first onion router, with the function taking place
in that first-hop router, not at the exit.
[View Less]
Thanks for the configuration suggestions. I intentionally set the
conntrack limit high, maybe that was not the best thing. I think I'll
be putting it back.
Removing my extra IPTables code plus adding a reject for :8888 has
made the exit behave properly again.
I wonder if the best possible course of action for this sort of thing
would be within Tor itself. I don't know that it was a single client
connection into Tor that was causing all this trouble, but maybe it
was. One would think …
[View More]that one client should not be allowed to do
something so severe with the TCP that it can single-handedly ruin a
fast exit. Maybe a code change that forces a rate-limit that
significantly slows down the ability of a single client to roll port
scans should be considered by the devs.
[View Less]
Well, it's still going on, and is pretty much ruining Libero :( .
Running CentOS 6, here.
Actually, I think from what I'm seeing that it may not exactly be a
synflood targeting Libero. I think Libero may be being (ab)used to do
massive portscanning or similar.
Image should be visible below - it's normal statistics for the 18th
through say, part of the 21st, messed up 22ed - 24th and on the 24th
me trying different things in an attempt to mitigate (graph is from
yesterday). Look at the …
[View More]SYN_SENT2 maximum.
When it's happening it can look like this:
# netstat -n | grep -c SYN
17696
#
Also one tiny part of the netstat looked like this:
tcp 0 1 64.113.32.29:33354 <external IP
munged>:81 SYN_SENT
tcp 0 1 64.113.32.29:39659 <external IP
munged>:8888 SYN_SENT
tcp 0 1 64.113.32.29:44247 <external IP
munged>:87 SYN_SENT
tcp 0 1 64.113.32.29:42038 <external IP
munged>:8888 SYN_SENT
tcp 0 1 64.113.32.29:42077 <external IP
munged>:83 SYN_SENT
tcp 0 1 64.113.32.29:36282 <external IP
munged>:8888 SYN_SENT
tcp 0 1 64.113.32.29:46023 <external IP
munged>:8888 SYN_SENT
Port 8888 is supposedly opened up for listen by a virus.
[View Less]