|
||
|
11 August 2013 Lavabit and End-point Security Follow discussion thread: http://cpunks.org/pipermail/cypherpunks/
[In reverse chronological order.]
Date: Sun, 11 Aug 2013 08:55:42 -0700 On Sun, Aug 11, 2013 at 10:39:55AM -0400, Sean Alexandre wrote [full email not received]:
> your more typical sys admin could find 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 some questions, some answers, ... On Sun, Aug 11, 2013 at 2:27 AM, coderman <coderman[at]gmail.com> wrote:
> ... 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, 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 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 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 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 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 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 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 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.
|