Re: [tor-relays] DoS stats from exits running 0.3.3.2-alpha
Hello, Here's the DoS log line after a few days: [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 500 single hop clients refused. On 16/02/18 18:23, nusenu wrote: > I was wondering if these unfriendly tor clients are using tor's default > path selection or something else. > > If they do tor exit relays would have much smaller values in their DoS stats, > right? > > Would any tor exit operator (listed bellow) running 0.3.3.2-alpha be willing > to share (obfuscated/not exact > counters) of their DoS log entries? (only if you do not have any additional > firewall rules filtering packets) > > > > | ab...@to-surf-and-protect.net >| > | replace k with c : kontakt @ zwiebeltoralf . de >| > | >| > | florentin aatt rochet ddoott be; LTC: LhRqJZu6U87BJNSUbkACHzVQsK39hJ3sMB >| > | tor-rel...@coldhak.ca >| > | ab...@to-surf-and-protect.de >| > | J. Random Hacker >| > | Exit by Reporters without Borders via https://www.torservers.net/ >| > | Neel Chauhan | BTC: > 1KogNvxdcXydDUNrPgqgtgV3AWktKPqXpS | > | Random Person >| > | OctaneZ-TOR >| > | https://www.torservers.net/donate.html >| > | shallot protonmail com >| > | Random Person >| > | Brandon Kuschel >| > | >| > > > > > ___ > 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] Increased cpu usage
Hello, I upgraded 4 exits yesterday and apart from one of them suffering a DDoS, I don't observe any large CPU increase. Maybe your upgrade coincides with the recent overload of create cells? https://trac.torproject.org/projects/tor/ticket/24716 Worth to keep an eye on it, anyway. Best, Florentin On 2018-01-17 11:30, r1610091651 wrote: Hi AFter upgrade from 3.1.9 to 3.2.9, I've noticed that the cpu usage doubled for same throughput / conditions. Is anyone else seeing that too? Regards ___ 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] Relays operators meetup @ FOSDEM 2018 ?
Up :) Thanks for the initiative ! Le 13/01/18 à 00:07, Nicolas Braud-Santoni a écrit : Hi, I might be able to organise a relays operators meetup at FOSDEM, early February. (This is contingent on me being able to come, though.) I wanted to ask whether there are other relay operators who are planning to go, and which times would work; I made a quick poll to this effect : https://framadate.org/HpPbnRwOYNmK6D5G Feel free to add yourself without filling your availability yet, if you will be around but haven't looked at the schedule yet. I know we had the yearly meetup at 34C3 quite recently, but after discussions there it seemed like a good idea to reach out to relays operators who don't necessarily attend congress, to people who don't yet run relays but have questions, and do so in a different context than congress. Best, nicoo ___ 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] Combined relay and hidden service, good idea or not?
Hey Tortilla, Sorry for the late reply: On 2018-01-05 21:13, Tortilla wrote: The issue is fixed by adding the above warning message: if you care about your hidden service's "hidden" property, do not run a relay on the same process. Would you mind elaborating? As I read the tracker link, the issue was an informational leak in bandwidth reporting that has now been solved and closed. As such, the startup warning is misleading unless there are other concerns (such as Igor's below) and in which case, the warning should be re-worded. Why do you say it is *fixed* by adding a warning? https://trac.torproject.org/8742 issue is already a stronger concern than Igor's point, and there are more. The informational leak in bandwidth is still there today, since these measurements are public. The issue is marked as fixed because, if you do relay+HS, you got a warning "not secure" that links to a possible attack (#8742) to recover your HS's location. To be honest, I don't really get why you feel that the startup warning is misleading. Is it because it links a fixed and closed trac issue? The part "cannot easily run an analysis targeted at a hidden service" looks just wrong to me. If you want an example of an active attacker able to easily uncover such a hidden service (when mixed with a relay), you can give a look at our paper "Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols" [1] (to appear in PoPETs18). The techniques presented are not applied on that particular setup, but this is somewhat trivial to do. I believe the logic was that if a machine is identified in some way as one to watch, and if it is seen participating in the Tor network but is not listed as a public relay, it's easier to conclude that it may be hosting a hidden service, after which other correlation attacks can be targeted at the machine. Thus, the recommendation that running a public relay helps mask HS traffic. Perhaps in the case that the HS operator is not trying to mask the HS location, the act of mixing public relay traffic can be nothing but a *help* to defeat anyone trying to correlate traffic coming to the HS with traffic emanating from any one client. Yes, if the HS operator does not want to mask the HS location, then it is all good. For that purpose, I agree that the warning message should be changed. Forgive me for only skimming your paper, but I didn't see any explanation that the attack outlined was either facilitated or enhanced by the HS also running a relay. Would you mind commenting? Ok, so suppose a public relay and a hidden service running on the same process, and the attacker knows the onion address. The hidden service's location can be uncovered using public bandwidth leaks of the relay. Just do the following trick: send a few GB of trash data to the hidden service using the kind of method described in the paper. Then, wait that the public measurements are updated and look for the relay having a few more GB of read data than write data. You should obtain only one IP. Congrats, it's the IP of the hidden service. So, if you care about your HS's hidden location, do not run a relay on the same process :-) Best, Florentin ___ 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] Combined relay and hidden service, good idea or not?
Hey, On 2018-01-05 04:08, torti...@mantablue.com wrote: When operating a hidden service and a relay in one tor instance, tor currently warns: [warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742 First, that issue has been fixed and closed. The issue is fixed by adding the above warning message: if you care about your hidden service's "hidden" property, do not run a relay on the same process. Second, I had read in the past opinions stating: When operating a hidden service, running a relay helps mix traffic so that anyone observing traffic from the machine cannot easily run an analysis targeted at a hidden service that might exist on that machine. The part "cannot easily run an analysis targeted at a hidden service" looks just wrong to me. If you want an example of an active attacker able to easily uncover such a hidden service (when mixed with a relay), you can give a look at our paper "Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols" [1] (to appear in PoPETs18). The techniques presented are not applied on that particular setup, but this is somewhat trivial to do. Best, Florentin [1] https://uclouvain.be/crypto/people/show/462 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Image asset in Tor readme html
On 2017-12-20 03:52, teor wrote: On 20 Dec 2017, at 12:59, Fabian A. Santiago wrote: Can the Tor service not serve up a locally referenced PNG file in the readme HTML file used for dirportfrontpage? Mine keeps showing as a broken link. Tor doesn't have this feature, it simply serves the page as a single file. There are probably some tricks you could use with newer browsers to embed a PNG file in the page. This example may help you: http://145.239.91.37. View source to see how the Tor image is embedded Best, Florentin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] OVH down
Hi all, A quick look this morning (UTC+1) at AS16276 (https://atlas.torproject.org/#search/as:AS16276) is a good example why we need more network diversity :-) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit / Bad Gateway
Hello,
Same for my exit. I just count that 220 exit relays over 869 have their
Consensus Weight at 20.
Best,
Florentin
On 2017-06-27 12:49, Logforme wrote:
On 2017-06-27 12:35:21, "Sebastian Urbach" wrote:
Dear list,
My Exit:
https://atlas.torproject.org/#details/4198BD138E5E11B15B05C826B427148CED7D99FE
My Consendus Weight dropped to 20 today and i found the following in
notices.log:
Jun 27 12:03:35.000 [warn] http status 502 ("Bad Gateway") reason
unexpected while uploading descriptor to server '154.35.175.225:80').
Jun 27 12:07:35.000 [warn] Received http status code 502 ("Bad
Gateway") from server '154.35.175.225:80' while fetching
"/tor/server/d/C8B7BA97808F42802FCC2DF231A85ACB5B8D848A.z". I'll try
again soon.
Any ideas what to do or just sit it out ?
-- Sincerely yours / M.f.G. / Sincères salutations
Sebastian Urbach
Same for my non-exit:
https://atlas.torproject.org/#details/855BC2DABE24C861CD887DB9B2E950424B49FC34
Looks like the drop in cw coincided with messages like these in the log:
Jun 27 04:35:48.000 [warn] Received http status code 502 ("Bad
Gateway") from server '154.35.175.225:80' while fetching
"/tor/server/d/44C3629D79C5366209DB976F1F1588A39B923123+C4716B2DA2AB2CAC2DA0256CD2484050B75371BF.z".
I'll try again soon.
154.35.175.225 is the authority server faravahar which have had
network issues in the past.
___
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] Memory Problems with tor releay
Le 22/05/17 à 20:29, tor-relay.d...@o.banes.ch a écrit : Dear all, we are operating two exit nodes with each two tor processes out of Switzerland. The nodes worked quite stable until about 2-3 weeks ago. Since then we experience frequent disruptions (Up to several times a day). This is caused by a significant rise in memory consumption by the tor processes and ends with a tor process being killed by the Linux Kernel: May 22 00:30:43 tor2 kernel: [2257156.134100] Killed process 40964 (tor) total-vm:448088kB, anon-rss:0kB, file-rss:0kB The systems are physical machines with Ubuntu 14.04.5 LTS with 4 GB of memory. This was sufficient the last 2 years. For more details a sample of this behavior is documented in a Ticket [1]. Tor project team is researching but until now no hints lead to an improvement. Due to a tweet last week [2] and the follow up discussion with another operator I became suspicious that is not just just us having a problem rather it cloud be more common. Therefore here the question to you all - do you experience some strange behavior like described in the ticket as well ? Please let me know if so. Hello! I have the same issue with tor-0.2.9.10 (last stable on jessie). The process got killed 6 times since May 14 .. and a 7th just right now. If not - maybe it is just an unfortunate coincidence and we will end up make a clean install of both server hoping the problem will go away. best regards Dirk [1] https://trac.torproject.org/projects/tor/ticket/22255 [2]https://twitter.com/FrennVunDerEnn/status/864583496072876034 ___ 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] Aggressive abuse report
Hi Maarten (and others who answered back), I got a few more mail exchange with them. I tried to educate a bit and it seems they agreed (not explicitly) that the right to privacy is something that should not be removed to people due to the illegal actions of a few others. They told me to be forced by law, as a service provider, to do their best to reduce this kind of illegal traffic. I told them I will reject targeted IPs seen in more than one complain. In my opinion, that's an appropriate tradeoff. Right now, it seems that I will not get banned :-) I appreciate the help, Florentin On 2017-03-14 17:08, Maarten wrote: Hi Florentin, Read the policy of your hoster. I had the same situation and already configured a reduced exit policy. So I just changed my exit policy. Now I do not relay to their entire IP block on port 80 anymore. So it can't happen again.. My hoster was fine with that. Along with this I sent an explenation that I am not the only Exit node and how to easily block all exit nodes. (The default text from the tor project website) I had the luck that the employee agreed that Tor's value to society makes the abuse acceptable. Maarten. Florentin Rochet wrote on 14-03-17 13:41: Hi list, I am running Kadoc[0] for a few weeks and got today a more aggressive complain from a System Administrator of my VPS provider. I seek for an appropriate response to not get banned. Does someone experienced a similar scenario and succeeded to educate the sys admins ? Here's the complain: /"It is running a Tor Exit, hence producing a false positive." is not a valid reason.// //You are the one responsible for the traffic generated on/trough your server, so you should make sure that no similar traffic will appear in future. Illegal actions are strictly prohibited in our network/servers.// //Please take immediate actions to stop this kind of activity./ I am almost sure that trying to argument that I am not responsible for the traffic generated through my Exit is not the right angle with such guy. Any ideas ? Best, Florentin Rochet [0] https://atlas.torproject.org/#details/171696AFDB589CA2C4978EED2C6A91153D2B993B ___ 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
[tor-relays] Aggressive abuse report
Hi list, I am running Kadoc[0] for a few weeks and got today a more aggressive complain from a System Administrator of my VPS provider. I seek for an appropriate response to not get banned. Does someone experienced a similar scenario and succeeded to educate the sys admins ? Here's the complain: /"It is running a Tor Exit, hence producing a false positive." is not a valid reason.// //You are the one responsible for the traffic generated on/trough your server, so you should make sure that no similar traffic will appear in future. Illegal actions are strictly prohibited in our network/servers.// //Please take immediate actions to stop this kind of activity./ I am almost sure that trying to argument that I am not responsible for the traffic generated through my Exit is not the right angle with such guy. Any ideas ? Best, Florentin Rochet [0] https://atlas.torproject.org/#details/171696AFDB589CA2C4978EED2C6A91153D2B993B ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
