Re: [tor-talk] Scripted installer of Tor and more being worked on at GitHub, ya may want to sit down for this...

[Michael <strangerthanbland@xxxxxxxxx>]

David,

I'll happily aid in testing and coding a Python translated version
if we can find an easy way of adding it to a custom build of BusyBox
or installing from source onto Android without chroot. My biggest
concern is portability and compatibility with as many devices as
possible because I plan to make a "BadUSB" and "ADB" wrapper. 
I've begun documenting the configurations that the current
version outputs into a project Wiki to help anyone that wants to
help get a jump on translating to any other languages while I continue
to add the remaining features ~

https://github.com/S0AndS0/Perinoid_Linux_Project/wiki/Config_Examples_Torrc_Bridge

~ and here's a link that may turn some of those frowns ya 
mentioned upside down, as it documents the custom set of
Bash functions that where written to make things a bit easier
to maintain. ~

https://github.com/S0AndS0/Perinoid_Linux_Project/wiki/Sandcastle_Arg_checker

~ Even if the current project moves to another language the above
should give frowners a reason to grin when they understand how
this can be used for "niche circumstances" on other projects ;-)
for the most part this script pack is a just a very simple set of `if`,
`for` and `case` statements so translation should be a trivial task.

The "haters" are more than welcome to, so long as the emotion
can be channelled towards building something constructive with
this project I've no reason to dissuade them from their feelings.
Truth be told if I didn't already know that Java would have received
more push back than Bash I would have tried to express this in 
Nodejs/NoFlo~

https://github.com/noflo/noflo

~ because it offers a more visual way of showing scripted logic.
But I've seen how people cringe at I2P's use of Java so I went to
what I knew to be pretty universally understood so that we can have
the logics and configurations mapped out without confusion and 
suspicions getting in the way.

Thanks David, I may need much in the way of luck in the future.
The "cross pollination" of education is exactly what I was hoping
for and from checking out what others have started or "stared"
I've already seen a few things I want to add as options for 
installation from this project such as ~

- for some hardcore filtering rules
https://github.com/jakeogh/dnsgate

- and this looks to be an amazing delivery system that 
"whistle blowers" could use for initial publishing of information.
https://github.com/tryforsure/ephemeral2

- And one of the best BTC+GitHub combos I've seen, which I may use
for this project in the future so code maintainers get something for their
contributions automatically.
https://github.com/WhisperSystems/BitHub

~ in short I'm learning a great deal from you all and am very
thankful for it.

####

For all readers I've a few Q's that could use some A's,
I've been working on the firewall scripted portion of this project ~

https://github.com/S0AndS0/Perinoid_Linux_Project/blob/master/functions/shared/output_iptables_varfile.sh

~ so far as I know Tor nodes use only TCP protocol (even for DNS?)
so I'll be adding each node's various ports via ~

` _tcp_ports="${ _tcp_ports},${_some_tor_port1},${_some_tor_port2}"`

~ and then have the `for` loop in ~

https://github.com/S0AndS0/Perinoid_Linux_Project/blob/master/firewall/functions/input_chains/input_tcp_filters.sh

~ and it's in/output counterparts for IPv6 to parse which
ports will be opened and or forwarded through the firewall.

My biggest questions are with forwarding chains and where to
place jumps to these filtering chains from the default iptables forward
chain for best performance. 
For example should `in_tcp` be used on `preroute` or `forward` chain?
And should the `out_tcp` be used on `postroute` or somewhere else?

Having an answer to these questions will allow me to push forward
with having a "proof of concept" version completed for not just
Tor and related software but also allow for "jailing" various packages
from one another on their own bridged network interfaces to keep
security breaches a bit more contained.

My last question (for now) has to do with Fail2Ban and hidden services.

My question is would you all prefer that separate jail.local configuration
blocks be written for each Tor service port individually, ei failing one port
doesn't ban from a possible second hidden service port, or is a fail one
ban'em all sufficient?

I see that the first option would make it harder for an attacker to be 100%
sure that two hidden services lead to two ports on one physical machine.
But would allow for repeated attacks on all available ports before all filters
ban their interactions.
And I see that the second option would limit attack surface but would also
allow for leakage of info as to what hidden services might be running on 
the same device. 
A tough call so I'm all ears on how we should proceed.
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk