Map beveiligen tegen extern inlezen

[IceOnFire]

Een beetje vreemde titel misschien, maar ik wist even geen betere

Ik heb een servertje waar wat php code op staat. Ik ben de enige met een rootaccount op die server, er is ook niemand anders met user access. Ik ben alleen niet de enige die fysiek bij de server kan en zou graag de map waar de php code staat op een dusdanige manier beveiligen dat als iemand de harddisk uit de server zou halen en extern zou aansluiten niet bij die php code kan. Uiteraard moet Apache er wel gewoon bij kunnen om de code uit te voeren.

Ik heb al druk rondgezocht maar ben niet zo'n linuxgoeroe. Ext2 heeft sowieso ondersteuning voor encryptie en ook met GPG kan je wel wat doen begrijp ik, maar aangezien uiteraard wel een keer toegang gegeven moet worden tot de data staat t benodigde wachtwoord altijd ergens neem ik aan. Als het niet anders is is een oplossing waarbij ik na iedere reboot zelf via ssh oid een commando moet uitvoeren om het eea zichtbaar te krijgen wat mij betreft ook nog te overwegen.

Iemand enig idee op wat voor manier ik zoiets zou kunnen realiseren? Op de server staat op dit moment CentOS 5.4 overigens

[Arioch]

Je zou bijvoorbeeld truecrypt kunnen gebruiken of LUKS om je filesystem te encrypteren.
Valt verder heel wat over te vinden.

IceOnFire schreef op zondag 17 januari 2010 @ 23:56:
Als het niet anders is is een oplossing waarbij ik na iedere reboot zelf via ssh oid een commando moet uitvoeren om het eea zichtbaar te krijgen wat mij betreft ook nog te overwegen.

Ik denk dat dit zowieso een vereiste zal zijn. Anders heeft het nog steeds hetzelfde nadeel: iedereen kan er aan door de disk er uit te halen.

[ Voor 63% gewijzigd door Arioch op 18-01-2010 00:55 ]

[Wolfboy]

Hier is een howto voor het encrypten van een partitie met cryptsetup (LUKS): http://www.c3l.de/linux/h...ubuntu-6.10-edgy-eft.html

Je zal alleen wel vast zitten aan het wachtwoord opgeven bij het opnieuw opstarten ja. Als je dat niet hebt dan zal iemand die de schijf in handen krijgt er nog steeds bij kunnen.

[johnkeates]

Je zou het beste voor een complete LVM op een LUKS RAID kunnen kiezen.

Het probleem met LUKS is dat je alle data nodig hebt om het te kunnen ontsleutelen. Daarom RAID.
En om dat je misschien meerdere partities hebt, of meerdere schijven, meerder wat dan ook, zou je voor LVM kunnen kiezen. Een ander voordeel is dat je de device-mapper van LUKS+LVM kan gebruiken hoe je het ook maar leuk vind, als of het een losse schijf is. Dit betekent dus ook dat je partities kan toevoegen/verwijderen/resizen (logical volumes van LVM) zonder dat je steeds weer nieuwe LUKS entries moet maken en configureren.

Qua veiligheid heb je meerdere opties;

1. Key op extern medium, bij opstarten vereist

2. Root niet op LUKS partitie, dus root niet encrypted gebruiken, /home e.d. op losse LUKS partitie (+LVM)

3. /var/www op losse schijf, en die steeds handmatig via SSH met cryptsetup openen en sluiten wanneer je maar nodig acht

Een van de dingen die je wel eerst voor elkaar moet hebben:

- Een van de vele systemen gebruiken die bijhoudt of syseembestanden gewijzigd zijn (zodat ssh binaries niet gehackt kunnen worden om aan jouw password te komen)

- Geen onveilige services gebruiken, anders heb je er nog niets aan

- Veilige plek om een backup van de sleutel te bewaren (bank, kluis, ander land online [in dit geval dubbel encrypted])

Zelf heb ik meerdere servers met LUKS gemaakt/opgeleverd en ook persoonlijk in gebruik. Werkt als een zonnetje, en loopt als een trein. Met een beetje goede hardware (dual core op z'n minst, SIMD (de 4e versie al weer dacht ik) is ook wel handig) en snelle schijven moet je er weinig van merken. Zorg er wel voor dat het een zonder het ander niet te gebruiken is!

- Sleutel is niet bruikbaar om in te loggen

- Sleutel staat niet op systeem

- Inloggen kan alleen met een veilig wachtwoord en niet met root (dus SSH met een gewone account en sudo waar nodig)


Een andere optie is misschien een disk image gebruiken. Maar de enige ervaring die ik heb, is dat het erg langzaam is. Wel net zo veilig (mits juist uitgevoerd).

Afhankelijk van je distro zijn dingen als luks en cryptsetup moet mdadm/md/lvm e.d. makkelijk uit de repositories te halen. (Debian, Gentoo e.d.)

Meerdere tutorials beschikbaar op internet! Google! (LUKS, Debian Cryptsetup)

[johnkeates]

Oh, en truecrypt werkte 6 maanden geleden nog niet echt productie-stable op linux. Weet niet hoe het nu is.

Wil je encryptie, dan zal je LUKS moeten doen (om het goed te doen - als je het niet goed wil doen kan het je beter niet doen)


Opstarten kan gewoon zonder wachtwoord intypen, als je je /var/www map op een losse partitie hebt en die gewoon steeds even mount. Je zou ook een scriptje kunnen schrijven die naar je key vraagt, scheelt je een hoop typewerk.


Relevante tutorials en wiki's:

- http://linuxgazette.net/140/pfeiffer.html
- http://www.shimari.com/dm-crypt-on-raid/#encrypt_root
- http://www.debian.org/releases/stable/i386/ch07s02.html.en
- http://madduck.net/docs/cryptdisk/
- http://www.vectorspace.dk...-secret-key-on-usb-stick/
- http://www.saout.de/misc/dm-crypt/
- http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS
- http://wiki.archlinux.org...xternally_.28USB_stick.29

En dan nog iets wat ook belangrijk is om te weten:

- Wikipedia: Cold boot attack

En een stukje realiteit:

- http://xkcd.com/538/


Met al deze dingen zal je ongetwijfeld verder komen. Als je niet verder wil komen, dan moet je iemand regelen die het even voor je doet, of een andere oplossing gebruiken. (iSCSI, SSHFS&Fuse anyone?)