Datenhaufen zu IT und Elektronik.

Autor: Sebastian van de Meer (Seite 35 von 49)

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!

 

 

DNSSEC & DANE: TLS-Zertifikate mit TLSA-Records absichern​

Schon einige Zeit ist meine Domain per DNSSEC geschützt und der Zugriff ist ebenfalls per SSL/TLS möglich. Mit DANE (DNS-based Authentication of Named Entities) ist es jetzt möglich die eingesetzten X.509 Zertifikate bzw. deren Checksummen mit dem DNS „abzugleichen“.

Die Idee dahinter ist, das löchrige System der CAs (certificate authority oder certification authority) etwas sicherer zu machen / zu ersetzten.

Unterstützt ein Client, wie zum Beispiel ein Browser, DANE so kann er beim verschlüsselten Verbindungsaufbau mit einem Server (z.B.: Webserver). Prüfen ob die Checksumme des TLS Zertifikates mit der in der DNS Zone hinterlegten übereinstimmt. So kann man diesem Zertifikat „trauen“, selbst wenn es sich um ein selbst signiertes Zertifikat handelt oder das Root-Zertifikat der CA nicht in seinem Client enthalten ist.

Selbstverständlich wird damit nicht sichergestellt das die angegebene Person oder Organisation wirklich hinter dem Zertifikat steht. Hier hängt es dann wieder an der CA, der muss man zum einen selbst vertrauen und zum anderen sollte sie dafür sorgen dass niemand an ihre Zertifikate kommt. Nichts ist 100%tig sicher! Man kann nur versuchen dem absoluten Vertrauen so nahe wie möglich zu kommen. Daher ist es sehr angenehem wenn verschiedene Mechanismen ineinandergreifen und sich nach Möglichkeit auch gegenseitig prüfen.

Dabei sollte der Benutzer aber mit so wenig technischen Dingen gequält werden wie nur möglich. DNSSEC, DANE und TLS ist aus meiner Sicht im Moment eine recht gute Kombination. Wenn alles sauber im Client implementiert ist und die Admins ihre Arbeit gemacht haben, bekommt der Benutzer nur die Information: „Was du da gerade machst ist möglicherweise nicht der Server mit dem du sprechen wolltest. Lass es lieber!“

Klar steht und fällt am Ende alles mit dem Benutzer. Hier müssen die Benutzer geschult und aufgeklährt werden. Den technischen Hintergrund muss aber kein Anwender verstehen. 

Ich stehe ja auf so etwas. Daher habe ich es direkt bei mir implementiert.

Bind kann ab der Version 9.8.3 mit TLSA RECORDS umgehen:

#### SCHNIPP ####
Feature Changes

* BIND now recognizes the TLSA resource record type, created to
support IETF DANE (DNS-based Authentication of Named Entities)
[RT #28989]
#### SCHNAPP ####

Damit es einfacher wird bietet die Internet Society (http://www.internetsociety.org/deploy360/resources/hashslinger-a-tool-for-creating-tlsa-records-for-dane/) ein Tool mit dem Namen Hash-slinger an. Dieses Tool unterstützt beim erstellen der TLSA-RECORDS und natürlich bei der Prüfung der DNS-RECORDS.

Für meine Hauptdomain findet sich folgender RECORD in der Zone:

_443._tcp.www.kernel-error.de. IN TLSA 3 0 1 a3218154fbaa792afba91075ea36b5ea6623d46766a10ff1d06e7de461f933f7

Geprüft wird dieser korrekt wie folgt, einmal für die IPv4 und einmal für die IPv6 Adresse:

$ ./tlsa -d -v www.kernel-error.de
Received the following record for name _443._tcp.www.kernel-error.de.:
Usage: 3 (End-Entity)
Selector: 0 (Certificate)
Matching Type: 1 (SHA-256)
Certificate for Association: a3218154fbaa792afba91075ea36b5ea6623d46766a10ff1d06e7de461f933f7
This record is valid (well-formed).
Attempting to verify the record with the TLS service...
Got the following IP: 212.23.142.146
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
The matched certificate has Subject: /description=3G0bqBiLJsg0y2nv/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=www.kernel-error.de/emailAddress=postmaster@kernel-error.de
Got the following IP: 2001:7d8:8001:100::dead:beef
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
The matched certificate has Subject: /description=3G0bqBiLJsg0y2nv/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=www.kernel-error.de/emailAddress=postmaster@kernel-error.de

Die gängigen Browser lassen sich bereits mit Plugins nachrüsten.

Spannende Infos zum Thema DANE gibt es hier:
http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec

Wer nur schnell und einfach die TLSA Records testen möchte, kann dieses hier tun: http://check.sidnlabs.nl/dane/


U-P-D-A-T-E 28.01.2014

Wie sich das Thema zusammen mit Postfix nutzen lässt um auch etwas gegen dieses hässliche EmiG (E-Mail made in Germany) zu tun ist hier zu finden: https://www.kernel-error.de/kernel-error-blog/260-postfix-ssl-tls-gesichert-mit-tlsa-dane-und-dnssec


U-P-D-A-T-E 09.08.2014

Ich habe den Mailgraph erweitert ( mailgraph Graphen um DANE erweitern ), damit er mir den unten stehenden Graphen erzeugt.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑