Einführung
Sicherheitswerkzeuge und Beweisdateien werden unter Benutzeridentitäten ausgeführt beziehungsweise verwaltet. Diese Identitäten zu verstehen hilft dir, die für eine Aufgabe nötigen Berechtigungen zu wählen, ohne jede Datei jedem Konto zugänglich zu machen.
Du erstellst in Kali ein Übungskonto, weist ihm ein privates Fallverzeichnis zu und testest erlaubte sowie verweigerte Zugriffe. Dieses Lab behandelt lokale Benutzer und Dateiberechtigungen; Prozesse und Protokolle folgen in einem eigenen Lab.
Benutzer identifizieren und ein Übungskonto erstellen
In diesem Schritt unterscheidest du die Identität eines normalen Benutzers von Administratorrechten und erstellst ein separates lokales Konto in Kali.
Öffne die vorbereitete Kali-Shell und wähle den gemeinsamen Arbeitsbereich:
kali
cd /home/labex/project
id zeigt deine numerische Benutzer-ID (UID), die primäre Gruppen-ID (GID) und deine Gruppenmitgliedschaften:
id
Der Benutzername ist kali; die numerischen IDs können je nach Umgebung variieren. UID 0 kennzeichnet root, den Administrator. Dein normales Konto hat eine von null verschiedene UID.
sudo führt einen autorisierten Befehl mit höheren Rechten aus. Dieser Übungscontainer erlaubt dem Kali-Lernkonto die Verwendung ohne Passwort. Diese Berechtigung gilt lokal im Container; sie ist kein Grund, jeden Befehl als root auszuführen. Lass root sich für einen Befehl identifizieren:
sudo whoami
Die Ausgabe ist root. Die erhöhten Rechte enden mit diesem Befehl:
whoami
Die Ausgabe ist weiterhin kali.
Ein lokales Konto hat einen Namen, eine UID, eine Gruppe, ein Home-Verzeichnis und eine Login-Shell. useradd erstellt ein Konto und erfordert Administratorrechte. --create-home erstellt sein Home-Verzeichnis, --user-group eine gleichnamige primäre Gruppe und --shell /bin/bash wählt Bash als Shell:
sudo useradd --create-home --user-group --shell /bin/bash practice-analyst
Führe das in einem neuen Lab einmal aus. Eine Meldung über ein bestehendes Konto bedeutet, dass es bereits vorhanden ist. Passwort oder SSH-Zugriff sind für diese Übung unnötig. Prüfe die neue Identität, indem du ihren Namen an id übergibst:
id practice-analyst
Die Ausgabe nennt practice-analyst als Benutzer und primäre Gruppe. Seine UID sollte sich von kali und root unterscheiden.
Eigentümer und private Berechtigungen zuweisen
In diesem Schritt erstellst du ein Fallverzeichnis, überträgst sein Eigentum und beschränkst den Zugriff auf das zugewiesene Konto.
Kehre zum gemeinsamen Arbeitsbereich zurück:
cd /home/labex/project
Erstelle als normaler Benutzer ein Verzeichnis:
mkdir case-files
ls -ld beschreibt das Verzeichnis selbst: -l fordert Details an, während -d verhindert, dass stattdessen sein Inhalt aufgelistet wird:
ls -ld case-files
Die Ausgabe enthält Berechtigungszeichen, einen Eigentümer und eine Gruppe. Anfangs ist kali der Eigentümer. Das erste Zeichen d bedeutet Verzeichnis. Die nächsten neun Stellen bilden drei Gruppen von Bits für Lesen (r), Schreiben (w) und Ausführen (x), jeweils für Eigentümer, Gruppe und andere. Bei einem Verzeichnis erlaubt Lesen das Auflisten von Namen, Schreiben das Ändern von Einträgen und Ausführen den Durchgriff auf Einträge.
chown ändert das Eigentum. Die Form user:group weist Eigentümer und Gruppe zu. Die Übertragung an ein anderes Konto benötigt Administratorrechte:
sudo chown practice-analyst:practice-analyst case-files
chmod ändert Berechtigungen. Numerisch steht Lesen für 4, Schreiben für 2 und Ausführen für 1. Die Summe 7 gewährt alle drei, 0 keine. Modus 700 gibt dem Eigentümer vollen Zugriff und gewährt Gruppe und anderen keinen Verzeichniszugriff:
sudo chmod 700 case-files
ls -ld case-files
Der Anfang sollte drwx------ lauten; Eigentümer und Gruppe sollten practice-analyst sein. Datumsangaben und numerische Größen können abweichen. Das Eigentum bestimmt, welches Konto die Eigentümerberechtigungen erhält; der Modus definiert dann den Zugriff jeder Kategorie.
Zugriff als vorgesehenes Konto testen
In diesem Schritt prüfst du den Zugriff mit echten Benutzeridentitäten, statt dich nur auf die Berechtigungsliste zu verlassen.
sudo -u NAME führt einen Befehl als genannter Benutzer statt als root aus. Erstelle als Falleigentümer eine Datei in dessen privatem Verzeichnis:
sudo -u practice-analyst touch /home/labex/project/case-files/checked.txt
Es wird keine Ausgabe erwartet. Prüfe das Ergebnis als dasselbe Konto:
sudo -u practice-analyst ls -l /home/labex/project/case-files
Die leere Datei checked.txt sollte practice-analyst gehören. Ihre Erstellung beweist, dass dieses Konto das Verzeichnis durchqueren und darin schreiben kann.
Das normale Kali-Konto sollte diesen Zugriff nicht haben. Der nächste Befehl soll mit einer Meldung über verweigerten Zugriff fehlschlagen, um die Beschränkung zu zeigen. Fahre nach dem Fehler fort:
ls /home/labex/project/case-files
Root kann das Verzeichnis weiterhin über einen ausdrücklich autorisierten Befehl prüfen:
sudo ls /home/labex/project/case-files
Du solltest checked.txt sehen. Private Berechtigungen beschränken normale Konten; root behält Administratorrechte. Verwende weiter kali für normale Arbeiten und erhöhe die Rechte nur für den jeweiligen Vorgang, der sie benötigt. Keiner dieser Befehle ändert das Lernkonto auf dem Host oder die Art, wie LabEx sich mit der VM verbindet.
Zusammenfassung
Du hast Benutzeridentitäten geprüft, sudo für bestimmte administrative Aktionen verwendet, ein Konto erstellt und Verzeichniseigentum sowie Berechtigungen zugewiesen. Du hast bestätigt, dass das vorgesehene Konto arbeiten konnte, während einem anderen normalen Konto der Zugriff verweigert wurde.
