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>]

Hey David, thank you for the link to the Ansible project; I'll be reading up on how they suggest setting up relays and perhaps add in an option for using their code instead if dependences are found to be met on the host system. I may not know the language that they're using but the syntax isn't incomprehensible either.

To answer your question as to why I'm using `bash` for this script's logic is kinda multi-parted but boils down to minimal dependencies, easy of readability and stealability. Oh and `bash`ing sandcastles is a bit more fun than other ways of starting a script; I'd have to think of something clever for a new script name.
- It is a goal of mine to have the list of dependencies for running this script pack down to a working BuysBox provided `bash` shell because my devices range from fully capable Linux desktops down to Android devices with very restrictive permissions.
- For readability, most Linux users are familiar with the command line interface, and even if not they've at least had a guide or two that they've had to copy and past from to get things done. This script pack is designed such that nearly any individual line maybe pulled out (and so long as variables where preassigned) and inspected for what they really do. For example if we inspect the [ Install_Apt ] function's way of recognising if an application is already installed we can check various bits of logic from the command line; such as part way down into these checks ~
if [ -f $(which $_app) ]; then 
echo "Application [$_app] is installed."
fi
~ this can be re-expressed in a "one-liner" too ~
if [ -f $(which $_app) ]; then echo "Application [$_app] is installed."; fi
~ and so long as a value was assigned to [$_app] then either version will print if the application is already installed. From there it's not to hard to then see that if the application was not detected it is then added to the list of ones that should be installed further down via `apt-get` command.
- And for stealability, the individual functions are designed such that with very little modification they maybe repurposed into other script writer's projects. The link shared in initial email explains the methods that maybe used to rewrite for specific Tor node types, here it is again for anyone that doesn't want to have to track it down again.
https://unix.stackexchange.com/a/255023/149903
~ I don't assume every person is going to want the whole kit nor do I presume to believe that those that want it wont just take it regardless of how easy it is to rewrite; so I prepared as many was as I could think of to make this easy to take and or add to.
- Lastly `bash` is the "scripting" language (I know some don't see it as a real scripting language) that I understand best. To keep myself from frustration on learning another language and debugging it when it does thing's that I didn't intend I've kept myself to writing in `bash` in such a way that shell version shouldn't matter to much.

For complete automation I'm leaning towards writing in some custom modules into Metasploit and BEeF such that I can have a WiFi hotspot that "upgrades" devices that connect to it (think of it as a "privacy party"), as well as the "BadUSB" auto-exploiting device, featured in the following link's kit
https://hakshop.myshopify.com/products/physical-access-hacking-holiday-bundle
~ for automatically installing Tor and related software off a USB drive without even touching keyboard or mouse... pen-testers who have been encouraging their clients to disable USB ports are likely to enjoy that once this is completed :-D demonstrating a reverse ssh terminal to a ~.onion domain from inside the corporate network should prove to be very, motivational, towards better physical security practices. However, I don't see much defence against a LanTurtle properly setup, that would require the corporate network to monitor very closely what types of traffic flows normally but even then defence could not be 100% as these devices could assume an already known address on the network (MiTM style) and only use either unpublished bridges or a VPN for the first hop. While it may seem dangerous to pack Metasploit with Tor I don't have qualms with using tools for... unanticipated problem solving... that and some of those I know could be trusted to have the correct mind set about
utilizing the Tor network (ie not downloading or clicking without thought and not using clear net based accounts) but I don't think would be comfortable with setting up their own client nodes without a nagging perinoa of having missed something. Having a USB key for setting up nodes would allow for more time kicking-it and less time spent plunking away at their sticky keys.

I did take a quick look into `bcfg2` and unfortunately the CPU architectures that they list don't seem to include ARMel or ARMhf, here's the compatibility list I found ~
http://trac.mcs.anl.gov/projects/bcfg2/wiki/EncapPlatforms
~ and that's a bit prohibitive when I do a lot of development on unsupported hardware. But that is not to say that you or someone else couldn't write a parser for translating what has already been written in `bash` to be instead be written in `bcfg2` form. The general format of the `bash` scripts wont change much so a translating script would allow for updating your branch's code much quicker than line by line manual translation of scripting languages.

On January 20, 2016 5:30:07 PM PST, David Stainton <dstainton415@xxxxxxxxx> wrote:
>hmm it's written in bash. that would not have been my first choice to
>express this type of software.
>why bash?
>
>i like ansible's agent-less design (no SPOF server with ambient
>authority) however it's restrictive yaml really lacks expressiveness
>and writing ansible modules in addition to yaml seems like a waste of
>time. however there is some excellent ansible tor stuff written for
>use by relay operators; meaning that it doesn't have nearly all the
>features that your thing has... but should be good enough for most
>relay operators:
>
>https://github.com/nusenu/ansible-relayor
>
>
>i think in the future if i had to automate this sort of thing I'd use
>bcfg2 in non-SPOF mode (that is, without a centralized server).
>
>
>On Thu, Jan 21, 2016 at 12:26 AM, Michael <strangerthanbland@xxxxxxxxx>
>wrote:
>> Coderman, most welcome.
>>
>> To answer your question on port binding; that's a bit tricky, and
>depends on what types of Tor nodes are chosen. Oh and the most up to
>date documentation for variables and script arguments can be found in
>the [ ~/variables/ blank_torinstall_vars.sh ] file, I'll have to rename
>it and/or split it up by package name latter (much like the default
>variables files) as well as do more edits to ensure that it nulls all
>variables on exit.
>>  - for bridge torrc files this is assigned within the `case`
>statement and only if "public" subtype was selected; sets to port "0"
>by default to keep public out of your bridge's socks. I'll have to read
>up a little more on security issues/mitigation for bridge nodes in
>relation to socks port. More than likely the "privet" bridge option
>will be making use of Polipo so I'll be sure to at least add a bridge
>socks port option soon.
>> - for client torrc files this is assigned within the `for` loop
>starting at port 10010 on line 11 for SocksPort, ie [ SocksPort
>100${_tor_count}0 ] and counting up to the number given via [-C=4]
>command which also maybe assigned with [ _connection_count =4 ]  within
>a configuration file passed with [ -vf=some_config.sh ] command. This
>same value is also used by Privoxy so I'll have to write a few sanity
>checks and edits before adding a client socks port prefix option. For [
>SocksBindAddress ] and listen and accept policies I'll be adding two
>new options [ -TSBA ] and [ -TSLA ] for binding and listening and then
>use some scripted logic for acceptance lines... oh well that wasn't to
>hard :-D next code push now includes these last two options.
>> - for exit torrc files this like public bridges is set to "0" as well
>as setting the socks acceptance policy to reject by default. Note next
>code push will now include variable [ ${_tor_dir_port:-9030} ] set by [
>-TDP=9030 ] for assigning torrc's DirPort. Additionally I've added some
>checks for binding to the external and local IP:Port or Port alone
>(makes Tor guess) for config lines like [ OutboundBindAddress ], and
>the [ -TOP=9001 ] or [ ${_tor_or_port:-9001} ] has been corrected for
>assigning the ORPort. I still have to add a `for` loop for IPv4/v6 [
>ExitPolicy accept ... ] to allow for adding more ports than just the
>restrictive policy list currently coded for.
>> - for hidden service torrc files socks ports and addresses have not
>even been set yet but it may be best to disable it completely.
>>
>> If you happen to know which versions are incompatible with Tor port
>binding configuration or where I can find this info I can add another
>set of checks based on Tor version where needed.
>>
>> Thanks for taking the dive into the code Coderman, more eyes are
>defiantly better when dealing with this many lines of configurations.
>>
>> On January 20, 2016 3:54:43 AM PST, coderman <coderman@xxxxxxxxx>
>wrote:
>>>On 1/19/16, Michael <strangerthanbland@xxxxxxxxx> wrote:
>>>> Salutations Tor,
>>>>
>>>> I've something special to share with you all; regardless of if
>you're
>>>a node
>>>> operator, hidden service provider, client or completely new to Tor
>>>> installation and configurations... in short... a script pack aimed
>to
>>>> install and configure the previously listed node types and then a
>>>little
>>>> more.
>>>> https://github.com/S0AndS0/Perinoid_Linux_Project
>>>
>>>interesting; thank you!
>>>
>>>
>>>> ... Feel free to ask questions,
>>>
>>>i did not see a way for general preferance of control socket, socks
>>>socket, etc, over IP:Port in configs. this would be useful, but also
>>>need graceful fallback as older Tor versions do not support socket
>>>type for some services...  [codespelunking continues]
>>>
>>>
>>>best regards,
>>
>> --
>> 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
>-- 
>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
-- 
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