IT-Blog von Sebastian van de Meer

Kategorie: Kernel-Error-Blog (Seite 35 von 49)

Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.

VirtualBox CompareExchange128

Da versuche ich gerade mein Windows 8 auf Windows 8.1 in der VirtualBox zu heben, da springt mich unverhofft eine Meldung an. Ich könne Windows 8.1 nicht installieren da mein Prozessor CompareExchange128 nicht unterstützt.

CompareExchange 128? Das kommt mir im Zusammenhang mit C/C++ und dem Compiler irgendwie bekannt vor. Ich hatte da mal etwas mit einer Binary unter einem FreeBSD. Hing zusammen mit einer AMD64 CPU und noch irgendwas… Gott, warum kann ich mir so einen Mist nicht merken. Aber ich habe in meiner aktuellen Kiste eine Intel CPU. Wobei es wohl eher mit 64Bit als mit dem CPU Hersteller zu schaffen hat. Kann mich da bitte noch mal jemand schlau machen?

Öhm wie auch immer ich erinnere mich daran dass irgendeine recht kryptisch aussehender „Befehlssatz/Anweisung“ im Prozessor genutzt werden sollte. Das Programm auf dem FreeBSD war irgendwie sehr Hardwarenahe übersetzt worden….. 😛

Google brachte mich auf den richtigen Weg, nachdem ich es mit: FreeBSD Compareexchange 128 und AMD64 gefüttert hatte. Plöp: http://en.wikipedia.org/wiki/X86-64 und CMPXCHG16B instruction.

Meine CPU:

$ cat /proc/cpuinfo |grep "model name"|uniq
model name : Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz

Kann diese instruction aber und ich wüsste jetzt nicht das mein Bios oder Hostkernel es abschaltet (warum auch?). AAABBBER vielleicht muss man es für VirtualBox einschalten?!? Ok also VBoxManage und öhm sicherlich VBoxInternal und ich würde es bei CPUM?/device? Vermuten… Ach noch mal Google fragen!

Google bringt mit den Worten: CMPXCHG16B und VirtualBox auch direkt ein passendes Ergebnis!

$ VBoxManage setextradata "Windows 8 " VBoxInternal/CPUM/CMPXCHG16B 1

Tja, was soll ich sagen? Geht 🙂 Gefühlt habe ich mich mit dem Thema schon wieder zu lange beschäftigt und vor allem zu oft Google fragen müssen (ich bin so schlecht). Also tippe ich mal CompareExchange128 CPU und Instruction hier hin. Dann erinnere ich mich sicher daran es mal hier hin geschrieben zu haben .o0(oder auch nicht).

gzip

Ja, es sollte Standard sein, es war aber bis heute nicht aktiviert. Jetzt werden meine Seiten erst mit gzip komprimiert und dann an euren Browser ausgeliefert. Euer Browser muss sie dann noch entpacken! Davon solltet ihr aber nichts merken….. Warum das alles? Da gibt es mehrere Gründe:

1. Komprimierte Daten verbrauchen weniger Platz auf der Leitung.

2. Komprimierte Daten sind kleiner uns damit schneller übertragen.

3. Weder der Server noch euer Rechner muss wirklich CPU-Zeit aufbringen um die Daten zu packen/entpacken.

4. Die Webseiten werden bei euch schneller angezeigt.

 

 

Sicheres SSL / TLS Zertifikat

Es ist Zeit für ein neues Serverzertifikat. Im Standard sind dieses RSA Schlüssel mit einer Länge von 2048 Bit und SHA1 als Hash Algorithmus für Signaturen. Bei SHA1 bekommt man leider etwas Bauchschmerzen… 2048 Bit Keys sind nun ebenfalls nicht SO lang. Theoretisch noch „sicher“ aber wer will es schon darauf anlegen?

Nun wurde über Jahre an SSL / TLS Zertifikaten dieser Art festgehalten. Meist um kompatibel mit älteren Systemen zu sein. So können zum Beispiel die Betriebssysteme Windows XP sowie das darauf basierende Server Betriebssysteme von der Firma Microsoft, Windows Server 2003, nicht mit SHA2 umgehen.

Ich werde für die nächste Zertifikatsrunde auf 4096 Bit lange Schlüssel und SHA2 (SHA256) setzten. Selbst wenn ich damit einige Windows XP Benutzer abhängen werde!

Natürlich braucht man zusätzlich eine CA, welche mit X.509 Zertifikaten dieser Art umgehen kann. StartCOM / StartSSL kann dieses glücklicherweise. Ich erstelle die Zertifikate jeweils mit openSSL (Patch nicht vergessen!).

Key erstellen:

openssl req -new -outform PEM -out http.cert -sha256 -newkey rsa:4096 -nodes -keyout http.key -keyform PEM -days 730 -x509

Zertifizierungsanforderung (CSR) erstellen:

openssl req -new -key http.key -out http.csr -sha256

Die von er CA Unterzeichnete CSR einpflegen:

cat http.key http.crt > http.pem

Diffie Hellman Parameter erstellen und einfach mit ins pem werfen:

openssl gendh 4096 >> http.pem

Ja, es sind 4096bit für DH 😀 dieses kann etwas dauern. Ist aber am Ende nötig damit zum Beispiel der Apache >=2.4 diese Bits auch nutzen kann!

Noch Fragen?

Parken an der Burg Blankenstein: Tipps und Infos

Der Parkplatz im Tünken, Hattingen Blankenstein ist Käse! Ich wohne in der Nähe der Burg und parke hin und wieder auf diesem Parkplatz. Immer mal wieder wird dort in der nahen Kirche geheiratet und dann, ja dann ist da nix mit parken 🙁 Ich will mich nicht beschweren. Kurz nach jeder Hochzeit ist dann schnell wieder Platz. Das Timing macht es halt!

Ich besorge mir einfach einen aufblasbaren riesigen Tux (Linux Maskottchen, ihr wisst schon) oder einen riesigen Computer oder sonst ein PC oder Netzwerk Ding und stelle es dort auf einen Parkplatz. Wenn ich dann abends komme muss ich nur die Luft raus lassen und…. Gott was für eine sch..s Idee 😛 Ich lebe wohl einfach damit!

OpenRheinRuhr 2013

In der Zeit vom 09. und 10.11.2013 ist wieder die Open Rhein Ruhr in Oberhausen. Gerade eben habe ich mein Ticket bestellt 🙂 Ich habe zwar noch keine Ahnung welche Vorträge gehalten werden, denn noch bin ich mir sicher dass es wie jedes Jahr wieder Spaß machen wird! Wer ist noch da?

Warum keine Windows Server Sicherung?

Eine gute Frage, oder? Nun ja, man bekommt diese tolle Windows Server Image oder Image Server Sicherung ja kostenlos von Microsoft dazu. Mit ihr lassen sich auch tatsächlich komplette Server sichern. Dieses sogar zuverlässig 😀

Ich muss aber sicher nicht erwähnen, dass ich im Grunde keine Ahnung von Microsoft Systemen und vor allem der Windows Server Sicherung habe, oder? Egal, mal weiter! Ich wollte ja die Frage beantworten….

Die Windows Server Sicherung kann nicht mit Bandlaufwerken oder ähnlichem umgehen. Natürlich kann man auf einen Netzwerk Share -eine Freigabe- sichern. Da die Sicherung in diesem Fall leider keine Volume Shadow Copy vom Ziel erstellen kann, würde die laufende Sicherung also die bestehende Überschreiben. Bricht die Sicherung als „unvollständig“ ab, hat man nichts mehr.

Volume Shadow Copy…. Weist man der Windows Server Sicherung ein spezielles Backup Volume zu, gibt es der Windows Sicherung die Möglichkeit solche Schattenkopien vom Ziel anzulegen. Man verliert also bei einer unvollständigen Sicherung nicht unbedingt die alten Sicherungen :-). Damit sind wir also bei einer im Rechner verbauten Platte, einer externen USB Platte (bis hier eine schlechte Idee) oder auch bei einer ISCSI Platte. Ersteinmal ok, oder? Jain, warum erkläre ich später! Erst noch etwas zu den Schattenkopien. Windows selbst hat natürlich die Möglichkeit einzelne Schattenkopie von seinen Dateien anzulegen. Diese werden sogar noch von der Serversicherung gesichert. So könnte man also nach dem Zurückspielen einer Vollsicherung sogar noch zu einem etwas älteren Stand zurückspringen. Denn noch muss zuerst die Vollsicherung zurückgespielt werden und dann geht es auf einen älteren Stand. Das ist im Falle einer Rücksicherung sehr langwierig. Funktioniert denn noch sehr gut…

Vollsicherung… Die Windows Server Sicherung kann nur Vollsicherungen erstellen, also keine inkrementell oder differentielle Datensicherung. Das bedeutet man muss jeden Tag die kompletten Daten zum Sicherungsziel „pumpen“. Nutzt man nun als Ziel ein intelligentes Storage System wie ein NetApp oder ein ZFS basiertes System (Nexenta, OpenIndiana, Solaris, FreeNas)… Vielleicht noch zusammen mit ISCSI…. dann bringen einem sehr viele der feinen Zusatzfunktionen des Storage Servers kaum noch etwas. Mal angenommen man möchte sein Storage System mit einem anderen abgleichen, dann wird ebenfalls wieder alles kopiert, da sich ja leider immer alles ändert. Dumme Sache das 🙁

Möchte man also seine Sicherung nicht im Unternehmen liegen haben (Feuer / Flugzeug / Wasser / ..) würde so jeden Tag die vollständige Sicherung bewegt werden müssen. Denkt man nun an ein paar TB wird schnell klar, das man sich schon extreme Anbindungen an seinen Standort mieten muss, nur um die Sicherung überhaupt in einem gewissen Zeitfenster aus dem Haus zu bekommen.

Hier kommen dann wieder die etwas teureren Sicherungsprogramme anderer Hersteller ins Spiel .-)

Um es also auf den Punkt zu bringen… Die Windows Server Sicherung funktioniert und hält was sie verspricht, ohne die Möglichkeit einer differentielle Sicherung wird sie denn noch von mir in fast allen Fällen eine Abfuhr bekommen.

Oh ja, sobald es die Möglichkeit einer differentiellen Datensicherung gibt, bitte melden!

Der sichere GPG-Schlüssel

Absolut sicher ist wie immer nichts, jeder kann nur versuchen sich so weit wie möglich der Perfektion anzunähern. Nachdem nun bewiesen ist dass einige Organisationen keine Kosten und Mühen scheuen um selbst starke Verschlüsselungen zu brechen…. Ja, da kann man nur versuchen es ihnen so schwer und aufwendig wie nur irgendwie möglich zu machen. Wie? Na da schauen wir doch mal!

Es beginnt mit der Schlüssellänge, diese sollte länger 1024 sein. DSA Schlüssel müssen eine größe zwischen 512 und 1024 Bits haben. Damit sollte man schon mal keinen DSA Schlüssel nutzen, vor allem da DSA von einem ehemaligen NSA-Mitarbeiter entwickelt wurde. ElGamal-Schlüssel hingegen können unbegrenzt groß werden. DSA sowie auch ElGamal-Schlüssel haben ein großes Problem mit schlechten Zufallsgeneratoren. Wird zum Beispiel eine Signatur mit der Hilfe eines schlechten Zufallsgenerators erstellt, lässt sich unter Umständen der private Schlüssel daraus errechnen. Es gibt für RSA theoretische Angriffsszenarien. Für einen 1024 Bit-Schlüssel wäre es eine Maschine welche von Menschen zwar gebaut werden kann, für den Betrieb würde es aber im Moment mehr Energie benötigen als die USA liefen können. Die Jungs schlafen nicht und bei die Faktorisierungsalgorithmen werden immer weiter verbessert, also den Schlüssel aufbohren… Mit den heutigen Rechenleistungen sind 4096 Bit lange Schlüssel kein Problem mehr. Einigen wir uns also für heute auf einen RSA Schlüssel mit einer Länge von 4096 Bit. Für heute? Joar… Quantencomputer könnten in der Zukunft erfolgreiche Angriffe auf RSA Schlüssel fahren. Dazu müsste ein Quantencomputer aber einen Angriff auf den kompletten Schlüssel fahren. Derzeit sind wir bei ~ich glaube~ deutlich unter 10Bit. 

Nun ist der benutzte Algorithmus an der Reihe. Welche Verfahren von seiner GnuPG Version unterstützt werden, zeigt man sich am einfachsten an mit:

$ gpg --version

Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2

MD5? War das nicht schon lange geknackt? Jappp… MD5 ist ein unsicherer Hashalgorithmus. SHA1 gilt zwar noch als sicher, wird aber auch bald gefressen werden. SHA2 wurde zwar von der NSA entwickelt, es haben aber inzwischen so viele Augen drüber geschaut dass man davon ausgehen kann; hier hat die NSA nichts versteckt! SHA3 ist aktuell noch nicht komplett fertig ~oder?~. Wie auch immer…. Glücklicherweise kann man nun in seinem Schlüssel einstellen was genutzt werden soll und in welcher Reihenfolge. Reihenfolge kann man nicht einfach den „sichersten“ als einzigen einstellen? Ja, kann man…. Jetzt müssten sich nur noch alle auf den vermeintlich sichersten einigen, das umsetzten und wenn etwas schief geht dieses schnell anpassen. Klingt nicht nur so als wenn es nicht klappen wird. Also stellt man mehrere Algorithmen ein die man selbst verwenden möchte. Angenommen ich möchte nun also den Schlüssel mit der ID 0x0F9874D8 (b.t.w.: die kurze ID ist auch nicht mehr sicher) ändern. Dann mache ich dieses mit:

gpg --edit-key 0x0F9874D8

Zuerst mal schauen was eingestellt ist:

gpg> showpref
[ uneing.] (1). Sebastian van de Meer (E-Mail Address) kernel-error @ kernel-error.com;
Verschlü.: TWOFISH, AES256, AES192, 3DES
Digest: RIPEMD160, SHA512, SHA256, SHA1
Komprimierung: BZIP2, ZLIB, nicht komprimiert
Eigenschaften: MDC, Keyserver no-modify

Die gewünschten Algorithmen setzte ich mit:

gpg> setpref TWOFISH AES256 AES192 RIPEMD160 SHA512 SHA256 BZIP2 ZLIB
Setze die Liste der Voreinstellungen auf:
Verschlü.: TWOFISH, AES256, AES192, 3DES
Digest: RIPEMD160, SHA512, SHA256, SHA1
Komprimierung: BZIP2, ZLIB, nicht komprimiert
Eigenschaften: MDC, Keyserver no-modify
Die Voreinstellungen wirklich ändern? (j/N)

Jetzt noch das editieren beenden:

gpg> q
Änderungen speichern? (j/N) j
random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
secmem usage: 64/32768 bytes in 1 blocks

Fertig… Schon arbeitet der Schlüssel nur noch mit den Algorithmen, welchen ich vertrauen möchte.

Welchen Verfahren kann man nun eigentlich noch wirklich vertrauen? Dieses muss natürlich jeder für sich entscheiden. 

Linux Luks keymap

Festplattenverschlüsselung ist eine tolle Sache, luks übernimmt diesen Job 1A. Nur dumm wenn sich „plötzlich“ die Keymap von latin1 / deutsch auf englisch ändern. Wie geht das? Nun ja, man richtet mit geladener deutsche Keymap seine verschlüsselte Partition oder Festplatte ein. Beim booten kommt die Abfrage des Passphrase noch vor dem laden der gewünschten Keymap. Schon kommt man in die Verlegenheit sein Kennwort auf einer englischen Tastatur zu tippen. Dieses merkt man nur leider nicht. Also gibt man sein Kennwort tausend mal ein und wundert sich warum es denn nicht korrekt sein soll.

Ich habe mich von dem Thema ebenfalls schon mal verarschen lassen. Auf einer Sabayon Kiste löst sich dieses Problem wie folgt:

Man erweitert einfach in der Kernel comand line diese Parameter: dokeymap keymap=de

dokeymap sorgt dafür das die Keymap sofort geändert wird und zwar zu keymap=de

 

Dieses giest man einfach in die passende Konfigurationszeile für grub:

$ vim /boot/grub/grub.cfg

linux /kernel-genkernel-x86_64-3.10.0-sabayon ro single init_opts=single splash quiet splash dokeymap keymap=de vga=791 quiet domdadm resume=swap:/dev/mapper/swap real_resume=/dev/mapper/swap dolvm root=/dev/mapper/root crypt_root=UUID=d8a6be16-1977-4471-bdbb-b8cea4aed177 docrypt crypt_swap=/dev/sdb3

Damit es nicht bei jedem neuen Kernel / Update neu nachgetragen werden muss legt man es am besten noch in der Standardkonfiguration ab:

$ vim /etc/default/sabayon-grub

GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX} splash quiet splash dokeymap keymap=de vga=791 quiet domdadm resume=swap:/dev/mapper/swap real_resume=/dev/mapper/swap dolvm root=/dev/mapper/root crypt_root=UUID=d8a6be16-1977-4471-bdbb-b8cea4aed177 docrypt crypt_swap=/dev/sdb3"

 

Beim nächsten Reboot sollte es dann mit der deutschen Tastatur klappen!

 

 

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑