Seit Firefox 127 kann man sich das Wetter auf der Startseite anzeigen lassen. Startet euren Firefox, gebt in der Adresszeile about:config ein und bestätigt die Warnung. Sucht nach browser.newtabpage.activity-stream.system.showWeather und stellt den Wert mit...
Liebe Leser*innen,
heute seid ihr gefragt. Denn ich möchte von euch wissen, welchen Laptop und welche Linux-Distribution, ihr für ältere, nicht EDV-affine Menschen und Windows-Umsteiger empfehlen könnt.
Der Laptop soll über folgende Merkmale verfügen:
Die Unterstützung von Linux und Windows ist sehr wichtig. Sollte der Feldversuch mit Linux scheitern, möchte auf der gleichen Hardware ein aktuelles Windows-Betriebssystem installieren können.
Mir schwebt etwas in der Richtung der Lenovo IdeaPad oder ein ThinkPad der L-Serie vor, ich bin jedoch auf eure Empfehlungen gespannt.
Ich suche nach einer Desktop-Umgebung, die folgende Merkmale bietet:
Dies sind Muss-Kriterien, die unbedingt erfüllt sein müssen. Ich möchte, dass die Desktopoberfläche diese Eigenschaften in der Standardkonfiguration erfüllt und ich diese nicht erst konfigurieren oder drölfzig Plug-ins installieren muss, um diesen Zustand zu erreichen.
Die wichtigsten Anwendungen sind:
Die Linux-Distribution muss die oben genannten Anforderungen an die Desktop-Umgebung und die Software erfüllen und dabei stabil allerdings nicht steinalt sein.
Ich möchte nicht vor jeder Videokonferenz mit den Audio-Einstellungen kämpfen müssen, um deutlich zu machen, wo meine Priorität liegt.
Kandidaten, die ich mir ansehen möchte, sind:
Was könnt ihr mir empfehlen? Bitte nutzt die Kommentare und verlinkt, wo möglich zu den Projekten, die ihr empfehlt.
Wer ein GitHub Account hat, kann sich sehr einfach über neue Releases (Veröffentlichungen) von Projekten per E-Mail informieren lassen. Es benutzen aber nicht alle Projekte das „Releases“ Feature, sondern setzen stattdessen auf Git Tags....
Dies ist mein Erfahrungsbericht der Chemnitzer Linux-Tage 2024. Es war mal wieder eine sehr schöne Veranstaltung.
Im vergangenen Jahr hatte mich die Deutsche Bahn in Chemnitz sitzengelassen und ich musste mit einem kurzfristig angemieteten Leihwagen heimfahren.
Da die Deutsche Bahn und die Gewerkschaft Deutscher Lokomotivführer sich noch immer nicht auf einen neuen Tarifvertrag einigen können und ich mich nicht erneut über eine schlechte Verbindung ärgern wollte, bin ich dieses Jahr mit dem eigenen Pkw gefahren.
Am Freitag um 13:30 Uhr ging die Reise los. Mit viel Verkehr, Baustellen und Stau waren ich etwa 4,5 Stunden später im Hotel, wo ich direkt über Stoeps gestolpert bin.
Wir spazierten vom Residenz Hotel Chemnitz zum Veranstaltungsgebäude, um uns anzumelden und unsere Badges zu empfangen. Damit ersparten wir uns das Warten in der Schlange am Samstagmorgen.
Am Hörsaalgebäude traf ich schon erste vertraute Gesichter, wie z.B. Andreas, welcher fleißig beim Aufbau geholfen hat. Hier haben wir uns auch mit Michael von der Aspicon GmbH getroffen, mit dem ich für Sonntag einen Vortrag geplant hatte. Wir sind gemeinsam in die Stadt gegangen, um uns bei Speis und Trank kennenzulernen und den Abend zu verplaudern.
Um 07:00 Uhr begann ich den Tag mit dem Frühstück. So war der erste Hunger bereits gestillt, als der Frühstücksraum sich zu füllen begann. Bekannte Gesichter und nerdige T-Shirts verrieten, dass es sich bei sehr vielen der Gäste um Besucher der Chemnitzer Linux-Tage handelte.
Die 20 Minuten zum Veranstaltungsort wurden auch diesmal wieder zu Fuß zurückgelegt. Und der erste Konferenztag konnte beginnen.
Um 10:00 Uhr war ich an der Reihe und durfte in einem rappelvollen Raum V6 meinen „::1“-Vortrag halten. An dieser Stelle euch allen nochmal vielen Dank für eure Teilnahme. Ich hoffe, ihr hattet so viel Spaß wie ich und konntet ein paar neue Eindrücke gewinnen.
Es hat mich gefreut, auch nach dem Vortrag noch einige Fragen beantworten zu können und über IPv6 zu fachsimpeln. Ganz nebenbei konnte ich auch noch die Frage eines Red Hat-Kunden beantworten. Darüber freute sich dieser sehr, bleibt ihm der Support eine zufriedenstellende Antwort doch seit langer Zeit schuldig. Es ist halt stets eine gute Erfahrung, einen TAM zu treffen.
Die Chemnitzer Linux-Tage gibt es übrigens schon seit 25 Jahren. Da eine Veranstaltung aufgrund der Pandemie ausfallen musste, findet die 25. Veranstaltung allerdings erst im nächsten Jahr am 22. und 23. März statt.
20-jähriges Jubiläum feiert in diesem Jahr Ubuntu, weshalb der Community-Stand dieses Jahr besonders schön geschmückt war und toddy mehrfach mit Luftschlangen gefesselt wurde.
Ich genieße die Zeit unter gleichgesinnten Nerds oder wie Stoeps es ausdrückte: „Endlich wieder unter normalen Menschen“. Mich hat es dieses Jahr sehr gefreut, auch viele jüngere Gesichter zu sehen. So sehr ich mich freue, auch die gleichen alten Nasen immer wiederzutreffen ist es doch schön, dass die Gemeinschaft nicht einfach alt wird, sondern auch junge Menschen mit Interesse, Motivation und Freude an Open Source nachwachsen.
Da die Hörsäle hier bei den Vorträgen meist aus allen Nähten platzen, hatte ich mich im Vorfeld als Sessionleitung für die drei Vorträge
gemeldet. So war mir ein guter Platz im Raum sicher. Ich danke den drei Referenten für ihre interessanten Vorträge.
Am Abend waren alle Aussteller, Helfer und Referenten zum gemütlichen Beisammensein in die Mensa eingeladen, welche schräg gegenüber dem Veranstaltungsgebäude liegt. Hier gab es ein reichhaltiges Angebot an warmem und kaltem Essen sowie eine Auswahl verschiedenster Getränke. Vielleicht ist es in der Zukunft möglich, die Getränke zu kühlen. Dann wird das Bier nicht so schnell warm und schmeckt länger gut.
Ich schätze es sehr, mich auf Konferenzen mit alten und neuen Bekannten auszutauschen, zu fachsimpeln und ganz allgemein angeregte Gespräche zu führen. Das musikalische Rahmenprogramm traf auch in diesem Jahr nicht meinen Geschmack. Ich würde mir etwas Hintergrundberieselung wünschen, um sich gut unterhalten zu können. Doch sind Geschmäcker verschieden und ich erkenne durchaus an, was das Organisations-Team der Chemnitzer Linux-Tage hier Jahr für Jahr auf die Beine stellt. Euch allen vielen Dank für euren unermüdlichen Einsatz.
Nach einem frühen Frühstück und Check-out ging es heute mit dem Auto zum Veranstaltungsgelände. Noch vor dem zweiten Kaffee wurden hier die Folien für den nächsten Vortrag nochmal geprüft. Um 10:00 Uhr war es wieder soweit. Diesmal durfte ich zusammen mit Michael den Vortrag „Mit Ansible Collections & Workflows gegen das Playbook-Chaos“ halten.
@Michael: „Es hat mir gut gefallen, mit dir einen Vortrag zu halten. Das können wir gerne wiederholen.“
Beim Mittagessen habe ich dann auch noch Christian getroffen. Für ihn waren es die ersten Chemnitzer Linux-Tage und auch ihm haben sie sehr gut gefallen.
Und wie immer war die Zeit auch viel zu schnell wieder vorbei. So habe ich Henning zwar kurz gesehen, doch für mehr als ein kurzes „Hi und Tschüss, bis zum nächsten Mal“ reichte es diesmal leider nicht.
Auch die schönsten Chemnitzer Linux-Tage gehen vorbei. Doch im Auto sitzend freute ich mich auch schon darauf, meine Familie wiederzusehen. Die Straße war frei und nach nur 3 Stunden 20 Minuten war ich wieder daheim. Zum Vergleich, mit der Bahn wäre ich je nach Verbindung erst nach 5,5-6,5 Stunden daheim gewesen, wenn alles nach Plan fährt.
So konnte ich mehr Zeit vor Ort verbringen und war rechtzeitig daheim, um noch etwas Zeit mit meinem Sohn zu verbringen, bevor dieser ins Bett ging.
Es war schön. Ich hoffe, ihr seid alle wieder gut heimgekommen und behaltet auch diese Chemnitzer Linux-Tage in guter Erinnerung.
Mit einem Dualstack-Proxy Internet-Protokolle verbinden beschrieb eine Möglichkeit, um von Hosts, welche ausschließlich über IPv6-Adressen verfügen, auf Ziele zugreifen zu können, die ausschließlich über IPv4-Adressen verfügen. In diesem Beitrag betrachte ich die andere Richtung.
Zu diesem Beitrag motiviert hat mich der Kommentar von Matthias. Er schreibt, dass er für den bei einem Cloud-Provider gehosteten Jenkins Build Server IPv4 deaktivieren wollte, um Kosten zu sparen. Dies war jedoch nicht möglich, da Kollegen aus einem Co-Workingspace nur mit IPv4 angebunden sind und den Zugriff verloren hätten.
Doch wie kann man nun ein IPv6-Netzwerk für ausschließlich IPv4-fähige Clients erreichbar machen, ohne für jeden Host eine IPv4-Adresse zu buchen? Dazu möchte ich euch anhand eines einfachen Beispiels eine mögliche Lösung präsentieren.
Um diesem Text folgen zu können, ist ein grundsätzliches Verständnis von DNS, dessen Resource Records (RR) und des HTTP-Host-Header-Felds erforderlich. Die Kenntnis der verlinkten Wikipedia-Artikel sollte hierfür ausreichend sein.
Zu diesem Proof of Concept gehören:
Ich habe mich für HAProxy als Reverse-Proxy-Server entschieden, da dieser in allen Linux- und BSD-Distributionen verfügbar sein sollte und mir die HAProxy Maps gefallen, welche ich hier ebenfalls vorstellen möchte.
Der Versuchsaufbau kann wie folgt skizziert werden:
Für dieses Minimal-Beispiel besteht die HAProxy-Konfiguration aus zwei Dateien, der HAProxy Map hosts.map und der Konfigurationsdatei poc.cfg.
Anmelden
~]$ cat /etc/haproxy/conf.d/hosts.map
www1.example.com serversa
www2.example.com serversbEine HAProxy Map besteht aus zwei Spalten. In der ersten Spalte stehen die FQDNs, welche vom HTTP-Client aufgerufen werden können. In der zweiten Spalte steht der Name des Backends aus der HAProxy-Konfiguration, welcher bestimmt, an welche Backend-Server eine eingehende Anfrage weitergeleitet wird. In obigem Beispiel werden Anfragen nach www1.example.com an das Backend serversa und Anfragen nach www2.example.com an das Backend serversb weitergeleitet.
Die HAProxy Maps lassen sich unabhängig von der HAProxy-Konfigurations-Datei pflegen und bereitstellen. Map-Dateien werden in ein Elastic Binary Tree-Format geladen, so dass ein Wert aus einer Map-Datei mit Millionen von Elementen ohne spürbare Leistungseinbußen nachgeschlagen werden kann.
Die HAProxy-Konfigurations-Datei poc.cfg für dieses Minimal-Beispiel ist ähnlich simpel:
~]$ cat /etc/haproxy/conf.d/poc.cfg
frontend fe_main
bind :80
use_backend %[req.hdr(host),lower,map(/etc/haproxy/conf.d/hosts.map)]
backend serversa
server server1 2001:DB8::1:80
backend serversb
server server1 2001:DB8::2:80In der ersten Zeile wird ein Frontend mit Namen fe_main definiert. Zeile 2 bindet Port 80 für den entsprechenden Prozess und Zeile 3 bestimmt, welches Backend für eingehende HTTP-Anfragen zu nutzen ist. Dazu wird der HTTP-Host-Header ausgewertet, falls notwendig, in Kleinbuchstaben umgewandelt. Mithilfe der Datei hosts.map wird nun ermittelt, welches Backend zu verwenden ist.
Die weiteren Zeilen definieren zwei Backends bestehend aus jeweils einem Server, welcher auf Port 80 Anfragen entgegennimmt. In diesem Beispiel sind nur Server mit IPv6-Adressen eingetragen. IPv4-Adressen sind selbstverständlich auch zulässig und beide Versionen können in einem Backend auch gemischt auftreten.
Kann eine HTTP-Anfrage nicht über die hosts.map aufgelöst werden, läuft die Anfrage in diesem Beispiel in einen Fehler. Für diesen Fall kann ein Standard-Backend definiert werden. Siehe hierzu den englischsprachigen Artikel Introduction to HAProxy Maps von Chad Lavoie.
Von einem IPv4-Client aus benutze ich curl, um die Seite www1.example.com abzurufen:
~]$ curl -4 -v http://www1.example.com
* processing: http://www1.example.com
* Trying 203.0.113.1:80...
* Connected to www1.example.com (203.0.113.1) port 80
> GET / HTTP/1.1
> Host: www1.example.com
> User-Agent: curl/8.2.1
> Accept: */*
>
< HTTP/1.1 200 OK
< server: nginx/1.20.1
< date: Sat, 06 Jan 2024 18:44:22 GMT
< content-type: text/html
< content-length: 5909
< last-modified: Mon, 09 Aug 2021 11:43:42 GMT
< etag: "611114ee-1715"
< accept-ranges: bytes
<
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Test Page for the HTTP Server on Red Hat Enterprise Linux</title>Der FQDN www1.example.com wird mit der IPv4-Adresse 203.0.113.1 aufgelöst, welche dem Host haproxy.example.com gehört. Bei der Zeile Host: www1.example.com handelt es sich um den HTTP-Host-Header, welchen der HAProxy benötigt, um das richtige Backend auszuwählen.
Es ist zu sehen, dass wir eine Antwort von einem NGINX-HTTP-Server erhalten. Der HTML-Quelltext wurde gekürzt.
Damit ist es gelungen, von einem IPv4-Client eine Ressource abzurufen, die von einem IPv6-Server bereitgestellt wird.
Im Access-Log des Backend-Servers mit der IPv6-Adresse 2001:DB8::2 sieht man:
2001:DB8::1 - - [06/Jan/2024:19:44:22 +0100] "GET / HTTP/1.1" 200 5909 "-" "curl/8.2.1" "192.0.2.1"Die Anfrage erreicht den Backend-Server von der IPv6-Adresse des haproxy.example.com (2001:DB8::1). Die am Ende der Zeile zu sehende IPv4-Adresse (192.0.2.1) gehört dem IPv4-Client, von dem ich die Anfrage gesendet habe.
In diesem Beispiel sind die Server www1.example.com und www2.example.com über ihre IPv6-Adressen direkt erreichbar. Nur die Client-Anfragen von IPv4-Clients laufen über den Reverse-Proxy. Wenn man es wünscht, kann man selbstverständlich sämtliche Anfragen (von IPv4- und IPv6-Clients) über den Reverse-Proxy laufen lassen.
In kleinen Umgebungen kann man einen Reverse-Proxy wie HAProxy zusammen mit Squid (vgl. Artikel Mit einem Dualstack-Proxy Internet-Protokolle verbinden) auf einem Host laufen lassen. Selbstverständlich kann man sie auch auf separate Hosts verteilen.
Hochverfügbarkeit lässt sich auch hier mit keepalived nachrüsten:
Die Internet-Protokolle IPv4 und IPv6 werden wohl noch eine ganze Zeit gemeinsam das Internet bestimmen und parallel existieren. Ich bin mir sogar sicher, dass ich das Ende von IPv4 nicht mehr miterleben werde. Dualstack-(Reverse)-Proxy-Server stellen eine solide und robuste Lösung dar, um beide Welten miteinander zu verbinden.
Sicher bleiben noch ausreichend Herausforderungen übrig. Ich denke da nur an Firewalls, Loadbalancer, NAT und Routing. Und es werden sich auch Fälle finden lassen, in denen Proxyserver nicht infrage kommen. Doch mit diesen Herausforderungen beschäftige ich mich dann in anderen Artikeln.
In drei Wochen beginnen die Chemnitzer Linux-Tage 2024 mit dem diesjährigen Motto „Zeichen setzen“. Am 16. und 17. März erwartet euch im Hörsaalgebäude an der Richenhainer Straße 90 ein vielfältiges Programm an Vorträgen und Workshops. Hier finden sich Vorträge für interessierte Neueinsteiger wie für alte Hasen.
So geht es am Samstag im Einsteigerforum beispielsweise um die Digitalisierung analoger Fotos, das Erstellen von Urlaubsvideos mit der Software OpenShot oder die Verschlüsselung von E-Mails. In der Rubrik „Schule“ gibt Arto Teräs einen Einblick in den Einsatz der Open-Source-Lösung Puavo an finnischen und deutschen Schulen. Zusätzlich stehen Vorträge aus den Bereichen Finanzen, Medien, Datensicherheit, KI oder Netzwerk auf dem Programm. Am Sonntag gibt das Organisationsteam der Chemnitzer Linux-Tage mit „make CLT“ Einblicke in die Planung und Strukturen der Veranstaltung selbst. In der Rubrik „Soft Skills” wird es um die Schätzung von Aufwänden oder notwendige Fähigkeiten von Software-Entwicklern gehen.
Eintrittskarten können online im Vorverkauf und an der Tageskasse erworben werden. Kinder bis 12 Jahren haben freien Eintritt.
Während viele Besucher bereits Stammgäste sind, werden auch neue Gesichter herzlich willkommen. Lasst euch gern von der hier herrschenden Atmosphäre voller Begeisterung für freie Software und Technik anstecken und begeistern.
Ich selbst freue mich, am Samstag um 10:00 Uhr in V6 den Vortrag mit dem obskuren Namen ::1 beisteuern zu dürfen. Update: Unverhofft kommt oft. Uns so freue ich mich am Sonntag um 10:00 Uhr in Raum V7 noch in einem zweiten Vortrag vertreten zu sein. Zusammen mit Michael Decker von der ASPICON GmbH erfahrt ihr, wie man „Mit Ansible Collections & Workflows gegen das Playbook-Chaos“ angehen kann.
Darüber hinaus beteilige ich mich als Sessionleiter für die folgenden drei Vorträge an der Veranstaltung:
So habe ich auf jeden Fall einen Platz im Raum sicher. ;-)
Wer ebenfalls helfen möchte, kann sich unter Mitmachen! informieren und melden.
Für mich ist dieses Jahr einiges im Programm dabei. Doch freue ich mich ebenso sehr auf ein Wiedersehen mit alten Bekannten aus der Gemeinschaft und darauf, neue Gesichter (Namen kann ich mir meist erst Jahre später merken) kennenzulernen.
Also bis bald in der Karl-Marx-Stadt.
Am 16. und 17. März 2024 werde ich euch auf den Chemnitzer Linux-Tagen um 10:00 Uhr in Raum V6 mit einem Vortrag über IPv6 unterhalten.
Dazu bin ich noch auf der Suche nach ein paar Beispielen aus dem echten Leben. Falls ihr mögt, teilt mir doch eure schönsten und schlimmsten Momente im Zusammenhang mit IPv6 mit und ich prüfe, ob ich sie in meinen Vortrag mit einbauen kann.
Ich freue mich über Einsendungen, Beiträge und Rückmeldungen:
Bitte schreibt dazu, ob ihr eine Namensnennung wünscht oder euer Beispiel anonym einfließen soll.
Um einen runden Vortrag zu erstellen, wird evtl. nicht jeder Beitrag einfließen können. Bitte habt Verständnis dafür und verzeiht, wenn ihr euch nicht im Vortrag wiederfindet. Ich werde eure Geschichten ggf. im Nachgang hier im Blog veröffentlichen.
Bis neulich in Chemnitz. :-)
Stellt euch vor, ihr habt eine Menge von Servern, welche ausschließlich über IPv6-Adressen verfügen und deshalb keine Dienste nutzen können, welche nur über IPv4 bereitgestellt werden. Wer sich dies nicht vorstellen mag, findet in „IPv6… Kein Anschluss unter dieser Nummer“ ein paar Beispiele dafür.
Was kann man nun tun, damit diese IPv6-only-Hosts dennoch mit der IPv4-only-Welt kommunizieren können?
Eine mögliche Lösung ist die Nutzung eines Dualstack-Proxy-Servers. Das ist ein Server, welcher über Adressen beider Internet-Protokoll-Versionen verfügt und so stellvertretend für einen IPv6-Host mit einem IPv4-Host kommunizieren kann. Das folgende Bild veranschaulicht den Kommunikationsablauf:
Im Bild ist zu sehen:
Das obige Video demonstriert die Nutzung eines Proxy-Servers durch den Abruf einer Demo-Seite mit curl:
host-Kommando wird gezeigt, dass für die Demo-Seite kein AAAA-Record existiert; die Seite ist also nicht via IPv6 erreichbarip-Kommando wird geprüft, dass der Host auf dem Interface ens18 ausschließlich über IPv6-Adressen verfügtJa. Entscheidend ist, dass der verwendete Proxy beide IP-Versionen unterstützt.
Der Proxy-Server muss beide IP-Versionen beherrschen. Ich persönlich bevorzuge Squid. Dieser ist in so gut wie allen Linux-Distributionen verfügbar, weit verbreitet, robust und selbstverständlich Freie Software.
Für eine Virtualisierungs-Umgebung mit einer IPv4-Adresse und einem /64-IPv6-Netzsegment funktioniert diese Lösung gut. Sie funktioniert auch in jeder anderen Umgebung, wie gezeigt. Man beachte jedoch, dass man mit nur einem Proxy einen Single-Point-of-Failure hat. Um diesem zu begegnen, kann man Squid mit keepalived hochverfügbar gestalten.
Keepalived ist ebenfalls Freie Software. Sie kostet kein Geld, erhöht jedoch die Komplexität der Umgebung. Verfügbarkeit vs. Komplexität möge jeder Sysadmin selbst gegeneinander abwägen.
Das Stichwort lautet Reverse-Proxy. Ein Artikel dazu erscheint in Kürze in diesem Blog. ;-)
Das Jahr 2024 ist nun schon zwei Wochen alt. Dennoch möchte ich noch einen Blick zurückwerfen und mich erinnern, wie das Jahr 2023 für meinen Blog verlaufen ist.
In 2023 wurden auf My-IT-Brain insgesamt 45 Artikel veröffentlicht. Dies sind 16 mehr als in 2022 und 14 mehr als in 2021. Jeden Monat sind mindestens zwei Artikel veröffentlicht worden.
Die Themen waren dabei wieder bunt gemischt. Allein Artikel über die Red Hat Enterprise Linux (RHEL) System Roles zogen sich wie ein roter Faden durch den Blog. Welche Artikel haben denn euch am besten gefallen? Lasst es mich gerne in den Kommentaren wissen.
Ich hoffe, es war für jeden von euch etwas Interessantes mit dabei und ihr folgt diesem Blog auch in 2024. Ihr könnt mir auch gerne Anregungen in die Kommentare schreiben, welche Themen ihr hier gerne behandelt sehen wollt. Vielleicht greife ich ja einige davon auf.
Und nun aber auf in ein spannendes Jahr 2024!
Das Jahr 2023 neigt sich langsam dem Ende zu. In diesem Monat for 25 Jahren wurde das IPv6-Protokoll in RFC 2460 beschrieben, bevor es 2017 in RFC 8200 als Internet-Standard von der Internet Engineering Task Force (IETF) veröffentlicht wurde.
Seit immerhin sechs Jahren ist dieses IP-Protokoll also schon standardisiert. Da sollte man doch meinen, dass man im Jahr 2023 problemlos ein vernetztes System betreiben kann, welches nur mit einer IPv6-Adresse mit dem Internet verbunden ist. Leider ist dem nicht so.
In den folgenden kurzen Abschnitten schreibe ich mir meinen Frust von der Seele und dokumentiere, was heute alles mit IPv6 noch nicht geht. Falls ihr weitere Fälle ergänzen möchtet, nutzt gerne die Kommentare, um eurem IPv6-Frust Luft zu machen.
Bei der Planung einer Red Hat Satellite 6.14 Installation bin ich über folgenden Satz in der Dokumentation gestolpert:
You can install Satellite and Capsules in IPv6-only systems, dual-stack installation is not supported.
URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html/installing_satellite_server_in_a_connected_network_environment/preparing-environment-for-installation-in-ipv6-network_satellite
Das ist schade. Betreibt man Server in IPv4- und IPv6-Netzwerken und möchte eine vollständig unterstützte Lösung, muss man aktuell zwei Satellite installieren.
Ich wollte jedoch einen Satellite in einer reinen IPv6-Umgebung installieren, daher sollte mich diese Anmerkung nicht weiter stören. Da störten mich folgende Stellen im gleichen Kapitel der Dokumentation schon mehr:
You must deploy an external IPv4 HTTP proxy server. This is required because Red Hat Content Delivery Network distributes content only over IPv4 networks, therefore you must use this proxy to pull content into the Satellite on your IPv6 network.
You must configure Satellite to use this IPv4 HTTP proxy server as the default proxy. For more information, see Adding a Default HTTP Proxy to Satellite.
URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html/installing_satellite_server_in_a_connected_network_environment/preparing-environment-for-installation-in-ipv6-network_satellite#requirements-for-installation-in-an-ipv6-network_satellite
Zuerst wollte ich dies nicht glauben, habe einen Fehler in der Dokumentation vermutet. Es ist 2023 und Content Delivery Network (CDN) von Red Hat unterstützt kein IPv6? Das kann doch nicht sein! Kann es doch:
Der zweite Link in obiger Liste führt ausschließlich IPv4-Adressen auf. Einzelne Kommentare lassen darauf schließen, dass es jedoch durchaus Interesse an IPv6-Konnektivität gibt. Also installiere ich erstmal einen Proxy-Server mit Dual-Stack, damit ich Hosts aus einem reinen IPv6-Netzwerk via subscription-manager register beim Red Hat Subscription Management (RHSM) registrieren kann.
Nachzulesen in:
Die gute Nachricht, es sind gefixte Versionen für RHEL 9 und RHEL 8 in Aussicht. Auf einen Fix für RHEL 7 würde ich nicht warten und diese Systeme lieber migrieren oder aktualisieren, ist das Support-Ende doch bereits nah.
Also lege ich mein Vorhaben erstmal beiseite und wende mich anderen Wochenendprojekten zu, die vielleicht mehr Erfolg versprechen.
Nun guck an, da ist mein Kollege Andreas also schon im Jahr 2022 in den Ansible-Issue #77308 gelaufen. Ihr interessiert euch für den aktuellen Stand dieser Geschichte? Siehe:
So langsam komme ich mir vor wie ein bekannter spanischer Junker, welcher gegen Windmühlen pardon Riesen anritt. Aber es ist ja nicht so, dass mir die Themen ausgehen. Klone ich mir halt ein Repo von Github und trage ein bisschen zu Open Source bei…
Ich spare mir viele Worte und präsentiere nur folgenden Code-Block:
$ host -t AAAA github.com
github.com has no AAAA recordURL zur Diskussion: https://github.com/orgs/community/discussions/10539
Auch hier kein Anschluss unter dieser Nummer.
Ich möchte meine jüngsten Erfahrungen umschreiben mit: „An manchen Tagen hat man kein Glück und an anderen kommt auch noch Pech dazu.“
Für Red Hat möchte ich sagen, ist es ein Priorisierungs-Thema. Wenn der Wunsch nach IPv6 auf Kundenseite hinreichend groß wird, wird man hier handeln. Bei Github wird es ähnlich sein. Ich muss vielleicht nur nochmal 25 Jahre warten.
In diesem Artikel stelle ich euch die RHEL System Role nbde_client vor, mit welcher sich Hosts für Network Bound Disk Encryption (NBDE) installieren lassen. Er ist Bestandteil einer losen Serie, in der ich eine Reihe von System Roles vorstelle, mit denen häufig anfallende Aufgaben in der Systemadministration erledigt werden können.
Wer sich zuerst über die genannten Begriffe informieren möchte, lese:
Für das folgende Beispiel verwende ich eine Umgebung, bestehend aus:
ansible-corerhel-system-roles/dev/sdc in den Beispielen in diesem Text)Die Installation von RHEL sowie der genannten Pakete sind nicht Bestandteil dieses Artikels. Wer hierzu einen Einstieg sucht, findet entsprechende Dokumentation unter:
Durch die Installation des Pakets rhel-system-roles existiert diese Rolle bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.nbde_client/ und die Dokumentation in /usr/share/doc/rhel-system-roles/nbde_client/README.md. Letztere enthält verschiedene Beispiele für häufige Anwendungsfälle.
In meinem Labor betreibe ich zwei NBDE-Server (TANG-Server) rhel-hetz-tang1 und rhel-hetz-tang2 sowie zwei NBDE-Clients (Clevis-Clients) rhel-hetz-clevis1 und rhel-hetz-clevis2. Die beiden NBDE-Clients besitzen jeweils ein LUKS-Device /dev/sdc, welches aktuell durch eine LUKS-Passphrase gesichert ist.
Zukünftig sollen diese LUKS-Devices durch die Kommunikation mit einem NBDE-Server entschlüsselt werden. Die LUKS-Passphrase soll entfernt werden.
Damit wird zukünftig ein Neustart der Clients aus der Ferne ermöglicht. Gleichzeitig bleibt das verschlüsselte Gerät bei Diebstahl vor unbefugtem Zugriff geschützt.
Hinweis: Das folgende Playbook ist nicht idempotent. Um dies zu ändern, ist dem ersten Task eine Bedingung hinzuzufügen, damit dieser nur dann ausgeführt werden, wenn die Bedingung erfüllt ist.
Für dieses Beispiel ist die fehlende Idempotenz des Playbooks jedoch kein Problem, da grubby das Argument nur dann hinzufügt, wenn es nicht bereits vorhanden ist.
---
- hosts: clevis
tasks:
- name: Configure ip address for interface during early boot
ansible.builtin.command:
cmd: grubby --update-kernel=ALL --args='GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0 ip={{ ansible_default_ipv4.address }}::{{ ansible_default_ipv4.gateway }}:{{ ansible_default_ipv4.netmask }}::{{ ansible_default_ipv4.alias }}:none"'
- name: Enroll Clevis clients
include_role:
name: rhel-system-roles.nbde_client
vars:
nbde_client_bindings:
- device: /dev/sdc
encryption_password: "{{ luks_password }}"
password_temporary: true
slot: 2
servers:
- http://rhel-hetz-tang1.example.com
- http://rhel-hetz-tang2.example.comluks_password stecktluks_password mit ansible-vault vor neugierigen Blicken zu schützenpassword_temporary: true wird die LUKS-Passphrase aus dem jeweiligen Key-Slot gelöscht, nachdem das LUKS-Device für NBDE konfiguriert wurdeAchtung (I know, the warning comes after the spell): Wenn zur Laufzeit ein Fehler auftritt und der Key-Slot mit der LUKS-Passphrase bereits gelöscht wurde, die NBDE-Konfiguration jedoch nicht erfolgreich war, verliert man Zugriff auf das LUKS-Device. In meiner Labor-Umgebung bin ich das Risiko eingegangen. In der echten Welt, müsst ihr selbst entscheiden, ob ihr mehr Vorsicht walten lasst.
Zur Erstellung des Playbooks habe ich die Informationen aus /usr/share/doc/rhel-system-roles/nbde_client/README.md und dem Kapitel 12.18. Using the nbde_client System Role for setting up multiple Clevis clients genutzt. Bis ich festgestellt habe, dass ich auch noch den Task „Configure ip address for interface during early boot“ benötige, hat es ein wenig gedauert. Nun habe ich allerdings ein Playbook, dass ich zukünftig wiederverwenden kann.
In der erstellten Konfiguration, können die LUKS-Devices nur entschlüsselt werden, wenn mindestens einer der beiden Tang-Server im Netzwerk erreichbar ist. Wird ein so gesicherter Server gestohlen und sind die Tang-Server nicht aus dem Internet erreichbar, bleiben die Daten in der verschlüsselten Partition wie gewohnt geschützt. Es ist jedoch möglich den Server neuzustarten, ohne manuell die LUKS-Passphrase an der Konsole eingeben zu müssen.
In diesem Artikel stelle ich euch die RHEL System Role nbde_server vor, mit welcher sich Tang-Server für Network Bound Disk Encryption (NBDE) installieren lassen. Er ist Bestandteil einer losen Serie, in der ich eine Reihe von System Roles vorstelle, mit denen häufig anfallende Aufgaben in der Systemadministration erledigt werden können.
Wer sich zuerst über die genannten Begriffe informieren möchte, lese zuerst:
Im folgenden Text verwende ich die Begriffe NBDE-Server und Tang-Server synonym. Bitte lasst euch dadurch nicht verwirren.
Für das folgende Beispiel verwende ich eine Umgebung, bestehend aus:
ansible-corerhel-system-rolesDie Installation von RHEL sowie der genannten Pakete sind nicht Bestandteil dieses Artikels. Wer hierzu einen Einstieg sucht, findet entsprechende Dokumentation unter:
Durch die Installation des Pakets rhel-system-roles existiert diese Rolle bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.nbde_server/ und die Dokumentation in /usr/share/doc/rhel-system-roles/nbde_server/README.md. Letztere enthält verschiedene Beispiele für häufige Anwendungsfälle.
Ich möchte mit dieser Rolle Folgendes erreichen:
enforcingDas Playbook ist recht übersichtlich. tang bezeichnet eine Gruppe aus meinem Ansible-Inventory, welche die Systeme enthält, die ich als NBDE-Server konfigurieren möchte.
---
- name: Manage nbde server with selinux and firewall
hosts: tang
vars:
nbde_server_manage_firewall: true
nbde_server_manage_selinux: true
roles:
- rhel-system-roles.nbde_serverNach der Anwendung der Rolle lauscht der Tang-Service auf Port 80/tcp der Zielsysteme und ist aus dem Netzwerk erreichbar.
Leider läuft es dieses Mal nicht ganz so rund wie üblich. Der Task [redhat.rhel_system_roles.selinux : Set an SELinux label on a port] schlägt auf dem RHEL 8 Host mit folgender Fehlermeldung fehl: „Failed to import the required Python library (libselinux-python)“
Das Problem und die Lösung beschreibt Red Hat in dem Solution Article: Ansible playbook fails with libselinux-python aren’t installed on RHEL8 (Login required)
Diesmal lief es nicht ganz so reibungslos wie gewohnt.
Letztendlich konnten die beiden NBDE-Server dennoch schneller konfiguriert werden, als wäre ich der manuellen Prozedur in Chapter 12. Configuring automated unlocking of encrypted volumes using policy-based decryption gefolgt.
Die Server sind damit aufgesetzt, nächste Woche beschreibe ich, wie die Clients konfiguriert werden.
Diese Einführung gibt Antworten auf die folgenden Fragen:
In dieser Einführung verwendete Betriebssysteme:
Um dieser Einleitung folgen zu können, solltet ihr mit den Grundlagen der Linux-Systemadministration vertraut sein und zumindest mit den folgenden Begriffen etwas anfangen können:
Ein Intrusion Detection System (englisch intrusion „Eindringen“, IDS) bzw. Angriffserkennungssystem ist ein System zur Erkennung von Angriffen, die gegen ein Computersystem oder Rechnernetz gerichtet sind. Das IDS kann eine Firewall ergänzen oder auch direkt auf dem zu überwachenden Computersystem laufen und so die Sicherheit von Netzwerken und Computersystemen erhöhen. Erkannte Angriffe werden meistens in Log-Dateien gesammelt und Benutzern oder Administratoren mitgeteilt; hier grenzt sich der Begriff von Intrusion Prevention System (englisch prevention „Verhindern“, IPS) ab, welches ein System beschreibt, das Angriffe automatisiert und aktiv verhindert.
Quelle: https://de.wikipedia.org/wiki/Intrusion_Detection_System (Letzter Abruf: 2023-09-08)
Die Gruppe der Intrusion Detection Systems (IDS) untergliedert sich in:
Beim AIDE handelt es sich um ein Host-basiertes IDS. Es ist unter der GPL-2.0 lizenziert.
Aus dem vorhergehenden Abschnitt ist bekannt, dass es sich bei AIDE um ein Host-basiertes System zur Angriffs- bzw. Einbruchserkennung für Linux-Systeme handelt. Es stellt ein kostengünstiges Werkzeug dar, mit dem die Integrität eines Systems überprüft werden kann.
Es soll dem Administrator helfen, zu erkennen, ob Dateien oder Verzeichnisse eines Systems hinsichtlich ihres Inhalts und bzw. oder ihrer Eigenschaften wie z.B. Berechtigungen, SELinx-Kontext, erweiterte Attribute, etc. verändert wurden.
/var/log/aide/aide.log protokolliertUm diese Schwäche zu minimieren, sind folgende Maßnahmen durch Administratoren in Erwägung zu ziehen:
Wie diese Maßnahmen umgesetzt werden können, beschreibe ich in einem folgenden Beitrag.
Werden beispielsweise Konfigurationsdateien unterhalb von /etc auf Änderungen hin überwacht, wird auch jede beabsichtige Änderung protokolliert. Das Programm kann zwischen legitimen und unautorisierten Änderungen nicht unterscheiden.
Daher ist nach jeder legitimen Änderungen die Referenzdatenbank zu aktualisieren. Ich empfehle, dies als einen Schritt in den Konfiguration-Management-Workflow zu integrieren und diese Aufgabe einen Automaten wie Ansible, Chef, Puppet o.ä. erledigen zu lassen. Dies erscheint mir weniger fehleranfällig zu sein als bei einer manuellen Durchführung, wo dieser Schritt sicher gern einmal vergessen wird.
AIDE ist in den Paketquellen der meisten Distributionen vorhanden und kann wie folgt installiert werden.
$ sudo dnf in aide
[sudo] password for tronde:
Updating Subscription Management repositories.
Last metadata expiration check: 2:26:44 ago on Fri 08 Sep 2023 08:16:28 PM CEST.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
aide x86_64 0.16-100.el9 rhel-9-for-x86_64-appstream-rpms 154 k
Transaction Summary
================================================================================
Install 1 Package
Total download size: 154 k
Installed size: 354 k
Is this ok [y/N]:
/etc/aide.conf besitzt im Auslieferungszustand bereits 303 Zeilen; ohne Kommentare und Leerzeilen sind es immerhin noch 161aide.conf(5)/etc/aide.conf vertraut machen; oder würdet ihr einem Firewall-Regelwerk vertrauen, das ihr nicht kennt?$ sudo apt install aide
[sudo] password for jkastning:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
aide-common liblockfile-bin liblockfile1 libmhash2
Suggested packages:
figlet
The following NEW packages will be installed:
aide aide-common liblockfile-bin liblockfile1 libmhash2
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 372 kB of archives.
After this operation, 1064 kB of additional disk space will be used.
Do you want to continue? [Y/n]aide werden noch die Pakete aide-common, liblockfile-bin, liblockfile1 und `libmhash2` installiert
/etc/aide/aide.conf installiert Debian auch das Verzeichnis /etc/aide/aide.conf.d, in welchem sich direkt nach der Installation schon etliche Konfigurationsdateien befinden:$ ls -l /etc/aide/aide.conf.d/ | wc -l
212Während AIDE in RHEL über eine einzige Datei (/etc/aide.conf) konfiguriert wird, gibt es in Debian eine Konfigurationsdatei (/etc/aide/aide.conf) und die Verzeichnisse /etc/aide/aide.conf.d sowie /etc/aide/aide.settings.d, welche weitere Dateien zur Konfiguration und Einstellungen beinhalten.
Eine AIDE-Konfigurationsdatei aide.conf besteht aus drei verschiedenen Arten von Zeilen:
Parameter = Wert bzw. Gruppenname = Wert@@define foo bar die Variable foo mit dem Wert barAIDE kann die folgenden Attribute bzw. Elemente von Dateien auf Änderungen hin überwachen:
#p: permissions
#i: inode
#n: number of links
#u: user
#g: group
#s: size
#b: block count
#m: mtime
#a: atime
#c: ctime
#S: check for growing size
#acl: Access Control Lists
#selinux SELinux security context
#xattrs: Extended file attributes
#md5: md5 checksum
#sha1: sha1 checksum
#sha256: sha256 checksum
#sha512: sha512 checksum
#rmd160: rmd160 checksum
#tiger: tiger checksumDer folgende Code-Block zeigt die Definition der beiden Gruppen NORMAL und DIR (aus der /etc/aide.conf in RHEL 9), welche spezifizieren, welche Attribute überwacht werden sollen, wenn die jeweilige Gruppe in einer Regel verwendet wird.
NORMAL = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha512
# For directories, don't bother doing hashes
DIR = p+i+n+u+g+acl+selinux+xattrsWelche Dateien und Verzeichnisse in die AIDE-Datenbank aufzunehmen bzw. auszuschließen sind durch reguläre Ausdrücke bestimmt. Der nächste Code-Block zeigt drei Beispiele, die anschließend erläutert werden:
/etc NORMAL
=/var/log/ DIR
=/home DIR
!/dev/etc und alle darunterliegenden Dateien und Verzeichnisse werden in die AIDE-Datenbank aufgenommen und mit den Regeln aus der Gruppe NORMAL verknüpft/var/log/ und die direkt darunter befindlichen Dateien und Verzeichnisse werden in die AIDE-Datenbank aufgenommen und mit der Gruppe DIR verknüpft; der Inhalt der Unterverzeichnisse wird nicht in die Datenbank aufgenommen/home wird aufgenommen; nicht jedoch der Inhalt davon/dev und alle darunterliegenden Dateien und Verzeichnisse werden nicht in die AIDE-Datenbank aufgenommenMit Sicherheit und Vertrauen ist das immer so eine Sache. Am besten ist es stets, wenn Vertrauen für Sicherheit nicht erforderlich ist. Daher rate ich an dieser Stelle nochmals ausdrücklich, die AIDE-Konfiguration zu überprüfen und ggf. den eigenen Bedürfnissen anzupassen… Nur um direkt gegen meinen eigenen Rat zu verstoßen.
Der Umfang an Regeln ist in beiden Systemen so groß, dass ich in dieser Einführung nicht alle einzeln erläutern kann. Ich vertraue für diese Einführung daher darauf, dass die Distributionen eine sinnvolle Konfiguration ausliefern.
Initialisiert wird die Datenbank je nach Distribution mit einem leicht abgewandelten Befehl.
$ sudo time aide --init
Start timestamp: 2023-09-18 20:50:06 +0200 (AIDE 0.16)
AIDE initialized database at /var/lib/aide/aide.db.new.gz
Number of entries: 54290
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.new.gz
MD5 : xOf5Bs/Hb2Caa5i2K41fbg==
SHA1 : KoCkqwfe+oZ2rlQTAU+AWQBrt2I=
RMD160 : eM6IC68wq1VRhDbyHhRqy+63ldI=
TIGER : lQC+UTBqUm0iEDdKA0u7THqAPLNQxegH
SHA256 : vdzjqIr/m7FgjXdZLQG+D1Pvf75WlF17
WYiA6gU+4Pg=
SHA512 : EdMB0I92j05zlfjXHcJFasZCAvkrK9br
6zQEcDfD4IDM8D9c1Sz0r7A5tJTKGXVZ
AFCOJR65j66ihKB0suFS6w==
End timestamp: 2023-09-18 20:50:19 +0200 (run time: 0m 13s)Die erzeugte Datenbank wird umbenannt, indem das new aus dem Dateinamen entfernt wird.
$ sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gzDie umbenannte Datei stellt die Referenzdatenbank dar, gegen die mit dem Befehl aide --check geprüft werden kann, ob es Änderungen im Dateisystem gab.
In diesem Artikel gebe ich mich damit zufrieden, dass die Datenbank auf dem zu überwachenden Host liegt und damit dem Risiko unterliegt, von einem Angreifer manipuliert zu werden (siehe zu den Schwächen oben). Ich gehe in einem Folgeartikel darauf ein.
Unter Debian wird die AIDE-Datenbank mit dem Wrapper-Script aideinit (siehe aideinit(8)) initialisiert. Das README unter /usr/share/doc/aide-common/README.Debian.gz warnt bereits davor, dass Debian mit zu restriktiven Einstellungen daherkommt:
Configuring AIDE the Debian way
/usr/share/doc/aide-common/README.Debian.gz
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AIDE’s Debian default configuration takes a very paranoid stance and
is likely to report more changes than you will need to focus your
attention on.
Lassen wir uns überraschen…
$ sudo time aideinit
Running aide --init...
7044.57user 54.97system 2:00:40elapsed 98%CPU (0avgtext+0avgdata 132408maxresident)k
231120192inputs+88320outputs (12major+66397minor)pagefaults 0swapsDas hat deutlich länger gedauert und endete mit einer deutlich kürzeren Ausgabe. Die erzeugte Datenbank ist jedoch wie bei RHEL im Verzeichnis /var/lib/aide/ zu finden.
:~# ls -l /var/lib/aide/
total 43536
-rw------- 1 root root 22286930 Sep 19 15:13 aide.db
-rw------- 1 _aide _aide 22286930 Sep 19 15:13 aide.db.new
:~# qm start 102
:~# file /var/lib/aide/aide.db.new
/var/lib/aide/aide.db.new: gzip compressed data, max compression, from Unix, original size modulo 2^32 44239215
:~# file /var/lib/aide/aide.db
/var/lib/aide/aide.db: gzip compressed data, max compression, from Unix, original size modulo 2^32 44239215Warum die Erstellung so viel länger gedauert hat, weiß ich nicht. Ich habe keine Idee dazu. Auch Debian erzeugt eine gzip-komprimierte Datenbank, auch wenn hier keine Dateiendung darauf hinweist. Ich finde das etwas seltsam, behalte die Standardeinstellung für diese Einführung jedoch bei. Dafür muss die Datei nicht manuell umbenannt werden, da direkt eine Kopie erstellt wird, die als Referenzdatenbank genutzt werden kann.
Im Gegensatz zu RHEL wird unter Debian auch ein Timer namens dailyaidecheck.timer installiert, welcher täglich einen automatischen Check auf Veränderungen durchführt. Allerdings ist es für einen Angreifer ein Leichtes, diese Timer-Unit zu deaktivieren.
Unter Debian und RHEL werden die in der Referenzdatenbank enthaltenen Elemente mit folgendem Befehl auf Änderungen überprüft:
:~# aide --check # unter RHEL
:~# aide --check --config /etc/aide/aide.conf # unter DebianIch habe meine Testsysteme ein paar Tage laufen lassen und einen AIDE-Integritätscheck durchgeführt. Hier das Ergebnis für ein RHEL 9 System:
$ sudo aide --check
Start timestamp: 2023-09-26 19:54:59 +0200 (AIDE 0.16)
AIDE found differences between database and filesystem!!
Summary:
Total number of entries: 54290
Added entries: 0
Removed entries: 0
Changed entries: 3
---------------------------------------------------
Changed entries:
---------------------------------------------------
f = ... . ..S : /var/log/insights-client/insights-client.log.3
f < ... . ... : /var/log/rhsm/rhsmcertd.log
f < ... . ... : /var/log/squid/cache.log
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /var/log/insights-client/insights-client.log.3
SELinux : system_u:object_r:insights_clien | unconfined_u:object_r:insights_c
t_var_log_t:s0 | lient_var_log_t:s0
File: /var/log/rhsm/rhsmcertd.log
Size : 1426 | 1343
File: /var/log/squid/cache.log
Size : 6230 | 334
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.gz
MD5 : xOf5Bs/Hb2Caa5i2K41fbg==
SHA1 : KoCkqwfe+oZ2rlQTAU+AWQBrt2I=
RMD160 : eM6IC68wq1VRhDbyHhRqy+63ldI=
TIGER : lQC+UTBqUm0iEDdKA0u7THqAPLNQxegH
SHA256 : vdzjqIr/m7FgjXdZLQG+D1Pvf75WlF17
WYiA6gU+4Pg=
SHA512 : EdMB0I92j05zlfjXHcJFasZCAvkrK9br
6zQEcDfD4IDM8D9c1Sz0r7A5tJTKGXVZ
AFCOJR65j66ihKB0suFS6w==
End timestamp: 2023-09-26 19:55:12 +0200 (run time: 0m 13s)Die Integritätsprüfung in obigen Code-Block führt Änderungen an drei Dateien auf:
summarize_changes in aide.conf(5).Abbruch meiner Tests unter Debian 12 (Bookworm)
Unter Debian hat die Integritätsprüfung über Stunden einen CPU-Kern blockiert. Der Prozess ist in einem futex Syscall hängen geblieben.
Ob es an meinem System liegt oder AIDE unter Debian generell ein Problem hat, kann ich nicht sagen. Ich bin der Sache nicht weiter nachgegangen.
Falls jemand von euch AIDE unter Debian einsetzt und dies liest, freue ich mich, wenn ihr eure Erfahrungen mit mir teilt.
Mit dem Befehl aide --update wird die Datenbank-Integrität geprüft und eine neue Datenbank /var/lib/aide/aide.db.new.gz erzeugt. Die bestehende Referenzdatenbank /var/lib/aide/aide.db.gz wird dabei nicht überschrieben und bleibt zunächst erhalten. Möchte man diese länger aufbewahren, kann man sie umbenennen und bspw. einen Zeitstempel anhängen. Anschließend erzeugt man mit mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz eine neue Referenzdatenbank.
Der folgende Code-Block zeigt die Ausgabe von aide --update unter RHEL 9.
~]# aide --update
Start timestamp: 2023-09-26 20:13:52 +0200 (AIDE 0.16)
AIDE found differences between database and filesystem!!
New AIDE database written to /var/lib/aide/aide.db.new.gz
Summary:
Total number of entries: 54290
Added entries: 0
Removed entries: 0
Changed entries: 3
---------------------------------------------------
Changed entries:
---------------------------------------------------
f = ... . ..S : /var/log/insights-client/insights-client.log.3
f < ... . ... : /var/log/rhsm/rhsmcertd.log
f < ... . ... : /var/log/squid/cache.log
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /var/log/insights-client/insights-client.log.3 [0/100]
SELinux : system_u:object_r:insights_clien | unconfined_u:object_r:insights_c
t_var_log_t:s0 | lient_var_log_t:s0
File: /var/log/rhsm/rhsmcertd.log
Size : 1426 | 1343
File: /var/log/squid/cache.log
Size : 6230 | 334
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.gz
MD5 : xOf5Bs/Hb2Caa5i2K41fbg==
SHA1 : KoCkqwfe+oZ2rlQTAU+AWQBrt2I=
RMD160 : eM6IC68wq1VRhDbyHhRqy+63ldI=
TIGER : lQC+UTBqUm0iEDdKA0u7THqAPLNQxegH
SHA256 : vdzjqIr/m7FgjXdZLQG+D1Pvf75WlF17
WYiA6gU+4Pg=
SHA512 : EdMB0I92j05zlfjXHcJFasZCAvkrK9br
6zQEcDfD4IDM8D9c1Sz0r7A5tJTKGXVZ
AFCOJR65j66ihKB0suFS6w==
/var/lib/aide/aide.db.new.gz
MD5 : Dgoc1/L5F1UfXPAQRvMdTg==
SHA1 : 23RFwEBIh0kw/3TiiVAh39Fzx0Q=
RMD160 : 1szie2CW1dyLmaKFg01j48Fr+Us=
TIGER : TgdG3zNAOSZH2D9jkyvBves8PtjC0lCR
SHA256 : hjn9vxFxg4KoVwT3YvgU347EhvTCg5ey
lfktpr/OrcA=
SHA512 : x6E3YPa0eILD3nZqDt6N755KSmPRFOz8
lhKD9CimYScSpxyoVxJAVWiozR8KUwkt
Ao7mgy3BgtUA0MZuNMv43w==
End timestamp: 2023-09-26 20:14:03 +0200 (run time: 0m 11s)
~]# ls -l /var/lib/aide
total 6184
-rw-------. 1 root root 3163359 Sep 18 20:50 aide.db.gz
-rw-------. 1 root root 3163384 Sep 26 20:14 aide.db.new.gzAn dieser Stelle endet die Einführung in das Advanced Intrusion Detection Environment (AIDE). Kommt das Ende für euch abrupt? Ist es ein Ende mit Schrecken? Lasst es mich gern wissen.
In dieser Einführung habe ich beschrieben, was Intrusion-Detection-Systeme im Allgemeinen und AIDE im Speziellen sind. Ich bin auf deren Nutzen eingegangen und habe die Schwächen von AIDE als Host-basiertem IDS benannt. Installation, Konfiguration, Integritäts-Check und Aktualisierung der Datenbank wurden erklärt und mit Beispielen belegt.
Was ist nun von AIDE zu halten?
Nun, es ist besser als nichts. Man besitzt damit ein Werkzeug, mit dem sich Änderungen im Dateisystem erkennen lassen. Man muss sich jedoch der Schwächen Host-basierter IDS bewusst sein. Ein Angreifer mit lokalen root-Rechten kann dieses Werkzeug mit wenig Aufwand unschädlich machen bzw. die eigenen Änderungen verschleiern.
Sicher kann man einen Integritätscheck automatisiert alle 5 Minuten durchführen und für Änderungen eine E-Mail-Benachrichtigung einrichten. Doch wirkt dies etwas hemdsärmelig. Daher werde ich dieses Thema in einem späteren Artikel aufgreifen und zeigen, wie man AIDE in einen Automations- bzw. Konfigurations-Management-Prozess einbinden kann.
Vor kurzem gab es das „WinRAR | 9GAG Special Offer!“ und ich bin einer von 5449 Personen, die bei diesem Angebot zugeschlagen haben. Der Key gilt nicht nur für WinRAR, sondern auch für die...
Im siebten Teil meiner losen Reihe über die RHEL System Roles stelle ich die Rolle rhc vor, mit welcher sich RHEL-Systeme (Version >= 8.6) in der Hybrid Cloud Console, Insights und dem RHSM registrieren lassen.
Das Tool rhc selbst habe ich bereits im Artikel Red Hat Remote Host Configuration ausführlich vorgestellt.
Möchte man ein oder mehrere RHEL-Systeme in der Hybrid Cloud Console registrieren, kann man dazu die RHEL System Role rhc verwenden.
Durch die Installation des Pakets rhel-system-roles existiert die Rolle rhc bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.rhc/ und die Dokumentation in /usr/share/doc/rhel-system-roles/rhc/README.md.
- name: Register systems
hosts: all
vars:
rhc_auth:
activation_keys:
keys: ["key-1", ...]
rhc_organization: "your-organization"
roles:
- rhel-system-roles.rhckey-1 ist durch den eigenen Activation Key zu ersetzenyour-organization ist durch die eigene Org-ID zu ersetzenMit dieser System Role ist es einfach möglich, eine große Anzahl Systeme in die Hybrid Cloud Console aufzunehmen. Dabei lässt sich konfigurieren, ob Funktionen wie Insights und Remediation Playbooks genutzt werden können.
Eine weitere tolle Rolle aus dem Paket rhel-system-roles, die sich einfach zur Anwendung bringen lässt.
Auf Mobiltelefonen, Tablets, Laptops, Netzwerkspeichern und in diversen Anwendungen in unserem Heimnetzwerk befinden sich Daten, welche wir schmerzlich vermissen würden, wenn sie dauerhaft verloren gingen.
Im Folgenden beschreibe ich, wie ich z.B. Fotos, Videos, Zeugnisse, Verträge, Urkunden, Versicherungspolicen, etc. vor Verlust schütze.
Der Artikel behandelt nicht:
Sie sind unsere ständigen Begleiter, verfügen über große Speicher und beinhalten häufig jede Menge an Fotos und Videos. Diese werden mit DS-Apps auf eine Synology Diskstation im heimischen Netzwerk gesichert.
Für Threema benutze ich Threema Safe. Ein Datenbackup führe ich nicht durch. Der Inhalt der Nachrichten ist mir nicht so wichtig, als dass mich ein Verlust schmerzen würde.
E-Mails, Kalender und Kontakte werden zwischen Mailbox.org und diversen Geräten synchronisiert, jedoch nicht gesichert. Wenn jemand z.B. das Adressbuch löscht, müsste ich das Netzwerk vom PC trennen, um das Adressbuch ohne Netzwerkverbindung zu starten, um den letzten Stand von dort wiederherstellen zu können. Für mich ist das ausreichend, da ich bei einem GAU meine wichtigsten Kontakte auch ohne Adressbuch zu erreichen weiß und sich Kontaktinformationen von Handwerkern und sonstigen Unternehmen wieder recherchieren lassen.
Sollte ich Zugriff auf die App Aegis Authenticater verlieren, muss ich auf die Backup-Codes zurückgreifen, welche in einer KeePass-Datenbank lagern.
Falls ihr einfache Lösungen kennt, um sämtliche Apps samt deren Inhalte sichern und auf abweichenden Telefonen wiederherstellen zu können, freue ich mich, wenn ihr mir davon berichtet.
Meine Synology Diskstation ist:
Ausgewählte Daten werden wöchentlich mit Hyper Backup (Backup-Anwendung der Diskstation) auf eine angeschlossene USB-Festplatte gesichert. Darüber hinaus habe ich mir ein Offsite-Backup gebastelt, welches ich in diesem Artikel beschrieben habe.
Über Erfolg und Misserfolg der Sicherungen werde ich per E-Mail benachrichtigt.
Die größte Herausforderung für mich ist es, die Wiederherstellbarkeit der gesicherten Daten zu kontrollieren. Dies mache ich bisher sporadisch und manuell. Und vermutlich viel zu selten.
Daten meiner Laptops synchronisiere ich teilweise mit Nextcloud, welche ich auf einem virtuellen Server betreibe. Gehostet wird dieser bei Contabo in Deutschland.
Darüber hinaus nutze ich Déjà Dup Backups für eine wöchentliche Datensicherung meines HOME-Verzeichnisses in die Nextcloud mit 180 Tagen Vorhaltezeit. Auch hier teste dich die Wiederherstellbarkeit sporadisch.
Das HOME-Verzeichnis meines Dienstlaptops wird täglich mit Déjà Dup in das Google Drive meines Arbeitgebers gesichert.
Auch wir haben jede Menge totes Holz im Schrank stehen, dessen Wiederbeschaffung bei Verlust mit viel Zeit und Mühe verbunden ist.
Meine Lösung für diese Herausforderung habe ich in Mein Paperless-NGX-Mini-Konzept niedergeschrieben.
Hier möchte ich die Wiederherstellung noch verbessern, indem ich auf meinem Laptop ein Ansible-Playbook ablege, welches die Paperless-NGX-Instanz auf meinem Laptop wiederherstellt. So teste ich die Wiederherstellbarkeit und habe immer eine relativ aktuelle Kopie auf der verschlüsselten Festplatte meines Laptops bei mir.
Auf einem virtuellen Server in der Cloud möchte ich diese Daten aktuell nicht so gerne hosten. Dazu muss ich mir zuvor in Ruhe Gedanken über mögliche Risiken für die Integrität und Vertraulichkeit der Daten machen.
Meine produktive Paperless-NGX-Instanz steht mit dem Papier im gleichen Haus. Das Backup beinhaltet alle PDF-Dateien und liegt verschlüsselt in der Cloud. Da die Dateinamen halbwegs sinnvoll benannt sind, scheint im Falle eines GAU die Suche im Heuhaufen nicht hoffnungslos.
Für beide Dienste, welche auf einem virtuellen Server bei Contabo laufen, wird zur Datensicherung wöchentlich ein Datenbank-Dump und ein Archiv der Verzeichnisstruktur mit Ordnern und Dateien erstellt. Dieses Backup wird lokal auf dem Server abgelegt und für 30 Tage vorgehalten. Ich nutze dafür selbstgeschriebene Bash-Skripte, welche durch Cron ausgeführt werden.
Auf meinem NAS läuft ein Skript, welches die Backups vom Server auf das NAS synchronisiert.
Über Erfolg und Misserfolg der einzelnen Jobs werde ich per E-Mail benachrichtigt.
Die Wiederherstellbarkeit teste ich sporadisch und sollte dies mutmaßlich häufiger tun. Ein Automat dafür befindet sich aktuell in Arbeit. Den aktuellen Stand kann man in folgenden Artikeln nachlesen:
Ruhende Daten werden verschlüsselt, bevor sie in die Cloud hochgeladen werden. Das Restrisiko, dass der fremde Betreiber prinzipiell die Kontrolle über meinen virtuellen Server übernehmen kann, bleibt.
Betreibe ich Server oder Dienst nicht im eigenen Heimnetzwerk, nutze ich für den Betrieb deutsche Anbieter mit Standorten in Deutschland. Zu diesen habe ich einfach das größte Vertrauen, dass sie sich an geltende Gesetze halten, die Hoffnung, dass sie den Datenschutz ernst nehmen und meine Daten dort gut aufbewahrt sind.
Wie sichert ihr eure Daten außer Haus? Welche Dienste verwendet ihr dazu? Ich freue mich, wenn ihr eure Erfahrungen in den Kommentaren teilt.
Ich habe mir zumindest mal Gedanken gemacht, welche Daten so wichtig sind, dass ich sie vor Verlust schützen möchte. Zum Schutz vor Verlust kommen verschiedene Verfahren zum Einsatz, die auf der Schaffung von Redundanz durch Synchronisierung oder der Datensicherung mit Versionierung beruhen.
Die Wiederherstellbarkeit wird zumindest sporadisch getestet. Dieser Punkt ist sicherlich ausbaufähig.
Wer die einzelnen Abschnitte gelesen hat, stellt jedoch auch fest, dass es schnell ein wenig unübersichtlich wird. Zumindest hilft dieser Artikel etwas, den Überblick zu behalten.
Für die Zukunft wünsche ich mir eine dedizierte Backup-Senke im Keller, in der sich ausschließlich Backups befinden und eine Offsite-Senke, auf welche die Daten der Backup-Senke gesichert werden. Bis ich da hinkomme, wird sicherlich noch etwas Zeit vergehen.
Der Pinecil v2 kann, wie der Pinecil v1 und andere IronOS-kompatible Lötkolben, mit einem eigenen Bootlogo versehen werden. Hierfür müssen folgende Voraussetzungen erfüllt sein: Pinecil v2 mit IronOS 2.22-rc (oder neuer) Ich für diese...
Ich habe mir mit einem Odroid HC1 ein zusätzliches NAS aufgebaut, auf welchen mein Proxmox VE Server täglich sichern soll. Sofern ihr noch keinen freigegebenen Ordner, auf welchen der Proxmox VE Server am Ende...
Der Xbox One Digital TV Tuner ist mit ~15€ der günstigste DVB-T2 & DVB-C USB-Stick, welcher auch unter Linux nutzbar ist. In diesem Beitrag zeige ich euch, wie ihr den benötigten Treiber unter CoreELEC...
Ich habe mir vor kurzem den „SONOFF Zigbee 3.0 USB Dongle Plus“ gekauft. Dieser wird standardmäßig mit der Z-Stack 3.x.0 Firmware Version „20210120“ ausgeliefert, die (Stand August 2024) aktuelle Z-Stack Firmware Version ist „20240710“....
Durch diesen Blogbeitrag auf LinuxNews bin ich auf das Tool trash-cli aufmerksam geworden. Installation: # Arch Linux sudo pacman -S trash-cli # Debian/Ubuntu sudo apt install trash-cli # Fedora sudo dnf install trash-cli Befehle:...
Pika Backup ist eine Anwendung für einfache Updates über „BorgBackup„. Der Name „Pika Backup“ hat nichts mit dem Pokémon „Pikachu“ zu tun. Auf GitLab steht hierzu folgendes: The name “Pika Backup” derives from the...
Ich besitze seit kurzem ein TUXEDO InfinityBook Pro 14 Gen6 mit 3K „Omnia“ Display. Dieses Display besitzt eine Auflösung von 2880 x 1800 Pixeln. Für HiDPI Displays können unter Gnome dank des „Fractional Scaling“...
Mit Firefox 89 führt Mozilla (mal wieder) ein neues Design ein, welches nicht allen Nutzern und Nutzerinnen gefällt. Es gibt aber bereits einen „Fix“ mit welchem einige Teile des neuen Designs deaktiviert werden können....
