| 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 |
Archives