für den IT-Administrator

Redaktion IT-Administrator

In jeder Ausgabe präsentiert Ihnen IT-Administrator Tipps, Tricks und Tools zu den aktuellen Betriebssystemen und Produkten, die in vielen Unternehmen im Einsatz sind. Wenn Sie einen tollen Tipp auf Lager haben, zögern Sie nicht und schicken Sie ihn per E-Mail an tipps@it-administrator.de.

Bei unserer Arbeit mit Datenbankanwendungen wie Microsoft SQL, Oracle und SAP Hana kommt es hin und wieder zu unerwarteten Problemen. Wir müssen die Datenbanken dann umgehend in einem konsistenten Zustand wiederherstellen, um eine Beschädigung zu vermeiden. Die daraus entstehenden Ausfallzeiten und Datenverluste werfen unsere Zeitpläne teils drastisch zurück. Wie können wir die Sicherheit unserer Daten gewährleisten und nach einem derartigen Vorfall so schnell wie möglich weiterarbeiten?

Bei jeder Art von Entwicklungsarbeit kann es zu Störungen oder Ausfällen kommen, die Auswirkungen auf den Betriebsalltag haben und zu Datenverlust führen können. Mit AWS Elastic Disaster Recovery (DRS) lassen sich solche Risiken minimieren und lokale und cloudbasierte Anwendungen wiederherstellen. AWS wirbt dabei mit kostengünstiger Speicherung, wenig Rechenaufwand und zeitpunktbezogenem Recovery der Anwendungen. Hierzu müssen Sie Elastic Disaster Recovery auf Ihren Quellservern einrichten. Auf diese Weise lassen sich Ihre Daten in ein Staging-Area-Subnetz Ihres AWSKontos in der ausgewählten AWS-Region wiederherstellen. Zudem können Sie die Backups überwachen und in regelmäßigen Abständen unterbrechungsfreie Recoveryund Failback-Übungen durchführen. DRS konvertiert Ihre Server automatisch so, dass sie direkt in AWS starten und ausgeführt werden.

Um Elastic Disaster Recovery nutzen zu können, müssen Sie es zunächst in jeder dafür vorgesehenen AWS-Region einrichten: Legen Sie zunächst die Einstellungen der Standardreplikation fest. Dazu wählen Sie "Set default replication settings" auf der Startseite von DRS. Es öffnet sich ein Setup- Assistent. Im ersten Schritt gehen Sie zu "Setup replication servers". Hier verwenden Sie entweder die Standardeinstellungen oder konfigurieren Ihre eigenen Einstellungen. Wenn Sie diesen Schritt abgeschlossen haben, wählen Sie "Next". Konfigurieren Sie nun die "Volumes and security groups". Hier empfiehlt es sich, dass DRS automatisch die Standard-Sicherheitsgruppe zuordnet und überwacht. Mit "Next" gelangen Sie wieder zum nächsten Schritt. Konfigurieren Sie danach die "Additional settings". Dazu gehören Datenweiterleitung und -drosselung, PIT-Richtlinie (Point-in-Time) und Tags. Klicken Sie danach erneut auf "Next". Überprüfen Sie abschließend die von Ihnen konfigurierten Einstellungen. Wenn Sie noch etwas bearbeiten wollen, klicken Sie auf "Edit" neben der jeweiligen Einstellung. Sobald Sie alle von Ihnen gewählten Einstellungen überprüft haben, ist "Create default" der abschließende Klick. Nun wird die Standardvorlage erstellt und Sie werden zur Elastic- Disaster-Recovery-Konsole weitergeleitet. Damit haben Sie das erste Setup erfolgreich abgeschlossen. (AWS/ln)

In der Berechtigungsverwaltung von Azure AD lassen sich einem Zugriffspaket (Access Package) Ressourcen und Richtlinien so einrichten, dass der Zugriff für die gesamte Lebensdauer des Zugriffspakets automatisch verwaltet wird. Wir sehen bei der Administration des Access Packages jedoch weniger unsere IT-Abteilung in der Pflicht, sondern die einzelnen Fachabteilungen. Wo nehmen wir die Grundeinstellungen vor?

Natürlich sollten Access Packages nicht von der zentralen IT verwaltet werden. Die jeweilige Abteilung selbst kann das Delegieren dieser Tätigkeiten für das Schnüren der Pakete und der Approvals und Rejections handhaben. Pakete lassen sich deshalb logisch in "Kataloge" gruppieren, denen Sie dann delegierte Administratoren und Bewilliger zuweisen. Bei der Erstellung eines neuen Access Packages konnten Sie im ersten Schritt einen "Catalog" auswählen, in dem das Paket dann veröffentlicht wird.

Bei "Azure Active Directory / Identity Governance" im Azure-AD-Portal sehen Sie im linken Menü den Punkt "Catalogs". Dort findet sich die Übersicht, in der Sie auch neue Kataloge hinzufügen können. Haben Sie bei der Paketerstellung keinen Katalog ausgewählt, wandert das neue Access Package automatisch in den "Default Catalog". Per Klick darauf sehen Sie im linken Menü weitere Auswahlmöglichkeiten sowie Übersichten zu Ressourcen, Paketen und Delegationsmöglichkeiten in "Roles and administrators".

In der Hauptübersicht befindet sich der Schalter "Edit", mit dem Sie Änderungen am Katalog vornehmen. Wichtig: Hierüber definieren Sie, ob der Katalog und all seine Pakete für Mitarbeiter und wahlweise für externe Partner sichtbar sein soll oder nicht: Die beiden Optionen heißen "Enabled" und "Enabled for external users". Sind hier die Schalter auf "No" gesetzt, sehen Mitarbeiter oder externe Partner die Pakete nicht im Self-Service- Portal und können sie entsprechend auch nicht selbstständig anfragen.

Bei der Auswertung möglicher Sicherheitsvorfälle können fehlgeschlagene Anmeldungen ein Hinweis auf versuchte Angriffe sein. Mit dem Windows Event Viewer ist es jedoch nahezu unmöglich, solche Ereignisse sinnvoll auszuwerten. Wie können wir beispielsweise alle gescheiterten Logins des letzten Tages anzeigen?

Fehlgeschlagene Anmeldungen sind ein normaler Teil des IT-Alltags. Häufen sich diese jedoch, kann dies ein Anzeichen für Brute-Force-Attacken und ähnliche Angriffe darstellen. Für Admins empfiehlt es sich daher, Anmeldeversuche auf den Konten der eigenen Domäne auf verdächtige Aktivität zu prüfen. Für die laufende Kontrolle bietet sich ein Power- Shell-Skript an, das regelmäßig zur Ausführung kommt. Die PowerShell liest jedoch nur Events auf dem jeweiligen Domaincontroller aus – um mehrere DCs zu überprüfen, müssen Sie diese also einzeln ansteuern. Wichtig: Damit Win - dows die entsprechenden Daten überhaupt aufzeichnet, müssen Sie zunächst über eine GPO die Überwachungsrichtlinie "Anmeldeversuche überwachen" aktivieren.

In unserem Beispielskript im Kasten definieren wir zunächst einen anpassbaren Datumsfilter. Anschließend rufen wir das EventLog auf, filtern alle Ereignisse mit der ID 4625 (Anmeldefehler) heraus und exportieren die Daten zu jedem Vorfall in ein CSV-Dokument. Die dort aufgelisteten Informationen lassen sich je nach Bedarf erweitern. Nun gilt es zu analysieren, ob die Failed Logins auf einen Benutzerfehler oder Angriff zurückzuführen sind. Die Auswertung von Sicherheitsvorfällen im Active Directory lässt sich über eine Benutzerverwaltungssoftware automatisieren, um schnell einen Überblick über mögliche Bedrohungen zu gewinnen.

Weitere Tipps zum Thema Active Directory finden Sie im IAM-Blog von tenfold unter https://tenfold-security.com/ratgeber/

Bei der Installation von Debian 11 auf einem System mit einem RAID-Controller der Marke MegaRAID 9341-4i erscheint beim Bootvorgang die Fehlermeldung "AVAGO EFI SAS Driver is Unhealthy" und beim Starten des Betriebssystems die Nachricht "R: DRHD: handling fault status reg 3". Hinzu kommt, dass der Debian- Installer bei der Festplattenauswahl teilweise das RAID nicht anzeigt. Wie lässt sich dieses Problem beheben?

Um das beschriebene Problem zu lösen, müssen Sie die Intel-IOMMU-Funktionen im Linux-Kernel auf "pass-through" setzen. Dies funktioniert mittels des Kernel- Parameters "intel_iommu=on iommu= pt". Diesen müssen Sie jedoch insgesamt dreimal setzen, jeweils

- beim Debian-Installer

- nach dem Booten im GRUB und

- im OS unter "/etc/default/grub"

Bei der UEFI-Installation funktioniert das im Debian-Installer so: Mit "E" für "Edit Selection" lässt sich der Booteintrag ändern. Hier müssen Sie die dritte Zeile "linux /install.amd/vmlinuz vga=788 --- quiet" bearbeiten, indem sie ""--- quiet" durch "intel_iommu=on iommu=pt" ersetzen. Nehmen Sie hingegen eine Legacy- Installation vor, lässt sich der Booteintrag im Legacy-Modus über die Tab- Taste bearbeiten. Auch hier modifizieren Sie wieder den Eintrag "linux /install.amd/ vmlinuz vga=788 --- quiet" und ersetzen "---quiet" durch den bereits beschriebenen Kernel-Parameter. Das RAID sollte nun im Debian-Installer erscheinen und sich auswählen lassen.

Nach dem Booten müssen Sie nun noch im GRUB tätig werden. Nach der Installation über "E" sollten Sie den Boot- Eintrag bearbeiten. Hier scrollen Sie zur drittletzten Zeile namens "linux /boot/ vmlinuz-5-10.0-17...... ro quiet". Hier ersetzen Sie "quiet" ebenfalls durch "intel_ iommu=on iommu=pt". Als Letztes sind noch Änderungen im Betriebssystem selbst nötig. Navigieren Sie in das Verzeichnis "/etc/ default" und bearbeiten Sie zum Beispiel mit dem Editor nano das GRUB-File. Hier geht es um die Zeile

die Sie mit der Zeile

ersetzen. Anschließend führen Sie noch mit su - und update-grub ein Update von GRUB durch. Nach dem Setzen der Parameter und dem GRUP-Update sollten nun keine Fehlermeldungen mehr auftauchen und das RAID erkannt werden.

Viele weitere Tipps und Tricks zum Servermanagement, Virtualisierung und Linux finden Sie im Thomas-Krenn-Wiki unter https://www.thomas-krenn.com/de/wiki/Hauptseite

Wir monitoren unsere IT- und IoT-Systemumgebungen mittlerweile komplett mit Paessler-Produkten. Die Installationen sind dabei global über all unsere Standorte verteilt. Hinzu kommt, dass wir sowohl die klassische On-Premises-Software PRTG Network Monitor einsetzen als auch einige Instanzen der cloudbasierten Plattform PRTG Hosted Monitor betreiben. Nun möchten wir in unserer IT-Zentrale auf einen Blick sehen, ob die IT-Komponenten an allen Standorten problemlos laufen, ohne zwischen den einzelnen Webinterfaces hin und her zu springen. Welche Möglichkeiten gibt es hier?

Für den von Ihnen beschriebenen Anwendungsfall stellt Paessler die Anwendung "PRTG Desktop" zur Verfügung. Die Applikation lässt sich beispielsweise auf dem Client des Administrators installieren und verbindet sich mit den PRTG-Servern. In der Anwendung bietet Ihnen die Einzelserver- Ansicht den aus dem Webinterface gewohnten Zugriff auf Sensoren und Geräte. Sobald mehrere Installationen von PRTG mit der Applikation verbunden sind, steht zusätzlich die Multi-Server-Ansicht zur Verfügung. Dort finden Sie eine Übersicht aller Sensoren, ein konfigurierbares Dashboard und eine Reporting- Funktion. Mit dem Probe-Transfer-Feature haben Sie außerdem die Möglichkeit, eine PRTG-Probe mit all ihren Geräten und Sensoren von einem PRTG-Server auf einen anderen zu verschieben. Auf der Webseite des Herstellers [Link-Code: m0pe1] können Sie PRTG Desktop kostenlos für die Betriebssysteme Windows, macOS und Linux herunterladen.

Für viele weitere Tipps und Tricks rund um das Thema Monitoring mit PRTG bietet Paessler unter [Link-Code: https://www.youtube.com/c/PRTGNetworkMonitorByPAESSLER?utm_source=itadministrator&utm_medium=referral&utm_campaign=tipps] auch einen Youtube-Kanal mit Tutorials an.

Viele Administratoren von Linux- Servern schalten automatische Updates für die auf ihren Maschinen installierten Anwendungen ab. Sie verzichten also auf Softwareaktualisierungen über den Package Manager und nehmen Updates von Hand vor. Dies erfolgt zumeist aus Sicherheitsgründen, denn sofern Updates automatisch erfolgen, muss der IT-Verantwortliche sicher sein, dass es darin keine bekannten Schwachstellen gibt, die auf diesem Wege auf seinen Server gelangen können. Dies hat aber zur Folge, dass der Admin selbst prüfen muss, ob neue Softwarepakete einen Eintrag in Schwachstellendatenbanken wie der NVD (National Vulnerability Database) oder vergleichbaren DBs aufweisen. Doch bekanntermaßen ist ein solches manuelles Vorgehen besonders fehleranfällig, etwa wenn dabei eine Schwachstelle übersehen wird. Einen Ausweg aus diesem Dilemma will der freie Scanner Vuls liefern.

Die Open-Source-Software Vuls stellt dem IT-Verantwortlichen die für eine manuelle Aktualisierung seiner Systeme notwendigen Sicherheitsanalysen in Sachen Softwareschwachstellen bereit. Dabei listet das Werkzeug zunächst alle bekannten Lücken in den untersuchten Servern und zeigt auf, welche Systeme konkret betroffen sind. Dies erfolgt automatisiert und verspricht so, dass alle potenziellen Gefahrenherde erkannt werden. Auf dieser Basis erstellt Vuls dann einen Bericht.

Die Software unterstützt nahezu alle bekannten Linux-Distributionen, unter anderem FreeBSD-Server, Amazon Linux, CentOS, Debian, Oracle Linux, Raspbian, RHEL, SUSE Enterprise Linux, Fedora und Ubuntu. Zum Einsatz kann der Scanner lokal, in der Cloud und in Docker-Infrastrukturen kommen. Vuls benötigt dabei keine Root-Rechte und bringt auch keine Abhängigkeiten zu anderer Software mit sich. Bei Bedarf lässt sich der Scanner allerdings auch mit Root-Berechtigung ausführen, um so auf bestimmten Systemen wie etwa Amazon Linux Prozesse zu identifizieren, die vom geplanten Update beeinträchtigt werden könnten. Zudem geben die Entwickler an, dass das Tool den gescannten Server kaum in Sachen Performance belastet.

Link-Code: https://vuls.io/

Schwachstellen, die nicht wie bei Vuls in den auf Servern installierten Anwendungen, sondern in der Infrastruktur zu verorten sind, machen Admins oft Probleme beim schnellen Aufspüren der Gefahren. Protokolle wie DNS, HTTP und TCP finden sich nahezu überall in der IT-Landschaft und sind oft schwer einzugrenzen. Hier hat der Open-Source- Scanner Nuclei den Ehrgeiz, den IT-Verantwortlichen von Anfang an auf die richtige Fährte zu führen.

Nuclei ist ein schneller und anpassbarer Schwachstellen-Scanner. Das Tool basiert auf der Programmiersprache Golang, weshalb für die Arbeit damit eine entsprechende Umgebung auf der ausführenden Maschine vorhanden sein muss. Nuclei sendet seine Scans Requests (auch über mehrere Ziele) auf der Grundlage von Vorlagen. Dies hat laut den Entwicklern den Vorteil, dass es nicht zu False Positives oder irrelevanten Ergebnissen kommt. Zudem sollen die Untersuchungen dank dieser Templates auch deutlich schneller laufen als mit vergleichbaren Werkzeugen. Dabei kann der Admin Scan-Vorlagen vom Anbieter, aus der Community und natürlich auch eigene nutzen. Besonders clever ist dabei eine Funktion, die solche Templates automatisch aktualisiert, um immer nach aktuellen Schwachstellen zu scannen.

Das Open-Source-Tool sendet seine Anfragen an frei definierte Hosts in der Infrastruktur und sucht dort Probleme in Sachen TCP, SSH, DNS, HTTP/S, SSL, Websocket, Whois und mehr. Diese Anfragen basieren auf den erwähnten Vorlagen, die bei Nuclei in YAML verfasst sind. Diese Scans bringen Schachstellen in Webanwendungen und Netzwerken zum Vorschein, zeigen aber auch Fehlkonfigurationen im DNS. Darüber hinaus ist das Werkzeug in der Lage, sensible Daten wie Credentials in Source Code und dem lokalen Dateisystem zu finden.

Link-Code: https://nuclei.projectdiscovery.io/

Um in einer eher kleinen Infrastruktur für mehr Sicherheit zu sorgen, müssen nicht gleich mächtige Scanner wie die soeben vorgestellten Vuls und Nuclei zum Einsatz kommen. In solchen Umgebungen ist es aber dennoch eine Pflichtaufgabe, Logmeldungen, wie sie beispielsweise Netzwerkgeräte oder Drucker absetzen, im Auge zu behalten. Doch dies ist mit einigem Zeitaufwand verbunden, wenn der Admin jedes Log einzeln untersuchen muss. Mit der freien Version des Syslog-Verwaltungswerkzeugs Kiwi Syslog Server lassen sich Syslog- Meldungen und SNMP-Traps von bis zu fünf Quellen erfassen, anzeigen und archivieren.

Die kostenlose Version des eigentlich lizenzpflichtigen Kiwi Syslog Server von SolarWinds bietet eine Plattform zum zentralen Sammeln und Auswerten von Loginformationen. IT-Verantwortliche haben so die Möglichkeit, alle Syslog-Meldungen in Echtzeit zu verfolgen und zu filtern. Auch kann er Alarme auf Basis von Schwellenwerten einrichten und sich darüber per E-Mail informieren lassen. Schließlich aggregiert Kiwi die Daten zu Statistiken, die eine Übersicht über das Geschehen im Netz liefern.

Das Werkzeug zur zentralisierten Verwaltung von Syslog-Meldungen und SNMP-Traps läuft ausschließlich unter Windows und erlaubt die Anzeige der gesammelten Daten in bis zu zehn Fenstern. Letzteres ist nützlich, wenn der Admin mehrere Filter parallel auf einen Datensatz anwedet. Der Download erfordert eine Registrierung beim Hersteller.