Hello all, So as some of you know, I've been working on installers for hidden services, to ideally make very common services (such as blogs and plain websites) easy to deploy and automatically update. This is a very rough version of the one-click hidden service installer, but I'd love to get feedback on places where it breaks and where it could use a major structural change. Script is here, please feel free to flag bugs or tell me how I'm doing it wrong: https://github.com/glamrock/Stormy/blob/master/one-click-blog.sh Q: Can I use this right now to set up a hidden service? A: Please don't use this in production until firewall settings are in place. Q: Are there firewall settings in place? A: Not yet - the current setup is entirely for development and should not be used as-is. best, Griffin -- "I believe that usability is a security concern; systems that do not pay close attention to the human interaction factors involved risk failing to provide security by failing to attract users." ~Len Sassaman
On Mon, 17 Nov 2014, Griffin Boyce wrote:
Hello all,
So as some of you know, I've been working on installers for hidden services, to ideally make very common services (such as blogs and plain websites) easy to deploy and automatically update. This is a very rough version of the one-click hidden service installer, but I'd love to get feedback on places where it breaks and where it could use a major structural change.
Here is an idea for a major structural change. That's probably too much changes if you're planning to have a first version soon, but maybe for a future 2.0 version if this change looks like a good idea. After looking at the scripts, it looks quite similar to configuration that is usually done with tools such as ansible, puppet, saltstack, etc ... So I am thinking that an other way to do it could be to write a few ansible modules (or modules for your favorite configuration management tool) for the various tasks currently done by the script (installing nginx, installing a blog software, setup a hidden service, configure the firewall, etc ...), or take existing modules if they do what is needed. Then write a GUI program that will ask some questions, and when you click on the "setup" button generate an ansible variables file containing the answers to those questions (variables which are used by the ansible modules), and run ansible to apply the changes on the system. Normal users would only use the GUI and click "setup", but expert users would be able to take the modules and include them in their own ansible setup without the GUI.
Hi! I think it's non-ideal to modify config files using cat/sed/echo. That breaks sooner or later. And if later settings are supposed to be changed in the same file, things get messy. Some suggestions... It would be better to put the config files into (debian) packages. Want to disable popcon? Have some package that ships a config file that disables it. What if an existing package owns that config file? Use config-package-dev's [1] displace feature. Or have a package that conflicts/replaces popcon. Then have packages such as hidden-service-wordpress depend on popcon-disable package. Please consider to set timezone to UTC. Perhaps use the timezone-utc [2] package? What about disabling tcp timestamps? Perhaps use tcp-timestamps-disable for [3] that? There is some more functionality that might be useful. List: [4] You're sure you're not inventing a new linux distribution here? :) Cheers, Patrick [1] http://debathena.mit.edu/config-packages/ [2] https://github.com/Whonix/timezone-utc [3] https://github.com/Whonix/tcp-timestamps-disable [4] https://github.com/Whonix
On 11/17/14 10:33 AM, Griffin Boyce wrote:
Q: Can I use this right now to set up a hidden service? A: Please don't use this in production until firewall settings are in place.
I would suggest to add a Tor2web policy that, looking at X-Tor2web: HTTP header, enable or disable access to the Blog trough he internet: You may also consider adding support for Ahmia directory index, by publishing/announcing the blog to the Ahmia directory automatically with a TorHS descriptor (GlobaLeaks do it): https://ahmia.fi/documentation/descriptionProposal/ In the upcoming future, when Tor2web will support configurable policy for caching and crawling, you may wish to "govern" how Tor2web should behave within the respect to such TorHS: https://github.com/globaleaks/Tor2web-3.0/issues/29 In such one-click-hidden-service probably some Tor2web concrete improvements with some dedicated effort would be very useful (currently it's volunteer / residual use of OTF/GlobaLeaks's funding for ongoing small step improvements). -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi
Hey all, Sorry for the delay in responding -- comments inline. Fabio Pietrosanti - lists wrote:
I would suggest to add a Tor2web policy that, looking at X-Tor2web: HTTP header, enable or disable access to the Blog trough he internet:
What is your reasoning for disabling access via tor2web?
You may also consider adding support for Ahmia directory index
This seems reasonable =) Added as a task. Nicolas Vigier wrote:
So I am thinking that an other way to do it could be to write a few ansible modules (or modules for your favorite configuration management tool) for the various tasks currently done by the script (installing nginx, installing a blog software, setup a hidden service, configure the firewall, etc ...), or take existing modules if they do what is needed.
I've been considering creating ansible modules to make it easier to deploy for some people. An organization reached out who wants to offer it in-house as some kind of enterprise service, which has reignited the discussion.
Then write a GUI program that will ask some questions, and when you click on the "setup" button generate an ansible variables file containing the answers to those questions (variables which are used by the ansible modules), and run ansible to apply the changes on the system.
Lots of people would like a GUI, which would make it much easier to deploy, but I always recommend that people segregate their hidden services (and websites) from their personal machine. I might be slowly changing my mind on GUIs for a number of reasons. It's still not a good idea to run on one's personal machine if there is a large risk associated with being personally linked to running a particular hidden service (eg, Muslims in Myanmar should host in a VM or a dedicated machine). But this may be a case where more users would be better served by having a gui than the fairly mild risk of someone running a service on their personal machine. And a GUI would be great for people who want to run a hidden service using Tails. =) Patrick Schleizer wrote:
I think it's non-ideal to modify config files using cat/sed/echo. That breaks sooner or later. And if later settings are supposed to be changed in the same file, things get messy. Some suggestions...
It would be better to put the config files into (debian) packages.
While this is true for popcon, this is not possible for most config files being edited. The most critical edits require the onionsite address, which of course has to be generated by each user on their own. It's possible for debian and ubuntu packages to list package conflicts, which would be much better than rolling up custom packages that only exist to remove another.
Please consider to set timezone to UTC. Perhaps use the timezone-utc [2] package?
Tor requires an accurate clock to work properly.
You're sure you're not inventing a new linux distribution here? :)
Quite sure ;-) There's a real risk in trying to be everything to everyone. Not only does everything have to be created and documented, but maintained long-term. Bash scripts are straightforward for these tasks, as is ansible, VMs much less so, and GUIs very difficult. best, Griffin -- "The apparent safety of modern life is just a shallow skin atop an ocean of blood, guts and bricked devices." ~Pearce Delphin
So I am thinking that an other way to do it could be to write a few ansible modules (or modules for your favorite configuration management tool) for the various tasks currently done by the script (installing nginx, installing a blog software, setup a hidden service, configure the firewall, etc ...), or take existing modules if they do what is needed.
I've been considering creating ansible modules to make it easier to deploy for some people. An organization reached out who wants to offer it in-house as some kind of enterprise service, which has reignited the discussion.
if interested in deploying tor or tor hidden services with ansible then take a look at this: https://github.com/david415/ansible-tor ...but if you simply want to make it easier for people to deploy hidden services on their workstation/laptop then you might consider using the Tor control port to do so: https://lists.torproject.org/pipermail/tor-dev/2014-November/007821.html cheers, david
participants (5)
-
David Stainton -
Fabio Pietrosanti - lists -
Griffin Boyce -
Nicolas Vigier -
Patrick Schleizer