| 1 |
On Sun, 11 Dec 2011 16:53:02 +0200 |
| 2 |
Alex Efros wrote: |
| 3 |
|
| 4 |
> Hi! |
| 5 |
> |
| 6 |
> On Sun, Dec 11, 2011 at 02:25:19PM +0000, Sven Vermeulen wrote: |
| 7 |
> > > 1) How can |
| 8 |
> > > 4.2.4.1. Root Logon Through SSH Is Not Allowed |
| 9 |
> > > increase security, if we're already using |
| 10 |
> > > 4.2.4.2. Public Key Authentication Only |
| 11 |
> > > Disabling root may have sense with password auth, but with keys it is |
| 12 |
> > > just useless inconvenience. |
| 13 |
> > |
| 14 |
> > I read somewhere that security is about making things more inconvenient for |
| 15 |
> > malicious people than for authorized ones. |
| 16 |
> > |
| 17 |
> > For me, immediately logging in as root is not done. I want to limit root |
| 18 |
> > access through the regular accounts on the system (with su(do)). I never had |
| 19 |
> > the need to log on as root immediately myself. |
| 20 |
> |
| 21 |
> Understood. But I still don't see how this can increase security. |
| 22 |
> |
| 23 |
|
| 24 |
Defense in Depth, I disable root in >4 different ways. |
| 25 |
|
| 26 |
shell |
| 27 |
pam |
| 28 |
ssh_config |
| 29 |
securetty |
| 30 |
suid + setcap |
| 31 |
rbac |
| 32 |
chattr + immutable syscall turn off |
| 33 |
|
| 34 |
It may not help against root exploits but it makes life a little more |
| 35 |
difficult for priv escalation. |
| 36 |
|
| 37 |
It may take more work to iron out any diffciulties (short lived) but if |
| 38 |
you try to imagine the exploits rather than using minimal |
| 39 |
footprint/priviledges then you won't get that nice feeling of, hee hee |
| 40 |
doesn't affect me, nearly so often ;-). You'd be surprised, there's |
| 41 |
been lots of times where I've thought this is pointless and yet it's |
| 42 |
paid off eventually. |
| 43 |
|
| 44 |
|
| 45 |
>>5) In my experience, while |
| 46 |
>> 4.8.5. Review File Integrity Regularly |
| 47 |
>> looks like good idea, it's nearly impossible to use in Gentoo because |
| 48 |
>> of daily updates which change a lot of system files, so it's too hard |
| 49 |
>> to review aide-like tool reports and quickly detect suspicious file |
| 50 |
>> changes. If anyone have a good recipe how to work around this I'll be |
| 51 |
>> glad to learn it. |
| 52 |
|
| 53 |
|
| 54 |
The king of this for full pc (x86 etc.) is OpenBSD, though package |
| 55 |
updates are more work. I have NEVER had to upgrade the kernel on an |
| 56 |
OpenBSD system due to security problems. (Only because I had disabled |
| 57 |
ipv6 where it wasn't needed though, which re-affirms the above. I would |
| 58 |
guess you would have said disabling ipv6 where it is not needed to be |
| 59 |
just a hindrance and not anything to do with security and yet it |
| 60 |
accounts for one of the only remote exploits on OpenBSD at default in |
| 61 |
more than a decade and meant that I could leave my systems humming away, |
| 62 |
rather than getting hot and bothered). In fact some of them could have |
| 63 |
been left untouched untill now if it wasn't for the want to upgrade. |
| 64 |
|
| 65 |
Of course an attacker who modifies files isn't very good these |
| 66 |
days. Though they are the ones you may catch. |
| 67 |
|
| 68 |
p.s. There really should be a central linux kernel security problem |
| 69 |
site as the work of necessarily good people seems duplicated at the |
| 70 |
moment? |
Archives