Kategorie: Infrastruktur

Veröffentlicht am

Passwort Richtline bei VMware Linux Appliances einstellen

Über den Sinn von regelmäßigen Passwortwechseln lässt sich lange streiten. Der Zwang, alle x Tage ein neues Kennwort zu vergeben, welches sich vom vorherigen stark unterscheiden muss, halte ich für kontraproduktiv. Aber das ist ein anderes Thema.

Das Szenari, über das ich sprechen möchte, sieht folgendermaßen aus: eine nicht produktive Labor-Umgebung, bei der immer genau dann das Passwort abgelaufen ist, wenn man gerade wichtigeres zu tun hat. Die Appliance xy zeigt mir den virtellen Mittelfinger und nötigt mich zur Eingabe eines neuen Passwortes, das mindestens 5 klingonische Sonderzeichen enthalten muss. Grrr! Dies ist ein nicht-produktives Lab und ich verwende für alle – ja, alle – Dienste und Logins das gleiche Passwort. Es geht um Machbarkeit – nicht Sicherheit.

Bevor das jetzt jemand falsch versteht: 
Ja, im Live-Betrieb wäre das eine sehr dumme Idee.

Password Expiration

Der erste Schritt ist, die Ablaufzeit des Kennworts auf Null (Achtung! nicht bei VCF!) oder einen sehr langen Zeitraum zu setzen. Standardmäßig setze ich hier 9000 Tage ein. Das sind umgerechnet etwa 24 Jahre und 7 Monate. Das sollte reichen 😉

Oftmals lässt sich dieser Wert nicht in der GUI konfigurieren. Dann ist ist die CLI gefragt. Die Einstellung verbirgt sich bei den meisten Linux Varianten in einer Konfigurationsdatei namens login.defs. Wir können auf der shell eine schnelle Abfrage machen.

cat /etc/login.defs | grep PASS

PASS_MAX_DAYS 90
PASS_MIN_DAYS 0
PASS_MIN_LEN 8
PASS_WARN_AGE 7

Voila! PASS_MAX_DAYS ist unsere Passwort Ablaufzeit.

Zur Veränderung müssen wir den vi verwenden, da nur selten andere Editoren in diesen Systemen verfügbar sind. Aber keine Angst vor vi. De ist eigentlich ganz nett. 🙂 Wir öffnen die Konfiguration mit:

vi /etc/login.defs

Jetzt Ruhe bewahren und nur die Taste i (für insert) drücken. Jetzt suchen wir in der Datei die Zeile mit PASS_MAX_DAYS und ändern den Wert auf beispielsweise 9000. Wer möchte, kann auch das Mindestalter PASS_MIN_DAYS auf 0 setzen. Damit kann das Passwort ohne Wartezeit erneut gewechselt werden.

Um unsere Änderung zu speichern drücken wir die ESC-Taste und danach die Taste mit dem Doppelpunkt. Unten links erscheint ein Doppelpunkt und zeigt, dass wir im Command-Modus sind. Wir geben die Zeichen wq (write, quit) und drücken Enter.

Sonderfall NSX-T mit VCF

Die Ablaufzeit der vordenfinierten Konten admin, root und audit unter NSX-T werden auf der Shell des NSX-Mangers mit einem eigenen Kommando gesetzt. Dazu verbindet man sich per SSH mit der Virtual-IP (VIP) des Management Clusters und wird zum aktuellen Master-Knoten weitergeleitet.

Um die Ablaufzeit der drei Konten auf 9000 Tage festzulegen, gibt man folgende drei Befehle ein:

set user admin password-expiration 9000
set user root password-expiration 9000
set user audit password-expiration 9000

In NSX-T Umgebungen ohne VCF dürfen die Ablaufzeiten der Passwörter ganz deaktiviert werden.

Achtung! bei NSX-T in Verbindung mit VCF führt dies aber zu Problemen beim Upgrade. Der Vollständigkeit halber hier die Befehle zur Deaktivierung:

clear user admin password-expiration
clear user root password-expiration
clear user audit password-expiration

Kontrolle

Die Ablaufzeit in NSX-T kann mit folgenden Kommandos abgefragt werden:

get user admin password-expiration
get user root password-expiration
get user audit password-expiration

Passwort History

Normalerweise reichen die obigen Änderungen aus. Wenn wir aber das Ablaufdatum verpasst haben und beim Login ein neues Passwort setzen mussten, dann können wir nicht wieder auf unser altes Passwort zurück wechseln. Das System merkt sich eine definierte Anzahl vergangener Passworte und erlaubt hier kein Recycling. Aber auch das können wir ändern. In vielen Linux Varianten gibt es dafür den daemon für pluggable authentication modules (pam.d). Die Konfiguration liegt unter /etc/pam.d/common-password. Systeme mit root Zugang können statt dessen auch die Konfiguration in /etc/pam.d/system-password haben.

vi /etc/pam.d/system-password

Hier setze ich den Wert remember=0. Damit kann das Wunschpasswort sofort neu gesetzt werden. Als root User genügt auf der shell das Kommando:

passwd

Veröffentlicht am

ExaGrid Time-Lock – Keine Angst vor Ransomware

Einleitung

Ransomware stellt aktuell eine der herausragenden Bedrohungen für IT Infrastrukturen dar. Berichte über erfolgreiche Angriffe häufen sich, die Einschläge kommen näher. Über 30% aller Unternehmen, Institute, Universitäten oder Behörden in Deutschland hatten bereits mit derartigen Attacken zu tun. Zum Teil wurde ein Lösegeld bezahlt, um wieder an die eigenen Daten zu gelangen.

Selbst bei Zahlung ist der Erfolg niemals sicher. Schließlich verhandelt man mit Verbrechern. Die Behörden raten daher von der Zahlung ab.

Die wesentliche Schutzmaßnahme gegen die Folgen einer solchen Attacke ist ein aktuelles und konsistentes Backup.

Ransomware vs. Backup

Leider wissen auch die Angreifer um die Wichtigkeit der Backups. Die aktuell kursierenden Schädlinge, wie z.B. Emotet oder Ryuk, enthalten Code der aktiv nach Datensicherungen im Netz fahndet. Mit vorher erlangten Zugangsdaten für Active Directory Konten oder durch Attacken auf z.B. RDP Lücken oder die brandaktuelle Zerologon Lücke wird versucht die Systeme zu übernehmen, welche die Datensicherung im Unternehmen betreiben bzw. die Backupdaten halten.

Oftmals folgen der automatischen Attacke sogar Hacker aus Fleisch und Blut, die sich aktiv im Netz umsehen und versuchen alle Backups zu zerstören. Ein vielfach leiches Unterfangen, da Backups heute vorzugsweise auf Festplattensystemen permanent mit der Infrastruktur verbunden sind.

Der Grund liegt auf der Hand: Sind alle Backups gelöscht oder ebenfalls verschlüsselt, steigt die Compliance des „Kunden“ zur Zahlung eines Lösegeldes massiv.

Viele Ansätze wurden daher schon erdacht, die Backupdaten sicher im Netz abzulegen. Eine sehr einfache und sichere Variante ist ein Air-Gap – also eine echte Trennung der Backupmedien vom System. Beispielsweise können LTO Tapes physisch aus der Library entnommen werden.

Ohne eine solche aufwändige manuelle Entnahme – die zudem täglich erfolgen müsste – bleiben die Daten latent verwundbar. Ganz egal, ob sie auf Plattensystemen, Dedup-Appliances, Tapes in einer Library oder sogar in einem S3 Cloud Repository liegen.

S3 Cloud Anbieter haben daher schon vor einiger Zeit eine API Erweiterung mit dem Namen „Object Lock“ vorgeschlagen. Hiermit können zumindest die Backups im Cloud Layer eine gewisse Zeit immun gegen Änderungen gemacht werden.

Einige dieser Lösungen werden inzwischen nativ von Veeam unterstützt. Amazon AWS gehört z.B. dazu. Microsoft Azure fehlt z.B. aktuell noch. Außerdem ist S3 Speicher nicht für jeden Anwendungsfall geeignet. Ein Primärbackup mit Veeam auf S3 ist z.B. nicht direkt möglich. Der S3 Layer ist ausschließlich als Erweiterung eines Scale-Out-Backup Repositories verfügbar.

„ExaGrid Time-Lock – Keine Angst vor Ransomware“ weiterlesen
Veröffentlicht am

Veeam Storage Plugin für DataCore – Deepdive

SANsymphony trifft Veeam Backup and Replication – Ende gut, alles gut!

(der folgende Artikel wurde automatisch aus dem englischen Original übersetzt)

Fragen, Ergänzungen oder Anmerkungen zu diesem Artikel: melter[at]idicos.de

Seit Dezember 2019 ist das Plugin für den populären DataCore SANsymphony SDS veröffentlicht. Realisiert wurde es auf die einzig richtige Art und Weise: Mit voller Unterstützung und Validierung durch Veeam.

In dieser Artikelserie werden wir verschiedene Aspekte des Plugins behandeln:

„Veeam Storage Plugin für DataCore – Deepdive“ weiterlesen
Seiten: 1 2 3 4 5 6
Veröffentlicht am

Storage Praxis – Das Synchronspiegel Dilemma

Eine kleine Einführung in die Hochverfügbarkeit

Datenbestände an zwei Orten identisch zu halten, wird in der hochverfügbaren IT immer wichtiger. War dies noch vor einigen Jahren ein sehr teurer Luxus für das Enterprise Segment, so dringt diese Anforderung in den letzten Jahren immer weiter in den SMB Bereich vor. Diese Methode nennt man Spiegel und sie kann prinzipiell auf zwei Arten umgesetzt werden:

  • asynchron – Der Datenabgleich erfolgt in definierten Intervallen. Dazwischen herrscht eine Differenz zwischen Quelle und Ziel.
  • synchron – Der Abgleich erfolgt transaktionsgenau, sodaß der Datenbestand zu jedem Zeitpunkt auf beiden Seiten identisch ist. Ein Schreibvorgang gilt erst als abgeschlossen, wenn auch Spiegelziel den Schreibvorgang bestätigt hat.

Eine Voraussetzung für Hochverfügbarkeit ist die Spiegelung der Daten (synchron, oder asynchron). Sind die Daten an zwei Orten (Rechenzentren) vorhanden stellt sich eine weitere Designfrage: Soll das Speicherziel als Kopie für den Notfall fungieren (Active-Passive), oder soll an beiden Orten aktiv mit den Daten gearbeitet werden (Active-Active)?

  • Active-Passive – In diesem Fall wird nur auf der aktiven Seite gearbeitet und die Daten auf die passive Seite übertragen (synchron oder asynchron). im Fehlerfall wird automatisch oder manuell (je nach Modell) umgeschaltet und die vorher passive Seite wird zur aktiven Seite. Sie bleibt dies, bis eine erneute Umkehr ausgelöst wird (Failback). Der Vorteil dieses Verfahrens ist, dass auch im Fehlerfall konstante Leistung garantiert werden kann. Die Ausstattung der passiven Seite muss natürlich identisch mit der aktiven sein. Der Nachteil besteht darin, dass nur maximal 50% der Ressourcen genutzt werden. Die anderen 50% stehen für den Fehlerfall bereit.
  • Active-Active – Hier werden die Ressourcen beider Seiten parallel genutzt und die Hardware kann somit effizienter eingesetzt werden. Dies bedingt aber, dass im Fehlerfall die Hälfte der Ressourcen wegfällt und somit nicht die volle Leistung garantiert werden kann. Active-Active Designs erfordern einen Synchronspiegel, da beide Seiten mit identischen Daten arbeiten müssen.

Active-Active Cluster gibt es in vielfacher Ausprägung. Es gibt klassischen SAN-Storage mit integrierter Spiegelfunktion, oder Software-defined-Storage (sds) bei der die Spiegelung nicht in Hardware, sondern in der Software-Schicht erfolgt. Ein Beispiel dafür ist DataCore SANsymphony. Eine Sonderrolle nimmt hier der VMware vSAN Stretched Cluster ein, der aber nicht Gegenstand dieser Betrachtung sein wird.

Ich werde im folgenden Abschnitt auf eine Besonderheit von LUN basierten active-active Konstrukten eingehen, die leider oft übersehen wird, aber im Fehlerfall zu Datenverlust führen kann. VMware vSAN ist hiervon nicht betroffen, da dessen Stretched Cluster auf einem grundlegend anderen Verfahren beruht.

„Storage Praxis – Das Synchronspiegel Dilemma“ weiterlesen