Re: [tor-relays] my IP got blocked

2017-11-14 Thread Julien ROBIN

Hi,

It's not the first time I hear about Non-Exit IP blocked (but may be 
some people here are more familiar with the subject) : I don't really 
know what are the most used interfaces/websites from which those 
administrators are getting the list of IP addresses before blocking them 
(are they downloading the full consensus list like tor clients or from 
another website ?).


May be websites proposing these lists should split them in 2 distinct 
lists, and normally show only exit nodes unless something very precise 
is asked by the user for seeing all tor relays including non exit. For 
lazy/angry administrators trying to definitely block all Tor IP 
addresses without considering giving any another time or second chance 
it would avoid some of these non exit relays blocked ? Of course ideally 
those administrators are doing some mistake and the problem is coming 
from them more than from anybody else (or may be bad users, too). But 
into the facts, when a mistake is repeatedly done, may be changing some 
things should be considered ? If possible of course (it's not always 
simple or quick).


Best regards,
Julien ROBIN

Le 14/11/2017 à 13:45, Matt Traudt a écrit :


On 11/14/17 07:38, Patrice wrote:

Hi everyone,


I`ve got an issue with my local IP address. I am running a relay about 1
year and since 3 or 4 weeks I can`t reach some websites like: ebay or ikea.

All I get is this message:

*
*

*Access Denied*
You don`t have permission to access "Http://www.ebay.com/" on this server.

Reference # looong number__


I think I am on some blacklists. After I change my IP address all worked
fine for only 2 days.

Can I do something about this?

Thank you for your help!

Kind regards
Kalle


If you're running an exit, they probably saw abusive traffic, didn't
like it, and blocked your IP. You could consider not running an exit
relay from home.

If you're running a non-exit, then they're being dumb for blocking your
IP when it is impossible for abusive traffic to come from your relay.
Some webmasters who don't understand Tor do that, but there's not really
anything we can do. Best I can suggest is you try talking to them, which
isn't a very satisfying suggestion, I know.

Matt
___
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] Bandwidth Measurement

2017-02-20 Thread Julien ROBIN

Hi,

I think that in this case, every existing connection and transfers act 
as "best effort" (it means that used bandwidth for some connection 
aren't absolutely reserved),  the new transfer is making a place by 
reducing just a little bit the others connection's available speed.


If 50 active connection are using 1 MB/s each at the same time, with a 
total amount of 50 MB/s which is the maximum of a given server for 
example, then a new connection trying to get 1 MB/s will make the 50 
Megabits divided by 51, then the usable bandwidth for all connection 
becomes 0,98 MB/s in the place of 1 MB/s


When your relay is very overused and severe congestion occurs, then the 
bandwidth measurement will be very poor, this will reduce the weight of 
your relay in the consensus in order to reduce the congestion. The 
algorithm is designed to give the ideal consensus weight for your relay 
in order to be as close as possible of your maximum available bandwidth, 
without placing too much users on it (with too much users on it, the 
total used bandwidth will be at the maximum, but each user get a painful 
browsing experience because the available bandwidth per user becomes too 
weak)


Bye !

Julien

PS : if the advertised bandwidth is incorrect then congestion will occur 
and the consensus weight of your relay will be decreased because of poor 
performance during measurements, that's how possible 
cheating/disturbance is avoided in this case, I think.


I think there is some documentation on this subject, by searching if you 
have some time and want to know more on this subject.



Le 20/02/2017 à 18:39, Marcobr a écrit :

Hey everyone,

as far as I know, the DAs running the bwauth scripts conduct hourly 
bandwidth measurements. Depending on the advertised bandwidth of the 
relay node, a smaller/bigger file gets transmitted on a custom 
2-hop-circuit and the transmission time determines the actual bandwidth.


Now, here is my problem: Assuming that my relay node advertised 
50MB/s, and is currently at 98% load (49 MB/s). To conduct the 
measurement, the bwauth script will send a 8MB file over my relay, but 
since it can only serve another 1MB/s, how will the bwauth script 
determine that my advertised 50MB/s is correct?



___
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] Vodafone Italia blocking traffic from IPs that belong to Tor relays

2016-11-27 Thread Julien ROBIN

Hi,

Apart from the problem of non-exit relays, I also think there is a 
problem with blocking users from exit nodes.


Anyway, whatever the point of view is about Exit Nodes blocking, it's 
sure that blocking entry and middle nodes is not useful, it's the 
signature of either something that is misunderstood, or something (bad 
?) that is done in a very lazy way (!) ...  in both case that's 
exasperating ! Additionally it's making normal Internet navigation 
painful and censored for those who operate relays at home. Getting 
censored while fighting against censorship is really depressing.


Even if some webmasters don't care anymore about Tor and online privacy, 
because in the past they got pissed of by misuses and don't want to talk 
anymore about "what should be done ideally"; I think that others aren't 
really aware of possible solutions, and what is at stake about online 
right and Internet of tomorrow, because it's not always obvious in their 
position.


By blocking fair usages of Tor they are going to make Tor censored and 
unable for fair navigation and that's the absolute opposite of what 
should be done ! For everybody. I think that a lot of big websites are 
aware of this (and it's a chance, otherwise nothing would be available 
from Tor, and Tor usage would be prohibited everywhere), but 
unfortunately not all website owners are aware of this.


I see 2 things :

 * For website owners who have big amount of problems with Tor misuses,
   the good approach could be Captcha, for forums / message boards it
   can be a moderator approval of first message, in order to make only
   "fair" usage possible. Finding that kind of ideas maybe is the only
   possible way to make sysadmins and freedom volunteers to agree on
   something technically working for everybody. May be we should list
   everything that makes a sysadmin banning Tor IP addresses and see
   what technical solution could be suggested.

 * Also, for raising awareness about this subject at large scale may be
   some big organisations like Mozilla could do something significant
   enough, but individually it's complicated to convince somebody who
   have pretty strong and fixed ideas, and bad experiences in the past.
   May be some others discussion already discussed this subject in the
   past and got good conclusions about ideal approach for this problem,
   and how to ideally handle this kind of situations ?


Julien ROBIN



On 27/11/2016 11:31, fnordomat wrote:

Ah, the unfathomable depths of human stupidity never cease to amaze.

fr33d0m4all, you did the right thing. In the absence of negative
reinforcement, the persons responsible will continue thinking they are
doing the right and sensible thing. Of course, the pessimistic
standpoint is that words never convinced anyone, but I for one believe
in trying.

We are still documenting sites whose wannabe admins discriminate against
Tor btw:

https://pad.systemli.org/p/noncloudflare-torblocks
http://j7652k4sod2azfu6.onion/p/noncloudflare-torblocks

I added ricarica.vodafone.it to it.

As a Tor-only user, I'm accustomed to seeing this kind of stupidity -
fed up with it - but I know for sure that it's hardly going to stop
anytime soon. Many trends point in the opposite direction - the
apperception that it's OK to discriminate against people who value their
privacy and security, the idea that it's OK to paint us as criminals,
and tools like Tor as impractical for daily use.

The kindest thing I'm prepared to say about Tor blockers is that they're
mediocre individuals who never bothered to look behind the FUD. The best
thing about Tor blockers is that they're not out there burning actual
witches, but sitting somewhere burning virtual ones and jerking off to
their own friggin' feeling of comforting normalcy in unnormal times.

It's discrimination, pure and simple.

But the inconvenience of having to find ways around a block - sometimes
after some important transaction fails - is a minor thing: not everyone
knows how to do that, or manages quickly to find a proxy that is
unblocked. Novice users could very well give up at this point. No one
should be comfortable thinking that sabotaging public perception of the
practicality of casual anonymity, in times of mass surveillance, is
acceptable.

And yet here we are - a whole industry offers the snake-oil "security"
of Tor blocking lists, or blocking and MitM as an infrastructure. And
there's plenty of wannabe webadmins out there who implement such things,
mistakenly thinking three things:

a) they need that for "security"

b) it buys them anything in terms of real security, rather than being a
quick fix to temporarily reduce the volume of "suspicious" or fraudulent
events

c) their classification of traffic into "mostly legit" from outside Tor,
and "mostly crooked" from Tor is correct.

Reality is more complex and panopticon-style surveillance of course
drives any activity tha

Re: [tor-relays] Interrogated by Finnish police for alleged idendity crimes, fraud and attempts of fraud

2016-11-01 Thread Julien ROBIN
the meeting is fine.
>
> Each time, I explain that my servers are rented in my name, and that I
> use them for volunteer participation to a free proxies and VPN network
> called Tor. I then give some details and explanations about what is Tor,
> who created it, what are the goals of the project (about protection of
> expression in bad countries and censorship avoidance, by accessing the
> same Internet that others do, pricacy protection too), and yes, the
> misuses... and that these are discouraging misuse and it is not the
> reason why we participate in this network (far from it !). Then I give
> the IP of those servers (and one of them is the reason why they called
> me). And I explain that they are computers with a very fast bandwidth,
> located in datacenters (Rennes, Vitry...) that can be accessed and
> configured remotely, like a remote desktop.
>
> When they ask the question about logs and how to find the author of the
> fact, my answer is that (unfortunately in that case), Tor is designed as
> it's not possible for anybody to find who is the IP address from where
> the traffic originated. It's very secure for those who need to use it.
> Of course I tell them that if they have suspects in the entourage of the
> victim, they can check if one of them was connected to the Tor network
> at the time of the "fact" but as me and others people are using Tor for
> online privacy without any intention of misuse against anybody, using
> Tor is not a proof of misuse and is most of the time not done for bad
> intention. Of course some questioning about a suspect using Tor at the
> same hour would be rightful in this particular situation, anyway (like I
> was questioned).
>
> All time I also come with a sheet of paper explaining Tor a little bit
> deeply, what are the motivation of the teams and people behind this
> project, (even in front of misuses that we are, of course, not proud of
> having on the Tor network, even if without the Tor network, those
> misuses would have been done by another way). In France I
>
> Of course sometimes the agent is not very happy about the Tor Network as
> the investigations is likely to fail because of the Tor Network
> efficiency. When the misuse is real and obviously bad, nobody can be
> happy of it !
>
> In all those cases, my words are honest and true; as we shouldn't be
> ashamed of participating to projects aiming to a better word and more
> freedom, but shouldn't be happy of misuses, my personal preference is to
> be understanding and true. I also tell them that I'm participating, with
> my computers, to others scientific projects like World Community Grid
> (explaining it's about cancer research and a lot of others subjects) :
> It can be seen as "not related" but it is, as that's the way we are
> volunteers to the Tor Network !
>
>
> Here's for my feedback ! It's very personal of course, I hope nobody
> would copy it without feeling it :) I'm just expressing my own feeling
> on those situations, if it can help everybody to better understand those
> cases.
>
> Best regards !
>
> Julien ROBIN
>
>
> On 31/10/2016 14:25, Juuso Lapinlampi wrote:
>> Putting the word out: I was interrogated by the Finnish police 
today for

>> multiple alleged counts (15+) of identity crimes, fraud and attempts of
>> fraud. The invitation letter to be interrogated was sent out on
>> 2016-10-21 and received by me on 2016-10-25. Today is 2016-10-31.
>>
>> The police suspects me because of an "IP-address assigned to my name",
>> which I can't confirm or deny to have a relation to me. As a suspect, I
>> was not told what this aclaimed IP-address was on a specific date to my
>> knowledge. It is only speculation if these allegations wrongly against
>> me have something to do with my relation with the Tor community or
>> activism about digital rights online.
>>
>> Pending ongoing investigation, I am not allowed by law to share more
>> specific details about to the investigation. I'd be glad to reveal more
>> details about the case once the investigation is over and 
share/hear how

>> I became a suspect, once I know about it. (Note that my story is at
>> least slightly opinionated.)
>>
>> I had a witness with me and I feel like my rights were being violated
>> during the interrogation. The officer (not to be named publicly in
>> respect for privacy) didn't want to allow me to write down their badge
>> number by taking the badge away from me while trying to write down the
>> numbers. The officer looked slightly anxious.
>>
>> After refusing to comment on few questions (to which I have a legal
>> right as a suspect), soon after me and my belonging

Re: [tor-relays] Interrogated by Finnish police for alleged idendity crimes, fraud and attempts of fraud

2016-10-31 Thread Julien ROBIN

Hi,

With the 3 big exit nodes I had in France (about 30MB/s in both 
direction for each of them), I got called by police a lot of time (may 
be 10 times approximately ? I do not really count anymore) on 
investigations about misdeed that was committed from IP addresses of my 
Tor relays (95.130.9.190 and 95.130.9.89 mainly, at Digicube, not 
running anymore since June, 2015). No call about the Online.net one 
(62.210.206.25, now Relay only since January, 2015), which was as big as 
the 2 others and Exit too, but the ISP is well known as servers and 
website big provider in France so I guess they realize it's an exit node 
before calling me. The "facts" were also, most of the time, fraud and 
attempts of fraud but also slander one time.


I was most of the time called as suspect because IP are related to my 
name (because I was leasing those servers), as for a home connection in 
their point of view (not aware that those IP are dedicated servers IP). 
Then I simply explain this in appropriate terms. After some times, 
depending on the agent, for new investigations I'm sometimes "heard" as 
witness. And most of the time the meeting is fine.


Each time, I explain that my servers are rented in my name, and that I 
use them for volunteer participation to a free proxies and VPN network 
called Tor. I then give some details and explanations about what is Tor, 
who created it, what are the goals of the project (about protection of 
expression in bad countries and censorship avoidance, by accessing the 
same Internet that others do, pricacy protection too), and yes, the 
misuses... and that these are discouraging misuse and it is not the 
reason why we participate in this network (far from it !). Then I give 
the IP of those servers (and one of them is the reason why they called 
me). And I explain that they are computers with a very fast bandwidth, 
located in datacenters (Rennes, Vitry...) that can be accessed and 
configured remotely, like a remote desktop.


When they ask the question about logs and how to find the author of the 
fact, my answer is that (unfortunately in that case), Tor is designed as 
it's not possible for anybody to find who is the IP address from where 
the traffic originated. It's very secure for those who need to use it. 
Of course I tell them that if they have suspects in the entourage of the 
victim, they can check if one of them was connected to the Tor network 
at the time of the "fact" but as me and others people are using Tor for 
online privacy without any intention of misuse against anybody, using 
Tor is not a proof of misuse and is most of the time not done for bad 
intention. Of course some questioning about a suspect using Tor at the 
same hour would be rightful in this particular situation, anyway (like I 
was questioned).


All time I also come with a sheet of paper explaining Tor a little bit 
deeply, what are the motivation of the teams and people behind this 
project, (even in front of misuses that we are, of course, not proud of 
having on the Tor network, even if without the Tor network, those 
misuses would have been done by another way). In France I


Of course sometimes the agent is not very happy about the Tor Network as 
the investigations is likely to fail because of the Tor Network 
efficiency. When the misuse is real and obviously bad, nobody can be 
happy of it !


In all those cases, my words are honest and true; as we shouldn't be 
ashamed of participating to projects aiming to a better word and more 
freedom, but shouldn't be happy of misuses, my personal preference is to 
be understanding and true. I also tell them that I'm participating, with 
my computers, to others scientific projects like World Community Grid 
(explaining it's about cancer research and a lot of others subjects) : 
It can be seen as "not related" but it is, as that's the way we are 
volunteers to the Tor Network !



Here's for my feedback ! It's very personal of course, I hope nobody 
would copy it without feeling it :) I'm just expressing my own feeling 
on those situations, if it can help everybody to better understand those 
cases.


Best regards !

Julien ROBIN


On 31/10/2016 14:25, Juuso Lapinlampi wrote:

Putting the word out: I was interrogated by the Finnish police today for
multiple alleged counts (15+) of identity crimes, fraud and attempts of
fraud. The invitation letter to be interrogated was sent out on
2016-10-21 and received by me on 2016-10-25. Today is 2016-10-31.

The police suspects me because of an "IP-address assigned to my name",
which I can't confirm or deny to have a relation to me. As a suspect, I
was not told what this aclaimed IP-address was on a specific date to my
knowledge. It is only speculation if these allegations wrongly against
me have something to do with my relation with the Tor community or
activism about digital rights online.

Pending ongoing investigation, I am not allowed by law to share mor

Re: [tor-relays] Really bad ISP

2016-10-26 Thread Julien ROBIN

Hi,

You can check if there is no physical problem on your line, just in case 
! Connect to your modem integrated web ui and check ATM statistics of 
your DSL line.
Of course the first step is to watch the "DSL" signal light when you are 
disconnected. If it's a loss of DSL signal then it's a physical/local 
problem ! After some checks you can ask your ISP for maintenance on your 
line. Or try another ISP if this one is unable to find and repair your 
line (hoping that the next one will be able to do it fine).


But if the DSL connection is running fine when you cannot access 
anything anymore, then it's your provider's network that is down (then 
you must probably find another one !).


Some useful information :
SNR margin should be, for an optimized bandwidth/stability, 6dB (it 
means that the useful signal is 4 times stronger (in milliwatts) than 
the noise on your line); it can be moving to 4 to 8 between hours but 
it's generally supposed to be smooth along hours. Some providers 
settings are different (10dB target margin, with a small loss of 
bandwidth).


When connected, check your upload/download ATM Speed and the SNR Margin 
for both upload and download. In electronics 3dB is a good minimal 
standard, but for telecommunication lines, the standard value is 
multiplied by two because of environments induced noise that is moving 
along the day. If the Margin is going under 3dB and is still going down, 
you're probably going to be disconnected soon, and then reconnected with 
a lower bandwidth (and may be a new IP address).


If SNR margin is moving up and down (like 11db, 2db, 7dB, 9dB, 3dB, and 
disconnected for example) and a very different bandwidth at each 
connection, then you have a problem on your physical line !


Useful tip for reparation : a line is not just a conductor, it's a very 
long conductor like an antenna, capacitor and lot of things. Then 
"injecting" signal into it needs a certain amount of milliwatts. At the 
other side of the line, "reading" the signal doesn't really need to 
consume current.
So, when there is a defective contact near your home, your download 
bandwidth is quite clean. But your upload bandwith is low and changing 
between each new connection. In that case, check all your connections 
and cable.


At the opposite, when the is a weak contact into the ISP equipments, 
your upload bandwidth is generally fine and stable, but not your 
download bandwidth / SNR Margin. Then in that case, it's very easy for 
your ISP to fix it.


Sometimes, it's one of the modem at one side that is defective.

Also, if connection problems are occurring at particular events 
(switching on some device for example) you can try to find what : 
sometimes there is devices (set top boxes or anything else) that are 
defective and doing a lot of electronic high frequency noise into cables 
and electric wires, it's a frequent case that can make your line (and 
your neighbors lines !) to stop working fine. If so, change/repair the 
device or his power supply unit ! If it's your neighbors, only an 
official technician can do the job to find who and what.


Good luck ;)

Best regards,
Julien ROBIN


Le 26/10/2016 à 10:11, Lluís a écrit :

Hello,

I am a relay operator in Spain (or at least I try to).

I am just desperate with my ISP, he is just leaving the
VDSL2 connection down several times a day, taking the relay with it.

Does anyone know a much more stable, tor-friendly, ISP for an
Spanish user ?

The following record of assigned IPs in a **single** day shows
the dimension of the drama:

95.23.157.152 - Tue Oct 25 01:00:02 CEST 2016
95.23.156.52 - Tue Oct 25 07:00:02 CEST 2016
95.23.157.180 - Tue Oct 25 11:54:06 CEST 2016
188.79.227.152 - Tue Oct 25 12:20:52 CEST 2016
95.23.155.112 - Tue Oct 25 13:12:30 CEST 2016
95.23.144.75 - Tue Oct 25 13:15:19 CEST 2016
188.77.208.15 - Tue Oct 25 13:29:02 CEST 2016
95.23.159.249 - Tue Oct 25 14:00:06 CEST 2016
95.23.146.89 - Tue Oct 25 14:12:12 CEST 2016
95.23.159.163 - Tue Oct 25 14:19:21 CEST 2016
188.79.238.188 - Tue Oct 25 14:34:55 CEST 2016
188.79.237.90 - Tue Oct 25 14:36:05 CEST 2016
188.79.229.164 - Tue Oct 25 14:57:30 CEST 2016
95.23.149.124 - Tue Oct 25 15:08:51 CEST 2016
188.79.237.0 - Tue Oct 25 15:10:12 CEST 2016
188.77.213.199 - Tue Oct 25 16:28:47 CEST 2016
95.23.153.98 - Tue Oct 25 16:32:50 CEST 2016
95.23.146.46 - Tue Oct 25 16:49:03 CEST 2016
188.79.235.239 - Tue Oct 25 17:10:03 CEST 2016
188.77.215.232 - Tue Oct 25 17:20:03 CEST 2016
95.23.146.36 - Tue Oct 25 17:30:03 CEST 2016
95.23.148.238 - Tue Oct 25 18:10:03 CEST 2016
95.23.149.136 - Tue Oct 25 18:20:03 CEST 2016
188.77.211.53 - Tue Oct 25 18:50:03 CEST 2016
188.77.211.90 - Tue Oct 25 19:30:03 CEST 2016
188.79.225.153 - Tue Oct 25 20:10:01 CEST 2016
95.23.157.171 - Tue Oct 25 21:00:02 CEST 2016
188.77.212.227 - Tue Oct 25 22:00:02 CEST 2016
95.23.157.179 - Tue Oct 25 22:30:02 CEST 2016

Thanks for your assintance,
Lluís

Re: [tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance

2016-02-21 Thread Julien ROBIN
Hi,

I think it's a problem of amount of file descriptors : depending on the user, 
you have a limited amount of file descriptor that can be used (inside the tor's 
code, file descriptors are also used as handle/identifier for all network 
connections).

I think the max amount of it (for a given user) can be checked with the command 
"ulimit -n" as this user.

When I had 2 tor clients running (the second launched manually by a user named 
"tor2"), I modified the "limits.conf" file, adding those 2 lines at the end :

#*   softcore0
#roothardcore10
#*   hardrss 1
#@studenthardnproc   20
#@facultysoftnproc   20
#@facultyhardnproc   50
#ftp hardnproc   0
#ftp -   chroot  /ftp
#@student-   maxlogins   4
tor2 softnofile  10
tor2 hardnofile  10

May be it needs a restart, or it doesn't apply to what have been started by 
"tor2" user before the modification
When tor is launched by /etc/init.d/tor start may be this haven't to be done 
manually.

That's all I know about it, hope it will help you to find and correct the 
problem !

Best regards,
Julien ROBIN

- Mail original -
De: tor-ad...@torland.me
À: tor-relays@lists.torproject.org
Envoyé: Dimanche 21 Février 2016 12:39:59
Objet: [tor-relays] [WARN]Failing because we have 4063 connections  
already. Please read doc/TUNING for guidance

Hi all,

since I upgraded the torland relay from 2.6.7 to 0.2.7.6 I get the following 
warnings:

09:20:30 [WARN] Failing because we have 4063 connections already. Please read 
doc/TUNING for guidance. [101144347 similar message(s) suppressed in last 
21600 seconds]

Google only spits out https://trac.torproject.org/projects/tor/ticket/16929 
which does not help me. I don't find the mentioned branch bug16929 in git.

Can someone please advise what has to be done to avoid the warning, or point 
me where I find can the file "doc/TUNING". 

Thanks

torland
___
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] Sustained large spike in outbound traffic - what might be going on?

2015-12-29 Thread Julien ROBIN
Hi,

In fact, this is strange because Upload means that the server is receiving 
something to send, idem for Downloads : upload and download should be the same 
if the Tor Process is used as server only (relay or exit).

For a Tor process, the only normal way to do this, is to be using the socks 
port (client side) of the Tor Process ! At least, it's the only normal way I 
know.

Good luck for your investigations
Julien ROBIN

- Mail original -
De: "Tim Wilson-Brown - teor" <teor2...@gmail.com>
À: tor-relays@lists.torproject.org
Envoyé: Mardi 29 Décembre 2015 01:48:02
Objet: Re: [tor-relays] Sustained large spike in outbound traffic - what
might be going on?







On 23 Dec 2015, at 19:32, David Tomic < da...@tomic.com.au > wrote: 


Hello everyone, 


I noticed something a little bit "odd" on one of my exit relays recently, and I 
just wanted to ask whether anybody might be able to account for what was 
actually happening, and whether it's likely to warrant any further 
investigation? 


TLDR; I noticed a fairly significant spike - in excess of 30MB/s (yes, 
megabytes) - of outbound traffic compared to inbound. 



http://s2.postimg.org/cvfzqvrsp/graph.png 


It persisted steadily for just over an hour, until I noticed what was going on 
and restarted Tor (not the whole server, only Tor), at which point my traffic 
appeared to return to normal again. 


I have this relay running a a dedicated machine, with multiple physical NICs, 
and the ONLY thing which should be touching this NIC is my Tor traffic. 


Thoughts? 

Exit relays can end up with large traffic disparities for two reasons: 
* small internet server requests can yield large internet server responses, or 
vice versa 
* Tor cells are 512 bytes, if a small request or small response is embedded in 
a cell, the overhead can be quite large 


This could happen because someone is uploading or downloading a large file. 
But 30MB/s would probably require more than one client at the same time. 


Tim 





















Tim Wilson-Brown (teor) 


teor2345 at gmail dot com 
PGP 968F094B 

teor at blah dot im 
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F 

___
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] IP-Echelon complains about claimed infringement

2015-11-21 Thread Julien ROBIN
Hi,

2 years ago I had the same problem on french exit nodes.
Once I set the reduced exit policy it was OK

Some providers simply ignore those mails but not all providers: my provider was 
suddenly (and without any comment) forwading to me hundreds of IP-Echelon mails 
and I understood that without solutions my 2 servers were going to be stopped 
by my provider soon or late.

IP-Echelon are just stupid robots, even with tens of emails sent to them, they 
may have no reaction at all. Very frustrating !

The ideal solution is to have a custom RIPE record for your(s) IP with your own 
abuse@xxx email box, and your own filter :) but you should have somthing like a 
company/firm number in order to do this.

Of course every abuse message should be answered at least once, but once tens 
of emails have been anwered to a robot without any reaction, it becomes fair to 
ignore the sender.

Good luck !
Best regards,
Julien ROBIN

- Mail original -
De: "Riccardo Mori" <pata...@autistici.org>
À: tor-relays@lists.torproject.org
Envoyé: Samedi 21 Novembre 2015 04:34:34
Objet: [tor-relays] IP-Echelon complains about claimed infringement

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi everyone,
It's almost a week that I am receiving dozens of "Notices of Claimed
Infringement" a day from IP-Echelon, all equals, saying that they "are
contacting" me "on behalf of Paramount Pictures Corporation (Paramount)"
and asking me to remove the film in question that is being shared via
bittorent (the port varies each time).
The first time I wrote them that the ip address in question is a Tor
exit node, I explained briefly what is Tor and that I can't do anything
to help them. I also wrote to MyLoc (the ISP) saying pretty much the
same.
I wrote to IP-Echelon another time but they never replied.
Usually I wouldn't care about them but this time MyLoc told me to "fix
the problem or" they "will block" my "server".
I modified the exit policy so now I am running the reduced one[1]
That (in theory) should fix the problem but I would like to avoid the
reduced policy.
Is there anyone that had the same issues with IP-Echelon and can help
me?
Usually how do you handle those annoying auto generated reports?

Thanks,
patacca


[1] https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWT+YZAAoJEE1LNuolWAxgl90P/Rq5DCCc4FrrFqqOSKjisJ57
zBVOpzrfDxAG0ArRFWdhUBi8etpvbNtq042mjevVGp3N3p+IPpyl9bKvZWM7ACID
BtBnra7WwMEW21BHqKGmzXJ6CG35AdVRUaJMaJXXSaNGNThFh+mXDGm4B8iHUoI3
3vZxiIHG17INY7lZM7RimYA1MKRQAcICldIYaCA2Nwt/n4gbUlZ3OUXmeGbJins/
NZrN98ZOhxeNg93+wk3f5ns1mQk137ZIcsdb+86uyaqDCxGn7fja2/MXBeHBUonM
cZcBUSw1SKdY3XbYh6VyHRhRxWfmHeB/e2MLlDiOZbVc5QgGsOkmwmPKFuNA1dvg
w5QoXcUSpUh01mxEK0x1IRl5BAD1zya4ZyITxLAr7OXGVx1jifCvkCKq6rDrLzsX
XP8hq8w6Hp9GuFr8QrOx08Q6kvAvQjcF59s6/h0P3ehdbLnNaquEgQA86+WDtlNU
lON0MnCf5vmZbww0TP5ymhiiZZIy6uilaqfVJry9lXdiXJvu/xeWs1p2VkxlUpaD
ySnjFArg8iT5+veZro1ui0tmqseyu2BdEPfAyu86FcrS3wpbvI983aPDZOEpDoJh
NaiE5pQCtsxj7moL1pDfHfFfS23aTGerpj9VTXYE9vd/hO8gqZTWCFA7coDZcXQV
0ZdIkA2C4EI7Rd6ui/cS
=CxVx
-END PGP SIGNATURE-
___
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] Windows Tor Server Guide

2015-05-17 Thread Julien ROBIN
Hi !

From my memories, I think the Expert Tor installer for Windows is installing, 
registering and launching Tor as service in a completely automatic way. It must 
be run as administrator, if not the Tor files cannot be written to Program 
Files and the service cannot be registered into Windows. This installer could 
be found into View all downloads on the Download Tor page.


You will have to find where is the Tor's DataDir ! But it should not be too 
complicated.
Feel free to try :) I remember it as easy.

At the begining, it will not be a Tor Relay, just a Tor proxy client listening 
on 127.0.0.1:9050 (it will change once you will edit your torrc and restart the 
Tor service)



But the idea of isolating the Tor service with a dedicated user, that cannot 
touch anything on the system, is a pretty good idea also. I'm not sure the 
Expert installer does that, but it should not be too much complicated 
(following the how to should be enough for that part).



From the task manager, you can launch the resource manager : into the 
network tab, you have a view of all listening socket into your system. (You 
can see if Tor is inside or not, for example by looking if something listens on 
9050, or another port you defined on torrc file). You can also see the Tor's 
log file ! It's usefull as it warns you in case of problems, and it tells you 
if it's working.

Good luck !


PS : Expert Installer should probably not be used for browing the Internet 
through Tor with a standard browser. TBB is a better solution for Browsing 
Internet trough Tor (thanks to a secured browser). That's why Expert Installer 
is a little bit hidden, for avoiding people browing Internet with it. But for 
a server use, Expert Installer does the job !



- Mail original -
De: Ben Serebin b...@reefsolutions.com
À: tor-relays@lists.torproject.org tor-relays@lists.torproject.org
Envoyé: Dimanche 17 Mai 2015 07:59:14
Objet: Re: [tor-relays] Windows Tor Server Guide





Hi there… 



1 st post (I figured after years of donating to EFF, I should run a tor relay). 
I’ve searched and read many posts on tor-relays and the best Windows Tor Server 
Guide I found was this below one by Rafael Rodriguez. A few questions, and 
apologies if they seem silly, but there is scant info out there for us Windows 
admins. 



- is a web server needed? 

- the below email post had the slashes stripped from the path entries which 
makes it tricky to follow (talk about an annoying mail-list process). Overall, 
throw all the files in a single dir? 

- before I load it as a service, once all files and config the “torrc” can I 
just launch the tor.exe and then test it’s working? 

- is this the only way to run a relay on Windows? Hoping there’s a special 
approach to simplify the process (now I know why there aren’t more of them). 



Thanks, 

-Ben 



Rafael Rodriguez rafaelr at icctek.com 

Wed Nov 5 00:47:46 UTC 2014 



Previous message: [tor-relays] Windows Tor Server Guide 

Next message: [tor-relays] Windows Tor Server Guide 

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 



Hi, here is it. Please, feel free to contribute to it. 



RUNNING A TOR SERVER IN WINDOWS 



- Download latest Tor Browser Bundle. 

- Install to c:tor 

- Create a temporary folder on your Desktop and name it server. 

- Copy all files from C:TorBrowserTorBrowserDataTor to the server 

folder on the Desktop. 

- Browse to C:TorBrowserTorBrowserTor; delete the folder 

PluggableTransports and it content. 

- Copy all files from C:TorBrowserTorBrowserTor to the server folder 

on the Desktop. 

- Browse to C:Tor and delete everything inside that folder. C:Tor should 

be completely empty at this point. 

- Move all files from the server folder on your Desktop to C:Tor 

- Browse to C:Tor and create a new folder named datadir. 

- Create a new text file in C:Tor named notices (I myself use 

notices.log but we want to keep it simple for users who may not know how 

to change the file extension from .txt to .log) 

- EDIT C:TORTORRC FILE: (this could be the torrc-defaults file and all 

its comments). Note that the sample below is just for references. Each 

user needs to define her/his own parameters based on their own needs and 

that's impossible for me to cover in a single file for everyone. Hence, 

each parameter should be included in the torrc-defaults with due 

comments to be used as reference. Also, noted that I'm using IPv4 geoip 

by default. Users using IPv6 should define geoip6 in their torrc file. 

Then again, I cannot use a single sample file for all deployments. The 

defaults file should be used as reference once again. 



DATADIRECTORY .DATADIR 

LOG NOTICE FILE .NOTICES.TXT 

GEOIPFILE .GEOIP 

AvoidDiskWrites 1 

SocksPort 0 

ORPort 9001 

DirPort 9030 

ExitPolicy reject *:* 

Nickname 

RelayBandwidthRate 

RelayBandwidthBurst 



Up until this point, all I've written is nothing more than using the 

default Tor Bundle to create a 

Re: [tor-relays] simple relay setup

2015-04-18 Thread Julien ROBIN
Hi !

You can try a mix between this (ultra simple), from 
https://www.torproject.org/docs/debian.html.en :



You need to add the following entry in /etc/apt/sources.list or a new file in 
/etc/apt/sources.list.d/:

deb http://deb.torproject.org/torproject.org wheezy main
deb-src http://deb.torproject.org/torproject.org wheezy main


gpg --keyserver keys.gnupg.net --recv 886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -

apt-get update
apt-get install tor deb.torproject.org-keyring



This will make your apt-get using the last table version of Tor from the Tor 
Project servers, with signatures check making sure that no one car jacked the 
server before you download from it ;)



You will have to find a way to make your apt-get update and apt-get -y 
upgrade automatic, may be reboot too (when kernel have been updated for 
example, but here I cannot say precisely  how to know if you have to reboot !)




And a second link, that can give you a lot of tips also

http://www.torservers.net/wiki/setup/server

Including disabling password authentification, but if you want to completely 
lock your server, a good way could be to make /etc/init.d/ssh unable to run 
(you delete the x permission for example)

After the reboot, you will not be able to connect anymore using SSH on your 
server, and you will have to use tools from your ISP if you want to drive your 
server again !

Personnaly, I always do a minimalist installation in order to have nothing else 
than OpenSSH listening (and Tor, of course !). Because if others things that I 
don't know (rpc bind port 111 etc) are listening I'm not sure that I have 
everything into control. 




- Mail original -
De: tor-server-crea...@use.startmail.com
À: tor-relays@lists.torproject.org
Envoyé: Samedi 18 Avril 2015 12:06:07
Objet: [tor-relays] simple relay setup


I need some help. 
My dedicated server is running debian and is new, set up by my serverhoster. 

I want to run a TOR-Relay: 
- It should always update to latest stable automatically. 
- It should be save. 


I will edit the torrc by myself. What i need is simple copy+paste codeline for: 
- isntall and run functional auto-update for tor (is it libevent?) just simply 
@root user without user/pgp dealing stuff. pgp stuff is confusing me! 
- deactivate complete access (ssh disable?) to ensure savety (i have to 
reinstall the system by serverhoster-website if change needet) i want to lock 
out even myself. 

Is this a practical idea to most easy set-up and let run without struggle? 
Please help, thanks. 
___
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] strange consensus messages in log

2015-04-06 Thread Julien ROBIN
PS :

I think a defective network equipment could also be the cause of such data 
corruptions on incoming data ? May be it should be added on the check list !

But if it's the case, it should be the case for every kind of connexion (try to 
download an unzip some big file, just to be sure ;)


- Mail original -
De: Julien ROBIN julien.robi...@free.fr
À: tor-relays@lists.torproject.org
Envoyé: Lundi 6 Avril 2015 13:54:38
Objet: Re: [tor-relays] strange consensus messages in log

Hi, 

Very strange !
Data have been corrupted (even the hour), but it seems to be repeated and 
constant.


From my experiences, every newer library contains the older library 
functionalities (even if improved), it's supposed to be the goal of a library. 
Can somebody confirm that about OpenSSL ?


Data could have been corrupted :
  - Before reception (strange, it seems to come from several source) - 
unlikely I would said, but it's not a truth, just my opinion.
  - After reception (strange also : what is the cause ?)


Another remark :
   Unable to load microdesc consensus directory downloaded from server 
'194.109.206.212:80'. I'll try again soon.

This maybe doesn't need OpenSSL ?


Generally, defective memory modules are driving to random errors executing 
programs (those are located (or working with data located) at the faulty 
emplacement), and with Windows Kernels, it drives to OS crashes and reboots 
everywhere (may be it could be the same on Linux ?). But you can check with 
memtest (http://www.memtest.org/) started in place of your OS.

If it's ECC memory module, a slightly defective ECC memory module cannot be 
the cause of a successful data corruption (the data is saved from corruption 
in extremis, and you should be warned - but I don't know how).


Keep us informed ! And good luck.

Best regards,
Julien ROBIN


- Original mail -
From: starlight 2015q2 starlight.201...@binnacle.cx
To: tor-relays@lists.torproject.org
Sent: Lundi 6 Avril 2015 06:55:17
Object: Re: [tor-relays] strange consensus messages in log

Yesterday built openssl-1.0.1m and dropped
it over the top of 1.0.1j.  Tor said

OpenSSL version from headers does not match the version we're running with. If 
you get weird crashes, that might be why. (Compiled with 100010af: OpenSSL 
1.0.1j 15 Oct 2014; running with 100010df: OpenSSL 1.0.1m 19 Mar 2015).

Can't see why this would cause the
strange consensus error (identical ABI,
right?), but just in case rebuilt
tor relay 0.2.4.26 against the rebuilt
openssl and restarted.



At 22:32 4/5/2015 -0400, you wrote:
Does anyone have any idea what this is about?

Is it serious?


___
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] Unreachable ORPort - Potential ISP block?

2015-04-05 Thread Julien ROBIN
Hi,


One thing you have to be sure :

  - Is you external IP address directly assigned to your Router ? The IP 
address given by www.whatismyip.com shoud be readable somewhere on your router. 
If not (like for mobile data Internet access : a kind of local IP address is 
given to your router device, and it doesn't matches with your external IP 
address), your router's IP address simply cannot be contacted from the outside 
:( so it has nothing it could receive and forward, even if well configured. I 
hope it's not the case for you ! It's the case with my mobile data provider, 
but I never saw this with a wired line provider.


If nothing wrong and your router is connected using your external IP address, a 
good way to be sure is to try other services (like apache2, on port 80 or 
another). Things that should work !

As said Robert, if nothing works, check firewall rules into your router. 
Inside your raspbian too, but I don't remember having anything inside Raspbian 
telling me no when a process or service successfully opened a listening 
socket (apart from a non root process trying to listen on a  1024 port)

Also, do not hesitate to try with other computers, with a Filezilla Server on 
Windows for example, in order to be sure that nothing escaped from your 
vigilance (a kind of double check so different that you cannot repeat 2 times 
the same error, if there is one)


If everything but Tor is reachable, and netstat -n -l -p is showing your Tor 
process listening on globally (0.0.0.0), may be your ISP is involved in this 
problem ! But it would be a bit strange, and so disappointing.


Good luck ! 

- Original mail -
From: CJ Barlow iamthech...@gmail.com
To: tor-relays@lists.torproject.org
Sent: Dimanche 5 Avril 2015 21:31:49
Object: [tor-relays] Unreachable ORPort - Potential ISP block?



I'm attempting to run a Relay but I haven't been able to get it the ORPort to 
be confirm as reachable. I've tried lots of things but I'm hoping there is 
something I haven't thought of yet that can make this work! I've got a 50Mbps 
symmetrical connection (without data caps) that I would love to have the Tor 
network utilize. 


Hardware info: 
- Asus RT-N66U running DD-WRT 
- Raspberry Pi 2 running Raspbian 
- SanDisk MicroSDHC UHS-I 16GB 


Here are all the steps I've taken: 

- Formatted the MicroSDHC with Win32DiskImager. 
- Followed the Instructables Raspberry Pi Tor Relay configuration guide. 
- Port forwarded via NAT/QoS then Port Forwarding. Protocol is set to TCP, 
double-checked IP is what is assigned to Raspberry Pi 2 and enable box is 
checked. 
- ORPort set to 9001. Also changed ORPort to 443, did sudo service tor reload 
and changed the port in the forwarding section of my router. 
- Tried router DMZ for Raspberry Pi LAN IP. 


I would really like to get this to work, if possible. I can't run an Exit node 
on my connection but since my connection sits unused for most of the day it 
should be put to good relay use. 
___
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] could smoothing/smearing a consensus weights change makes sense

2015-01-24 Thread Julien ROBIN
I also think that, once a server is running for weeks (or month(s) ?) it could 
be usefull if the bandwidth authorithy system is able to lock a good speed 
based on the server history. Instead of rising, falling, rising, falling, 
rising, falling in unstable loop, because if it's day or night, too highly 
loaded and, few hours after, underloaded, every every and every day.




It would unlock this value and re-evaluate it only if current test shows that 
this is really needed (suddenly excessive congestion, or too many consecutive 
tests that confirms that the server is more overloaded, or more underloaded 
that before). For example. But may be the Tor Project team already have a lot 
of work on other subjects ;)



- Original mail -
From: Toralf Förster toralf.foers...@gmx.de
To: tor-relays@lists.torproject.org
Sent: Vendredi 23 Janvier 2015 14:00:13
Object: [tor-relays] could smoothing/smearing a consensus weights change
makes sense

I am wondering if an adversary would be able to derive useful information due 
to the fact that the consensus weights are changed abrupt ?
(screen shot attached)
-- 
Toralf
pgp key: 7B1A 07F4 EC82 0F90 D4C2  8936 872A E508 0076 E94E


___
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] Simulate High Tor Load

2015-01-11 Thread Julien ROBIN
Hi,

If you are on a dedicated high Bandwidth server you can maybe use your relay as 
client, an idea could be to open a lot of wget commands.

sudo apt-get install torsocks
usewithtor wget URL

But it's not guaranteed that the selected circuits will be super-fast (first 
reason to open lot of wgets simultaneously)

Of course, doing that you consume some useful bandwidth for users (but if it's 
quick, after all you're a Tor user like another!)

And it's not totally the same that relaying data as server, since it's using 
the client part of the tor process (but starting from here, I cannot help you 
anymore since I don't know what is written in the code ;)

So if anybody have another better idea
Something that would generate a full customized circuit for example, or reduce 
the amount of used hop for the test. 

It already exists EntryNodes and ExitNodes commands for your torrc file, 
but no server can be used as EntryNode if it's not Guard already, and I'm not 
sure that some MiddleNodes command exists.


Last things, you can also make you machine's CPU working hard on a lot of 
threads simultaneously, and watch if Tor is suffering or not (like too many 
circuit creation request! in the log).

Or make some tests with Iperf for high bandwidth load in parallel (iperf -s 
on a fast machine, ipers -c Ip -t TimeInSeconds -p port -P 
ParallelsTcpConnexions on the other machine - this one will send data (chains 
of 1234567890123...) to the server)

Good luck ! By curiosity, I'm interested also, but I would understand if this 
kind of easiness in creating bandwidth statistics and degraded path (for 
analysis, for example) is not really sought by developers.

Best regards,
Julien ROBIN



- Mail original -
De: webmaster webmas...@defcon-cc.dyndns.org
À: tor-relays@lists.torproject.org
Envoyé: Dimanche 11 Janvier 2015 11:59:12
Objet: [tor-relays] Simulate High Tor Load

Hey Folks,

is there a common procedure for testing a tor server for a high load?

Thanks in advance


-- 
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v2.0.17 (MingW32)

mQENBFHMmT8BCAC0smvU7Bq1ABxAhvBRn7d4ekkk95aCE4TTQo4wy1z/rGLhQfdt
dhiD+Vy61vGrsdK3ei5sW6rBvX2m8+YmBi+8AAgSiZmS0JM3Zz3cmTi5oh0D/yM8
4aDj7wQYfJyzSmYN8InAQ5eA77lwIdqG27kR9wga2szeJwCnWReta0R+7YFkpUW+
zUlf4SWcUx5SmBsaiELQpm+Qcn+fyopo12RX6YVmoNPBvN2nDXDnRhUCKGc+0xhD
UrBpCHrApK6sTnMsD34ClCLTL2L1gckQ0AsQqY3PJlx3R8kIJxlmr6R3WnjPMIG0
lqrukB9PcOrHM1MZXK1gK6AtypHBN98lr8Z9ABEBAAG0KndlYm1hc3RlciA8d2Vi
bWFzdGVyQGRlZmNvbi1jYy5keW5kbnMub3JnPokBPgQTAQIAKAUCUcyZPwIbIwUJ
CWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQcN1vxvRQl+0SEwf+KXjf
YtiSUSVS11uqeQ/8g46NwmNa91P3toZvEd7vhLSbjnL9bi/vApzNnUTGT3VP4/NA
dg9SbR4qKlSr8T+YikRMV3tiuiVq8m7g00qM9y8MIomwJTounz8VdO/aJXFSOxAK
Bb6ElREADspCzr2qSZCnozWUzbd+b8owbGeRRq3e33Aa5Nlm/xDRxGDWANbaIA8q
Gkibvy3vWEwrxiwsakvHGaEZnPEtlNm3M1xcmFAuyl73qzUMkLN0u9E/2igo4EB5
EdMb5Ab5hfWdljxBqJr0tsvMfSK4VkzMCbKYkTqHZIRPQnhiSBE6Yo1Q6RCl/Hht
bkvU4RA0J+NkXMZljrkBDQRRzJk/AQgA0HojJnK0uhEkAnbmszYsf477DV+LD02s
ZEAlLGhJlf9qYaDiPMPwaZ3nK8/PYKzPpBWfHgRQP97rLHPIVJYl3BHDa/nWeZ2b
e/HzYhpX0djbK9qe6W/CTfGbXmC/y+4dDGB8dvtTAW3JILm7xEdwiWtywozEVy7V
lnMK4JQvlfOh+3XO6qv71FXyuRkObvkYzqvxUYHewtvvObcVxXHP0C0O6LB44iAW
2boZVVuiHdudnyNAezJajPMUT8SnI0bwL6+0TgnHL4cKNUEPQljIrrvi+9nCkq7V
uBtnsYtyoo2reoxmCbX/Z1zZsxdUcKpeJHlc5AypyN8DUJ+APJ9NnwARAQABiQEl
BBgBAgAPBQJRzJk/AhsMBQkJZgGAAAoJEHDdb8b0UJftOY0H/1TChmQrJC/qzefW
PK7EqFlBg3TIEXdu8JHjF42ZOgzQRfp7E2wWzEx0Y45lNXMs6Yg15hWCEDaUDF6F
5WZKNrP8xIldyR9Aw7fyKqjZ9UuKovqofHsCiaSO7nWzGM6GF3nBDNI9NcFve/wN
wggyjAbohOJrJGal3N0HlG3cakqjEmjBe1gQEMC0ZPlWstb/cqqr49TNPrRmQc4P
SyGffh8Xqhw94m1LDBXFEaYe7AxjNk1sPAVfO1rOdLF6GOun/UwgbhDQX/Rb9C3t
AhjSgyFEiR/gfrUZ7R6SY51qOUf1lN5ZN85C/x27XoZWYlsNaH3Ei6nG+yeswBMk
ZRMbezQ=
=Med3
-END PGP PUBLIC KEY BLOCK-

___
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] Possible DDoS

2014-12-26 Thread Julien ROBIN
Hi,

My advice is to try to ask them is they are OK to let you a second chance to 
let your relay running. Tell them that if such a big attack happen again so you 
shut it down and you don't disturb them anymore with it.

Also, a Good Point to get if it's not already done, set your reverse DNS to 
something that hackers will instantly recognize (torproxy.something.readme 
...), it reduces the risk of DDoS problems (those who drives DDoS attacks often 
know what is Tor, may be some of them are using it everyday). Tell you ISP if 
you do so, in order to say them that you improved somethong to reduce the risk 
for it to happen again.

On one of my relays, enabling that after month without, made a very very big 
difference (several DDoS per month - nothing now).

If your relay have been running for several month now without any problem, and 
if most of the DDoS attacks should be smaller that the one you got, may be they 
can be OK for a second chance!

Good luck ;)




- Mail original -
De: Christian Burkert p...@cburkert.de
À: tor-relays@lists.torproject.org
Envoyé: Vendredi 26 Décembre 2014 12:32:19
Objet: [tor-relays] Possible DDoS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi *,

I'm running a non-exit Tor node for a few months now on a virtual server
hosted in a professional datacenter.

That's the node:
https://globe.torproject.org/#/relay/4C246EA9C950B872FD77F761CEAAB41D93D9764D

Yesterday, December 25th, the support wrote me, that my server is
under a DDoS attack with 2GBit/s lasting over more than two hours. So,
the hoster black holed my traffic to protect the other customers.

The hoster wanted to know which services I'm running and told me that
if I continue running Tor and further attacks will happen, then I
would have to bear the costs.
Eventually, I took down the Tor node to avoid further confrontation.

Now I seek for your interpretation of this event:
- - Has there been more recent incidents against Tor nodes?
- - How can I investigate it?
- - How should one react to a hoster? I mean they could have made up the
whole thing...

Looking forward to your comments
Chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCgAGBQJUnUdDAAoJEHAzZ6ooPDSy0nMP/1lyHPPFBxpAOvEiWL+ijrvA
SPViJvZH/cPUS/11M7qm+bsZa/fbiRk6kY8ADcY8abe1Z8lHzMYPGwZvKaIijiZG
M8hjCHtMWLipO6iLmVfFskDtRn37Ga2ibEhGkVesDV53kPcotgg4i7tIqIuNb11X
Gnkk+WpYwkrS9nPZjYNLmce093s4lux/N5GyRY/gQii+h9mfDJ++W+1ueNU94UQ0
bvK1wF7MdicWlu0kR49hCgFtDFh7uUjP87MPZmmQYHI82qWhTJxqOuuImrnJew2k
pCFSzn03x/hXg1QFNPNLsqHU9OhUob3/z17Azcpbir15mY4/YE7Gq14/LBM+FKh0
LqGjzaVbQo0hs0kE2yFk5sEP0Dsv5aiOUItqFIMTG52FYZ6cUh/eTxMd6vblHwfU
ujil0rFCRqtmbF6wIDBuXDxc0fmdaRMWTDfSlPxYGkfUaq1tSea1OAvjFpheOcNM
wu9QiTSq9BTLY010iHSYQDknSr+gFkc/ooNLsPV1AAZFyMlG0epLww6tqR7C9hZq
RyEX9piqGal7mU56gETxhDrD0Z/aKgXMbS+KvYfZhopGWEVg5vbWPGxAId53nhr6
hjvLyFmy68hBdbOB/pvp8qvw8veQR3niiHIxhxAl+BIQzXX45x0uVCPHFUpbbLp5
POIwpEJ46oaz7+cddAHf
=TcPt
-END PGP SIGNATURE-
___
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] OrPort self-testing sometimes fails

2014-11-21 Thread Julien ROBIN
Hi everybody,

Second time it happen to me so I would like to know if you have ideas about it.
Sometimes after a reboot, I haven't the following message into the log :

Self-testing indicates your ORPort is reachable from the outside. Excellent. 
Publishing server descriptor.

And after a while (fortunately), I receive a warning (Tor Weather) because my 
server is shown as offline.

So I just type /etc/init.d/tor stop and /etc/init.d/tor start, and it works 
fine.

I would like to know how does the test works, in order to check what can fail 
during the test.
If my server's IP (95.130.9.190) is not reachable by a part of the Internet for 
example, in order to open a support ticket with my ISP (do you know how I can 
easily check it ?).

Also, since few month now, the bandwith usage seems to keeps far below what I 
had before (even with a good consensus weight, fresh OS install with new keys 
and name a month ago) so I now realize that may be there is a problem somewhere 
with this machine.

Thank you in advance for your help and ideas !

Best Regards,
Julien ROBIN



Please find below the logs of the failed start, followed by the working 
start


Nov 21 11:56:53.000 [notice] Tor 0.2.5.10 (git-43a5f3d91e726291) opening log 
file.
Nov 21 11:56:53.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Nov 21 11:56:53.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Nov 21 11:56:53.000 [notice] Configured to measure statistics. Look for the 
*-stats files that will first be written to the data directory in 24 hours from 
now.
Nov 21 11:56:53.000 [notice] Caching new entry debian-tor for debian-tor
Nov 21 11:56:53.000 [notice] Caching new entry debian-tor for debian-tor
Nov 21 11:56:53.000 [notice] Your Tor server's identity key fingerprint is 
'MagnetronFR1 145AEE9359A8943189500C5451722CAA7EEEC6C3'
Nov 21 11:56:53.000 [notice] Bootstrapped 0%: Starting
Nov 21 11:56:57.000 [notice] We now have enough directory information to build 
circuits.
Nov 21 11:56:57.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Nov 21 11:56:57.000 [notice] Bootstrapped 85%: Finishing handshake with first 
hop
Nov 21 11:56:58.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Nov 21 11:57:00.000 [notice] Tor has successfully opened a circuit. Looks like 
client functionality is working.
Nov 21 11:57:00.000 [notice] Bootstrapped 100%: Done
Nov 21 13:56:58.000 [notice] Interrupt: we have stopped accepting new 
connections, and will shut down in 30 seconds. Interrupt again to exit now.
Nov 21 13:57:28.000 [notice] Clean shutdown finished. Exiting.


Nov 21 13:57:39.000 [notice] Tor 0.2.5.10 (git-43a5f3d91e726291) opening log 
file.
Nov 21 13:57:39.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Nov 21 13:57:39.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Nov 21 13:57:39.000 [notice] Configured to measure statistics. Look for the 
*-stats files that will first be written to the data directory in 24 hours from 
now.
Nov 21 13:57:39.000 [notice] Caching new entry debian-tor for debian-tor
Nov 21 13:57:39.000 [notice] Caching new entry debian-tor for debian-tor
Nov 21 13:57:39.000 [notice] Your Tor server's identity key fingerprint is 
'MagnetronFR1 145AEE9359A8943189500C5451722CAA7EEEC6C3'
Nov 21 13:57:39.000 [notice] Bootstrapped 0%: Starting
Nov 21 13:57:39.000 [notice] Bootstrapped 5%: Connecting to directory server
Nov 21 13:57:41.000 [notice] We now have enough directory information to build 
circuits.
Nov 21 13:57:41.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Nov 21 13:57:41.000 [notice] Bootstrapped 85%: Finishing handshake with first 
hop
Nov 21 13:57:41.000 [notice] Self-testing indicates your ORPort is reachable 
from the outside. Excellent. Publishing server descriptor.
Nov 21 13:57:43.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Nov 21 13:57:44.000 [notice] Tor has successfully opened a circuit. Looks like 
client functionality is working.
Nov 21 13:57:44.000 [notice] Bootstrapped 100%: Done
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Bwauths Measures question, friends.

2014-11-05 Thread Julien ROBIN
Wow, it's not very good
With an advertised bandwidth raising 1,03MB your consensus weight is now 
updated to 13 (it's far too low).

It means that somethings goes bad when bwauth is testing your relay, so even 
with a very good advertised bandwidth, your final score keeps ultra-low, and 
with such a consensus wieght, your relay keeps unused by clients.


I have no idea from where can be the problem (and the solution), technically it 
could be the ISP that blocks bw auth, but in real facts it would be pretty 
strange.

Try to transport your relay (/var/lib/tor/keys and /etc/tor/torrc) to another 
computer on the same connection (the more different, the better), if it still 
doesn't works, it means something at your connection make a problem.

Double check your upload rate is good (since everything have to be transmitted, 
the lowest bandwidth (generally upload) applies to the relay).

If your relay appears to be online it means that it means that port 
redirections is well configured, so I'm not sure that something else could be 
misconfigured into it (if you have several ones, test a different one)


Let us know when you find the solution ! This problem is surprising but it 
cannot be nowhere ;)





- Mail original -
De: Rafael Rodriguez rafa...@icctek.com
À: tor-relays@lists.torproject.org
Envoyé: Mercredi 5 Novembre 2014 00:13:37
Objet: Re: [tor-relays] Bwauths Measures question, friends.




Indeed, Julien. 

As a matter of fact I saw the server (using the Tor network) pushing up to 
8.8MB/s at some point while I was using it as a proxy in my setup. That was 
yesterday. As soon as I closed the SocksListenAddress I was connecting to, it 
went back to almost not existent cos' it is weighted 10. Even the Fast flag 
isn't there. As I said, I'm waiting to see if it picks up relevance in the next 
day or so. 

On 2014-11-04 14:26, Julien ROBIN wrote: 

Hi Rafael,

On Tor Atlas after a little time offset, your download seems now to appear into 
your server stats. 
https://atlas.torproject.org/#details/48ADFCC561402D7EBB1CDE233F206B01D8FA0765 
Your Advertised Bandwidth seems now to be better : 866.83 KB/s
But the consensus weight is still at 10 (it's like zero) for now (let's wait 
less that one day)

In the following hours, we will see if the consensus weight value can be 
better thanks to that (so then true clients will start using the bandwidth and 
nourish your advertised bandwith).

If I remember well what I read before, the consensus weight, when recalculated, 
is the result of your Advertised Bandwidth multiplied by a coefficient obtained 
by bw authorites (when periodically testing your server). If it's 
congestionned, the test gives low result and your consensus weight is reduced. 
If it's really good, your consensus weight is increased (and your server usage 
too).

If your consensus weight is stuck at 10 and doesn't increase, it would mean 
that bw authorities cannot test your server and always gives zero as 
coefficient (if so, you will have to check everything on your network : router, 
softwares, etc)

The answer is near :)

- Mail original -
De: Rafael Rodriguez  rafa...@icctek.com 
À: tor-relays@lists.torproject.org Envoyé: Lundi 3 Novembre 2014 22:04:24
Objet: Re: [tor-relays] Bwauths Measures question, friends.




Hi Julien, 

Thanks for the tip. I did ssh'd tunnel into my Tor server and I can pull 
downloads at 1-2MB/s as expected. I do not see my server getting any better in 
measurements though. After 4 days running my Advertised Bandwidth is barely 
62kb/s and its Consensus Weight is 10. I wouldn't mind as long as it serves our 
Tor community but I'm under the impression that something is just not quite 
right. This box was put in place specifically to put all its bandwidth to good 
use and help the network. I have the feeling that a Relay measured at such low 
speeds does more harm than good to the network. I will keep it up there running 
as it is since I cannot pinpoint a problem at this time and maybe it just needs 
to stay online for a longer period of time. 


--- 



On 2014-11-02 07:29, Julien ROBIN wrote: 

It strange you still haven't any used bandwidth 
https://atlas.torproject.org/#details/48ADFCC561402D7EBB1CDE233F206B01D8FA0765 
I cannot explain you why but I have an idea for you in order to kickstart 
your bandwidth usage.

A tor process used to relay traffic also have the possibility to be used as 
client. If it's at home, it's easy (socks v5 at 127.0.0.1:9050 if you haven't 
changed anything), if your relay isn't at home, use SSH tunnelling to do so 
(SSH session brings you to localhost on your remote computer, on the port you 
choose)

Try to download something through your relay, if nothing changed, even the 
client bandwidth will be able to raise your advertised and used bandwidth as 
server, in order for your server to start having weight on the network.

Once started, everything should be automatic but normally, the start is also 
automatic after 2

Re: [tor-relays] Bwauths Measures question, friends.

2014-11-04 Thread Julien ROBIN
Hi Rafael,

On Tor Atlas after a little time offset, your download seems now to appear into 
your server stats.

https://atlas.torproject.org/#details/48ADFCC561402D7EBB1CDE233F206B01D8FA0765

Your Advertised Bandwidth seems now to be better : 866.83 KB/s
But the consensus weight is still at 10 (it's like zero) for now (let's wait 
less that one day)

In the following hours, we will see if the consensus weight value can be 
better thanks to that (so then true clients will start using the bandwidth and 
nourish your advertised bandwith).

If I remember well what I read before, the consensus weight, when recalculated, 
is the result of your Advertised Bandwidth multiplied by a coefficient obtained 
by bw authorites (when periodically testing your server). If it's 
congestionned, the test gives low result and your consensus weight is reduced. 
If it's really good, your consensus weight is increased (and your server usage 
too).

If your consensus weight is stuck at 10 and doesn't increase, it would mean 
that bw authorities cannot test your server and always gives zero as 
coefficient (if so, you will have to check everything on your network : router, 
softwares, etc)

The answer is near :)

- Mail original -
De: Rafael Rodriguez rafa...@icctek.com
À: tor-relays@lists.torproject.org
Envoyé: Lundi 3 Novembre 2014 22:04:24
Objet: Re: [tor-relays] Bwauths Measures question, friends.




Hi Julien, 

Thanks for the tip. I did ssh'd tunnel into my Tor server and I can pull 
downloads at 1-2MB/s as expected. I do not see my server getting any better in 
measurements though. After 4 days running my Advertised Bandwidth is barely 
62kb/s and its Consensus Weight is 10. I wouldn't mind as long as it serves our 
Tor community but I'm under the impression that something is just not quite 
right. This box was put in place specifically to put all its bandwidth to good 
use and help the network. I have the feeling that a Relay measured at such low 
speeds does more harm than good to the network. I will keep it up there running 
as it is since I cannot pinpoint a problem at this time and maybe it just needs 
to stay online for a longer period of time. 


--- 



On 2014-11-02 07:29, Julien ROBIN wrote: 

It strange you still haven't any used bandwidth 
https://atlas.torproject.org/#details/48ADFCC561402D7EBB1CDE233F206B01D8FA0765 
I cannot explain you why but I have an idea for you in order to kickstart 
your bandwidth usage.

A tor process used to relay traffic also have the possibility to be used as 
client. If it's at home, it's easy (socks v5 at 127.0.0.1:9050 if you haven't 
changed anything), if your relay isn't at home, use SSH tunnelling to do so 
(SSH session brings you to localhost on your remote computer, on the port you 
choose)

Try to download something through your relay, if nothing changed, even the 
client bandwidth will be able to raise your advertised and used bandwidth as 
server, in order for your server to start having weight on the network.

Once started, everything should be automatic but normally, the start is also 
automatic after 2 or 3 days, so it is strange. 

May be it's because of the oversupply of middle nodes on the network (there 
is so much middle nodes that most of them - the slowers - probably keep totally 
unused). Without the guard flag (and it needs enough bandwidth) your relay 
cannot be used as entry guard right now.

Good luck !


- Mail original -
De: Rafael Rodriguez  rafa...@icctek.com 
À: tor-relays@lists.torproject.org Envoyé: Samedi 1 Novembre 2014 16:16:24
Objet: Re: [tor-relays] Bwauths Measures question, friends.




Maybe I should just wait longer but the 3 days unmetered has obviously been 
passed already. That's why I'm asking about bwauths measurements. 

I was under the impression that after 3 days bwauths adjust your consensus 
weight and raises your bandwidth estimate. In this case, the server is simply 
capped at 20kb/s still while my advertise bandwidth is little over 50kb/s. 
Since I have a 2MB/s relay, I'm expecting to see at least over 100kb/s or 
250kb/s measurements to make my relay a usable one. Yet the advertised speed 
hasn't changed. Is that normal and should I just give it more time? That's what 
I'm trying to understand. 



On 2014-11-01 07:00, Krbusek Christian wrote: 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

You may want to read the following, which should make this more clear. 
https://blog.torproject.org/blog/lifecycle-of-a-new-relay Cheers

Am 01.11.2014 um 10:46 schrieb Rafael Rodriguez: 

Anyone knows how often bwauths measures a relay? I don't understand why 
directory authorities have not lifted the 20KB cap for my older relay. Now I 
have doubts if it could be a problem with my server. This is a 2MB/s relay with 
burst of 4MB/s to start tuning it and increase it later if stable, which is not 
being used and has been running for over 3 days. Is it normal for Relays to 
take longer than three days to start getting

Re: [tor-relays] Bwauths Measures question, friends.

2014-11-02 Thread Julien ROBIN
It strange you still haven't any used bandwidth

https://atlas.torproject.org/#details/48ADFCC561402D7EBB1CDE233F206B01D8FA0765

I cannot explain you why but I have an idea for you in order to kickstart 
your bandwidth usage.

A tor process used to relay traffic also have the possibility to be used as 
client. If it's at home, it's easy (socks v5 at 127.0.0.1:9050 if you haven't 
changed anything), if your relay isn't at home, use SSH tunnelling to do so 
(SSH session brings you to localhost on your remote computer, on the port you 
choose)

Try to download something through your relay, if nothing changed, even the 
client bandwidth will be able to raise your advertised and used bandwidth as 
server, in order for your server to start having weight on the network.

Once started, everything should be automatic but normally, the start is also 
automatic after 2 or 3 days, so it is strange. 

May be it's because of the oversupply of middle nodes on the network (there 
is so much middle nodes that most of them - the slowers - probably keep totally 
unused). Without the guard flag (and it needs enough bandwidth) your relay 
cannot be used as entry guard right now.

Good luck !


- Mail original -
De: Rafael Rodriguez rafa...@icctek.com
À: tor-relays@lists.torproject.org
Envoyé: Samedi 1 Novembre 2014 16:16:24
Objet: Re: [tor-relays] Bwauths Measures question, friends.




Maybe I should just wait longer but the 3 days unmetered has obviously been 
passed already. That's why I'm asking about bwauths measurements. 

I was under the impression that after 3 days bwauths adjust your consensus 
weight and raises your bandwidth estimate. In this case, the server is simply 
capped at 20kb/s still while my advertise bandwidth is little over 50kb/s. 
Since I have a 2MB/s relay, I'm expecting to see at least over 100kb/s or 
250kb/s measurements to make my relay a usable one. Yet the advertised speed 
hasn't changed. Is that normal and should I just give it more time? That's what 
I'm trying to understand. 



On 2014-11-01 07:00, Krbusek Christian wrote: 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

You may want to read the following, which should make this more clear. 
https://blog.torproject.org/blog/lifecycle-of-a-new-relay Cheers

Am 01.11.2014 um 10:46 schrieb Rafael Rodriguez: 

Anyone knows how often bwauths measures a relay? I don't understand why 
directory authorities have not lifted the 20KB cap for my older relay. Now I 
have doubts if it could be a problem with my server. This is a 2MB/s relay with 
burst of 4MB/s to start tuning it and increase it later if stable, which is not 
being used and has been running for over 3 days. Is it normal for Relays to 
take longer than three days to start getting at least some traffic and for 
directory authorities to lift the 20KB cap? Fingerprint 
48ADFCC561402D7EBB1CDE233F206B01D8FA0765 -BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUVL1GAAoJECgP5Pn8Zk3/cfoQAI9bMRyx8hl3B+V+vSLC7xoJ
sfQedgt15LRyJ/+Ru3tQaPDPOkleTKR3rCnKaDiRCmjxibWt4liRUBji2nzDPFJU
dcD0kEXqCA/H3jyIJWvKnkxvzUfAjCZ7Y7b16sGsJSgVfZ8UFin52loTDgjSz7zU
tgsqsOBIHT72gr/hbxRBzr3ZP8LZqTDA5baoLFAxnYyxIQwK5eRefI6zMP9cuiOA
FL4I60Tige+TBp8kDnyKdYosxRJFkkAJN3YCuHuewIgoV0pD/xkScEscYgqp+CWu
cMQkj5NDDMP/I5ZXw2a64Etq33Hc4SzEm4HvKquu05pS2QgClXu7pg8z2u1BCdPQ
7uMZRyKfAnOOwITKVxsKXT5XJySFJXskMLgupLtp3iEA24GfLJTax0pa7xmOeEbb
nvt2kGdrKvAl3t4PgwvtwuFmfJoqXzjxWMJJRD2s3hXi0TS4WC1y1pccw+INXKsG
7sV+dHhqDPwOHpFleHv4RG207Kx6P8+hbNjdeVI8iEelAhKoPfcUJDM/A4aa2ahd
GB+vZrnuInJlZJeg+hL28Xk1pOxwHtq046nhLosVY7YNDW6CHoD5aruWeQdCT1y5
AFZ/xqOP+XPWMYj/UJLhWoBFTjYjSUZuxi5c4nGpKoK/OSc1GCZERx8Ec7mJrN2R
lzlnW4uBh7M+pvMrhRWl
=rF5K
-END PGP SIGNATURE-
___
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] Exit Nodes under DDoS attacks

2014-08-04 Thread Julien ROBIN
Hello,

With my 2 servers at Digicube it's pretty often (every month ?)

The ISP's protection system is often disconnecting the server for the network 
because of this.
Sometimes it's just false detection (or packets sended by a Tor user), 
invisible on bandwidth graphs but causing the network going offline.

So it's disconnected serveral times per month (each time it happens, I send 
them an email and the server is reconnected).
Because I'm not annoying at all with them, they aren't annoying with me.

The user interface that provides a way to change reverse DNS doesn't work 
anymore for my second server (digi00666.digicube.fr - 2x 15MB/s), it have much 
more DDoS problems that the other one (with customised reverse DNS - 2x 
12.5MB/s).

Once, at Online.net, a DDoS attack (high amount of packet incoming) made my 
server send back a lot of answers. It was banned several days for sending flood!

But as Tor Relay Operators we are strong and combatives ;)


- Mail original -
De: Tyler Durden vi...@enn.lu
À: tor-relays@lists.torproject.org
Envoyé: Lundi 4 Août 2014 14:53:12
Objet: [tor-relays] Exit Nodes under DDoS attacks


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi

I just wanted to know from others how often your nodes are being DDoSed?
Because this month one of our nodes has been targeted twice.


Because DDoS sucks and most providers aren't very happen when this
happens often.





Greetings
virii - enn.lu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlPfgjcACgkQzowS8yos8Rt1LQD/Rj2zZJpdmCyQhCmG3enWL6Z5
J0tbnnG2FS1GelACY74BAKIYRK8EVUt/pYfuuRzlBWWI84kuzcOmOiehqm6iyVjS
=/ay4
-END PGP SIGNATURE-

___
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] Parliamentary inquiry about legal status of running Tor in Austria

2014-07-09 Thread Julien ROBIN
Such political event about Tor is critical because a lot of countries could 
follow Austria about taking (the same ?) static and written position about Tor.

With a political and legal complete acknowledgement of Tor, their will be no 
possible interpretation about is it OK or not to be a Tor Relay operator or Tor 
user.
It can be so useful in front of ISP. And law agents also (sometimes complicated 
to show that what we do is fair and right, answering to their emails).

With a political denial it would be catastrophic : It could be prohibited to be 
a Tor Relay operator, or to be a Tor user, and their will be no possible 
interpretation.

Sometimes I imagine such a situation... as one of the last barrier crossing to 
the end of the free, open and real Internet, like it's being forbidden to exist 
without the proof of some representative's approval stuck on your back and 
checked everywere, with obligation of saying what you are doing, who do you 
want to see, and why... Can't help thinking that existence and freedom doesn't 
desserve anybody's approval !

Let's hope these people will consider Tor as a hope of preserving the Internet, 
even when freedom has drawback freedom is part of the meaning of our lives 
(especially on the Internet, network of exchanges and free expression).


- Original mail -
De: MacLemon t...@maclemon.at
À: tor-relays@lists.torproject.org, tor-t...@lists.torproject.org
Envoyé: Mercredi 9 Juillet 2014 15:42:39
Objet: [tor-relays] Parliamentary inquiry about legal status of running Tor in 
Austria

Hoi!

This is a cross posting tor-talk/tor-relays (Due to the current attention on 
the recent events in Austria. Thanks for understanding.)

Niko Alm (of Austrian political party NEOS) has made an official parliamentary 
inquiry to the Austrian ministry of justice about the legal status of Tor.

Blog posting: http://alm.at/tor/ (in german language)
Inquiry: http://neos.eu/klub/20140708_AF-TOR-BMJ.pdf (in german language)

In theory running a relay/exit _should_ be covered by Austrian E-Commerce law 
§13. It's just not legally proven that Tor also falls under the definition of a 
“communications network” from a legal point of view. Technically everyone would 
certainly agree that this is the case.

From what I understand the goal is to get an official statement by the Austrian 
ministry of justice that Tor falls under the legal definition of a 
communications network. Which would mean, that Relay-Ops are not liable for the 
traffic passing through their relays given they
do not initiate the traffic by themselves
do not select the recipient of the information
do not select or alter the transmitted information
This includes caching.

Austrian E-Commerce law, §13 legal text (german language)
http://www.jusline.at/index.php?cpid=ba688068a8c8a95352ed951ddb88783elawid=116paid=13

Best regards
MacLemon

___
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] CPU usage

2014-07-07 Thread Julien ROBIN
Hi, 

In effect this CPU usage is quite normal : a Tor Relay use a lot of CPU, 
proportionally with amount of data passing trough the relay.
With an Intel Atom D510 I was above 40 Mbps, while CPU was giving everything.

The problem with Tor is the single-thread working for encryption/relaying, so 
if you have a second CPU core available, may be you can open a second Tor 
instance in order to use the second core capacity.

In fact, when your Tor daemon reaches 100% of 1 core usage, you can see what is 
the current bandwith and set it into your torrc file as maximum. When a Tor 
instance exceeds 100% it's a little bit like a congestion into your Tor 
process, so it's better for 100% value to be a limit per Tor process. 
Your relay may average a little bit under the limit bandwidth of your torrc 
file, but this give better performance for Tor circuits established through 
your relay so it's not a bad ;)

An interesting webpage here, full of usefull informations that doesn't appear 
on the official tutorial :
https://www.torservers.net/wiki/setup/server

Even if what you've done is more simple, or a little bit different, this 
tutorial will make you aware of a lot of interesting details and possibilities.

Good luck !
Julien ROBIN

- Mail original -
De: kingqueen kingqu...@btnf.tw
À: tor-relays@lists.torproject.org
Envoyé: Lundi 7 Juillet 2014 22:31:02
Objet: [tor-relays] CPU usage

Hi, I'm running a Tor relay on a low cost dedicated server.

The tor relay is named kingqueen and it's running on an Intel Atom N2700 dual 
core hyperthreaded CPU with 2gb of memory, in a data centre with a symmetric 
100mbps connection.

I have found as time goes on and usage of my relay increases (about 3 weeks 
now) that the Tor process is increasingly using more of the CPU. TOP shows Tor 
using over 100% of CPU and the load average is 2 or more.

I use the dedi for other, less intensive things (OpenVPN, seedbox, also 
Owncloud though this falls over). I know that this is sub-optimal and ideally 
the dedi should be for the relay alone.

I was wondering if the CPU usage is standard. I guess it could be, given it has 
decryption work to be done? Is it high? Is there anything I can do to lower it, 
other than rate limiting, which I don't want to do?

Thank you
___
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] UK Exit Node

2014-07-06 Thread Julien ROBIN
In effect, as Moritz said (and Roman also tried to say) it's necessary for 
navigation over Tor, that every Exit Possibility/Restriction are listed into 
your Exit Policy. If your Exit Node is not going to connect to a given website, 
it's fine, but the Tor Client have to know it, in order to automatically choose 
another Exit to reach the destination.


For Tor Exit Node on a residential DSL line, because I love challenges, I've 
done this in the past, from August 2013 to end of December 2013, with unlimited 
exit policy ;) on a Raspberry Pi. May be I was lucky but apart from 1 copyright 
infrigement (French Hadopi the second week), I never had any problem, and in 
such case the situation is not very comlicated to handle (you simply explain).

If you're like me you will have no problem by thinking your Internet connexion 
have great chance to be looked by your ISP and/or bigger instition : it's part 
of the challenge, and a challenge is interesting when almost no one is plucky 
enough to do what you're going to do ;)


In order to get your participation to last a long time, it's usefull to run 
your node on a dedicated machine, while you can focus on your hobbies and use 
your computer/desktop as before.

Best regards,
Julien ROBIN

- Mail original -
De: Moritz Bartl mor...@torservers.net
À: tor-relays@lists.torproject.org
Envoyé: Dimanche 6 Juillet 2014 14:41:23
Objet: Re: [tor-relays] UK Exit Node

On 07/06/2014 09:39 AM, Michael Banks wrote:
 ‎The block lists are very limited, i.e P2P, lists of known
 blackhats/paedophiles, unallocated IP ranges and most importantly:
 government-owned address and anti-tor addresses

Please do not run PeerGuardian or any other blacklist. These lists are
part of the problem, and in no way a solution. As stated earlier in this
thread, it will break stuff. These lists are never up to date and always
contain false information.

It is your exit, you can indeed block IPs, but please do it on the level
of ExitPolicy.

In your world maybe government-owned addresses are a bad thing. For me
and many other Tor users certainly not.

You're free to run an exit on a residential line, but I doubt that your
ISP will like the abuse complaints. You will likely get kicked off your
contract sooner or later. Also, a residential ISP will not forward abuse
complaints or even tell you about them, so there is no way for you to
explain yourself.

-- 
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] NSA knew about Heartbleed

2014-04-12 Thread Julien ROBIN
It was so much previsible :)

Few days ago the bug was published, few years ago it was already there, and 
this kind of stuff totally matches with NSA's - and other state security 
agencies's - full-time work. 

So in fact there is no more usefull precipitation since Apr 7, but there is 
also No Way they haven't already found our keys, for a long time already.

May be after most part of the network have been updated (and most of the keys 
changed ?) it would be usefull to kick out of the network every compromised 
relays ?

As I'm better in understanding/avoiding bad habbits, than in using hacking 
techniques, I'm unable to know if computers that are hosting Tor Relays could 
have been entirely compromised : without anymore knowledge I decided to 
completely reinstall them. Do you think this is usefull ?


We cannot deny that this kind of well-kept secrets aren't usefull for the 
world in some conditions (I'm thinking about terrorist threats), but as for lot 
of similar subject, how many crap things have been done by these these all 
powerful governments by playing with such a security flaw... 

So I'm curious about what will happen now that we (are may be thinking that we) 
remove that opportunity they had in their hands.

At my side, waiting for what will happen now, I have completely erased and 
reinstalled my servers starting from 0, new passwords... let's hope that 
attention I have for avoiding bad habbits on my personnal computer are enough - 
for me and for others Tor relays Operators !


Best regards
Julien ROBIN




- Mail original -
De: Jesse Victors jvict...@jessevictors.com
À: tor-relays@lists.torproject.org
Envoyé: Samedi 12 Avril 2014 02:32:07
Objet: [tor-relays] NSA knew about Heartbleed


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Saw this article:
http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html

The U.S. National Security Agency knew for at least two years about a
flaw in the way that many websites send sensitive information, now
dubbed the Heartbleed bug, and regularly used it to gather critical
intelligence, two people familiar with the matter said. The NSA said in
response to a Bloomberg News article that it wasn?t aware of Heartbleed
until the vulnerability was made public by a private security report.
The agency?s reported decision to keep the bug secret in pursuit of
national security interests threatens to renew the rancorous debate over
the role of the government?s top computer experts.

Thanks NSA, glad you've got our backs there.

If you run a relay and you have been on one of the affected versions of
OpenSSL, I would urge you to STRONGLY CONSIDER your relay compromised.
Delete your keys per the recommendations and let Tor generate new ones.
It's better to cripple the network temporarily while we come back from
this, rather than preserving the uptime with possibly compromised keys.
Security matters here. Please follow the best practice recommendations.
If you run a web server, rekey your SSL certificates. Basically, if you
were affected, consider encryption to have been bypassed and passwords
and other sensitive information compromised. We cannot afford to take
chances here. If the NSA knew it, you can also bet that someone else
with a good static analyzer discovered it as well, I'll let you imagine one.

Good luck out there everyone, we really need to revoke our keys if we
were affected. Seriously, guys. It's worth it.

On a lighter note, https://xkcd.com/1354/

Stay safe. Live long and prosper.
Jesse V.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQF8BAEBCgBmBQJTSImHXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB
RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yA0nIIAKj1lOXRGcwMFd39CxjnymSN
FVzrPUa/JomCJHqW/A0xSFdxbVAZIvio6C1phuWHmiiDKhsBuBGwLNzXQMGFltaw
BnaTO1lLCvvSbEdmXPg12hR3YqR1d5D7Xnb0iTlSfrjZ7gGDEsXoJG3pU/V/RCFo
IOEqxfZtVcI3DdrImlwcR6gPw6ip9JlTo49w8ncy6/K4cHED2liCQ13JvWjaQzSl
uB06eWNsNo1IhPCKkZ7gFzharhN/4kAQrytC+ZcTmIrXdPrsd1lUaVICHWK9AEon
sciDu5lI77srXWwt77YVAKw6Jrls41N3USgvKBSrxZhfBVQlCPOmoXtTHdwbhks=
=pmBQ
-END PGP SIGNATURE-

___
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