Schutz eines Linux-Servers. Was zuerst zu tun ist

Schutz eines Linux-Servers. Was zuerst zu tun ist
Habib M’henni / Wikimedia Commons, CC BY-SA

Es ist heutzutage ein Kinderspiel, einen Server bei einem Hosting-Anbieter hochzufahren - es dauert nur ein paar Minuten und einige Mausklicks. Aber sofort nach dem Start gelangt er in eine feindliche Umgebung, denn er ist für das gesamte Internet zugänglich, wie ein unschuldiges Mädchen auf einer Rockdisco. Scanner finden ihn schnell, und tausende automatisierte Bots durchstreifen das Netz auf der Suche nach Schwachstellen und falschen Konfigurationen. Es gibt einige Dinge, die sofort nach dem Start getan werden sollten, um einen grundlegenden Schutz zu gewährleisten.

Inhalt

No-Root Benutzer

Zuerst sollte man sich einen No-Root-Benutzer anlegen. Der Grund ist, dass der Benutzer root absolute Rechte im System hat, und wenn man ihm die Fernadministration erlaubt, hat man dem Hacker die halbe Arbeit abgenommen, indem man ihm einen gültigen Benutzernamen überlässt.

Deshalb sollte man einen anderen Benutzer anlegen und für den Root-Zugang die Fernadministration über SSH deaktivieren.

Ein neuer Benutzer wird mit dem Befehl useradd:

useradd [options]

Dann wird ihm ein Passwort mit dem Befehl hinzugefügt passwd:

passwd

Schließlich muss dieser Benutzer zu der Gruppe hinzugefügt werden, die das Recht hat, Befehle mit erhöhten Privilegien auszuführen. sudoJe nach Linux-Distribution kann dies unterschiedliche Gruppen sein. Zum Beispiel wird der Benutzer in CentOS und Red Hat zur Gruppe wheel:

usermod -aG wheel

In Ubuntu wird er zur Gruppe hinzugefügt sudo:

usermod -aG sudo

Schlüssel statt SSH-Passwörter

Brute-Force oder Passwortlecks sind Standardangriffsvektoren, daher ist es besser, die Passwort-Authentifizierung über SSH (Secure Shell) zu deaktivieren und stattdessen die Schlüssel-Authentifizierung zu verwenden.

Es gibt verschiedene Programme zur Implementierung des SSH-Protokolls, wie zum Beispiel lsh und Dropbear, aber das beliebteste ist OpenSSH. Installation des OpenSSH-Clients auf Ubuntu:

sudo apt install openssh-client

Installation auf dem Server:

sudo apt install openssh-server

Start des SSH-Daemons (sshd) auf dem Server unter Ubuntu:

sudo systemctl start sshd

Automatischer Start des Daemons bei jedem Boot:

sudo systemctl enable sshd

Es ist anzumerken, dass der Serverteil von OpenSSH auch den Client umfasst. Das heißt, über openssh-server Es ist möglich, sich mit anderen Servern zu verbinden. Darüber hinaus können Sie von Ihrem Client-Rechner aus ein SSH-Tunnel von einem Remote-Server zu einem externen Host starten, und dann wird der externe Host den Remote-Server als Quelle der Anfragen betrachten. Eine sehr praktische Funktion zur Maskierung Ihres Systems. Weitere Informationen finden Sie im Artikel. „Praktische Tipps, Beispiele und SSH-Tunnel“.

Auf dem Client-Rechner macht es normalerweise keinen Sinn, einen vollständigen Server zu installieren, um die Möglichkeit einer Remote-Verbindung zum Computer (aus Sicherheitsgründen) zu vermeiden.

Um also für Ihren neuen Benutzer zunächst die SSH-Schlüssel auf dem Computer zu generieren, von dem Sie auf den Server zugreifen werden:

ssh-keygen -t rsa

Der öffentliche Schlüssel wird in einer Datei gespeichert .pub und sieht aus wie eine Zeichenkette zufälliger Symbole, die mit ssh-rsa.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ3GIJzTX7J6zsCrywcjAM/7Kq3O9ZIvDw2OFOSXAFVqilSFNkHlefm1iMtPeqsIBp2t9cbGUf55xNDULz/bD/4BCV43yZ5lh0cUYuXALg9NI29ui7PEGReXjSpNwUD6ceN/78YOK41KAcecq+SS0bJ4b4amKZIJG3JWm49NWvoo0hdM71sblF956IXY3cRLcTjPlQ84mChKL1X7+D645c7O4Z1N3KtL7l5nVKSG81ejkeZsGFzJFNqvr5DuHdDL5FAudW23me3BDmrM9ifUmt1a00mWci/1qUlaVFft085yvVq7KZbF2OP2NQACUkwfwh+iSTP username@hostname

Dann erstellen Sie als Root auf dem Server ein SSH-Verzeichnis im Home-Verzeichnis des Benutzers und fügen den öffentlichen SSH-Schlüssel in die Datei authorized_keys, indem Sie einen Texteditor wie Vim verwenden:

mkdir -p /home/user_name/.ssh && touch /home/user_name/.ssh/authorized_keys

vim /home/user_name/.ssh/authorized_keys

Schließlich setzen Sie die richtigen Berechtigungen für die Datei:

chmod 700 /home/user_name/.ssh && chmod 600 /home/user_name/.ssh/authorized_keys

und ändern den Besitz auf diesen Benutzer:

chown -R username:username /home/username/.ssh

Auf der Client-Seite müssen Sie den Speicherort des geheimen Schlüssels für die Authentifizierung angeben:

ssh-add DIR_PATH/keylocation

Jetzt können Sie sich unter dem Benutzernamen mit diesem Schlüssel auf dem Server anmelden:

ssh [username]@hostname

Nach der Authentifizierung können Sie den Befehl scp zum Kopieren von Dateien verwenden, das Dienstprogramm sshfs zum Remote-Mounten von Dateisystemen oder Verzeichnissen.

Es wird empfohlen, mehrere Sicherungskopien des privaten Schlüssels anzufertigen, da, wenn die Passwortauthentifizierung deaktiviert wird und Sie ihn verlieren, Ihnen keinerlei Möglichkeit bleibt, auf Ihren eigenen Server zuzugreifen.

Wie bereits erwähnt, muss die Authentifizierung für den Root in SSH deaktiviert werden (aus diesem Grund haben wir einen neuen Benutzer angelegt).

In CentOS/Red Hat finden wir die Zeile PermitRootLogin yes in der Konfigurationsdatei /etc/ssh/sshd_config und ändern sie:

PermitRootLogin no

In Ubuntu fügen wir die Zeile PermitRootLogin no in die Konfigurationsdatei 10-my-sshd-settings.conf:

sudo echo "PermitRootLogin no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

Nachdem überprüft wurde, dass der neue Benutzer sich mit seinem Schlüssel authentifiziert, kann die Passwortauthentifizierung deaktiviert werden, um das Risiko eines Lecks oder Brute-Force-Angriffs auszuschließen. Jetzt benötigt ein Angreifer, um auf den Server zuzugreifen, den privaten Schlüssel.

In CentOS/Red Hat finden wir die Zeile PasswordAuthentication yes in der Konfigurationsdatei /etc/ssh/sshd_config und ändern sie wie folgt:

PasswordAuthentication no

In Ubuntu fügen wir die Zeile PasswordAuthentication no in die Datei 10-my-sshd-settings.conf:

sudo echo "PasswordAuthentication no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

Die Anleitung zur Einrichtung der Zwei-Faktor-Authentifizierung über SSH siehe hier.

Firewall

Die Firewall stellt sicher, dass nur der Datenverkehr auf den Server gelangt, der über die von Ihnen direkt erlaubten Ports erfolgt. Dies schützt vor der Ausnutzung von Ports, die versehentlich zusammen mit anderen Diensten aktiviert wurden, und verringert somit die Angriffsfläche erheblich.

Vor der Installation der Firewall muss sichergestellt werden, dass SSH auf der Ausnahmeliste steht und nicht blockiert wird. Andernfalls können wir nach dem Start der Firewall nicht mehr auf den Server zugreifen.

Mit der Ubuntu-Distribution wird die Uncomplicated Firewall (ufw), und mit CentOS/Red Hat — firewalld.

Erlauben von SSH in der Firewall unter Ubuntu:

sudo ufw allow ssh

Unter CentOS/Red Hat verwenden wir den Befehl firewall-cmd:

sudo firewall-cmd --zone=public --add-service=ssh --permanent

Nach diesem Verfahren kann die Firewall gestartet werden.

Unter CentOS/Red Hat starten wir den systemd-Dienst für firewalld:

sudo systemctl start firewalld
sudo systemctl enable firewalld

Unter Ubuntu verwenden wir folgenden Befehl:

sudo ufw enable

Fail2Ban

Dienst Fail2Ban analysiert die Protokolle auf dem Server und zählt die Anzahl der Zugriffsversuche von jeder IP-Adresse. In den Einstellungen sind die Regeln angegeben, wie viele Zugriffsversuche in einem bestimmten Zeitraum erlaubt sind — danach wird die betreffende IP-Adresse für einen festgelegten Zeitraum blockiert. Zum Beispiel erlauben wir 5 fehlgeschlagene SSH-Authentifizierungsversuche innerhalb von 2 Stunden, danach blockieren wir diese IP-Adresse für 12 Stunden.

Installation von Fail2Ban auf CentOS und Red Hat:

sudo yum install fail2ban

Installation auf Ubuntu und Debian:

sudo apt install fail2ban

Start:

systemctl start fail2ban
systemctl enable fail2ban

Das Programm hat zwei Konfigurationsdateien: /etc/fail2ban/fail2ban.conf und /etc/fail2ban/jail.conf. Die Einschränkungen für die Sperre werden in der zweiten Datei angegeben.

Das Jail für SSH ist standardmäßig mit den Voreinstellungen (5 Versuche, Intervall 10 Minuten, Ban für 10 Minuten) aktiviert.

[DEFAULT]
ignorecommand =
bantime = 10m
findtime = 10m
maxretry = 5

Neben SSH kann Fail2Ban auch andere Dienste auf dem Webserver nginx oder Apache schützen.

Automatische Sicherheitsupdates

Wie bekannt ist, werden in allen Programmen ständig neue Schwachstellen gefunden. Nach der Veröffentlichung von Informationen werden Exploits zu beliebten Exploit-Packs hinzugefügt, die massenhaft von Hackern und Jugendlichen beim Scannen aller Server verwendet werden. Daher ist es sehr wichtig, Sicherheitsupdates sofort zu installieren, sobald sie verfügbar sind.

Auf einem Ubuntu-Server sind standardmäßig automatische Sicherheitsupdates aktiviert, sodass keine zusätzlichen Maßnahmen erforderlich sind.

Auf CentOS/Red Hat müssen Sie die Anwendung dnf-automatic installieren und den Timer aktivieren:

sudo dnf upgrade
sudo dnf install dnf-automatic -y
sudo systemctl enable --now dnf-automatic.timer

Überprüfung des Timers:

sudo systemctl status dnf-automatic.timer

Ändern der Standard-Ports

SSH wurde 1995 entwickelt, um Telnet (Port 23) und FTP (Port 21) zu ersetzen, weshalb der Programmautor Tatu Ylönen den Standardport 22 wählte, und dieser wurde in der IANA bestätigt.

Natürlich sind alle Angreifer sich bewusst, auf welchem Port SSH läuft — und scannen diesen zusammen mit allen anderen Standardports, um die Softwareversion herauszufinden, um Standardpasswörter des Root-Benutzers zu überprüfen und so weiter.

Die Änderung der Standardports — Obfuskation — verringert erheblich das Volumen des Müllverkehrs, die Größe der Protokolle und die Serverlast und reduziert auch die Angriffsfläche. Einige kritisieren diese Methode als „Sicherheit durch Unklarheit“ (security through obscurity). Der Grund dafür ist, dass diese Technik der grundlegenden architektonischen Sicherheitentgegensteht. Daher weist das National Institute of Standards and Technology der USA in „Security Guidelines for Servers“ auf die Notwendigkeit einer offenen Serverarchitektur hin: „Die Sicherheit eines Systems sollte nicht von der Geheimhaltung der Implementierung seiner Komponenten abhängen“, heißt es in dem Dokument.

Theoretisch widerspricht die Änderung der Standardports der Praxis einer offenen Architektur. Aber in der Praxis wird das Volumen des schädlichen Datenverkehrs tatsächlich reduziert, sodass dies eine einfache und effektive Maßnahme ist.

Die Portnummer kann angepasst werden, indem die Direktive Port 22 in der Konfigurationsdatei geändert wird. /etc/ssh/sshd_configSie wird auch über den Parameter -p in sshdangegeben. Der SSH-Client und die Programme sftp unterstützen ebenfalls den Parameter -p.

Parameter -p der verwendet werden kann, um die Portnummer bei der Verbindung über den Befehl ssh in Linux anzugeben. In sftp und scp wird der Parameter -P verwendet. (überschrift P). Der Befehl in der Eingabeaufforderung überschreibt jeden Wert in den Konfigurationsdateien.

Wenn viele Server vorhanden sind, können fast alle Maßnahmen zum Schutz des Linux-Servers in einem Skript automatisiert werden. Aber wenn nur ein Server vorhanden ist, ist es besser, den Prozess manuell zu überwachen.

Als Werbung

Bestelle und arbeite sofort! Erstellung von VDS jeder Konfiguration und mit jedem Betriebssystem innerhalb einer Minute. Die maximale Konfiguration ermöglicht vollständigen Spaß - 128 CPU-Kerne, 512 GB RAM, 4000 GB NVMe. Episch 🙂

Schutz eines Linux-Servers. Was zuerst zu tun ist

Quelle: habr.com

60GB SSD 8Gb DDR4