[F4RR3LL]

trueman nimm den 2.6.22.6 mit grsec patch ...
dann kannste crypten und dein kernel fühlt sich dank patch auch wohler

für 2.6.22.7 und 8 gibts noch keinen grsec patch

[trueman]

Konnte das Problem weitestgehend umgehen *fg*

Hab einfach auf den original ovh kernel umgestellt.

Dann neu gebootet. Dann container erstellt und es ging.

Nun folgen die restlichen Arbeitsschritte.

Scheint wogl am neuen Kernel 2.6.22.7 zu liegen irgendwie

[serverchef]

cryptoloop ist eh deprecated (weil knackbar)...man sollte auf dm-crypt + luks setzen.

gruss,
serverchef

[sledge0303]

Ich vermute mal dass es an dem fehlenden kernel modul liegen könnte

Das hätte dann schon einen anderen Grund. Wie gesagt, heute Abend oder Nacht mach ich eh einen neuen Kernel und hab auch nicht alle Einstellungen für Kernelsourcen im Kopf um jetzt eine direkte Antwort bieten zu können.

[trueman]

ich habs via diesem befehl heute nacht gemacht:

dd if=/dev/urandom of=./con1 bs=1024k count=$SIZE

die heute angeandte methode:

dd if=/dev/zero of=./con1 bs=1024k count=$SIZE

ist nur etwas schneller.

Erstellt wurden diese container vom /home Verzeichnis aus

Aber da hatte ich den selben effekt, dass er bei knapp 60 GB aufhörte

Ich vermute mal dass es an dem fehlenden kernel modul liegen könnte

[sledge0303]

58049167360 Bytes (58 GB) kopiert, 897,506 Sekunden, 64,7 MB/s

Eigentlich sollten es 650 GB ungefähr sein

Ich würde das Device so erstellen, wenn es mal bei mir anstehen würde. Um es noch 'schöner' zu machen, würde ich außerdem auf LVM2 Devices bauen!

dd if=/dev/urandom of=/$Container bs=1024 count=655360

[trueman]

Das is schon klar dass, wenn ein server kompromittiert ist, und das device gemountet ist, dass der Angreifer alles da drin einsehen kann.

Hab aber mal testweise nen container erstellen wolllen in /home via:

dd if=/dev/zero of=./con1 bs=1024k count=$SIZE

bei count=$SIZE habe ich SIZE ersetzt mit der MB-Zahl, in diesem Testfall 655360 MB.

Aber komischerweise bricht er bei knapp 60 GB ab, bzw. gibt nur die meldung aus, dass 58 GB erstellt wurden

58049167360 Bytes (58 GB) kopiert, 897,506 Sekunden, 64,7 MB/s

Eigentlich sollten es 650 GB ungefähr sein

[sledge0303]

Wenn ein Modul nicht aktiviert wurde, kann man es auch nicht laden. Es wird so oder so noch einen Kernelupgrade geben heute und dann werden auch die Kernel-Headers verfügbar sein. Das wird notwendig für die Installation des 'e1000', jetzt unabhängig davon.
Ich binde dann Cryptoloop mit ein

Allerdings frage ich mich welchen Sinn verschlüsselte Festplatten auf einem dedizierten Server bringen. Ist dieses Device gemountet, der Server kompromittiert, dann ist auch dieses Device dem Angreifer schutzlos ausgeliefert wie alle anderen auch!

Just my 2c about.

[trueman]

Kann man das kernelmodul nicht irgendwie nachladen?

Danke schon mal

[sledge0303]

Kann sein das Cryptoloop nicht in die Config aufgenommen wurde. Ich baue morgen wieder einen neuen Kernel und werde Crypt besser berücksichtigen.

[trueman]

Ja is nen kernel aus deinen sourcen.

Die neueste als tar.gz via wget http://www.kernel.org/pub/linux/kern....6.22.7.tar.gz

und dann mit deiner config

[sledge0303]

Benutzt du einen Kernel aus meinen Sourcen kompiliert bzw. das debfile installiert?

[trueman]

Hallo, versuche auf nem Server von einem Kunden die Platten zu crypten.

Dafür gibts ja ne wunderschöne Anleitung.

u.a. heisst es da:

Laden der Kernelmodule für Loop-AES Cipher:
modprobe cryptoloop
modprobe aes

das mit aes geht ja, aber beim modprobe cryptoloop kommt halt die meldung dass es nicht gefunden wurde

Kann man das irgendwie nachreichen das modul?

verwendeter Kernel:

2.6.22.7

Danke schon mal