Bestimmte Google-Suchergebnisse in Google Chrome blockieren

Da ich in den letzten Tagen einiges mit CSS gemacht habe und in diesem Thema noch recht neu bin, habe ich mir, wer hätte das gedacht, durch Google weitergeholfen. Dabei fällt einem ziemlich schnell auf, dass die obersten Ergebnisse so gut wie immer von W3Schools kommen, was ich nicht unbedingt begrüße.

Um dieses Problem endgültig aus der Welt zu schaffen, hab ich erneut Google um Rat gebeten und bin auf ein von Google selbst entwickeltes Add-On namens “Personal Blocklist” gestoßen

 

Durch das Add-On wird nun unter jedem Ergebnis die Möglichkeit gegeben, die Angezeigte Webseite zu blockieren.

 

Und schon ist W3Schools von der Bildfläche verschwunden, jedenfalls für mich.

 

Durch einen Klick auf das Add-On Icon oben rechts im Browser, lässt sich die Blockliste öffnen und bearbeiten. Hier können Webseiten auch blockiert werden während man sie besucht.

 

Noah Hilverling

Autor: Noah Hilverling

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter, oder schwingt sich auf sein Mountainbike.

WLAN in deutschen ICEs

WIFIinICE

WLAN im Zug

Seit Anfang diesen Jahres wurde die Angebotspalette in den deutschen ICE Zügen um ein kostenloses WLAN in allen Klassen erweitert. Das kommt den viel reisenden Kollegen von Netways zu gute, welche oft im Zug unterwegs sind. Sei es jetzt unser Consulting Team, der Vertrieb auf dem Weg zum Kundentermin oder unsere Event Abteilung unterwegs zum nächsten Highlight.

Wir wollen das Ganze aber mal etwas genauer unter die Lupe nehmen und schauen, warum es besser ist als ein Hotspot per Handy oder Tablet mit seinem eigenen Mobil-Provider. Hintergrund ist die Technik, welche mit dem Partner Icomera aus Schweden zum Einsatz kommt. Sie koppelt sich parallel zu den 3 großen Anbietern (Telekom, Vodafone, Telefónica) um eine stabile und dauerhafte Verbindung herzustellen und zu gewährleisten. Damit werden Unterbrechungen auf ein Minimum reduziert und treten meist nur in langen Tunnelfahrten auf. Man bleibt aber verbunden und kann im Anschluss sofort weiter surfen.

Zu erwähnen ist noch ein Datenvolumen von 200 MB pro Tag in der 2. Klasse. Ist das Volumen aufgebraucht, wird die Geschwindigkeit reduziert, damit alle Passagiere eine gleichbleibenden Qualität nutzen können. Die Geschwindigkeit nach der Drosselung ist aber noch höher als man sie von Mobilanbietern kennt. Jedoch sollten 200 MB in den meisten Fällen pro Fahrt für eine normale Nutzung ausreichen. Es ist daher zu empfehlen, die WLAN Verbindung als ‘getaktet’ zu markieren um Hintergrundaktivitäten seiner Geräte zu mindern. Unnötige Downloads, Updates oder Streams sollten ebenfalls vermieden werden.

Werfen wir noch einen Blick auf die Sicherheit. Dabei kommen viele moderne Umsetzungen und bekannte Technologien wie z.B. die Client Isolation zum Einsatz. Jedoch ist das ganze immer noch ein HotSpot Angebot und ein Abfangen von Informationen kann nicht grundsätzlich ausgeschlossen werden. Nutzern mit sensiblen Daten wird daher die Verwendung einer VPN Verbindung und das surfen per HTTPS empfohlen.

Als Schlusswort kann ich die Nutzung nur empfehlen und begrüße das neue WLAN in den ICEs. Da ich selbst jede Woche sehr oft 5-6 Stunden pro Fahrt unterwegs bin, kann ich so mein Büro mitnehmen und die Zeit sinnvoll nutzen.

Bei weiterem Interesse, kann man sich auf den Portalen der Deutschen Bahn informieren (hier und hier)

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

TLS Konfiguration von Icinga 2 mit collect_ssl_info checken

In Icinga2 und dessen Kommunikationsprotokoll ist SSL/TLS die Kommunikationsbasis. Transportverschlüsselung von Daten ist heute weit verbreitet wie das Beispiel HTTPS zeigt. Die technische Grundlage ist SSL/TLS. SSL steht für Secure Socket Layer und TLS bedeutet Transport Layer Security. Transportlayer Security ist nur eine neuer Name der die Weiterentwicklung verdeutlichen soll. Die entscheidende Grundlage ist die Standardisierung dieser Kommunikation um möglichst vielen Kommunikationspartnern eine problemlose Kommunikation zu ermöglichen.

Die Kryptographische Grundlagen sind mehrere Algorithmen für Datenhashing und Verschlüsselung die sich in vier Gruppen aufteilt. Die erste Gruppe sind Securehashe. Beim Hashing besteht die Aufgabe von Quelldaten eine Quersumme zu erzeugen die zweifelsfrei nur von identischen Daten identische Quersummen erzeugt und gleichzeitig einen Rückschluss von der erzeugten Quersumme, Hashwert auf die Quelldaten unmöglich macht. Die zweite Gruppe sind symmetrische Chiffrierer. Bei Symmetrischer Verschlüsselung muss zuallererst ein geheimer Schlüssel erzeugt und nur an den Kommunikationspartner übermittelt werden. Danach wird ein symmetrisches Verfahren vereinbart und mit dem geheimen Schlüssel die Daten an der Quelle verändert und diese Transformation am Ziel wieder Rückgängig gemacht. Für alle unbeteiligten sind diese veränderten Daten unleserlich und damit wertlos. Die Dritte Gruppe sind asymmetrische Chiffren. In den siebziger Jahren wurden Asymmetrische Verfahren erfunden. Der erste Algorithmus der sich verbreitet hat trägt den Namen RSA nach den Anfangsbuchstaben der Entwickler. Wesentliches Prinzip ist hier dass immer zwei komplementäre Schlüssel erzeugt werden wobei immer was mit dem einen Schlüssel verändert wurde kann nur mit dem zweiten Schlüssel rückgängig und wieder lesbar gemacht werden. Und weiter kann von einem Schlüssel nicht der andere hergeleitet oder erzeugt werden. Das bietet die schöne Möglichkeit einen Schlüssel zu veröffentlichen und den anderen geheim zu halten. Da jetzt beliebig viele diesen öffentlichen Schlüssel anwenden und damit Daten verschlüsseln können und nur der Besitzer des zweiten geheimen Schlüssels dies Daten wieder lesbar machen kann, sonst niemand und damit entfällt die Notwendigkeit zwischen Beteiligten geheime Schlüssel vorher austauschen zu müssen. Noch erwähnen möchte ich eine vierte Gruppe, die Schlüsselaustauschprozeduren wie beispielsweise Diffie-Hellman. Solche Verfahren ermöglichen es ein gemeinsames Geheimnis, geheime Schlüssel, zwischen zwei Partnern zu verabreden ohne das Dritte durch abhören erfahren können was ausgehandelt wurde.

Im praktischen Einsatz werden meist alle verfahren kombiniert eingesetzt um damit die Aufgaben

  • Identitätsfeststellung
  • Massendatenverschlüsselung
  • Datenauthentizität
  • Schlüsselaustausch

zu bewältigen. Asymmetrische Verfahren bieten bisher nur geringen Datendurchsatz und sind für Massendaten kaum zu gebrauchen, bieten aber die Möglichkeit der Identitätsfeststellung indem man mit dem öffentlichen Schlüssel ein bestimmtes Datenmuster verschlüsselt, zur Gegenseite transferiert mit der Aufforderung zu entschlüsseln, das Muster zu invertieren und mit dem zweiten privaten Schlüssel zu verschlüsseln und wieder zurückzusenden. Kann an der Datenquelle die Antwort mit dem öffentlichen Schlüssel wieder erfolgreich entschlüsselt werden und liefert das erwartete invertierte Bitmuster, ist sichergestellt dass am andern Ende der zugehörige private Schlüssel vorhanden ist und somit ist die Identität festgestellt. Bisherige Asymmetrische Verfahren benötigen zur ausreichenden Schlüssel-härte größere Schlüssellängen. Schlüssel-härte bezeichnet die Resistenz gegen Knacker. Als neue Verfahren sind in den letzten Jahren EC Verfahren, Elliptische Kurven Kryptographie, dazugekommen, die erheblich härtere Schlüssel haben und damit deutlich kürzer sein können. Ein Vergleich, beim RSA Verfahren sind weniger als 2048 Bit als unsicher anzusehen, hingegen ECDSA erreicht die gleich Härte schon mit gut 200 Bit Schlüssellänge. Mit Symmetrische Verfahren können Massendaten am schnellsten codiert werden und sie bieten eine relativ hohe Schlüssel-härte. Symmetrische Verfahren sind bereits mehrere tausend Jahre bekannt und es gibt viele verschiedene davon. In neuere Zeit hat sich hier der AES, Advanced Encryption Standard, verbreitet. 128 Bit lange Schlüssel sind heute bei diesem symmetrischen Verfahren schon als hart und damit als sicher zu betrachten. Aber beide Kommunikationspartner brauchen denselben geheimen Schlüssel und der muss vorher sicher erzeugt und ausgetauscht werden. Hier kommen Schlüsselaustauschprozeduren wie DH, Diffie-Hellman oder die neuere Variante ECDH, Elliptische Kurven Kryptographie Diffie Hellman zum Einsatz oder alternative werden auch asymmetrische Cipher dazu eingesetzt. Und nicht vergessen möchte ich die Aufgabe übermittelte Daten auf Authentizität zu prüfen und jede Veränderung zu bemerken und solche Daten als falsch abzuweisen wozu wieder Hashverfahren angewendet werden, mein HMAC bezeichnet, Hashed Message Authentication Code

Zusammengefasst

  • Symmetrische Verfahren arbeiten performant aber benötigen ein gemeinsames Geheimnis
  • Asymmetrische Verfahren arbeiten langsam aber verwenden zwei komplementäre Schlüssel die als privat und öffentlich bezeichnet werden
  • Secure Hashe bilden Prüfsummen von Daten
  • Schlüsselaustauschprozeduren handeln Geheimnisse aus

So besteht heute die Aufgabe öffentliche Schlüssel und Daten zu Personen, Firmen oder Rechnern zuzuordnen. Dazu haben sich mehrere Arbeitsabläufe etabliert. Manche, handeln nach dem Prinzip des Web of Trust, also wer kennt wen und vertraut wem und welche Schlüssel gehören zu wem. Andere handeln nach der Standardisierung x509, einem ITU-T Standard. Zur Erfüllung dieses Standards haben sich sogenannte Trustcenter etabliert die sich in zwei Aufgaben splitten der CA und der RA. CA bedeutet Zertifikatsautorität und hat zur Aufgabe kryptographisch Schlüssel und Datenzugehörigkeit zu beweisen in Form eines x509 Zertifikats. Der zweite Teil besteht aus der Registrierungs Autorität und der Aufgabe die Verifikation von Kundendaten wie Adresse, Firmenname, Rechnernamen und bei Fehlern Zertifikate zu verweigern. Ein Zertifikat enthält dann diese Daten, einen öffentlichen Schlüssel und die Signatur durch die CA.

Signaturen sollen Datenauthentizität sicherstellen. Dazu wird über die als korrekt bewerteten Daten mit einem Secure Hase eine Prüfsumme erstellt und mit dem privaten Schlüssel der CA verschlüsselt. Diese CA stellt ihren öffentlichen Schlüssel mit Ihren Daten als x509 Root-Zertifikat aus und hat diesen normalerweise bereits weit verteilt in Webbrowsern oder anderen Programmen. Eine zu jeder Zeit durchführbare Authentizitätsprüfung wiederholt den Schritt die Quersumme aus den vorhandenen Daten, wie Rechnernamen neu zu erzeugen, die verschlüsselte Quersumme in der Signatur mit dem öffentlichen Schlüssel der CA aus deren Zertifikat zu entschlüsseln und zu vergleichen. Sind beide identisch, so ist damit die Authentizität bewiesen. Solche Zertifikate können mehrstufige Ketten bilden und beginnen immer mit einem Root-Zertifikate der CA, einem Zwischenzertifikat und dem Server oder Clientzertifikat am Ende das dann in Massen ausgestellt wird.

Heute wird sehr oft SSL/TLS angewendet. Transport Layer Security beschreibt eine große Zahl von verfügbaren Ciphern, Chiffrierverfahren, deren Anwendung, Protokollen und besonders das jeweilige Handshake Protokoll, also das Aushandeln vom Kommunikationsparametern. Für SSL stehen mehrere Softwarepakte zur Verfügung die durch die Standardisierung untereinander in der Kommunikation kompatibel sind und verschlüsselt kommunizieren können. Diese Softwarepakete werden in der Regel in Kommunikationsprogramme als Bibliotheken eingebunden. Solche um SSL erweiterten Programme haben oft ein “S” für Secure im Namen. Das SSL/TLS-Protokoll enthält heute das TLS-Record-Protokoll das die über TCP, Transmission Controll Protocol, die zu transferierenden Datenblöcke behandelt. Darüber werden die TLS-Protokolle, TLS-Handshake, TLS-Cipher-Spec, TLS-Alert-Protocol und das TLS-Application-Protocol transportiert. Für die praktische Anwendung werden fast immer mehrere Algorithmen kombiniert eingesetzt um Identitäten fest zu stellen, das gemeinsame symmetrische Verfahren zu vereinbaren und den gemeinsamen geheimen Schlüssel zu erzeugen und für beide Seiten zugänglich zu machen. Über TLS-Handschake beginnt die Kommunikation, wer ist wer, über TLS-Cipher-Spec wird der Symmetrische Cipher mit Parametern vereinbart. Anschließend werden Meldungen über das Alert-Protocol und die Massendaten über das TLS-Application-Protokoll transportiert.

Das TLS-Handshake-Protocol arbeitet beim Verbindungsaufbau diese Schritte ab

  1. Client schickt zum Server ein Hello
  2. Server identifiziert sich beim Client mit seinem Zertifikat
  3. Client kann sich bei Server mit seinem eigenen Zertifikat ausweisen oder mitteilen dass er keines hat
  4. Sind die vorangegangenen Schritte akzeptiert wird ein einmaliger gemeinsamer Schlüssel nur für diese Verbindung vereinbart, und im Abstand von Stunden geändert

Über das Alert-Protocol verständigen sich die Kommunikationspartner über verschiedene Events während der Kommunikation wie zB Datenblöcke fehlerhaft übermittelt oder andere Ereignisse.

x509 Zertifikate können also auch zur Authentisierung von Clients gegenüber Servern verwendet werden, sodass ein Server dies Zertifikate auf Zugehörigkeit oder weitere Angaben prüfen und dann zur Kommunikation akzeptierten oder ablehnen und die Verbindung beenden oder mit User und Passwortcheck fortfahren kann. Dies Möglichkeit bietet sich für automatische Verbindungen zwischen Servern oder Systemkomponenten an. Eine solche hierarchische x509 Zertifikatskette wird von Icinga 2 zur Authentisierung verwendet. Dabei existiert ein Root-Zertifikat einer CA auf einem Icinga 2 Server. Mit dem privaten Schlüssel dieser CA werden dann für jeden Kommunikationspartner eine eigenes x509 Zertifikat erzeugt. Entscheidender Teil ist der korrekte Rechnername, FQDN, Full qualified Domain Name. Danach erhält jeder Kommunikationspartner sein eigenes Zertifikat, den privaten Schlüssel und das Rootzertifikat der Icinga 2 CA.

Damit kann nur kommunizieren wer die “Erlaubnis” per Zertifikat hat, also ein Zertifikat das in diesem Baum signiert ist und wenn, dann nur verschlüsselt. Zur weiten Detaillierung können in Icinga 2 Konfigurationsdateien die TLS Version und die erlaubten symmetrischen Cipher definiert werden. In jedem Zertifikat ist der Servername hinterlegt und damit wird die Kommunikation nur von diesem System mit einem Zertifikat aus dem Icinga 2 CA Baum angenommen. Im Unterschied zu Zertifikaten von Webservern akzeptiert Icinga 2 keine Metazeichen im Rechnernamen.

Beispieleinträge in einer /etc/icinga2/features-enabled/api.conf Datei

protocolmin = "TLSv1.1"
cipher_list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256"

Als Erweiterung zur Erleichterung der Einrichtung und Erstkontaktaufnahme mit dem Icinga 2 Server von Systemen mit Agenten werden sogenannte Tickets verwendet. Solche Tickets leiteten sich aus dem Root-Zertifikat, und dem Systemnamen des Agenten, FQDN, ab.

Erzeugen kann man Tickets auf zwei Arten

icinga2 pki ticket --cn mein.agent.de
c4eb335a1e62c4779bed3901eaa245699d92817b

oder via rest-api

curl -k -s -u apiuser:apipassword -H 'Accept: application/json' \
-X POST 'https://IcingaCAServer:5665/v1/actions/generate-ticket' \
-d '{ "cn":"mein.agent.de" }' | python -m json.tool

Und dieser API-User muss natürlich angelegt sein und sollte nur Rechte für generate-ticket haben. Das wird in der api-users.conf eingestellt

object ApiUser "apiuser" {
  password =  "apipassword"
  permissions = [ "actions/generate-ticket" ]
}

Für Administratoren stellt sich Aufgabe solche Sicherheitseinstellungen zu kontrollieren. Und dazu gibt es ein Toolchen das solche Einstellungen einfach über Netz abfragt, das Skript collect_ssl_info.

collect_ssl_info 192.xx.yy.zz:5665

fragt vom Icinga 2 Server das Zertifikat ab

collect_ssl_info 192.xx.yy.zz:5665 -showcerts

fragt die komplette Zertifikateskette ab

Und nun ein kleines Beispiel zur Abfrage nach schwachen Ciphern.

collect_ssl_info -qp -u 192.xx.yy.zz:5665 -u www.xyz.de:443 \
 -c RC4-MD5 -c AES128-SHA256 
===== begin ciphertest 192.xx.yy.zz:5665 =============
RC4-MD5                          failed
AES128-SHA256                    success
===== end ciphertest 192.xx.yy.zz:5665 ===============
===== begin ciphertest www.xyz.de:443 ==============
RC4-MD5                          failed
AES128-SHA256                    success
===== end ciphertest www.xyz.de:443 ===============

jetzt erzeugen wir listen für ein zweites Beispiel

host.txt

192.xx.yy.zz:5665
www.xyz.de:443

cipher.txt

RC4-MD5
AES128-SHA256

und erledigen den gleichen Job mit Anwendung dieser Listen

collect_ssl_info -qp -ul host.txt -cl cipher.txt 
===== begin ciphertest 192.xx.yy.zz:5665 ===============
RC4-MD5                          failed
AES128-SHA256                    success
===== end ciphertest 192.xx.yy.zz:5665 ===============
===== begin ciphertest www.xyz.de:443 ===============
RC4-MD5                          failed
AES128-SHA256                    success
===== end ciphertest www.xyz.de:443 ===============

Eine Übersicht über die Icinga 2 Konfigurationsparameter.

Configuration Attributes:

Name Description
cert_path Required. Path to the public key.
key_path Required. Path to the private key.
ca_path Required. Path to the CA certificate file.
crl_path Optional. Path to the CRL file.
bind_host Optional. The IP address the api listener should be bound to. Defaults to 0.0.0.0.
bind_port Optional. The port the api listener should be bound to. Defaults to 5665.
accept_config Optional. Accept zone configuration. Defaults to false.
accept_commands Optional. Accept remote commands. Defaults to false.
cipher_list Optional. Cipher list that is allowed.
tls_protocolmin Optional. Minimum TLS protocol version. Must be one of TLSv1, TLSv1.1 or TLSv1.2. Defaults to TLSv1.

Das Skript steht zum Download bereit und viel weitere Info zur Konfiguration von Icinga 2.

Siegfried Eichhorn

Autor: Siegfried Eichhorn

Siegfried ist ein Urgestein der IT, das die Dinosaurier noch selbst erlebt hat. Bei den ersten Projekten mit Open Source und Linux gabs noch komische Bemerkungen, aber das ist längst Geschichte. Nach vielen Projekten und Eskapaden hat er jetzt das Abenteuer NETWAYS gewagt und arbeitet dort als Consultant. Und wenn er da mal nicht arbeitet, genießt er Nürnberg.

Get ready with NETWAYS

This entry is part 1 of 11 in the series Azubis erzählen

nerd_of_awesome_by_movillefacepalmplz-d5qvmzxGet ready with NETWAYS! Das trifft für mich auf die letzten 3 Jahre zu, in denen ich meine Ausbildung hier bei NETWAYS absolvieren durfte. An meinem ersten Tag, hatte ich keine Ahnung von Linux, Servern geschweige denn von OpenSource. Aber das hat hier niemanden abgeschreckt und mir wurde über die Zeit alles nötige beigebracht um selbstständig arbeiten und lernen zu können. Verschiedene Linux Distributionen, Hardware und Verkabelungen im Rechenzentrum, Pflege der HQ-Infrastruktur, Kundensupport und auch die Entwicklung einiger Automatisierungsskripte waren unter anderem Teil meiner Ausbildung hier. Ich empfand es als großen Vorteil, Teil einer verhältnismäßigen jungen und aufstrebenden Firma zu sein, allein schon deswegen, weil man jeden einzelnen Kollegen beim Namen kennt. Aber auch deswegen, weil eine Firma wie diese, viele neue Produkte testet und versucht sie in den produktiven Einsatz zu überführen. Manchmal erfolgreich, manchmal eher weniger. So bekommt man sehr viel von der “neuen Technik” mit und sieht in manchen Situationen auch wie es nicht geht.

Besonders überrascht war und bin ich teilweise immernoch, über den Umgang miteinander. Es herrscht ein eher freundschaftliches Verhältnis, sodass man auch in der Freizeit oder nach Feierabend mal zusammen einen trinkt, die ein oder andere Feier miterlebt oder eine LAN-Party veranstaltet. Auch Konferenzen und Schulungen in Nürnberg, Berlin, Köln, Düsseldorf, Barcelona oder den USA waren bisher immer ein sehr angenehmes Erlebnis. Soweit also eine Firma, in der man jeden Tag aufs neue gern arbeitet.

Zu jeder Ausbildung gehört am Ende auch eine Abschlussarbeit in Form eines Projektes und dessen Dokumentation. Mein Projekt befasst sich damit, eine Docker-Registry aufzusetzen. In diesem Projekt war sehr viel gefordert. Ich musste mich in kurzer Zeit in ein neues Thema einarbeiten, eine virtuelle Maschine mit entsprechenden Anforderungen aufsetzen, Fehler korrigieren, so viel automatisieren wie möglich und alles anschließend dokumentieren. Als letztes gilt es dieses Projekt im Sommer einem Prüfungsausschuss zu präsentieren und sich deren Fragen zu stellen.

Nach erfolgreichem Abschluss meiner Ausbildung werde ich im Support arbeiten und versuchen unseren Kunden bestmöglich zu helfen. Ich freue mich auf die Arbeit und auch darauf weiterhin zu lernen und Erfahrungen zu machen.

Trotz alledem lernt man nie aus und es ist auch unmöglich alles beigebracht zu bekommen. Aber bei NETWAYS bekommt man eine sehr gute Vorbereitung auf den Alltag in der IT Branche nach der Ausbildung. Für den Fall, dass jemand auf der Suche nach einer geeigneten Firma ist, dann ist er bei uns an der richtigen Stelle!

 

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Blacklists prüfen mit check_rbl

The_Blacklist_logo.svgBlacklists sind prinzipiell nichts schlechtes. Sie helfen zu verhindern, dass ein Unternehmen oder eine Privatperson mit Spam oder ähnlichem Übel gestört werden oder vielleicht sogar Schaden davon tragen.
Gelegentlich kommt es jedoch vor, dass ein Unternehmen oder eine Privatperson auf einer Blacklist landen, obwohl sie keine negativen Absichten verfolgen. Ein Grund hierfür kann zum Beispiel das Versenden von Newslettern sein, wodurch ein erhöhtes Mailaufkommen von bestimmten Systemen verzeichnet wird und Mails als “Spam” markiert werde. Als Folge dessen wird für die versendenden Server ein Eintrag auf einer Blacklist angelegt. Der Nachteil für den Betroffenen ist, dass er keine Benachrichtigung bekommt, mit dem Hinweis, auf einer Blacklist markiert worden zu sein.

Wir bei NETWAYS wollen aber kontrollieren, ob unsere Server oder die von unseren Kunden bei gewissen Systemen einen Eintrag besitzen und können dies auch überprüfen. Eine sehr elegante Möglichkeit wird hierfür mit dem check_rbl gegeben. Dieser Check durchforstet gegebene Blacklists von Servern nach einem gefragten Server.
Ein kleines Beispiel wird die Funktionsweise aufzeigen:

check_rbl -t 60 -H netways.de \
-s cbl.abuseat.org \
-s dnsbl.cyberlogic.net \
-s bl.deadbeef.com \

So würde der Check überprüfen, ob Einträge für den Host “netways.de” auf den Servern, die mit dem “-s” Parametern übergeben wurden, vohanden sind und ein “warning” beziehungsweise “critical” auslösen. Eine weitere gute Erläuterung der Funktionsweise dieses Checks findet man auf GitHub oder auf dem Icinga-exchange.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Es trifft mich wie ein Blitz …

Java-Logo

… heute früh meldete Heise Security einen seit ca. neun Monaten bekannten Exploit, der sich als besonders kritisch einstuft.

Zu diesem Zeitpunkt war ich gerade in einem Meeting mit Bernd und bin fast aus allen Wolken gefallen, als Sebastian mit dieser Nachricht in der Tür stand.

Ich bot an dieser Meldung genauer auf den Grund zu gehen, da ich selber begeisterter Java Entwickler bin und mich wie vermutlich auch viele von euch direkt oder eben auch indirekt mit Java und dem erweiterten Stack tagtäglich beschäftige.

Im Netz kursiert seit dem 6. November der folgende Artikel, dessen Autor Herr Stephen Breen, sehr genau, fast schon spielerisch beschreibt, wie dieser Exploit denn genau funktioniert.

Er schreibt dort im wesentlichen über die in Java schon seit Version 1.1 verfügbare ‘Serializable’ Schnittstelle, die es dem Programmierer ermöglicht fertig instanziierte Java Objekte über das Netzwerk zu senden oder auch von Festspeichern zu lesen. Diese Klasse ist allerdings nur der kleinere Teil des Übels, genauer gesagt ist es die Methode “InvokerTransformer” der “Apache CommonCollections API” die hier über die “Java Reflections API” es einem möglichen Angreifer hier Kinderleicht macht seinen Schadcode auf dem Zielsystem zur Ausführung zu bringen.

Nun könnte man fast meinen das einen das ja nicht wirklich betrifft, da muss ich euch leider enttäuschen und das sogar berechtigterweise.

Folgende Szenarien um das Problem im wesentlichen zu konkretisieren:

  • Servlet Container sowie Application Server verwenden diese API, wie im Artikel zu lesen ist, auch um Cookies und HTTP Header zu lesen. Das ist im ersten Moment noch nicht so kritisch, nur werden heutzutage auch viele Cross-Site-Request-Forgery und andere Angriffe dazu verwendet die Systeme der Wahl erfolgreich zu attackieren.

    Ein Angreifer könnte versuchen über entsprechende HTTP Header mit Cookie Payload ein bösartiges Objekt seiner Wahl einzubetten, das wiederum wenn auf dem Ziel System einmal angekommen, im ersten Moment Zugriff auf die der dort laufenden Anwendung zu Verfügung stehenden Klassen nutzen kann. Hier ist es dann bereits ein leichtes dem Application Server bzw. ServletContainer einen separaten URL Context ( zum Beispiel unter http://application.yourdomain.com/nasty-little-exploit ) mit anderen Funktionen unterzujubeln. Et Voila der Schaden wäre bereits immens.

    Auch ein simpler Download als Injected Java Objekt könnte hier den Rest des Ziel Systems mit entsprechenden Schadcode über eine Art Bootstrap Job infizieren.

    Um dem vorher gehenden Beispiel noch einmal etwas Würze zu verleihen, einen bereits bestehenden URL Context einer großen Bank könnte so manipuliert werden, um Kundendaten abzugreifen. Auch hier wäre der Schaden nicht zu ermessen.

  • Die Software von Drittanbietern ist davon mit unter auch betroffen. Vor allem wenn sie die oben genannte Schnittstelle verwendet oder sogar muss. Hier sollte man schnell Handeln aber auf keinen Fall das Problem ignorieren. Allein anzunehmen das hier ja bereits verschlüsselte Kommunikation stattfindet, schütz vor diesem Exploit nicht.
  • Ich schlage ihnen daher vor, den Rat des Autors zu beherzigen und diese Schnittstelle aus der Apache CommonCollections API zu verbannen, allein die Nutzung der Application einzustellen um anschließend ein komplettes Refacturing der Anwendungen vorzunehmen verursacht vermutlich sehr hohe Kosten und ist hier mit der Gefahr verbunden sich einem weiteren Exploit zu schaffen, jedoch recht schnell geschehen. Schnelle Änderungen schaffen immer wieder neue Bugs und vermutlich auch neue noch unbekannte ZeroDay Vectoren.

Dem einen oder anderen von euch stellen sich hier vermutlich schon die Nackenhaare auf, daher wollen wir nun lieber über die Deeskalation bzw. möglichen Lösungen kümmern, was gilt es nun zu tun!?

  • Evaluieren ob die Apache CommonCollections API auf dem eigenen Systemen existiert.
  • Prüfen ob die eingesetzte Java Software von dieser Gebrauch macht.
    • Wenn dem so ist, sollte die Anwendung aus der DMZ entfernt werden, das blockieren der von außerhalb erreichbaren Ports genügt im ersten Moment bereits.
    • Wenn dem nicht so ist, dann Schwein gehabt.
  • Sofern die betroffenen Anwendungen ermittelt werden konnten, sollten folgende Punkte abgearbeitet werden.
    • Test der Anwendung in isolierter Umgebung ( Docker kann hierbei recht hilfreich sein ) mit der Apache CommonCollections API. Wobei vor Beginn die org/apache/commons/collections/functors/InvokerTransformer.class bereits aus der API entfernt sein sollte.

      Wenn es hier nichts zu beanstanden gibt und die Application auch ohne diese Schnittstelle zu laufen scheint, kann diese wieder in den Betrieb überführt werden.

    • Sollte die Anwendung nicht korrekt funktionieren, wird empfohlen diese unter Vorbehalt nur den eig. Mitarbeitern zur Verfügung zu stellen, sollte es sich bei der Anwendung allerdings, um eine des Kunden handeln, sieht es da schon etwas schwieriger aus, wobei sich vmtl. kein Kunde den damit einhergehenden Gefahren gerne ausgesetzt sieht.

      Hier sollte dem Kunden angeraten werden, die Application bis zu einem erfolgreichen Security Audit vom Netz zu nehmen.

Weitere Lösungsansätze sind derzeit noch nicht bekannt, wir versuchen euch aber entsprechend auf dem Laufenden zu halten.

Nützliche Links:

Link Inhalt
http://www.heise.de/security/meldung/Zero-Day-Alarm-fuer-viele-Server-mit-Java-2913605.html Heise Security Artikel
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ der Exploit im Detail
https://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections4/functors/InvokerTransformer.html Javadoc zum betroffenen Interface
https://github.com/frohoff/ysoserial das daraus entwickelte Framework für Penetration Tests
https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html Java CVE – Übersicht
Enrico Labedzki

Autor: Enrico Labedzki

Enrico ist beruflich ganz schön rumgekommen – IT hat ihn aber immer beschäftigt. Nach einem Ausflug in die Selbstständigkeit im Bereich Webentwicklung und Network Solutions, wurde es dann Zeit Nägel mit Köpfen zu machen und endlich den Weg als Softwareentwickler und Systemintegrator einzuschlagen. In seiner Freizeit widmet sich der passionierte Bastler der Elektrotechnik und Animatronik. Bei Netways bereichert er mit seinem vielseitigen Know-How das Managed Service-Team.