- tor-relays - lists.torproject.org

Relay Consensus Weight
by Marco Morgia 24 Apr '15

24 Apr '15

Hello, on friday my realay's Consensus Weight felt down suddenly to 20 and the its bandwidth is not used anymore (https://atlas.torproject.org/#details/94212674A2C6AEBF77354D959D464E49BC878…) I don't understand why, as nothing is changed in its configuration. And, I don't know if it's related, but I noticed that the tor network has slow down in the last days and some times it's very difficult to use it. Thanks for your help, Marco ____________________________________________________________ Receive Notifications of Incoming Messages Easily monitor multiple email accounts & access them with a click. Visit http://www.inbox.com/notifier and check it out!

3 11

Re: [tor-relays] Installing obfs4 on Raspberry Pi bridge
by jchase 23 Apr '15

23 Apr '15

Hello, When I run $ go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy $ sudo cp $GOPATH/bin/obfs4proxy /usr/local/bin on a laptop running linuxmint/ubuntu it produces a nice binary executable. Unfortunately it doesn't work to copy it to the Pi2, because it's not an ARM binary. When I run the same script on the Pi2 I get the following error messages: go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy # git.torproject.org/pluggable-transports/obfs4.git/common/ntor /usr/lib/go/src/pkg/git.torproject.org/pluggable-transports/obfs4.git/common/ntor/ntor.go:272: undefined: sha256.Sum256 /usr/lib/go/src/pkg/git.torproject.org/pluggable-transports/obfs4.git/common/ntor/ntor.go:369: undefined: hmac.Equal # git.torproject.org/pluggable-transports/obfs4.git/common/log /usr/lib/go/src/pkg/git.torproject.org/pluggable-transports/obfs4.git/common/log/log.go:131: function ends without a return statement # git.torproject.org/pluggable-transports/obfs4.git/transports/obfs3 /usr/lib/go/src/pkg/git.torproject.org/pluggable-transports/obfs4.git/transports/obfs3/obfs3.go:278: function ends without a return statement # git.torproject.org/pluggable-transports/obfs4.git/transports/scramblesuit /usr/lib/go/src/pkg/git.torproject.org/pluggable-transports/obfs4.git/transports/scramblesuit/conn.go:322: undefined: hmac.Equal /usr/lib/go/src/pkg/git.torproject.org/pluggable-transports/obfs4.git/transports/scramblesuit/handshake_uniformdh.go:143: undefined: hmac.Equal /usr/lib/go/src/pkg/git.torproject.org/pluggable-transports/obfs4.git/transports/scramblesuit/handshake_uniformdh.go:152: undefined: sha256.Sum256 and the script exits Any idea how I can get it cleanly on a Pi2? Thanks, J. Chase tor-relays-request(a)lists.torproject.org: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: Installing obfs4 on Raspberry Pi bridge (jchase) > 2. Re: Installing obfs4 on Raspberry Pi bridge (Yawning Angel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 12 Apr 2015 17:43:55 +0000 > From: jchase <jchase(a)riseup.net> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Installing obfs4 on Raspberry Pi bridge > Message-ID: <552AAEDB.4020007(a)riseup.net> > Content-Type: text/plain; charset=windows-1252 > > Hello, > Thanks to you I have tor 0.2.5.11 running on a Raspberry Pi2 and obfs4 > installed from git. I have good news and bad news. > The largest problem is that I get the warning "could not launch managed > proxy executable at '/path/obfs4proxy'('Permission denied')" In the past > this used to be a problem with apparmor, but apparmor isn't installed. > Any idea where I can start looking for a solution? > Here are a couple of details and small problems: > I didn't install obfs4 directly (due to problems), but installed it to > another laptop and copied it to the Pi2 using scp. > I have ORPort somewhere above 9000. When I set it to auto, I got a late > warning that the port chosen by tor was presenting problems, had I > arranged port forwarding, etc.? ExtORPort is "auto" and I get no > complaints (probably because obfs4 isn't working). > And I have ServerTransportListenAddr obfs3 0.0.0.0:90xx because a lower > port, like 80, with port forwarding, received a warning (and didn't work). > One thing at a time... Like I asked, where can I look for answers to the > obfs4proxy permission denied problem? If I get that fixed, I assume I > can play around with the rest until I can use lower ports. > Thanks, > J Chase > > > ------------------------------ > > Message: 2 > Date: Sun, 12 Apr 2015 20:14:33 +0000 > From: Yawning Angel <yawning(a)schwanenlied.me> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Installing obfs4 on Raspberry Pi bridge > Message-ID: <20150412201433.6c42f28d(a)schwanenlied.me> > Content-Type: text/plain; charset="us-ascii" > > On Sun, 12 Apr 2015 17:43:55 +0000 > jchase <jchase(a)riseup.net> wrote: >> Hello, >> Thanks to you I have tor 0.2.5.11 running on a Raspberry Pi2 and obfs4 >> installed from git. I have good news and bad news. >> The largest problem is that I get the warning "could not launch >> managed proxy executable at '/path/obfs4proxy'('Permission denied')" >> In the past this used to be a problem with apparmor, but apparmor >> isn't installed. Any idea where I can start looking for a solution? >> Here are a couple of details and small problems: >> I didn't install obfs4 directly (due to problems), but installed it to >> another laptop and copied it to the Pi2 using scp. > > Oh dear. What happens when you run the obfs4proxy executable in a > shell directly (on the pi2)? > > It should look something like: > $ ./obfs4proxy > 2015/04/12 20:13:02 [ERROR]: obfs4proxy - must be run as a managed > transport > > If not, what does 'file /path/obfs4proxy' say? > > Regards, >

2 1

Any t-shirts being sent?
by I 23 Apr '15

23 Apr '15

2 1

Delete keys on reboot
by CJ Barlow 23 Apr '15

23 Apr '15

The Tor Relay Security document suggests deleting keys upon reboot to prevent one-time key theft. I have tried to do this in Raspbian via cron but have been unsuccessful. The cronjob I have running is: @reboot rm -f /var/lib/tor/keys/* && echo "keys gone!" > /home/[me]/reboot.txt 2>&1 I have the echo as a debugger. When I changed /var/lib/tor/keys/* to /home/[me]/test/* the job runs successfully. When changing it back to /var/lib/tor/keys/* it does not. Is this something I should resolve? If so, is there something with my cronjob that's preventing it from working?

4 6

Re: [tor-relays] tor-relays Digest, Vol 51, Issue 27
by Rekha Tokas 23 Apr '15

23 Apr '15

Can I get the list of those sites which are blocking tor traffic to view or edit their page? On 23 Apr 2015 17:30, <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: Subpoena received (Jan GUTH) > 2. Re: Subpoena received (Jan GUTH) > 3. Re: Subpoena received (Brian Kroll) > 4. Re: Subpoena received (renke(a)mobtm.com) > 5. Re: Quantum Insert detection for everyone (tor(a)t-3.net) > 6. Re: Subpoena received (Moritz Bartl) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 23 Apr 2015 10:15:32 +0200 > From: Jan GUTH <prometheus(a)enn.lu> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Subpoena received > Message-ID: <5538AA24.3040802(a)enn.lu> > Content-Type: text/plain; charset=utf-8 > > On 20/04/15 16:32, Tyler Durden wrote: > > Hi > > I just wanted to let you know that Washington sent us a subpoena > > regarding one of our exit nodes in Romania. They want to know the real > > IP behind the Tor Network. I mailed them what Tor is and why I can't > > help them in identifying this person. Nevertheless I will give you the > > link to the full subpoena. Maybe you guys find it interesting. I will > > forward the subpoena to our lawyer as well. > > > > > > > https://mega.co.nz/#!ilIjlZSb!-deirKharWaDtp_UMxhev58E14zeouyoWUbzxeWPvEQ > > Good morning list, > > I just called up Alistar and explained the entire situation. They IT > guys know what Tor is and their company is strongly interested in > continuing supporting Tor. They are a partner company now of Voxility, > and the apparently while moving some clients, someone did forget to tell > them that they'll get a client running Tor exit nodes. > > They are simply overchallenged with this request as it is the very first > one they have ever received. > > The good news is, that they will _not_ shutdown our server, nor take any > logs, which are non-existant. The counterpart we need to contribute is a > letter by our lawyer and favorably a letter from EFF or some other > bigger organization guaranteeing Tor is what it is and we as client do > not try to fool them. > > This is a request from the administration level of the company, not the > tech guys - as always. > > So, I'll get in touch with our lawyer & with EFF. Is there anyone else > within EU, whom could certify them what Tor is and what it is capable of > and what not? Moritz? > > Cheers, > J. > > -- > Jan GUTH > International Coordinator > > Fr?nn vun der ?nn A.S.B.L. (NGO) > e. info(a)enn.lu (GPG: 0x02225522) > t. +352?691?71?77?44 > w. http://enn.lu/ > > > ------------------------------ > > Message: 2 > Date: Thu, 23 Apr 2015 10:20:10 +0200 > From: Jan GUTH <prometheus(a)enn.lu> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Subpoena received > Message-ID: <5538AB3A.2050701(a)enn.lu> > Content-Type: text/plain; charset=utf-8 > > On 20/04/15 16:32, Tyler Durden wrote: > > Hi > > I just wanted to let you know that Washington sent us a subpoena > > regarding one of our exit nodes in Romania. They want to know the real > > IP behind the Tor Network. I mailed them what Tor is and why I can't > > help them in identifying this person. Nevertheless I will give you the > > link to the full subpoena. Maybe you guys find it interesting. I will > > forward the subpoena to our lawyer as well. > > > > > > > https://mega.co.nz/#!ilIjlZSb!-deirKharWaDtp_UMxhev58E14zeouyoWUbzxeWPvEQ > > Good morning list, > > I just called up Alistar and explained the entire situation. They IT > guys know what Tor is and their company is strongly interested in > continuing supporting Tor. They are a partner company now of Voxility, > and the apparently while moving some clients, someone did forget to tell > them that they'll get a client running Tor exit nodes. > > They are simply overchallenged with this request as it is the very first > one they have ever received. > > The good news is, that they will _not_ shutdown our server, nor take any > logs, which are non-existant. The counterpart we need to contribute is a > letter by our lawyer and favorably a letter from EFF or some other > bigger organization guaranteeing Tor is what it is and we as client do > not try to fool them. > > This is a request from the administration level of the company, not the > tech guys - as always. > > So, I'll get in touch with our lawyer & with EFF. Is there anyone else > within EU, whom could certify them what Tor is and what it is capable of > and what not? Moritz? > > Cheers, > J. > > -- > Jan GUTH > International Coordinator > > Fr?nn vun der ?nn A.S.B.L. (NGO) > e. info(a)enn.lu (GPG: 0x02225522) > t. +352?691?71?77?44 > w. http://enn.lu/ > > > ------------------------------ > > Message: 3 > Date: Thu, 23 Apr 2015 08:29:45 +0000 > From: Brian Kroll <brian(a)fiberoverethernet.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Subpoena received > Message-ID: <5538AD79.3060902(a)fiberoverethernet.com> > Content-Type: text/plain; charset=windows-1252 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > Zack Weinberg: > > On Mon, Apr 20, 2015 at 10:32 AM, Tyler Durden <virii(a)enn.lu> > > wrote: > >> I just wanted to let you know that Washington sent us a subpoena > >> regarding one of our exit nodes in Romania > > > > Just FYI, "Washington" doesn't appear to have anything to do with > > this. The subpoena is on the letterhead of an office of Cook > > County, Illinois, which is the locality containing the city of > > Chicago. Per > > http://www.cookcountyil.gov/office-of-the-independent-inspector-general/ > > > > > this office investigates misconduct by county officials. > > > > This matters because, first, this is probably a tiny little outfit > > with little or no clue about either the Internet or international > > law. > > As a resident of Cook Country I can safely say it's not a small > locality, but I'm sure their knowledge about international law is > quite low. > > > They *should have* hired an international lawyer when they saw > > they'd need to talk to someone operating out of Romania and/or > > Luxembourg, but it doesn't surprise me in the slightest that they > > didn't. > > > And they've probably never even heard of Tor before. > > I know the Chicago Police claim they don't know what Tor is. > > http://www.muckrock.com/foi/chicago-169/chicago-police-use-of-tor-15392/ > > > Second, the incident which triggered the investigation, whatever it > > is, is probably quite minor. (This is backed up by their asking > > for one IP address active at a single point in time.) It would > > have been booted up to the state or federal level if it were any > > kind of serious. For both those reasons, I would rate the odds of > > them actually bothering to jump through all the necessary legal > > hoops to get a court order binding on a foreign national as slim to > > none. > > > ATB > //Brian > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJVOK1xAAoJEFjBjkteF9VaV2EP/3OrGZqHMdqWccR0Qkrt80rc > vw9RgIAtnhUfZVLlt8Y/RNhpSUOwrBf2gFxcc48zN3/Llad1ybF1PDFQym516ntK > RLRmGDf945qRxTsApXCN9WjRD0iMqyfQuq/NddTYKCMeMZadYW9MoUNe3md8wwKg > feeYNpCRmrTTh1Q7gRKYa4dRS6jLrNqNv5o/pL3jp5OlX8nLz+LyJxNVopZ2khAq > T4B51NOD0D5rLJ8cEQf528dmAM6QipUvtY3r5mVqb7VRO5NJuAxsRCnql6qTi68h > FIeLRZh44miY/vOS//dPlSFyb/h3ECVGCMH3ngtaJ5LLkAUXXWc8XYiEeDFyUrxg > O5/pUy9uo4ZRz9UXU7ZEpsttw2Gs1GDc7bRRrL4aHp8OGr+85p493aBqyixmr16d > Wz2lUdVioVBO5sj7rG+QXSc5b4Wp1/jKOWszKUNjX02AMnpe21idQrS0qn9kzSNP > Gsi8XyFP/08m+n2weTZ9W000uznjMCKWvWlOfJtTyo9oB23cZ7g/4Rs1j4wQR4W4 > 8/iuQFwjx3OipdxjzP4g3HwYLYeFT5DECVEzWtqx2LaIMI6ObTjDOnyO/PDIqzWA > YSK8hUqCKI6SqJE5l1kP4bzDsbQaY13nxoK0uVbW35h01FpHRIjyIXrFJorTqjrT > 8c3B2zNha+ogBOljvYtJ > =uUdm > -----END PGP SIGNATURE----- > > > ------------------------------ > > Message: 4 > Date: Thu, 23 Apr 2015 11:47:17 +0200 (CEST) > From: renke(a)mobtm.com > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Subpoena received > Message-ID: <20150423094717.382558A02B7(a)dd1818.kasserver.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > > The counterpart we need to contribute is a > > letter by our lawyer and favorably a letter from EFF or some other > > bigger organization guaranteeing Tor is what it is and we as client do > > not try to fool them. > > as the US government sponsored (parts of) the Tor development - what about > giving them US military research papers about the Tor network? > > http://www.dtic.mil/dtic/tr/fulltext/u2/a465464.pdf is one of them, > co-authored by a Navy researcher and performed by the Naval Research > Laboratory. > > Not itself sufficient, but done by a bigger organisation w/o triggering > anarchist/commie/hacker/terroristsupporting/publicenemy bias reactions. > > Renke > > > ------------------------------ > > Message: 5 > Date: Thu, 23 Apr 2015 07:39:07 -0400 > From: tor(a)t-3.net > To: <tor-relays(a)lists.torproject.org> > Subject: Re: [tor-relays] Quantum Insert detection for everyone > Message-ID: <5538d9db.9d8.3c445700.6bd5299c(a)t-3.net> > Content-Type: text/plain; charset=us-ascii; format=flowed > > > On 04/23/2015 01:56 AM, David Stainton wrote: > > > It is possible to add a "prevention" mechanism to HoneyBadger; an > > event based firewall ruleset generator made to block TCP injection > > attacks as they are happening... yes. This is possible. I could > write > > that if there was interest from enough people. > > Gief. > > > > > > ------------------------------ > > Message: 6 > Date: Thu, 23 Apr 2015 13:57:32 +0200 > From: Moritz Bartl <moritz(a)torservers.net> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Subpoena received > Message-ID: <5538DE2C.3030200(a)torservers.net> > Content-Type: text/plain; charset=utf-8 > > On 04/23/2015 10:20 AM, Jan GUTH wrote: > > So, I'll get in touch with our lawyer & with EFF. Is there anyone else > > within EU, whom could certify them what Tor is and what it is capable of > > and what not? Moritz? > > Depends on what convinces them. :-) Sounds like it may make sense to get > a generic letter signed by all our partner organizations (which includes > Reporters without Borders, Institute of War & Peace Reporting, > Article19, and potentially other Human Rights Orgs) in the long run. > > I'm happy to write something as Torservers.net, in a way representing > all the current partner orgs. Then, we can send the letter around and > get it co-signed by all the partner orgs and other orgs. > > -- > Moritz Bartl > https://www.torservers.net/ > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ------------------------------ > > End of tor-relays Digest, Vol 51, Issue 27 > ****************************************** >

1 0

Re: [tor-relays] Quantum Insert detection for everyone
by tor＠t-3.net 23 Apr '15

23 Apr '15

On 04/23/2015 01:56 AM, David Stainton wrote: > It is possible to add a "prevention" mechanism to HoneyBadger; an > event based firewall ruleset generator made to block TCP injection > attacks as they are happening... yes. This is possible. I could write > that if there was interest from enough people. Gief.

1 0

Quantum Insert detection for everyone
by David Stainton 23 Apr '15

23 Apr '15

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

2 4

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