sainslie
commented
8 years ago Open sainslie opened 8 years ago
sainslie
commented
8 years ago 
alecmuffett
commented
8 years ago That is an interesting idea, but I do not see the benefit. Perhaps you can explain it to me?
There is also the matter that I am trying to create a "secure basic platform" rather than dictate to people who use it regarding how they perform systems administration; to that end I would like to defer editorialising about how to get updates, or one update source being better than another, to other documents which can build upon this basic recipe.
Similarly SSH - the approach that I am taking is to flatly ban incoming connections, and leave it to the user's discretion as to how they selectively re-enable access; they may wish, for instance, to configure SSH to listen on one of the "virtual onion" interfaces and accept only traffic forwarded from the tor daemon to that interface.
So the goal of this document is to make a machine which people largely have to enable functionality, rather than frustratedly "undo" a configuration step which it has specified should be done.
alecmuffett
commented
8 years ago be aware this document is the first in a possible series, the subsequent documents planned to be written along the lines of: "first build a basic onion platform [this document] & then install {webserver, wordpress, etc...} and configure as follows ..."
it's like cooking: the same basic sauce which you then add different flavours to.
sainslie
commented
8 years ago I feel that it's better that all egress traffic is routed in such a manner that it doesn't utilize direct connections to the repositories and permit for potential location of the server. It just isn't going to happen if routing it through @torproject. It also doesn't permit third parties to interpret the packages being installed.
I agree that users should decide upon access methods in regard to @openssh but that being said I still consider it useful to at least consider different options for managing access; perhaps it's useful just to mention it as a potential suggestion instead rather than outright dictate configurations?
I guess perhaps I'm interpreting it from an outright counter-forensic standpoint rather than for commonplace practices but the point is that these computers just aren't meant to disclose their location at all or the platform it's built upon. I feel it's at least important to lessen the potential of that happening through forensic investigation, malice or misconfiguration.
alecmuffett
commented
8 years ago I feel that it's better that all egress traffic is routed in such a manner that it doesn't utilize direct connections to the repositories and permit for potential location of the server.
That's fair, and I have a Optional TODO item which leans in that direction for updates, but - back to the mixed-up food analogies - this is like making a roux from which we shall make any number of other sauces. I don't want to add some strong systems-administration flavour like Tarragon / "OF COURSE YOU MEAN THIS BOX TO MAKE OUTGOING CONNECTIONS UNDER CLIENT CONTROL" / "OF COURSE YOU ARE TRYING TO BE ANONYMOUS" - and thereby skew any future practical deployment.
eg: Facebook & ProPublica are both running Onions now, and are not at threat of deanon because deanon is simply not a thing for them, especially not from the perspective of an ISP, Nation-State Actor, nor Canonical, Inc.
Incidentally, are you suggesting that Canonical are blocking access to software updates from Tor exit nodes? If that is true, I did not know that and it should be more widely publicised.
SSH and other listeners are protected from casual scanning by the "ufw firewall condom" installation towards the bottom of the document, and the daemon is currently listening promiscuously to all internal interfaces. I intend to document setting up a machine with 2+ onions to have one for "public" use and another for admin access on an arbitrary and ephemeral port number (remapped to 22 on arrival at the tor daemon locally) which will have an option for screwing that down.
Between UFW and "not configuring a onion port that connects to 22 locally", though, it's currently really hard to get any traffic into port 22 at all. Which is the intention.
alecmuffett
commented
8 years ago etckeeper for managing change...more? Would love to do UUCP :-P
alexhaydock
commented
8 years ago This is a very useful set of tutorials - many thanks for the hard work!
I like the idea of using the RFC2606 non-routable .invalid TLD for the hostname. It seems like a great idea, although after reading through the document I'm still a little unclear on whether there is a specific attack scenario that this is addressing, or whether it's a "just in case" addition. I have been working under the impression that internal hostnames were only really exposed during DHCP requests, though I am now wondering if I've been missing something.
Incidentally, are you suggesting that Canonical are blocking access to software updates from Tor exit nodes? If that is true, I did not know that and it should be more widely publicised.
To weigh in on this though, I have been using apt-transport-tor on multiple Ubuntu systems for some time now and this (fortunately) doesn't seem to be the case. I can at least confirm that the GB, DE and NL mirrors for archive.ubuntu.com and the security.ubuntu.com server don't seem to block Tor exits at all. I think perhaps @sainslie's reference was to the fact that there do not seem to be any onion services providing Ubuntu updates.
That is an interesting idea, but I do not see the benefit. Perhaps you can explain it to me?
I definitely agree with it's probably a good idea not to be dictating user choices too harshly with your basic "recipe", but I think there's more to the suggestion of updating a system via Tor than simply to prevent potential location of the server.
Most notably for a server hosting a critical service, if the target can be observed directly downloading a security update for a particular package, an adversary can make a reasonable assumption that the target is currently running the older (potentially vulnerable) version of the package, and may be able to mount an attack before the download and installation of the security update has completed. (This, I think becomes particularly concerning when security updates are helpfully-pinpointed by the domain being named security.ubuntu.com, which doesn't appear to support HTTPS.)
sainslie
commented
8 years ago @ajhaydock @alecmuffett Yes. I just thought I'd point out that @ubuntu hasn't got repositories permitting updating packages through just @torproject itself. Its parent distribution does but not @ubuntu itself. I do hope @ubuntu does something about it and considers addressing the @launchpad bug report to fix it outright. apt-transport-tor does a good job in the meantime.
I'd argue that it is beneficial for its inclusion but also in hindsight I understand not dictating exacting setups as @alecmuffett suggests. I did stress that I approached it from an outright anti-forensics standpoint but I do understand that it might be much less usable and inflexible in doing so; at least in regard to regular maintenance.
alecmuffett
commented
8 years ago After all the discussion of this on Twitter, I am minded to finish off the document by leaving the firewall in an open-outbound state for automatic software updates and tor, and then push discussion of this sort of thing to the "configuring for anonymity" document.
There are a bunch of pros-and-cons; performing software updates over Tor to non-HTTPS sites would both be against Tor's general advice (use only HTTPS over Tor) and also put users at risk of bugs like this[1] if ever a code-signing key leaks, or else if Debian/Ubuntu signature-checks get silently broken. That is even/especially with use of apt-transport-tor
It would break the "no editorialising" rule to force people reading this document to use some arbitrary third-party HTTPS or Onion repo.
So, we'll keep the recipe light, and let the readers pick what to do next, and try to help them in subsequent documents.
[1] http://www.leviathansecurity.com/blog/the-case-of-the-modified-binaries
If an @ubuntu server is fetching updates through APT I'd suggest it should fetch it from across @torproject. @wikimedia has dedicated repositories accessible through @torproject though I'm curious if this is better than fetching updates through a local network interface from a local cache; @linode caches remote repositories on their data center servers. I guess this depends upon if a user has physical access or not to the server.