1 |
A few weeks ago I tried to setup a domU under Xen with GRsecuriy + |
2 |
PAX. But (maybe due to a lack of time) I was not able to get it |
3 |
working. Here's my question: Has anyone done such a setup and can |
4 |
give me some hints (patches for xen-sources to include PAX etc.)? |
5 |
|
6 |
Yours, |
7 |
Andreas |
8 |
|
9 |
Am 15.01.2007 um 18:32 schrieb Viktors Rotanovs: |
10 |
|
11 |
> Hi Michael, |
12 |
> |
13 |
> Michael wrote: |
14 |
>> I co-admin 2 servers running x86_64 gentoo installs. Due to not |
15 |
>> updating |
16 |
>> the servers for a longer period, there were several major security |
17 |
>> issues which at least allowed for someone to run a ftp server on it |
18 |
>> without me knowing about it. |
19 |
>> Because a lot of stuff is still outdated and this was the first |
20 |
>> install |
21 |
>> for the servers I want to reinstall them, again using gentoo. My own |
22 |
>> idea was to isolate the web and mail-server in Xen virtual |
23 |
>> machines, so |
24 |
>> that if someone's ever able to get in they can only bring down a |
25 |
>> small |
26 |
>> part, which can easily be restored. |
27 |
>> Now my question is, would this be a good way to at least partly |
28 |
>> secure |
29 |
>> the machine? Or should I use something from the hardened depot to |
30 |
>> increase the security levels on these servers? The problem now was |
31 |
>> that |
32 |
>> one program had a bug in it which could even give remote users root |
33 |
>> access to the entire machine, which could've also caused loss of data |
34 |
>> the program was not related to. By isolating in Xen domains this |
35 |
>> problem |
36 |
>> is partly solved, but it does also bring a few other problems along. |
37 |
> |
38 |
> Chroot hardening using grsecurity (with TPE enabled) IMHO provides |
39 |
> even better protection (but your opinion may differ), because it |
40 |
> prevents several common types of attacks. |
41 |
> Xen = protection against mythical attacks |
42 |
> GRsecurity+PAX = protection against real-world script kiddies (99% |
43 |
> of cases) |
44 |
> |
45 |
> GRSecurity makes hacking extremely inconvenient even if you have |
46 |
> shell account in chroot, and unusual files are easily detectable |
47 |
> via simple file monitoring tools running outside that chroot. You |
48 |
> can also enable netconsole logging to secure loghost to catch |
49 |
> hacking attempts/IPs in realtime. |
50 |
> |
51 |
> Regarding Xen, hacked website inside a Xen VM still can collect |
52 |
> user data, credit card numbers, etc., as well as serve as a place |
53 |
> to scan internal networks if they exist. |
54 |
> |
55 |
> If you use PHP, keep in mind that history tells that PHP is very |
56 |
> insecure. You can: |
57 |
> - improve your php.ini (disable allow_url_fopen, etc.) |
58 |
> - check http://www.hardened-php.org/ |
59 |
> - check http://www.modsecurity.org/ |
60 |
> |
61 |
>> I hope someone that has had or is avoiding these same problems can |
62 |
>> shed |
63 |
>> some light on it... |
64 |
> |
65 |
> I'm very happy with grsec+hardened gentoo for several years, on >50 |
66 |
> servers (athlon xp, amd64, some intels). |
67 |
> |
68 |
>> Greetings, |
69 |
>> Michael |
70 |
> |
71 |
> Best Wishes, |
72 |
> Viktors | http://rotanovs.com |
73 |
> -- |
74 |
> gentoo-hardened@g.o mailing list |
75 |
> |
76 |
|
77 |
-- |
78 |
gentoo-hardened@g.o mailing list |