December 2015 - tor-relays - lists.torproject.org

ANN: TCP injection attack detection tool - honeybadger
by David Stainton 07 Dec '15

07 Dec '15

Dear Golang community, Edward Snowden, cypherpunks, Tor-relay operators, low-level network hackers and TCP abolitionists, I was inspired by the Snowden documents to write a TCP injection attack detection tool. Powerful entities world wide are stock piling zero-days. TCP injection attacks can be used to deliver many of these attacks. source: https://github.com/david415/HoneyBadger docs: https://honeybadger.readthedocs.org/en/latest/ tasty pcap for "integration testing": https://github.com/david415/honeybadger-pcap-files HoneyBadger does bidirectional TCP stream reassembly... temporarily storing segments in ring buffer for comparison to later received overlapping stream segments. In other words it doesn't rely on simply matching duplicate sequence numbers but compares the actual overlapping stream segment contents. This more thorough approach is needed to account for TCP's retransmission which can send various segments sizes that can differ from the original dropped segment length. Furthermore we also detect the other injection types such as handshake hijack. The literature (go ahead and scour the Internet) does NOT mention all of the TCP injection attacks that are possible. I assert that there are 5 possible types of TCP injection attack. I describe them here: https://github.com/david415/HoneyBadger_docs/blob/hackpad1/source/how-to-de… https://github.com/david415/HoneyBadger_docs/blob/hackpad1/source/how-to-de… current honeybadger project status: - honeybadger seems mostly useable for use in the wild, though we are pretty sure that bugs exist and probably some false positive bugs at that. - active development halted several months ago when the implementation seemed good enough to deploy and sniff packets in the wild. - if in the future the gopacket dev team releases a new "sufficient" TCP reassembly API then I could severely reduce HoneyBadger's code size. - pull requests and github issue comments will inspire me to contribute feature additions and fixes It runs on Linux but does honeybadger work on *BSD? Of course it does... I wrote the gopacket BSD BPF sniffer API ;-p and tested honeybadger on NetBSD, FreeBSD and OpenBSD. I'd like to explore the possibility of writing a similar TCP injection attack detector in rust using libpnet as soon as libpnet is sufficiently mature to use for TCP analysis: https://github.com/libpnet/libpnet So what? 1. So... all TCP analyzers need to be rewritten to account for TCP injection attacks, otherwise you are doing it wrong. 2. So feel free to use HoneyBadger to analyze your own traffic over the wire or sketchy pcap files that you acquire; perhaps our data collection efforts will result in responsible disclosure of 0-days... and publicly reporting that in fact these TCP injection attacks do happen as targeted attacks against real people to violate their human rights. 3. So use my design in your software; The description of how to detect the 5 possible TCP injection attacks can serve as a part of a design document for other software projects to implement their own TCP injection attack detection. cheers from the Internet, David Stainton

2 1

VPS/Tor
by Kurt Besig 07 Dec '15

07 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I want to thank everyone for the multitude of great suggestions regarding getting my relay up on a VPS. I reviewed every email and all the input was useful. The relay is up and running: E65D 300F 11E1 DB12 C534 B014 6BDA B697 2F1A 8A48 As well as my home relay: F527 3098 A711 F845 E5D1 A24F 9D38 F93B 86A0 F220 While all the information culminated in a successful outcome the suggestion of installing ufw as a means of setting up iptables was exceptionally valuable, thank you. Hopefully in the future I can return the kindness. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJWZZzuAAoJEJQqkaGlFNDPifYIAIGF6EZIxvuRCz2pTQa9+vg1 6OX1YJ/Z/fP4sGhhS+VtpGzhjewFf4Yv1FYXvWdRQWVW204Ms6wR6ibul4jLd58u ENr75uDqK/ro8kLWQpWsLeJoh3zp8cAc5dpH/u9Itftj0o/td8fGVeV6YIOw9q3L oA90pIVRNXun49Tb4cZjYm71+KBRwSekyXUoXccAcFzw+1WvLkW9TD8Xtd25/D7E 2VBfsYZinqia+7kqcCfUzoO4Ekg4JTkgBt/PkQ9eONz3w5g6+e52hh3kNurW3wfO 61BQ5Nq/0Q2u+cmgp+DItkD5+XSLPop8HZnwJM17M1nGxZ+/cBFYGZQmrlXpFUs= =nGYI -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] Custom bandwith for different time ranges
by starlight.2015q3＠binnacle.cx 07 Dec '15

07 Dec '15

>Is it possible to schedule the time when bandwith . . . >How may I schedule this in tor relay? >Is it possible to limit traffic on >the client or I need to do it on my firewall ? As suggested in an earlier reply, configuring 'cron' jobs to adjust the rate usually makes sense. As an alternative to modifying 'torrc' and sending SIGHUP to the daemon, you could use a control-channel script similar to: nc 127.0.0.1 9151 <<EOF AUTHENTICATE "passphrase" SETCONF BandwidthRate=Y BandwidthBurst=Y QUIT EOF An even better way is to use the 'tc' or "traffic control" command to limit ingress traffic to the relay via a 'police' filter, as rate-limiting through discarding of packets result in better performance from daemon during overload conditions than the daemon rate-limit algorithm. But 'tc' only works if an interface or alternate IP on an interface can be dedicated to the Tor router, and it's more technical to configure. If the firewall is an Cisco ASA, an ingress rate 'police' policy can be constructed with results similar to the 'tc' approach. However one must dedicate an entire ASA Ethernet port to the relay as this type of filter cannot be applied to a limited set of flows. A problem with altering bandwidth significantly on a schedule is that the BWauths that measure and rate relays will produce erratic results for the relay. BWauths are erratic when rating stable relays due to some issues with the implementation, and the results for a moving target is even worse.

1 0

VPS/Tor Almost There
by Kurt Besig 07 Dec '15

07 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks again for all the support everyone has bee extremely helpful. So, I reinstalled the OS on the VPS: lsb_release -d Description: Ubuntu 14.04.3 LTS uname -r 2.6.32-042stab102.9 Finally solved all the permissions problems, paths are correct, tor and arm open properly. The problem now boils down to this: The VPS isn't allowing Ports 9001 and 9030 Should I investigate further getting my iptables up and running or just contact the admin and have them allow the ports? As I mentioned previously even after saving the tables upon reboot iptables -L shows no rules, the file is empty. :~$ iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Any further suggestions would be appreciated. Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJWZF8qAAoJEJQqkaGlFNDPO18H/2Axj4EeGf5joYQ3n2SH1cgs HhDAawaiMaSKMcfC/Oc9TudwKAxkoY+QkhegZr5senNKXrXjNPeLucfejkRBiUoJ 8KLOZabSGH2Uf89JNa4ZFbf9QVIiU8GdNJ0vSGy55iAuJQl14ZUpDRQeNnGkmwb5 uhADchwTVjK7Pq+ELyG6OI6l0jlQ69TWCpgH4lnMjQ5U+Nr1QKyApxXqr1ap5Heb KJmlwchTv4zAxX2eBc1DPqAXdc9OsvEsPG/r/zp4Z/wPWxsUTGoZWoXsWv4xyjPQ xzAzUKD+b+AvqGQ3ehQbdXtg423kO7/amVidAzux8mDmMeZuFoP3tpfqLd8cH+s= =uoin -----END PGP SIGNATURE-----

5 4

Re: [tor-relays] tor-relays Digest, Vol 59, Issue 8
by Manager Bahia del Sol LLC 06 Dec '15

06 Dec '15

1 0

Re: [tor-relays] Unbelieveable
by Manager Bahia del Sol LLC 06 Dec '15

06 Dec '15

5 6

Unbelieveable
by Kurt Besig 06 Dec '15

06 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 That I got two responses after posting to tor-relays regarding a fairly simple, I thought, CntrolPort question on a new VPS relay.. That's pathetic. Thanks for all your input. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJWYP6FAAoJEJQqkaGlFNDPTCUIAKGRC9/XUKeBLrhIlXUrZd03 oTiWdNJebmCRJ55gXbXv+2VxwM18YipkkwEIRmxrSdUsvzn2zRZ11FOnv1Yi8tFY oiD8HgqLVe6pcDepslPPe/SJyMz6tIqBnosYG6yADOpYCXRR22ehRlPQHkdg2kZ+ ePBWJwDVop8WXUDwgAxRFd/jp/WWjLRt90bgHpcupEzbGi7GMTvNbftHEBeJvhwc g1xp5gZlvBgCT8Kb03dXQCUaYQ8hpjc9zbo4sQwnJNOZpyU6ftLdsoODa8NRW73s bslUj6EjQ5P2+tC2d9Q7s669XpLoxipJm1QiYVqFPIfLo48F4GjW1r64SKBxHVw= =mddV -----END PGP SIGNATURE-----

14 22

VPS Connection Refused
by Kurt Besig 04 Dec '15

04 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just set up a VPS on PulseServers as I noticed quite a few running relays had mostly good things to say about the service. So Far the people operating the servers seem very cooperative and responsive. Anyway I've been running a middle relay for 1.5 years and know the "ropes" pretty well, however a VPS is new to me. After setting up Tor and tor-arm on the VPS I'm not able to connect with this error: unable to reconnect (connection refused. Is the ControlPort Enabled?) I've edited ~/home/.arm/torrc and /etc/tor/torrc un-commenting the ControlPort 9052 and all the other typical ports, etc.. Obviously I'm not able to forward or enable ports on the VPS, so do I need to ask the admin to make some changes? Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJWX3RnAAoJEJQqkaGlFNDPiS4H/2g/stKLNl0R1ZzbM2/MmC45 D0t2K8E7mcuIhxDiQJ/klaluJWnTHUrUPonSXTZuMYQJOBjdQIV6Mbq61/2g/TK9 VOdiTIsJSD30wmPIUZXlFb7xGX98DNedsySbCG4evJGmJvmEKXiAwg9i/K0iz5Ar KmRTRxtqCUJcmS+L0s0chV2A7TsIpP2h/WUS/tzc+AmAlbx1jZ4K1zu2uzCqZIjQ 69nkbbHd9DDlmSXvC9aKCB1MO3HcJUgA6gUin4UBOhkrTokbfRQBtizuHqlI4RSG sL9CyOocs9d1DEQVF1pN3PPNjWh/Owm4WzMTm3dMJ+DuRQQ5ls3R+4Fn9I//2Mg= =26fO -----END PGP SIGNATURE-----

6 11

(no subject)
by 海洋 04 Dec '15

04 Dec '15

1 0

webiron requesting to block several /24 subnet
by WubTheCaptain 03 Dec '15

03 Dec '15

This will be my lengthy opinion on Webiron to get everything out of my mind without redactions. > Webiron's system sends notifications to both the abusix.org contact > for the IP and to abuse at base-domain.tld for the reverse-DNS name of > the relay IP. This doesn't seem to be the case for us. Our rDNS is set to tor-exit.se.partyvan.eu. Back when I received our first abuse complaint from Webiron, the WHOIS for the Tor exit IP-address had an abuse-mailbox contact for us but the abuse-c was still pointed at our data center. Webiron emailed three email addresses: - abuse(a)portlane.com (abuse-c, mnt-by for all of our /29) - info(a)partyvan.eu (unlisted, unused RFC 2142 address) - abuse(a)partyvan.eu (abuse-mailbox) By the time I had received a second or third abuse report from Webiron, I had made some voluntary changes to get the abuse-c assigned to us after registering to RIPE database. Despite this, Webiron's system still contacted two addressses: - abuse(a)portlane.com (mnt-by for netnum) - abuse(a)partyvan.eu (abuse-c and abuse-mailbox) More accurately, Webiron may employ caching of results or go for the netnum abuse-c/abuse-mailbox instead. Other abuse complaints we've received such as one from the Brazilian Army have contacted our abuse@ role only and never bothered our data center. For what it's worth, abuse.net also lists our abuse@ contact for the domain. > I'm currently in the middle of a somewhat heated e-mail debate with > their vice-president. > Pasting the e-mails below would be indelicate, but their position is > that the Tor network is responsible for the abuse it generates and > should take measures to prevent/block malicious traffic. > They also state that according to their measurements, 99% of the > traffic coming out of Tor is hostile, and they're going to release a > report on the matter soon. Webiron's policies are dodgy at best. They even claim that Tor exit operators are legally liable for the traffic they route [1], which is obviously false given our real legislative liability protection for service providers. I immediately lost sense of their credibility. They say: > Groups hosting exit nodes are responsible for the abuse that comes out > of exit nodes. By refusing to take action to stop attacks originating > from your proxies it can make you legally responsible to international > law as well as laws in most regions (IE EU) as it shows a willingness > to facilitate further attacks. Our data center doesn't seem to mind Webiron's abuse reports regarding our Tor exit, and while they also get copies of the abuse complaints they've never bothered us about it. (For the curious, Portlane used to house Serious Tubes which housed The Pirate Bay until a raid on December 2014.[2]) After receiving six or so abuse complaints from Webiron [3] and acknowledging each to support(a)webiron.com explaining it's a Tor exit, I've not heard back from them again for a while. Banning /32 or /24 seems out of question for us to keep the limited liability protection. It wouldn't solve the issue anyway due to 1000+ other exits available, so the best solution remains to block Tor temporarily from the other end or implement CAPTCHAs for Tor users to slow down or defeat bruteforce attacks. As an example, CloudFlare implements CAPTCHA for visitors from Tor. Webiron could do something similar if they wished to act on these as a reverse proxy service. Their requests are too unreasonable for Tor exit operators. By their ideology, I understood they're saying stores selling ski equipment for skiing should be held liable for crimes commited by their customers who bought their skiing masks: > You chose to allow this to run from the network you are responsible > for. Proxing attacks is translatable to providing the mask before an > assault or robbery. At this point we feel your company is complicit in > these attacks by allowing them to continue. For me this does not sound credible, and I didn't bother trying to give their argument more credibility with a reply. They wished me "good luck" [4] after mentioning my Tor exit will be on their blacklist and referencing to IBM's research on "recommending a blanket ban on Tor".[5] At least I still remain to have some sense of credibility in SpamCop and Spamhaus, despite few controversies involved with the latter. This is why we can't have nice things and why I've given up with most hosting providers. PS: Portlane is not yet listed on GoodBadISPs [6] wiki page. -Wub [1]: https://archive.is/Obhnk [2]: http://www.bbc.com/news/technology-30411782 [3]: https://partyvan.eu/transparency/emails/abuse/ [4]: https://partyvan.eu/transparency/emails/abuse/2015-11-13-webiron-tor-exit.m… [5]: http://www.techweekeurope.co.uk/security/ibm-companies-tor-175468 [6]: https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs

1 0