Netzwerkverbindungen und Netzwerk Statistik auf Linux mit netstat in Echtzeit verfolgen
Netstat – abgeleitet von Netzwerk Statistik, ist ein Befehlszeilen-Dienstprogramm, das von Systemadministratoren zum Analysieren von Netzwerkstatistiken verwendet wird. Es zeigt eine ganze Reihe von Statistiken an, wie beispielsweise offene Ports und entsprechende Adressen auf dem Hostsystem, Routing-Tabelle und maskierte Verbindungen.
Dieser Artikel beleuchtet, wie mithilfe von „netstat“ und „ss“ aktuelle Netzwerk Statistik und die Verbindungen auf einem Linux Hostsystem für Analysen in nahezu Echtzeit verfolgt werden können.
net-tools installieren
Auf vielen modernen Linux Distributionen wird netstat durch das neue Dienstprogramm ss ersetzt, falls es nicht vorinstalliert ist, kann netstat nachträglich installiert werden. Das Paket das netstat enthält ist net-tools.
Der netstat-Befehl wird mit Filter bearbeitet, so das nur die Remote Adressen ausgegeben werden. Mit dem watch-Befehl wird netstat in Intervalle kontinuierlich ausgeführt. Die Ausgabe mit netstat zeigt die aktuelle https Netzwerk Statistik auf einem Webserver in Echtzeit.
Grundsätzlich ist die Intervall Überprüfung mit jedem Dienst möglich, beliebige Ports und Intervallzeiten in Sekunden können gewählt werden.
IPv6 Netzwerk Verbindungen verfolgen
Mit dem neuen Befehlszeilen-Dienstprogramm, mit dem ss-Befehl können Netzwerk Statistik und Verbindungen ebenfalls in Echtzeit verfolgt werden. Grundsätzlich fragt es den Kernel direkt ab und kann schneller antworten als netstat.
Hier werden die Filter tail und cut nicht mehr eingesetzt, da das ss-Dienstprogramm über eigene Filter Operatoren verfügt.
Es werden die Verbindungen für IPv4 so wie für IPv6 ausgegeben, jeweils mit IPv4-als-IPv6-Adresse und dem peer Source Port.
Netzwerk Statistik mit ss und multitail verfolgen
Unter Verwendung von multitail gibt es weitere Anwendungsmöglichkeiten. So können mehrere Befehle in Fenstern aufgeteilt werden, um die Netzwerk Statistik gleichzeitig zu verfolgen, wie es das Beispiel mit multitail zeigt.
Die Ausgabe zeigt das apache.log mit Netzwerk Statistik in Echtzeit mit den Verbindungen auf einem Debian Webserver ohne netstat. Wobei multitail in zwei Fenster horizontal gesplittet wird, -R 3 gibt das Intervall von 3 Sekunden vor, -l für das externe Kommando, hier „ss -nH“ mit Header Unterdrückung. Das Befehlszeilen-Tool kann mit „apt install multitail“ bereitgestellt werden.
Windows Terminal: Netzwerk Statistik in multitail verfolgen
Hinweis: Multitail bereitstellen mit sudo apt install multitail
Fazit
Der Artikel beleuchtet, wie das Dienstprogramm netstat verwendet werden kann, um mittels watch – der netstat-Befehl regelmäßig ausgeführt wird. Um die aktuelle Netzwerk Statistik und die Verbindungen zu Services in Echtzeit zu verfolgen. Mit dem Hinweis, dass „netstat“ veraltet ist und stattdessen das „ss“ Utility seinen Platz eingenommen hat. Es wird so sein, dass das „ältere“ netstat sowohl durch ss- als auch durch ip-Befehle ersetzt wird.
Der ähnliche Beitrag hier könnte dich auch interessieren.
SSH-Server mit Zwei-Faktor-Authentifizierung (2FA) auf Debian einrichten
Die Zwei-Faktor-Authentifizierung für den SSH Login bietet eine zusätzliche Sicherheitsebene. Bei der Zwei-Faktor-Authentifizierung wird zum Systembenutzerkennwort ein weiteres Kennwort erforderlich, ein PIN oder das sogenannte One-Time-Password (OTP), ein sechsstelliger Code der auf einem Mobilgerät angezeigt wird. Dadurch wird eine stärkere Authentifizierungsmethode für den Zugang zum Server erreicht.
In diesem Tutorial wird gezeigt, wie der SSH-Server mit Zwei-Faktor-Authentifizierung (2FA) abgesichert wird, für SSH Schlüsselbasierte Authentifizierung bei der SSH Keys verwendet werden.
Systemvoraussetzung
Debian 10 (buster), Ubuntu 20.04 (Focal Fossa), Linux Mint 20
Ein sudo privilegierter User Account mit $home Verzeichnis
Wichtig! es wird empfohlen, sich während der Konfiguration der Authentifizierungseinstellungen eine zweite Terminalsitzung offen zu halten. Auf diese Weise wird man vom System nicht ausgesperrt, wenn die Verbindung beim Testen getrennt wird, weil etwa die Konfiguration noch nicht vollständig ist.
Im weiteren Verlauf werden wir nicht mehr root sein, sondern als Voraussetzung im Rahmen dieses Tutorials weiter nur noch sudo verwenden. Bei Debian muss möglicherweise das sudo Paket erst installiert werden.
Falls sudo nicht vorliegt, wird das sudo Paket als root installiert.
$ su -
Password:
apt install sudo
Jetzt unserem Benutzer „john“ die sudo-Berechtigungen erteilen.
$ usermod -aG sudo john
Google Authenticator PAM-Modul Installation
Um den SSH-Server für die Zwei-Faktor-Authentifizierung einzurichten, wird das Google Authenticator PAM-Modul auf dem Debian System installiert. Wir sind als nicht-root, mit john eingeloggt dieser nun Mitglied der Gruppe sudo ist.
$ sudo apt install -y libpam-google-authenticator
Führe nach der Installation des Google Authenticator den folgenden Befehl aus.
$ google-authenticator
Während der Ausführung müssen einige Fragen wie unten gezeigt beantwortet werden.
$ Do you want authentication tokens to be time-based (y/n) y
Warning: pasting the following URL into your browser exposes the OTP secret to Google:
https://www.google.com/chart?XYZl=otpauth://totp/root@debian%3Fsecret%34YNE6ZI3XCLUQLBD862UR6NAL2A%36ixxuer%3Ddebian
Drücke y und die Enter Taste um fortzufahren. Im folgenden wird im Terminal ein QR-Code angezeigt werden.
Öffne als nächstes die Google Authenticator App auf dem Handy und scanne den QR-Code im Terminal, mit dem + unten rechts. Alternativ kann man über den Link oben den QR-Sicherheitscode im Browser öffnen.
Sobald der QR-Code gescannt ist, erscheint auf dem Handy das sechsstellige Einmalpasswort. Es dauert 30 Sekunden bis der Token ändert, mit diesem wir uns später per SSH beim Debian Server anmelden.
In der Ausgabe oben ist auch der geheime TOTP Schlüssel, den Bestätigungscode und die Notrufcodes zu sehen. Es wird empfohlen, diese für die spätere Verwendung an einem sicheren Ort aufzubewahren.
Beantworte als nächstes alle Fragen mit y um die Google Authenticator-Konfigurationsdatei wie unten gezeigt zu aktualisieren.
Do you want me to update your "/home/john/.google_authenticator" file? (y/n) y
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) y
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y
Die Datei .google_authenticator im $home Verzeichnis ist für die 2FA Authentifizierung erforderlich, fehlt die Datei wird die 2FA Authentifizierung ignoriert und die Token Eingabe wird übersprungen.
SSH für die Verwendung von Google Authenticator Konfigurieren
Als nächstes muss der SSH-Server für die Verwendung von Google Authenticator konfiguriert werden, in dem wir sshd_config bearbeiten.
$ sudo vi /etc/ssh/sshd_config
Für die 2FA Authentifizierung werden folgende Zeilen benötigt.
Die geänderte SSH-Dienst Konfiguration übernehmen.
$ sudo systemctl restart sshd
SSH Schlüsselbasierte Authentifizierung
Insbesondere Linux-Systemadministratoren sollten statt Passwörter SSH-Keys als Authentifizierungsmethode verwenden, wie es in obiger sshd_config konfiguriert ist. Eine Anleitung für die SSH-Public-Key-Authentifizierung gibt es hier. In unserem Beispiel soll der User john sich mit SSH-Key und 2FA anmelden.
Als nächstes müssen die PAM-Regeln für den SSH-Dienst in der Datei /etc/pam.d/sshd definiert werden.
$ sudo vi /etc/pam.d/sshd
Die Zeile @include common-auth mit # auskommentieren und nachfolgend zwei PAM-Regeln hinzufügen.
Das Wort nullok am Ende der Zeile teilt PAM mit, dass diese Authentifizierungsmethode optional ist. Dadurch können sich Benutzer ohne OATH-TOTP-Token weiterhin mit nur dem SSH-Key anmelden. Sobald alle Benutzer über ein OATH-TOTP-Token verfügen, kann man nullok aus dieser Zeile entfernen, um 2FA obligatorisch zu machen. Die zweite Zeile mit pam_permit.so ist erforderlich, um die Authentifizierung zu ermöglichen, auch wenn ein Benutzer kein 2FA-Token verwendet.
Bei der Anmeldung benötigt jede Methode ein SUCCESS, um die Authentifizierung zu ermöglichen. Wenn ein Benutzer das 2FA-Authentifizierungstool nicht verwendet, gibt die Verwendung der Option nullok ein IGNORE für die interaktive Tastaturauthentifizierung zurück. pam_permit.so gibt dann SUCCESS zurück und ermöglicht die Fortsetzung der Authentifizierung.
SSH Login mit Zwei-Faktor-Authentifizierung Testen
Der SSH-Server ist jetzt mit Zwei-Faktor-Authentifizierung konfiguriert, damit ist nun die Gelegenheit gekommen es mit john zu testen.
$ ssh -v john@10.0.0.7
...
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\john/.ssh/debian ECDSA SHA256:cxoaQ9ccAAqS563BnOnFf2Ru6I3dc5uAeblO/8ua5Md explicit
debug1: Server accepts key: C:\\Users\\john/.ssh/debian ECDSA SHA256:cxoaQ9ccAAqS563BnOnFf2Ru6I3dc5uAeblO/8ua5Md explicit
Authenticated with partial success.
debug1: Authentications that can continue: keyboard-interactive
Verification code:
Troubleshooting
Gibt es Fehler bei der Authentifizierung mit 2FA, kann für des PAM-Modul die debug Funktion aktiviert werden.
Mit debug werden Fehler in der Authentifizierung rasch erkannt.
Oct 22 17:59:32 debian sshd(pam_google_authenticator)[3938]: debug: shared secret in "/home/john/.google_authenticator" processed
Oct 22 17:59:32 debian sshd(pam_google_authenticator)[3938]: Invalid verification code for john
Oct 22 17:59:32 debian sshd(pam_google_authenticator)[3938]: debug: "/home/john/.google_authenticator" written
Oct 22 17:59:32 debian sshd[3938]: Failed password for john from 10.0.0.8 port 55673 ssh2
Hier versuchte john sich ohne SSH-Key zu Authentifizieren.
Existiert im user home ~/.google_authenticator, so erwartet der Google Authenticator ein SUCCESS von der SSH-Key (publickey) Authentifizierungsmethode.
Wichtig ist eine korrekte Zeit, damit die TOTP-Token synchron sind, bei grösserer Abweichung kann es zu abgelaufenen OATH-TOTP-Token kommen. Der NTP-Dienst sollte daher auf dem Server entsprechend eingerichtet und konfiguriert sein, für eine präzise Zeitsynchronisation. Das Tutorial zu Linux Systemzeit Synchronisation mit Network Time Protocol (NTP) gibt es hier.
Zum Schluss
Gratulation! Du hast eben den SSH-Server mit Zwei-Faktor-Authentifizierung für Debian oder Ubuntu erfolgreich eingerichtet. Wir hoffen, wir konnten die nötigen Grundlagen Kenntnisse vermitteln, um den SSH-Server mit Google Authenticator zu schützen.
UNBLOG verwendet Cookies, um Dein Online-Erlebnis zu verbessern. Mit "ACCEPT" gibst Du Deine Zustimmung zur Nutzung dieser Website und unseren Datenschutzbestimmungen, oder wähle Cookie settings.
Diese Website verwendet Cookies, um Ihre Erfahrung zu verbessern, während Sie durch die Website navigieren. Von diesen werden die Cookies, die nach Bedarf kategorisiert werden, in Ihrem Browser gespeichert, da sie für das Funktionieren der grundlegenden Funktionen der Website wesentlich sind. Wir verwenden auch Cookies von Drittanbietern, mit denen wir analysieren und verstehen können, wie Sie diese Website nutzen. Diese Cookies werden nur mit Ihrer Zustimmung in Ihrem Browser gespeichert. Sie haben auch die Möglichkeit, diese Cookies zu deaktivieren. Das Deaktivieren einiger dieser Cookies kann sich jedoch auf Ihre Browser-Erfahrung auswirken.
Notwendige Cookies sind unbedingt erforderlich, damit die Website ordnungsgemäß funktioniert. Diese Kategorie enthält nur Cookies, die grundlegende Funktionen und Sicherheitsmerkmale der Website gewährleisten. Diese Cookies speichern keine persönlichen Informationen.
Alle Cookies, die für die Funktion der Website möglicherweise nicht besonders erforderlich sind und speziell zur Erfassung personenbezogener Daten des Benutzers über Analysen, Anzeigen und andere eingebettete Inhalte verwendet werden, werden als nicht erforderliche Cookies bezeichnet. Es ist obligatorisch, die Zustimmung des Benutzers einzuholen, bevor diese Cookies auf Ihrer Website ausgeführt werden.
Der ähnliche Beitrag hier könnte dich auch interessieren.
GitHub