1 |
On 10/11/2015 17:58, Michael Orlitzky wrote: |
2 |
> On 11/10/2015 10:30 AM, Alan McKinnon wrote: |
3 |
>>> Maybe, but your argument isn't convincing. How am I better off doing it |
4 |
>>> your way (what is your way)? |
5 |
>> |
6 |
>> The most common way is to disallow all remote logins as root. Admins log |
7 |
>> in with their personal unpriv account using an ssh key. To become root |
8 |
>> they must su or sudo -i with a password. |
9 |
>> |
10 |
>> Benefits: two factor auth using different mechanisms. Having the key or |
11 |
>> the password is not enough to become root, an attacker must have both. |
12 |
>> |
13 |
>> Allowing root logins directly over the network is considered bad |
14 |
>> practice, due to the "one mistake = you lose" aspect. |
15 |
>> |
16 |
> |
17 |
> It sounds good, but what sort of attack on my root password does the |
18 |
> two-factor authentication prevent? Assume that I'm not an idiot and to |
19 |
> brute-force my root password would take literally forever. |
20 |
> |
21 |
> I'm weighing this against the complexity of adding separate accounts, |
22 |
> making sure that *those* are secure, risking breakage of the sudoers |
23 |
> file, granting someone the ability to brute force my SSH key password |
24 |
> offline,... |
25 |
> |
26 |
> All of the good attacks (shoot me, bribe me, steal the hardware, etc.) |
27 |
> that I can think of work just fine against the two-factor auth. The only |
28 |
> other way to get the root password is to be there when I transfer it |
29 |
> from my brain to the terminal, in which case you have the SSH key, too. |
30 |
|
31 |
I think you are approaching this problem from the wrong viewpoint. You |
32 |
have to assume an attacker has vastly more resources to bear on the |
33 |
problem than you have. Thanks to Amazon and the cloud, this is now a |
34 |
very true reality. Brute force attacking a root password is nowhere near |
35 |
as complex as the maths would lead you to believe; for one thing they |
36 |
are decidedly not random. The fact is that they are heavily biased, |
37 |
mostly due to 1) you need to be able to remember it and 2) you need to |
38 |
be able to type it. |
39 |
|
40 |
Humans have been proven to be very bad at coming up with passwords that |
41 |
are truly good[1] and hard for computers to figure out. And our brains |
42 |
and very very VERY good at convincing us that our latest dumb idea is |
43 |
awesome. Are you really going to protect the mother lode (root password) |
44 |
with a single system proven to be quite broken and deeply flawed by wetware? |
45 |
|
46 |
Two factor auth is cheap (ssh-keygen and ssh-copy-id) and keys take the |
47 |
human factor out of the first step. It's not security theatre nor cargo |
48 |
culting, so why not use it and gain the benefits for minimal effort? |
49 |
|
50 |
Complexity of separate accounts is a bit of a red herring. If your user |
51 |
account is weak, I have to assume so is your root account - apart from |
52 |
UID=0 there is no difference between them. Hopefully you use Puppet or |
53 |
friends so you set up a decent template once and the system ensures it |
54 |
stays that way. No having to check if user accounts really are still not |
55 |
weak. |
56 |
|
57 |
Finally the root password by it's nature is a shared secret between one |
58 |
or more admins. On every system a boss has had me look after, I have |
59 |
shown to my own satisfaction that it is the weak link. It has to exist, |
60 |
it has to be known an it has to be communicated when it changes. Systems |
61 |
designed to help make that process safe are themselves weak (such as a |
62 |
GPG encrypted file protected by .... a never-changing shared password |
63 |
that every admin knows!) Am I going to build a front line of defence |
64 |
based on ssh keys? You betcha. |
65 |
|
66 |
Alan |
67 |
|
68 |
[1] Our bosses and auditors keep coming up with stupid ideas designed to |
69 |
improve this but all they succeed in doing is causing the problem they |
70 |
seek to solve. Such as rotating passwords, insisting on punctuation, no |
71 |
repeating characters. In the real world all this does is invite *bad* |
72 |
practices - people have to resort to this to get something that |
73 |
satisfies the password policy and they can remember. And from there it's |
74 |
a short step to Post-It-Note syndrome |
75 |
|
76 |
|
77 |
-- |
78 |
Alan McKinnon |
79 |
alan.mckinnon@×××××.com |