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