Welche Schritte unternehmen Sie, um einen Debian-Server zu sichern? [geschlossen]

Ich installiere einen Debian-Server, der direkt mit dem Internet verbunden ist. Natürlich möchte ich es so sicher wie möglich machen. Ich möchte, dass ihr Jungs / Mädels eure Ideen hinzufügt, um es zu sichern und welche Programme ihr dafür benutzt.

Ich möchte, dass ein Teil dieser Frage behandelt, was Sie als Firewall verwenden. Nur iptables manuell konfiguriert oder verwenden Sie irgendeine Software, um Ihnen zu helfen? Was ist der beste Weg? Alles blockieren und nur das zulassen, was benötigt wird? Gibt es vielleicht gute Tutorials für Anfänger zu diesem Thema?

Ändern Sie Ihren SSH-Port? Verwenden Sie Software wie Fail2Ban , um Bruteforce-Angriffe zu verhindern?

Obligatorisch:

• Installation des Systems mit Expertenmodus, nur Pakete, die ich brauche
• Handgeschriebene Firewall mit Standardrichtlinie für iptables'input: drop, ermöglicht den Zugriff auf SSH, HTTP oder was auch immer auf dem Server läuft
• Fail2Ban für SSH [und manchmal FTP / HTTP / andere - je nach Kontext]
• Deaktivieren Sie Root-Anmeldungen, erzwingen Sie die Verwendung von normalen Benutzern und sudo
• kundenspezifischer Kernel [nur alte Gewohnheit]
• Geplante Systemaktualisierung

Je nach Grad der Paranoia zusätzlich:

• Drop-Richtlinie für die Ausgabe mit Ausnahme einiger zulässiger Ziele / Ports
• integritum zu überprüfen, ob einige Teile des Dateisystems nicht geändert wurden [mit einer außerhalb des Computers gespeicherten Prüfsumme], z. B. Tripwire
• Geplanter Scan mindestens mit nmap des Systems von außen
• automatische Log-Überprüfung auf unbekannte Muster
• Geplante Ausführung von chkrootkit
• unveränderliches Attribut /etc/passwd, um neue Benutzer hinzuzufügen, ist etwas schwieriger
• / tmp mit noexec gemountet
• Port Knocker oder eine andere nicht standardmäßige Methode zum Öffnen von SSH-Ports [z. B. der Besuch einer "geheimen" Webseite auf einem Webserver ermöglicht den zeitlich begrenzten Eingang einer SSH-Verbindung über eine IP-Adresse, die die Seite aufgerufen hat. Wenn Sie eine Verbindung herstellen, müssen Sie -m state --satete ESTABLISHEDden Paketfluss zulassen, solange Sie eine einzelne SSH-Sitzung verwenden.]

Dinge, die ich nicht selbst tue, aber sinnvoll finde:

• grsecurity für den Kernel
• Remote-Syslog, damit Protokolle nicht überschrieben werden können, wenn das System kompromittiert wird
• Benachrichtigung über alle SSH-Anmeldungen
• Konfigurieren Sie rkhunter und richten Sie es so ein, dass es von Zeit zu Zeit ausgeführt wird

Nur ein Hinweis zum Firewalling Ihres Rechners ...

• Verwenden Sie eine Whitelist, keine Blacklist - dh blockieren Sie alles und lassen Sie nur das zu, was Sie brauchen, verweigern Sie alles andere.
• Verwenden Sie keine GUIs / ncurses oder andere Software, die versucht, Ihre Firewall für Sie zu schreiben. Wenn Sie dies tun, werden Sie zulassen, dass die Software Annahmen für Sie trifft - Sie müssen dieses Risiko nicht eingehen und sollten dies auch nicht tun. Konfigurieren Sie es selbst. Wenn Sie sich nicht sicher sind, deaktivieren Sie es. Sie werden früh genug herausfinden, ob es erforderlich ist. Wenn es bereits ein lauffähiges System ist und Sie den Datenverkehr nicht stören können (indem Sie ihn versehentlich blockieren), führen Sie tcpdump (dump to file) aus und nehmen Sie Beispiele - studieren Sie sie später und finden Sie dann heraus, was gültig ist und was nicht.
• Ich persönlich sehe keinen Grund darin, einen Dienst auf einem nicht standardmäßigen Port auszuführen. Die Tools sind heutzutage nicht so dumm anzunehmen, dass etwas auf Port 22 ausgeführt wird, dann muss es ssh sein und nicht anders - z Beispiel amapund nmap's -AOption. Sie können (und sollten wahrscheinlich auch, wenn Sie sich Sorgen machen) Ihre Dienste so ändern, dass sie sich vor neugierigen Blicken verstecken. Die folgenden Informationen geben dem Angreifer beispielsweise Auskunft über die genaue Version, auf der OpenSSHSie ausgeführt werden, und können dann nach Exploits suchen genau diese Version. Wenn Sie solche Dinge verstecken, würden Sie es ihnen schwerer machen.

    [root @ ud-olis-1 uhtbin] # telnet localhost 22
    127.0.0.1 wird versucht ...
    Verbunden mit localhost.localdomain (127.0.0.1).
    Escape-Zeichen ist '^]'.
    SSH-2.0-OpenSSH_3.9p1

• Halten Sie alle öffentlichen Dienste auf dem neuesten Stand und aktualisieren Sie sie mit den neuesten Sicherheitspatches.
• Speichern Sie keine DATEN auf dem Gatewayserver selbst. Zumindest gewinnen Sie Zeit, wenn sie in diesen Computer eindringen, und Sie verlieren den einen oder anderen Dienst und einige Zeit, aber keine Daten.

Fazit ist, dass es Ihnen nie gelingen wird, etwas 100% sicherer zu machen - das ist einfach nicht möglich - das Ziel ist es, so sicher wie möglich zu machen - wenn es nur zu viel Aufwand ist, um Ihr System zu beschädigen, ist es gut genug und die meisten lamer script-kiddies wechseln auf das nächste system.

• iptables ist der richtige Weg für jedes Linux-System - aber konfigurieren Sie es selbst.

Verwenden Sie niemals eine "Sicherheitssoftware", die nicht auf offenen Standards basiert - sie ist dazu verdammt, schlecht geschrieben zu sein und wird gehackt (keine Frage von "ob", sondern "wann"). Open Source und Open Protocols sind öffentlich zugänglich und werden zu einem ausgereiften und zuverlässigen Produkt. Closed-Source - Software beruht vor allem auf dem Autoren Selbstvertrauen, wie groß / secure-a-Produkt sie denken , es ist - dh eine kleine Anzahl von Augen gegen eine Erde voller Augen.

Ich hoffe, das hilft :)

• Deaktivieren Sie die Root-Anmeldung
• Login per Passwort deaktivieren (nur Login per Public-Key zulassen)
• Ändern Sie den SSH-Port

• benutze denyhosts (oder ähnliches)

• Schreiben Sie Ihr eigenes Iptbles-Skript (damit Sie genau steuern können, was zugelassen werden soll, und alles andere ablegen können)

• Erzwingen Sie die Verwendung von SSL / TLS-gesicherter Kommunikation und stellen Sie sicher, dass gültige, nicht abgelaufene und signierte Zertifikate vorhanden sind

• Aktivieren Sie die strikte Zertifikatüberprüfung für alle externen Dienste (z. B. beim Authentifizieren von Benutzern mit einem LDAP-Server auf einem anderen Computer).

Fang hier an:

http://www.debian.org/doc/manuals/securing-debian-howto/

Als allgemeinen Ausgangspunkt folge ich den Benchmark / Leitfäden des Center for Internet Security , die umfassende Zusammenstellungen von Best Practices für die Sicherheit darstellen. Es sieht nicht so aus, als ob ihr Debian-Benchmark in einiger Zeit aktualisiert wurde, aber ein allgemeiner Überblick über die Schritte ist:

• Wenden Sie die neuesten Betriebssystem-Patches / -Pakete an
• Aktivieren Sie die System- / Kernel- / Prozessabrechnung.
• Aktivieren Sie MAC (z. B. SELinux oder AppArmor).
• Aktivieren Sie die hostbasierte Firewall (iptables).
• Überprüfen Sie die APT sources.list (Schlüssel sind korrekt, Quellen sind vertrauenswürdig).
• Minimieren Sie die Netzwerkdienste, deaktivieren Sie alle nicht erforderlichen Funktionen und installieren Sie die Firewall.
• Verwenden Sie TCPWrappers, um den Systemzugriff weiter einzuschränken.
• Verwenden Sie nur verschlüsselte Netzwerkprotokolle. Deaktivieren Sie unverschlüsselte Dienste (Telnet, FTP usw.).
• Konfigurieren Sie den Remotezugriff nur auf SSH.
• Deaktivieren Sie die Benutzeranmeldungskennwörter und erfordern Sie eine schlüsselbasierte Authentifizierung.
• Deaktivieren Sie die Dateisystemfreigabe (NFS, SMB).
• Aktivieren Sie die Remote- / zentrale Systemprotokollierung (und überprüfen Sie regelmäßig die Protokolle!).
• Legen Sie ein Kennwort für die BIOS- / Firmware-Ebene fest.
• Legen Sie ein Bootloader-Passwort fest.
• Konfigurieren Sie System-Backups, führen Sie einen Disaster Recovery-Plan durch und testen Sie, ob die Backups gültig sind und ob das Personal mit Disaster Recovery-Verfahren vertraut ist!

Es gibt viele Ressourcen für all diese verschiedenen Einstellungen, einschließlich der spezifischen Befehle und Konfigurationsdateien, die in den CISecurity-Benchmarks auf dem System implementiert werden müssen.

Ich würde vorschlagen, keine Maschine direkt an das Internet anzuschließen. Platzieren Sie eine Art Firewall zwischen dem Computer und dem Internet. Auf diese Weise können Sie die Sicherheit und das Netzwerk überwachen, ohne den Server stärker zu belasten. Persönlich finde ich, dass Netzwerk- und Funktionssegmentierung häufig die Fehlerbehebung im Netzwerk vereinfacht, obwohl die zusätzliche Komplexität gelegentlich die Analyse erschwert.

Die sicherste, aber am ärgerlichsten zu verwaltende Firewall-Richtlinie besteht darin, alle zu verweigern und explizit nur den Verkehr zuzulassen, den Sie zulassen müssen. Dies ist ärgerlich, da die Firewall-Richtlinie häufig aktualisiert werden muss, wenn sich das Netzwerk ändern muss.

Ich würde auch vorschlagen, eine Art Firewall für die Benutzeroberfläche auf dem Server zu verwenden - die Tiefenverteidigung ist der Schlüssel. Die Verwendung von nicht standardmäßigen Ports für verwaltungsbezogene Dienste schadet nicht. fail2ban ist in ordnung. Befolgen Sie die genaueren Fragen zu Sicherheitsanwendungen in Serverfault, um weitere Ideen zu finden.

Sicherheit ist wie ein Scherz über die beiden Wanderer und den Bären - während man nie perfekte Sicherheit erreichen kann, ist es hilfreich, ein schwierigeres Ziel zu sein als die anderen.

Einige Leute haben auf das Securing Debian Manual hingewiesen . Dies sollte für alles außer für militärische Anforderungen völlig ausreichend sein.

Viele Leute denken, lächerlich paranoid zu sein, ist cool oder professionell oder so. Es ist nicht so , es ist nur ärgerlich für andere Administratoren und geradezu repressiv für Ihre Benutzer. Die meisten Dinge, die Sie als empfehlenswert erachten, sind nur gefälschte Aktivitäten, um sich für den paranoiden Administrator nützlich zu fühlen, aber nicht wirklich hilfreich, da die eigentliche Sicherheitsverletzung wahrscheinlich durch ein nicht ausreichend aktualisiertes System und / oder eine interne Quelle verursacht wird.

Ich halte es jedoch für einen meiner Grundsätze, dem lokalen Netzwerk nicht mehr zu vertrauen als dem Internet. Daher konfiguriere ich alles so, dass eine Authentifizierung auch im lokalen Netzwerk erforderlich ist. Ich verschlüssele und authentifiziere den gesamten Datenverkehr zwischen allen Computern mithilfe von IPsec.

Ich bin gerade dabei, alle meine Server auf Festplattenverschlüsselung umzustellen.

Ich installiere nur die Dienste, die ich benutze. Ich habe keine Firewall. Ich konfiguriere die Dienste, für die eine Authentifizierung erforderlich ist, oder beschränke sie (durch die eigene Konfiguration des Programms oder durch TCP-Wrapper) auf bestimmte IP-Adressen. Das einzige, was ich jemals mit iptables blockieren musste, war memcached, dass es keine Konfigurationsdatei und keine TCP-Wrapper gab.

Ich verwende gute, zufällig generierte Passwörter für meine Konten und vertraue meinem SSH-Server (und allen anderen Diensten), um diejenigen fernzuhalten, die das Passwort nicht kennen. fail2banist nur für diejenigen mit begrenztem Speicherplatz für Protokolldateien, IMO. (Sie sollten über ausreichend gute Passwörter verfügen, um diesen vertrauen zu können.)

Gehen Sie diese Anleitung unter www.debian.org/doc/manuals/securing-debian-howto/ durch.

Ich persönlich ändere den ssh-Port und verwende fail2ban + denyhosts. Und ich blockiere alles, was nicht gebraucht wird. Je mehr Sie blockieren, desto weniger müssen Sie sich Sorgen machen.