Gentoo Archives: gentoo-hardened

From: Ed W <lists@××××××××××.com>
To: gentoo-hardened@l.g.o
Subject: Re: [gentoo-hardened] Remove toolchain?
Date: Tue, 02 Feb 2010 14:02:38
Message-Id: 4B682AA6.7080808@wildgooses.com
In Reply to: Re: [gentoo-hardened] Remove toolchain? by basile
1 On 02/02/2010 11:34, basile wrote:
2 > schism@×××××××××.org wrote:
3 >
4 >> On Mon, Feb 01, 2010 at 01:35:10PM +0100, Hinnerk van Bruinehsen wrote:
5 >>
6 >>
7 >>> But there is one thing which disturbs me: Since Gentoo (and hardened
8 >>> Gentoo) is sourcebased, i'll need a complete toolchain to keep the
9 >>> system up to date.
10 >>>
11 >>> I don't like the idea of giving this tools to someone who might
12 >>> compromise the server.
13 >>>
14 >>>
15 >> Removing the toolchain is an old, common misconception whose originator
16 >> I would love to meet and slap some sense into.
17 >>
18 >>
19 > In fact, this itself is the answer to what to do if you want to remove
20 > the toolchain. If you have several similar machines, you could use one
21 > to compile and build the .tbz2 packages for updates to deploy to those
22 > machines that do not have a toolchain.
23 >
24 > Having said that, I agree that removing the toolchain is weak defense
25 > and you should use rbac.
26 >
27 >
28
29 I personally like the hardened project, but I think it's easy to
30 overlook that usually the biggest weaknesses (and most probed areas of
31 exploit right now) are something like:
32
33 - Bad passwords for ssh/mysql (and other apps...)
34 - Various bad practices in web applications which allow remote
35 exploit/access/sql injection/xss, etc
36 - Trojans/viruses which target client workstations and can capture
37 information without breaking into the server
38 - Internal attacks... Admin's who leave. Disgruntled employees..
39
40 I think it's easy to overlook that the above is often your biggest
41 source of risk and continue polishing something which is normally pretty
42 resistant to external attack. As a rough rule of thumb I can only think
43 of perhaps a tiny handful of exploits in the last few years which would
44 have allowed remote breakin to a non hardened box running your usual
45 remote access services, say Apache or email or similar (I will discount
46 Bind and Sendmail from this analysis...). However, lots of unix boxes
47 have been rooted through simple holes in web applications and a bunch of
48 distros that leave remotely accessible accounts with known guessable
49 passwords...
50
51 Virtualisation is also a big step forward for helping contain the
52 effects of a compromised machine - I'm very impressed with what we have
53 been able to do since we started using it on all our servers..!
54
55 Good luck
56
57 Ed W