it-swarm.com.de

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

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 sie zu sichern und welche Programme ihr dafür verwendet.

Ich möchte, dass ein Teil dieser Frage behandelt, was Sie als Firewall verwenden. Nur iptables manuell konfiguriert oder verwenden Sie eine 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?

66
Thomaschaaf

Obligatorisch:

  • installation des Systems mit Expertenmodus, nur Pakete, die ich brauche
  • handgeschriebene Firewall mit Standardrichtlinie für den Eingang von iptables: Löschen, Ermöglichen des Zugriffs auf SSH, HTTP oder einen anderen Server
  • Fail2Ban für SSH [und manchmal FTP/HTTP/andere - je nach Kontext]
  • deaktivieren Sie Root-Anmeldungen, erzwingen Sie die Verwendung mit normalem Benutzer und Sudo
  • benutzerdefinierter Kernel [nur alte Gewohnheit]
  • geplantes System-Upgrade

Je nach Grad der Paranoia zusätzlich:

  • löschen Sie die Ausgaberichtlinie mit Ausnahme einiger zulässiger Ziele/Ports
  • integrit zum Überprüfen, ob einige Teile des Dateisystems nicht geändert wurden [mit Prüfsumme außerhalb des Computers], zum Beispiel Tripwire
  • geplanter Scan mindestens mit nmap des Systems von außen
  • automatische Protokollprüfung auf unbekannte Muster [dies dient jedoch hauptsächlich dazu, Hardwarefehler oder kleinere Abstürze zu erkennen]
  • geplanter Lauf von chkrootkit
  • unveränderliches Attribut für /etc/passwd Das Hinzufügen neuer Benutzer ist daher etwas schwieriger
  • / tmp mit noexec gemountet
  • port Knocker oder eine andere nicht standardmäßige Methode zum Öffnen von SSH-Ports [z. Der Besuch einer "geheimen" Webseite auf dem Webserver ermöglicht eine eingehende SSH-Verbindung für einen begrenzten Zeitraum von einer IP-Adresse, die die Seite angezeigt hat. Wenn Sie verbunden werden, -m state --satete ESTABLISHED sorgt dafür, dass der Paketfluss zugelassen wird, solange Sie eine einzelne SSH-Sitzung verwenden.]

Dinge, die ich nicht selbst mache, die aber Sinn machen:

  • grsecurity für den Kernel
  • remote-Syslog, sodass Protokolle nicht überschrieben werden können, wenn das System kompromittiert wird
  • benachrichtigung über SSH-Anmeldungen
  • configure rkhunter und richte es so ein, dass es von Zeit zu Zeit ausgeführt wird
50
pQd

Nur ein Hinweis zur Firewall Ihres Computers ...

  • Verwenden Sie eine Whitelist, keine Blacklist - d. H. Blockieren Sie alles und lassen Sie nur zu, was Sie brauchen, und 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, lassen Sie die Software Annahmen für Sie treffen - Sie müssen dieses Risiko nicht eingehen und sollten es auch nicht. 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 sich bereits um ein betriebsbereites System handelt und Sie den Datenverkehr nicht stören können (indem Sie es versehentlich blockieren), führen Sie tcpdump (Dump to File) aus und nehmen Sie Proben - studieren Sie sie später und finden Sie 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. Tools sind heutzutage nicht so dumm anzunehmen, dass, weil etwas beispielsweise auf Port 22 ausgeführt wird, es ssh sein muss und nicht anders - z Beispiel amap und nmap 's -A Möglichkeit. Allerdings können (und sollten Sie wahrscheinlich, wenn Sie sich Sorgen machen) Ihre Dienste so ändern, dass sie sich vor neugierigen Blicken verbergen. Im Folgenden wird der Angreifer beispielsweise über die genaue Version von OpenSSH informiert, die Sie ausführen kann dann nach Exploits für genau diese Version suchen. Wenn Sie solche Dinge verstecken, würden Sie es ihnen schwerer machen.
 [root @ ud-olis-1 uhtbin] # telnet localhost 22 
 Versuch 127.0.0.1 ... 
 Verbunden mit localhost.localdomain (127.0.0.1). 
 Escape-Zeichen ist '^]'. 
 SSH-2.0-OpenSSH_3.9p1 
  • Halten Sie alle Ihre öffentlichen Dienste auf dem neuesten Stand und aktualisieren Sie sie mit den neuesten Sicherheitspatches.
  • Speichern Sie keine DATEN auf dem Gateway-Server selbst. Zumindest kaufen Sie Zeit, wenn sie in diesen Computer eindringen können, und Sie verlieren ein oder zwei Dienste und einige Zeit, aber keine Daten.

Fazit ist, dass es Ihnen nie gelingen wird, etwas 100% sicher zu machen - das ist einfach nicht möglich - und das Ziel ist es, es so sicher wie möglich zu machen - wenn es einfach zu viel Aufwand ist, Ihr System zu beschädigen, ist es gut genug und die meisten Lamer Script-Kiddies wechseln zum nächsten 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 sind dazu verdammt, schlecht geschrieben zu sein und werden gehackt (keine Frage von "wenn", sondern "wann"). Open Source- und Open-Protokolle können öffentlich geprüft werden und werden zu einem ausgereiften und zuverlässigen Produkt. Closed-Source-Software beruht hauptsächlich auf dem Selbstvertrauen der Autoren, wie großartig/sicher ein Produkt ist sie denken, dass es ist - d. h. eine kleine Anzahl von Augen gegenüber einer Erde voller Augen.

Ich hoffe, das hilft :)

18
Xerxes
  • deaktivieren Sie die Root-Anmeldung
  • anmeldung mit Passwort deaktivieren (nur Anmeldung mit öffentlichem Schlüssel zulassen)
  • sSH-Port ändern
  • benutze Denyhosts (oder ähnliches)

  • schreiben Sie Ihr eigenes iptbles-Skript (damit Sie genau steuern, was zugelassen werden soll, und alles andere löschen 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. bei der Authentifizierung von Benutzern mit einem LDAP-Server auf einem anderen Computer).
12
x-way
9
KPWINC

Als allgemeinen Ausgangspunkt folge ich den Benchmarks/Leitfäden des Center for Internet Security , bei denen es sich um umfassende Zusammenstellungen bewährter Sicherheitsmethoden handelt. Es sieht nicht so aus, als ob der Debian-Benchmark seit einiger Zeit aktualisiert wurde, aber ein allgemeiner Überblick über die Schritte lautet:

  • 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 APT sources.list (Schlüssel sind korrekt, Quellen sind vertrauenswürdig).
  • Minimieren Sie Netzwerkdienste, deaktivieren Sie alles, was nicht benötigt wird, und Firewall, was ist.
  • Verwenden Sie TCPWrapper, um den Systemzugriff weiter einzuschränken.
  • Verwenden Sie nur verschlüsselte Netzwerkprotokolle, deaktivieren Sie unverschlüsselte Dienste (Telnet, FTP usw.).
  • Konfigurieren Sie nur den Remotezugriff auf SSH.
  • Deaktivieren Sie Benutzeranmeldekennwörter und erfordern Sie eine schlüsselbasierte Authentifizierung.
  • Deaktivieren Sie die Dateisystemfreigabe (NFS, SMB).
  • Aktivieren Sie die Remote-/zentralisierte Systemprotokollierung (und überprüfen Sie die Protokolle regelmäßig!).
  • Legen Sie ein Kennwort auf BIOS-/Firmware-Ebene fest.
  • Legen Sie ein Bootloader-Passwort fest.
  • Konfigurieren Sie Systemsicherungen, erstellen Sie einen Notfallwiederherstellungsplan und testen Sie, ob die Sicherungen gültig sind und ob die Mitarbeiter die Notfallwiederherstellungsverfahren kennen!

Zu all diesen verschiedenen Einstellungen gehören viele Ressourcen, einschließlich der spezifischen Befehle und Konfigurationsdateien, die in den CISecurity-Benchmarks auf dem System implementiert werden müssen.

6
jtimberman

Ich würde vorschlagen, eine Maschine nicht 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 die Netzwerküberwachung durchführen, ohne den Server stärker zu belasten. Persönlich finde ich, dass die 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 Datenverkehr 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 Schnittstellen-Firewall auf dem Server zu verwenden - Tiefenverteidigung ist der Schlüssel. Die Verwendung von nicht standardmäßigen Ports für verwaltungsbezogene Dienste schadet nicht. fail2ban ist in Ordnung. Verfolgen Sie die spezifischeren Fragen zu Sicherheitsanwendungen in Serverfault, um weitere Ideen zu finden.

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

5
pcapademic

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

Viele Leute denken, dass es cool oder professionell ist, lächerlich paranoid zu sein oder so. Es ist nicht , es ist nur ärgerlich für andere Administratoren und geradezu repressiv für Ihre Benutzer. Die meisten Dinge, die empfohlen werden, sind nur gefälschte Arbeit, um sich für den paranoiden Administrator nützlich zu fühlen, aber nicht wirklich hilfreich, da die tatsächliche Sicherheitsverletzung wahrscheinlich durch ein nicht ausreichend aktualisiertes System und/oder von einer internen Quelle verursacht wird.

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

Ich bin dabei, für alle meine Server auf die Festplattenverschlüsselung umzustellen.

Ich installiere nur 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 programmspezifische Konfiguration oder durch TCP-Wrapper) auf bestimmte IP-Adressen. Das einzige, was ich jemals mit iptables blockieren musste, war memcached, da es keine Konfigurationsdatei hatte und keine TCP-Wrapper verwendete.

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. fail2ban ist nur für diejenigen mit begrenztem Speicherplatz für Protokolldateien, IMO. (Sie sollten über ausreichend gute Passwörter verfügen, um ihnen vertrauen zu können.)

4
Teddy

Lesen Sie diese nette Anleitung unter www.debian.org/doc/manuals/securing-debian-howto/

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

3
Vihang D