Schlagwort-Archive: osbn

Tag OSBN

Chemnitzer Linux-Tage 2018 — Jeder fängt mal an.

Am 10. und 11. März 2018 finden fanden die Chemnitzer Linux-Tage (#clt2018) statt. Das Motto lautet in diesem Jahr lautete: „Jeder fängt mal an.“


Auch an dieser Stelle nocheinmal vielen Dank an die Veranstalter der #CLT2018 und die Hörer meines Vortrags „Webseiten mit HTTPS bereitstellen und mit HSTS sichern“. Die Folien zum Vortrag findet ihr auf der Seite Artikel und Vorträge sowie hinter diesem Direktlink.

Zum Ende meines Vortrags habe ich auf weitere Maßnahmen hingewiesen, mit denen sich die Angriffsfläche auf HTTPS verkleinern lässt. Weitere Informationen dazu findet ihr auf dieser Seite im Artikel „Über Pinning (HPKP), CAA und Certificate Transparency“.


Die Besucher erwartet in diesem Jahr erneut ein prall gefülltes Vortragsprogramm mit bis zu sieben parallel laufenden Tracks. War ich im vergangenen Jahr als Besucher zu Gast, steuere ich in diesem Jahr den Vortrag „Webseiten mit HTTPS bereitstellen und mit HSTS sichern“ bei. In diesem führe ich in das Thema HTTPS und die Internet-PKI ein und weise auf einige Stolpersteine hin, die auf dem Weg lauern.

Neben vielen interessanten Vorträgen werden an beiden Tagen jeweils sechs Workshops zum Lernen und Mitmachen angeboten. Für die Teilnahme ist eine Anmeldung erforderlich und es sind 5 Euro Teilnahmegebühr zu entrichten. Beeilt euch bei Interesse mit der Anmeldung, denn die Plätze sind begrenzt.

Darüber hinaus erwarten euch auf den CLT2018:

Die Praxis Dr. Tux bietet in ihrer Sprechstunde bei allen Problemen Hilfestellung, die der Anwender nicht alleine lösen kann.

Im Business Forum stellen sich bis zu 15 Open-Source-Firmen kurz vor. Hört entspannt zu, was diese Firmen genau tun, stellt Fragen und beteiligt euch an der Diskussion.

Auf der PGP-Party könnt ihr eure öffentlichen Schlüssel-Dateien signieren lassen. Weitere Informationen zur Vorbereitung und Durchführung findet ihr unter vorstehendem Link.

Retro Gaming wird während der Chemnitzer Linux-Nacht geboten. Ab 19:30 Uhr könnt ihr auf der Atari 2600 zeigen, aus welchem Holz ihr geschnitzt seid!

In der Projektküche präsentieren 15 Personen in jeweils fünf Minuten ihre Open-Source-Projekte. Möchtet ihr selbst euer Projekt vorstellen? Dann Beeilung, Anmeldeschluss ist der 1. März 2018.

Es wird also wieder viel geboten. Und neben den spannenden und interessanten Vorträgen freue ich mich natürlich auch, bekannte Gesichter wiederzusehen und abends über alte Zeiten zu plaudern. Bis neulich.

Ansible: Playbook nur auf Nodes laufen lassen, die gewissen Kriterien genügen

Manchmal möchte man ein Playbook bzw. Plays nur auf Hosts laufen lassen, welche gewissen Kriterien entsprechen. In diesem Beitrag möchte ich zwei Beispiele geben, wie sich dies umsetzen lässt.

Playbook nur auf Hosts mit Red Hat Betriebssystem ausführen

Das Modul group_by [1] wird genutzt, um während des Laufs eines Playbooks dynamisch Gruppen von Hosts zu erstellen, auf welche man später weitere Plays anwendet.

---
- hosts: all

  tasks:
    - name: Group by OS

      group_by: key=os_{{ ansible_distribution }}
      changed_when: False

- hosts: os_RedHat
  roles:
    - common

Zu Beginn eines Playbook-Laufs wird das Modul setup [2] ausgeführt, um Variablen mit nützlichen Informationen über die Nodes zu belegen. Die Variable ansible_distribution enthält dabei ein Schlüsselwort für eine bestimmte Distribution.

In obigen Beispiel wird dabei die Gruppe os_RedHat erstellt. Im Folgenden werden dann alle Nodes dieser Gruppe der Rolle common zugeordnet.

Dieses Verfahren lässt sich natürlich auch für weitere Variablen anwenden. Möchte man sehen, welche Variablen belegt werden und genutzt werden können, kann sich die Rückgabe von setup in der Standardausgabe ansehen, wenn man das Modul manuell auf einigen Nodes ausführt.

Plays nur auf bestimmten Nodes ausführen

Ein weiteres Beispiel habe ich auf ITrig [4] gefunden:

---
- name: install open-vm-tools
  hosts: vmwareclients
  gather_facts: True
  become: true
  become_user: root
  tasks:
- name: debian install open-vm-tools
  apt: name=open-vm-tools state=present
  when: ansible_os_family == "Debian" and ansible_virtualization_type == "VMware"

- name: centos install open-vm-tools
  yum: name=open-vm-tools state=present
  when: ansible_os_family == "RedHat" or ansible_distribution == 'CentOS' and ansible_virtualization_type == "VMware"

Hier werden Ansible Conditionals [3] verwendet, um zu bestimmen, auf welchen Nodes ein Play ausgeführt wird. Auch hier werden wieder Variablen ausgewertet, welche durch das Modul setup [2] belegt wurden.

In obigen Beispiel wird dies genutzt, um die open-vm-tools mit einem Playbook sowohl auf Debian und RedHat/CentOS Systemen zu installieren.

Quellen

  1. group_by – Create Ansible groups based on facts {en}
  2. setup – Gathers facts about remote hosts {en}
  3. Conditionals {en}
  4. Ansible Playbooks auf Servern mit SSH Key Authentifizierung verwenden {de}

Unit-Typ systemd.path kurz vorgestellt

Mit systemd.path lassen sich Dateien und Verzeichnisse auf bestimmte Ereignisse hin überwachen. Tritt ein spezifiziertes Ereignis ein, wird eine Service-Unit ausgeführt, welche üblicherweise den gleichen Namen, wie die Path-Unit trägt.

Wie dies funktioniert, möchte ich an einem sehr einfachen Beispiel zeigen. Das Ziel ist, die Datei testfile auf Änderungen hin zu überwachen. Immer wenn die Datei nach einem Schreibvorgang geschlossen wird, soll ein bestimmtes Skript gestartet werden.

beispiel.path

Im Verzeichnis /etc/systemd/system/ wird die Datei beispiel.path mit folgendem Inhalt erstellt:

[Unit]
Description=Datei auf Änderungen hin überwachen

[Path]
PathChanged=/home/oglattermann/testfile
Unit=beispiel.service

[Install]
WantedBy=multi-user.target

In der Sektion [Path] wird mit PathChanged= der absolute Pfad zu der zu überwachenden Datei spezifiziert, während Unit= angibt, welche Service-Unit ausgeführt werden soll, wenn sich die Datei ändert. Diese Unit soll gestartet werden, wenn sich das System im Multi-User-Mode befindet.

beispiel.service

Wird die Datei testfile geändert (genau: geschrieben und geschlossen), wird folgende Service-Unit aufgerufen, um das darin spezifizierte Skript auszuführen:

[Unit]
Description=Führt Skript aus, wenn eine Datei sich geändert hat.

[Service]
Type=simple
ExecStart=/home/oglattermann/skript.sh

[Install]
WantedBy=multi-user.target

Das Skript skript.sh enthält dabei in diesem Beispiel lediglich folgenden Code:

#!/bin/bash
echo "Datei geändert" >/home/oglattermann/Output.txt

Für einen Test müssen die beiden soeben erstellten Units noch aktiviert werden:

sudo systemctl enable beispiel.path beispiel.service
sudo systemctl start beispiel.path

Schreibt man nun die Datei testfile neu bzw. wird eine Schreiboperation auf diese Datei abgeschlossen, wird die entsprechende Service-Unit ausgeführt und man findet die Datei Output.txt vor.

Anwendungsbeispiele

Die folgende, unvollständige und nicht abschließende Liste führt einige Anwendungsbeispiele auf, wo sich systemd.path sinnvoll nutzen lässt.

  • Ereignisgesteuerte Datenverarbeitung starten
  • Dateien unter /etc überwachen und bei Änderungen Benachrichtigung versenden
  • Import-Ordner auf neue Dateien hin überwachen und Verarbeitung starten

Quellen und weiterführende Links

Wie kann man mit tcpdump HTTP-Traffic eines bestimmten Hosts sniffen?

Diese Frage wurde bereits von Scott in seinem englischsprachigen Blog beantwortet. Ich gebe sie an dieser Stelle wieder, um nicht immer wieder danach suchen zu müssen.

Das Kommando lautet:

tcpdump -c 20 -s 0 -i eth1 -A host 192.168.1.1 and tcp port http

Die Parameter bedeuten:

  • -c 20: Beendet den Vorgang, nachdem 20 Pakete aufgezeichnet wurden.
  • -s 0: Die mitgeschnittenen Nutzdaten sollen ungekürzt wiedergegeben werden.
  • -i eth1: Zeichne nur Pakete an der Netzwerkschnittstelle eth1 auf.
  • -A: Gebe alle Pakete in ASCII aus.
  • host 192.168.1.1: Zeichne nur Pakete auf, die von Host 192.168.1.1 kommen.
  • and tcp port http: Zeichne nur HTTP-Pakete auf.

Ergänzt man den Befehl noch um -w DATEINAME wird die Aufzeichnung in eine Datei statt auf die Standardausgabe geschrieben.

sht21andrasppi

Raspi-SHT21 Version 2 BETA veröffentlicht

Zwei Jahre sind seit dem letzten Release vergangen. Letztes Wochenende fand ich nun endlich die Zeit, mich wieder mit dem Projekt Raspi-SHT21 zu befassen. Herausgekommen ist die BETA der Version 2.

Alle Informationen zur neuen Version gibt es in den Versionsinformationen auf GitHub und in der README-Datei des Projekts.

Bei mir daheim läuft die neue Version bisher stabil. Da ausführliche Tests fehlen, habe ich sie als BETA markiert. Falls ihr Fehler findet, Fragen habt oder der Meinung seid, dass noch etwas fehlt (Code, Doku, Spendenbutton), eröffnet bitte einen GitHub-Issue oder hinterlasst mir hier einen Kommentar.

In Zukunft soll das Projekt um Remote-Messstationen erweitert werden. Der Raspberry Pi dient dabei als Zentrale zur Speicherung und Visualisierung der Messdaten. Diese werden zukünftig nicht mehr nur ausschließlich vom direkt angeschlossenen SHT21-Sensor geliefert, sondern auch von weiteren Sensoren, die ihre Daten per WLAN übertragen. Sobald es etwas zu zeigen gibt, werde ich in diesem Blog darüber berichten.

Verwandte Artikel

  1. Überwachung von Temperatur und Luftfeuchtigkeit mit dem SHT21
  2. Visualisierung von Umweltdaten

Synology NAS: Einzelnen Ordner neu indizieren

Synology Diskstations stellen Anwendungen bereit, um Bilder, Musik und Videos verwalten zu können. Dies sind im einzelnen

  • die Photo Station,
  • die Audio Station und
  • die Video Station.

Damit die Medien in den jeweiligen Anwendungen angezeigt werden können, müssen diese zuvor indiziert werden. Die Indizierung erfolgt automatisch, wenn Medien über die entsprechende Anwendung hinzugefügt werden. Fügt man sie jedoch auf anderem Wege hinzu, z.B. durch rsync, startet die Medienindizierung nicht und die Medien können in der jeweiligen Anwendung nicht wiedergegeben werden.

Die Benutzeroberfläche „DSM“ bietet lediglich die Möglichkeit, ganz allgemein eine Medienindizierung zu starten. Dabei werden jedoch sämtliche Medien neu indiziert und nicht nur die neu hinzugefügten. Je nach Umfang dauert die Indizierung mehrere Stunden bis Tage. Es gibt jedoch eine Möglichkeit, die Indizierung manuell zu starten und dabei auf ein einzelnes Verzeichnis zu beschränken.

Dazu meldet man sich per SSH an der Diskstation an und führt folgendes Kommando aus:
/usr/syno/bin/synoindex -R /Pfad/zum/Verzeichnis/

Damit lässt sich eine Menge (Rechen-)Zeit sparen.

Ordnung in die Fotosammlung bringen

In diesem Beitrag möchte ich festhalten, wie ich mit dem ExifTool von Phil Harvey [1] ein wenig Ordnung in meine Fotosammlung brachte.

Meine Frau und ich verwenden verschiedene Geräte wie z.B. Smartphones, Tablets und Digitalkameras, um Fotos aufzunehmen. Dabei speichern diese Geräte die aufgenommenen Bilder nach folgenden Namensmustern:

  • IMG_1234.JPG
  • IMG_<YYYYMMDD>_<hhmmss>.jpg

Die so benannten Bilder landen nach Themen sortiert in Verzeichnissen auf einem NAS. Um sie in eine chronologische Reihenfolge zu bringen, möchte ich sie einheitlich nach folgendem Muster benennen:

  • <YYYY-MM-DD>T<hhmmss>_img.jpg

Dazu lese ich das Aufnahmedatum mit dem ExifTool aus den EXIF-Daten [2] der Fotos aus und verwende dies, um die Dateien nach dem gewünschten Muster umzubenennen. Der dazu genutzt Befehl sieht wie folgt aus:

exiftool '-filename<DateTimeOriginal' -d "/Pfad/zum/Zielverzeichnis/%Y-%m-%dT%H%M%S_img%%-c.jpg" Quellverzeichnis/

Mit dem obigen Kommando werden die Dateien aus dem Quellverzeichnis wie gewünscht umbenannt und in das Zielverzeichnis verschoben. Sollte dort bereits eine Datei mit gleichem Namen existieren, wird durch die Option „%%-c“ ein Index angehängt und hochgezählt.

[1] ExifTool by Phil Harvey {en}
[2] Exchangeable Image File Format {de}

Zertifikatsanfrage (CSR) mit OpenSSL erstellen

Dieses Tutorial beschreibt, wie eine Zertifikatsanfrage (engl. Certificate Signing Request, kurz CSR) erstellt werden kann. Dabei wird die Erstellung von Anfragen für Zertifikate mit einem und mehreren enthaltenen Hostnamen behandelt. Die nach diesem Tutorial erstellten Zertifikatsanfragen können dann genutzt werden, um sie an eine Zertifizierungsstelle (engl. Certificate Authority, kurz CA) zu übermitteln.

Voraussetzung, um diesem Tutorial zu folgen, ist eine funktionsfähige Installation von OpenSSL. Die Installation von OpenSSL ist nicht Gegenstand dieses Tutorials.

Die folgende Tabelle gibt Auskunft über die Konfigurationen, mit denen dieses Tutorial getestet wurde.

BetriebssystemOpenSSL Version
Ubuntu 16.04 LTSOpenSSL 1.0.2g
CentOS/RHEL 7OpenSSL 1.0.2k-fips
Fedora 26OpenSSL 1.1.0f-fips

Keyfile und CSR in einem Schritt erstellen

Die Dateien für den privaten Schlüssel und den CSR können auf der Kommandozeile mit dem folgenden Befehl erstellt werden. Dabei werden die benötigten Informationen interaktiv abgefragt.

/tmp$ openssl req -newkey rsa:2048 -sha256 -keyout test.key -out test.csr
Generating a 2048 bit RSA private key
..............................................................................................+++
........................................................................................................................+++
writing new private key to 'test.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:NRW
Locality Name (eg, city) []:.        
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:test.example.com
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:.
An optional company name []:.

Die einzelnen Argumente des Befehls sind wie folgt zu erklären:

openssl req ruft das Kommando zur Generierung eines PKCS#10 CSR auf [1]. Das Argument -newkey rsa:2048 gibt an, dass ein neuer RSA-Key mit einer Schlüssellänge von 2048 Bit generiert werden soll. Dieser Schlüssel wird anschließend verwendet, um den CSR zu erzeugen. Mit dem Argument -sha256 wird angegeben, dass das beantragte Zertifikat mit dem SHA256-Algorhytmus signiert werden soll. Man beachte, dass dies von der Zertifizierungsstelle überschrieben werden kann. Mit -keyout test.key wird der Dateiname angegeben, unter dem die Private-Key-Datei (test.key) im aktuellen Verzeichnis gespeichert werden soll. Dementsprechend gibt -out test.csr an, wo die CSR-Datei (test.csr) gespeichert werden soll. Im oben dargestellten Beispiel geschieht dies ebenfalls im aktuellen Verzeichnis.

Das Kommando erzeugt den privaten Schlüssel und fragt interaktiv nach einer Passphrase, mit welcher die Private-Key-Datei verschlüsselt wird. Anschließend werden die Informationen abgefragt, welche in den CSR aufgenommen werden sollen. Mit einem „.“ gibt man an, dass der Standardwert aus den eckigen Klammern in den CSR übernommen werden soll. Auf die Angabe einer E-Mail-Adresse und eines Challenge-Passworts kann guten Gewissens verzichtet werden, da diese Angaben von den meisten Zertifizierungsstellen ignoriert werden.

CSR für mehrere Hostnamen erstellen

Um einen CSR für mehrere Hostnamen zu erstellen, bedient man sich am einfachsten einer Konfigurationsdatei. Die im Folgenden verwendete Konfigurationsdatei kann unter [2] heruntergeladen und unter einem beliebigen Namen (z.B. csr_config.cnf) gespeichert werden. Ausführliche Informationen zum Aufbau der Konfigurationsdatei finden sich in Kapitel 3.3 des unter [2] verlinkten TLS-Kochbuchs. Beachten Sie, dass hinter dem Parameter subjectAltName neben den weiteren Host-/Domain-Namen auch der commonName mit aufgeführt werden muss.

[ req ]
default_bits = 2048
default_keyfile = test_privatekey.pem
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:test.example.com, DNS:*.test.example.com

[ req_distinguished_name ]
countryName = DE
stateOrProvinceName = Nordrhein-Westfalen
localityName = MeinOrt
0.organizationName = MeineFirma
organizationalUnitName = MeineAbteilung
commonName = test.example.com

Die obige Konfigurationsdatei kann nun genutzt werden, um einen CSR für den Hostnamen test.example.com und alle möglichen Hostnamen unterhalb der Domain .test.example.com zu erstellen:

/tmp$ openssl req -batch -sha256 -new -config csr_config.cnf -out test2.csr

Mit der Option -batch wird der interaktive Modus deaktiviert. Die Option -new gibt an, dass ein neuer CSR generiert werden soll. Dabei wird ein Private-Key nach den Vorgaben in der Konfigurationsdatei, welche mit -config csr_config.cnf angegeben wird, erzeugt.

Abschließende Bemerkungen

Die beiden gezeigten Methoden zur Erzeugung einer Zertifikatsanfrage stellen nur einen kleinen Ausschnitt aus dem großen Werkzeugkasten namens OpenSSL dar. Doch sind sie dazu geeignet, in einfacher Weise einen CSR zu erstellen, den man zur Signatur an eine CA seines Vertrauens senden kann.

  1. PKCS #10: Certification Request Syntax Specification
  2. TLS/SSL-Kochbuch – Rezepte für die Verwendung von OpenSSL

Vorträge 2017 auf der OpenRheinRuhr und dem LinuxDay in Vorarlberg

Nicht ganz uneigennützig möchte ich mit diesem Beitrag auf zwei Veranstaltungen zu den Themen Open Source, Freie Software und Linux in diesem Jahr hinweisen. Beide Veranstaltungen haben gemeinsam, dass ich auf ihnen mit verschiedenen Vorträgen vor Ort bin.

OpenRheinRuhr 2017



Bereits kommende Woche findet vom 4.-5. November die OpenRheinRuhr im Rheinischen Industriemuseum in Oberhausen statt.

Ich selbst bin dieses Jahr zum ersten Mal auf der OpenRheinRuhr zu Gast und freue mich bereits auf spannende Themen und darauf, das ein oder andere vertraute Gesicht wiederzusehen. Von mir gibt es als Beitrag zur diesjährigen Veranstaltung am 4. November um 17 Uhr eine Einführung und kritische Betrachtung von Ansible.

LinuxDay in Vorarlberg

Am 2. Dezember diesen Jahres bin ich dann beim LinuxDay in Vorarlberg (Österreich) zu Gast. Die Veranstaltung legt den inhaltlichen Schwerpunkt dieses Jahr auf die Themen Privatsphäre und Sicherheit. Dazu gibt es um 15 Uhr mit meinem Vortrag „Webseiten mit HTTPS bereitstellen und mit HSTS und HPKP sichern“ einen Einblick in die Welt der Internet-PKI, ihrer Schwachstellen und zwei ausgewählte Methoden, um die Angriffsfläche zu verkleinern.

Der Vortrag ist ein Auszug aus meinem TLS-Kochbuch, welches unter dem angegebenen Link kostenlos zum Download zur Verfügung steht.

Ich freue mich bereits darauf, unsere Nachbarn im Süden zu besuchen, sowie altbekannte und neue Mitglieder der Gemeinschaft kennenzulernen.
LinuxDay 2017 am 2. Dez in Dornbirn

Linux: Wann ist ein Neustart erforderlich?

Es ist allgemein bekannt, dass ein Neustart erforderlich ist, um einen neu installierten oder aktualisierten Kernel zu laden. Doch gibt es auch noch weitere Pakete, welche den Neustart eines Hosts erforderlich machen. Dieser Artikel beschreibt Methoden für CentOS, RHEL, Oracle Linux, Debian und Ubuntu, mit denen geprüft werden kann, ob ein Neustart erforderlich ist oder nicht.

Prüfung unter CentOS, RHEL, Oracle Linux

Unter den genannten Distributionen existiert das Programm needs-restarting, welches durch das Paket yum-utils bereitgestellt wird. Dieses kann genutzt werden, um Prozesse anzuzeigen, die aktualisiert wurden:

# needs-restarting
477 : /usr/bin/VGAuthService -s

Die Ausgabe gibt die Prozess-ID und den Namen des Prozesses zurück. Möchte man prüfen, ob ein Neustart des gesamten Systems erforderlich ist, so nutzt man die Option -r:

# needs-restarting -r
Core libraries or services have been updated:
  kernel -> 3.10.0-693.1.1.el7

Reboot is required to ensure that your system benefits from these updates.

More information:
https://access.redhat.com/solutions/27943

Obige Ausgabe deutet darauf hin, dass ein Neustart erforderlich ist, da ein neuer Kernel installiert wurde. Auf einem neugestarteten System sieht die Ausgabe wie folgt aus:

$ sudo needs-restarting -r
No core libraries or services have been updated.
Reboot is probably not necessary

Prüfung unter Debian und Ubuntu

Um festzustellen, ob ein Neustart erforderlich ist oder nicht, kann man prüfen, ob die Datei /var/run/reboot-required existiert. Existiert die Datei, ist es angeraten, einen Neustart des Systems durchzuführen. Ist die Datei hingegen nicht vorhanden, ist höchstwahrscheinlich auch kein Neustart erforderlich.

Quellen und weiterführende Links