bzr branch
http://bzr.recompile.se/loggerhead/mandos/release
152
by Teddy Hogeborn
* README: New file. |
1 |
-*- org -*- |
2 |
||
3 |
* Mandos |
|
4 |
- Have your cake and eat it too! |
|
5 |
|
|
183
by Teddy Hogeborn
* Makefile (install-client-nokey): Do "&&" instead of ";" to catch |
6 |
You know how it is. You’ve heard of it happening. The Man comes |
7 |
and takes away your servers, your friends’ servers, the servers of |
|
152
by Teddy Hogeborn
* README: New file. |
8 |
everybody in the same hosting facility. The servers of their |
183
by Teddy Hogeborn
* Makefile (install-client-nokey): Do "&&" instead of ";" to catch |
9 |
neighbors, and their neighbors’ friends. The servers of people who |
10 |
owe them money. And like *that*, they’re gone. And you doubt |
|
11 |
you’ll ever see them again. |
|
152
by Teddy Hogeborn
* README: New file. |
12 |
|
13 |
That is why your servers have encrypted root file systems. However, |
|
183
by Teddy Hogeborn
* Makefile (install-client-nokey): Do "&&" instead of ";" to catch |
14 |
there’s a downside. There’s no going around it: rebooting is a |
152
by Teddy Hogeborn
* README: New file. |
15 |
pain. Dragging out that rarely-used keyboard and screen and |
16 |
unraveling cables behind your servers to plug them in to type in |
|
17 |
that password is messy, especially if you have many servers. There |
|
18 |
are some people who do clever things like using serial line consoles |
|
19 |
and daisy-chain it to the next server, and keep all the servers |
|
20 |
connected in a ring with serial cables, which will work, if your |
|
21 |
servers are physically close enough. There are also other |
|
22 |
out-of-band management solutions, but with *all* these, you still |
|
23 |
have to be on hand and manually type in the password at boot time. |
|
24 |
Otherwise the server just sits there, waiting for a password. |
|
25 |
|
|
183
by Teddy Hogeborn
* Makefile (install-client-nokey): Do "&&" instead of ";" to catch |
26 |
Wouldn’t it be great if you could have the security of encrypted |
152
by Teddy Hogeborn
* README: New file. |
27 |
root file systems and still have servers that could boot up |
28 |
automatically if there was a short power outage while you were |
|
29 |
asleep? That you could reboot at will, without having someone run |
|
30 |
over to the server to type in the password? |
|
31 |
|
|
32 |
Well, with Mandos, you (almost) can! The gain in convenience will |
|
33 |
only be offset by a small loss in security. The setup is as |
|
34 |
follows: |
|
35 |
|
|
36 |
The server will still have its encrypted root file system. The |
|
37 |
password to this file system will be stored on another computer |
|
38 |
(henceforth known as the Mandos server) on the same local network. |
|
39 |
The password will *not* be stored in plaintext, but encrypted with |
|
40 |
OpenPGP. To decrypt this password, a key is needed. This key (the |
|
41 |
Mandos client key) will not be stored there, but back on the |
|
42 |
original server (henceforth known as the Mandos client) in the |
|
43 |
initial RAM disk image. Oh, and all network Mandos client/server |
|
44 |
communications will be encrypted, using TLS (SSL). |
|
45 |
|
|
46 |
So, at boot time, the Mandos client will ask for its encrypted data |
|
47 |
over the network, decrypt it to get the password, use it to decrypt |
|
48 |
the root file, and continue booting. |
|
49 |
|
|
50 |
Now, of course the initial RAM disk image is not on the encrypted |
|
154
by Teddy Hogeborn
* README: Improved spelling. |
51 |
root file system, so anyone who had physical access could take the |
185
by Teddy Hogeborn
* .bzr-builddeb/default.conf: New. |
52 |
Mandos client computer offline and read the disk with their own |
53 |
tools to get the authentication keys used by a client. *But*, by |
|
54 |
then the Mandos server should notice that the original server has |
|
55 |
been offline for too long, and will no longer give out the encrypted |
|
56 |
key. The timing here is the only real weak point, and the method, |
|
57 |
frequency and timeout of the server’s checking can be adjusted to |
|
58 |
any desired level of paranoia |
|
152
by Teddy Hogeborn
* README: New file. |
59 |
|
60 |
(The encrypted keys on the Mandos server is on its normal file |
|
153
by Teddy Hogeborn
* README: Improved wording. |
61 |
system, so those are safe, provided the root file system of *that* |
152
by Teddy Hogeborn
* README: New file. |
62 |
server is encrypted.) |
63 |
||
64 |
* FAQ - couldn’t the security be defeated by... |
|
65 |
||
66 |
** Grabbing the Mandos client key from the initrd *really quickly*? |
|
67 |
This, as mentioned above, is the only real weak point. But if you |
|
68 |
set the timing values tight enough, this will be really difficult |
|
69 |
to do. An attacker would have to physically disassemble the client |
|
70 |
computer, extract the key from the initial RAM disk image, and then |
|
71 |
connect to a *still online* Mandos server to get the encrypted key, |
|
185
by Teddy Hogeborn
* .bzr-builddeb/default.conf: New. |
72 |
and do all this *before* the Mandos server timeout kicks in and the |
73 |
Mandos server refuses to give out the key to anyone. |
|
152
by Teddy Hogeborn
* README: New file. |
74 |
|
185
by Teddy Hogeborn
* .bzr-builddeb/default.conf: New. |
75 |
Now, as the typical procedure seems to be to barge in and turn off |
76 |
and grab *all* computers, to maybe look at them months later, this |
|
77 |
is not likely. If someone does that, the whole system *will* lock |
|
153
by Teddy Hogeborn
* README: Improved wording. |
78 |
itself up completely, since Mandos servers are no longer running. |
79 |
|
|
160
by Teddy Hogeborn
* Makefile: Changed to use symbolic instead of octal modes throughout. |
80 |
For sophisticated attackers who *could* do the clever thing, *and* |
81 |
had physical access to the server for enough time, it would be |
|
82 |
simpler to get a key for an encrypted file system by using hardware |
|
83 |
memory scanners and reading it right off the memory bus. |
|
152
by Teddy Hogeborn
* README: New file. |
84 |
|
85 |
** Replay attacks? |
|
86 |
Nope, the network stuff is all done over TLS, which provides |
|
87 |
protection against that. |
|
88 |
||
89 |
** Man-in-the-middle? |
|
90 |
No. The server only gives out the passwords to clients which have |
|
91 |
*in the TLS handshake* proven that they do indeed hold the OpenPGP |
|
92 |
private key corresponding to that client. |
|
93 |
||
94 |
** Physically grabbing the Mandos server computer? |
|
95 |
You could protect *that* computer the old-fashioned way, with a |
|
96 |
must-type-in-the-password-at-boot method. Or you could have two |
|
153
by Teddy Hogeborn
* README: Improved wording. |
97 |
computers be the Mandos server for each other. |
98 |
|
|
99 |
Multiple Mandos servers can coexist on a network without any |
|
100 |
trouble. They do not clash, and clients will try all available |
|
101 |
servers. This means that if just one reboots then the other can |
|
102 |
bring it back up, but if both reboots at the same time they will |
|
103 |
stay down until someone types in the password on one of them. |
|
152
by Teddy Hogeborn
* README: New file. |
104 |
|
105 |
** Faking ping replies? |
|
106 |
The default for the server is to use "fping", the replies to which |
|
107 |
could be faked to eliminate the timeout. But this could easily be |
|
108 |
changed to any shell command, with any security measures you like. |
|
109 |
It could, for instance, be changed to an SSH command with strict |
|
110 |
keychecking, which could not be faked. Or IPsec could be used for |
|
111 |
the ping packets, making them secure. |
|
112 |
||
113 |
* Security Summary |
|
114 |
So, in summary: The only weakness in the Mandos system is from |
|
115 |
people who have: |
|
153
by Teddy Hogeborn
* README: Improved wording. |
116 |
1. The power to come in and physically take your servers, *and* |
152
by Teddy Hogeborn
* README: New file. |
117 |
2. The cunning and patience to do it carefully, one at a time, and |
118 |
*quickly*, faking Mandos client/server responses for each one |
|
119 |
before the timeout. |
|
120 |
|
|
121 |
While there are some who may be threatened by people who have *both* |
|
122 |
these attributes, they do not, probably, constitute the majority. |
|
123 |
|
|
124 |
If you *do* face such opponents, you must figure that they could |
|
153
by Teddy Hogeborn
* README: Improved wording. |
125 |
just as well open your servers and read the file system keys right |
126 |
off the memory by running wires to the memory bus. |
|
152
by Teddy Hogeborn
* README: New file. |
127 |
|
155
by Teddy Hogeborn
* README: Improved wording. |
128 |
What Mandos is designed to protect against is *not* such determined, |
129 |
focused, and competent attacks, but against the early morning knock |
|
130 |
on your door and the sudden absence of all the servers in your |
|
131 |
server room. Which it does nicely. |
|
183
by Teddy Hogeborn
* Makefile (install-client-nokey): Do "&&" instead of ";" to catch |
132 |
|
133 |
* Copyright |
|
134 |
||
185
by Teddy Hogeborn
* .bzr-builddeb/default.conf: New. |
135 |
Copyright © 2008 Teddy Hogeborn |
136 |
2008 Björn Påhlsson |
|
137 |
|
|
183
by Teddy Hogeborn
* Makefile (install-client-nokey): Do "&&" instead of ";" to catch |
138 |
** License: |
185
by Teddy Hogeborn
* .bzr-builddeb/default.conf: New. |
139 |
|
183
by Teddy Hogeborn
* Makefile (install-client-nokey): Do "&&" instead of ";" to catch |
140 |
This program is free software: you can redistribute it and/or |
141 |
modify it under the terms of the GNU General Public License as |
|
142 |
published by the Free Software Foundation, either version 3 of the |
|
143 |
License, or (at your option) any later version. |
|
144 |
||
145 |
This program is distributed in the hope that it will be useful, but |
|
146 |
WITHOUT ANY WARRANTY; without even the implied warranty of |
|
147 |
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
|
148 |
General Public License for more details. |
|
149 |
||
150 |
You should have received a copy of the GNU General Public License |
|
151 |
along with this program. If not, see |
|
152 |
<http://www.gnu.org/licenses/>. |