Message-ID: <1079375614.2546.54.camel@coruscant.weisserth.net>
From: tobias at weisserth.de (Tobias Weisserth)
Subject: a secure base system

Hi there,

Am Mo, den 15.03.2004 schrieb harry um 12:37:
> hi all,
> 
> i have a little question. i'm asked to set up a base system, which has 
> to be secure. we want a system from which we can easily install a 
> compromised system. so i had a few ideas to make it as secure and yet as 
> usable as possible:
> 
> - use debian testing (stable is too old, unstable is ... well... you 
> know ;))

This is your first mistake. Take a look at www.debian.org and read the
remarks concerning releases. What does it say regarding unstable and
testing? Yes, there is no official support from the Debian security team
for those releases, meaning you'd have to patch buggy software and holes
yourself if you don't want to wait eternities.

If you want an up to date and modern productivity distribution with a
good security policy you mustn't use Debian but an alternative like
Fedora or SuSE or maybe Mandrake. I know this will raise flames en masse
from Debian fans. But it's a sour truth that Debian woody is hopefully
outdated and as long as the Debian security team doesn't support the
other releases it's no option at all to use these other releases in
productive environments.

> - /var and /tmp mounted nosuid and noexec

/tmp should always be mounted noexec. Add /home as well with noexec. Why
should users be able to install or run programs from within their home
directories anyway? Administered systems supply everything users need,
so there's no need to give them this freedom. This may be a trade-off,
but the result is more security.

> - grsec kernel
> - use lvm (so you don't need to worry about the sizes af the partitions)
> - remote logging to our logging server
> - all this in hardware raid 1 for easy transfer to other systems
> - iptables with all connections refused (you need physical access to do 
> something)
> - maybe allow ssh (no root logins)?
> 
> ==> is this ok, too paranoia or is there somenting i'm missing, and 
> cound it be even more safe?

You have missed the most important thing: file integrity checking. Take
a look at Tripwire or AIDE.

> how about a compiler? normally, all soft on it is compiled by hand, but 
> it is also "necessary" for a local exploit.

I wouldn't know why it is necessary to compile software for productivity
workstations or servers when there are perfectly usable prepackaged
builds from the distributor. If you include a compiler, then limit
access to it. If you compile packages yourself, you can't use the update
services from the distributor whenever there is a security issue for
this package because you chose to be your own packager. If you really
need to compile packages yourself, use source RPMs or corresponding
source packages the distributor offers so that you may profit from
patches the distributor offers.

Unless you're really capable and organised enough to cover all self
compiled software whenever there is a security issue for it, you'd
better stick to the precompiled packages and use the distributors update
procedure. Reading your knowledge level from what you wrote I'd strongly
advise you to take those precompiled packages if security is what you
have in mind.

> any ideas? remarks?

Yeah, open Google and search for "Linux Security Howto" and study the
result. There are some very good howtos there explaining some of the
"must do" procedures for securing Linux systems.

The project "Bastille Linux" may be worth a visit. It is a hardening
script that shuts down some unnecessary stuff.

Always remember though that an installation or configuration is always
safe at only a single moment in time. Security is a constant process of
adaptation. There is nothing like a safe base installation.


regards,
Tobias W.

-- 
***************************************************
   ____  _____
  |  _ \| ____| Tobias Weisserth
  | | | |  _|   tobias@...sserth.[de|com|net|org]
 _| |_| | |___  http://www.weisserth.org
(_)____/|_____|
                
Encrypted mail is welcome.
Key and fingerprint: http://imprint.weisserth.org

***************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040315/cffa2db6/attachment.bin

Powered by blists - more mailing lists