tldr
On Fri, Jan 22, 2016 at 1:16 AM, Michael <strangerthanbl...@gmail.com> wrote: > 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 <dstainton...@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 <strangerthanbl...@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 >><dstainton...@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 >><strangerthanbl...@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 <coder...@gmail.com> >>wrote: >>>>>> >>>>>> On 1/19/16, Michael <strangerthanbl...@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@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@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@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@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
