[In reverse chronological order.]
Date: Sun, 11 Aug 2013 08:55:42 -0700
From: Andy Isaacson <adi[at]hexapodia.org>
To: cypherpunks[at]cpunks.org
Subject: Re: Lavabit and End-point Security
On Sun, Aug 11, 2013 at 10:39:55AM -0400, Sean Alexandre wrote [full email not received]:
> your more typical sys admin could find
> and use. They might not have everything, but enough to make their services
> 99.99% secure. Those that provide the info would probably still have some
> things to their own and be 99.9999% secure.
Security doesn’t work that way. Keeping your system secure is like walking a tightrope across a gorge filled with ravenous tigers every morning. There are a billion ways to fuck up and get owned/eaten by the tigers, and asking someone who’s successfully walked the tightrope every day for 40 years “tell me your secret?” completely misses the point.
The expert can share advice and point out when you’re about to step off the tightrope, but no kind of advice can substitute for your own caution and experience. Pretending that a magic balance bar, or a magic technique that can be applied without careful thought, or a magic shoe that will make you stick to the rope, will save you is the kind of thing that works in a fairy tale but not in real life.
The analogy breaks down, though, because in fact you can get totally owned, through and through; exfiltrated, impersonated, and strung up by a prosecutor before a secret grand jury before you even learn that your security has failed. At least the tiger has the courtesy of giving you pain when you fail.
-andy
Date: Sun, 11 Aug 2013 05:45:02 -0700
Subject: Re: Lavabit and End-point Security
From: coderman <coderman[at]gmail.com>
To: cypherpunks[at]cpunks.org
some questions, some answers, …
On Sun, Aug 11, 2013 at 2:27 AM, coderman <coderman[at]gmail.com> wrote:
> …
> 1. use a common distro, but rebuild critical components – bootloader,
> initramfs, openssl, openssh, the kernel, gnutls, libgmp, use 64bit,
> etc.
this means rebuild hardened versions of these libraries from source; excluding insecure cipher suites in an OpenSSL build for example, altering architecture optimizations, supported features, in others, the goal being that an exploit targeted to a vanilla distribution will more likely fail with observable error or crash, rather than succeed silently.
many exploits are very brittle in this respect, with any change in symbol offsets or capabilities rendering them completely ineffective.
> 2. use isolation and RBAC, Qubes, VirtualBox, VMWare, Parallels,
> remember that VM escapes are available and expected. defense in depth
> can never be too deep.
virtualization implies chained exploits for full compromise. combined with the above you’ve drastically increased the cost of a successful attack with modest effort. the likelihood of detection (by appearing vulnerable yet not being so) is also increased.
remember that VMMs and hypervisors are themselves potentially vulnerable software systems suitable for hardening and customization.
> 3. use constrained network access – identify anomalies, control
> bandwidth, firewall ingress and egress aggressively. this implies
> constant monitoring to detect such events. (another exercise left to
> the reader)
data exfiltration can be very visible via network behavior if you’re paying attention. cross referencing connection state in your upstream router vs. local OS view of sockets can identify discrepancies where compromise has concealed covert connections. malware communicating directly on an ethernet or wireless adapter outside of the OS is also visible at this junction.
> 4. rootkit and backdoor your own systems – use the dirty tricks to
> observe and constrain your system before someone else uses dirty
> tricks to compromise your system.
this is mostly a variant of #1 at a kernel / system level. like notepad.exe connecting to the internet, there are some syscall, file access, and network requests which are clearly anomalous and indicators of compromise.
> 5. don’t forget physical security – this is the universal oversight
> and most effective end run around all other operational and technical
> security measures. there is a reason physical access so often implies
> “game over” and why black bag jobs are still and will continue to be
> effective against all targets.
this is a storied tangent unto itself…
last but not least: you must develop a routine of continuous hardening and improvement. these steps are not done once and finished; they are elements within a larger strategy of operational rigor defending against motivated and capable attackers. asking for my “hardened linux build” is missing the point entirely!
Date: Sun, 11 Aug 2013 06:51:32 -0400
Subject: Re: Lavabit and End-point Security
From: Steve Furlong <demonfighter[at]gmail.com>
To: coderman <coderman[at]gmail.com>
Cc: cypherpunks[at]cpunks.org
On Sun, Aug 11, 2013 at 5:27 AM, coderman <coderman[at]gmail.com> wrote:
if i were to summarize what i have found effective against dedicated
and resourceful attackers (again, i can’t go into details 🙂 this
would be the top 5:1. use a common distro, but rebuild critical components – bootloader, initramfs, openssl, openssh, the kernel, gnutls, libgmp, use 64bit, etc.
By “rebuild” do you mean compile it yourself or are you talking full-up review and rewrite? The former should be no problem for anyone capable of setting up a secure hosting service. The latter is probably beyond the means of small teams in any commercially reasonable timeframe.
—
Neca eos omnes. Deus suos agnoscet. — Arnaud-Amaury, 1209
Date: Sun, 11 Aug 2013 02:27:54 -0700
Subject: Re: Lavabit and End-point Security
From: coderman <coderman[at]gmail.com>
To: cypherpunks[at]cpunks.org
On Fri, Aug 9, 2013 at 7:43 AM, Sean Alexandre <sean[at]alexan.org> wrote:
> … this says Lavabit’s security was so good they
> couldn’t back door his machines….
>
> I’d love to see some kind of write-up by Ladar about how he did this…maybe
> even a book.
i’ve been contemplating a write up about this, but the problem is once you advertise your methods they become less effective.
there really is “security through obscurity” in this sense; when at a resource disadvantage, every little bit counts…
if i were to summarize what i have found effective against dedicated and resourceful attackers (again, i can’t go into details 🙂 this would be the top 5:
1. use a common distro, but rebuild critical components – bootloader, initramfs, openssl, openssh, the kernel, gnutls, libgmp, use 64bit, etc.
2. use isolation and RBAC, Qubes, VirtualBox, VMWare, Parallels, remember that VM escapes are available and expected. defense in depth can never be too deep.
3. use constrained network access – identify anomalies, control bandwidth, firewall ingress and egress aggressively. this implies constant monitoring to detect such events. (another exercise left to the reader)
4. rootkit and backdoor your own systems – use the dirty tricks to observe and constrain your system before someone else uses dirty tricks to compromise your system.
5. don’t forget physical security – this is the universal oversight and most effective end run around all other operational and technical security measures. there is a reason physical access so often implies “game over” and why black bag jobs are still and will continue to be effective against all targets.
Follow discussion thread: http://cpunks.org/pipermail/cypherpunks/
from here