Seite wählen

NETWAYS Blog

Windows Passwort mit Linux zurücksetzen

Falls ihr mal euer Windows Passwort vergessen habt, ein Freund euch fragt, Zugriff auf eine Dubiose Festplatte zu erhalten aber das System mit einem User und einem Passwort geschützt ist, dann wird euch das Tool chntpw sicherlich nützlich sein. Mit diesem Tool ist es möglich, über eine Live-Distribution von Linux (Lubuntu, Sabayon Linux, Peppermint OS, Fuduntu, Linux Mint usw.) Informationen der Benutzer zu bearbeiten, löschen oder zurückzusetzen. Ich werde für den Vorgang ein Live-Ubuntu verwenden um euch zu zeigen, wie einfach das ist.

Bootet Ubuntu vom USB-Stick und wählt “Try Ubuntu” aus. Im Desktop angekommen, müssen wir noch eine Einstellung aktivieren um Aktualisierungen der Anwendungen zu erhalten.


Wir setzen einen Haken bei “Von der Ubuntu-Gemeinschaft betreute freie und quelloffenne Programme (universe)”, schließen das Fenster und wählen Neu laden.
Nun gehen wir ins Terminal und aktualisieren.

Loggt euch gleich als root user ein um gewissen Berechtigungen aus dem Weg zu gehen. Mit chntpw ist es nicht möglich, bestehende Passwörter auszulesen.

$ sudo apt update && apt upgrade

Nun installieren wir das Tool chntpw:

$ sudo apt install chntpw

Jetzt suchen wir noch unsere Windows-Partition die wir mounten möchten (Partition auf der unsere Benutzer verwaltet werden).

$ sfdisk -l

Wir können daraus schließen, dass unsere Windows Festplatte als /dev/sda angegeben wird und die Partition die wir suchen /dev/sda2 ist. Um die Partition zu mounten, erstellen wir dazu noch ein Verzeichnis namens /Microsoft. Dann mounten wir unsere Festplatte, und wechseln in das eben erstellte Verzeichnis. Hier können wir die Ordnerstruktur einer Windows-Installation erkennen.

Falls die Partition nicht gemountet werden kann, weil unser Windows den Status “hibernate” besitzt, müssen wir erst in den abgesicherten Modus und von dort aus sauber herunterfahren.

Jetzt wechseln wir in das Verzeichnis Windows//System32/config/ und sehen uns die Einträge der Security Account Manager (SAM) Datenbank an. Uns werden alle Benutzer und deren Gruppe angezeigt in der sie sich befinden, ob ein Passwort gesetzt ist und das Konto eventuell gesperrt wurde.

$ sudo chntpw -l SAM

Nun kommt das Tool chntpw zum Einsatz, indem wir das Kommando $ sudo chntpw -i SAM ausführen. Wir landen im Main Interactive Menu, wo wir nun auswählen was genau wir anstellen möchten.
Edit user data and passwords (1) ist der Reiter den wir brauchen werden um die Benutzerdaten zu ändern.

Wir werden aufgefordert eine RID (Relative ID) einzugeben. Ich habe schon etwas vorbereitet und einen chntpw-Benutzer erstellt, dessen Passwort niemals verfällt und der Gruppe Administratoren angehört.
In meinem Falle ist die RID 3ea.

Uns wird angezeigt, wie viele fehlerhafte Logins wir hatten, wie oft wir uns bereits mit unserem Konto angemeldet haben und unsere Benutzereigentschaften. Das User Edit Menu ploppt weiter unten auf und wir können zwischen 5 Optionen wählen, was wir denn gerne mit unseren credentials anstellen möchten. Ich werde mein vorhandenes Passwort löschen und den Status blank wählen. (Option Nr. 1). Danach landen wir wieder in der Übersicht unserer Benutzerkonten.

Wie man schwer erkennen kann, ist in dem Reiter Lock nun *BLANK* gesetzt und es exisitiert für dieses Konto kein Passwort mehr. Wir verlassen das User Edit Menu mit der Eingabe von “q” und kehren zum Main Interactive Menu zurück, bei dem wir noch einmal “q” eingeben und gefragt werden, ob wir speichern möchten. Selbstverständlich bestätigen wir und speichern unsere Änderungen mit “y”.

Geschafft!
Bei der nächsten Anmeldung mit dem bearbeiteten Konto, werden wir nicht mehr nach einem Passwort gefragt. Wir können nun ein neues Passwort setzen.

 

Aleksander Arsenovic
Aleksander Arsenovic
Junior Consultant

Aleksander macht eine Ausbildung zum Fachinformatiker für Systemintegration in unserem Professional Service. Wenn er nicht bei NETWAYS ist, schraubt er an seinem Desktop-PC rum und übertaktet seine Hardware. Er ist immer für eine gute Konversation zu haben.

Graphite-API für Grafana und Icinga Web 2

Ziel dieses Posts ist es, am Ende die Metriken über die Graphite-API als Backend für Grafana und das Icinga-Web-2-Module graphite betreiben zu können.

Grafana übernimmt hierbei optional die Visualisierung über eigene Dashboards, was ansonsten Graphite-Web leistet. Für Icinga Web 2 ist Grafana nur erforderlich, falls nicht das Module graphite zum Einsatz kommen soll, sondern stattdessen grafana zur Darstellung im Icinga Web 2 verwendet werden sollte.

Die Graphite-API ist in Python implementiert und soll hierbei via HTTPS angesprochen werden. Zusätzlich ist der Zugriff via Basis-Authentifizierung zu beschränken. Dies alles überlassen wir dem Apache, auch die API lassen wir mittels WSGI im Apache laufen.

Der Vorteil gegenüber dem Graphite-Web liegt darin, die ganzen Django-Bibliotheken nicht zu benötigen und auch kein DB-Backend a la SQLite, MySQL oder PostgreSQL. Nachteil ist, das Projekt Graphite-API wird nicht vom Graphite-Team betrieben, somit ist die Pflege und Aktualität nicht sichergestellt.
mehr lesen…

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

TLS: Eine kleine Übersicht

Der durschnittliche Internetbenutzer benutzt TLS (Transport Layer Security) mittlerweile auf fast allen größeren Websiten – ohne, dass sich dieser darüber bewusst wäre, in den allermeisten Fällen. Auch in meiner Ausbildung bei NETWAYS darf ich mich nun intensiv mit TLS beschäftigen. Doch was ist TLS? Dieser Text soll einen groben Umriss um die zugrunde liegenden Prinzipien und Techniken hinter TLS legen.

Warum brauchen wir TLS?

TLS wird benötigt, um drei Probleme zu lösen. Unsere Kommunikationen sollen verschlüsselt sein – wir wollen nicht, dass Pakete oder Informationen, die wir übertragen, abgehört werden. Außerdem wollen wir sicher gehen, dass der andere Teilnehmer dieser Kommunikation auch derjenige ist, mit dem wir diesen Austausch an Informationen vollziehen wollen. Darüber hinaus wäre es auch gut, sich darauf verlassen zu können, dass das, was von der einen Seite losgeschickt wurde, auch das ist, was der andere erhält. Um diese drei Probleme kümmert sich TLS. Doch wie macht es das?

Eine Beispielverbindung:

1. ClientHello

Ein Client verbindet sich mit einem Server und verlangt eine gesichertete Verbindung. Dazu wird die Version von TLS übertragen, und eine Chiffrensammlung, aus denen sich der Server die Verschlüsselungsmethode aussuchen kann.

2. ServerHello & Certificate & ServerKeyExchange

Der Server antwortet, welches Chiffre verwendet werden soll, und einem Zertifikat, welches den Server authentifizieren soll und einen öffentlichen Schlüssel enthält.

3. ClientKeyExchange

Dieses Zertifikat wird von dem Client verifiziert, und der öffentliche Schlüssel des Servers wird vom Client benutzt, um ein pre-master secret zu erstellen, welcher dann wieder an den Server geschickt wird.

Der Server entschlüsselt das pre-master secret, und beide Parteien nutzen es, um einen geheimen, geteilten Schlüssel zu erstellen, welcher als shared secret bezeichnet wird.

4. ChangeCipherSpec

Der Client versendet die erste, mit dem shared secret verschlüsselte Nachricht, welche der Server entschlüsseln soll, damit geprüft werden kann, ob die Verschlüsselung richtig initialisiert wurde. Wenn diese Verifizierung erfolgreich abgelaufen ist, kommunizieren dann der Client und der Server verschlüsselt untereinander. Dieser ganze Prozess wird als TLS-Handshake bezeichnet.



Geschichte: TLS wurde unter dem Vorläufernamen SSL (Secure Sockets Layer) in 1994 von Netscape für den damals sehr populären Browser Mosaic vorgestellt. Version 2.0 und 3.0 folgten jeweils ein Jahr später. 1999 wurde SSL 3.1 bei der Aufnahme als Standart von der Internet Engineering Task Force in TLS 1.0 umbenannt. 2006 folgte Version 1.1, 2008 1.2 und 2018 die heutige Version 1.3.


Asymmetrische & Symmetrische Verschlüsselung: TLS ist zunächst asymmetrisch, dann symmetrisch verschlüsselt. Was bedeutet das? Nun, hier kommen die Schlüsselpaare ins Spiel. TLS benötigt einen öffentlichen und einen privaten Schlüssel. Der öffentliche Schlüssel wird benutzt, damit der Gegenpart einen Vorschlüssel erstellen kann, welcher dann von dem privaten Schlüssel wieder decodiert wird. Das ist eine asymmetrische Verschlüsselung – welche allerdings deutlich kostenintensiver und aufwändiger ist, und sich dementsprechend nicht für die zahlreichen Anwendungsmöglichkeiten für eine TLS-Verbindung eignet. Dank’ dem Vorschlüssel können allerdings beide Seiten des Austausches einen gemeinsamen, geheimen Schlüssel berechnen, mit Hilfe dessen die verschlüsselten Nachrichten auf jeweils beiden Seiten entschlüsselt werden können. Somit ist der Kern von TLS eine symmetrische Verschlüsselung; der Austausch der tatsächlichen Information passiert über diesen Kanal. Um aber an diesen Punkt zu kommen, sind asymmetrische Verschlüsselungsprinzipien im Einsatz.


Zertifikate: Wie in dem TLS-Handshake betrachtet, sind Zertifkate elementar zur Ausweisung und Identifikation von Server und Client – und wohl der kritischste Punkt in dem ganzen TLS-Ablauf. Damit ein Kommunikationspartner identifiziert werden kann, muss er sein Zertifikat ausweisen, welches seine Identiät beweist. Ausgestellt wird ein Zertifikat von einer certificate authority, einem vertrauenswürdigen Aussteller dieser Zertifikate, was verschiedenste Dinge bedeuten kann: Viele multinationale Konzerne stellen kommerziell Zertifikate aus, darunter fallen Firmen wie IdenTrust, Sectigo und DigiCert Group. Es existieren allerdings auch einige non-profit organisations, wie CAcert und Let’s Encrypt, die als Zertifizierungsstelle auftreten. Darüber hinaus gibt es natürlich auch jede Menge Zertifikatsaussteller innerhalb von Netzen, welche in der Hand von einem vertrauenswürdigen Admin liegen.


Chiffrensammlung: Eine Chiffrensammlung ist eine Auflistung aus den Verschlüsselungsmethoden, die bei einer TLS-Verbindung eingesetzt werden können. Beispiele dafür wären RSA, MD5, SHA. Bei einer TLC-Verbindung wird in ClientHello und ServerHello unter den beiden beteiligten Parteien kommuniziert, welche dieser Methoden zur Verfügung für den Aufbau der Verbindung stehen.


https: Doch was hat es nun mit https auf sich? Ganz einfach: https (HyperText Transfer Protocol Secure) ist eine Extension von http, bei der http über eine verschlüsselte TLS-Verbindung versendet wird, was sie im Gegensatz zu Klartext-http vor unerwünschten Abschnorchelungen und sonstigen Attacken schützt.


Verbreitung: Laut der regelmäßig auf einen neuen Stand gebrachten Auswertung von SSL Labs von rund 140.000 Webpages bieten gerade mal 67.2% eine adequate TLS-Ausstattung. Das mag im ersten Moment etwas niedrig erscheinen, man darf aber auch nicht vergessen, dass diese Lage vor nicht allzu langer Zeit noch deutlich, deutlich schlimmer war, und durch Maßnahmen wie einer automatischen Warnung von Chrome verbessert wurde. So hat sich auch laut Firefox Telemetry die Anzahl der per https aufgerufenen Websiten sich von 25% auf 75% erhöht. Ebenso bemerkenswert: Einem Jahr nach Einführung von TLS 1.3 unterstützen gerade mal 15% den aktuellen Standart, der absolut überwiegende Teil bietet noch hauptsächlich TLS 1.2 an. Man darf gespannt sein, wie lange es dauert, bis der Großteil den Wechsel vollzogen hat. Auf der anderen Seite bieten 7.5% der Webpages noch Unterstüztung für SSL 3.0 an, einem Standart, der mittlerweile fast so alt ist wie ich selbst, und als nicht sicher gilt.

 

 

 

Henrik Triem
Henrik Triem
Junior Developer

Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.

SSL/TLS Zertifikate für die Nutzung im internen Netz (apache)

Um verschiedene Dienste im LAN sicher zu nutzen, werden SSL-Zertifikate benötigt. Wir verwenden dafür in manchen Fällen ein selbstsigniertes Zertifikat. Das SSL-Zertifikat enthält Informationen über den Namen des Inhabers, den öffentlichen Schlüssel, eine Gültigkeitsdauer und gegebenenfalls den Namen der Zertifizierungsstelle. Mit dem öffentlichen Schlüssel kann das Zertifikat der Zertifizierungsstelle überprüft werden.

Das SSL-Zertifikat muss zuerst als vertrauenswürdig eingestuft werden, dazu sind bestimmte Rangordnungen der Autoritäten notwendig. Der Browser verfügt über Listen mit Zertifizierungsstellen deren SSL-Zertifikate bedingungslos vertraut werden. Beim Aufrufen einer SSL-verschlüsselten Website, prüft der Browser das Zertifikat auf Gültigkeit der Referenzen und des Herausgebers der Webadresse. Kennt der PC oder Browser den Herausgeber des Zertifikates nicht, meldet er einen Zertifikatsfehler. Diesen Fehler kann man übergehen und seinen Besuch auf der Website fortsetzen.

Selbstsignierte Zertifikate geben diesen Fehler logischerweise immer, da sie nicht von einer Zertifizierungsstelle als gültig und sicher geprüft wurden. Hier signiert der Server selbst für seine Dienste, die von den jeweiligen Clients besucht werden.

Ich zeige euch, wie wir das Zertifikat erstellen und manuell in den Firefox-Browser hinterlegen.

Zuerst müssen wir einen Private-Key erstellen, der immer bei uns verbleibt. Niemand außer uns sollte Zugriff auf diese Datei haben, da der Private-Key später untrennbar von unserem Zertifikat ist. Dazu wechseln wir in das Verzeichnis, indem wir den Schlüssel gerne haben wollen:

openssl genrsa -aes256 -out ca-key.pem 2048

Mit dem Argument -aes256 (Abkürzung für „Advanced Encryption Standard“) verschlüsseln wir unsere Datei mit einer 256Bit Schlüssellänge. Der Key muss eine Länge von 2048bit haben und in unserem Beispiel nenne ich ihn ca-key.pem (nehmt einen Namen, den ihr später leicht eurer Seite hinzufügen könnt). Das pass phrase muss mindestens 4 Zeichen lang sein und darf keine Sonderzeichen enthalten.

Nun kommt die CA-Datei, die die Antragsdaten sowie den öffentlichen Schlüssel zu unserem Private-Key enthält:

openssl req -x509 -new -nodes -extensions v3_ca -key ca-key.pem -days 1024 -out ca-root.pem -sha512

Benennt eure Dateien wieder mit einem beliebigen Namen. Ich nutze hier einige Argumente: -nodes (noDES) encrypted den Private-Key nicht, -x509 gibt das Certificate Data Management an, dass uns dann auch zu -extensions v3-ca führt. Hier wird eine Cryptographie erstellt und es werden Erweiterungen für policies verwendet.

Bei der Erstellung der CA werdet ihr nach einigen Details gefragt, die ihr angeben könnt um das Zertifikat eindeutig zu machen (oder aus Testzwecken einfach leer lassen).

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:

Wir brauchen jetzt noch einen Zertifikats-Key…

openssl genrsa -out zertifikat-key.pem 4096

…erstellen dann unsere CSR-Datei…

openssl req -new -key zertifikat-key.pem -out zertifikat.csr -sha512

…und signieren sie mit unserem eben erstellten Key.

openssl x509 -req -in zertifikat.csr -CA ca-root.pem -CAkey ca-key.pem -CAcreateserial -out zertifikat-pub.pem -days 365 -sha512

Gleiche Vorgehensweise wie zuvor beschrieben, pass phrase eingeben und bei belieben eure Details noch eintragen.

Wir sind fertig!

Jetzt bindet ihr das Zertifikat nur noch in euren Browser mit ein, in meinem Falle nutze ich den Firefox-Browser. Öffnet die Einstellungen und geht auf den linken Reiter “Datenschutz & Sicherheit”. Nun scrollt ihr ganz nach unten bis ihr die Option “Zertifikate” seht. Klickt auf den Button “Zertifikate anzeigen…”, dort öffnet sich ein neues Fenster in dem ihr nun euer erstelltes Zertifikat einpflegen könnt.

Der Browser muss nun geschlossen werden um die Veränderungen anzunehmen. Startet ihn neu und verbindet euch mit eurer Website. Nun müsstet ihr sehen können, dass ein https:// angezeigt wird.

Aleksander Arsenovic
Aleksander Arsenovic
Junior Consultant

Aleksander macht eine Ausbildung zum Fachinformatiker für Systemintegration in unserem Professional Service. Wenn er nicht bei NETWAYS ist, schraubt er an seinem Desktop-PC rum und übertaktet seine Hardware. Er ist immer für eine gute Konversation zu haben.

Aufmerksamkeit – ein super Mittel gegen schädliche Emails

Vor etwa einem halben Jahr stand der Autor im Kontakt mit einer lokalen Metzgerei im Vorwahlbereich 0911. Es ging um leckere Weißwürste mit ebenso leckeren Brezen.

Diese wurden geliefert und NETWAYS-typisch mit vollem Einsatz verzehrt.

Wir nehmen an, es wäre Mittwoch, 20.02.19, 09:19. Emaileingang am persönlichen Postfach:

Erstmal verblüffend:

a) Ich hatte keine Rechnungskopie angefordert.

b) Der Absender hat nichts mit der Metzgerei meines Vertrauens zu tun – die zensierte Emailadresse in der Signatur wäre allerdings korrekt.

c) Die Vorwahl in der Signatur zeigt ins Nirvana

Nun gut, aber man will ja ein verlässlicher Geschäftspartner sein, eventuell liegt es ja nur am “von meinem Samsung gesendet”?

Also klicken wir fröhlich den Link und landen auf einer Seite aus Beheshti Avenue,Tehra,1577837414,Iran??

Außerdem wird eine .doc-Datei angeboten. Auch die kleinste Metzgerei hat es mittlerweile hinbekommen, Rechnungen per pdf zu verschicken.

Aber gut, schauen wir doch mal, was LibreOffice damit so anfängt:

Hier habe ich dann das Experiment abgebrochen.

Es waren zuvor schon viele “Red Flags”, die einen aufmerksamen Emailbenutzer stutzig machen sollten.

Und im Zweifelsfall kann man seinen Geschäftskontakt auch schlicht anrufen, wenn man denn auf Nummer Sicher gehen will.

Wer sich weitere Beispiele anschauen möchte, kann bspw. hier klicken.

edit (TA): typos

Tim Albert
Tim Albert
Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere...

Veranstaltungen

Mi 21

Icinga 2 Advanced Training | Online

April 20 @ 09:00 - April 22 @ 17:00
Mi 21

InfluxDB & Grafana | Online

April 20 @ 09:00 - April 21 @ 17:00
Di 27

Elastic Stack Training | Online

April 27 @ 09:00 - April 29 @ 17:00
Di 27

Graylog Training | Online

April 27 @ 09:00 - April 28 @ 17:00
Mai 04

GitLab Fundamentals Training | Online

Mai 4 @ 09:00 - Mai 5 @ 17:00