Sicherheitslücke Log4Shell CVE-2021-44228

Vor einer Woche hat das BSI zum ersten mal die Warnstufe Rot ausgerufen. Durch die Sicherheitslücke Log4Shell CVE-2021-44228 im weit verbreiteten Framework Log4J sind potenziell fast alle Java-Anwendungen angreifbar. Log4J ist der De-facto-Standard für das Loggen von Java-Anwendungen. Deshalb sind weltweit sehr viele Anwendungen betroffen.

Für mich bedeutete die Sicherheitslücke jetzt erst mal eine anstrengende Arbeitswoche. Es galt alle Java-Anwendungen zu identifizieren, für die ich verantwortlich bin und das ist eine große Menge. Danach musste ich rausfinden, ob die entsprechende Anwendung tatsächlich Log4J verwendet. Und zu guter letzt musste ein Update eingespielt werden, sofern dies der Fall war.

Inzwischen habe ich alle Anwendungen überprüft und kann beruhigt Weihnachten feiern. Dazu bin ich wie folgt vorgegangen.

Wie findet man raus, ob eine Software betroffen ist?

Informationen des Herstellers

Informationen des Herstellers oder Programmierers sind natürlich der einfachste und beste Weg, um die Anfälligkeit eines Programms für diese Sicherheitslücke zu überprüfen. Ich persönlich habe bei betroffenen Anwendungen die folgenden Webseiten der Hersteller dazu genutzt:

Liste der Betroffenen Anwendungen auf GitHub

Sollte man bei Hersteller oder Programmierer solche Informationen nicht direkt finden, gibt es eine weitere Möglichkeiten, um diese zu feinden. Der französische Sicherheitsspezialist SwitHak pflegt bei GitHub eine Liste mit Aussagen der Hersteller die betroffen sind. Sofern eigene Anwendungen auf dieser Liste aufgeführt sind kommt man über einen Link zu den jeweiligen Informationen.

log4j-detector

MergeBase hat auf gitlab das Programm log4j-detector veröffentlicht, mit dessen Hilfe man nach verwundbaren Versionen von Log4J innerhalb von Java-Anwendungen suchen kann. Wenn man dieses auf dem Server mit einer Anwendung laufen lässt, durchsucht es alle Java Classen und meldet einem, wenn es dort eine verwundbare Version von Log4J findet.

Netzwerkscann

Eine weitere Möglichkeit für das aufspüren von verwundbaren Log4J Lücken ist das Scannen der Serverdienste über das Netzwerk mittels eines Vulnerability Scanners. Einer der bekanntesten Vulnerability Scanners ist OpenVAS von Greenbone, welchen ich für diesen Scann verwendet habe. Wie man dem Forumsbeitrag Testing for CVE-2021-44228 (Log4j/Log4Shell vulnerability) entnehmen kann, kann diese die Log4J Lücke auch bereits finden.

Um OpenVAS von Greenbone zum scanne zu verwenden, habe ich mir diesen schnell auf einer virtuellen Maschine mit Kali Linux installiert. Wie dies geht schildert der Blogbeitrag OpenVAS on Kali GNU/Linux Part 1: How to install OpenVAS von Staf Wagemakers.

Debian: Upgrade von 10 (Buster) auf 11 (Bullseye)

Am 14. August 2021 wurde Debian 11 (Bullseye) veröffentlicht. Dieser Artikel erläutert kurz, was zu tun ist, um ein Upgrade von Version 10 (Buster) auf Version 11 (Bullseye) bei einer bestehenden Installation durchzuführen. Im Prinzip ist das vorgehen dabei seit Jahren gleich. Schon bei dem Upgrade von Version 6.0 (Squeeze) auf Version 7.0 (Wheezy) war das Vorgehen nahezu identisch. Lediglich das aptitude wurde inzwischen durch apt ersetzt.

Datensicherung

Als erstes sollte das bestehende System mit einer Datensicherungssoftware gesichert werden. Dazu kommen eine ganze Reihe von Programmen wie cpio, tar, amanda oder rsnapshot infrage. Nähere Infos zu Backupsoftware unter Linux kann man in meinem Artikel Backup-Software für Linux nachlesen.

Danach sollte eine Liste der Installierten Software-Pakete erstellt werden, damit man im Notfall wieder ein System mit identischer Software installieren kann. Eine Anleitung dazu ist in meinem Artikel Ubuntu/Debian: Die gleiche Software auf einem neuen Computer installieren zu finden.

Einspielung aller Updates für das bestehende Debian

Bevor das eigentliche Upgrade auf die Version 11.0 gemacht wird sollten alle Updates für die alte Version eingespielt werden. Dazu muss zunächst die source-list aktualisiert werden:

sudo apt update

Danach können die Updates installiert werden:

sudo apt upgrade

Anpassen der sources-list

Damit die neuen Pakete gefunden werden, muss in der source-list das Wort buster gegen bullseye getauscht werden. Die source-list befindet sich in der Datei /etc/apt/sources.list. Die Datei sollte nach den Änderungen etwa wie folgt aussehen:

deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb-src http://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb http://security.debian.org/debian-security bullseye-security main
deb-src http://security.debian.org/debian-security bullseye-security main
deb http://ftp.debian.org/debian bullseye-backports main

Upgrade
Nun muss erneut die source-list aktualisiert werden:

sudo apt update

Zum Schluss wird dann der Rest der Pakete aktualisiert:

sudo apt full-upgrade

Während der Aktualisierung der einzelnen Software-Pakete wird dann ab und zu noch die ein oder andere Frage gestellt, bevor der abschließende Neustart fällig wird. Nach dem Neustart ist das Upgrade abgeschlossen.

ssh als SOCKS-Proxy verwenden

Eine geniale Funktion des ssh Protokolls ist der SOCKS-Proxy. Viele kennen und nutzen diese gar nicht. Dabei hilft einem diese enorm bei der Administration von Servern. Ich nutze diese Funktion z.B. sehr häufig, um mit einem Webbrowser aus einem andern Netzwerk zuzugreifen. Dies ist sehr praktisch, wenn man mit seinem Notebook gerade in einem andern IP-Netz hängt und deshalb mit dem Browser nicht durch eine Firewall kommt.

Wie geht sowas?

Um mit einem Webbrowser über den SOCKS-Proxy aus einem anderen Netzwerk zu kommen, sind die beiden folgenden Schritte notwendig.

1. Anmeldung per ssh an einem Server in dem gewünschten Netzwerk

Um aus einem andern Netzwerk zu kommen meldet man sich auf einem System das sich innerhalb des selben befindet mit ssh und dem Parameter -D <Port> an. Dieser Parameter aktiviert den SOCKS-Proxy auf dem angegebenen Port. Wenn man z.B. ein Open SSH, ein anderes System mit ssh-server und der IP-Adresse 10.10.10.10 hat und einen SOCKET auf Port 1080 verwenden möchte, gibt man in der Kommandozeile den folgenden Befehl ein:

ssh -D 1080 10.10.10.10

2. Einstellung des SOCKS-Proxy im Webbrowser

Danach stellt man in dem Webbrowser ein, dass man den SOCKS-Proxy auf dem entsprechenden Port verwenden möchte. Dazu sollte man natürlich einen Webbrowser verwenden, der dies auch kann. Bei dem Firefox Webbrowser geht dies z.B. Verbindungseinstellungen:

Im Anschluss surft man mit diesem Webbrowser von der IP-Adresse 10.10.10.10.

Einbinden einer neuen Festplatte bei Linux zur Laufzeit

In Zeiten zunehmender Virtualisierung (mit VMware vSphere, KVM, Citrix usw.) wird es immer häufiger notwendig Festplatten im laufenden Betrieb einzubinden, da diese ohne Neustart einfach zu einer virtuellen Maschine hinzufügen wurden. Bei Linux tauchen diese Platten ohne Neustart des Gastes aber nicht so einfach auf. Damit man diese auch im laufenden Betrieb zu Gesicht bekommt, muss der Kernel die Festplattenkonfiguration neu einlesen. Wie dies ohne Neustart geht, möchte ich in diesem Artikel dokumentieren.

Welche Speicher-Adapter kennt das System?

In dem Verzeichnis /sys/class/scsi_host befindensich die dem Kernel bekannten Speicher-Adapter des Systems. Der folgende Befehl zweigt die Adapter an.

ls /sys/class/scsi_host

Wie bringe ich die Speicher-Adapter dazu neue Festplatten zu erkennen?

Mit der folgenden Schleife, bringt man alle Speicher-Adapter des Systems dazu im laufenden Betrieb nach neuen Festplatten zu suchen.

for f in /sys/class/scsi_host/host*; do echo '- - -' > $f/scan; done

Wie bringe ich die Speicher-Adapter dazu Größenänderung bei Festplatten zu erkennen?

Wenn es sich nicht um eine neue neue Festplatte sondern nur um eine geänderte handelt, wird es noch etwas komplizierter. Dank ein bisschen Zauberei mit awk, kann man auch eine Schleife bauen, die bei allen Blockdevices nach Änderungen suchen lässt. Diese sieht dann so aus.

for d in $(lsblk -Sln | awk '{if ( $3 == "disk" ) print $1}'); do echo 1 > /sys/class/block/$d/device/rescan; done

Achtung: Fehlfunktion durch ablaufende Sicherheitszertifikate bei den Dell OS10 Switches

Dell hat gerade seine Kunden gerade per E-Mail angeschrieben und vor einem besonders heimtückischen Problem bei den OS10 Switches gewarnt. Bestimmte Versionen von OS10 (beginnend mit 10.4.1.4 bis 10.5.0.7 P3) enthalten ein Standardzertifikat, das für VLT Peer Establishment und die SFS-Cluster-Bildung verwendet wird. Und genau dieses Standardzertifikat läuft am 27. Juli 2021 ab. Dell beschreibt im Knowledge Artikel 000184027, wie man das Ablaufen des Zertifikates verhindern kann. In den meisten Konstellationen wird ein Update des OS10 auf eine aktuelle Version empfohlen. Ein Update von OS10 verursacht einen Netzwerkausfall. Deshalb sollten betroffenen diesen Artikel unbedingt zu Ende lesen.

Wenn das Zertifikat abläuft kann es zu massiven Fehlfunktionen bei betroffenen Switches kommen, sofern auf diesen VLT Peer Establishment und die SFS-Cluster-Bildung verwendet wird. Es könnte z.B. zu einem nachfolgenden Switch-Neustart, einer Link-Flap-Lösung, einer Operator-ausgelösten Konfigurationsänderung, VMotion und anderen Netzwerkereignissen kommen.

Aktualisierung von OS10 löst das Problem

Auf den von mir betreuten Switchen war die OS10 Version 10.5.0.1P1 installiert. Somit waren diese betroffen. Um das Problem zu lösen, empfiehlt Dell ein Update auf die aktuelle OS10 Version. Deshalb habe ich die Switche auf die OS10 Version 10.5.2.3 aktualisiert. Wie das im einzelnen geht, habe ich bereits in dem Blogartikel Dell OpenNetwork Switches mit OS10 beschrieben. Wer in der gleichen Situation wie ich ist, kann dort eine Anleitung für das Update der Switche finden.

Netzwerkausfall bei der Aktualisierung der Switche

Da Ich VLT Peer Establishment über jeweils zwei Switche verwende, wähnte ich mich vor einem Netzwerkausfall in Sicherheit. Genau dazu ist die VLT Technik ja schließlich gedacht. Wenn ein Switch ausfällt sollte der andere ohne Ausfall übernehmen. Dies war aber leider ein Trugschluss. Obwohl der Versionssprung von 10.5.0.1P1 auf 10.5.2.3 keine großen Änderungen suggeriert, wurde die Version des VLT Protokolls von Version 2.3 auf die Version 3.1 angehoben. Diese Versionen scheinen nicht kompatibel zu sein und es kommt nach dem Update des ersten Switches zu einer Netzwerkstörung, bis der zweite aktualisiert wurde.

Was sagt der Dell Support dazu?

Ich habe nach auftreten der Störung sofort den Support von Dell angerufen. Da kein Support-Mitarbeiter in deutscher Sprache verfügbar war, wurde zwar sofort aber auf englisch sehr freundlich beraten. Leider erhielt ich aber nur die Aussage, dass die Versionen der VLT Protokolle eben nicht kompatibel sind und man mit diesem Netzwerkausfall während dem Update eben leben müsse. Der Support versprach aber auch, dass sich nochmal ein Spezialist melden würde, der uns zu dem Update berät. Deshalb haben ich die Updates zunächst unterbrochen und werde noch mal ein paar Tage abwarten, ob sich jemand meldet. Vielleicht gibt es ja doch noch eine Lösung ohne Netzwerkausfall. Sofern dies der Fall sein sollte, werde ich den Blogeintrag hier entsprechend ergänzen.

Update: Peter gab mir in den Kommentaren den Tipp, das man den Upgradepfad beachten muss. Wenn man zwischenzeitlich auf die Version 10.5.0.6 und erst danach auf die Version 10.5.2.3 aktualisiert, soll es keinen Ausfall geben.

Persönliches Fazit

Wir hatten uns für die hochpreisigen Switche von Dell entschieden, um mit VLT genau solche Ausfälle zu vermeiden. Deshalb bin ich aktuell etwas enttäuscht. Nach gerade mal zwei Jahren, kommt es durch ein kurzfristig notwendiges Update zu genau einem solchen Ausfall. Ansonsten haben uns die Switche bis jetzt aber noch nicht im Stich gelassen und wir sind sehr zufrieden mit ihnen. Insofern hoffe ich, dass dies ein unglücklicher Einzelfall war, der sich so schnell nicht wiederholen wird.

Installation einer neueren PHP-Version auf einem älteren Ubuntu

Es kommt gerade bei den LTS-Versionen von Ubuntu immer häufiger vor, dass eine Software zwingend eine neuere PHP-Version voraussetzt, als auf einem Server mit einem Ubuntu Betriebssystem gerade installiert ist. Wie kann ein solche Herausforderung lösen?

Eine Möglichkeit diese Anforderung zu erfüllen ist ein Upgrade des Ubuntu auf ein neues Release. Oft möchte man dies aber nicht, da es andere Abhängigkeiten gibt, oder weil man nicht jeden Releasewechsel mitmachen möchte. Auch kann es vorkommen, dass selbst das neuste LTS Release ein zu alte Version von PHP beinhaltet. Somit stellt sich die Frage, nach einer Alternative zu einem Releasewechsel.

Dank dem offiziellen Repository für PHP von Ondřej Surý auf Launchpad gibt es eine weitere Lösung. Wenn man dieses Repository einbindet, wird es auch auf eine älteren Release von Ubuntu möglich neuere PHP Versionen zu installieren. Man kann z.B. auch auf einem Ubuntu 16.04 oder 18.04 problemlos ein ganz aktuelles PHP 7.4 installieren.

Um das Repository für PHP von Ondřej Surý bei einem Ubuntu 16.04 einzubinden, gibt man den folgenden Befehl in der Kommandozeile ein.

sudo add-apt-repository ppa:ondrej/php

Danach kann man ein PHP 7.4 mit den folgenden Zeilen installieren.

sudo apt-get update
sudo apt-get install php7.4

Im Anschluss sollte man noch einige Komponenten von PHP 7.4 installieren, welche meistens benötigt werden.

sudo apt-get install php7.4-common php7.4-mysql php7.4-xml php7.4-xmlrpc php7.4-curl php7.4-gd php7.4-imagick php7.4-cli php7.4-dev php7.4-imap php7.4-mbstring php7.4-opcache

Sobald das durch ist, kann man die Standard PHP-Version innerhalb des Betriebssystem mit den folgende Befehlen festlegen.

sudo update-alternatives --config php
sudo update-alternatives --config php-cgi

Und schon kann man auch Software installieren, die das aktuelle PHP 7.4 voraussetzt …

Ubiquiti Unifi: Releaseupgrade eines Ubuntu 16.04 auf 18.04 mit einer Mongodb

Mehrere Installationen der Software Unifi von Ubiquiti liefen bei mir noch auf einem Ubuntu 16.04 LTS. Da die kostenlosen Sicherheitsupdates für dieses Ubuntu nur noch ein halbes Jahr erscheinen, war es Zeit für ein Releaseupgrade auf Ubuntu 18.04. Gesagt, getan… Nach einem Backup eines der Controller führte ich kurzerhand ein Releaseupgrade durch.

Das eigentliche Releaseupgrade lief ohne Probleme durch. Überraschender Weise startete die Unifi Software aber nicht mehr. Ein Blick in das Logfile /var/log/unifi/server.log der Unifi Software offenbarte, dass die MongoDB nicht mehr erreichbar war.

[2020-08-12 17:40:59,094] <db-server> ERROR system - [exec] error, rc=100
[2020-08-12 17:40:59,095] <db-server> INFO db - DbServer stopped

Ein weiterer Blick in das Logfile /var/log/unifi/mongod.log der MongoDB zeigte, dass der Grund ein zu großer Versionssprung von der vorherigen Version 2.6 der MongoDB war.

2020-08-25T16:44:07.964-0400 F CONTROL  [initandlisten] ** IMPORTANT: UPGRADE PROBLEM: The data files need to be fully upgraded to version 3.4 before attempting an upgrade to 3.6; see http://dochub.mongodb.org/core/3.6-upgrade-fcv for more details.
2020-08-25T16:44:07.964-0400 I NETWORK  [initandlisten] shutdown: going to close listening sockets...
2020-08-25T16:44:07.964-0400 I NETWORK  [initandlisten] removing socket file: /usr/lib/unifi/run/mongodb-27117.sock
2020-08-25T16:44:07.964-0400 I REPL     [initandlisten] shutdown: removing all drop-pending collections...
2020-08-25T16:44:07.964-0400 I REPL     [initandlisten] shutdown: removing checkpointTimestamp collection...
2020-08-25T16:44:07.964-0400 I STORAGE  [initandlisten] shutdown: waiting for fs preallocator...
2020-08-25T16:44:07.964-0400 I STORAGE  [initandlisten] shutdown: final commit...
2020-08-25T16:44:07.964-0400 I JOURNAL  [initandlisten] journalCleanup...
2020-08-25T16:44:07.964-0400 I JOURNAL  [initandlisten] removeJournalFiles
2020-08-25T16:44:07.970-0400 I JOURNAL  [initandlisten] old journal file /usr/lib/unifi/data/db/journal/j._0 will be reused as /usr/lib/unifi/data/db/journal/prealloc.0
2020-08-25T16:44:07.976-0400 I JOURNAL  [initandlisten] Terminating durability thread ...
2020-08-25T16:44:08.067-0400 I JOURNAL  [journal writer] Journal writer thread stopped
2020-08-25T16:44:08.067-0400 I JOURNAL  [durability] Durability thread stopped
2020-08-25T16:44:08.067-0400 I STORAGE  [initandlisten] shutdown: closing all files...
2020-08-25T16:44:08.070-0400 I STORAGE  [initandlisten] closeAllFiles() finished
2020-08-25T16:44:08.070-0400 I STORAGE  [initandlisten] shutdown: removing fs lock...
2020-08-25T16:44:08.070-0400 I CONTROL  [initandlisten] now exiting
2020-08-25T16:44:08.070-0400 I CONTROL  [initandlisten] shutting down with code:62

Um das Releaseupgrade erfolgreich durchzuführen, muss man also erst die MongoDB auf Version 3.4 aktualisieren und danach das Releaseupgrade starten. Ein Upgrade der MongoDB macht man am besten mit den Softwarepaketen von MongoDB.org und das geht wie folgt:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6
sudo echo "deb http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list
sudo apt-get update
sudo apt-get install -y mongodb-org
sudo systemctl unmask mongodb
sudo systemctl restart mongodb

Jetzt sollte die MongoDB auf Version 3.4 aktualisiert sein und man kann gefahrlos das Releaseupgrade auf Ubuntu 18.04 starten. Ein Backup sollte man natürlich dennoch vorsichtshalber machen.

Nach dem Upgrade auf Ubuntu 18.04 ist noch zu empfehlen die MongoDB ein weiteres mal auf die Version 3.6 zu aktualisieren, da es für die Version 3.4 nur bis Januar 2020 Support und Sicherheitsupdates gab. Für die Version 3.6 gibt es selbiges bis April 2021 und diese wird seit der Unifi Version 5.13.10 unterstützt. Das Upgrade geschieht mit den folgenden Befehlen.

wget -qO - https://www.mongodb.org/static/pgp/server-3.6.asc | sudo apt-key add -
echo "deb https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.6 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.6.list
apt update
apt upgrade
systemctl restart mongodb

Dell OpenNetwork Switches mit OS10

Dell hat im Jahre 2011 die Firma Force10 Networks übernommen. Seit dieser Zeit sind im Portfolio von Dell auch Enterprise Switches zu finden. Seit 2016 laufen einige dieser Switches mit dem auf Debian Linux basierenden OS10.

Das OS10 verwendet einen Standard-Linux-Kernel und bietet Zugriff auf die Netzwerkhardware über das Switch Abstraction Interface (SAI) des Open Compute Project. Ein Projekt das neben Dell von Microsoft, Facebook, Broadcom, Intel und Mellanox unterstützt und verwendet wird. Damit müssen sich Entwickler nicht mehr um die tatsächlich verwendete Switching-Hardware kümmern und können auf offene Standards aufsetzen.

Das OS10 System ist inzwischen sehr ausgereift und bietet nahezu den gleichen Funktionsumfang wie das vorherige OS9. Grund genug für mich mir die OS10 Switches in den letzten Monaten näher anzusehen und bei ersten Projekten einzusetzen. Zumal diese Geräte preislich sehr attraktiv sind.

Meine Erfahrungen in der Praxis mit den Switches sind sehr positiv und ich kann sie durchweg empfehlen. Allerdings sind die Dokumentationen und Updates bei Dell etwas schwierig zu finden. Deshalb schreibe ich mir hier einige wichtige Informationen und Links mal zusammen, um diese immer griffbereit zu haben.

Downloads der Updates für OS10 und Firmware

Über die Dell Webseite sind die Updates und die Firmware nur schwer zu finden. Leichter findet man die Updates in dem sogenannten Dell Digital Locker. Wenn man sich dort mit seinem Benutzer anmeldet, finden man dort die Updates von OS10, sofern man Produkte mit einem laufenden Wartungsvertrag hat, auf denen OS10 läuft.

Eine aktuellere Firmware oder ein aktuelleres BIOS findet man wiederum am einfachsten in der Rubrik Treiber und Downloads auf der Dell Webseite über den Service-Tag oder die genaue Modellbezeichnung des Switches.

Zugriff auf die Konsole

Die Standardeinstellungen bei dem Zugriff auf die Konsole sind wie folgt:

  • 115200 baud rate
  • No parity
  • 8 data bits
  • 1 stop bit
  • No flow control

Da man auf einem aktuellen Mac einen USB-C Anschluss hat und nur ein USB-A Kabel mitgeliefert wird, benötigt man in der Regel einen Adapter. Wenn man das USB-Kabel an diesem Adapter anschließt, taucht das Cisco Gerät als USB-Gerät im Ordner /dev auf. Mit dem folgenden Befehl kann man den Namen der USB-Gerätes identifizieren:

ls /dev/*usb*

Bei mir heißt das USB-Gerät z.B. “ /dev/tty.usbmodemE69491011611″. Um mit dem Terminal auf diese Konsole zu kommen, muss ich dann nur den folgenden Befehl eingeben:

screen /dev/tty.usbmodemE69491011611 115200

Sichern der Konfiguration des Switches

Die Konfiguration des Switches kann mit copy über diverse Protokolle gesichert werden. Ich bevorzuge scp. Wichtig ist, dass der Pfad absolut angegeben wird. Bei einem Mac mit der IP-Adresse 192.168.140.157, dem User kristian und dem Passwort test muss man dann den folgenden Befehl eingeben.

copy running-configuration scp://kristian:test@192.168.140.157/Users/kristian/switch-maschen-23

Update des OS10

Ein Update des OS10 kann mit dem Befehl “image download” durchgeführt werden. Wenn das Update von dem zuvor beschriebenen MacBook aus geladen werden soll und das Image des OS10 den Namen “PKGS_OS10-Enterprise-10.5.0.1P1.433stretch-installer-x86_64.bin” hat, benötigt man den folgenden Befehl.

image download scp://kristian:test@192.168.140.157/Users/kristian/Downloads/PKGS_OS10-Enterprise-10.5.0.1P1.433stretch-installer-x86_64.bin

Um den Downloadstatus anzuzeigen, folgenden Befehl ausführen.

show image status

Um die heruntergeladene Images anzuzeigen, folgenden Befehl ausführen.

dir image

Zur Installation des heruntergeladenen Images, den folgenden Befehl benutzen.

image install image://PKGS_OS10-Enterprise-10.5.0.1P1.433stretch-installer-x86_64.bin

Der Fortschritt der Installation kann wieder mit folgendem Befehl “show image status” kontrolliert werden. Nach erfolgreicher Installation muss die Boot Partition geändert werden.

boot system standby

Der Status des Bootimages kann mit folgendem Befehl abgefragt werden.

show boot detail

Sobald das Update erfolgreich ausgeführt wurde, muss der Switch zum Schluss noch einem neu gestartet werden. Dies geschieht mit dem Befehl “reload”. Nach dem Neustart sollte dann die neue OS10 Version gebootet sein. Dies kann mit dem Befehl “show version” überprüft werden.

Einrichtung einer vlt Domain

Um eine vlt Domain 2 auf einem Switch mit der IP-Adresse “192.168.140.83 einzurichten, der über das Interface “ethernet1/1/1” und “ethernet1/1/2 mit einem Switch mit der IP-Adresse “192.168.140.84” verbunden ist, benötigt man die folgenden Konfigurationszeilen.

vlt-domain 2
 backup destination 192.168.140.84
 discovery-interface ethernet1/1/1-1/1/2

Um ein vlt mit dem vlt-port-channel 3 für einen Trunk einzurichten gibt man den folgenden Befehle ein.

interface port-channel3
 description "Name des vlt"
 no shutdown
 switchport mode trunk
 switchport access vlan 3002
 mtu 9216
 vlt-port-channel 3

Um z.B. das Interface “ethernet1/1/3” diesem vlt hinzuzufügen benötigt man die folgenden Befehle.

interface ethernet1/1/3
 no shutdown
 channel-group 3 mode active
 no switchport
 flowcontrol receive off

Auf dem zweiten Switch muss im Anschluss natürlich die gleiche Konfiguration gemacht werden, wobei die IP-Adresse in der vlt Domain entsprechend angepasst werden muss.

Um im Anschluss die eingerichtete vlt 2 Domain anzuzeigen und den Erfolg zu kontrollieren gibt man den folgenden Befehl ein.

show vlt 2 vlt-port-detail

Installation von Ansible auf einem Windows System

Was ist Ansible? Dies war die Frage, die mir meine Windows-Administratoren stellten, als ich mit der Idee einer Automatisierung von Windows mit Ansible um die Ecke kam. Eine durchaus berechtigte Frage, zumal die Automatisierung und Provisionierung von Windows durch Scripts aktuell noch nicht sehr verbreitet ist. Vielmehr gibt es hier eher grafisch gesteuerte Software wie den System Center Configuration Manager oder Windows Server Update Services.

Ansible ist ein Open-Source Automatisierungs-Werkzeug zur Orchestrierung und allgemeinen Konfiguration und Administration von Computern. Mit der Hilfe von Ansible kann man wiederkehrende Aufgaben bequem simultan auf mehreren System ausführen, ohne dass auf dem jeweiligen System eine zusätzliche Software verwendet wird. Dazu logt sich Ansible via SSH oder RPC auf dem zu administrierenden System ein und führt  vorher definierte Aufgaben aus. Diese Aufgaben werden in sog. Playbooks gespeichert. Playbooks werden im YAML-Format erstellt, erkennbar durch die Endung .yaml. Weitere Infos zur Syntax und Notation von YAML sind in der Ansible-Dokumentation zu finden.

Verwendung von Ansible unter Windows

Ansible basiert auf Python. Dabei erfolgt der eigentliche Zugriff auf das Windows Zielsystem dann ausschließlich über RPC. Ein Zugriff auf UNIX oder Linux erfolgt ausschließlich über SSH. Somit muss auf einem Windows, Linux oder Unix Zielsystem keinerlei zusätzliche Software installiert werden.

Für das Ausführen der Ansible-Skripte auf dem Quellsystem wird logischer Weise Python benötigt. Unter Linux wird ein Python eigentlich immer mitgeliefert. Deshalb kann dort Ansible einfach installiert und gestartet werden. Bei einem Windows System muss zunächst Python installiert werden, bevor man Ansible installiert. Ansonsten läßt sich Ansible nicht starten.

Da ich meinen Windows-Administratoren nicht zumuten wollte mit Linux zu arbeiten, habe ich mich dafür entschieden eine Administrations-Maschine mit Windows aufzusetzen, auf der man die Ansible Skripte direkt starten kann. Hier folgt die Anleitung für die Installation.

Anleitung für die Installation von Ansible unter Windows

Für die Installation der benötigten Software öffnet man unter Windows als Administrator die PowerShell. Hierfür drückt man einfach die Windowstaste, gibt „PowerShell“ ein und wählt nach einem Rechtsklick auf „Windows PowerShell“ den Menüpunkt „Als Adminsitrator ausführen“ aus. Anschließend gibt man in dem Fester mit der PowerShell den folgenden Befehl ein:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Nach der Eingabe möchte der Rechner neu starten. Nach einem Neustart kann man sich bei Windows 10 im Store ein Linux Distribution aussuchen und diese installieren. Dazu öffnen man den Windows Store (dazu wieder einfach die Windows Taste drücken und „Store“ eingeben). Anschließend kann man im Windows Store entweder nach Linux, oder direkt nach der gewünschten Distro suchen und diese installieren.

Bei Windows 2019 Server gibt es leider keinen Store. Hier muss die Linux Distribution von Hand bei Microsoft runtergeladen und installiert werden. Eine Anleitung für die Installationen und eine Liste der Linux Distributionen findet man bei Microsoft auf der Seite https://docs.microsoft.com/en-us/windows/wsl/install-manual. Um die Debian Distribution per PowerShell runterladen und entpacken zu lassen, kann man z.B. die folgenden drei Befehl in einer als “Administrator” gestarteten PowerShell eingeben:

Invoke-WebRequest -Uri https://aka.ms/wsl-debian-gnulinux -OutFile C:/Debian.appx -UseBasicParsing
Rename-Item C:/Debian.appx C:/Debian.zip
Expand-Archive C:/Debian.zip C:/Debian

Wenn die Befehle ausgeführt wurden, befinden sich die Installationsdaten von Debian Linux in dem Verzeichnis c:\Debian. Die eigentliche Installation startet man dann durch das ausführen der Datei Debian.exe in diesem Verzeichnis als Administrator. Es öffnet sich ein Fenster, in welchem die Installation durchläuft. Nach Abschluss der Installation wird man aufgefordert einen Benutzernamen für den Standardbenutzer und ein dazugehöriges Passwort einzugeben. Danach ist man in einer BASH Shell und kann das Debian Linux Benutzen.

Damit Linux von überall aufrufbar ist, sollte die Umgebungsvariable PATH noch entsprechend erweitert werden. Dies kann man mit den folgenden beiden PowerShell Befehlen machen:

$userenv = [System.Environment]::GetEnvironmentVariable("Path", "User")
[System.Environment]::SetEnvironmentVariable("PATH", $userenv + "C:\Debian;", "User")

Danach kann man sich in einer Kommandozeile die als Administrator gestaltet wurde jeder Zeit durch die Eingabe von “debian.exe” eine Linux Bash starten.

Als erstes sollte man das installierte Debian auf den aktuellen Stand bringen. Dazu gibt man den Befehl “sudo -s” ein und man wird um eine erneute eingäbe des Benutzerpasswortes gebeten. Nach der Eingabe erhält man eine root-shell. Wenn man in diese den folgenden eingibt, wird das Debian aktualisiert:

sudo apt update && sudo apt upgrade

Danach wird Python benötigt, da es die Grundlage von Ansible ist. Um Python zu installieren muss der folgende Befehle in eine root-Shell des Linux eigegeben werden:

apt-get -y install python-pip python-dev libffi-dev libssl-dev

Zum Schluss kommt dann die Installation von Ansible. Um immer die neuste Version von Ansible zu installieren, empfehle ich diese über das Python Paketverwaltungsprogramm (kurz Pip) zu machen. Dies geschieht durch die eingäbe des folgenden Befehlt in einer root-shell den Linux:

pip install ansible

Nachdem die Installation durchgelaufen ist, sollte Ansible funktionieren. Für alle weiteren Informationen empfiehlt sich ein Blick in die Ansible Dokumentation.

Let’s Encrypt Zertifikate für Postfix und Dovecot einrichten

In letzter Zeit wird die Verwendung der kostenlosen Zertifikate von Let’s Encrypt immer beliebter. Deshalb ist es naheliegend, diese auch für Verschlüsselung der Mails bei Postfix zu verwenden. Im folgenden sind die wenigen Schritte für die Einrichtung erklärt, die bei einem Ubuntu 18.04 notwendig sind.

Installation

Let’s Encrypt können mit dem certbot erzeugt werden. Die Installation des Programms bei Ubuntu 18.04 erfolgt mit den folgendenBefehlen.

sudo apt update
sudo apt install python-certbot-apache

Erzeugung eines Zertifikates

Das Zertifikat wir mit dem Programm certbot erzeugt. Da die Verifizierung des Host über den Webauftritt erfolgt. Ist es zwingend erforderlich, dass ein Apache auf dem Server installiert ist. Das Programm certbot macht dann die notwendigen Anpassungen an der Konfiguration des Apache Webservers. Mit der Option -d werden die Hostnamen angegeben, für welche das Zertifikat ausgestellt werden soll. Dabei ist es möglich das Zertifikat gleich für mehrere Hostnamen auszustellen. Nach dem ausführen des Programms certbot werden zudem einige Fragen gestellt, deren Beantwortung für das anpassen der Konfiguration des Apache Webservers notwendigen sind. Mit dem folgenden Befehl testet man z.B. das Ausstellen eines Zertifikates für die Hostnamen www.purrucker.de, purrucker.de imap.purrucker.de und smtp.purrucker.de. 

sudo certbot --apache --staging -d www.purrucker.de -d purrucker.de -d imap.purrucker.de -d smtp.purrucker.de

Wenn alles funktioniert, kann man das Kommando ohne die Option “–staging” ausführen. Dann fordert certbot beim Let’s-Encrypt-Projekt die generierten Zertifikate an, lädt diese herunter, installiert alle erforderlichen Dateien in das Verzeichnis /etc/letsencrypt, verändert die Apache-Konfiguration und startet Apache schließlich neu.

Einbindung des Zertifikates

Die Einbindung des Zertifikates in den Apache Webserver hat das Programm certbot erledigt. Bei Postfix und Dovecot muss die Einbindung jedoch von Hand erfolgen. Bei Postfix fügt man dazu die beiden folgenden Zeilen in die Datei /etc/postfix/main.cf ein.

smtpd_tls_cert_file= /etc/letsencrypt/live/www.purrucker.de/fullchain.pem
smtpd_tls_key_file= /etc/letsencrypt/live/www.purrucker.de/privkey.pem

Bei Dovecot benötigt man die drei folgenden Zeilen in der Datei /etc/dovecot/conf.d/10-ssl.conf.

ssl = yes
ssl_cert = </etc/letsencrypt/live/www.purrucker.de/fullchain.pem
ssl_key  = </etc/letsencrypt/live/www.purrucker.de/privkey.pem

Danach müssen beide Programme einmal neu gestartet werden.

service postfix restart
service dovecot restart

Automatische Erneuerung des Zertifikates

Das Let’s Encrypt Zertifikat ist grundsätzlich immer nur drei Monate gültig. Deshalb ist es notwendig, dieses regelmäßig zu erneuern. Um dies nicht immer von Hand machen zu müssen, sollte man sich dazu einen wöchentlichen Cronjob anlegen. Dazu einfach die Datei /etc/cron.weekly/letsencrypt mit folgendem Inhalt anlegen und ausführbar machen.

#!/bin/sh
# Datei /etc/cron.weekly/letsencrypt
certbot renew
result=$(find /etc/letsencrypt/live/ -type l -mtime -1 )
if [ -n "$result" ]; then
  systemctl restart postfix
  systemctl restart dovecot
fi