tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

ARM stopped working
by Jeffrey Hathaway 22 Apr '15

22 Apr '15

Hello Everyone, I noticed ARM stopped working for me. Has anyone seen this before? Traceback (most recent call last): File "/usr/share/arm/starter.py", line 578, in <module> cli.controller.startTorMonitor(time.time() - initTime) File "/usr/share/arm/cli/controller.py", line 700, in startTorMonitor curses.wrapper(drawTorMonitor, startTime) File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper return func(stdscr, *args, **kwds) File "/usr/share/arm/cli/controller.py", line 720, in drawTorMonitor initController(stdscr, startTime) File "/usr/share/arm/cli/controller.py", line 86, in initController firstPagePanels.append(cli.logPanel.LogPanel(stdscr, expandedEvents, config)) File "/usr/share/arm/cli/logPanel.py", line 652, in __init__ self.reprepopulateEvents() File "/usr/share/arm/cli/logPanel.py", line 696, in reprepopulateEvents torEventBacklog = getLogFileEntries(setRunlevels, readLimit, addLimit, self._config) File "/usr/share/arm/cli/logPanel.py", line 313, in getLogFileEntries eventTimeComp = list(time.strptime(timestamp, "%Y %b %d %H:%M:%S")) File "/usr/lib/python2.7/_strptime.py", line 467, in _strptime_time return _strptime(data_string, format)[0] File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime (data_string, format)) ValueError: time data '2012 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00Apr 22 15:23:48' does not match format '%Y %b %d %H:%M:%S'

3 2

Re: [tor-relays] [tor-talk] Quantum Insert detection for everyone
by Mike Perry 22 Apr '15

22 Apr '15

I'm being a jerk and cross-posting to tor-relays, because I want to make sure that relay operators are aware of the differences in the Snort vs HoneyBadger approach. Chris Dagdigian: > > I run a US-based exit node and would be interested in a way to run > this software without compromising the users exiting my node. > Looking forward to your additional writeups - especially anything > geared towards exit nodes and quantum insert detection. I too look forward to David's writeup! For what it's worth, I think HoneyBadger is likely to be safer for exits, more comprehensive, more accurate, less noisy, and more high performance than a Snort-based solution. HoneyBadger is focused only on this particular attack and is written in golang, whereas Snort has tons of rules for everything and is written in C. This means that HoneyBadger will have a much smaller vulnerability surface and should be much harder to directly exploit than Snort. Since we're talking about detecting and capturing attacks from well funded state/world-class adversaries here (wow, what a world), vulnerability surface minimization and general memory safety are top priority. Snort is also vulnerable to tailored attacks designed to flood its logs and/or avoid detection. Snort is particularly susceptible to missing stateful attacks designed to subvert its stateless rule-based approach to detection. Several types of TCP injection attacks that rely on TCP reassembly will likely fall into this category (type 4 in: https://honeybadger.readthedocs.org/en/latest/#tcp-injection-attacks). HoneyBadger also appears to have better logging options than the Snort rules. David has been in contact with malware researchers who were quite insistent that to properly analyze 0day, a single evilpacket is very likely to be insufficient -- context is essential, especially if the attacker wants to obfuscate the attack or otherwise avoid exploit extraction. Hence the need to provide optional full-take and rolling logging options that make it easier to extract the full TCP stream of a tampered connection, as well as related concurrent traffic (such as a stream from a related HTTP redirect to an ephemeral URL). I've been talking with David about ways to place these logs on a ramdisk or an ephemerally encrypted partition, so that when detailed logs are needed, they can be handled as safely as possible. > >David Stainton <mailto:dstainton415@gmail.com> > >April 22, 2015 at 2:41 PM > >Greetings, > > > >Did you all see this Wired article about Quantum Insert detection? > > > >https://www.wired.com/2015/04/researchers-uncover-method-detect-nsa-quantum… > > > >These TCP injection attacks are used by various entities around the > >world (not just NSA!) to target individuals for surveillance or > >perhaps to add their computers to a botnet for other purposes. > > > >If you do not use a VPN or Tor you can run "Quantum Insert" detection > >on your computer and detect when you receive an attack attempt. > >However be advised that proper sandboxing is important here because > >intrusion detection and protocol anylsis tools are notoriously > >insecure and get pwned all the time. > > > >If you are a Tor exit relay operator you have the options of running > >detection software; However you should not publish the results > >publicly without mixing in some noise or your published data might > >make it possible for some adversaries to deanonymize Tor users. If > >your country has strict telecommunications laws then it might only be > >legal for you to perform this type of detection if you do not perform > >logging. > > > >For the past several months... in my free time I've been slowly > >developing a very comprehensive TCP injection attack detection tool > >called HoneyBadger: > > > >https://github.com/david415/HoneyBadger > > > >Quantum Insert is a NSA codeword for "TCP injection attack", however > >either of these terms are too vague. During my research I was able to > >classify 4 different types of TCP injection attack. When I say that > >HoneytBadger is comprehensive what I mean is that Honeybadger can > >detect ALL of these types of TCP injection attack types... I describe > >them briefly here: > > > >https://honeybadger.readthedocs.org/en/latest/ > > > >Here's the Fox-IT blog post about their Quantum Insert detection software: > >http://blog.fox-it.com/2015/04/20/deep-dive-into-quantum-insert/ > > > >I am going to work on writing a much more comprehensive blog post; it > >will be filled with gory technical details AND it will include > >information on how to use HoneyBadger. HoneyBadger has optional (off > >by default) full-take logging which could enable you to capture a > >zero-day payload from a TCP attack; you should then responsibly > >disclose to the software vendor or contact a malware analyst to help > >out! > > > > > >Sincerely, > > > >David Stainton -- Mike Perry

1 0

Wj%#qpkkn
by Vitalie 22 Apr '15

22 Apr '15

XaLloukkkl Zp Eeddpprriioxzlal Pzjmmp --whmllpq,ukInviato dal l cellulare Andropf K-9 Mail.

1 0

onionoo backend seems to be down.
by jason＠icetor.is 21 Apr '15

21 Apr '15

Hello All, Anyone else notice onionoo and the tools that rely on it (globe.torproject.org atlas.torproject.org) seem to be down? -Jason

5 4

Re: [tor-relays] Undiagnosable Crashes in Relays
by teor 21 Apr '15

21 Apr '15

> Date: Wed, 25 Mar 2015 17:21:50 +0800 > From: Vincent Yu <v(a)v-yu.com> > > On Wed, Mar 25, 2015 at 4:26 PM, skyhighatrist <skyhighatrist(a)tfwno.gf> > wrote: >> I am wondering if anyone has had their relay randomly crash in the >> past >> week or so. Three of mine (I run 6, nonexits) have fallen over. One of >> them ~5 days ago, one of them ~4 days ago, and one of them earlier >> today >> . > > This also happened to my two relays about three weeks ago. They are: > > https://globe.torproject.org/#/relay/C309A31AD772FFDD0805C9FECB6D4748A7CBF6… > https://globe.torproject.org/#/relay/18BE989663CF3351F73D33C672BB1C985E0EA5… > > They are both middle/guard relays (about 200 Mbps each) on the 0.2.6 > branch and are on the same dedicated server. They went down at > different times, and as far as I can remember, there was nothing > notable in the Tor and system logs. No issues prior to this over the > past 12 months. I haven't had time to investigate this. > This also happened to my EC2 relay a few weeks ago, but I never had time to investigate. It's quite possible it was a bad nightly tor version, or some sort of misconfiguration on my end, but the timing matches. I didn't manage to get it to come back up in the limited time I had to try and fix it. https://globe.torproject.org/#/relay/425E55A8FA145ACFC01FA58CD4E6F46DD7762A… (No record, it's been down for a while.) teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

2 3

Tor and Freenode
by Markus Hitter 20 Apr '15

20 Apr '15

Hello all, after yesterday watching "State of the Onion", a speech held at 31C3 recently, I spontanuously decided to also run a Tor relay. After some back and forth it appears to be running fine on my OpenWRT based router. The only ORPort is 9001, which is also the only hole punched into the firewall, I hope I did this right. Today I wanted to continue at Freenode IRC, like I did for years, not even using an anonymous connection. But they wouldn't let me in: [12:02] * You are banned from this server- Your tor exit node must not allow connections to freenode (tor exit node (chat.freenode.net:8000)). Email tor-kline(a)freenode.net when corrected. (2015/1/24 09.41) I understand that my router and my PC share the same IP address to the remaining internet and IRC operators try to identify users by their IP address (which isn't possible). Reading up on the matter I found two texts: http://www.freenode.org/policy.shtml "The freenode network welcomes Tor users" http://www.freenode.org/irc_servers.shtml#tor "If you do want to be a Tor exit node and still use freenode, you will have to configure your exit policy to block all of the IRC ports we use, in addition to ports 80 and 443 as these are used for webchat." To me this sounds like "We welcome it, but please block all of its usage". They recommend to add a "reject *:*" rule, but that means the relay is no longer a relay, right? And blocking port 80 and 443 means Tor to become useless. As I can't find much on the matter by googling: is this actually a misalignment of Freenodes' statement to freedom as bad as it looks? If yes, what could I do about it? I'm a fairly experienced hobbyist hacker and admin, so I wouldn't fear writing some code. Cheers, Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/

14 27

many hundreds connections to the same ip address + port
by Toralf Förster 19 Apr '15

19 Apr '15

Since few days (or since 0.2.6.7 ?) I do observe this behaviour at y exit node, eg. to port 81, 110, 636 and other non-http ports. Didn't saw this before - any hints ? -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E -- "; the past is all dirty and cruel in the modern popular imagination, with the exception of the Romans, who are just cruel" Ian Mortimer, 2008, "The Time Traveller's Guide to Medieval England"

1 0

Re: [tor-relays] simple relay setup
by tor-server-creator＠use.startmail.com 18 Apr '15

18 Apr '15

thanks do i have to install something in first line to perform this gpg lines? you say "| apt-key add -" torproject.org says "| sudo apt-key add -" doesnt sudo matter cause im useing root? is it possible to just deactive login/ssh to be save or is it just better/necessary to deal with rsa key? will tor be utoupdated at new release with "apt-get -y upgrade" or how to manage automated actuality? On Saturday, April 18, 2015 3:46 PM, Julien ROBIN <julien.robin28(a)free.fr> wrote: > 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-creator(a)use.startmail.com > À: tor-relays(a)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(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

simple relay setup
by tor-server-creator＠use.startmail.com 18 Apr '15

18 Apr '15

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.

3 2

Hello Everyone
by Jeffrey Hathaway 17 Apr '15

17 Apr '15

Hey Everyone, I have been a big supporter of the Tor Project, and I have finally been able to work with my upstream providers and get an Exit bridge online. https://atlas.torproject.org/#details/DFBD4AD44C2EC14EA921C639859CE432A3554… Based on the exit policy, does anyone suggest any changes i should make to keep abuse to a minimum?

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays