Onderwerp: Beveilig linux server

ok, titel is clickbait

Maar diegene die erop klikken zijn waarschijnlijk wel diegene die ik nodig heb .

Samen weten we meer dan ik alleen....

Ik heb een systeem, encrypted rootfs maar met een unsecure /boot partitie en unsecure /data partitie. Rootfs wordt automatisch unlocked zonder passphrase en kan bijvoorbeeld gekoppeld zijn aan een TPM2.0 chip. Wat ik hiermee dus al bereikt heb is dat een clone van een hdd de betreffende software binnensdeur blijft. Wat ik dus nog niet uitgesloten heb is dat iemand die achter de pc zit kan booten in runlevel 1, en vervolgens dus alsnog binnenkomt. Nu kan ik grub voorzien van een password op moment je e drukt, echter de slimmerik die de disk mount in een ander systeem, en de grub.cfg handmatig aanpast is ook spekkoper.

Er zijn verschillende invalshoeken die mij te binnen schieten, het eruit slopen van runlevel 1 bijvoorbeeld, of zorgen dat ondanks het niet de bedoeling is script uitgevoerd wordt, checked op runleven en systeem simpelweg uitzet. Debian heeft bijvoorbeeld killscript voor runlevel 1, wellicht dat ik daar op in kan haken. Ook kan ik het script wat de sleutels maakt en doorgeeft aan luks laten checken op welk runlevel we inzitten. Echt veilig is deze oplossing niet, wie initramfs opent, en eventueel script aanpast loopt daar dus al omheen.

Als ik google dan wordt ik niet echt wijzer ervan.

Wie kan mij zetje in de juiste weg duwen. het systeem mag unrecoverable worden op moment password, updates etc etc fout gaan.

Het is het beste als het root file system volledig versleuteld is en niet vanaf locatie zonder wachtwoord ontsleuteld kan worden. Encryptie gebruik je juist om te voorkomen dat als de server of disks uitgefaseerd worden of iemand achter de machine staat alsnog in kan loggen. Het klinkt alsof de huidige oplossing geen afdoende beveiliging biedt.

Bij servers in ons beheer bieden we full disk encryption met unlocken van buitenaf via het netwerk. Dit kan toegepast worden op vrijwel alle dedicated en soms ook virtuele machines. We gebruiken hiervoor een zeer veilige en specifiek daarvoor opgestelde mini-SSH daemon die online komt voordat het OS start. We hebben momenteel een kleine wachtrij voor nieuwe projecten, maar nieuwe business is natuurlijk altijd interessant.

Oorspronkelijk geplaatst door Ber|Art

Het is het beste als het root file system volledig versleuteld is en niet vanaf locatie zonder wachtwoord ontsleuteld kan worden. Encryptie gebruik je juist om te voorkomen dat als de server of disks uitgefaseerd worden of iemand achter de machine staat alsnog in kan loggen. Het klinkt alsof de huidige oplossing geen afdoende beveiliging biedt.

Bij servers in ons beheer bieden we full disk encryption met unlocken van buitenaf via het netwerk. Dit kan toegepast worden op vrijwel alle dedicated en soms ook virtuele machines. We gebruiken hiervoor een zeer veilige en specifiek daarvoor opgestelde mini-SSH daemon die online komt voordat het OS start. We hebben momenteel een kleine wachtrij voor nieuwe projecten, maar nieuwe business is natuurlijk altijd interessant.

Op moment je een schijf mee naar huis neemt is hij al onbruikbaar. Dit komt doordat de sleutels opgeslagen worden in de TPM.
De clevis icm tang methode is ook niet de oplossing. De magic gebeurt op dezelde plek als die van mij, waarna de kernel nog steeds gestart kan worden in single user mode met init=/bin/sh . Waarna je vervolgens nog steeds een root pw kan resetten. En stel dat de setup niet correct is, kan ik vanuit thuis met meegenomen schijven ook de unlock keys bemachtigen op moment deze zich online kenbaar maakt.

Ik zie het liefst de optie init=/bin/sh gesloopt worden

OK, ik denk dat ik langzaam wel kom naar wat ik voor ogen had.

Inmiddels encrypt ik de /boot partitie ook. Wat je daarbij krijgt is dat je een master key in moet geven. Dit overrule ik in:

https://github.com/rhboot/grub2/blob...e/lib/crypto.c , sloop de while(1) loop eruit beginnend vanaf lijn 459, en ga daar de tpm functie eraan toevoegen. Mocht ik qua ruimte niet uit komen, dan kan ik altijd nog een sleutelpaar maken aan de hand van moederbord informatie bijvoorbeeld. En als dat echt niet anders kan, zou een permanente key voor de /boot partitie ook nog een optie kunnen zijn. Dat laatste heeft absoluut niet de voorkeur. En reeel, iemand die in mijn grub 1.5 stage gaat zitten neuzen en met een hex editor langs, heeft al veel meer kaas gegeten om ergens anders wellicht een betere vector te vinden ;-)

De eerste vraag die ik heb is eigenlijk 'tegen welk soort probleem ben je aan het beveiligen' ?

Het is opzich prima natuurlijk om een aantal 'grote gaten' dicht te hebben ook al is het niet perfect tegen een meer toegeruste aanvaller. Zolang je je maar bewust bent van de beperkingen, en je niet in de situatie komt dat er dingen op draaien die 'meer' nodig hebben dan je kunt bieden.

Gezien je derde post lijkt je je dat ook te realiseren. Het pad van je eerste post lijkt me een verloren zaak, als iemand er genoeg voor gaat zitten.

Iemand kan de boot/grub stage vervangen of aanpassen, en dat je daarna een recovery optie in het OS gesloopt hebt maakt niet echt uit - Als ik vanuit die first stage de gecrypte OS partitie kan laten decrypten (ik hoef 'm niet te starten) zou ik die hele partitie laten dumpen en dan off-line verder uitzoeken.
Voor zo ver ik het zie is het dan alleen nodig in die tijd jouw hardware bij de hand te hebben, voor de key die uit de TPM chip komt.
Het is zeker meer werk dan simpelweg init=/bin/sh meegeven , maar nog wel doenbaar.

Het soort security dat een iPhone inmiddels levert ga je niet snel evenaren nog.

Wat je eigenlijk nodig hebt is dat de harddisk zelf gecrypt is (als drive feature), dat de key daarvoor uit de TPM komt (ingegeven door BIOS) en er geen edit/escape opties meer bereikbaar zijn in GRUB.

Zodat de disk uit de machine halen geen leesbare data van de bootloader oplevert,noch de optie om een eigen bootloader te plaatsen, en dat daarna de volgende software stages (1st/2nd stage bootloaders, en daarna OS) geen afbreek/edit opties bieden.

(Als dat goed gedaan is, zijn de eerstvolgende zorgen aanvallers met coldspray die proberen data/decryptie keys uit het ram te halen na poweroff e.d. )

Oorspronkelijk geplaatst door visser

De eerste vraag die ik heb is eigenlijk 'tegen welk soort probleem ben je aan het beveiligen' ?

Voor mij voornamelijk concurrentie buiten de deur houden. Kleine markt en wij maken uiteraard betere spullen dan hun ;-)!

Dus waar ik me voornamelijk tegen wil beveiligen is dat er even snel een clone van de hardeschijf gemaakt wordt. Daar is bij een cold clone enkel rootfs encryptie voldoende. De keys staan niet op de schijf maar zitten in de TPM device. Maar waar ik me dus niet kon tegen beveiligen, en hoop dat @Ber|Art ook ziet wat ik bedoel is dat de encryptie zowel bij mij als de clevis / tang methode (ervanuitgaand dat ze dit gebruiken) niets doet tegen het principe booten van de kernel direct in een shell waarbij het rootfs al gedecrypt is. Vandaar mijn zoektocht naar full disk encryption icm grub beveiligen.

Het vreemde lijkt wel dat een hoop mensen zich dit niet realiseren, ik ben inmiddels heel wat mailinglists verder en heel soms zie je dat iemand het aanhaalt en ebt de vraag langzaam weg. Wat dat aangaat doen microsoft en apple het out of the box veel netter.

De oplossing die ik in mijn openingspost had is in ieder geval gebonden aan de hardware, maar bij fysieke toegang niet voldoende.

Ik moet bepalen wie er belang bij heeft om eventueel een keukje in mijn keuken te willen nemen. Vervolgens inschatten welke inspanning daarvoor nodig is, en afwegen of de beveiliging voldoende is.

Ik denk met mijn wijziging in de grub source, ik diegene met de coldspray welkom heet, en de concurrent in ieder geval succesvol buiten gehouden heb.

Bovenstaand is dus optie 1

Ik ga ook zeker kijken naar je sed + tpm optie.

Thanks en een fijn weekend !

Kleine update, inmiddels grub source aangepast en we kunnen nu twee kanten op afhankelijk van de hardware.

1. Aan de hand van smbios informatie een sha256 hash maken
2. Of gebruik maken van eventuele aanwezige TPM module.

Full disk encryptie inclusief /boot