[tor-relays] (no subject)

[海洋]

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] VPS/Tor

[Kurt Besig]

-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-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] ANN: TCP injection attack detection tool - honeybadger

[David Stainton]

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-detect-TCP-injection-attacks.rst

https://github.com/david415/HoneyBadger_docs/blob/hackpad1/source/how-to-detect-TCP-injection-attacks.rst#tcp-injection-attack-categories


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



signature.asc
Description: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ANN: TCP injection attack detection tool - honeybadger

[OM Healing]

Thank you.

On Monday, December 7, 2015, David Stainton  wrote:

>
> 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-detect-TCP-injection-attacks.rst
>
>
> https://github.com/david415/HoneyBadger_docs/blob/hackpad1/source/how-to-detect-TCP-injection-attacks.rst#tcp-injection-attack-categories
>
>
> 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
>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Custom bandwith for different time ranges

[tor-re...@b4ckbone.de]

Hi!
> Hi All
> Is it possible to schedule the time when bandwith will looks as follow:
> 
> 8:00 - 18:00 - Tor relay bandwith 250kb/s
> 
> 18:00 - 8:00 - Tor relay bandwith 10 000kb/s
> 
> 
> 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 ?

I do see 3 viable ways, just run the relay from 18 to 8 a clock and stop
it (via cron?) from 8 to 18.
Or create 2 different tor configurations one limiting the bandwith to
250 kb/s and the other one to 1 kb/s and reload tor with the
according configuration (via cron)
last but not least you could setup some fancy traffic shaping like in
https://svn.torproject.org/svn/tor/tags/tor-0_2_0_20_rc/contrib/linux-tor-prio.sh
where you limit the bandwith with tc and not tor itself.

Greets



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Custom bandwith for different time ranges

[Roman Mamedov]

On Mon, 7 Dec 2015 21:42:11 +0100
"tor-re...@b4ckbone.de"  wrote:

> Hi!
> > Hi All
> > Is it possible to schedule the time when bandwith will looks as follow:
> > 
> > 8:00 - 18:00 - Tor relay bandwith 250kb/s
> > 
> > 18:00 - 8:00 - Tor relay bandwith 10 000kb/s
> > 
> > 
> > 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 ?
> 
> I do see 3 viable ways, just run the relay from 18 to 8 a clock and stop
> it (via cron?) from 8 to 18.
> Or create 2 different tor configurations one limiting the bandwith to
> 250 kb/s and the other one to 1 kb/s and reload tor with the
> according configuration (via cron)
> last but not least you could setup some fancy traffic shaping like in
> https://svn.torproject.org/svn/tor/tags/tor-0_2_0_20_rc/contrib/linux-tor-prio.sh
> where you limit the bandwith with tc and not tor itself.

Yeah but any of these are very likely to wreck your consensus weight
situation, and as a result you'll be hard pressed to use the full potential of
the 1 KB/sec cap. The first option will also "ensure" you'll never get the
Stable flag.

Sure if "that's what you have to work with" then there's no any better options
remaining, and of these listed personally I'd suggest the reloading configs
one.

-- 
With respect,
Roman


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Custom bandwith for different time ranges

[Zalezny Niezalezny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I think I will write a script which will change bandwidth base on the number of 
incomin connections to my varnish server. Then there is a big chance to keep 
stable flag on.
Thank U for all that ideas ;)))

Zalezny

Dnia 7 grudnia 2015 22:23:21 CET, Roman Mamedov  napisał(a):
>On Mon, 7 Dec 2015 21:42:11 +0100
>"tor-re...@b4ckbone.de"  wrote:
>
>> Hi!
>> > Hi All
>> > Is it possible to schedule the time when bandwith will looks as
>follow:
>> >
>> > 8:00 - 18:00 - Tor relay bandwith 250kb/s
>> >
>> > 18:00 - 8:00 - Tor relay bandwith 10 000kb/s
>> >
>> >
>> > 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 ?
>>
>> I do see 3 viable ways, just run the relay from 18 to 8 a clock and
>stop
>> it (via cron?) from 8 to 18.
>> Or create 2 different tor configurations one limiting the bandwith to
>> 250 kb/s and the other one to 1 kb/s and reload tor with the
>> according configuration (via cron)
>> last but not least you could setup some fancy traffic shaping like in
>>
>https://svn.torproject.org/svn/tor/tags/tor-0_2_0_20_rc/contrib/linux-tor-prio.sh
>> where you limit the bandwith with tc and not tor itself.
>
>Yeah but any of these are very likely to wreck your consensus weight
>situation, and as a result you'll be hard pressed to use the full
>potential of
>the 1 KB/sec cap. The first option will also "ensure" you'll never
>get the
>Stable flag.
>
>Sure if "that's what you have to work with" then there's no any better
>options
>remaining, and of these listed personally I'd suggest the reloading
>configs
>one.
>
>--
>With respect,
>Roman
>
>
>
>
>___
>tor-relays mailing list
>tor-relays@lists.torproject.org
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQJEBAEBCgAuBQJWZgS7JxxaYWxlem55IDx6YWxlem55Lm5pZXphbGV6bnlAZ21h
aWwuY29tPgAKCRDiQxB1lp0KmnZJD/oCtkRXmnqYobwurX4Tts/j1ekQdVbMHJlu
KR0GQrPIDii/lrJwozeKmqpG7O5VMsOOOftrFLX3n3roQXirLXffXwnkIBZZvC3V
iHTfBRzXB3VrMiWhzthJSgie1qMQWXKyq+zcoXygq6t39pzBsilkjh97BOsQpqq1
EttTUVL+HTF5Uw6TD5KfQN330L1kWan7F1ILjB6qO7GRX7jz/gStibKaSc4j5O19
G3Z8S8FAGY+rGPI3f8qfXGNAd55i664Ah7fjK4HopE8ruf2u00Fs89oqc141n4Cq
cpR0TpDOGCdWKrDmmcX5cGKXV+YpRB+HlxfLnZI66Xu+Ern9V0Ue2tQ5ihG+to7Q
kJBqjACvVuS9WcND1aNNFbfwVLwC1FXcxrVwdEv/sx25NgsulD7175pwHDsuDuj1
cEteWrdLse850hRf5P/5q906xiILjBcW+XOw8h5FxgAmEQT2ehIhnQDx8AUxU0qh
ogqCLm+moy7tEYP5CKmszyqDhLshKhx04VKUrRtpE4xCoojcsYUEHsLwIszTmepb
tnpPu+82FaNa7+HKlQRaAoSFcuKU2CJ+f1dudrPFpF3EIYr0jRpQfGnE4p9Zr9dI
3T0+TarvTf4UftYkn63iSl8sLOn8iutWZ+yIT9Jm57q8g1ckSTKYM1EpZbjhcUNs
lsbQJgcvRg==
=bs0+
-END PGP SIGNATURE-

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Custom bandwith for different time ranges

[Tim Wilson-Brown - teor]

> On 8 Dec 2015, at 12:11, Green Dream  wrote:
> 
> > any of these are very likely to wreck your consensus weight situation
> 
> From a Tor user's perspective, if a relay is periodically dropping to 250 
> Kb/s, a low consensus weight for that relay is probably a good thing.

Two other possibilities:
* always run the relay at 250kbps
* run a bridge instead (I don't know if 250kbps is still considered enough for 
a bridge)

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays