One place for hosting & domains

      Konfigurieren des Remotezugriffs für MongoDB unter Ubuntu 20.04


      Eine frühere Version dieses Tutorials wurde von Melissa Anderson verfasst.

      Einführung

      MongoDB, auch als Mongo bekannt, ist eine Open-Source-Dokumentendatenbank, die für gewöhnlich in modernen Webanwendungen verwendet wird. Standardmäßig erlaubt sie nur Verbindungen, die von demselben Server stammen, auf dem sie installiert ist. Wenn Sie MongoDB aus der Ferne verwalten oder die Datenbank mit einem separaten Anwendungsserver verbinden möchten, müssen Sie einige Änderungen an der Standardkonfiguration vornehmen.

      In diesem Tutorial konfigurieren Sie eine MongoDB-Installation so, dass der Zugriff von einem vertrauenswürdigen Remotecomputer aus sicher möglich ist. Dazu aktualisieren Sie Ihre Firewall-Regeln, um dem Remotecomputer Zugriff auf den Port zu gewähren, auf dem MongoDB auf Verbindungen lauscht, und aktualisieren dann ihre Konfigurationsdatei, um ihre IP-Bindungseinstellung zu ändern. Als letzten Schritt testen Sie dann, dass Ihr Remotecomputer die Verbindung zu Ihrer Datenbank erfolgreich herstellen kann.

      Voraussetzungen

      Um dieses Tutorial zu absolvieren, benötigen Sie:

      • Einen Server, auf dem Ubuntu 20.04 ausgeführt wird. Dieser Server sollte über einen administrativen non-root user und eine mit UFW konfigurierte Firewall verfügen. Sie können dies einrichten, indem Sie unserem Leitfaden zur Ersteinrichtung des Servers mit Ubuntu 20.04 folgen.
      • MongoDB, das auf Ihrem Server installiert ist. Dieses Tutorial geht davon aus, dass Sie MongoDB 4.4 oder eine neuere Version installiert haben. Sie können diese Version installieren, indem Sie unserem Leitfaden zum Installieren von MongoDB unter Ubuntu 20.04 folgen.
      • Einen zweiten Computer, von dem Sie auf Ihre MongoDB-Instanz zugreifen. Aus Gründen der Einfachheit geht dieses Tutorial davon aus, dass es sich bei diesem Computer um einen weiteren Ubuntu 20.04-Server handelt, der mit einem administrativen non-root user und einer UFW-Firewall gemäß unserem Leitfaden zur Ersteinrichtung des Servers mit Ubuntu 20.04 konfiguriert ist. Schritt 1 und 2, die das eigentliche Verfahren zur Aktivierung des Remote-Zugriffs auf den Datenbankserver beschreiben, funktionieren jedoch unabhängig davon, unter welchem Betriebssystem der Remotecomputer ausgeführt wird.

      Auch wenn es zum Abschließen dieses Tutorials nicht erforderlich ist, empfehlen wir außerdem dringend, dass Sie Ihre MongoDB-Installation sichern, indem Sie ein administratives Benutzerkonto für die Datenbank erstellen und die Authentifizierung aktivieren. Folgen Sie dazu unserem Leitfaden Sichern von MongoDB unter Ubuntu 20.04.

      Schritt 1 — Anpassen der Firewall

      Unter der Annahme, dass Sie dem Leitfaden zur Ersteinrichtung des Servers aus den Voraussetzungen gefolgt sind und eine UFW-Firewall auf Ihrem Server aktiviert haben, ist Ihre MongoDB-Installation vom Internet nicht zugänglich. Wenn Sie MongoDB nur lokal mit Anwendungen verwenden möchten, die auf dem gleichen Server ausgeführt werden, ist dies die empfohlene und sichere Einstellung. Wenn Sie jedoch eine Verbindung mit Ihrem MongoDB-Server von einem entfernten Ort herstellen möchten, müssen Sie eingehende Verbindungen zu dem Port zulassen, auf dem die Datenbank lauscht, indem Sie eine neue UFW-Regel hinzufügen.

      Überprüfen Sie zunächst mit dem Befehl lsof, auf welchem Port Ihre MongoDB-Installation lauscht. Dieser Befehl gibt normalerweise eine Liste mit jeder offenen Datei in einem System aus. Wenn er jedoch mit der Option -i kombiniert wird, listet er nur netzwerkbezogene Dateien oder Datenströme auf.

      Der folgende Befehl leitet die von lsof -i erstellte Ausgabe an einen grep-Befehl weiter, der nach einer Zeichenfolge namens mongo sucht:

      • sudo lsof -i | grep mongo

      Diese Beispielausgabe zeigt, dass MongoDB den Verbindungen auf ihrem Standard-Port 27017 lauscht:

      Output

      mongod 82221 mongodb 11u IPv4 913411 0t0 TCP localhost:27017 (LISTEN)

      In den meisten Fällen sollte nur von bestimmten vertrauenswürdigen Orten auf MongoDB zugegriffen werden, wie z. B. von einem anderen Server, der eine Anwendung hostet. Um dies zu konfigurieren, besteht unter anderem die Möglichkeit, den folgenden Befehl auf Ihrem MongoDB-Server auszuführen. Dieser erlaubt den Zugriff auf den Standardport von MongoDB, lässt dabei jedoch nur die IP-Adresse des anderen vertrauenswürdigen Servers zu.

      Führen Sie den folgenden Befehl aus und ersetzen Sie hierbei trusted_server_ip mit der IP-Adresse des vertrauenswürdigen Remotecomputers, den Sie für den Zugriff auf Ihre MongoDB-Instanz nutzen möchten:

      Anmerkung: Wenn die Ausgabe des vorherigen Befehls gezeigt hat, dass Ihre Installation von MongoDB auf einem nicht standardmäßigen Port lauscht, verwenden Sie in diesem Befehl diese Portnummer anstelle von 27017.

      • sudo ufw allow from trusted_server_ip to any port 27017

      Wenn Sie in Zukunft von einem anderen Computer auf MongoDB zugreifen möchten, führen Sie diesen Befehl erneut mit der IP-Adresse des neuen Computers anstelle von trusted_server_ip aus.

      Sie können die Änderung der Firewall-Einstellungen mit ufw überprüfen:

      Die Ausgabe zeigt an, dass der Datenverkehr zum Port 27017 vom Remoteserver nun zugelassen wird:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 27017 ALLOW trusted_server_ip OpenSSH (v6) ALLOW Anywhere (v6)

      Weitere erweiterte Firewall-Einstellungen zum Einschränken des Zugriffs auf Dienste finden Sie in UFW-Grundlagen: gebräuchliche Firewall-Regeln und -Befehle.

      Als Nächstes binden Sie MongoDB an die öffentliche IP-Adresse des Servers, damit Sie von Ihrem Remotecomputer darauf zugreifen können.

      Schritt 2 — Konfigurieren einer öffentlichen bindIP

      Obwohl der Port geöffnet ist, ist MongoDB derzeit an 127.0.0.1 gebunden, die lokale Loopback-Netzwerkschnittstelle. Das bedeutet, dass MongoDB nur Verbindungen akzeptieren kann, die von dem Server stammen, auf dem die Datenbank installiert ist.

      Um Remoteverbindungen zu ermöglichen, müssen Sie die Konfigurationsdatei von MongoDB — /etc/mongod.conf — bearbeiten, um MongoDB zusätzlich an die öffentlich routbare IP-Adresse Ihres Servers zu binden. Auf diese Weise kann Ihre MongoDB-Installation auf Verbindungen zu Ihrem MongoDB-Server von Remotecomputern lauschen.

      Öffnen Sie die MongoDB-Konfigurationsdatei in Ihrem bevorzugten Editor. Das folgende Beispiel verwendet nano:

      • sudo nano /etc/mongod.conf

      Finden Sie den Abschnitt network interfaces und dann den bindIp-Wert:

      /etc/mongod.conf

      . . .
      # network interfaces
      net:
        port: 27017
        bindIp: 127.0.0.1
      
      . . .
      

      Hängen Sie dieser Zeile ein Komma an, gefolgt von der öffentlichen IP-Adresse Ihres MongoDB-Servers:

      /etc/mongod.conf

      . . .
      # network interfaces
      net:
        port: 27017
        bindIp: 127.0.0.1,mongodb_server_ip
      
      . . .
      

      Speichern und schließen Sie die Datei. Wenn Sie nano verwendet haben, drücken Sie STRG+X, Y, dann die EINGABETASTE.

      Starten Sie dann MongoDB neu, um diese Änderung umzusetzen:

      • sudo systemctl restart mongod

      Danach kann Ihre MongoDB-Installation Remoteverbindungen von allen Computern akzeptieren, denen Sie Zugriff auf Port 27017 gewährt haben. Als abschließenden Schritt können Sie testen, ob der vertrauenswürdige Remoteserver, den Sie in Schritt 1 über die Firewall erlauben, die MongoDB-Instanz auf Ihrem Server erreichen kann.

      Schritt 3 — Testen der Remotekonnektivität

      Nachdem Sie Ihre MongoDB-Installation so konfiguriert haben, dass sie auf Verbindungen lauscht, die von ihrer öffentlich routbaren IP-Adresse stammen, und Ihrem Remotecomputer Zugriff über die Firewall Ihres Servers auf den Standardport von Mongo gewährt haben, können Sie testen, ob der Remotecomputer in der Lage ist, sich zu verbinden.

      Anmerkung: Wie im Abschnitt Voraussetzungen erwähnt, geht dieses Tutorial davon aus, dass Ihr Remotecomputer ein anderer Server ist, auf dem Ubuntu 20.04 ausgeführt wird. Das in den Schritten 1 und 2 beschriebene Verfahren zur Aktivierung von Remoteverbindungen sollte unabhängig davon funktionieren, welches Betriebssystem auf Ihrem Remotecomputer ausgeführt wird. Die in diesem Schritt beschriebenen Testmethoden funktionieren jedoch nicht universell bei allen Betriebssystemen.

      Eine Möglichkeit, zu testen, dass Ihr vertrauenswürdiger Remoteserver eine Verbindung mit der MongoDB-Instanz herstellen kann, besteht in der Verwendung des nc-Befehls. nc, kurz für netcat, ist ein Dienstprogramm, das zum Erstellen von Netzwerkverbindungen mit TCP oder UDP verwendet wird. Er ist für Tests in Fällen wie diesen nützlich, da Sie sowohl eine IP-Adresse als auch eine Portnummer angeben können.

      Melden Sie sich zunächst mit SSH bei Ihrem vertrauenswürdigen Server an:

      • ssh sammy@trusted_server_ip

      Führen Sie dann den folgenden nc-Befehl aus, der die Option -z enthält. Dadurch wird nc darauf beschränkt, nur nach einem lauschenden Daemon auf dem Zielserver zu suchen, ohne diesem Daten zu senden. Erinnern Sie sich aus der Installationsanleitung in den Voraussetzungen, dass MongoDB als Dienst-Daemon ausgeführt wird. Daher ist diese Option nützlich zum Testen der Konnektivität. Außerdem enthält er die Option v, der die Ausführlichkeit des Befehls erhöht und bewirkt, dass netcat eine Ausgabe ausgibt, was sonst nicht geschehen würde.

      Führen Sie den folgenden nc-Befehl von Ihrem vertrauenswürdigen Remoteserver aus und stellen Sie sicher, mongodb_server_ip durch die IP-Adresse des Servers, auf dem Sie MongoDB installiert haben, zu ersetzen:

      • nc -zv mongodb_server_ip 27017

      Wenn der vertrauenswürdige Server auf den MongoDB-Daemon zugreifen kann, wird seine Ausgabe angeben, dass die Verbindung erfolgreich war:

      Output

      Connection to mongodb_server_ip 27017 port [tcp/*] succeeded!

      Wenn Sie eine kompatible Version der mongo-Shell auf Ihrem Remoteserver installiert haben, können Sie sich nun direkt mit der auf dem Hostserver installierten MongoDB-Instanz verbinden.

      Eine Möglichkeit zur Verbindung bietet eine URI-Verbindungszeichenfolge wie diese:

      • mongo "mongodb://mongo_server_ip:27017"

      Anmerkung: Wenn Sie dem empfohlenen Leitfaden Sichern von MongoDB unter Ubuntu 20.04 gefolgt sind, haben Sie den Zugriff auf Ihre Datenbank für nicht authentifizierte Benutzer geschlossen. In diesem Fall müssen Sie eine URI verwenden, die so wie die folgende einen gültigen Benutzernamen angibt:

      • mongo "mongodb://username@mongo_server_ip:27017"

      Die Shell wird Sie automatisch dazu auffordern, das Passwort des Benutzers einzugeben.

      Damit haben Sie bestätigt, dass Ihr MongoDB-Server Verbindungen vom vertrauenswürdigen Server akzeptieren kann.

      Zusammenfassung

      Sie können nun von einem Remoteserver auf Ihre MongoDB-Installation zugreifen. Jetzt können Sie Ihre Mongo-Datenbank von dem vertrauenswürdigen Server aus der Ferne verwalten. Alternativ können Sie eine Anwendung so konfigurieren, dass sie auf dem vertrauenswürdigen Server ausgeführt wird und die Datenbank aus der Ferne verwendet.

      Wenn Sie keinen administrativen Benutzer konfiguriert und die Authentifizierung nicht aktiviert haben, kann jeder, der Zugriff auf Ihren Remoteserver hat, auch auf Ihre MongoDB-Installation zugreifen. Sollten Sie es bisher nicht getan haben, empfehlen wir Ihnen dringend, unserem Leitfaden Sichern von MongoDB unter Ubuntu 20.04 zu folgen, und für eine erhöhte Absicherung einen administrativen Benutzer hinzuzufügen.



      Source link

      Härten von OpenSSH unter Ubuntu 18.04


      Der Autor wählte die Electronic Frontier Foundation Inc, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      Linux-Server werden oft über SSH aus der Ferne verwaltet, indem eine Verbindung mit einem OpenSSH-Server hergestellt wird. Das ist die SSH-Serversoftware, die in Ubuntu, Debian, CentOS, FreeBSD und den meisten anderen Linux/BSD-basierten Systemen verwendet wird.

      OpenSSH-Server ist die Serverseite von SSH, auch als SSH-Daemon oder sshd bekannt. Sie können über den OpenSSH-Client – den Befehl ssh – eine Verbindung zu einem OpenSSH-Server herstellen. Weitere Informationen über das Client-Server-Modell von SSH finden Sie in SSH-Grundlagen: Arbeiten mit SSH-Servern, Clients und Schlüsseln. Eine gute Sicherung Ihres OpenSSH-Servers ist sehr wichtig, da er als Eingangstür oder Zugang zu Ihrem Server fungiert.

      In diesem Tutorial härten Sie Ihren OpenSSH-Server durch verschiedene Konfigurationsoptionen, damit der Remotezugriff auf Ihren Server so sicher wie möglich ist.

      Voraussetzungen

      Um diesem Tutorial zu folgen, benötigen Sie:

      Sobald Sie diese zur Verfügung haben, melden Sie sich zunächst als non-root user auf Ihrem Server an.

      Schritt 1 — Allgemeines Härten

      In diesem ersten Schritt implementieren Sie einige anfängliche Härtungskonfigurationen, um die allgemeine Sicherheit Ihres SSH-Servers zu verbessern.

      Die für Ihren eigenen Server am besten geeignete Härtungskonfiguration hängt stark von Ihrem eigenen Gefahrenmodell und Ihrer Risikoschwelle ab. Die in diesem Schritt verwendete Konfiguration ist jedoch eine generell sichere Konfiguration, die für die Mehrheit der Server geeignet ist.

      Viele der von Ihnen implementierten Härtungskonfigurationen für OpenSSH verwenden die standardmäßige Konfigurationsdatei des OpenSSH-Servers, die sich unter /etc/ssh/sshd_config befindet. Bevor Sie mit diesem Tutorial fortfahren, empfiehlt sich ein Backup Ihrer vorhandenen Konfigurationsdatei, damit Sie sie in dem unwahrscheinlichen Fall, dass etwas schiefgeht, wiederherstellen können.

      Nehmen Sie mit dem folgenden Befehl ein Backup der Datei vor:

      • sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

      Dadurch wird eine Sicherungskopie der Datei unter /etc/ssh/sshd_config.bak. gespeichert.

      Bevor Sie Ihre Konfigurationsdatei bearbeiten, können Sie die aktuell festgelegten Optionen überprüfen. Dazu führen Sie folgenden Befehl aus:

      Dadurch wird OpenSSH-Server im erweiterten Testmodus ausgeführt, was die vollständige Konfigurationsdatei validiert und die effektiven Konfigurationswerte ausgibt.

      Sie können die Konfigurationsdatei nun mit Ihrem bevorzugten Texteditor öffnen, um mit der Implementierung der anfänglichen Härtungsmaßnahmen zu beginnen:

      • sudo nano /etc/ssh/sshd_config

      Anmerkung: Die Konfigurationsdatei des OpenSSH-Servers enthält viele standardmäßige Optionen und Konfigurationen. Je nach Ihrer vorhandenen Serverkonfiguration wurden möglicherweise bereits einige der Härtungsoptionen festgelegt.

      Bei der Bearbeitung Ihrer Konfigurationsdatei können standardmäßig einige Optionen mit einem einzelnen Hash-Zeichen (#) am Anfang der Zeile auskommentiert werden. Um diese Optionen zu bearbeiten oder die kommentierte Option anerkennen zu lassen, müssen Sie sie unkommentieren, indem Sie das Hash entfernen.

      Deaktivieren Sie zunächst die Anmeldung über SSH als root-Benutzer durch Festlegen der folgenden Option:

      sshd_config

      PermitRootLogin no
      

      Das ist sehr vorteilhaft, da es einen potenziellen Angreifer daran hindert, sich direkt als root anzumelden. Das unterstützt zudem gute betriebliche Sicherheitspraktiken wie das Operieren als nicht privilegierter Benutzer und die Verwendung von sudo, um Berechtigungen nur dann auszuweiten, wenn es unbedingt erforderlich ist.

      Als Nächstes können Sie die maximale Anzahl der Authentifizierungsversuche für eine bestimmte Anmeldesitzung begrenzen, indem Sie Folgendes konfigurieren:

      sshd_config

      MaxAuthTries 3
      

      Für die meisten Einstellungen ist ein Standardwert von 3 akzeptabel. Sie können diesen jedoch je nach Ihrer eigenen Risikoschwelle höher oder niedriger festlegen.

      Bei Bedarf können Sie auch eine reduzierte Anmeldefrist festlegen. Das ist die Zeitspanne, in der ein Benutzer die Authentifizierung abschließen muss, nachdem er sich mit Ihrem SSH-Server verbunden hat:

      sshd_config

      LoginGraceTime 20
      

      Die Konfigurationsdatei gibt diesen Wert in Sekunden an.

      Eine Einstellung auf einen niedrigeren Wert hilft, bestimmte Denial-of-Service-Angriffe zu verhindern, bei denen mehrere Authentifizierungssitzungen für einen längeren Zeitraum offen gehalten werden.

      Wenn Sie SSH-Schlüssel für die Authentifizierung konfiguriert haben anstatt Passwörter zu verwenden, deaktivieren Sie die SSH-Passwortauthentifizierung, um zu verhindern, dass geleakte Benutzerpasswörter einem Angreifer ermöglichen, sich anzumelden:

      sshd_config

      PasswordAuthentication no
      

      Als eine weitere Härtungsmaßnahme in Bezug auf Passwörter können Sie bei Bedarf auch die Authentifizierung mit leeren Passwörtern deaktivieren. Dadurch wird die Anmeldung verhindert, wenn das Passwort eines Benutzers auf einen blanken oder leeren Wert gesetzt ist:

      sshd_config

      PermitEmptyPasswords no
      

      In den meisten Anwendungsfällen wird SSH mit der Authentifizierung mit öffentlichen Schlüsseln als die einzige in Gebrauch befindliche Authentifizierungsmethode konfiguriert. Jedoch unterstützt OpenSSH-Server auch viele andere Authentifizierungsmethoden, von denen einige standardmäßig aktiviert sind. Wenn diese nicht erforderlich sind, können Sie sie deaktivieren, um die Angriffsoberfläche Ihres SSH-Servers weiter zu reduzieren:

      sshd_config

      ChallengeResponseAuthentication no
      KerberosAuthentication no
      GSSAPIAuthentication no
      

      Wenn Sie mehr über einige der in SSH verfügbaren zusätzlichen Authentifizierungsmethoden erfahren möchten, stehen Ihnen diese Ressourcen zur Verfügung:

      X11-Forwarding ermöglicht die Anzeige von entfernten grafischen Anwendungen über eine SSH-Verbindung, was jedoch selten in der Praxis verwendet wird. Es wird empfohlen, diese zu deaktivieren, wenn sie auf Ihrem Server nicht benötigt wird:

      sshd_config

      X11Forwarding no
      

      OpenSSH-Server ermöglicht es Verbindungsclients, benutzerdefinierte Umgebungsvariablen zu übergeben, d. h. einen $PATH festzulegen oder Terminaleinstellungen zu konfigurieren. Wie das X11-Forwarding werden diese jedoch generell nicht verwendet, sodass sie in den meisten Fällen deaktiviert werden können:

      sshd_config

      PermitUserEnvironment no
      

      Wenn Sie diese Option konfigurieren möchten, sollten Sie dabei sicherstellen, alle Referenzen zu AcceptEnv auszukommentieren, indem Sie am Anfang der Zeile ein Hash (#) hinzufügen.

      Als Nächstes können Sie verschiedene sonstige Optionen bezüglich Tunneling und Forwarding deaktivieren, wenn Sie diese nicht auf Ihrem Server verwenden:

      sshd_config

      AllowAgentForwarding no
      AllowTcpForwarding no
      PermitTunnel no
      

      Schließlich können Sie das standardmäßig aktivierte ausführliche SSH-Banner deaktivieren, da es verschiedene Informationen zu Ihrem System anzeigt, darunter die Betriebssystemversion:

      sshd_config

      DebianBanner no
      

      Beachten Sie, dass diese Option wahrscheinlich nicht in der Konfigurationsdatei vorhanden ist, sodass Sie sie möglicherweise manuell hinzufügen müssen. Speichern und schließen Sie die Datei, sobald Sie fertig sind.

      Validieren Sie nun die Syntax Ihrer neuen Konfiguration, indem Sie sshd im Testmodus ausführen:

      Wenn Ihre Konfigurationsdatei eine gültige Syntax hat, gibt es keine Ausgabe. Im Falle eines Syntaxfehlers gibt es eine Ausgabe, die das Problem beschreibt.

      Wenn Sie mit Ihrer Konfigurationsdatei zufrieden sind, können Sie sshd neu laden, um die neuen Einstellungen anzuwenden:

      In diesem Schritt haben Sie eine allgemeine Härtung der Konfigurationsdatei Ihres OpenSSH-Servers vorgenommen. Als Nächstes implementieren Sie eine Zulassungsliste für IP-Adressen, um weiter zu beschränken, wer sich bei Ihrem Server anmelden kann.

      Schritt 2 — Implementieren einer IP-Adressen-Zulassungsliste

      Sie können IP-Adressen-Zulassungslisten verwenden, um die Benutzer zu beschränken, die berechtigt sind, sich bei Ihrem Server auf Bais der einzelnen IP-Adressen anzumelden. In diesem Schritt konfigurieren Sie eine IP-Zulassungsliste für Ihren OpenSSH-Server.

      In vielen Fällen melden Sie sich nur von einer kleinen Anzahl bekannter, vertrauenswürdiger IP-Adressen auf Ihrem Server an. Beispiele sind Ihre private Internetverbindung, eine gemeinschaftliche VPN-Anwendung oder eine statische Jump Box oder ein statischer Bastion Host in einer Datenzentrale.

      Durch die Implementierung einer IP-Adressen-Zulassungsliste können Sie sicherstellen, dass sich Personen nur über eine der vorab zugelassenen IP-Adressen anmelden. Dadurch wird das Risiko eines unerwünschten Zugriffs in dem Fall, dass Ihre privaten Schlüssel und/oder Passwörter geleaked wurden, erheblich reduziert.

      Anmerkung: Bitte achten Sie darauf, die richtigen IP-Adressen zu identifizieren, die Sie Ihrer Zulassungsliste hinzufügen möchten, und stellen Sie sicher, dass es sich dabei nicht um schwebende oder dynamische Adressen handelt, die sich regelmäßig ändern können, wie es beispielsweise bei Internetdienstanbietern für Verbraucher häufig der Fall ist.

      Sie können die IP-Adresse identifizieren, mit der Sie sich derzeit mit Ihrem Server verbinden, indem Sie den Befehl w verwenden:

      Sie sehen eine Ausgabe, die der folgenden ähnelt:

      Output

      14:11:48 up 2 days, 12:25, 1 user, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT your_username pts/0 203.0.113.1 12:24 1.00s 0.20s 0.00s w

      Finden Sie Ihr Benutzerkonto in der Liste und notieren Sie sich die IP-Adresse der Verbindung. Hier verwenden wir die Beispiel-IP 203.0.113.1

      Um mit der Implementierung Ihrer IP-Adressen-Zulassungsliste zu beginnen, öffnen Sie die Konfigurationsdatei des OpenSSH-Servers mit Ihrem bevorzugten Texteditor:

      • sudo nano /etc/ssh/sshd_config

      Sie können IP-Adressen-Zulassungslisten mit der Konfigurationsanweisung AllowUsers implementieren, die Benutzerauthentifizierungen auf Basis des Benutzernamens und/oder der IP-Adresse beschränkt.

      Ihre eigenen Systemeinstellungen und -anforderungen bestimmen, welche spezifische Konfiguration am besten geeignet ist. Die folgenden Beispiele helfen Ihnen dabei, die am besten geeignete zu identifizieren:

      • Beschränken aller Benutzer auf eine bestimmte IP-Adresse:
      AllowUsers *@203.0.113.1
      
      AllowUsers *@203.0.113.0/24
      
      • Beschränken aller Benutzer auf einen bestimmten IP-Adressbereich (mit Wildcards):
      AllowUsers *@203.0.113.*
      
      • Beschränken aller Benutzer auf mehrere spezifische IP-Adressen und -bereiche:
      AllowUsers *@203.0.113.1 *@203.0.113.2 *@192.0.2.0/24 *@172.16.*.1
      
      • Deaktivieren aller Benutzer mit Ausnahme von benannten Benutzern von bestimmten IP-Adressen:
      AllowUsers sammy@203.0.113.1 alex@203.0.113.2<^>
      
      • Beschränken eines bestimmten Benutzers auf eine bestimmte IP-Adresse, während es allen anderen Benutzern weiterhin erlaubt ist, sich ohne Beschränkungen anzumelden:
      Match User ashley
        AllowUsers ashley@203.0.113.1
      

      Warnung: In einer OpenSSH-Konfigurationsdatei gelten alle Konfigurationen unter einem Match-Block nur für Verbindungen, die den Kriterien entsprechen, unabhängig von Einrückung oder Zeilenumbrüchen. Daher müssen Sie vorsichtig sein und sicherstellen, dass Konfigurationen, die zur globalen Anwendung bestimmt sind, nicht versehentlich in einen Match-Block eingestellt werden. Um das zu vermeiden, wird empfohlen, alle Match-Blocks an das untere Ende Ihrer Konfigurationsdatei zu setzen.

      Wenn Sie Ihre Konfiguration abgeschlossen haben, fügen Sie sie unten in Ihre OpenSSH-Server-Konfigurationsdatei ein:

      sshd_config

      AllowUsers *@203.0.113.1
      

      Speichern und schließen Sie die Datei. Anschließend testen Sie Ihre Konfigurationssyntax:

      Wenn keine Fehler gemeldet werden, können Sie OpenSSH-Server neu laden, um Ihre Konfiguration anzuwenden:

      In diesem Schritt haben Sie eine IP-Adressen-Zulassungsliste auf Ihrem OpenSSH-Server implementiert. Als Nächstes beschränken Sie die Shell eines Benutzers, um die Befehle, die er verwenden darf, einzugrenzen.

      Schritt 3 — Beschränken der Shell eines Benutzers

      In diesem Schritt sehen Sie sich die verschiedenen Optionen zur Beschränkung der Shell eines SSH-Benutzers an.

      Neben dem Remote-Shell-Zugriff eignet sich SSH auch hervorragend für die Übertragung von Dateien und anderen Daten, z. B. über SFTP. Es kann jedoch sein, dass Sie Benutzern nicht immer vollständigen Shell-Zugriff gewähren möchten, wenn sie nur in der Lage sein müssen, Datenübertragungen durchzuführen.

      Es gibt mehrere Konfigurationen im OpenSSH-Server, mit denen Sie die Shell-Umgebung für bestimmte Benutzer beschränken können. In dieser Anleitung werden wird diese zum Beispiel verwenden, um Nur-SFTP-Benutzer zu erstellen.

      Zunächst können Sie die Shell /usr/sbin/nologin verwenden, um interaktive Anmeldungen für bestimmte Benutzerkonten zu deaktivieren, während nicht-interaktive Sitzungen wie Dateiübertragungen, Tunneling usw. weiterhin funktionieren können.

      Um einen neuen Benutzer mit der nologin-Shell zu erstellen, verwenden Sie folgenden Befehl:

      • sudo adduser --shell /usr/sbin/nologin alex

      Alternativ können Sie die Shell eines vorhandenen Benutzers zu nologin ändern:

      • sudo usermod --shell /usr/sbin/nologin sammy

      Wenn Sie dann versuchen, sich interaktiv als einen dieser Benutzer anzumelden, wird die Anfrage abgelehnt:

      Sie sehen eine Ausgabe mit einer Meldung, die der folgenden ähnelt:

      Output

      This account is currently not available.

      Trotz der Ablehnungsmeldung zu interaktiven Anmeldungen werden andere Aktionen wie Dateiübertragungen weiterhin zugelassen.

      Als Nächstes sollten Sie die Verwendung der nologin-Shell mit einigen zusätzlichen Konfigurationsoptionen kombinieren, um die entsprechenden Benutzerkonten weiter zu beschränken.

      Öffnen Sie zunächst die Konfigurationsdatei des OpenSSH-Servers in Ihrem bevorzugten Texteditor:

      • sudo nano /etc/ssh/sshd_config

      Es gibt zwei Konfigurationsoptionen, die Sie gemeinsam implementieren können, um ein streng beschränktes Nur-SFTP-Benutzerkonto zu erstellen: ForceCommand internal-sftp und ChrootDirectory.

      Die Option ForceCommand innerhalb OpenSSH-Server zwingt einen Benutzer, einen bestimmten Befehl bei der Anmeldung auszuführen. Das kann für bestimmte Machine-to-Machine-Kommunikationen nützlich sein, oder um ein bestimmtes Programm zwangsweise zu starten.

      In diesem Fall ist der Befehl internal-sftp jedoch besonders nützlich. Dabei handelt es sich um eine spezielle Funktion des OpenSSH-Servers, die an Ort und Stelle einen grundlegenden SFTP-Daemon startet, der keine unterstützenden Systemdateien oder Konfiguration benötigt.

      Idealerweise kombinieren Sie diese mit der Option ChrootDirectory, die das erkannte Root-Verzeichnis für einen bestimmten Benutzer aufhebt bzw. ändert, wodurch dieser im Wesentlichen auf ein bestimmtes Verzeichnis im System beschränkt wird.

      Fügen Sie dazu den folgenden Konfigurationsabschnitt in Ihre OpenSSH-Server-Konfigurationsdatei ein:

      sshd_config

      Match User alex
        ForceCommand internal-sftp
        ChrootDirectory /home/alex/
      

      Warnung: Wie in Schritt 2 erwähnt, gelten in einer OpenSSH-Konfigurationsdatei alle Konfigurationen unter einem Match-Block nur für Verbindungen, die den Kriterien entsprechen, unabhängig von Einrückung oder Zeilenumbrüchen. Daher müssen Sie vorsichtig sein und sicherstellen, dass Konfigurationen, die zur globalen Anwendung bestimmt sind, nicht versehentlich in einen Match-Block eingestellt werden. Um das zu vermeiden, wird empfohlen, alle Match-Blocks an das untere Ende Ihrer Konfigurationsdatei zu stellen.

      Speichern und schließen Sie Ihre Konfigurationsdatei, und testen Sie die Konfiguration erneut:

      Wenn es keine Fehler gibt, können Sie dann Ihre Konfiguration anwenden:

      Dadurch wurde eine robuste Konfiguration für den Benutzer alex erstellt, bei der interaktive Anmeldungen deaktiviert sind, und alle SFTP-Aktivitäten sind auf das Stammverzeichnis des Benutzers beschränkt. Aus der Perspektive des Benutzers ist das Verzeichnis des Systems – d. h. / – ihr Stammverzeichnis. Er ist nicht in der Lage, das Dateisystem nach oben zu durchlaufen, um auf andere Bereiche zuzugreifen.

      Sie haben die nologin-Shell für einen Benutzer implementiert und dann eine Konfiguration erstellt, um den SFTP-Zugriff auf ein bestimmtes Verzeichnis zu beschränken.

      Schritt 4 — Erweiterte Härtung

      In diesem abschließenden Schritt implementieren Sie verschiedene zusätzliche Härtungsmaßnahmen, um den Zugriff auf Ihren SSH-Server so sicher wie möglich zu machen.

      Eine weniger bekannte Funktion des OpenSSH-Servers ist die Fähigkeit, Beschränkungen auf einer Pro-Schlüssel-Basis aufzuerlegen. Das sind Beschränkungen, die nur für bestimmte öffentliche Schlüssel gelten, die in der Datei .ssh/authorized_keys vorhanden sind. Das ist besonders nützlich, um den Zugriff bei Machine-to-Machine-Sitzungen zu kontrollieren und um auch Nicht-Sudo-Benutzern zu ermöglichen, die Beschränkungen für das eigene Benutzerkonto zu kontrollieren.

      Sie können die meisten dieser Beschränkungen auf System- oder Benutzerebene anwenden. Es ist jedoch immer noch von Vorteil, sie auch auf der Schlüsselebene zu implementieren, um eine tief greifende Abwehr und eine zusätzliche Ausfallsicherheit im Falle versehentlicher systemweiter Konfigurationsfehler zu gewährleisten.

      Anmerkung: Sie können diese zusätzlichen Sicherheitskonfigurationen nur implementieren, wenn Sie die SSH-Authentifizierung mit öffentlichen Schlüsseln verwenden. Wenn Sie nur Passwort-Authentifizierung verwenden oder über eine komplexere Einrichtung wie eine-SSH-Zertifizierungsstelle verfügen, können Sie diese leider nicht nutzen.

      Öffnen Sie zunächst Ihre .ssh/authorized_keys-Datei in Ihrem bevorzugten Texteditor:

      • nano ~/.ssh/authorized_keys

      Anmerkung: Da diese Konfigurationen auf einer Pro-Schlüssel-Basis gelten, müssen Sie jeden einzelnen Schlüssel, für den diese gelten sollen, innerhalb jeder einzelnen authorized_keys-Datei bearbeiten, für alle Benutzer auf Ihrem System. Normalerweise müssen Sie nur einen Schlüssel/eine Datei bearbeiten. aber es ist die Überlegung wert, wenn Sie über ein komplexes Mehrbenutzersystem verwenden.

      Nach dem Öffnen Ihrer authorized_keys-Datei sehen Sie, dass jede Zeile einen öffentlichen SSH-Schlüssel enthält, der höchstwahrscheinlich mit etwas Ähnlichem wie ssh-rsa AAAB... beginnt. Weitere Konfigurationsoptionen können am Anfang der Zeile hinzugefügt werden; diese gelten nur für erfolgreiche Authentifizierungen mit diesem bestimmten öffentlichen Schlüssel.

      Folgende Beschränkungsoptionen stehen zur Verfügung:

      • no-agent-forwarding: Deaktivieren des SSH-Agent-Forwardings.
      • no-port-forwarding: Deaktivieren des Port-Forwardings.
      • no-pty: Deaktivieren der Fähigkeit, einen tty zuzuweisen (d. h. eine Shell zu starten).
      • no-user-rc: Verhindern der Ausführung der Datei ~/.ssh/rc.
      • no-X11-forwarding: Deaktivieren des X11-Display-Forwardings.

      Sie können diese anwenden, um bestimmte SSH-Funktionen für bestimmte Schlüssel zu deaktivieren. Um zum Beispiel Agent-Forwarding und X11-Forwarding für einen Schlüssel zu deaktivieren, verwenden Sie die folgende Konfiguration:

      ~/.ssh/authorized_keys

      no-agent-forwarding,no-X11-forwarding ssh-rsa AAAB...
      

      Standardmäßig arbeiten diese Konfigurationen nach der Methode „standardmäßig zulassen, ausnahmsweise blockieren“. Es ist jedoch auch möglich, „standardmäßig blockieren, ausnahmsweise zulassen“ zu verwenden, was zur Gewährleistung der Sicherheit generell vorzuziehen ist.

      Hierzu können Sie die Option restrict verwenden, die implizit alle SSH-Funktionen für den spezifischen Schlüssel ablehnt und verlangt, dass diese nur dort neu aktiviert werden, wo sie unbedingt erforderlich sind. Sie können Funktionen mit denselben zuvor in dieser Anleitung beschriebenen Konfigurationsoptionen neu aktivieren, jedoch ohne das Präfix no-.

      Um z. B. alle SSH-Funktionen außer das X11-Display-Forwarding für einen bestimmten Schlüssel zu deaktivieren, können Sie die folgende Konfiguration verwenden:

      ~/.ssh/authorized_keys

      restrict,X11-forwarding ssh-rsa AAAB...
      

      Ziehen Sie auch die Verwendung der Option command in Betracht, die der in Schritt 3 beschriebenen Option ForceCommand sehr ähnelt. Sie bietet keinen direkten Vorteil, wenn Sie bereits ForceCommand nutzen, dient aber als eine gute tief greifende Abwehr für den unwahrscheinlichen Fall, dass die Hauptkonfigurationsdatei des OpenSSH-Servers überschrieben, bearbeitet etc. wird.

      Um beispielsweise Benutzer, die sich über einen bestimmten Schlüssel authentifizieren, zu zwingen, bei der Anmeldung einen bestimmten Befehl auszuführen, können Sie die folgende Konfiguration hinzufügen:

      ~/.ssh/authorized_keys

      command="top" ssh-rsa AAAB...
      

      Warnung: Die command-Konfigurationsoption fungiert lediglich als tief greifende Abwehrmethode. Sie sollte nicht als einzige Methode zur Beschränkung von Aktivitäten eines SSH-Benutzers genutzt werden, da es je nach Ihrer Arbeitsumgebung möglicherweise Wege gibt, sie zu überschreiben oder zu umgehen. Stattdessen sollten Sie die Konfiguration zusammen mit den anderen in diesem Artikel beschriebenen Kontrollen verwenden.

      Um schließlich die in Schritt 3 erstellten Pro-Schlüssel-Beschränkungen für den Nur-SFTP-Benutzer optimal zu nutzen, können Sie die folgende Konfiguration verwenden:

      ~/.ssh/authorized_keys

      restrict,command="false" ssh-rsa AAAB...
      

      Die Option restrict deaktiviert jeden interaktiven Zugriff. Die Option command="false" fungiert als zweite Verteidigungslinie für den Fall, dass die Option ForceCommand oder die nologin-Shell fehlschlagen sollten.

      Speichern und schließen Sie die Datei, um die Konfiguration anzuwenden. Diese wird sofort für alle neuen Anmeldungen wirksam. Daher müssen Sie OpenSSH nicht manuell neu laden.

      In diesem abschließenden Schritt haben Sie einige zusätzliche erweiterte Härtungsmaßnahmen für OpenSSH-Server implementiert, indem Sie die benutzerdefinierten Optionen in Ihrer .ssh/authorized_keys Datei verwendet haben.

      Zusammenfassung

      In diesem Artikel haben Sie die Konfiguration Ihres OpenSSH-Servers geprüft und verschiedene Härtungsmaßnahmen implementiert, um Ihren Server zu sichern.

      Dadurch wurde die Angriffsfläche Ihres Servers insgesamt verringert, indem nicht genutzte Funktionen deaktiviert und der Zugriff bestimmter Benutzer gesperrt wurde.

      Konsultieren Sie bei Bedarf auch die manuellen Seiten für OpenSSH-Server und die zugehörige Konfigurationsdatei, um mögliche weitere Optimierungen zu finden, die Sie eventuell vornehmen möchten.



      Source link

      Installieren und Konfigurieren von Postfix als Send-Only-SMTP-Server unter Ubuntu 20.04


      Der Autor wählte den Free and Open Source Fund, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      Postfix ist ein Mail Transfer Agent (MTA), eine Anwendung zum Senden und Empfangen von E-Mail. Er kann so konfiguriert werden, dass er sich nur zum Senden von E-Mails durch lokale Anwendungen verwenden lässt. Das ist in Fällen nützlich, in denen Sie regelmäßig E-Mail-Benachrichtigungen von Ihren Anwendungen senden oder über viel ausgehenden Datenverkehr verfügen, den E-Mail-Drittanbieter nicht zulassen. Außerdem handelt es sich dabei um eine schlankere Alternative zur Ausführung eines kompletten SMTP-Servers, die dennoch die erforderliche Funktionalität bietet.

      In diesem Tutorial installieren und konfigurieren Sie Postfix als Send-Only-SMTP-Server. Außerdem werden Sie für Ihre Domäne kostenlose TLS-Zertifikate von Let’s Encrypt anfordern und ausgehende E-Mails damit verschlüsseln.

      Voraussetzungen

      • Ein Ubuntu 20.04-Server, der gemäß Ersteinrichtung eines Servers unter Ubuntu 20.04 eingerichtet wurde, einschließlich eines non-root user mit sudo-Berechtigungen.
      • Einen vollständig registrierten Domänennamen. Dieses Tutorial verwendet in allen Bereichen your_domain. Sie können einen Domänennamen unter Namecheap günstig erwerben oder einen kostenlosen von Freenom herunterladen,. oder einfach die Domänenregistrierngsstelle Ihrer Wahl verwenden.
      • Ein A-DNS-Eintrag mit your-domain, der auf die öffentliche IP-Adresse Ihres Servers verweist. Sie finden in dieser Einführung in DigitalOcean DNS Details dazu, wie Sie sie hinzufügen können.

      Anmerkung: Der Hostname Ihres Servers und der Name Ihres Droplets müssen your_domain entsprechen, da DigitalOcean anhand des Namens automatisch PTR-Einträge für die IP-Adresse des Droplets festlegt.

      Sie können den Hostnamen des Servers überprüfen, indem Sie hostname in der Eingabeaufforderung eingeben. Die Ausgabe sollte mit dem Namen übereinstimmen, den Sie dem Droplet bei der Erstellung gegeben haben.

      Schritt 1 — Installieren von Postfix

      In diesem Schritt installieren Sie Postfix. Die schnellste Methode besteht aus der Installation des Pakets mailutils, in dem Postfix mit einigen zusätzlichen Programmen gebündelt ist, die Sie zum Testversand von E-Mails verwenden werden.

      Aktualisieren Sie zuerst die Paketdatenbank:

      Installieren Sie dann Postfix, indem Sie den folgenden Befehl ausführen:

      • sudo apt install mailutils

      Kurz vor Ende der Installation wird Ihnen das Postfix-Konfigurationsfenster angezeigt:

      Wählen Sie „Internet Site“ (Internetsite) aus dem Menü; drücken Sie zum Auswählen TAB<Ok>und dann ENTER.

      Die Standardoption lautet Internet Site (Internetseite). Das ist die empfohlene Option für Ihren Anwendungsfall. Drücken Sie also TAB und dann ENTER. Wenn Sie nur den Beschreibungstext sehen, drücken Sie TAB, um OK zu wählen, und dann ENTER.

      Wenn die Anzeige nicht automatisch erfolgt, führen Sie zum Starten den folgenden Befehl aus:

      • sudo dpkg-reconfigure postfix

      Danach erhalten Sie eine weitere Konfigurationsaufforderung in Bezug auf den System-E-Mail-Namen:

      Geben Sie Ihren Domänenamen ein und drücken Sie zum Auswählen TAB sowie<Ok>ENTER.

      Der System-E-Mail-Name muss gleich sein wie der Name, den Sie bei der Erstellung Ihres Servers zugewiesen haben. Wenn Sie damit fertig sind, drücken Sie TAB, gefolgt von ENTER.

      Sie haben Postfix jetzt installiert und können mit der Konfiguration beginnen.

      Schritt 2 — Konfigurieren von Postfix

      In diesem Schritt konfigurieren Sie Postfix so, dass E-Mails nur von dem Server gesendet und empfangen werden, auf dem Postfix ausgeführt wird – d. h. von localhost.

      Dazu muss Postfix so konfiguriert werden, dass nur an der Loopback-Schnittstelle gelauscht wird; das ist die virtuelle Netzwerkschnittstelle, die der Server zur internen Kommunikation verwendet. Um die Änderungen vorzunehmen, müssen Sie die Hauptkonfigurationsdatei von Postfix namens main.cf bearbeiten, die unter etc/postfix gespeichert ist.

      Öffnen Sie sie zum Bearbeiten in Ihrem bevorzugten Texteditor:

      • sudo nano /etc/postfix/main.cf

      Suchen Sie nach den folgenden Zeilen:

      /etc/postfix/main.cf

      . . .
      mailbox_size_limit = 0
      recipient_delimiter = +
      inet_interfaces = all
      . . .
      

      Setzen Sie den Wert von inet_interfaces auf loopback-only:

      /etc/postfix/main.cf

      . . .
      mailbox_size_limit = 0
      recipient_delimiter = +
      inet_interfaces = loopback-only
      . . .
      

      Eine weitere Anweisung, die Sie ändern müssen, ist mydestination; sie gibt die Liste der Domänen an, die über den Mail Delivery Transport local_transport bereitgestellt werden. Standardmäßig sehen die Werte etwa wie folgt aus:

      /etc/postfix/main.cf

      . . .
      mydestination = $myhostname, your_domain, localhost.com, , localhost
      . . .
      

      Ändern Sie die Zeile, damit sie wie folgt aussieht:

      /etc/postfix/main.cf

      . . .
      mydestination = localhost.$mydomain, localhost, $myhostname
      . . .
      

      Wenn Ihre Domäne in Wahrheit eine Subdomäne ist und Sie möchten, dass E-Mail-Nachrichten aussehen, als wären sie von der Hauptdomäne gesendet worden, können Sie am Ende von main.cf die folgende Zeile hinzufügen:

      /etc/postfix/main.cf

      ...
      masquerade_domains = your_main_domain
      

      Die optionale Einstellung masquerade_domains gibt an, bei welchen Domänen der Subdomänenteil in der E-Mail-Adresse entfernt wird.

      Wenn Sie fertig sind, speichern und schließen Sie die Datei.

      Anmerkung: Wenn Sie mehrere Domänen auf einem Server hosten, können die anderen Domänen mit der Anweisung mydestination ebenfalls an Postfix übergeben werden.

      Starten Sie dann Postfix neu, indem Sie den folgenden Befehl ausführen:

      • sudo systemctl restart postfix

      Sie haben Postfix so konfiguriert, dass von Ihrem Server nur E-Mails gesendet werden. Sie werden dies nun testen, indem Sie eine Beispielnachricht an eine E-Mail-Adresse senden.

      Schritt 3 — Testen des SMTP-Servers

      Im diesem Schritt testen Sie, ob Postfix E-Mails mit dem Befehl mail an ein externes E-Mail-Konto senden kann. Dieser Befehl ist Teil des Pakets mailutils, das Sie im ersten Schritt installiert haben.

      Um eine Test-E-Mail zu senden, führen Sie den folgenden Befehl aus:

      • echo "This is the body of the email" | mail -s "This is the subject line" your_email_address

      Sie können den Text und den Betreff der E-Mail nach Ihren Wünschen ändern. Denken Sie daran, your_email_address durch eine gültige E-Mail-Adresse zu ersetzen, auf die Sie zugreifen können.

      Überprüfen Sie nun die E-Mail-Adresse, an die Sie diese Nachricht gesendet haben. Sie sollten die Nachricht in Ihrem Posteingang sehen. Wenn Sie sie dort nicht finden können, sehen Sie in Ihrem Spam-Ordner nach. Bislang sind alle von Ihnen gesendeten E-Mails unverschlüsselt, weswegen Dienstanbieter denken, dass es wahrscheinlich Spam-Nachrichten sind. Im Schritt 5 richten Sie die Verschlüsselung ein.

      Wenn Sie einen Fehler vom Befehl mail erhalten oder auch nach längerer Zeit keine Nachricht empfangen haben, dann vergewissern Sie sich, dass die von Ihnen bearbeitete Postfix-Konfiguration gültig ist und der Name sowie Hostname Ihres Servers auf Ihre Domäne festgelegt sind.

      Achten Sie darauf, dass bei dieser Konfiguration die Adresse im Feld From für die von Ihnen gesendeten Test-E-Mails in Format your_user_name@your_domain vorliegt, wobei your_user_name der Benutzername des Serverbenutzers ist, als der Sie den Befehl ausgeführt haben.

      Sie haben nun eine E-Mail von Ihrem Server gesendet und überprüft, ob sie erfolgreich empfangen wurde. Im nächsten Schritt richten Sie die E-Mail-Weiterleitung für root ein.

      Schritt 4 — Weiterleitung von System-E-Mail

      Im diesem Schritt richten Sie eine E-Mail-Weiterleitung für den Benutzer root ein, damit systemgenerierte Nachrichten, die auf Ihrem Server an ihn gesendet werden, an eine externe E-Mail-Adresse weitergeleitet werden.

      Die Datei /etc/aliases enthält eine Liste von alternativen Namen für E-Mail-Empfänger. Öffnen Sie sie zum Bearbeiten:

      Im Standardzustand sieht sie wie folgt aus:

      /etc/aliases

      # See man 5 aliases for format
      postmaster:    root
      

      Die einzige vorhandene Anweisung gibt an, dass systemgenerierte E-Mails an root gesendet werden.

      Fügen Sie am Ende der Datei die folgende Zeile hinzu:

      /etc/aliases

      ...
      root:          your_email_address
      

      Mit dieser Zeile geben Sie an, dass an root gesendete E-Mails an eine E-Mail-Adresse weitergeleitet werden. Denken Sie daran, your_email_address durch Ihre persönliche E-Mail-Adresse zu ersetzen. Wenn Sie fertig sind, speichern und schließen Sie die Datei.

      Um die Änderung anzuwenden, führen Sie den folgenden Befehl aus:

      Durch Ausführung von newaliases wird eine Datenbank mit Aliassen erstellt, die der Befehl mail verwendet. Die Aliasse werden aus der Konfigurationsdatei übernommen, die Sie gerade bearbeitet haben.

      Testen Sie, ob E-Mails an root gesendet werden, indem Sie Folgendes ausführen:

      • echo "This is the body of the email" | mail -s "This is the subject line" root

      Sie sollten die E-Mail unter Ihrer E-Mail-Adresse erhalten. Wenn Sie sie dort nicht finden können, sehen Sie in Ihrem Spam-Ordner nach.

      In diesem Schritt haben Sie eine Weiterleitung systemgenerierter Nachrichten an Ihre E-Mail-Adresse eingerichtet. Sie aktivieren jetzt die Nachrichtenverschlüsselung, damit alle E-Mails, die Ihr Server versendet, sicher vor Manipulation bei der Übertragung sind und als legitimer betrachtet werden.

      Schritt 5 — Aktivieren von SMTP-Verschlüsselung

      Sie aktivieren jetzt SMTP-Verschlüsselung, indem Sie für Ihre Domäne ein kostenloses TLS-Zertifikat von Let’s Encrypt anfordern (mit Certbot) und Postfix so konfigurieren, dass das Zertifikat zum Senden von Nachrichten verwendet wird.

      Ubuntu enthält Certbot in seinen standardmäßigen Paket-Repositorys, sodass Sie für dessen Installation den folgenden Befehl ausführen können:

      Wenn Sie zur Bestätigung aufgefordert werden, geben Sie J ein und drücken Sie die Eingabetaste.

      Im Rahmen der Ersteinrichtung des Servers in den Voraussetzungen haben Sie ufw, die unkomplizierte Firewall, installiert. Sie müssen sie so konfigurieren, dass der HTTP-Port 80 zugelassen wird, damit die Verifizierung der Domäne abgeschlossen werden kann. Führen Sie den folgenden Befehl aus, um ihn zu aktivieren:

      Die Ausgabe sieht in etwa folgendermaßen aus:

      Output

      Rule added Rule added (v6)

      Nachdem der Port nun geöffnet ist, führen Sie Certbot aus, um ein Zertifikat zu erhalten:

      • sudo certbot certonly --standalone --rsa-key-size 4096 --agree-tos --preferred-challenges http -d your_domain

      Dieser Befehl weist Certbot dazu an, Zertifikate mit einer RSA-Schlüsselgröße von 4096 Bits auszugeben, einen temporären Standalone-Webserver (--standalone) zur Verifizierung auszuführen und die Prüfung über Port 80 (--preferred-challenges http) vorzunehmen. Denken Sie daran, your_domain durch Ihre Domäne zu ersetzen, bevor Sie den Befehl ausführen, und geben Sie bei Aufforderung Ihre E-Mail-Adresse ein.

      Die Ausgabe sieht ungefähr wie folgt aus:

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for `your_domain` Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem Your cert will expire on 2020-07-11. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

      Wie in den Anmerkungen erwähnt, wurden Ihr Zertifikat und Ihre private Schlüsseldatei unter /etc/letsencrypt/live/your_domain gespeichert.

      Nachdem Sie über das Zertifikat verfügen, öffnen Sie nun main.cf zum Bearbeiten:

      • sudo nano /etc/postfix/main.cf

      Suchen Sie nach dem folgenden Abschnitt:

      /etc/postfix/main.cf

      # TLS parameters
      smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
      smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
      smtpd_tls_security_level=may
      
      smtp_tls_CApath=/etc/ssl/certs
      smtp_tls_security_level=may
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      

      Ändern Sie ihn, damit er wie folgt aussieht, wobei Sie your_domain ggf. durch Ihre Domäne ersetzen. Dadurch werden Ihre TLS-Einstellungen für Postfix aktualisiert:

      /etc/postfix/main.cf

      # TLS parameters
      smtpd_tls_cert_file=/etc/letsencrypt/live/your_domain/fullchain.pem
      smtpd_tls_key_file=/etc/letsencrypt/live/your_domain/privkey.pem
      smtpd_tls_security_level=may
      
      smtp_tls_CApath=/etc/ssl/certs
      smtp_tls_security_level=may
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      

      Wenn Sie damit fertig sind, speichern und schließen Sie die Datei.

      Wenden Sie die Änderungen durch Neustart von Postfix an:

      • sudo systemctl restart postfix

      Versuchen Sie nun, erneut eine E-Mail zu senden:

      • echo "This is the body of an encrypted email" | mail -s "This is the subject line" your_email_address

      Überprüfen Sie dann die von Ihnen angegebene E-Mail-Adresse. Es ist möglich, dass Sie die Nachricht sofort in Ihrem Posteingang sehen, da E-Mail-Anbieter verschlüsselte Nachrichten deutlich seltener als Spam markieren.

      Sie können die technischen Informationen über die E-Mail-Nachricht in Ihrem Client prüfen, um zu sehen, ob die Nachricht tatsächlich verschlüsselt wurde.

      Zusammenfassung

      Sie verfügen nun über einen Send-Only-E-Mail-Server, der von Postfix bereitgestellt wird. Das Verschlüsseln aller ausgehenden Nachrichten ist ein guter erster Schritt, damit E-Mail-Anbieter Ihre Nachrichten nicht von vornherein als Spam markieren. Wenn Sie das in einem Entwicklungsszenario tun, sollte diese Maßnahme ausreichen.

      Wenn Ihr Anwendungsfall jedoch darin besteht, E-Mails an potenzielle Websitebenutzer zu senden (wie Bestätigungs-E-Mails für die Anmeldung bei einem Nachrichtenforum), sollten Sie sich mit der Einrichtung von SPF-Einträgen befassen, damit E-Mails Ihres Servers mit noch höherer Wahrscheinlichkeit als legitim gelten.



      Source link