Was ist Ethernet?

,
Ethernet

Den Begriff Ethernet hat der eine oder andere vielleicht schon einmal gehört. Die meisten wissen allerdings nicht, was sich dahinter verbirgt. Dabei ist es durchaus keine neue Erfindung und gewinnt zunehmend an Bedeutung. Was sich hinter dem Begriff verbirgt und warum es so bedeutend ist, verraten wir hier.

Was ist Ethernet?

Ethernet

Mit dem Ethernet können Daten übertragen werden

Durch ein Ethernet können Daten in einem geschlossenen Netzwerk von einem Gerät zum anderen transportiert werden. Notwendig sind dafür ethernetfähige Geräte und eine Verbindung zwischen diesen. Auf diese Weise lassen sich beispielsweise Fotos vom Computer an einen Smart-TV senden oder Dokumente von einem PC an einen Drucker, eine externe Festplatte oder einen anderen Computer.

Notwendig für diese Übertragung und Verbindung ist ein Ethernetkabel – dieses ist besser unter dem Begriff LAN-Kabel bekannt. Das Kabel ist jeweils mit einem Gerät und mit dem Router verbunden. Der Router dient als Schnittstelle und verbindet die Geräte zu einem geschlossenen Netzwerk. Als Heimnetzwerk ist diese Form bereits relativ weit verbreitet. Deutlich bekannter ist es jedoch in Büros beziehungsweise in Unternehmen.

Wie funktioniert das Ethernet?

Ein Ethernet besteht im Grunde aus zwei Komponentengruppen: dem „Data Communication Equipment“ (DCE) und dem „Data Terminal Equipment“ (DTE).

Zu dem Data Communication Equipment gehören alle Geräte, die Daten empfangen und anschließend weiterleiten können. Also zum Beispiel Router, Hub und Switch. Sie dienen als Schnittstellen und als Verbindung zwischen den einzelnen Elementen des Data Terminal Equipment. Bei diesem handelt es sich um nichts anderes als die Endgeräte, die über das Ethernet die Daten aus dem DCE empfangen und ihrerseits über das DCE an andere Endgeräte versenden können.

Ethernet-Kabel

Vor allem für große Unternehmen ist dies interessant

Damit ein Ethernet funktionieren und die Daten innerhalb eines geschlossenen Netzwerks versandt werden können, muss das Data Communication Equipment mit dem Data Terminal Equipment über ein entsprechendes Kabel verbunden sein. Die korrekte Bezeichnung für dieses lautet Ethernet-Kabel. Die meisten kennen es jedoch als LAN-Kabel – wobei Local Area Network für „Lokales Umgebungsnetzwerk“ beziehungsweise „Lokales Netzwerk“ steht.

Bei den anfänglichen Ethernets handelte es sich hierbei um ein dickes Koaxialkabel. Daher wurde die Form zunächst als „ThickEthernet“ (dickes Ethernet) bezeichnet. Mit der Zeit wurden die Kabel dünner und so erhielt die Form eine neue Bezeichnung: „Thin Ethernet“ (dünnes Ethernet). Mittlerweile haben sich allerdings Telefonkabel aus Kupfer als Transportmedium für die Daten zwischen Verteiler- und Endgeräten bewährt. Für größere Entfernungen werden hingegen Kabel aus Glasfaser verwendet.

Von der Direktverbindung zum Hub

Während der Anfänge des Ethernets waren die Rechner direkt über einen Kabelstrang miteinander verbunden. Dieser durchgängige Kabelstrang machte es einerseits schwierig, Defekte aufzuspüren. Andererseits wurden gesendete Daten an alle verbundenen Geräte verteilt. Das konnte wiederum einen Datenstau nach sich ziehen und erschwerte zudem die Zugangsbeschränkung auf Daten innerhalb des Netzwerks.

Vorteile brachte die Einführung von Hubs. Die Geräte im Ethernet waren nicht mehr direkt untereinander, sondern über eine Schnittstelle miteinander verbunden. Hierdurch lassen sich Defekte entlang der Kabel einfacher aufspüren. Zudem können Daten gezielt von einem Sender zu einem Empfänger transportiert werden – ohne dem gesamten Netzwerk zur Verfügung zu stehen. Hierdurch wird die Sicherung beziehungsweise Zugangsbeschränkung leichter und weniger aufwendig.

Durch die gerichtete Datenübertragung nimmt zudem das Risiko für Datenstaus innerhalb des lokalen Netzwerks ab.

Die Geschichte des Ethernets

Als Erfinder gilt Robert Melancton Metcalfe. Entwickelt wurde es über mehrere Jahre hinweg an dem Xerox PaloAlto Research Center. Metcalfe legte einen wichtigen Grundstein in einem Memo aus dem Jahre 1973 – hier erwähnte er das Ethernet erstmals. Funktion und Aufbau waren jedoch bisher nur als Skizze vorhanden. Die Idee geht auf das ALOHAnet zurück. Ein funkbasiertes Netzwerkprotokoll aus Hawaii.

Bis zum ersten funktionsfähigen Ethernet und seiner Verbreitung vergingen jedoch mehrere Jahre. Erst Ende der 1970er und Anfang der 1980er Jahre wurden vermehrte Bemühungen unternommen, um das Ethernet als Standard zu integrieren.

Verbesserungen folgten durch:

Die richtigen Kabel sorgen für eine sichere Verbindung

Hubs: Die bereits erwähnten Hubs ließen kürzere und separierte Verbindungen zwischen den Geräten zu. Die Datenübertragung kann durch sie gezielter erfolgen. Zudem lassen sich Fehler einfacher finden und beheben.

Switching: Das klassische Ethernet erlaubt mehreren Geräten ein Kabel gemeinsam zu nutzen. Der Erfolg dieser Methode ist erfahrungsgemäß gut, solange das Verkehrsaufkommen – also die Menge der transportierten Daten – vergleichsweise gering ist. Anderenfalls können sich bei dieser Technik Staus bilden. Diese werden auch als Kollisionen bezeichnet. Switching speichert Datenpakete und reduziert damit das Risiko dieser Kollisionen.

Ethernet flow control: Die – zu Deutsch – „Flusskontrolle“ verhindert Kollisionen bei der Datenübertragung durch ein gezieltes Pausieren des Transports. Zu vergleichen ist das System mit einer Ampelkreuzung. Damit alle möglichst sicher und zügig passieren können, wird der Verkehrsfluss kontrolliert. Allerdings ist diese Technik heute nicht mehr weit verbreitet. Optional kann es jedoch noch immer Anwendung finden.

Einführung von Kupfer- und Glasfaserkabeln: Die Einführung von dünneren Kupfer- und Glasfaserkabeln machte die Technologie zum einen verlässlicher. Zum anderen können über spezielle Kupferkabel nicht nur Daten, sondern auch Energie übertragen werden. Die Geräte im Ethernet können darüber also ebenfalls mit Strom versorgt werden. Glasfaserkabel haben vor allem den Vorteil, dass sie einen schnellen und weiten Datentransport ermöglichen. Sie werden daher vorzugsweise in größeren Unternehmen eingesetzt, um weitere Entfernungen zu überbrücken.

Vorteile des Ethernets

Vor allem private Nutzer sind mit dem Ethernet meist wenig vertraut und wundern sich vielleicht, warum dieses nicht schlicht durch ein WLAN ersetzt wird. Immerhin ist dieses kabellos und sehr einfach zu installieren. Das Ethernet hat auch gegenüber dem WLAN (Wireless Local Area Network) aber einige Vorteile zu bieten.

Darunter:

  • Unabhängigkeit: Ob die Internet- und WLAN-Verbindung gerade funktioniert oder nicht, die Technologie erlaubt eine fortlaufende Datenübertragung. Hierdurch zeigt es sich insgesamt verlässlicher und ist vor allem in Unternehmen eine gute Wahl.
  • Sicherheit: da das Ethernet unabhängig von Internet und WLAN funktioniert und auf die Verbindung über Kabel angewiesen ist, kann es sicherer gestaltet werden. Gerade bei sensiblen Inhalten innerhalb von Unternehmen fällt der Schutz leichter.
  • Kostengünstig: Die Implementierung eines Ethernets ist im Vergleich zu anderen Systemen ausgesprochen kostengünstig.
  • Weiterentwicklung: Nicht zuletzt aufgrund seiner zahlreichen Vorteile und weiten Verbreitung wird das Ethernet fortlaufend weiterentwickelt. Auch das ist wiederum ein Vorzug.

Nachteile des Ethernets

Ein potentieller Nachteil des Ethernets ist, dass es trotz der Steuerung des Datenaustauschs noch immer zu Kollisionen kommen kann. Dadurch kann der Datentransfer stocken oder eingeschränkt sein.

Ceph deep scrub error beheben

, ,

Ceph deep scrub error beheben

Wer Ceph produktiv betreibt, wird im Laufe der Zeit immer mal wieder einen „unhealthy“ Zustand des Clusters erleben. Solange es sich dabei um eine noch harmlose „Ceph Warning“ geht, ist der gesunde Zustand des Clusters oft schnell wieder erreicht. Oft sogar ganz von alleine ohne ein Zutun des Linux-Administrators.

Doch was tun wenn „plötzlich“ ein echter Fehler auftritt? Mit „ceph health detail“ erfahren wir auf einen Blick, was das Cluster macht. In unserem konkreten Fall war Ceph ohne Vorwarnung auf unserem frisch installierten Proxmox Cluster in einen „Health Error“ gewechselt.

root@pve02:/var/log/ceph# ceph health detail
HEALTH_ERR 129254/2436848 objects misplaced (5.304%); 1 scrub errors; Possible data damage: 1 pg inconsistent
OBJECT_MISPLACED 129254/2436848 objects misplaced (5.304%)
OSD_SCRUB_ERRORS 1 scrub errors
PG_DAMAGED Possible data damage: 1 pg inconsistent
pg 4.41 is active+remapped+inconsistent+backfill_wait, acting [0,10]

In Folge einer neu eingebauten Platte ergaben sich eine überschaubare Menge (5,3%) von Placement Groups (pg), die nun nicht mehr richtig verteilt waren. In einer normalen Ceph Umgebung wäre das Thema in wenigen Stunden von alleine erledigt gewesen.

Im konkreten Fall haben wir aber eine Placement Group, die ein echtes Problem hat: PG 4.41.

Diese PG liegt sowohl auf OSD.0 als auch OSD.10 – zu erkennen an [0,10] -> hier werden die OSD Nummern aufgelistet.

Ceph deep scrub error analysieren

Um das Problem genauer zu analysieren loggen wir uns also per ssh auf den jeweiligen ceph hosts an auf  denen die osds liegen bzw. die OSD-Prozesse laufen. Pro Ceph-OSD liegt unter /var/log/ceph ein einzelnes Log-File. Wir schauen uns nun genau das Logfile des OSD-Prozesses an, der von Ceph selbst in der obigen Meldung ausgegeben wird.

Pve02# cd /var/log/ceph
(host mit osd.10)
cat ceph-osd.0.log | grep -i 4.41
-> viel output -> suche nach „error“ oder „fail“
=> kein Ergebnis

Da der erste Host keinen Fehler anzeigt, muss also die andere potentielle OSD, auf der die Placement Group liegt, ein Problem haben. Wie loggen uns also auf dem Host ein  auf dem die OSD.0 liegt

root@pve01# cd /var/log/ceph
root@pve01:/var/log/ceph# cat ceph-osd.10.log | grep -i 4.41
(…)
2018-06-21 20:05:48.793010 7fc78b0f3700  0 log_channel(cluster) log [DBG] : 4.41 deep-scrub starts
2018-06-21 20:06:23.380373 7fc78b0f3700 -1 log_channel(cluster) log [ERR] : 4.41 shard 0: soid 4:823a7476:::rbd_data.2862f74b0dc51.0000000000006060:head candidate had a read error <== Hier beginnt das Problem
2018-06-21 20:07:04.032674 7fc78b0f3700 -1 log_channel(cluster) log [ERR] : 4.41 deep-scrub 0 missing, 1 inconsistent objects
2018-06-21 20:07:04.032681 7fc78b0f3700 -1 log_channel(cluster) log [ERR] : 4.41 deep-scrub 1 errors
2018-06-21 20:18:38.424228 7fc7830e3700  4 rocksdb: (Original Log Time 2018/06/21-20:18:38.424147) [/home/builder/source/ceph-12.2.5/src/rocksdb/db/memtable_list.cc:383] [default] Level-0 commit table #451: memtable #1 done

Dem Logfile nach liegt also auf der OSD.10 vermutlich das Problem.

 

Lösungsansatz zur Behebung des Deep Scrub Error

Wir entfernen temporär die OSD.10 aus dem Cluster und „zwingen“ Ceph die Placement Groups neu zu verteilen. Die Lösung dabei ist höchst einfach:

Befehl: ceph osd out osd.<OSD_ID>

 

root@pve01:/var/log/ceph# ceph osd out osd.10
root@pve01:/var/log/ceph# ceph osd df
ID CLASS WEIGHT  REWEIGHT SIZE   USE   AVAIL  %USE  VAR  PGS
8   hdd 1.81929  1.00000  1862G  485G  1377G 26.05 0.80  51
9   hdd 1.81929  1.00000  1862G  677G  1185G 36.38 1.12  72
10   hdd 1.63730        0      0     0      0     0    0  52
11   hdd 1.63730  1.00000  1676G  534G  1142G 31.86 0.98  57
12   hdd 1.81929  1.00000  1862G  479G  1383G 25.76 0.79  51

 

Nun ist die OSD 10 ist raus und 52 Placement Groups müssen verschoben bzw. neu auf die restlichen Platten verteilt werden. Mit „ceph –w“ können wir den laufenden Status des Ceph Clusters permanent überwachen. Dort kann man nach einigen Minuten auch anhand der sich verkleinernden Prozentzahl hochrechnen, wie lange der Umverteilungs-Vorgang noch dauern wird.

Weitere Infos zum Deep Scrub Error

 

IPMI Einführung

, ,

IPMI  Einführung

IPMI (Intelligent Plattform Management Interface ) bietet die Möglichkeit per Web-GUI auf einen Server zuzugreifen, selbst wenn der Server ausgeschaltet ist.

Solange die IPMI-Netzwerkschnittstelle mit dem TCP-IP-Netzwerk verbunden ist und der Server im Standby am Stromnetz hängt, kann ein Server via IPMI fern gesteuert werden. Damit ist es etwa möglich, eine komplette Neu-Installation durchzuführen. Oft wird IPMI aber auch dazu genutzt, um einen Soft-Reset eines „hängenden“ Betriebssystems durchzuführen.

Die betreuenden Techniker ersparen sich so die Fahrt ins Rechenzentrum.

IPMI ist bei SuperMicro Mainboards in der Regel standardmäßig installiert. Bei ASUS Mainboards kann es mit Hilfe eines Chips dazu konfiguriert werden. Bei ASUS heißt das IPMI „BMC“.

IPMI einstellen / konfigurieren

Die Netzwerk-Einstellungen – konkret die IP-Adresse für IPMI– werden in der Regel im Bios des Rechners vorgenommen. Hier sind folgende Einstellungen vorzunehmen:

  • IP-Adresse
  • Netzwerkmaske
  • Gateway (Router)
  • DNS-Server

Das IPMI-Interface sollte nach Möglichkeit eine IP-Adresse im OOB (Out of band) Netzwerk des Rechenzentrums erhalten. IT-Administratoren sind gut beraten, dieses OOB-Netzwerk gut gegen äußere Angriffe abzusichern. Die IPMI-IP-Adresse sollte nach Möglichkeit nicht direkt aus dem Internet erreichbar sein.

Zugriff auf IPMI

Der Zugriff auf das Management von IPMI erfolgt über eine Web-Oberfläche. Unter der Adresse https://<IPMI-IP-Adresse/ kann der Server nach der Erst-Konfiguration erreicht werden.

Standard-Benutzer und Passwort

Der standardmäßig eingerichtete Zugang für IPMI lautet:

Username: admin

Passwort: admin

Das sollte man unbedingt nach der Inbetriebnahme ändern.

Wichtig: Die Änderung kann nicht im Bios sondern nur über die Weboberfläche durchgeführt werden.

Neu-Installation des Servers über IPMI

Prinzipiell kann unter IPMI ein CD oder DVD Medium von bis zu 4.7 GB Größe über das Netz gemounted werden und dem mit IPMI verwalteten Server als Boot-Medium zur Verfügung gestellt werden.

Auf diese Weise ist es möglich Betriebssystem-Installationen (Linux, Windows, VMWare) über das Netzwerk auszuführen. Ebenso ist es so möglich Treiber-Updates von eingebauter Hardware vorzunehmen.

IPMI zurücksetzen

Nicht selten wir das Passwort bei IPMI schlecht oder gar nicht gesichert. Was also tun, wenn „admin/admin“ nicht geht und auch das aktuelle Passwort für IPMI nicht (mehr) bekannt ist?

Für diesen Fall hat SuperMicro das kleine Tool IPMICFG erstellt.

Mit diesem kann man unter Linux und VMWare (was letztlich auch ein Linux ist) das Passwort kurz und schmerzlos neu setzen oder auch die Konfig des IPMI ändern.

 

Laden Sie sich dazu unter ftp://ftp.supermicro.com/utility/IPMICFG das dort gespeicherte Zip-File herunter und speichern es auf ihrem PC ab. Entpacken Sie die Zip-Datei mit IPMICFG in einen Unterordner. Kopieren Sie alle Dateien im passenden Unterverzeichnis auf den Linux bzw. VMWare Host.

Die Bits+Bytes für ein 64-bit Linux finden Sie unter „IPMICFG_1.27.1_build.170901\Linux\64bit“.

 

Bsp.: scp /<pfad>/IPMICFG_1.27.1_build.170901/Linux/64bit/* root@<esxi-host>:/tmp/

 

Verbinden Sie sich nun per ssh auf den VMWare oder Linux-Host und wechseln Sie ins Verzeichnis, in das Sie IPMICFG kopiert haben (hier /tmp). Zunächst müssen Sie die Datei „IPMICFG-Linux.x86_64“ ausführbar machen ( chmod +x)

 

Host# cd /tmp/
Host# chmod +x IPMICFG-Linux.x86_64

Hinweis: Mit dem Zusatz „—help“ erhalten Sie eine Übersicht aller Optionen und Befehlsteile von IPMICFG.

./IPMICFG-Linux.x86_64 –help

 

Konkret möchten wir zunächst wissen, welche Benutzer bereits in IPMI angelegt sind:

./IPMICFG-Linux.x86_64 -user list
[root@esxi01:/tmp/ipmicfg] ./IPMICFG-Linux.x86_64 -user list
Maximum number of Users          : 10
Count of currently enabled Users : 1

User ID | User Name        | Privilege Level | Enable

——- | ———–      | ————— | ——

2 | admin            | Administrator   | Yes

Wir sehen, dass der Benutzer „admin“ angelegt ist und die User-ID 2 aufweist. Die User-ID benötigen wir gleich um das Passwort zurück zu setzen.

Mit dem Befehl „-user setpasswd <user-id> <neues Passwort> können Sie nun das Passwort des Users „admin“ neu setzen.

./IPMICFG-Linux.x86_64 -user setpwd 2 <neues Passwort>

IPMI unter Windows

Die gerade beschriebene Vorgehensweise klappt übrigens auch unter Windows. Im Verzeichnis „\IPMICFG_1.27.1_build.170901\Windows\64bit“ finden Sie etwa die 64-Bit Variante der Software für einen Windows-Rechner bzw. Server. Ebenso ist unter „IPMICFG_1.27.1_build.170901\Windows\32bit“ eine 32-bit Version vorhanden.

Zur Benutzung von IPMICFG unter Windows kopieren Sie das entsprechende Verzeichnis auf ihren Windows-Rechner (auf dem IPMI installiert ist) und starten mit „cmd“ ein Kommandozeilen-Fenster.

Weitere Befehle von IPMI

Mit IPMICFG können Sie noch weit mehr als das Passwort zurücksetzen.

Factory default / Standard-Einstellungen setzen

Die Standard-Einstellungen für Netzwerk und Benutzer stellen Sie mit folgendem Befehl wieder her:

[root@esxi:/tmp/ipmicfg] ./IPMICFG-Linux.x86_64 -fd

IP-Adresse abfagen

[root@esxi:/tmp/ipmicfg] ./IPMICFG-Linux.x86_64 -m

Zusammenfassung / Übersicht von IPMI

[root@esxi:/tmp/ipmicfg] ./IPMICFG-Linux.x86_64 -summary
Summary
——————————————-
IP Address             : 10.10.10.20
BMC MAC Address        : 14:EE:A9:D7:B9:4E
Firmware Revision      : 1.07

 

Weiter Informationen und Downloads

Download IPMICFG

ftp://ftp.supermicro.com/utility/IPMICFG/

 

PDF-Handbuch zu IPMI-Konfig:

ftp://ftp.supermicro.com/utility/IPMICFG/Supermicro_Utility_User_Guide_IPMICFG.pdf

 

Bareos Einführung – Online-Backup

, ,
Die Anmeldemaske von Bareos

Einleitung zu Bareos

Bareos ist neben Backup-PC und Bacula eines der populärsten Programme aus der OpenSource-Community um entfernte Server zu sichern. Wer die Software Bacula zur Sicherung auf Platte oder Tape (Bandlaufwerk) im Rahmen der Linux-Administration schon eingesetzt hat, wird sich in Bareos schnell zurecht finden.
Im nachfolgenden Tutorial zu Bareos gehen wir der Reihe nach die Schritte durch, die zur Installation und Konfiguration von Bareos notwendig sind. Außerdem fügen wir exemplarisch einen Windows-Client und einen Linux-Client hinzu.

Im zweiten Tutorial zu Bareos behandeln wir die notwendigen Anpassungen in der Konfiguration, wenn Sie Bareos mit sehr vielen Clients nutzen möchten.
Bareos ist ein so genannter Fork von Bacula, das bereits seit über 10 Jahren als Online-Backup bekannt ist. Seit 2012 entwickeln mehrere Software-Entwickler Bareos auf Basis von Bacula weiter. Hauptgrund war die schleppende Weiterentwicklung von Bacula

Das Konzept von Bareos

Bareos besteht wie Bacula aus 3 Diensten:

  • Der Storage Daemon (bareos-sd) – dieser Dienst verwaltet den Speicher, auf denen Backups gespeichert werden. Das können Festplatten oder Tape-Drives sein.
  • Der Filedaemon von bareos (bareos-fd) übernimmt auf jedem Client die Aufgabe, die Dateien des Clients zum zentralen Storage Daemon zu schicken.
  • Der Bareos-Director (bareos-dir) ist die zentrale Komponente, über die der Netzwerk-Administrator Backup-Clients anlegt, Backup-Jobs definiert oder Restores vornehmen kann.

Der Storage-Daemon sowie der Director werden typischerweise auf einem Linux-Server installiert. Der Bareos-Filedaemon muss auf jedem zu sichernden Client installiert werden. Es existieren dazu Programm-Pakete für Windows (ab Windows 2008 Server bzw. Windows 7) sowie für alle gängigen Linux-Distributionen (CentOS, Redhat, Ubuntu, Debian, SuSE Linux, …) sowie Univention (Version 4).

Vorteile von Bareos

Durch die Verteilung des Programms auf drei Dienste kann Bareos relativ gut skalieren. D.h. es ist möglich, den Director und den Storage-Daemon auf getrennten Servern laufen zu lassen.

Gegenüber Bacula hat Bareos noch den angenehmen Vorteil, daß es von Haus aus eine Weboberfläche mitbringt, über die Jobs gestartet oder Restores vorgenommen werden können.
Bareos unterscheidet sich sowohl von Backup-PC als auch bacula, daß hinter Bareos mittlerweile eine deutsche GmbH sitzt, die von einigen ambitionierten Software-Entwicklern geführt wird. Hier können Firmen im Zweifel auch kostenpflichtigen IT-Support für Bareos einkaufen.

Voraussetzungen für Bareos

Damit Bareos einwandfrei funktioniert, benötigen wir

  • Einen zentralen Server mit ausreichend Speicherplatz als Zuhause für den Bareos-Director
  • Mysql auf dem zentralen Bareos-Director
  • Netzwerk-Verbindungen zu allen zu sichernden Clients (internes LAN, Internet oder via VPN) auf den Ports 9102, 9103 und 9104

Im konkreten Fall platzieren wir den Bareos-Server zentral im internen LAN der Firma so daß er von dort problemlos mit allen internen Servern per TCP/IP kommunizieren kann.
Für die Kommunikation mit verteilten Clients im Internet richten wir (weiter unten) auf der pfsense ein 1:1 NAT ein und erlauben von extern den Zugriff auf Port 9102.

Empfehlung für das Hardware-Sizing bzw. Setup von Bareos

Im Test ist eine virtuelle Maschine mit 4 GB RAM und 4 Kernen ausreichend. Für das Betriebssystem (Centos 7) reichen in der Regel 50 -100 GB.
Wieviel Plattenplatz für die zu sichernden Rechner notwendig ist, hängt von deren Größe sowie der Vorhaltezeit für Backups ab. Dazu unten bzw. im zweiten Teil des Tutorials mehr.
Im konkreten Beispiel starten wir mit 10 TB Speicher, die über eine separate virtuelle Festplatte via LVM (wichtig!) zur Verfügung gestellt wird.

Besonderheiten von Bareos

Um Bareos auszuprobieren sollten Sie den Hostnamen des zentralen Bareos-Servers auf „bareos“ eingestellt lassen. Der Name „bareos“ für den Hostnamen ist an unzähligen Stellen in den Konfigurations-Dateien von Bareos versteckt. Hier lohnt sich die Umbenennung (meiner Meinung nach) erst, wenn man größere Installationen von Bareos mit verteilten Diensten einrichten möchte.

Damit die Clients mit dem zentralen Bareos-Server kommunizieren können muss sowohl für den Bareos-Director der Hostname des Clients als auch für den Client der Hostname von Bareos (bareos) per DNS auflösbar sein.

Dazu richten Sie am besten im DNS einen entsprechenden Eintrag ein. Wer Bareos nur mal eben auf zwei Geräten testen möchte, kann selbstverständlich den passenden Eintrag auch in der /etc/hosts auf Linux bzw. unter c:\windows\system32\drivers\etc\hosts anlegen.

Installation und Vorbereitung von Bareos

Wir nutzen zur Installation von Bareos eine Centos 7 Standard-Installation. Die Root-Partition bekommt 45 GB. Das Verzeichnis /var/lib/mysql erhält eine separate Partition mit 25 GB.
Zusätzlich erstellen wir eine große, zweite Festplatte mit 10 TB, die wir später mittels LVM unter /var/lib/bareos hängen. Unter /var/lib/bareos speichert Bareos in der Standard-Konfiguration die einzelnen Volumes ab, auf denen die gesicherten Daten gespeichert werden.

Hinweis: Für einen Test reicht sicherlich deutlich weniger Platz unter /var/lib/bareos.
Für die Installation sind die folgenden Schritte notwendig:

  1. Bareos-Repository für Centos 7 herunterladen
  2. Bareos, Mysqld(bzw. Mariadb) sowie das Bareos-Webui installieren
  3. Datenbank mit Hilfe von 3 fertigen Skripten erstellen
  4. Dienste (Bareos und httpd) starten
  5. Web-User anlegen

Die Schritte im Einzelnen:

Bareos-Repositiory herunterladen

Mit dem nachfolgenden Snippet/Skript laden Sie automatisch das richtige Repository für yum herunter:

1
2
3
4
5
6
7
8
#
DIST=CentOS_7
DATABASE=mysql
yum -y install wget
# add the Bareos repository
URL=http://download.bareos.org/bareos/release/latest/CentOS_7
wget -O /etc/yum.repos.d/bareos.repo $URL/bareos.repo
#

Bareos, Mysqld und Bareos-Webui installieren

Direkt danach können wir mit einem Befehl alle notwendigen Programme installieren

1
yum -y install bareos bareos-database-mysql bareos-webui mariadb-server

Mariadb/Mysqld anpassen / Datenbanken erstellen

1
2
3
4
systemctl enable mariadb
systemctl start mariadb
mysql_secure_installation
#(Fragen mit “y” beantworten und neues Passwort für mysql Benutzer root vergeben)
1
2
3
4
5
6
vi ~/.my.cnf
#insert:
[client]
host=localhost
user=root
password=&lt;root mysql-Passwort&gt;

Danach rufen wir die 3 SQL-Skripte auf, die alle notwendigen Datenbanken sowie Tabellen für Bareos erstellen:

1
2
3
/usr/lib/bareos/scripts/create_bareos_database
/usr/lib/bareos/scripts/make_bareos_tables
/usr/lib/bareos/scripts/grant_bareos_privileges

Ergebnis:

1
2
3
4
5
6
7
8
9
[root@bareos01 ~]# /usr/lib/bareos/scripts/create_bareos_database
Creating mysql database
Creating of bareos database succeeded.
[root@bareos01 ~]#     /usr/lib/bareos/scripts/make_bareos_tables
Making mysql tables
Creation of Bareos MySQL tables succeeded.
[root@bareos01 ~]#     /usr/lib/bareos/scripts/grant_bareos_privileges
Granting mysql tables
Privileges for user bareos granted ON database bareos.

Bareos Dienst und Apache starten

Mit den nachfolgenden Befehlen starten wir die vier Dienste. Die letzten 4 stellen sicher, daß die 4 Dienste auch nach einem Reboot wieder automatisch gestartet werden.

1
2
3
4
5
6
7
8
systemctl start bareos-dir
systemctl start bareos-sd
systemctl start bareos-fd
systemctl start httpd
systemctl enable bareos-dir
systemctl enable bareos-sd
systemctl enable bareos-fd
systemctl enable httpd

Web-Konfiguration

Die Konfiguration von Bareos für das Web-Interface liegt unter /etc/httpd/conf.d/bareos-webui.conf . Hier müssen Sie an sich nichts tun.
Wer zum Testen auf die Firewall bzw. iptables verzichtet, stellt den Firewall folgendermaßen aus:

1
2
systemctl disable firewalld
service firewalld stop

Zu guter Letzt legen wir noch einen Benutzer namens “admin” für die Web-Gui von Bareos an.

1
2
3
bconsole
configure add console name=admin password=test123 profile=webui-admin
quit

Danach können Sie sich unter http://<IP>/bareos-webui/ mit dem Usernamen „admin“ sowie dem Passwort „test123“ anmelden.
Abbildung: Anmeldemaske von Bareos

Die Anmeldemaske von Bareos

Die Anmeldemaske von Bareos

 

Vorbereitung für Backups

Damit Sie nun auch tatsächlich Backups und Restores durchführen können, müssen wir noch wenige Anpassungen am Bareos-Director vornehmen:

FileSets anlegen.

Damit Bareos weiß was es sichern soll, muss für Linux und Windows jeweils eine Definition für ein so genanntes FileSet angelegt werden. Dazu erstellen Sie unter „/etc/bareos/bareos-dir.d/fileset“ die Datei LinuxAll.conf. In ihr ist enthalten welche FileSysteme unter Linux gesichert werden sollen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
FileSet {
Name = "LinuxAll"
Description = "Backup all regular filesystems, determined by filesystem type."
Include {
Options {
Signature = MD5 # calculate md5 checksum per file
One FS = No     # change into other filessytems
FS Type = btrfs
FS Type = ext2  # filesystems of given types will be backed up
FS Type = ext3  # others will be ignored
FS Type = ext4
FS Type = reiserfs
FS Type = jfs
FS Type = xfs
FS Type = zfs
FS Type = vzfs
}
File = /
}
Exclude {
File = /var/lib/bareos
File = /var/lib/bareos/storage
File = /proc
File = /tmp
File = /var/tmp
File = /.journal
File = /.fsck
}
}

Das Gleiche machen wir analog für Windows. Hier erstellen Sie eine Datei mit dem Namen WindowsAllDrives.conf im selben Verzeichnis:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
FileSet {
Name = "WindowsAllDrives"
Enable VSS = yes
Include {
Options {
Signature = MD5
Drive Type = fixed
IgnoreCase = yes
WildFile = "[A-Z]:/pagefile.sys"
WildDir = "[A-Z]:/RECYCLER"
WildDir = "[A-Z]:/$RECYCLE.BIN"
WildDir = "[A-Z]:/System Volume Information"
Exclude = yes
}
File = /
}
}

Die nachfolgenden Job-Definitionen verwenden gleich die eben angelegten FileSets.

JobDefinitionen anlegen

Wechseln Sie nun ins Verzeichnis „/etc/bareos/bareos-dir.d/jobdefs“ und legen dort die Standard-Job-Definition für Linux-Clients an. In dieser generellen Job-Definition wird zentral eingestellt, welches FileSet verwendet wird, wie oft und wohin gesichert wird.
Erstellen Sie dazu für alle Linux-Rechner die Datei DefaultLinux.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
JobDefs {
Name = "DefaultLinux"
Type = Backup
Level = Incremental
FileSet = "LinuxAll"                     # selftest fileset                            (#13)
Schedule = "WeeklyCycle"
Storage = File
Messages = Standard
Pool = Incremental
Priority = 10
Write Bootstrap = "/var/lib/bareos/%c.bsr"
Full Backup Pool = Full                  # write Full Backups into "Full" Pool         (#05)
Differential Backup Pool = Differential  # write Diff Backups into "Differential" Pool (#08)
Incremental Backup Pool = Incremental    # write Incr Backups into "Incremental" Pool  (#11)
}

Das Gleiche machen wir für Windows-Clients. Hier legen wir im gleichen Verzeichnis die Datei DefaultWindows.conf an:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
JobDefs {
Name = "DefaultWindows"
Type = Backup
Level = Incremental
FileSet = "WindowsAllDrives"
Schedule = "WeeklyCycle"
Storage = File
Messages = Standard
Pool = Incremental
Priority = 10
Write Bootstrap = "/var/lib/bareos/%c.bsr"
Full Backup Pool = Full                  # write Full Backups into "Full" Pool         (#05)
Differential Backup Pool = Differential  # write Diff Backups into "Differential" Pool (#08)
Incremental Backup Pool = Incremental    # write Incr Backups into "Incremental" Pool  (#11)
}

Die Definitionen zu Pools, Volumes und Storage lassen Sie für den Moment so wie sie sind.

Zeitpläne für Backups / Schedules

Zur Sicherheit prüfen Sie noch, ob der Zeitplan für die Backups auch an Ort und Stelle ist.
Dazu wechseln Sie ins Verzeichnis „/etc/bareos/bareos-dir.d/schedule“ .
Dort sollen Sie die Datei WeeklyCycle.conf vorfinden. Diese hat den Inhalt:

1
2
3
4
5
6
Schedule {
Name = "WeeklyCycle"
Run = Full 1st sat at 21:00                   # (#04)
Run = Differential 2nd-5th sat at 21:00       # (#07)
Run = Incremental mon-fri at 21:00            # (#10)
}

Sie haben nun alle grundsätzlichen Vorbereitungen abgeschlossen, um gleich mit wenigen Handgriffen den ersten Client in ihr neues Bareos-System aufzunehmen.

Einen Windows Client einrichten

Zur Installation eines Windows-Client (ab Windows 2008 Server oder Windows 7) laden Sie sich auf dem zu sichernden Server die für das Betriebssystem passende Windows-Datei herunter.
Extern: http://download.bareos.org/bareos/release/16.2/windows/

Die Installation starten Sie wie gewohnt mit einem Doppelklick auf die Exe-Datei des Bareos-Installers.

Der Windows-Installer für den Bares-Client unter Windows

Der Windows-Installer für den Bares-Client unter Windows

Standardmäßig ist bei der Windows-Installation lediglich der File-Daemon-Dienst angehakt. Sofern Sie den PC/Server lediglich sichern möchten, ist das auch vollkommen ausreichend.
Die beiden unteren Haken benötigen Sie nur, wenn Sie auf einer Windows-Maschine den Bareos-Director bzw. den Bareos-Storage-Daemon installieren möchten.
Klicken Sie anschließend auf „Next“.

Die richtigen Einstellungen für Bareos unter Windows

Die richtigen Einstellungen für Bareos unter Windows

In der nachfolgenden Maske müssen Sie mindestens bei (1) und (4) den Hostnamen ändern.
Der Reihe nach:
Bei (1) tragen Sie den vollständigen DNS-Hostnamen (fqdn) des Rechners ein auf dem Sie gerade Bareos installieren. Über den einzutragenden DNS-Namen muss der Bareos-Director den Client übers Netz erreichen können.
Die Zeile (2) „Director Name“ mit dem Eintrag „bareos-dir“ lassen Sie so wie sie ist. Ausnahme: Sie haben Ihren Director anders genannt. Dann passen Sie das hier an.
In der Zeile (3) finden Sie das von Bareos vorgeschlagene Passwort. Da es sich hier um ein willkürlich gewähltes Passwort handelt, können Sie das so lassen wie es ist. Das Passwort des Clients wird lediglich zur Kommunikation zwischen Client und Server verwendet. Sie selbst müssen es sich nicht merken.
Bei „Network Address“ (4) geben Sie wieder den vollständigen DNS-Hostnamen (fqdn) des Rechners ein auf dem Sie gerade Bareos installieren.
Klicken Sie nun auf „next“ und speichern Sie bitte unbedingt den Inhalt der letzten Maske ab:

Die fertige Konfig-Datei für den Windows Client von Bareos

Die fertige Konfig-Datei für den Windows Client von Bareos

Die 7 Zeilen Code der Konfiguration speichern Sie am besten zunächst auf dem Rechner unter c:\Install ab.

Bekanntmachen des Windows-Clients im Director

Wichtig: Damit der zentrale Bareos-Director den zu sichernden Client kennt, müssen Sie den Inhalt dieser Datei (inkl. Passwort-String) an der folgenden Stelle abspeichern:
Bareos# cd /etc/bareos/bareos-dir.d/client
Bareos# vi itsc40.itsc.local.conf # Inhalt einfügen, abspeichern
Hinweis: Die Datei muss die Endung *.conf haben. Zur besseren Übersicht empfehle ich die Datei wie den Hostnamen plus die Endung „.conf“ zu nennen. Im Beispiel also „itsc40.itsc.local.conf“.

Erstellen eines Backup-Jobs für den Windows-Client

Der Client ist nun zwar im Director bekannt, allerdings werden noch keine Backups durchgeführt. Eine Backup-JobDefinition für den Windows-Client erstellen Sie folgendermaßen:
Bareos# bconsole

1
2
*configure add job name=itsc40.itsc.local.job client=itsc40.itsc.local jobdefs=DefaultWindows
*quit

Mit dem obigen Befehl erstellen Sie für den Client mit Namen “itsc40.itsc.local” einen Job mit Namen “itsc40.itsc.local.job” und der JobDefinition, die unter “DefaultWindows” abgespeichert ist.

1
2
3
4
5
6
7
8
*configure add job name=itsc40.itsc.local.job client=itsc40.itsc.local jobdefs=DefaultWindows
Created resource config file "/etc/bareos/bareos-dir.d/job/itsc40.itsc.local.job.conf":
Job {
Name = itsc40.itsc.local.job
Client = itsc40.itsc.local
JobDefs = DefaultWindows
}
quit

Rein technisch wird dabei von Bareos eine Text-Datei unter „/etc/bareos/bareos-dir.d/job/“ mit dem Namen itsc40.itsc.local.job.conf abgespeichert. In dieser Datei wird lediglich die Zuordnung von Job-Definition zu Client vorgenommen.

Starten des Backup-Jobs für den Windows-Client

Der Backup-Job wird nun zur nächsten Gelegenheit (siehe Konfiguration) starten. Sofern Sie den Backup-Job sofort laufen lassen möchten, so tun Sie das wie folgt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Bareos# bconsole
*run job=itsc40.itsc.local.job
Using Catalog "MyCatalog"
Run Backup job
JobName:  itsc40.itsc.local.job
Level:    Incremental
Client:   itsc40.itsc.local
Format:   Native
FileSet:  WindowsAllDrives
Pool:     Incremental (From Job IncPool override)
Storage:  File (From Job resource)
When:     2018-01-03 16:54:57
Priority: 10
OK to run? (yes/mod/no): y
Job queued. JobId=345

Wenn Sie den Status des Backup-Jobs prüfen möchten, so können Sie das entweder in der Web-Gui machen oder über die bareos-Konsole mit dem Kommando „messages“:

1
2
3
4
5
6
7
Bareos# bconsole
*messages
03-Jan 16:54 bareos-dir JobId 345: No prior Full backup Job record found.
03-Jan 16:54 bareos-dir JobId 345: No prior or suitable Full backup found in catalog. Doing FULL backup.
03-Jan 16:55 bareos-dir JobId 345: Start Backup JobId 345, Job=itsc40.itsc.local.job.2018-01-03_16.54.58_36
03-Jan 16:55 bareos-dir JobId 345: Using Device "FileStorage" to write.
quit

Einen Linux-Client einrichten

Installation von Bareos auf Centos

Für Centos müssen Sie zuerst das passende Repository für Bareos herunterladen und nach /etc/yum.repos.de kopieren.

1
2
3
4
yum -y install wget
wget -O /etc/yum.repos.d/bareos-centos7.repo http://download.bareos.org/bareos/release/latest/CentOS_7/bareos.repo
yum -y install bareos-fd
systemctl enable bareos-fd

Hinweis: Für Centos 6 wählen Sie bitte „wget -O /etc/yum.repos.d/bareos-centos6.repo http://download.bareos.org/bareos/release/latest/CentOS_6/bareos.repo“

Die Installation auf Debian / Proxmox

Auf Debian ist bareos bereits in den Standard-Repositories enthalten. Daher können Sie direkt über apt-get den bareos-filedaemon installieren:

1
2
apt-get install bareos-filedaemon
systemctl enable bareos-filedaemon

Linux-Client auf dem Director einrichten

Damit nun der neue Linux-Rechner auch dem Bareos-Director bekannt gemacht wird, müssen wir folgendes auf dem zentralen Bareos-Director ausführen.

1
2
3
bareos# bconsole
*configure add client name=&lt;CLIENT&gt; address=&lt;IP/FQDN&gt; password=&lt;SOME_PASSWORD&gt;
*quit

Hinweis: Ich empfehle beim Client-Namen und bei der Adresse jeweils den FQDN des zu sichernden Servers zu verwenden.
Anmerkung: Die Anlage eines Client in der Web-Gui ist (bis jetzt) leider nicht möglich.

Linux-Client anlegen in der Konsole von Bareos

Linux-Client anlegen in der Konsole von Bareos

Beispiel:

1
2
3
4
5
6
7
8
9
10
11
12
*configure add client name=skisp02.veryhost.de address=skisp02.veryhost.de password=geheim123
Exported resource file "/etc/bareos/bareos-dir-export/client/skisp02.veryhost.de/bareos-fd.d/director/bareos-dir.conf":
Director {
Name = bareos-dir
Password = "[md5]576aa4c2e8948b2a10d21617d3a84085"
}
Created resource config file "/etc/bareos/bareos-dir.d/client/skisp02.veryhost.de.conf":
Client {
Name = skisp02.veryhost.de
Address = skisp02.veryhost.de
Password = geheim123
}

Bareos legt nun die Client-Datei, die Sie gleich auf den Linux-Client kopieren unter „/etc/bareos/bareos-dir-export/client/<clientname>/bareos-fd.d/director/ ab.
Die dort abgelegte Datei „bareos-dir.conf“ kopieren Sie auf den Linux-Client in das Verzeichnis
/etc/bareos/bareos-fd/director
Anschließend starten Sie den bareos-FileDaemon neu.

1
Client# service bareos-fd restart

Backup-Job für den Linux-Server anlegen

Damit anschließend auch wirklich täglich Backups erstellt werden, benötigen wir wie beim Windows-Client auch eine Job-Definition. Diese erstellen Sie ebenfalls über die Bareos-Konsole:

1
2
3
Bareos# bconsole
*configure add job name=&lt;fqdn&gt;.job client=&lt;fqdn&gt;jobdefs=DefaultLinux
quit

Wenn Sie nun nichts weiter tun, dann wird der Backup-Job entsprechend der Backup-Konfiguration während der folgenden Nachstunden starten. Wenn Sie den Backup-Job sofort starten lassen möchten, dann geben Sie folgendes ein:

1
2
Bareos# bconsole
*run job=&lt;clientname&gt;.job

Beantworten Sie die abschließend Frage mit “y“ und schon startet der Backup-Job.

Den Backup-Job für den Linux-Client starten

Den Backup-Job für den Linux-Client starten

Anmerkung:
Sofern einmal eine Job-Definition für einen Client angelegt ist und der Backup-Job läuft, können Sie alle weiteren Aktionen in der Web-Oberfläche von Bareos durchführen.

Fazit zu Bareos

Bareos ist mit einigen kleinen Hürden ein sehr brauchbares Tool zur Sicherung von verteilten Rechnern. Vor allem die Web-Oberfläche macht es den Netzwerk-Admins sehr leicht, die täglichen Jobs für Backup und Restore im Blick zu haben.
Welche Anpassungen Sie an Bareos für eine flächendeckende Nutzung mit vielen Clients vornehmen sollten, behandeln wir im zweiten Teil des Tutorials zur Bareos.

Weiterführende Infos zu Bareos

Weitere Informationen und Sites zu Bareos Online-Backup:

Da Bareos immer noch in viele Einstellung identisch mit Bacula ist, hilft an einigen Stelle auch die Doku von Bcula weiter: Hompage von Bacula
Bücher zu Bacula bzw. Bareos:

 

Ansible Tutorial – Einführung

, ,
Erneute Ausführung eines ansible Playbooks

Einleitung zu ansible

Ansible ist eine Software zur zentralen Verwaltung (Orchestrierung) und Administration von verteilten Servern. Die Community-Version von Ansible selbst ist als OpenSource Software im Rahmen der Linux-Administration lizenzfrei. Neben der Community-Edition von ansible gibt es vom Hersteller (Redhat) noch weitere lizenzpflichtige Editionen, die etwa ein Dashboard oder Workflows zur Verfügung stellen.

Ansible ist seit 2012 „auf dem Markt“ und aktuell in der Version 2.4 in den meisten Linux-Distributionen wie CentOS, Ubuntu oder Debian enthalten.

Warum ansible?

Ansible gehört neben Puppet und Chef zu den bekanntesten Software-Produkten, mit denen verteilte Systeme administriert werden können. Gegenüber puppet und chef hat ansible jedoch einige Vorteile:

  • Ansible benötigt keine zentrale Komponente. Ein Rechner, um per ssh auf die zu verwaltenden Server zugreifen kann, reicht aus.
  • Der Einarbeitungsaufwand ist bei ansible deutlich geringer als bei chef oder puppet
  • Es gibt für ansible eine Vielzahl von fertigen Skripten (so genannten Playbooks), die sie meistens kostenlos (etwa bei github) herunter laden können.

Voraussetzungen für ansible

Damit ansible einwandfrei funktioniert, benötigen wir

Eine Workstation / Server

Für die tägliche Arbeit mit ansible empfiehlt sich die Installation auf einem Rechner bzw. Server, auf dem Linux installiert ist. Das kann die Workstation des Linux-Administrators oder ein anderer Rechner sein, von dem aus die zu verwaltenden Server gut zu erreichen sind.

Netzwerk

Damit ansible von der Administrations-Installation aus auf die zu verwaltenden Server zugreifen kann, müssen diese über ein Netzwerk erreichbar sein. Dabei spielt es keine Rolle, ob die Geräte über das Internet, das LAN oder ein VPN erreicht werden können.

SSH-Keys

Die Kommunikation zwischen ansible und den entfernten Hosts läuft im Wesentlichen über ssh (secure shell). Damit ansible auf dem zentralen Host ohne Passwort auf die entfernten Server zugreifen kann, muss eine SSH-Verbindung mittels Zertifikat möglich sein.(Wie diese eingerichtet wird erklären wir weiter unten)

 

Installation und Vorbereitung von ansible

Neben der Software von ansible benötigen wir nur wenig weitere Zutaten:

Die Installation von ansible erfolgt in der Regel durch den Paket-Manager der eingesetzten Linux-Distribution. Ansible selbst basiert auf der Programmiersprache python. Die dafür notwendigen Pakete werden durch den Paketmanager (yum oder apt) mit installiert.

Installation von ansible auf Centos/RedHat

Centos# yum install ansible

Installation von ansible unter Ubunti/Debian

Debian# apt-get install ansible

SSH-Key erstellen

Damit später eine passwort-lose Anmeldung auf den entfernten Rechnern möglich ist, muss einmal zentral auf dem Verwaltungs-Server ein ssh-Schlüssel erzeugt werden:

1
Linux# ssh-keygen

Die anschließend gestellten Fragen nach dem Namen (id_rsa und id_rsa.pub) sowie einer Passphrase bestätigen Sie mit Return.

Nun sind um Verzeichnis /root/.ssh/ zwei Dateien vorhanden. Die ist der geheime Teil des Schlüssels (id_rsa) sowie der öffentliche Teil des RSA-Schlüssels: id_rsa.pub (pub = public).

SSH-Key auf die entfernten Rechner kopieren

Damit eine passwortlose Anmeldung auf den entfernten Rechnern möglich ist, muss nun der öffentliche Teil des Schlüssels auf den entfernten Server kopiert werden. Das geht am einfachsten mit ssh-copyid

1
Linux# cd /root/.ssh/

Linux# ssh-copy-id -id id_rsa.pub root@<entfernter Server>
#Ersetzen Sie <entfernter Server> durch die IP oder den DNS-Namen des entfernten Servers.

Sie werden nun noch einmal das Passwort des entfernten Servers angeben müssen. Danach sollte eine SSH-Anmeldung ohne Passwort möglich sein.

Testen Sie ob die Anmeldung ohne Passwort klappt:

1
Linux# ssh root@&lt;entfernter Server&gt;

Wenn dieser Schritt gekappt hat, dann können wir mit der eigentlichen Vorbereitung von ansible loslegen

Die Konfiguration von ansible

Nach der Installation von ansible auf dem zentralen Rechner hat der Paket-Manager ein Verzeichnis für ansible unter /etc/ansible angelegt. Im Verzeichnis /etc/ansible liegen zwei elementare Dateien:

Ansible.cfg

In der Datei ansible.cfg sind die grundsätzlichen Einstellungen für ansible abgelegt.

Wichtig in der Konfig-Datei ist, daß der Pfad zu Hosts-Datei nicht auskommentiert ist. Sofern die Zeile mit ‚#‘ beginnt, entfernen Sie das ‚#‘ Zeichen.

1
#inventory      = /etc/ansible/hosts

Es empfiehlt sich, alle weiteren Einstellungen zunächst einmal so zu belassen, wie sie sind.

Hosts-datei

Ebenfalls unter /etc/ansible liegt die Datei „hosts“. (nicht zu verwechseln mit der Datei /etc/hosts).

In dieser Datei speichert ansible die Namen und Adresse der zu verwaltenden Server

Struktur der Hosts-Datei

Server und Rechner die Sie mit ansible verwalten möchten, müssen Sie an mindestens einmal in der Datei /etc/ansible/hosts eintragen.

Sofern Sie ihre zu verwaltenden Server alle gleich (im Sinne der Konfiguration) sind, können Sie diese der Reihe nach untereinander in der Hosts-Datei eintragen.

Gruppen in der Hosts-Datei

Sofern Sie Ihre Server nach bestimmten Kategorien gruppieren möchten, so tragen Sie in die Hosts-Datei den Namen ihre Gruppe in eckigen Klammern ein und führen direkt danach ihre Server nacheinander zeilenweise auf.

Bsp.:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Server01.domain.tld
Server02.domain.tld
Testserver01.intern.local
Testserver02.intern.local
[Produktion]
Server01.domain.tld
Server02.domain.tld
[Testserver]
Tessterver01.intern.local
Testserver02.intern.local
[Webserver]
Server01.domain.tld
Testserver01.intern.local
[Datenbankserver]
Server02.domain.tld
Testserver02.intern.local

Die Gruppen können Sie später dazu nutzen, die eigentlichen Skripte von ansible gezielt nur auf eine oder mehrere Gruppen anzuwenden.

Das macht u.a. dann Sinn, wenn etwa unterschiedliche Linux-Paketmanager zum Einsatz kommen oder Sie zwischen Produktions- und Entwicklungs-Servern unterscheiden wollen.

Der Ansible Befehl

Für ansible sind im täglichen Betrieb zwei Befehle wichtig

  • ansible zum interaktiven Aufruf
  • ansible-playbook zum ausführen komplexerer Skripte

 

Interaktive Nutzung von ansible

Der Befehl „ansible“ ist hilfreich, um direkt bestimmte einmalige und meist kurze Kommandos auf einem Remote-Host abzusetzen. Insofern ähnelt ansible hier dem klassischen ssh-Kommando.

Ein Beispiel:

1
ssh <a href="mailto:root@remotehost.tld">root@remotehost.tld</a> „ls –la /root“

ist im Wesentlichen identisch mit:

1
ansible remotehost.tld  -m shell -a "ls -la /root/”

Beide Befehle listen den Inhalt des Verzeichnisses /root auf.

Im Gegensatz zu ssh können Sie aber bei ansible diesen Befehl auf mehrere Hosts anwenden – vorausgesetzt die Server sind in der /etc/ansible/hosts aufgelistet.

Bsp.:

ansible centos –m shell –a „ls –la /root“

Die obere Zeile wird simultan auf allen Server ausgeführt, die in der Gruppe “[centos]” in der Datei /etc/ansible/hosts enthalten sind.

Alle Systemparameter eines Hosts abfragen

Um etwa alle bekannten System-Parameter eines Hosts (die ansible kenn) abzufragen und auszugeben, reicht der folgende Einzeiler:

1
2
3
4
5
6
7
8
9
10
11
12
Linux# ansible &lt;hostname&gt; -m setup
[root@ ansible]# ansible sample.domain.tld -m setup | head -n10
sample.domain.tld | SUCCESS =&gt; {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"123.231.218.129"
],
"ansible_all_ipv6_addresses": [],
"ansible_apparmor": {
"status": "disabled"
},
"ansible_architecture": "x86_64",

Diese System-Informationen nennt ansible “facts” und sammelt sie bei jedem Aufruf von ansible. Auf diese ansible-facts kann später in Skripten zugegriffen werden. So ist es etwa möglich Unterscheidungen in Skripten bei unterschiedlichen Linux-Versionen oder Distributionen zu machen. Dazu gleich mehr.

Ansible Playbooks / Skripte

Ansible Skripte heißen „Playbooks“ und werden im YAML-Format erstellt und in der Regel mit der Endung .yaml abgespeichert. Neben den eigentlichen Playbooks können von ansible noch ganz normale Dateien kopiert werden. Außerdem steht mit Jinja2 eine Template-Engine zur Verfügung, mit der sie Datei-Vorlagen mit Variablen ersetzen und anschließend auf die Zielrechner kopieren können.

Hinweis: Das YAML-Format der Playbooks ist etwas tricky was die Einrückungen am Zeilenanfang anbelangt. Es empfiehlt sich daher einen Editor (z.B. Notepad++) zu verwenden, der das berücksichtigt, so daß Sie sich auf das Erstellen bzw. Anpassen des Playbooks konzentrieren können.

Mehr zur Notation von YAML in ansible finden sie in der ansible-Dokumentation.

Verzeichnis-Struktur für Ihre Skripte:

Damit Ihre Skripte später leichter zu managen sind, empfehle ich Ihnen folgende Struktur:

  • Legen Sie ein Verzeichnis für die ansible Playbooks an z.B. /root/ansible
  • Legen Sie ein weiteres Unterverzeichnis für Dateien und Templates an, die durch die Playbooks kopiert oder verändert werden sollen. /root/ansible/files

Ein einfaches ansible Playbook

Im ersten Skript bzw. Playbook verwenden wir wenige Zeilen ansible-Code um den Apache httpd-Dienst zu installieren. Kopieren Sie die nachfolgenden Zeilen in eine Datei mit dem Namen „playbook-install-httpd.yml“ ab:

1
2
3
4
5
---
- hosts: all
tasks:
- name: ensure apache is at the latest version
yum: pkg=httpd state=latest

Hinweis: Bitte beachten Sie die Anzahl der Leerzeichen bzw. Einrückungen am Anfang einer jeden Zeile.

Zur Erklärung:

In der ersten echten Zeile definieren Sie hinter „- hosts:“ zunächst auf welche Server/Rechner das Skript angewendet werden soll. In unserem Beispiel habe ich „all“ gewählt. Das ist die bei ansible bereits vordefinierte Gruppe aller Server, die in der Datei /etc/ansible/hosts enthalten sind.

Danach werden nach dem Schlüsselwort „tasks:“ die eigentlichen Zeilen mit Kommandos untereinander geschrieben.

Der Eintrag „- name:“ definiert eine Task mit einem Namen, der nach dem „:“ eingetragen ist. Hier können Sie ihren Aufgaben sinnvolle Begriffe geben, die in der späteren Ausführung der Tasks für Sie sichtbar sind.

In der letzten Zeile erfolgt dann das erste echte Kommando: Eine Installation durch den Paket-Manager „yum“. Über das ansible-Modul für yum „pkg=httpd“ (sprich: Package -> httpd) wird festgelegt, was installiert werden soll. Mit der Anweisung „state=latest“ definieren Sie, welche Version von apache Sie installieren lassen wollen.

Hinweis: Im obigen Beispiel haben wir im Skript angegeben, daß der Paketmanager yum sein soll. Daher würde dieses Skript auf Ubuntu oder Debian keinen Sinn ergeben, da hier der Paket-Manager apt heißt.

Daher wäre es für dieses Skript sinnvoll, es auf die Gruppen einzuschränken, die entweder CentOS oder Redhat installiert haben.

Ablauf des Skripts / Playbooks

Um das Playbook auf dem entfernten Host ablaufen zu lassen, geben Sie auf der Kommandozeile folgendes ein:

ansible-playbook playbook-install-httpd.yml –limit=<hostname>*

Erklärung: ansible-playbook ist der ansible-Befehl, der Playbooks im YAML-Format interpretieren und ausführen kann.

Sofern Sie die Ausführung eines Skripts auf wenige oder nur einen Host beschränken wollen, so nutzen Sie den Schalter „—limit=<hostname>*“ und geben etwa ihren Hostnamen (so wie er in der /etc/ansible/hosts eingetragen ist) ein.

Ausgabe eines Skripts bzw. Playbooks bei ansible

Ausgabe eines Skripts bzw. Playbooks bei ansible

Im Beispiel (siehe Bild) ist der Hostname mit 10.39.189.114 in der /etc/ansible/hosts eingetragen.

 

Ablauf eines Skripts

Bei allen ansible-Playbooks werden im ersten Schritt zunächst einmal die so genannten „Facts“ durch ansible gesammelt. Zu diesen Fakten gehören neben der Betriebssystem-Version unter anderem auch die Software-Stände oder die IP-Adresse des Hosts.

Anschließend werden die einzelnen Aufgaben (Tasks) der Reihe nach abgearbeitet. In der Zeile nach TASK (siehe Bild) erscheint dann lediglich die Beschreibung, die Sie in ihrem Skript nach dem Schlüsselwort „name:“ eingegeben haben.

Sofern lediglich Informatoinen von ansible erhoben werden oder wenn Aufgaben keine Veränderung nach sich ziehen, wir die Zeile GRÜN dargestellt. Sofern Änderungen vorgenommen werden, so erscheint die Ausgabezeile in GELB.
Fehler erscheinen in ROT.
Ganz zum Schluss werden im „Play Recap“ noch einmal für jeden Host.
Falls Sie ein Skript versehentlich zweimal durchlaufen lassen, so ergibt sich bei der Ausgabe folgendes Bild:

Erneute Ausführung eines ansible Playbooks

Erneute Ausführung eines ansible Playbooks

Ansible hat bei der Sammlung von Fakten festgestellt, daß die Software für den httpd-daemon (apache2) bereits in der aktuellsten Version installiert ist. Daher wird die Task mit „ok: [servername]“ quittiert und daher in Grün ausgegeben.

 

Ein Skript erweitern: Apache installieren und starten

Unser einfaches Beispiel hat nun zwar den Apache-Webserver installiert, aber noch nicht gestartet. Ein dauerhafter Start nach einem Reboot des betroffenen Servers fehlt ebenfalls.

Ebenso fehlen die für den apache sinnvollen Erweiterungen wie PHP, Python oder Perl. Mit der folgenden Erweiterung installieren wir nun die noch fehlenden Pakete, starten den apache und stellen sicher, daß nach einem Reboot der httpd-Dienst wieder startet.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
- hosts: centos
tasks:
- name: ensure apache is at the latest version
yum: pkg=httpd state=latest
- name: ensure php is at the latest version
yum: pkg=php state=latest
- name: ensure perl is at the latest version
yum: pkg=perl state=latest
- name: ensure python is latest
yum: pkg=python state=latest
- name: ensure httpd is running (and enable it at boot)
service: name=httpd state=started enabled=yes
handlers:
- name: restart httpd
service: name=httpd state=restarted

Erklärung zum Skript:

In der Hosts-Anweisung haben wir nun nur die Gruppe [centos] in der Datei /etc/ansible/hosts angesprochen. Die nachfolgenden 4 Anweisungen installieren erst den Apache, dann php und danach perl und python.

Die Anweisung „service: name=httpd state=started enabled=yes” stellt sicher, daß der httpd-daemon sofort gestartet wird und außerdem in der Systemkonfiguration (systemctl bzw. chkconfig) dauerhaft auf „on“ gesetzt wird.

Der Eintrag nach „handlers:“ bewirkt folgendes: Sofern eines der vorangegangen Kommandos eine Änderung am System vorgenommen hat, wird der httpd-Dienst neu gestartet. Sofern keines der Kommandos eine Änderung bewirkt, wird der httpd-Dienst nicht neu gestartet.

Bedingungen in Skripten

Wie oben bereits beschrieben, kann es Sinn machen, Unterscheidungen in Skripten vorzunehmen um etwa die Linux-Distribution und damit den Paketmanager zu unterscheiden.

Der folgende Auszug aus einem komplexeren Skript unterscheidet bei Centos nach der Major-Release-Version (6 oder 7) und kopiert eine unterschiedliche Datei, je nachdem ob wir eine Centos-6 oder Centos-7 Installation haben:

1
2
3
4
5
6
7
8
9
10
11
tasks:
- name: copy bareos repo file for Centos 7.x
copy: src=files/bareos7.repo dest=/etc/yum.repos.d/
when:
- ansible_distribution == "CentOS"
- ansible_distribution_major_version == "7"
- name: copy bareos repo file for Centos 6.x
copy: src=files/bareos6.repo dest=/etc/yum.repos.d/
when:
- ansible_distribution == "CentOS"
- ansible_distribution_major_version == "6"

Das Schlüsselwort „when:“ nach der eigentlichen Task definiert, unter welchen Umständen die Aufgabe (Task) durchgeführt wird.

Der eigentliche ansible Befehl „copy:“ kopiert die Datei, die nach „src“ angegeben ist in das Verzeichnis, das nach „dest=“ folgt. Hier also: „files/bareos6.repo“ bzw. „files/bareos7.repo“ nach /etc/yum.repos.d .

Variablen und Templates in Skripten verwenden

Anstatt einfach eine statische Datei vom Kontroll-Rechner auf den entfernten Hosts zu kopieren, kann auch ein Template verwendet werden. Der Unterschied zum Kopieren ist der, daß Sie beim Template Host-spezifische Änderungen an der zu kopierenden Datei bzw. dem Template vornehmen können.

Templates haben bei ansible üblicherweise die Endung .j2 . Die eigentlichen Variablen werden in Templates oder Skripten mit doppelten geschweiften Klammern eingefügt.

Bsp.:

1
2
- name: modify index.html.j2 and copy to /var/www/html
template: src=files/index.html.j2 dest=/var/www/html/index.html

Inhalt von files/index.html.j2:

1
2
3
Sie sehen den Webserver auf {{ ansible_fqdn }} .
Auf dem Server ist {{ ansible_distribution }} in der Version
{{ ansible_distribution_major_version }} installiert .

Beim Kopieren des Templates werden nun pro Host der jeweilige Hostname sowie der Name und die Nummer der Linux-Distribution ausgegeben.

Die Variablen ansible_fqdn sowie ansible_distribution und ansible_distribution_major_version werden durch ansible beim Gather-Facts Durchlauf mit Inhalt gefüllt

Eigene Variablen in Playbook und Templates

Ansible erlaubt die Definition und Verwendung eigener Variablen. Variablen sind dabei immer „Schlüsselname->Wert“-Zuweisungen. Dabei kann nicht nur ein Wert definiert werden, sondern eine Variable kann eine Liste von Werten enthalten.

Variablen können vorab im Kopf eines Playbooks definiert werden oder zur Laufzeit auf dem Host erfragt und registriert werden:

Beispiel:

1
2
3
- hosts: webservers
vars:
http_port: 80

Hier wird die Variable „http_port“ mit dem Wert „80“ belegt.

Beispiel für die Registrierung von Variablen zur Laufzeit:

– hosts: web_servers tasks: – shell: /usr/bin/foo register: foo_result ignore_errors: True

Im zweiten Beispiel wird auf dem entfernten Host der Shell-Aufruf “/usr/bin/foo” ausgeführt. Das Ergebnis wird als Variable „foo_result“ gespeichert. Die Aufgabe der Zuweisung von Wert zu Variable übernimmt das Schlüsselwort „register“. Der eigentliche Inhalt der Variable kann später weiter verwendet werden.

Hinweis: Das Programm /usr/bin/foo gibt es nicht wirklich.

Skripte in Playbooks wieder verwenden

Über include und import-Anweisungen können Sie bestehende Skripte in ihren Playbooks einbinden und so mehrfach verwenden. Ein so eingebundenes Playbook-Fragment kann wiederum beliebig viele Tasks enthalten.

Ein Beispiel.:

1
2
3
4
5
6
7
8
- hosts: all
vars:
internal_networks: [10.10.10.0, 10.20.20.0]
tasks:
- include_tasks: ansible_bareos_external_network.yml
when:  ansible_default_ipv4.network not in internal_networks
- include_tasks: ansible_bareos_internal_network.yml
when:  ansible_default_ipv4.network in internal_networks

Über das Schlüsselwort “include_tasks:” definieren Sie das Skript, das eingefügt warden soll.

Im obigen Beispiel wurde außerdem eine eigene Variable namens „internal_networks“ definiert und mit den Werten „10.10.10.0“ sowie „10.20.20.0“ vorbelegt..

Je nachdem ob die (beim Fakten-Check) ansible-Variable ansible_default_ipv4.network identisch mit einem der Einträge bei „internet_networks“ ist, wird entweder das Skript ansible_bareos_internal_network.yml oder ansible_bareos_external_network.yml ausgeführt.

Hinweis: Ein yaml-Skript, das sie über include in ein Skript einfügen, darf nur reine Task-Anweisungen enthalten. Hosts-Anweisungen sind nicht erlaubt. Die nehmen Sie im Haupt-Skript vor.

Fazit zu ansible:

Mit ansible kann sich jeder Netzwerk-Administrator mit wenig Aufwand seine eigene Sammlung an Skripten zum Systemmanagement erstellen. Vor allem die große Auswahl an bestehenden Playbooks macht es auch Einsteigern sehr leicht, mit ansible erste Erfolge zu erzielen.

Für viele Linux-Admins sind die kleinen und großen ansible-Helferlein aus dem IT-Alltag gar nicht mehr wegzudenken. Wer einmal das Konzept und die Einfachheit von ansible verstanden hat, will meist keine 20 Server mehr von Hand anpassen ;-).

Welche Erfahrungen haben Sie mit ansible gemacht? Schreiben Sie’s uns in die Kommentare. Wir freuen uns drauf.

 

Weiterführende Infos

Weitere Informationen und Sites zu ansible:

Bücher zu ansible:

VPN-Tunnel mit IPSec

,

Einleitung zu IPsec

Wer als Linux- oder Windows-Administrator in Firmen Netzwerke verwaltet, der muss meistens unterschiedliche Netzwerke miteinander verbinden. Etwa mehrere Außenstellen oder Filialen an eine Zentrale (der Firma) .  Um dies zu eralisieren, kommt heute sehr oft IPSec als Basis für ein VPN (virtual private network) zum Einsatz. In diesem Tutorial im Rahmen unserer Reihe zur Linux-Administration lernen Sie:

  • Wie Verschlüsselung grundsätzlich funktioniert
  • Wie ein Verbindungsaufbau für ein IPSec-VPN  prinzipiell abläuft
  • Wie IPsec auf der Opensource Firewall pfsense implementiert ist.

IPsec (Internet Protocol Security) ist heute ein de-fakto Standard für die Verschlüsselung von Datenverkehr im Internet. IPSec ist auf allen gängigen Betriebssystem-Plattformen sowie in den allermeisten Firewalls vorhanden. IPsec wird heute vor allem zur Koppelung von unterschiedlichen IP-Netzwerken – etwa hinter Firewalls – verwendet.

Hinweis: Für das Verständnis der Implementierung von IPSec auf einer pfsense-Firewall sollten, Sie die Grundlagen der Netzwerk-Technik verstehen und die Basics der pfsense-Firewall verstanden haben. Über beide Themen haben wir hier im Blog der Biteno GmbH ausführliche Tutorials.

Lesetipps dazu:

Technische Komponenten für ein VPN

Damit ein VPN mit IPsec einwandfrei funktioniert, benötigen wir auf der Firewall mehrere Elemente:

  • Eine Hash-Funktion,
  • Eine Schlüsselverwaltung
  • Einen Verschlüsselungsalgorithmus

Hashes / Prüfwerte

Ein Hash-Wert dient zur Berechnung eines eindeutigen Prüfwerts für beliebige digitale Daten (Nachrichten). Hashes sind außerdem  Grundlage zur Erstellung einer digitalen Signatur.

Der Prüfwert wird verwendet, um die Integrität einer Nachricht bzw. einer beliebigen Zeichenkette zu sichern.

Wenn zwei Nachrichten den gleichen Prüfwert ergeben, soll die Gleichheit der Nachrichten nach normalem Ermessen garantiert sein. Darum fordert man von einer kryptologischen Hashfunktion die Eigenschaft der Kollisionssicherheit: es soll praktisch unmöglich sein, zwei verschiedene Nachrichten mit dem gleichen Prüfwert zu erzeugen.

(Quelle: Wikipedia: https://de.wikipedia.org/wiki/Secure_Hash_Algorithm)

Die Eigenschaften eines Hash-Wertes:

  • Jeder Hashwert einer identischen Zeichenkette muss immer denselben Output (=Hashwert) ergeben.
  • Eine Rückrechnung – also ein Knacken des Hashes soll möglichst unmöglich sein

Anwendung für Prüfsummen:

Hashwerte werden immer dann verwendet, um etwa Passwörter zu vergleichen. So werden in modernen Anwendungen nicht die Passwörter gespeichert, sondern deren Hash-Werte.

Nach der Eingabe eines Passworts durch den Anwender wird der Hash-Wert ermittelt und mit dem gespeicherten Hash-Wert verglichen. Sind beide gleich, dann stimmten die Passwörter überein.

MD5

Der Message-Digest Algorithm 5 (MD5) ist eine weit verbreitete kryptographische Hashfunktion, die aus einer beliebigen Nachricht einen 128-Bit-Hashwert erzeugt. Dies erlaubt beispielsweise die leichte Überprüfung eines Downloads auf Korrektheit. Der MD5 wurde 1991 von entwickelt.

Bsp. Zu MD5

1
„Hallo mein Name ist Franz“ -&gt; <strong>53fd70b0411e0822625bbb08cd8d941b</strong>

MD5 Hash-Wert online erstellen: https://www.md5-generator.de/

Der MD5  gilt heute (2017/2018) als Hash-Wert nicht mehr als wirklich sicher, da es mit überschaubarem Aufwand möglich ist, unterschiedliche Nachrichten zu erzeugen, die den gleichen MD5-Hashwert aufweisen.

Dennoch findet sich der MD5 noch immer in vielen Software-Anwendungen bzw. Firewalls.

Weiterführende Informationen: https://de.wikipedia.org/wiki/Message-Digest_Algorithm_5

SHA-1 und Nachfolger

Der Secure Hash Algorithm (SHA bzw SHA-1) wurde 1993 entwickelt und galt bis Ende der 1990er sicher. Die Funktion ermittelt für jede beliebige Zeichenkette einen eineindeutigen Wert

Bsp. Zu SHA-1:

„Hallo mein Name ist Franz“ -> 9dcd46848cbb177296693eaa3de4f59ff603ae5f

Online selbst ausprobieren: http://www.sha1generator.de/

Da der SHA-1 in zwischen 2000 und 2010 mit sehr viel Aufwand mehrfach gebrochen werden konnte, empfiehlt man heute statt SHA-1 die Weiterentwicklungen der SHA-2-Familie (SHA-224, SHA-256, SHA-384, SHA-512) zu verwenden.

Sie unterscheiden sich von SHA-1 dadurch, daß die Berechnung komplexer und die Bitfolgen länger werden.

Bsp. Zu SHA-3

„Hallo mein Name ist Franz“ -> f83a982bbd010930076555a20dcf311c7cc89737736a3f48a0cd3de3001219b3ca18b721ed58ddd63955818da341ca56cfcb033dbc0b945ad03ca9221842b9b0

SHA-3 unterscheidet sich also sowohl von SHA-1 als auch MD5 von der deutlich längeren Zeichenkette.

Online checken: https://emn178.github.io/online-tools/sha3_512.html

Weitere Informationen zu SHA https://de.wikipedia.org/wiki/Secure_Hash_Algorithm

Schlüsselverwaltung

Damit zwei Gesprächspartner (Firewalls) in einem ungesicherten Raum (Internet) sicher miteinander kommunizieren können, müssen Sie sich zunächst gegeneinander mit Schlüsseln absichern.

Manuelle Schlüsselverwaltung

Prinzipiell können alle Schlüssel zwischen zwei Firewalls vorab über einen gesicherten Weg manuell (!) ausgetauscht werden. In der Praxis ist das aber meist nicht praktikabel.

Automatischer Schlüsselaustausch mit IKE

Das Internet-Key-Exchange-Protokoll (IKE) dient der automatischen Schlüsselverwaltung für IPsec. Es verwendet den Diffie-Hellman-Schlüsselaustausch für einen sicheren Austausch von Schlüsseln über ein unsicheres Netzwerk (z.B. Internet).

IKE definiert, wie Sicherheitsparameter vereinbart und gemeinsame Schlüssel (shared keys) ausgetauscht werden.

Beide Gesprächspartner benötigen also für den Aufbau ein gemeinsam und vorher bekanntes „Shared Secret“.

Weitere Informationen zu IKE: https://en.wikipedia.org/wiki/Internet_Key_Exchange

Diffie Hellmann Schlüsselaustausch

Die beiden Namensgeber Whitfield Diffie und Martin Hellman haben im Jahr 1976 den nach Ihnen bekannten Schlüsselaustausch beschrieben, auf dem heute ein Teil des Algorithmus für den Schlüsselaustausch bei IPsec erfolgt.

Im Wesentlichen beschreiben Sie dabei u.a. eine mathematische Einwegfunktion.

https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch

Verschlüsselungs-Algorithmen

Damit zwei Parteien (Menschen oder Firewalls) geheime Informationen sicher austauschen können, benötigen Sie einen gemeinsamen Ablauf (Algorithmus), um damit Nachrichten zu verschlüsseln. Dieser Algorithmus muss auf beiden Seiten eindeutig sein und gleich ablaufen.

DES & 3DES

Der Data Encryption Standard (DES) ist ein weit verbreiteter symmetrischer Verschlüsselungsalgorithmus.  Der DES-Algorithmus wurde als offizieller Standard für die US-Regierung   im Jahr 1977 bestätigt und wird seither international vielfach eingesetzt.  Heute wird DES aufgrund der verwendeten Schlüssellänge von nur 56 Bits für viele Anwendungen als nicht ausreichend sicher erachtet.

Weiterentwicklungen von DES sind 3DES oder Tripple-DES sowie AES (siehe unten)

AES (Rijndael)

Der Advanced Encryption Standard (AES) ist eine Blockchiffre, die als Nachfolger für DES im Oktober 2000 vom National Institute of Standards and Technology (NIST) als Standard bekanntgegeben wurde. Nach seinen Entwicklern Joan Daemen und Vincent Rijmen wird AES auch Rijndael-Algorithmus genannt.

Es handelt sich um ein symmetrisches Verschlüsselungsverfahren, d. h. der Schlüssel zum Ver- und Entschlüsseln ist identisch. Der Rijndael-Algorithmus besitzt variable, voneinander unabhängige Block- und Schlüssellängen von 128, 160, 192, 224 oder 256 Bit. Rijndael bietet ein sehr hohes Maß an Sicherheit; erst mehr als zehn Jahre nach seiner Standardisierung wurde der erste theoretisch interessante, praktisch aber nicht relevante Angriff gefunden.

Blowfish

Blowfish (deutsch Kugelfisch) ist ein symmetrischer Blockverschlüsselungsalgorithmus, der 1993 von Bruce Schneier entworfen und erstmals im April 1994 publiziert wurde. Er wurde als public domain veröffentlicht und kann frei verwendet werden.  Blowfish hat als Blockchiffre eine feste Blocklänge von 64 Bit, basiert auf einem Feistelnetzwerk, welches die Umkehrbarkeit zwischen Verschlüsselung und Entschlüsselung garantiert.

Mehr dazu. https://de.wikipedia.org/wiki/Blowfish

Weitere Begriffe

Encapsulating Security Payload (ESP) stellt Mechanismen zur Sicherstellung der Authentizität, Integrität und Vertraulichkeit der übertragenen IP-Pakete bereit. Im Unterschied zum AH wird der Kopf des IP-Paketes vom ICV (Integrity check value) nicht berücksichtigt, jedoch werden die Nutzdaten verschlüsselt übertragen. ESP basiert direkt auf IP und verwendet die Internet-Protokoll Nummer 50.

Quelle:  https://de.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload_(ESP)

Funktionsweise von IPsec

IPsec (kurz für Internet Protocol Security) ist eine Protokoll-Suite, die eine gesicherte Kommunikation über potentiell unsichere IP-Netze wie etwa das Internet ermöglichen soll.

IPsec arbeitet direkt auf der Internetschicht (Internet Layer) und ist eine Weiterentwicklung der IP-Protokolle. Das Ziel ist es, eine verschlüsselungsbasierte Sicherheit auf Netzwerkebene bereitzustellen.

IPsec bietet durch die verbindungslose Integrität sowie die Zugangskontrolle und Authentifikation der Daten diese Möglichkeit an. Zudem wird durch IPsec die Vertraulichkeit sowie Authentizität der Paketreihenfolge durch Verschlüsselung gewährleistet.

Weitere Informationen zu IPsec:

 

IPsec verwendet zwei Phasen, um eine VPN-Verbindung sicher aufzubauen. Diese heißen Phase 1 und Phase2.

Phase 1 von IPsec

Der erste Teil (Phase 1) eines IPsec ist der technisch komplexere Teil von IPsec. In der echten Welt ist das in etwa so, also würden sich ein Telefonanrufer und ein Angerufener, die sich beide nicht kennen und die nicht wissen ob der andere die eigene Sprache versteht, versuchen zu verständigen.

Die Phase 1 beginnt mit dem so genannten „Main Mode“. Er wird in der ersten Phase der Verschlüsselungsvereinbarung und Authentisierung (Internet Key Exchange) genutzt.

Im Main Mode handeln der Initiator (derjenige, der die Verbindung aufnehmen will) und der Antwortende (der Responder) miteinander eine ISAKMP-SA (kurz für Internet Security Association and Key Management Protocol – Security Association ; mehr: https://de.wikipedia.org/wiki/Internet_Security_Association_and_Key_Management_Protocol   ) aus.

 

Die Verhandlung geschieht in folgenden Schritten:

  1. Der Initiator sendet einen oder mehrere Vorschläge (engl. Proposal) mit Authentisierungs- und Verschlüsselungsalgorithmen.
  2. Der Responder wählt aus der Schnittmenge der angebotenen und der von ihm unterstützten Algorithmen den sichersten aus und sendet das Auswahlergebnis an den Initiator.
  3. Der Initiator sendet seinen öffentlichen Teil vom Diffie-Hellman-Schlüsselaustausch und einen zufälligen Wert (die Nonce).
  4. Der Responder sendet ebenfalls seinen öffentlichen Teil vom Diffie-Hellman-Schlüsselaustausch und einen zufälligen Wert.
    Dieser Wert dient weiter unten zur Authentisierung.

Da nun beide Firewalls (der Responder und der Initiator) die öffentlichen Bestandteile für den Diffie-Hellman-Schlüsselaustausch kennen, wird dieses Verfahren genutzt, um den geheimen Schlüssel zu berechnen.

Dieser wird dann für die Verschlüsselung nach dem vereinbarten Schlüsselverfahren für die folgenden Schritte verwendet. Der berechnete (Diffie-Hellman-)Schlüssel wird auch für die Erzeugung eines weiteren Schlüssels genutzt, der für die Authentifikation verwendet wird.

Der letzte Schritt hier  ist die Authentisierung. Dabei müssen sich beide Beteiligten als zugriffsberechtigt ausweisen. Hierbei kommen zwei unterschiedliche Verfahren zum Einsatz:

  1. die Authentisierung mittels vereinbartem Geheimnis (im englischen Pre-Shared-Keys, PSK) oder
  2. zertifikatsbasiert.

Phase 2 von IPsec

In der zweiten Phase von IKE wird der Quick Mode verwendet (Schutz durch die IKE SA). Die gesamte Kommunikation in Phase 2 erfolgt dabei bereits verschlüsselt.

Wie in der ersten Phase wird zunächst ein Vorschlag (Proposal) gemacht und zusammen mit einem Hashwert übertragen. Später werden die Schlüssel neu berechnet, und es fließen keinerlei Informationen aus den zuvor generierten SAs ein. Dies stellt sicher, dass niemand von den zuvor generierten Schlüsseln auf die neuen schließen kann (Perfect Forward Secrecy). Dies wird erreicht, indem ein zusätzlicher Diffie-Hellman-Austausch stattfindet. Die Geheimnisse zur Schlüsselbildung werden verworfen, sobald der Austausch abgeschlossen ist.

Mehrere „Quick Modes“ können zur gleichen Zeit stattfinden und durch die gleiche IKE SA geschützt sein. Um die verschiedenen Wechsel unterscheiden zu können, wird das Message-ID-Feld des ISAKMP-Headers herangezogen. Der Status eines solchen Austausches wird durch die Cookies identifiziert.

Quelle: https://de.wikipedia.org/wiki/IPsec

 

Implementierung von IPsec in der pfsense Firewall

Die Implementierung von IPsec lehnt sich an den Standard von IPsec mit Phase1 und Phase2 an. Es gibt je eine Maske für die Phase1 von IPsec und eine weitere für die Phase2.

Hinweis: Ein Ipsec-Tunnel kann mehrere Phase2 Einträge pro Verbindung haben. Das ist dort sinnvoll wo etwa mehrere Netze hinter einer Firewall über ein IPSec VPN gleitet werden.

Übersicht der Verbindungen auf der pfsense

Abbildung: Ein Tunnel mit IPsec auf der pfsense mit zwei Netzen und zwei Phase2 Einträgen

In der obigen Abbildung ist ein VPN-Tunnel (1) mit Phase 1 definiert. Dazu gehören zwei unterschiedliche Phase 2 Einträge (2) für jeweils ein Netzwerk.

Übersicht der Verbindungen mit IPSec auf einer pfsense

Übersicht der Verbindungen mit IPSec auf einer pfsense

Zur Übersicht der VPN-Tunnel auf einer pfsense gelangen Sie über

VPN -> IPsec -> Tunnel.

Um einen neuen VPN-Tunnel zu erstellen klicken Sie unten in der Übersicht auf „Add P1“. Sie beginnen anschließend mit den Einstellungen zu Phase1 von IPsec für ihren neuen Tunnel.

Einstellung von Phase 1 auf der pfsense

Die Einstellungen für die Phase 1 im Detail:

Einstellungen der Phase einer IPSec Verbindung

Einstellungen der Phase einer IPSec Verbindung

Als Authentication Method für die Phase 1 wählen Sie unter (1) entweder „Mutual PSK“ (PSK -> Preshared Key ) oder ein Zertifikat. In der Praxis ist das meistens ein PSK.

Unter (2) wählen Sie den Negatiation Mode. Das ist meistens „Main“. Die seltener verwendete Alternative heißt „Aggressive“.

Sofern Sie bei (1) „Mutual PSK“ gewählt haben, tragen Sie bei (3) ihren geheimen Schlüssel ein. Diesen Schlüssel müssen Sie exakt identisch auf der entfernten Firewall hinterlegen. Außerdem müssen sie sicherstellen, daß dieser Schlüssel niemals in falsche Hände gelangt

Tipp:

Unter https://www.gaijin.at/olspwgen.php können Sie online ein sicheres Passwort wählen. Nutzen Sie dort bitte die Einstellung mit min. 16 Zeichen oder länger.

Im zweiten Abschnitt wählen Sie unter (4) den eigentlichen Verschlüsselungs-Algorithmus (engl. Encryption Algorithm) aus. Dies wird in der Regel AES oder 3DES sein. Sofern Sie AES auswählen, müssen Sie (rechts daneben) die richtige Bit-Länge des Schlüssels auswählen. Auch diese muss auf der entfernten Firewall identisch sein.

Unter (5) wählen Sie den Hash-Algorithmus aus. Dies sollte SHA-1 oder höher (z.B. SHA-256 oder SHA-512) sein.

In der Auswahl bei (6) wählen Sie nun noch die für Sie passende Diffie-Hellman-Gruppe aus (also den Algorithmus für den Schlüsselaustausch).

Ebenso wichtig: Die Ablaufzeit (Lifetime) für die Phase 1 in Sekunden. Nach Ablauf dieser Zeitspanne verhandeln beide Firewalls wieder neu. Auch dieser Wert muss auf beiden Firewalls identisch sein.

Die Auswahl für die DH-Group unter (6) ist relativ groß. Je höher die Gruppe, desto höher die Bitlänge und damit die Stärke der Verschlüsselung. Beginnen Sie im Zweifel eher mit einer niedrigeren Schlüssellänge, bis Sie auf beiden Seiten eine stabile Verbindung haben. Danach können Sie (gemeinsam mit der Gegenstelle) die Schlüssellänge erhöhen.

Abbildung: Diffie Hellmann Gruppen auf der pfsense

Die diffie-hellmann-group Einstellungen in der Phase1 der IPSec VPN Verbindung

Die diffie-hellmann-group Einstellungen in der Phase1 der IPSec VPN Verbindung

 

 

Einstellung von Phase 2 auf der pfsense

In Phase 2 werden zwei wesentliche Einstellungen gemacht:

  • Die Definitionen der unterschiedlichen Netzwerke, die übertragen werden sollen.
  • Der Verschlüsselungs- und Sicherungsmechanismus

 

Phase 2: Netzwerk-Einstellungen

Phase2 IPsec Einstellungen auf der pfsense

Phase2 IPsec Einstellungen auf der pfsense

Unter „Mode“ (1) stellen Sie zunächst ein, on IPV4 oder IPv6 übertragen werden soll.

Unter (2) wählen Sie welches ihrer lokalen Netzwerke auf ihrer Seite des VPN später erreichbar sein wird.

Unter (3) legen Sie das entfernte Netzwerk bzw. eine Adresse fest. Sofern Sie bei (3) ein Netzwerk gewälht haben, definieren Sie bei (4) die Netz-Adresse sowie die Netzmaske.

Hinweis: Sofern Sie mehrere Netzwerke über ein VPN mit einer pfsense übertragen möchten, so müssen Sie mehrere Phase-2 Einträge für ein IPsec Tunnel erstellen. (wohl aber nur einen Eintrag für die Phase1)

 

Phase 2: Verschlüsselungs-Einstellungen

Im unteren Teil der Phase 2 finden Sie alle Einstellungen zum Schlüsselaustausch der Phase 2 sowie die Verschlüsselungs-Algorithmen:

Phase2 bei IPSec auf der pfsense: Verschlüsselungs-Einstellungen

Phase2 bei IPSec auf der pfsense: Verschlüsselungs-Einstellungen

Unter (1) wählen Sie entweder ESP (siehe Einleitung) oder AH (steht für Authentication Header). Am häufigsten wird ESP verwendet.

Unter (2) werden nun die zur Auswahl stehenden Verschlüsselungs-Mechanismen angewählt. Wichtig ist hier: Sie geben der Firewall eine Liste bzw. Auswahl mit. Mit dieser Liste verhandeln die beiden betroffenen Firewalls den passenden Verschlüsselungsmechanismus und dessen Schlüssellänge.

In der Praxis sollten Sie hier mit einem (in Worten: eins) Wert zur Auswahl beginnen, der bei beiden betroffenen Firewalls enthalten ist.

Unter (3) wählen Sie einen Hash-Algorithmus aus, der in Phase 2 zum Einsatz kommt. Vermeiden Sie dabei möglichst MD5. Besser ist ein (hoher) SHA-Algorithmus.

Bei (5) erhalten Sie die Auswahl für die Perfect Forward Secrecy. Das ist nichts anderes als der Schlüsselaustausch-Mechanismus. Sie haben im Wesentlichen die gleiche Auswahl wie bei der Diffie-Hellmann-Gruppe in Phase 1.

Wenn Sie auf Nummer sicher gehen wollen, wählen Sie hier wieder dieselbe Gruppe wie die DH-Group in Phase 1.

Unter (6) legen Sie wieder eine maximale Lebensdauer der verhandelten Schlüssel fest. Dieser Wert muss ebenfalls bei beiden Firewalls identisch sein. Nach Ablauf dieser Zeit in Sekunden fangen die Firewalls wieder neu an zu verhandeln.

Empfehlung für die Praxis:

IPsec VPN-Tunnel funktionieren in der Regel nur dann dauerhaft und vor allem stabil, wenn Sie auf beiden Seiten

  • Für die Einstellungen der relevanten Parameter die gleichen Werte verwenden
  • Kompatible Geräte auf beiden Seiten haben.

Kritik an IPsec

In ihrer Untersuchung über Ipsec von 1999 schrieben Niels Ferguson und Bruce Schneier “IPsec was a great disappointment to us. Given the quality of the people that worked on it and the time that was spent on it, we expected a much better result. We are not alone in this opinion; (…) Even with all the serious critisisms that we have on IPsec, it is probably the best IP security protocol available at the moment.”

An dieser Einschätzung hat sich vermutlich in den vergangenen Jahrzehnten wenig geändert. IPsec ist weiterhin ein sehr komplexer Mechanismus. Er ist aber offenbar selbst fast 20 Jahre nach dieser Kritik immer noch der de-facto Standard, der durch fast alle Hersteller von Security Software  und Hardware durchgängig unterstützt wird.

Verwendete Begriffe

AES: Symmetrischer Verschlüsselungs-Mechanismus mit variabler Bitlänge

DES / 3DES: Symmetrischer Verschlüsselungs-Mechanismus

IKE: Internet Key Exchange – Schlüsselaustausch über ein unsicheres Netz

MD5: Hash-Funktion, die mittlerweile als unsicher gilt

PFS: Perfect Forward Secrecy https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy

SHA: Hash-Funktion, die mit unterschiedlicher Schlüssellänge eindeutige Hash-Werte erzeugt.

Shared Secret: Ein nur zwei Parteien bekannte, geheime Zeichenfolge.