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

[David Stainton <dstainton415@xxxxxxxxx>]

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@xxxxxxxxx> 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@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