| 1 |
On 11 December 2011 06:53, Alex Efros <powerman@××××××××.name> wrote: |
| 2 |
> On Sun, Dec 11, 2011 at 02:25:19PM +0000, Sven Vermeulen wrote: |
| 3 |
>> > 1) How can |
| 4 |
>> > 4.2.4.1. Root Logon Through SSH Is Not Allowed |
| 5 |
>> > increase security, if we're already using |
| 6 |
>> > 4.2.4.2. Public Key Authentication Only |
| 7 |
>> > Disabling root may have sense with password auth, but with keys it is |
| 8 |
>> > just useless inconvenience. |
| 9 |
>> |
| 10 |
>> I read somewhere that security is about making things more inconvenient for |
| 11 |
>> malicious people than for authorized ones. |
| 12 |
>> |
| 13 |
>> For me, immediately logging in as root is not done. I want to limit root |
| 14 |
>> access through the regular accounts on the system (with su(do)). I never had |
| 15 |
>> the need to log on as root immediately myself. |
| 16 |
> |
| 17 |
> Understood. But I still don't see how this can increase security. |
| 18 |
|
| 19 |
It is my understanding this is not so much about security per se as it |
| 20 |
is about auditing. Especially in an environment with more than one |
| 21 |
admin. |
| 22 |
|
| 23 |
Let's say there are two admins (A and B) who both log on (remotely) as |
| 24 |
root. Then there is no easy way to tell who did what. Leaving an audit |
| 25 |
trail is useful and in many environments simply required. |
| 26 |
|
| 27 |
Moreover, if admin A's account is compromised then a black hat can use |
| 28 |
admin A's access to root to remotely log on to any machine admin A has |
| 29 |
access to. This will be hard to detect and it will be hard(er) to |
| 30 |
determine how the black hat gained access. If admin A had logged on as |
| 31 |
admin A instead of root then it would be more obvious it was admin A's |
| 32 |
account that had been compromised. |
Archives