Re: [tor-relays] Firewalls

[Quintin]

On Fri, Mar 2, 2018 at 10:04 AM TorGate  wrote:

> Hi to all,
> I have a simple question, what is the best firewall solution ?
> With sourcecode and must be opensource.
>

What are you trying to protect? An entire network or a single host?

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

Re: [tor-relays] bridge behavior question

[teor]

> On 5 Mar 2018, at 08:28, Arisbe  wrote:
> 
> Hello all,
> 
> I have run a number of Tor nodes for five years but I started adding a few 
> bridges last year.  I have one bridge recently installed on a lease VPS that 
> has not reported a single inbound connection in over 40 days (except for 
> Bifroest hanging out).  I see up to 4 outbound connections and usually see 
> between 4 and 14 circuits.
> 
> The IP tables are correct and torrc is copied from successful bridges except 
> for IP address.  The Tor version is 0.2.9.14 and the OS is debian 9.0 
> (stretch).  I'm running obfs4proxy.  I set ORPort 9001 and ORPort [IPv6]:9001.
> 
> Tor | Metrics reports Advertised Bandwidth = 8.0 KiB/s for this bridge.  Tor 
> | Metrics reports Advertised Bandwidth for another working bridge I have with 
> the same hosting company at 598.7 KiB/s.  I suspect this variation is due to 
> lack of connections by the unused bridge.  I loaded a speed checker and it 
> reported 72-Mb/s.
> 
> Can anyone give me some steerage to help me get this bridge productive?

BridgeDB has an unallocated pool of bridges for emergency use.

Run another bridge on the same hardware.

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

Re: [tor-relays] Publishing bridge contact information

[Roger Dingledine]

On Tue, Feb 20, 2018 at 05:51:44PM +0100, Karsten Loesing wrote:
> FWIW, we collected all feedback from this thread, discussed this change
> in the metrics team, and forwarded our planned change to the Tor
> Research Safety Board. I don't know how fast that will move, but I could
> imagine it's a matter of weeks, not days.

I just put in a review over on the safety board page, but I'm publishing
it here too for completeness / efficiency:

Thought 1: I wouldn't worry that much about whether published
contactinfo would help an adversary do blocking. There are many ways
that bridge enumeration might happen, and this one seems pretty tame and
limited.

But thought 1b: Is there a way to discover if we were wrong and it *is*
helping an adversary? It would be nice to have some way to validate this
decision not to worry, and some way to detect if it turns out we were
wrong. I can't think of a good way, and the lack of a feedback mechanism
makes the assumption more risky to act on.

Thought 2: Ordinarily, research groups would do the analysis privately
on their data set, and publish only the results. That is, the safety
board question would be "Can I collect this data? I'll throw it away
afterwards and only publish my analysis." But this is a different
situation: the goal is to provide a public data set so others can do
their own analysis. It's a tradeoff: potential surprises to bridge
operators vs potential benefits to community. This is really a community
growth strategy decision. When phrased that way, you might be able to
include some more concrete points in the "positive" category, such as:
ability for more external researchers to get involved, and increased
chance that a community of bridge operators develops. And speaking of
community-building, are there volunteers lined up who would contact
bridge operators if given the chance, or is this more of a theoretical
"maybe it would happen"?

Thought 3: I think sending mail to the current contactinfos, telling
them that starting in a few weeks their contactinfo will go public, is a
fine approach on the "notice / consent" spectrum -- especially since as
you say they technically already got notice when they were editing the
torrc file, so this follow-up attempt wouldn't be the first try.

Thought 4: In retrospect, it would be good to have some initial analysis
of the (currently secret) data set. For example, how many bridges set
contactinfo, and how many don't? How many of each of those are 'fast'
(popular) bridges? What fraction of the contactinfos are actually a
usable email address? How many bridge families are there now, i.e.
bridges that use the same contact email address? Maybe most bridges
don't set it currently, so this whole question doesn't matter much, or
maybe many of them set it but obfuscate it, which will make your
notification plan harder than you predicted.

--Roger

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

Re: [tor-relays] less than 3 bw auths available: self-measurement (with 10k cap in effect)

[teor]

> On 5 Mar 2018, at 00:35, Stijn Jonker  wrote:
> 
> Perhaps it makes sense to do a call and add some more bandwidth authority 
> relays
> during the upcoming meeting in Rome similar to the Montreal meeting.
> Would the following documents still be valid (They themselves state they 
> might be outdated)?
> https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthority
> https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthorityMeasurements
> 
> Also what bandwidth should an bwauth have available itself?
> 
> I can see if I can support by running one, although it will be EU based.
> You need a directory authority to vote on your bandwidth authority's output.
> 
> Do you know what is the best way to get these vote(s), i.e. who to approach; 
> as these kind of things are still a mystery with the Tor project for me. From 
> a personal believe happy to assist, have reasonable spare CPU/Mem and 
> Bandwidth available. So that should't be an huge issue. I know a thing or two 
> about running systems so to say..
> 

It's a big ask.

You need a directory authority operator to trust you enough to take
arbitrary, unvalidated output from a process you run, and feed it to
their directory authority.

Try to meet some directory authority operators, if you don't know any.
Get involved in running relays and other Tor volunteer work.

But it might not happen.

> Bandwidth authorities measure relay capacity. Then they send their results to 
> a
> directory authority, and the directory authority puts the results in its 
> vote. The
> directory authority votes change the consensus weights of relays.
> 
> If your bandwidth authority isn't used for voting or testing, it's just 
> wasting
> bandwidth.
> 
> If you want to test and contribute code to a new bandwidth authority
> implementation, I'd recommend:
> 
> https://github.com/TheTorProject/bwscanner
> 
> Thanks I found the TorFlow repo; that feels a bit hacked, but if either do 
> the job and the above Q can be answered then happy to (try and) set it up.
> 

We need a bandwidth authority implementation that works better
than TorFlow. One thing you can do to help is run bwscanner, and
feed its output to a test directory authority.

You might find chutney useful for setting up a test network:
https://gitweb.torproject.org/chutney.git

> But you'll need to change the default bandwidth server config, due to the
> tor project DDoS.
> 
> I assume that can be shared in a more private setting then.
> 

You can set up your own bandwidth server:
https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/README.BwAuthorities#n157

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

Re: [tor-relays] One pubblic IP, two or more relay on different ports

[teor]

> On 5 Mar 2018, at 00:20, MLTorNode  wrote:
> 
> Mar 04 04:31:37.000 [notice] Your relay has a very large number of 
> connections to other relays. Is your outbound address the same as your relay 
> address?

Does your NAT box have multiple IP addresses?
Does it have an IPv4 and IPv6 address, and is the IPv6 address configured on
your relay?

This might be an issue with your NAT.
Does it support 14000 simultaneous connections?
Most consumer NATs don't.
(There are 7000 relays, and every one will try to connection every other relay.)

> Found 15 connections to 10 relays. Found 15 current canonical connections, in 
> 0 of which we were a non-canonical peer. 5 relays had more than 1 connection, 
> 0 had more than 2, and 0 had more than 4 connections.
> Mar 04 05:31:35.000 [notice] Heartbeat: Tor's uptime is 5:59 hours, with 0 
> circuits open. I've sent 7.50 MB and received 17.31 MB.
> Mar 04 05:31:35.000 [notice] Circuit handshake stats since last time: 0/0 
> TAP, 21/21 NTor.
> Mar 04 05:31:35.000 [notice] Since startup, we have initiated 0 v1 
> connections, 0 v2 connections, 0 v3 connections, and 9 v4 connections; and 
> received 0 v1 connections, 3 v2 connections, 0 v3 connections, and 18 v4 
> connections.

It looks like a small number of other relay have connected twice to your relay,
or you connected to them, and they connected back. The problem should
go away after a week when the connections rotate.

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

[tor-relays] bridge behavior question

[Arisbe]

Hello all,

I have run a number of Tor nodes for five years but I started adding a 
few bridges last year.  I have one bridge recently installed on a lease 
VPS that has not reported a single inbound connection in over 40 days 
(except for Bifroest hanging out).  I see up to 4 outbound connections 
and usually see between 4 and 14 circuits.


The IP tables are correct and torrc is copied from successful bridges 
except for IP address.  The Tor version is 0.2.9.14 and the OS is debian 
9.0 (stretch).  I'm running obfs4proxy.  I set ORPort 9001 and ORPort 
[IPv6]:9001.


Tor | Metrics reports Advertised Bandwidth = 8.0 KiB/s for this bridge.  
Tor | Metrics reports Advertised Bandwidth for another working bridge I 
have with the same hosting company at 598.7 KiB/s.  I suspect this 
variation is due to lack of connections by the unused bridge.  I loaded 
a speed checker and it reported 72-Mb/s.


Can anyone give me some steerage to help me get this bridge productive?



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

Re: [tor-relays] CPU saturation attack/abuse

[Dhalgren Tor]

Found other ones:  December 24 where egress was much higher then
ingress (but crypto-workers were pegged, not main thread).  December
28 & 29, attack like today.  Feburary 1 & 2, like today with ingress
higher than egress.

In today's and the latter-two above the main event thread was pegged
either continuously or intermittently with ingress higher than egress.

Just looked again and see all threads, crypto-worker and main-event
pegging episodically.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] CPU saturation attack/abuse

[Dhalgren Tor]

On Sun, Mar 4, 2018 at 7:06 PM, Toralf Förster  wrote:
> On 03/04/2018 07:41 PM, Dhalgren Tor wrote:
>>  the main event-worker thread
>> going from a normal load level of about 30%/core to 100%/core and
>> staying there for about 30 seconds;
> I do wonder if this is just the normal behaviour when - IIRC correctly - 
> consensus documents are compressed before sending.

No chance whatsoever.  Relay runs for months-on-end never exceeding
40% CPU.  Have seen the same or a similar attack, twice before I
believe under 0.2.9.14.  Just realized the ISP added some bugs to
their data graphs:  in this case _ingress_ traffic is 3-4% higher than
egress (they reversed the labels along with breaking long-term
historical).  Earlier observed a similar attack where _egress_ traffic
was 10-15% higher than ingress traffic.

What's interesting here is the crypto-worker threads are near zero
(normal) in contrast to circuit-extend attacks where the crypto
threads peg at 100%.  Did see one brief, intense crypto-
worker CPU spike today but it's not characteristic of this event in general.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] CPU saturation attack/abuse

[Toralf Förster]

On 03/04/2018 07:41 PM, Dhalgren Tor wrote:
>  the main event-worker thread
> going from a normal load level of about 30%/core to 100%/core and
> staying there for about 30 seconds; 
I do wonder if this is just the normal behaviour when - IIRC correctly - 
consensus documents are compressed before sending.

-- 
Toralf
PGP C4EACDDE 0076E94E



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] CPU saturation attack/abuse

[Dhalgren Tor]

Upgraded exit to 0.3.3.3 and now seeing a curious CPU saturation
attack.  Whatever the cause, result is the main event-worker thread
going from a normal load level of about 30%/core to 100%/core and
staying there for about 30 seconds; then CPU consumption declines back
to 30%.  Gradual change on ascent and decent.  Another characteristic
is egress traffic slightly higher than ingress traffic, perhaps 3-4%,
where normally egress and ingress flows match precisly.  Checked
browsing via the node and performance seems fine--no obvious
degradation.  Elevated NTor circuit creation rates as-of the last
heartbeat, from roughly 300k to 700k per-report, but not extreme (at
least in a relative sense since late December).

Anyone else observed this?  Have any idea how the attack works?

Captured a debug-level log of a cycle from normal load to
full-on-attack but won't have time to analyzed it for a couple of
weeks.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] less than 3 bw auths available: self-measurement (with 10k cap in effect)

[Stijn Jonker]

Hi Teor & Others,

Thanks for your response,

On 2 Mar 2018, at 23:26, teor wrote:

> > On 3 Mar 2018, at 02:15, Stijn Jonker  wrote:
>>
>> On 2 Mar 2018, at 12:08, Vasilis wrote:
>>
>> Hi,
>>
>> Roger Dingledine:
>>
>> On Tue, Feb 27, 2018 at 06:47:00PM +, nusenu wrote:
>>
>> if your relays behave strangely in terms of bandwidth seen, than this
>> might be due to the fact that there are less than 3 bw auth votes available.
>>
>> If you run a fast relay it is capped to 10k cw.
>>
>> This affects currently the 857 fastest relays.
>>
>> Yep! We had 4 running, but 2 of them had problems, and we need 3
>> for the authorities to want to use the values from them.
>>
>> Perhaps it makes sense to do a call and add some more bandwidth authority 
>> relays
>> during the upcoming meeting in Rome similar to the Montreal meeting.
>> Would the following documents still be valid (They themselves state they 
>> might be outdated)?
>> https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthority
>> https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthorityMeasurements
>>
>> Also what bandwidth should an bwauth have available itself?
>>
>> I can see if I can support by running one, although it will be EU based.
>>
>
> You need a directory authority to vote on your bandwidth authority's output.

Do you know what is the best way to get these vote(s), i.e. who to approach; as 
these kind of things are still a mystery with the Tor project for me. From a 
personal believe happy to assist, have reasonable spare CPU/Mem and Bandwidth 
available. So that should't be an huge issue. I know a thing or two about 
running systems so to say..

> Bandwidth authorities measure relay capacity. Then they send their results to 
> a
> directory authority, and the directory authority puts the results in its 
> vote. The
> directory authority votes change the consensus weights of relays.
>
> If your bandwidth authority isn't used for voting or testing, it's just 
> wasting
> bandwidth.
>
> If you want to test and contribute code to a new bandwidth authority
> implementation, I'd recommend:
>
> https://github.com/TheTorProject/bwscanner

Thanks I found the TorFlow repo; that feels a bit hacked, but if either do the 
job and the above Q can be answered then happy to (try and) set it up.

> But you'll need to change the default bandwidth server config, due to the
> tor project DDoS.

I assume that can be shared in a more private setting then.

Stijn

signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] One pubblic IP, two or more relay on different ports

[MLTorNode]

nusenu ha scritto il 03/03/2018 alle 20:03:
>
>
> MLTorNode:
>> Is it possibile? I have one dynamic public IP with one relay server 
published on

>> ORPort 443 and DIRport 80 (with IPv6 ORPort too).
>> Can i add a second relay with OR and DIR natted on other ports 
published on the

>> same IP of the first server?
>
> you can run up to two tor relay instances on a single public IPv4.
>
> You can not run more than 2 instances per public IPv4.

Yes, but i have a strange problem: my first relay is MLTorNode (Linux 
Debian), with ORPort NATted on public port 443 and DIRPort NATted on 
public port 80. This relay works without problems, i can see the 
configuration in Atlas.


The second relay (MLTorNode02) is running on another PC with Windows 
2016 Server. It publish ORPort on NATted 9001 public port.
In this relay, however, I have strange NOTICE in log and very very few 
connections.

These are the logs:

=
[...]
Mar 03 23:33:45.000 [notice] No circuits are opened. Relaxed timeout for 
circuit 26 (a General-purpose client 3-hop circuit in state doing 
handshakes with channel state open) to 6ms. However, it appears the 
circuit has timed out anyway.
Mar 03 23:34:01.000 [notice] Tor has successfully opened a circuit. 
Looks like client functionality is working.

Mar 03 23:34:01.000 [notice] Bootstrapped 100%: Done
Mar 03 23:34:01.000 [notice] Now checking whether ORPort 
82.51.162.68:9001 and DirPort 82.51.162.68:9030 are reachable... (this 
may take up to 20 minutes -- look for log messages indicating success)
Mar 03 23:34:19.000 [notice] Self-testing indicates your DirPort is 
reachable from the outside. Excellent.
Mar 03 23:34:21.000 [notice] Self-testing indicates your ORPort is 
reachable from the outside. Excellent. Publishing server descriptor.

Mar 03 23:34:22.000 [notice] Performing bandwidth self-test...done.
Mar 04 02:31:36.000 [notice] Your relay has a very large number of 
connections to other relays. Is your outbound address the same as your 
relay address? Found 12 connections to 8 relays. Found 12 current 
canonical connections, in 0 of which we were a non-canonical peer. 4 
relays had more than 1 connection, 0 had more than 2, and 0 had more 
than 4 connections.
Mar 04 03:31:35.000 [notice] Your relay has a very large number of 
connections to other relays. Is your outbound address the same as your 
relay address? Found 13 connections to 8 relays. Found 13 current 
canonical connections, in 0 of which we were a non-canonical peer. 5 
relays had more than 1 connection, 0 had more than 2, and 0 had more 
than 4 connections.
Mar 04 04:31:37.000 [notice] Your relay has a very large number of 
connections to other relays. Is your outbound address the same as your 
relay address? Found 15 connections to 10 relays. Found 15 current 
canonical connections, in 0 of which we were a non-canonical peer. 5 
relays had more than 1 connection, 0 had more than 2, and 0 had more 
than 4 connections.
Mar 04 05:31:35.000 [notice] Heartbeat: Tor's uptime is 5:59 hours, with 
0 circuits open. I've sent 7.50 MB and received 17.31 MB.
Mar 04 05:31:35.000 [notice] Circuit handshake stats since last time: 
0/0 TAP, 21/21 NTor.
Mar 04 05:31:35.000 [notice] Since startup, we have initiated 0 v1 
connections, 0 v2 connections, 0 v3 connections, and 9 v4 connections; 
and received 0 v1 connections, 3 v2 connections, 0 v3 connections, and 
18 v4 connections.

=

Thanks in advance,

--
Marlenio (MLTorNode)
FE4033D750831C32A957174ADD11E40F558A14A9
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [WARN] Your computer is too slow to handle this many circuit creation requests

[Vasilis]

Hi,

*UPDATE**
I'm still seeing these warning messages but in a lower frequency:
Your computer is too slow to handle this many circuit creation requests! Please
consider using the MaxAdvertisedBandwidth config option or choosing a more
restricted exit policy. [1077 similar message(s) suppressed in last 60 seconds]


The defenses seems to be working (?):
DoS mitigation since startup: 45482775 circuits rejected, 157 marked addresses.
2187600 connections closed. 993 single hop clients refused.


~Vasilis
-- 
Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162
Pubkey: https://pgp.mit.edu/pks/lookup?op=get=0x5FBF70B1D1260162



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays