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

[Michael]

Apologies David, I often am to long wended but will endeavor to be a bit more to the point in the future but I may fail as words are an not always the most efficient form of communication.

Indeed Bash is what I use because it's what I know. While I've studied a bit of Python (enough to read and mod pre existing code) I've not become savvy enough to write fully fleshed out code with it; had to become familiar with other languages up to this point too but rarely have to pursue it further to get a task done. Totally valid points in favor for Python, or really any real programming language, both have been challenges that I've had to bodge solutions for while writing in Bash. Error handling currently is spread across three separate functions and uses `||` redirection to detect failures (which it does an okay job at but can still be defeated) because like you've already stated `set -e` really doesn't count and unit tests are no contest in favor of another language as the current methods of testing one logic train individually would require a code rewrite or pulling just the required shared functions out and rewriting the installer script a bit. While I've attempted to
mitigate for what Bash lacks through the use of custom functions and loading only what is needed for each task; I know full well that it ain't pretty nor ideal, but as I haven't seen anyone else tackle it in a comprehensive manor on all fronts it seemed like a good idea to take a shot at it.

Heh, ok I've reclassified that memory "I read it online somewhere..." :-D instead of true and will look into bcfg2 further. It seems like Python wouldn't be to big a jump but it will increase the script's dependencies beyond base Linux or BusyBox depends that I aim for... but then again just a Bash written installer for Python and having the rest of the code in that language may allow for easer future modifications. I'll help maintain the code if it is translated but if ya wait on me to rewrite it'll be awhile as there's still almost an equivalent amount of data as the current script trapped in notes form waiting to be scripted for Fail2ban, Apache, and two other privacy centric networks.

Yeah that would be part of the solution that Tor's network brings to the table, the other would be that for those on the penetrated network it would be more difficult to figure out to whom that box was reporting to or where or what information it is reporting. Definitely take a look into Metasploit's reverse ssh and other payloads, they use IPs or domains but ~.onion or ~.i2p options currently are not supported.

Danger I see is, as with any tool, when with mal intent. Currently, well as far as I have been able to read, Metasploit doesn't have a payload available that installs Tor onto a target device; ya have to have a static IP or regular domain to point the remote and local host values to. While there are tricks to get around this , ie VPN chaining, they require a much larger scope of knowledge to setup correctly and seems to me a waist of time and resources when there's a network already available for routing. I'm not encouraging anyone to go out and do harm with either set of tools but I will encourage that everyone have a healthy paranoia of these tools being used for ill; encourage it to the point of trying to make it a bit easier to test your own networks against such things before someone does it for ya. That is the more dangerous application of such a combination that I could think of but I come from a background of using exploits on my own devices in order to obtain more
functionality; for example I happily root all my past upgrades (phones) such that they can be used for various local network monitoring among some even run as good security cameras that can be checked up on when away from home without divulging to a secondary ISP (such as Motel WiFI) of where or what I'm checking up on. Metasploit seems to me would pair well with Tor because it would allow for "upgrading" routers among many other consumer products remotely as well as providing resources for testing the results. The over all goal is to have my nodes testing their own vulnerabilities and reporting types of behaviours back so that various monitoring tools can have profiles updated for what to look out for, I know this will be impossible to fully mitigate but certainly improvements can be found through throw testing. Tripwire is a good candidate that I've found for reporting after the a break-in and Selinux as well as Apparmor I keep finding and taking notes on for further limiting
damage as well as reporting (I'm very open to suggestions for other tools). Tools such as these are the next set of pieces that I'll be working on. For example if I'm running a specific browser within a sandbox (Firejail seemed like a good candidate for this but there's issues I'm still debugging for ARMhf) in addition to other mentioned tools and I then run Metasploit+BEef against it I want to be able to profile the damage that can be done when each layer is complete and have a set of reports that can be shared with developers. The reference to clearnet vers non would be that the information or puzzle peaces used to put this together are all there published online and unhidden by anonymouzing networks, ie literacy plus time and a browser and the same can be put together for a specific purpose.

On the subject of injection attacks; I'm all ears on how best to add mitigation or protection against local and remote attacks. For some of the local networking I've been trying to monitor for "good-by" packets from "routers" I've setup to assume the same MAC & BSSID but without doing some auto-magics with rotating these identifiers on both router and attached clients I don't see an easier way of preventing local/drive-by MiTM attacks. For the remote attacks I've no direction of research just yet opened other than being cautious about browsing and clicking as well as using a few plugins for not loading content from the same domain kinds of things. Some of the options I've come across for local proxy filtering looks promising but only against known malware venders, much like running a custom hosts file.

On January 21, 2016 12:59:09 PM PST, David Stainton <dstainton415 at gmail.com> wrote:
>Firstly, I don't think my questions "deserved" such a long reply and
>it is not my preference to have such a broad spattering of
>conversation topics... but you started it and so I have tried to reply
>to your various points.
>
>The take-away i get from all of that is that you really like bash and
>don't have much experience with other programming languages; which is
>fine... you have to start somewhere. But I think Python would be a
>saner place to start... computer programming. I often recommend it to
>people who have zero experience programming... and they pick it up and
>learn good habits... such as writing unit tests.
>
>IMHO bash is better for shorter smaller simpler things because it is
>not so easily maintainable and has no exception handling (set -e
>doesn't count).
>
>You are not correct about bcfg2. It's written in python and therefore
>it of course runs on whatever ARM platform. I don't know what bcfg2
>encap is... but it sounds like an irrelevant boot strapping mechanism
>whose packages are no longer maintained... so just forget you saw
>that. ;-0
>
>I don't know what you mean by "reverse ssh terminal to a ~.onion" but
>perhaps you meant to comment on the NAT penetration property of onion
>services?
>
>"While it may seem dangerous to pack Metasploit with Tor" um what? i
>don't know what you mean. And by clearnet I suppose you mean
>non-cryptographic protocols like http. This isn't ever really safe in
>light of the TCP injection attacks that can be used to insert
>malicious data into your TCP stream in order to compromise the client
>and/or server.
>
>
>Sincerely,
>David
>
>On Thu, Jan 21, 2016 at 8:17 AM, Michael <strangerthanbland at gmail.com>
>wrote:
>> 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 at gmail.com>
>> 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 at gmail.com>
>>> 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 at gmail.com>
>wrote:
>>>>>
>>>>> On 1/19/16, Michael <strangerthanbland at gmail.com> 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 at lists.torproject.org
>>>>  To unsubscribe or change other settings go to
>>>>  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>>>
>>> --
>>> tor-talk mailing list - tor-talk at lists.torproject.org
>>> To unsubscribe or change other settings go to
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk