Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Anthony G. Basile]

On 12/11/2011 03:08 PM, Kevin Chadwick wrote:
> On Sun, 11 Dec 2011 16:53:02 +0200
> Alex Efros wrote:
>
>> Hi!
>>
>> On Sun, Dec 11, 2011 at 02:25:19PM +0000, Sven Vermeulen wrote:
>>>> 1)  How can
>>>> 	4.2.4.1. Root Logon Through SSH Is Not Allowed
>>>>     increase security, if we're already using
>>>> 	4.2.4.2. Public Key Authentication Only
>>>>     Disabling root may have sense with password auth, but with keys it is
>>>>     just useless inconvenience.
>>>
>>> I read somewhere that security is about making things more inconvenient for
>>> malicious people than for authorized ones.
>>>
>>> For me, immediately logging in as root is not done. I want to limit root
>>> access through the regular accounts on the system (with su(do)). I never had
>>> the need to log on as root immediately myself.
>>
>> Understood. But I still don't see how this can increase security.
>>
>
> Defense in Depth, I disable root in >4 different ways.
>
> shell
> pam
> ssh_config
> securetty
> suid + setcap
> rbac
> chattr + immutable syscall turn off
>
> It may not help against root exploits but it makes life a little more
> difficult for priv escalation.
>
> It may take more work to iron out any diffciulties (short lived) but if
> you try to imagine the exploits rather than using minimal
> footprint/priviledges then you won't get that nice feeling of, hee hee
> doesn't affect me, nearly so often ;-). You'd be surprised, there's
> been lots of times where I've thought this is pointless and yet it's
> paid off eventually.
>

Do you have this documented anywhere.  It would be a good addition to
any system wide hardening docs we already have.

>
>>> 5)  In my experience, while
>>> 	4.8.5. Review File Integrity Regularly
>>>   looks like good idea, it's nearly impossible to use in Gentoo because
>>>    of daily updates which change a lot of system files, so it's too hard
>>>    to review aide-like tool reports and quickly detect suspicious file
>>>    changes. If anyone have a good recipe how to work around this I'll be
>>>    glad to learn it.
>
>
> The king of this for full pc (x86 etc.) is OpenBSD, though package
> updates are more work. I have NEVER had to upgrade the kernel on an
> OpenBSD system due to security problems. (Only because I had disabled
> ipv6 where it wasn't needed though, which re-affirms the above. I would
> guess you would have said disabling ipv6 where it is not needed to be
> just a hindrance and not anything to do with security and yet it
> accounts for one of the only remote exploits on OpenBSD at default in
> more than a decade and meant that I could leave my systems humming away,
> rather than getting hot and bothered). In fact some of them could have
> been left untouched untill now if it wasn't for the want to upgrade.
>
> Of course an attacker who modifies files isn't very good these
> days. Though they are the ones you may catch.
>
> p.s. There really should be a central linux kernel security problem
> site as the work of necessarily good people seems duplicated at the
> moment?
>

Gentoo is not the only system with lots of daily updates.  I used to use
tripwire on RedHat boxes years ago and it was tedious sifting through
the files changes.  To construct good rules about what triggered an
alert just shifted the tedium.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@g.o
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535