Zeit ist einzigartig

von Thilo Wening | Aug 21, 2015 | Network, Security, Linux, Puppet, Technology

Einige haben erst am 12. Dezember 2012 gemerkt, dass die Zeit einzigartig ist. CAs hingegen wissen das schon seit Längerem und wissen dies auch effektiv zu nutzen. Bei meinem letzten Setup bin ich wieder über diese Falle gestolpert: Die Einrichtung der externen CA und des Puppetmasters ging wie immer ohne Probleme, nur jegliche Zertifikate wollten nicht akzeptiert werden. Wer Puppet einsetzt wird diese Fehlermeldung sofort erkennen:
err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppet ]
Wir können in diesem Fall zum einen prüfen, ob unsere CA die selbe ist.
Mit OpenSSL können Zertifikate lesbar dargestellt werden.
openssl x509 -text -noout -in /path/to/ssl/certs/ca.pem | grep Issuer
In dem Output sollte dann eine Zeile mit dem Issuer zu sehen sein und wenn dieser mit der Puppet CA nicht übereinstimmt, müssen deren Einstellungen überprüft werden. Dabei können diese Befehle hilfreich sein.
sudo puppet master --configprint certname
sudo puppet master --configprint ca
Sobald aber hier alles richtig konfiguriert wurde, ist es zum anderen gut ein Auge auf die Zeit zu werfen.
Wenn die Zeit nicht stimmt kann es dazu kommen, dass Zertifikate in der Zukunft ausgestellt werden und diese für die CA keine Gültigkeit besitzen.
Ein einheitlicher Zeitserver kommt diesem Problem entgegen, denn mit ihm vermeiden wir Zertifikate in der Zukunft auszustellen. Wenn dieser nicht vorhanden ist, reicht ein einfaches:
sudo apt-get install ntp
und eventuell ein kurzer Neustart. Danach muss der Puppet Agent neu signiert werden. Dazu müssen alle Zertifikate gelöscht werden.
Auf dem Puppetmaster:
sudo puppet cert clean yourserver.localdomain
Auf dem Client:
sudo rm -rf /path/to/puppet/ssl/* #Default ist /var/lib/puppet/ssl/
Anschließend kann ein neuer Testlauf auf dem Agent ausgeführt werden, der dann ein neues Zertifikat generiert
sudo puppet agent --test
und durch den Puppetmaster validieren lässt.
sudo puppet cert sign yourserver.localdomain
P.S.: Achtet bei eurer Icinga2 HA Installation auch auf die Zeit, hier werden ebenfalls SSL Zertifikate benutzt und unterschiedliche Zeitserver können zu Zeitverschiebungen (im Projekt) führen. 😉

Thilo Wening

Manager Consulting

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

Lies mehr von Thilo und triff unser Team

Exchange SSL Error

von Martin Schuster | Jan 20, 2015 | Windows

Wir haben unsere interne Windows CA von SHA1 auf SHA256 umgestellt und alle Zertifikate erneuert. Soweit so gut, doch nach einem Neustart der Exchange Server konnten sich unsere Mailclients nicht mehr mit dem Exchange verbinden und OWA gab nach dem Login nur eine weiße Seite zurück.
In der Ereignisanzeige fanden wir folgenden Fehler:
An error occurred while using SSL configuration for endpoint
0.0.0.0:444. The error status code is contained within the returned
data.
Um dieses Problem zu lösen sind wir wie folgt vorgegangen:
netsh http show sslcert
IP:port : 0.0.0.0:444 Certificate Hash : Application ID : {4dc34hge........} Certificate Store Name : (null) Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled
Dieser Befehl zeigt die gebundenen Zertifikate an. Das relevante hierbei ist das Zertifikat für 0.0.0.0:444.
Dieses müssen wir nun löschen und neu zuordnen. Die Ausgabe kopieren wir uns vorher in ein Textfile.
netsh http delete sslcert ipport=0.0.0.0:444 iisreset
Nun brauchen wir den Hash aus unserem neuen Zertifikat und die Application ID, die wir uns in das Textfile
kopiert haben.
netsh http add sslcert ipport=0.0.0.0:444 certhash=XXXXXX appid=”{XXXXXXX}” iisreset

Martin Schuster

Senior Systems Engineer

Martin gehört zu den Urgesteinen bei NETWAYS. Wenn keiner mehr weiss, warum irgendwas so ist, wie es ist, dann wird Martin gefragt. Er hat es dann eigentlich immer mal schon vor Jahren gesehen und kann Abhilfe schaffen :). Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren oder zieht einfach um und fängt von vorne an.

Lies mehr von Martin und triff unser Team

Warum SSL nicht funktioniert

von Gunnar Beutner | Okt 30, 2014 | Security, NETWAYS

Zugegeben, der Titel ist sehr provokativ formuliert. Es soll hier auch gar nicht darum gehen, irgendwelche Sicherheitslücken direkt im SSL-Protokoll (bzw. TLS) oder einer der vielzähligen Implementierungen aufzuzeigen. Vielmehr möchte ich zeigen, dass Verschlüsselung, wie sie heutzutage an vielen Stellen eingesetzt wird, oft nicht mehr tut, als den Benutzer in Sicherheit zu wiegen.
Viele Webseiten unterstützen inzwischen Verschlüsselung – nicht zuletzt, da beispielsweise Google dies seit einigen Monaten in die Bewertung des Rankings einfließen lässt.
Seine Ziele erreicht SSL hier allerdings leider nur bedingt. Es wird zwar sichergestellt, dass die Webseite wie auch Benutzereingaben auf dem Transportweg z.B. durch transparente Proxies nicht verändert werden.
Trotz Verschlüsselung lassen sich von einem Angreifer, der die Netzwerkverbindung passiv abhören kann, dennoch viele Informationen ableiten:
1. Üblicherweise unterstützen Webseiten Redirects, die von HTTP auf HTTPS umleiten. Dabei wird allerdings die erste HTTP-Anfrage ohne Verschlüsselung abgesendet, aus der sich beispielsweise die vollständige URL erfahren lässt.
Zwar gibt es für dieses Problem die HTTP-Erweiterung HSTS, aber zum einen wird sie nur von den wenigstens Webseiten unterstützt und zum anderen greift sie nicht beim ersten Request.
2. Webseiten integrieren prinzipbedingt oftmals Bilder oder JavaScript-Dateien von anderen Webseiten. Selbst wenn diese auch über HTTPS-URLs eingebettet wurden, lässt sich zumindest feststellen, welchen Organisationen diese externen Webseiten gehören.
Beim Aufrufen eines WordPress-Blogs wäre es so beispielsweise nicht verwunderlich, IP-Adressen von Facebook, Google, Twitter und WordPress zu sehen, was z.B. darauf hindeuten würde, dass der Blog über Plugins für Social Buttons verfügt.
3. Anhand der in Punkt 2 ermittelten Daten lässt sich bereits ein recht guter Fingerabdruck erstellen. Noch eindeutiger wird dieser, wenn man die Download-Größe der Webseiten-Requests beobachtet. Viele Webseiten inkludieren beispielsweise eine unterschiedliche Anzahl an Bildern, die dazu beitragen, dass sich die Download-Größe von Seite zu Seite signifikant unterscheidet. Der technische Begriff dafür ist Traffic Analysis.
Um mit diesen Informationen Rückschlüsse auf die aufgerufene URL zu ziehen, müsste der Angreifer über einen Index aller aufrufbaren Seiten verfügen, um deren Download-Größe mit der tatsächlich aufgerufenen Seite zu vergleichen. Bei öffentlich zugänglichen Seiten ließe sich dieser Index mit Hilfe eines Web-Crawlers mit moderatem Aufwand erstellen.
Die beschriebenen Probleme gibt es natürlich nicht nur bei Webseiten. Wenn ich beispielsweise einen Blick in mein E-Mail-Postfach werfe, finde ich gerade einmal eine Handvoll signierter E-Mails und eine einzige verschlüsselte E-Mail. Alle anderen E-Mails liegen unverschlüsselt auf dem E-Mailserver meines Providers (Google).
Fragen Sie einfach einmal einen Ihrer Bekannten, ob deren E-Mails verschlüsselt sind: Dank großflächiger Werbemaßnahmen wie „E-Mail made in Germany“ und De-Mail wird Ihnen dieser die Frage sicher bejahen. Dumm nur, dass dabei nur die Verbindung zum E-Mailserver der Provider verschlüsselt ist, dieser aber dann die Mails im Klartext einsehen kann.

"Barrierefrei" mit OpenVPN

von Bernd Erk | Aug 12, 2008 | Technology, Security

Das Problem, bestimmte Netzdienste oder ganze IP-Bereiche nicht zu erreichen, ist für Journalisten bei der Olympiade zwar eine bittere Erfahrung, aber in der IT-Welt längst nichts Neues. In jeder größeren Firma verhindern die Firewalls Dienste wie Jabber, RDP, POP oder ähnliches. Dieses Problem lässt sich sehr einfach mit einem VPN-Tunnel auf den eigenen Server und dessen Nutzung für den Zugang in die weite Welt umgehen.
Bei den meisten kommerziellen VPN-Lösungen sind jedoch ebenfalls dedizierte Ports notwendig um eine solche Verbindung zu etablieren. Und damit können sie natürlich auch wieder gefiltert werden. Anders sieht das ganze bei OpenVPN aus. Ohne größere Mühen kann man den Server auf den Port 443 konfigurieren, der aufgrund des notwendigen SSL-Zugriffs meist auf den Firewalls geöffnet ist und somit eine Verbindung zum eigenen VPN-Server aufbauen. Somit ist dann auch die Nutzung entsprechender Dienste und vor allem eine sichere Übertragung möglich.
Neben diesen etwas unorthodoxen Möglichkeiten ist OpenVPN auch eine praktische Lösung, verschiedene Standorte sicher zu vernetzen oder Road Warriors mit Laptops an die Firmenzentrale anzubinden.

Bernd Erk

CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

Lies mehr von Bernd und triff unser Team

Nächste Einträge »