Was mein ist, bleibt mein

Auch wenn mich das als Egoist darstellt, sollte das jeder in Betracht ziehen. Jedenfalls wenn es um potentiell sensible Daten geht.

Ein Beispiel

Jeder der häufig im Internet unterwegs ist, sei es nun privat oder geschäftlich, kennt das. Eine Anmelde-Maske.

Wer auf Sicherheit wert legt, nutzt hoffentlich überall ein anderes Passwort. Selbstverständlich sind die auch in einem Passwort-Manager wie Keepass oder Enpass hinterlegt und mit einem sicheren Master-Passwort gesichert.

Aber mal ganz ehrlich, wer klickt im Browser bei der Frage “Soll dieses Passwort gespeichert werden?” nicht gerne auf Ja? Nun, ich hab es eine Zeit lang vermieden war aber jedes Mal traurig nicht auf Ja geklickt zu haben.

Warum? Weil ich eine üble Angewohnheit, wie viele andere wohl auch, habe.

Bequemlichkeit

Ich nutze ein Passwort niemals ein zweites Mal. Ich habe alle meine Passwörter in Keepass gespeichert. Diese Datenbank ist mit einem relativ komplexen jedoch noch leicht zu merkendem Master-Passwort versehen und mit meinem Yubikey gekoppelt. 2-Faktor Authentifizierung wie aus dem Buche.

Aber ich bin bequemlich. Jedes Mal Keepass aufzumachen und diese Prozedur durchzuführen, für jede Anmelde-Maske die ich im Laufe des Tages benutzen muss? Ein Graus. Selbstverständlich kann ich Keepass im Hintergrund offen lassen, aber das würde dem Gedanken der 2-Faktor Authenfizierung widersprechen. Sicher, Keepass schützt die Passwörter vor unerlaubten Speicherzugriffen und derlei Späßen, jedoch hab ich dennoch kein gutes Gefühl dabei.

Aber warum speichere ich dann nicht einfach die Passwörter mit Hilfe des Browsers? Werden die dort nicht auch sicher gespeichert? Na, selbstverständlich werden sie das. Doch das Problem ist ein ganz anderes.

Das schwache Glied

Die Frage ist nämlich nicht wie die Passwörter vom Browser gespeichert werden, sondern wie erneut auf sie zugegriffen wird.

Ich setze Ubuntu 18 ein. Hier werden derart gespeicherte Passwörter im GnuPG-Schlüsselbund hinterlegt. Dieser wird bei jedem Login auf dem System entsperrt. (Oder beim entsperren des Systems.)

Nun, der aufmerksame Leser wird sich nun denken können weshalb ich das als schwaches Glied in der Kette ansehe. Ich bin bequemlich, welch Überraschung. Wenn ich das System entsperren muss, möchte ich nicht erst ein super sicheres Passwort eintippen müssen. Erst recht nicht während jemand daneben steht/sitzt. Je komplexer das Passwort nämlich, desto langsamer tippe ich es. Je langsamer ich tippe, desto eher steigt die Gefahr mir schaut jemand dabei zu. (Kollegen vertraue ich selbstverständlich, aber man weiß ja nie wo man sonst ist.) Deshalb: Es ist ein einfaches Passwort das super schnell getippt ist.

Falls aber doch jemand, oder etwas, Kenntnis von diesem Passwort erlangt war alles für die Katz. Sofort sind alle Passwörter aus dem GnuPG-Schlüsselbund gefährdet. Da hilft nur eines.

Die Lücke schließen

Zum Glück hat meine Bequemlichkeit doch ihre Grenzen. Denn ich fahre mein DELL XPS 13 grundsätzlich immer herunter wenn ich es länger aus den Augen lasse.

Somit ist diese Lücke auf einen Schlag verschlossen sobald der gesamte Festplatten-Inhalt verschlüsselt ist. Und das ist er inzwischen. LUKS sei dank.

Auch hier kommt es auf die Qualität der gewählten Passwörter an, schließlich muss vor dem Start des Systems erst einmal alles entschlüsselt werden können. Aber Achtung: Ein zu schwaches Passwort ist erneut das schwache Glied.

Hier habe ich einen Kompromiss mit meiner Bequemlichkeit geschlossen. Ich habe zwei Möglichkeiten meine Festplatte zu entschlüsseln. Zum einen ein super sicheres Passwort (das nicht im Wörterbuch zu finden ist), zum anderen aber auch ein leicht zu merkendes. (Das aber auch nicht im Wörterbuch zu finden ist, jedenfalls nicht 1:1) Der Clou jedoch ist, das zweite (einfache) Passwort ist mit dem Yubikey gekoppelt.

Ein Hoch auf die 2-Faktor Authentifizerung

Man merkt es vielleicht. Ich bin ein Fan meines Yubikeys. Besser gesagt, meiner zwei Yubikeys. (Es könnte ja einer abhanden kommen) Auf die technischen Details gehe ich jetzt nicht mehr ein, das macht zum Teil bereits Marius. Doch kurz auflisten wofür ich ihn noch einsetze möchte ich:

  • GPG (Private subkeys auf dem Yubikey)
  • SSH (Dank GPG, Gunnar hatte hierzu bereits etwas geschrieben)
  • Github (FIDO U2F)

Außerdem ist mein zweiter (privater) Yubikey NFC fähig, ich kann ihn also super easy mit der Keepass App auf dem Smartphone nutzen.

Was mein ist, bleibt mein!

Johannes Meyer
Johannes Meyer
Developer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.

RFID & NFC

Die Namen RFID und NFC sind uns bestimmt irgendwo schon mal begegnet, aber viele wissen gar nicht was das ist oder was diese zwei “Dinge” machen.
RFID steht für “radio frequency identification” und ist eine Technologie (Sender-Empfänger) mit der man Daten kontaktlos speichern, lesen und verändern kann.
NFC steht für “Near Field Communication”, basiert auf RFID und ist auch eine Art mit der man Daten über wenige Zentimeter austauschen kann. Merke: NFC ist eine spezielle RFID Technik.
Einsatz
Immer mehr Banken statten die Kredit- und Debitkarten mit NFC-Chips aus, damit die Kunden an den Kassenterminals der Märkte kontaktlos zahlen können. Zu erkennen ist es am WLAN-ähnlichem Symbol.

Natürlich gibt es diese Technologie auch woanders, zum Beispiel bei Zutrittskontrollen oder für die Zeiterfassung. Auch zwei NFC-fähige Smartphones können untereinander Musik, Bilder, Videos usw. austauschen. Im Teil “Projekte” dieses Blogpost werde ich ein paar Projekte ansprechen, die man auch zu Hause nachmachen kann.
Aber wie funktioniert das Ganze?
RFID arbeitet in drei verschiedenen Frequenzen: 125 kHz – 135 kHz, 13,56 MHz und 860 MHz – 960 MHz. Beim Hinhalten des Transponder erzeugt das Lesegerät ein elektromagnetisches Wechselfeld. Das dient während der Kommunikation als Stromquelle für den Chip. NFC arbeitet dagegen mit einer Frequenz von 13,56 MHz. Haben beide NFC-Chips, so muss man diese einfach nah aneinanderhalten und die Kommunikation kann beginnen.
Vorteile
RFID: mehrere Meter Reichweite. NFC: schnelles, bequemes Bezahlen an Kassen.
Nachteile
RFID: über größere Distanzen auslesbar (je nach Frequenz). NFC: nicht an jeder Kasse verfügbar.
Schutz
Wer denkt, dass diese Technologie sicher ist, der denkt falsch. Denn es gibt viele Angriffsmethoden. Beim “Sniffing” werden während der Übertragung die Daten mit einem Lesegerät ausgelesen. So können Kriminelle auch neuere Autoschlüssel kopieren und ins Auto einsteigen. Sie können sich auch zwischen Sender und Empfänger reinhängen, die zu übertragenden Daten ändern und dem Empfänger weiterschicken. Dagegen hilft ein Schreibschutz. Wer aber eine Bankkarte besitzt, die eine NFC-Funktion hat, der kann sich eine spezielle Hülle oder einen speziellen Geldbeutel kaufen (z. B. auf ebay: RFID-, NFC-Blocker). Wer aber keine Lust hat Geld auszugeben, kann die Karte auch mit Alufolie einwickeln. 🙂  Was wir also wissen ist, dass noch viel in der Sicherheit verbessert werden muss.
Projekte
Im Internet gibt es zahlreiche Projekte, unteranderem mit einem Raspberry Pi in Verbindung mit einem RFID-Reader. Man könnte für Zuhause mit Hilfe einer App einen NFC-Tag (oder auch Transponder genannt) so programmieren, sodass er beim Hinhalten an das Handys eine WLAN-Verbindung für das Gerät herstellt. Auch sehr beliebt ist ein Schließmechanismus für eine Box, der nur aufgeht, wenn man seinen Transponder dabei hat.

Loei Petrus Marogi
Loei Petrus Marogi
Junior Developer

Loei ist Fachinformatik-Azubi im ersten Lehrjahr und lernt momentan unseren Toolstack kennen. Nach der Linux-Schulung freut er sich besonders aufs Programmieren. Wenn er mal nicht bei NETWAYS ist, spielt er Fußball im Verein oder geht ins Fitnessstudio.

HAProxy und SQL Grants

In diesem kurzen Beitrag will ich auf einen Fallstrick im Bezug von HAProxy und SQL Backends wie MySQL oder MariaDB eingehen. Speziell geht es um Grants und die damit verbunden Quell Hosts. Diese werden bei einem Standard Setup mit HAProxy durch die IP des Proxys ersetzt. Solange man sich in dem selben Netz wie die DB Server und dem Proxy befindet und die Host-Beschränkungen nicht all zu streng sind, kann es gut sein, das man dieses Szenario nicht erreicht. Sobald die Verbindungen aber Netz übergreifend erfolgen und die Grants damit umso wichtiger sind, kommt das Detail zum Tragen und stellt einen vor neue Herausforderungen. Dafür gibt es an sich schon etwas länger das Proxy Protokoll, welches aber erst nach und nach in mögliche Backend Software implementiert wurde/wird. Bei MariaDB war es mit der 10.3.1 z.B. erst Ende letzten Jahres soweit.
Die Arbeitsweise des Protokolls beschreibt sich einfach gesagt so, dass mit dem Aufbau der Verbindung zuerst ein zus. Header geschickt wird, in dem die IP des Quell Hosts bekannt gegeben wird. Dazu muss das Backend jedoch von der IP des HAProxys das Proxy Protokoll erlauben. Das Ganze drum rum kann mit Seiten über weitere Details und Sicherheit befüllt werden. Damit verschone ich Euch aber und weise nur auf eine schlichte Zusammenfassung im Blog von HAProxy hin.

Canonical schließt Lücken in Ubuntu 18.04 LTS

Common Vulnerabilities and Exposures (CVE) ist ein Industriestandard, dessen Ziel die Einführung einer einheitlichen Namenskonvention für Sicherheitslücken und andere Schwachstellen in Computersystemen ist. Mehrfachbenennung gleicher Gefahren durch verschiedene Unternehmen und Institutionen werden um eine laufende Nummer ergänzt, um eine eindeutige Identifizierung der Schwachstelle zu gewährleisten. Dadurch ist ein reibungsloser Informationsaustausch zwischen den verschiedenen Datenbanken einzelner Hersteller möglich.

Canonical hat ein neues Kernel-Update für Ubuntu 18.04 LTS veröffentlicht, indem Lücken, die im VirtIO-Subsystem und dem ACPI Kernel stecken, gepatcht werden. Eine Lücke in der Speicherinitialisierung (CVE-2018-1118) im VirtIO-Subsystem des Kernels, die nicht immer funktionierte, wurde entfernt. Hier konnte ein Angreifer über einen lokalen Zugriff vertrauliche Informationen erhalten. Die zweite Lücke betrifft das ACPI (Advanced Configuration and Power Interface) des Kernels wodurch auch ein lokaler Angriff Erfolg hätte.
Außerdem gab es mehrere Schwachstellen in der PHP-Komponente FPM und EXIF bei denen Angreifer auch lokal mit speziell präpariertem PHP-Skripten die Vorbereitung von verschiedenen DoS-Angriffen ausführen konnten. Später dann auch aus der Ferne steuerbar. Die Schwachstellen CVE-2018-14851 und CVE-2018-14883 lassen den Angreifer beliebigen Programmcode ausführen. CVE-2015-9253 lassen sich aus der Ferne für DoS-Angriffe auf geteilte PHP-Server ausführen.
Die Updates stehen seit längerem für Ubuntu 18.04 LTS, 16.04 LTS und 14.04 LTS bereit.

Aleksander Arsenovic
Aleksander Arsenovic
Junior Consultant

Aleksander macht eine Ausbildung zum Fachinformatiker für Systemintegration in unserem Professional Service. Wenn er nicht bei NETWAYS ist, schraubt er an seinem Desktop-PC rum und übertaktet seine Hardware. Er ist immer für eine gute Konversation zu haben.

Adfree Internet with pi-hole

There are two ways to motivate people: intrinsic, motivation stems from the person her/himself or extrinsic, where an external force pushes a person to do something.
I myself experienced this external motivation when I bought a new TV and wanted to test the YouTube-Application.
Using ublock origin on both private and work-related devices, I was surprised by the amount of advertisements being displayed – before and during the video.

mildly annoying, no offense Ben Schmid!


I don’t want to dive to deep into the discussion whether ads and tracking are good or bad, but show you a way how to get rid of most of the ads in your network.
One of the most basic protocol of the internet is DNS. It resolves Domain Names (like nws.netways.de) that you type into your browser to IP Adresses (185.11.252.146) which the browser then invokes. A common analogy would be “phone directory of the Internet”. This is the part we’re going to have closer look on.
Most ad blocking techniques use lists of hosts which deliver the ads (like noisy.popups.com) to your device and direct your device to 127.0.0.1 (localhost) instead. You’re essentially calling yourself.
For web browsers, there are very popular plugins available, even for (rooted) mobile phones similar solutions are known, but have you ever tried to root your TV or Apple device and side load an application?
This is exactly the point where pi-hole is getting handy.
It uses aforementioned lists to block ads but not only for the device you installed an adblocker on but for all devices in your network.
You just have to use pihole as DNS-Server in your network – if you can’t configure a specific DNS fuss-free on your device or router you might want to use pi-hole as your DHCP-Server.
This way it pushes itself as DNS to your devices.
If you want to have a look at it, there are several very good installation guides in multiple languages available.
Feel free to invest one hour of setting it up and enjoy a new ad free network and don’t forget to support the project 🙂

Tim Albert
Tim Albert
System Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere...

Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache

Die IT-Landschaften der Unternehmen wachsen prächtig – und auch die Anforderungen an die Sicherheit der dort gespeicherten Daten, denn besonders sensible Daten sind für so manch einen besonders interessant.
Passwörter werden noch heute viel genutzt, aber die vergangenen Jahre haben bewiesen, dass hier vor allem der Nutzer eine Schwachstelle darstellt. Passwörter werden hier sehr bequem; also zu kurz, mehrfach auf verschiedenen Diensten oder leicht zu erraten, gewählt.
Da nützt die beste Verschlüsselung im Zweifel nicht viel, wenn das Passwort auf einer der unzähligen Passwort-Listen im Internet rumschwirrt. Auch Phishing stellt ein Problem dar und nutzt die Unaufmerksamkeit der Nutzer aus. Kürzlich erhielten wir von einem unserer Managed-Services Kunden die Anfrage, ob wir nicht dafür eine Lösung haben. Das Stichwort “clientbasierte Zertifikats-Authentifizierung” kam dabei vom Kunden. Wenn man danach sucht, findet man schnell den Fachbegriff Mutual SSL Authentication (also gegenseitige SSL Authentifikation).
Gesagt, getan. Wir haben eine Lösung auf seinem Managed-Server-System bereitgestellt und zu Abnahmetests aufgefordert – das Ergebnis überzeugt. Für den Zugang zum Webdienst des Kunden braucht man nun kein Passwort mehr und es ist sicherer als zuvor. Aber wie genau funktioniert das?

  1. Der Nutzer beantragt Zugang auf eine geschützte Ressource
  2. Der Server antwortet nun neben seinen TLS-Zertifikat mit seinem Serverzertifikat
  3. Der Client verifiziert das erhaltene Zertifikat
  4. Der Client vertraut dem Zertifikat und übersendet sein Publickey
  5. Der Server überprüft die vom Client erhaltenen Daten
  6. Der Server gewährt dem Client Zugang zum gewünschten Medium

Im nachfolgenden Beispiel werde ich die Vorgehensweise zur Erstellung der selbstsignierten Zertifikate, Konfiguration des Webservers (hier Apache) und Einbindung in den Webbrowser beschreiben. Ausgangssituation ist ein aktuelles Linux mit Apache (dieser nutzt für TLS bereits Zertifikate). Tools wie openssl und vim sehe ich jetzt mal als gegeben.
Wir wechseln zunächst auf die grüne Wiese und erstellen uns einen neuen Ordner, z. B. /usr/local/src/SSL
1. Erstellung eines firmenweiten rootca-Zertifikates-Privatekeys mit 4096 BIT Schlüssellänge

openssl genrsa -out ssl.netways.de_rootca.key 4096

2. Nun erstellen wir ein Serverzertifikat mit 10 Jahren Gültigkeit, dies kann natürlich individuell angepasst werden

openssl req -x509 -new -nodes -key ssl.netways.de_rootca.key -sha256 -days 3650 -out ssl.netways.de_rootca.pem


3. Wir erstellen einen Key unseres ersten Clients, dieser kann natürlich individuell benannt werden, damit die Unterscheidung leichter fällt

openssl genrsa -out ssl.netways.de_client1.key 4096

4. Für den soeben erstellten Client-Key erstellen wir nun eine Zertifikatsanforderung, CSR
Eine Besonderheit, ist hier dass wir als OU (also Organizational Unit, bzw. Abteilung) ein Mitarbeiter-Kürzel (im Beispiel gmimietz) angeben, dazu später mehr

openssl req -new -key ssl.netways.de_client1.key -out ssl.netways.de_client1.csr


5. Wir legen schnell die erforderlichen Daten an, damit wir nicht die ganze OpenSSL-Config umbauen müssen

mkdir -p demoCA/newcerts && mkdir demoCA/certs && mkdir demoCA/crl && echo 00 > demoCA/serial && touch demoCA/index.txt

6. Jetzt signieren wir das CSR des Clients gegen unsere Serverzertifikate und erstellen ein Clientzertifikat mit 10 Jahren Gültigkeit, dies auf Korrektheit überprüfen und bestätigen.

openssl ca -in ssl.netways.de_client1.csr -cert ssl.netways.de_rootca.pem -keyfile ssl.netways.de_rootca.key -out ssl.netways.de_client1.crt -days 3650

7. Abschließend exportieren wir das Clientzertifikat und den Key übertragungstauglich in PKCS12-Format, hierzu wird ein Passwort abgefragt, welches wir später beim Import wieder brauchen.

openssl pkcs12 -export -in ssl.netways.de_client1.crt -inkey ssl.netways.de_client1.key -out NETWAYS_Client_gmimietz.p12

8. wir kopieren unseren rootca in unser ca-Verzeichnis (wichtig, dies muss dort mit crt benannt sein, um im nächsten Schritt eingelesen zu werden)

cp /usr/local/src/SSL-TEST/ssl.netways.de_rootca.pem /usr/local/share/ca-certificates/ssl.netways.de_rootca.crt

9. Zunächst aktualisieren wir unseren Zertifikats-Store mit

update-ca-certificates

10. In der Apache-Config brauchen wir noch ein paar kleine Anpassungen innerhalb der jeweiligen vhost-Definition

SSLCACertificatePath "/etc/ssl/certs"
SSLVerifyClient require
SSLVerifyDepth 5

11. Falls wir einem Zertifikat das Vertrauen entziehen möchten, so müssten wir eine Unterscheidung sicherstellen, deshalb haben wir in Punkt 4 eine OU angegeben, diese dient nur der Unterscheidung

<location />
  SSLRequire (%{SSL_CLIENT_S_DN_OU} ne "gmimietz")
</location>

12. Final starten wir den Apache neu

service apache2 restart

13. Zertifikat auf Client importieren
Wir importieren das Zertifikat (p12-File aus Schritt 7) unseren Browser. Dazu brauchen wir unser Entschlüsselungspasswort wieder, womit wir den Export verschlüsselt haben.
Im Firefox gehen wir hierzu auf Einstellungen -> Datenschutz & Sicherheit -> Zertifikate anzeigen.
Dort importieren wir im Register “Ihre Zertifikate” nun das p12-File und geben einmalig das Passwort ein.

Für die Anlage weiterer Client-Zertifikate führen wir die Schritte 3., 4., 6., 7. erneut aus und unterscheiden mittels Nutzernamen anhand der OU.
Fertig, wird laufen. Bitte noch beachten, dass andere Vhost-Configs natürlich auch abgedichtet werden müssen, falls die in das gleiche Doc-Root mit sensiblen Daten zeigen!
Ja, so tolle Sachen machen wir – was der Kunde sich wünscht, setzen wir um!

Georg Mimietz
Georg Mimietz
Lead Support Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.