Datenhaufen zu IT und Elektronik.
Notizen & Praxis zur IT-Sicherheit – von Responsible Disclosure bis Härtung.
Die Webseite https://dmarcian.com stellt zwei sehr schöne Möglichkeiten zur Verfügung um seinen >> DMARC-RECORD << und oder seinen >> SPF-RECORD << zu testen.
Am besten gefällt mir dabei der SPF Test, denn dieser sammelt auch gleich alle nötigen DNS Lookups zusammen und visualisiert sie einem recht ansprechend.
Bunte Bilder *wwwööööööööööhhhhhhhhhyyyyyyyyy*
Ja, wenn es hilft schick mir eine E-Mail und ich sage dir ob deine Konfiguration sauber ist 😀
Viel Spaß!
Es gibt viele gute Gründe warum man die Version seines DNS Servers unkenntlich machen sollte. Viele Roboter und noch mehr Scriptkiddies suchen nach Versionen mit Sicherheitslöchern. Natürlich sollte man seine Version immer auf dem aktuellen Stand der Sicherheitsupdates halten… Denn noch kommt es vor dass man auch mal ein paar Tage auf einer „kaputten“ Version läuft. Dieses muss man ja nicht jedem unter die Nase reiben, hm?
Beim Bind ist es extrem einfach. Man reißt einfach mit dem Editor seiner Wahl die named.conf auf und wandert zum Options-Bereich. Dort ergänst man einfach die Option version:
options
{
[Zeugs und andere Optionen]
version "unknown";
[noch mehr Zeugs und andere Optionen]
};
Nun einfach Bind seine Konfiguration neu laden lassen:
$ rndc reconfig
Schon wird keine Version mehr angezeigt. Testen kann man alles wie immer mit dig:
$ dig -c CH -t txt version.bind +short @dns1.telekom.de "SORRY"
Sorry finde ich gut liebe Telekom 🙂
Bock auf ein kleines Spiel? Wer mir zuerst sagt auf welchem Schiff mein primärer DNS Server stehen müsste, der bekommt eine Dose Dr Pepper Cola geschenkt.
Update 26.11.2013 19:53
Glückwunsch Dome, du bekommst die Dose. Bekomme ich ein Foto wie alles ausschaut nachdem DHL das Paket (oder besser Maxibrief *grübel*) bei dir abgegeben hat? Ich löse aber mal nicht, dann können die anderen noch mitspielen!
Ich hocke hier an meinem Sabayon Linux Hobel und bin etwas genervt da ich einen einfachen ping oder ping6 nur mit den erweiterten Rechten vom root ausführen kann.
$ ping www.kernel-error.de ping: icmp open socket: Operation not permitted
Um es mir einfach zu machen hilft es die Rechte an den beiden Programmen zu ändern:
$ chmod u+s /bin/ping $ chmod u+s /bin/ping6
Schon kann fast jeder User wieder pingen!
Ich sitze hier gerade vor einem Sabayon mit XFCE und wundere mich darüber dass der ClamAV nicht nach der Installation „out of the Box“ funktioniert.
Folgende kurze Schritte sind nötig damit er bei mir die Basisarbeit in aktueller Form aufnimmt 🙂
$ equo install app-antivirus/clamav $ cp /etc/freshclam.conf.sample /etc/freshclam.conf $ systemctl enable freshclamd.service $ systemctl enable clamd.service $ systemctl start freshclamd.service $ systemctl start clamd.service
So long…
Im Grunde könnte es mir ja fast egal sein, welche Protokollversion und/oder Prüfsumme der Client verwendet um mit dem Server zu sprechen. Ist es denn noch nicht. Der Client verbindet sich mit dem Server. Dabei teilt der Client dem Server mit was er kann, der Server tut dieses ebenfalls. Dann einigen sich beide auf ein Protokoll und eine Prüfsumme. Dabei kann der Server wie auch der Client sagen welches ihm denn am liebsten wäre. Wenn sich nun beide für etwas unsicheres entscheiden, gehen die Daten unsicher über die Leitung 🙁
Warum also nicht dem Server sagen er soll nur die „sicheren“ Protokolle anbieten? Dieses lässt sich recht schnell erledigen, indem man in seine Apache 2 Serverkonfiguration folgendes aufnimmt:
SSLProtocol -ALL +SSLv3 +TLSv1 SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT
Die einzelnen Optionen sind so schön benannt, dass man sich nicht mal mehr erklären muss, oder? Denn noch verlinke ich natürlich gerne hier hin: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html
Nachteile hat das ganze natürlich auch… Ältere Clients oder Systeme welche dummerweise kein passendes Protokoll / Chipher unterstützen, können keine verschlüsselte Verbindung mehr aufbauen. Meine Erfahrung zeigt aber, wenn man den Menschen die Möglichkeit gibt einfach durch die Sache zu kommen, machen sie es auch! Ich meine damit: „Solange es irgendwie funktioniert.“ Kümmert sich kaum jemand um ein Upgrade auch die Entwickler komme nicht aus dem Quark. Natürlich darf man nicht nach der Verabschiedung des neusten Standards die vorherigen fallen lassen…. Nur klar unsichere und seit Jahren überholte, die darf man dann schon mal los lassen (Windows XP *hust*).
Ach ja, möchte man einen Server testen gibt es mehrere Möglichkeiten. Am einfachsten ist sicher: https://www.ssllabs.com/ssldb/index.html Wer es lieber selbst auf der Konsole machen möchter, der freut sich sicher über sslscan http://sourceforge.net/project/showfiles.php?group_id=204329
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?
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.
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!
Sicher ist es schon aufgefallen…. Ich habe die Einstellung meiner Webseite so verändert dass nun SSL/TLS gesicherte Verbindung „erzwungen“ ist.
Nun hoffen wir mal dass ich damit keinen „abhänge“ 😀 Sollte es also Probleme geben, einfach mal melden!
Na wunderbar, mein Class 2 x.509 S/MIME Zertifikat läuft in kürze aus. Die Class 2 Validation ist auch ausgelaufen, also muss ich wohl was tun, hm?
Schnell alles bei StartSSL angeschoben und auf den bekannten Anruf irgendwo aus Israel warten… Es klingelte auch aber aus 001 213-341. Die Landesvorwahl ist USA und mein Android meint der Rest wäre etwas aus Los Angeles, CA! Das hat mich etwas überrascht; whatever. Wie gewohnt war das Gespräch schnell erledigt. Wobei die Dame am anderen Ende der Leitung extrem schlecht zu verstehen war. Nun warte ich also auf die Bestätigung meiner Class 2 Zertifizierung.
*UPDATE*
Na wunderbar:
### Schnipp ###
To Sebastian Van De Meer,
This electronic mail message was created by StartCom’s Administration Personnel:
Congratulations! Your Class 2 Identity Validation has been confirmed and approved. You are eligible for certificates at Class 2 level until 2014-05-01.
Additionally you have been awarded with StartSSL™ Web-of-Trust Notary status due to your fulfilling of all requirements. Well done!
Best Regards
### Schnapp ###
Dann kann ich ja gleich mal von diesem Zertifikat:
Seriennummer: 13:27
SHA1-Fingerprint: 28:AE:4C:96:51:75:EB:18:03:F9:9E:E3:7A:ED:C7:EA:13:8B:44:99
Zu diesem Zertifikat wechseln:
Seriennummer: 33:97
SHA1-Fingerprint: 7F:8B:92:19:FF:07:BF:EB:8E:E0:18:D4:98:B8:48:DF:E3:0E:4A:85
© 2026 -=Kernel-Error=- — RSS
Theme von Anders Norén — Hoch ↑