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


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

Ich möchte, dass ein Teil dieser Frage behandelt, was Sie als Firewall verwenden. Gerade iptables manuell konfiguriert oder verwenden Sie irgendeine Art von Software, um Ihnen zu helfen? Was ist der beste Weg? Alles blockieren und nur erlauben, 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 Brute-Force-Angriffe zu verhindern?


66


Ursprung


Es gibt viele Überschneidungen mit serverfault.com/questions/42/securing-a-fresh-ubuntu-server und - Zoredache
Ubuntu hat ufw Debian nicht;) Ich habe mich gefragt, ob Leute iptables selbst konfigurieren oder eine Software wie fireHOL verwenden - Thomaschaaf
Ich habe schon immer dazu tendiert, Iptables-Regeln selbst zu schreiben. Ich habe eine Kesseltafel, die Sachen wie Tropfen aller Fragmente, Weihnachtspakete usw. macht. Alles darüber hinaus ist systemspezifisch und normalerweise ziemlich klein. Ich kann nicht genug fallen Fragmente bei der Verwendung von iptables, BTW betonen. Aus irgendeinem Grund, den ich noch nicht erforscht habe, überprüft iptables nur das erste Fragment und übergibt den Rest ohne Überprüfung. Das macht meines Erachtens eine Haftung aus. - Scott Pack
Uhm ... Debian hat ufw. packages.debian.org/aufw - womble♦


Antworten:


Obligatorisch:

  • Installation des Systems mit Expertenmodus, nur Pakete, die ich brauche
  • Handgeschriebene Firewall mit Standardrichtlinie für iptables'input: drop, erlaubt den Zugriff auf SSH, HTTP oder was auch immer sonst auf dem Server läuft
  • Fail2Ban für SSH [und manchmal FTP / HTTP / andere - je nach Kontext]
  • deaktiviere root logins, erzwinge die Verwendung von normalem Benutzer und sudo
  • Custom Kernel [nur alte Gewohnheit]
  • geplantes System-Upgrade

Je nach Grad der Paranoia zusätzlich:

  • Drop-Richtlinie für die Ausgabe mit Ausnahme einiger erlaubter Ziele / Ports
  • integrit B. um zu überprüfen, ob einige Teile der Dateisystem-Software nicht verändert wurden [mit einer Prüfsumme, die außerhalb der Maschine gehalten wird] Stolperdraht 
  • geplanter Scan mindestens mit nmap System von außen
  • Automatisches Log-Check für unbekannte Muster [aber das ist hauptsächlich um Hardware-Fehlfunktionen oder kleinere Abstürze zu erkennen]
  • geplanter Lauf von chkrootkit
  • unveränderbares Attribut für /etc/passwd Das Hinzufügen neuer Benutzer ist daher etwas schwieriger
  • / tmp eingehängt mit noexec
  • Port-Klopfer oder andere nicht-standardisierte Weise zum Öffnen von SSH-Ports [z.B. Wenn Sie eine "geheime" Webseite auf dem Webserver besuchen, können Sie eine SSH-Verbindung für eine begrenzte Zeit von einer IP-Adresse aus aufrufen, die die Seite angezeigt hat. Wenn du verbunden bist, -m state --satete ESTABLISHED kümmert sich um den Paketfluss, solange Sie eine einzelne SSH-Sitzung verwenden]

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

  • Sicherheit für den Kernel
  • Remote-Syslog, so dass Protokolle nicht überschrieben werden können, wenn das System kompromittiert wird
  • Warnungen über SSH-Logins
  • konfigurieren rkhunter und richte es von Zeit zu Zeit ein

50



Nachdem Sie all dies ausgeführt haben, führen Sie BASTILLE gegen das System, um nach etwas anderem zu suchen. Ich würde auch empfehlen, eine volle Bohrung zu machen, unsicher prüft Nessus Scan des Systems auch; dann repariere, was immer es alarmiert. - Scott Pack
Das Kompilieren eines benutzerdefinierten Kernels bietet keine Sicherheitsvorteile, es sei denn, Sie wissen wirklich, was Sie tun. Sie werden es auch vernachlässigen, es auf dem neuesten Stand zu halten, wenn Sie es nicht in das Paketverwaltungssystem einfügen, was zu einer schlechteren Sicherheit führen würde. - Adam Gibbins
-1 für Sicherheit durch Dunkelheit. Sonst anständige Antwort. - dwc
@Adam - Ja, das weiß ich, immer noch bevorzuge ich einen monolithischen Kernel, der nur aus Teilen besteht, die ich brauche. das ist wahrscheinlich sehr rückständig, aber ich mache es trotzdem. @ dwc - es ist nur ein weiterer Schritt, der nur ein Sahnehäubchen ist, oder wie wir sagen, Kirsche oben auf dem Haufen unangenehmer stinkender Dinge. - pQd
Und du meinst sudo nicht su - - LapTop006


Nur eine Anmerkung zur Firewall Ihrer Maschine ...

  • Verwende eine Whitelist, keine Blacklist - d. H. Blockiere alles und erlaube nur das, was du brauchst, leugne alles andere.
  • Verwenden Sie keine GUIs / ncurses oder eine andere Software, die versucht, Ihre Firewall für Sie zu schreiben. Wenn Sie dies tun, erlauben Sie der Software, Annahmen für Sie zu treffen - 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 es bald genug herausfinden, wenn es erforderlich ist. Wenn es bereits ein laufendes System ist und Sie den Datenverkehr nicht unterbrechen können (indem Sie es versehentlich blockieren), führen Sie tcpdump (dump to file) aus und nehmen Sie Beispiele - studieren Sie sie später und finden Sie heraus, was gültig ist und was nicht.
  • Ich persönlich sehe keinen Sinn darin, einen Dienst auf einem Nicht-Standard-Port auszuführen, Werkzeuge sind heutzutage nicht so dumm, anzunehmen, weil etwas auf Port 22 läuft, dann muss es ssh sein, und nicht anders - für Beispiel amap, und nmapist es -A Möglichkeit. Nachdem Sie das gesagt haben, können Sie Ihre Dienste ändern (und wahrscheinlich sollten Sie sich auch Sorgen machen), um sich vor neugierigen Blicken zu schützen. Zum Beispiel würde das Folgende dem Angreifer die genaue Version von OpenSSH Sie können dann nach Exploits für diese genaue Version suchen. Wenn Sie solche Dinge verstecken, machen Sie es ihnen schwerer.
    [root @ ud-olis-1 uhtbin] # telnet localhost 22
    Versucht 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 patchen Sie mit den neuesten Sicherheitspatches.
  • Speichern Sie keine Daten auf dem Gateway-Server selbst, zumindest werden Sie Zeit kaufen, wenn sie es schaffen, auf diesen Rechner einzubrechen, und Sie verlieren einen oder zwei Dienste und einige Zeit, aber keine Daten.

Fazit ist, dass es dir niemals gelingen wird, etwas 100% sicher zu machen - das ist einfach nicht möglich - also ist es das Ziel, das so sicher wie möglich zu machen - wenn es zu viel Mühe ist, dein System zu brechen, ist es gut genug und am lahmen Script-Kiddies werden auf das nächste System wechseln.

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

Verwenden Sie niemals eine "Sicherheitssoftware", die nicht auf offenen Standards basiert - sie sind schlecht geschrieben und werden gehackt (keine Frage "wenn", sondern "wann"). Open-Source- und offene Protokolle sind öffentlich zugänglich und konvergieren zu einem ausgereiften und zuverlässigen Produkt. Closed-Source-Software stützt sich meist auf das Selbstbewusstsein der Autoren, wie groß / sicher ein Produkt ist Sie denke, es ist - d. h. eine kleine Anzahl von Augen gegenüber einer Erde - voller Augen.

Hoffentlich hilft das :)


18



"... eine kleine Anzahl von Augen gegen eine Erde - voller Augen." - Ich wünsche genug "Unternehmen" dies zu realisieren, aber Sicherheit durch Dunkelheit scheint der Trend zu folgen. Wenn ein Dienst wie ssh auf einem nicht standardmäßigen Port ausgeführt wird, wird ein entschlossener Angreifer nicht davon abgehalten. Es wird jedoch die Skript-Kiddies fernhalten - jemand, der einen Wörterbuchangriff auf eine Reihe von IP-Adressen an Port 22 ausführt. - L0neRanger


  • Deaktivieren Sie die Root-Anmeldung
  • Login mit Passwort deaktivieren (nur Login mit Public-Key erlauben)
  • Ändern Sie den SSH-Port
  • benutze denyhosts (oder ähnlich)

  • schreibe dein eigenes iptbles-Skript (damit du genau bestimmst, was erlaubt ist und alles andere fallen lassen kannst)

  • 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 strenge Zertifikatsprüfung für alle externen Dienste (z. B. beim Authentifizieren von Benutzern mit einem LDAP-Server auf einem anderen Computer).

12



Sie erhalten eine Verbesserung für die Deaktivierung der Passwortauthentifizierung. - derobert


Fang hier an:

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


9



Das Debian-Sicherheitshandbuch ist eine fantastische Ressource. - kce


Als allgemeiner Ausgangspunkt folge ich den Benchmark / Guides von der Zentrum für Internetsicherheit, die umfassende Zusammenstellungen von Best Practices für Sicherheit sind. Es sieht nicht so aus, als ob ihr Debian-Benchmark in einiger Zeit aktualisiert worden wäre, aber ein allgemeiner Überblick über die Schritte ist:

  • Wenden Sie die neuesten Betriebssystem-Patches / -Pakete an
  • Aktivieren Sie System / Kernel / Prozessabrechnung.
  • Aktiviere MAC (zB SELinux oder AppArmor).
  • Aktivieren Sie die hostbasierte Firewall (iptables).
  • Überprüfen Sie APT sources.list (Schlüssel sind korrekt, Quellen sind vertrauenswürdig).
  • Netzwerkdienste minimieren, alles deaktivieren, was nicht benötigt wird, und Firewall, was ist.
  • 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 Fernzugriff nur auf SSH.
  • Deaktivieren Sie Benutzeranmeldepasswörter, und fordern Sie eine schlüsselbasierte Authentifizierung an.
  • Deaktivieren Sie die Freigabe des Dateisystems (NFS, SMB).
  • Aktivieren Sie die Remote / zentrale Systemprotokollierung (und überprüfen Sie regelmäßig die Protokolle!).
  • Stellen Sie ein BIOS / Firmware-Passwort ein.
  • Legen Sie ein Bootloader-Passwort fest.
  • Konfigurieren Sie System-Backups, haben Sie einen Disaster-Recovery-Plan und TEST, dass die Backups gültig sind und dass das Personal Disaster-Recovery-Verfahren kennt!

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 sollen.


6





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 Sicherheits- und Netzwerküberwachung durchführen, ohne den Server mehr zu belasten. Ich persönlich finde, dass Netzwerk- und Funktionssegmentierung häufig die Fehlersuche im Netzwerk vereinfacht, obwohl die zusätzliche Komplexität gelegentlich die Analyse erschwert.

Die sicherste, aber am meisten störende Firewall-Richtlinie besteht darin, alle zu verweigern und explizit nur den Verkehr zu erlauben, den Sie zulassen müssen. Dies ist ärgerlich, da häufig die Firewall-Richtlinie aktualisiert werden muss, da das Netzwerk geändert werden muss.

Ich würde auch vorschlagen, eine Art Interface Firewall auf dem Server zu verwenden - Verteidigung in der Tiefe ist der Schlüssel. Die Verwendung nicht standardmäßiger Ports für verwaltungsbezogene Dienste tut nicht weh. fail2ban ist in Ordnung. Verfolgen Sie die spezifischeren Fragen zu Sicherheitsanwendungen auf Serverfault, um weitere Ideen zu finden.

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


5



+1 für nette Antwort. Ich muss darauf hinweisen, dass Standard-Verweigerung ist nicht nervig zu verwalten, wenn Sie es richtig angehen. Sicher, du musst wissen, was du erlaubst, oder? In der Tat sollte dies in einer einfachen Sprache als politische Erklärung niedergeschrieben werden. Wenn Sie das nicht als normale Routine tun, dann machen Sie Ihre Arbeit als Administrator nicht. Wenn dies der Fall ist, müssen Sie die Firewall-Regeln einfach aktualisieren. - dwc
Sehr gute Punkte. Jede Organisation sollte eine klare Sicherheitsrichtlinienanweisung haben. Wenn sich die Anforderungen der Organisation ändern, sollte die Richtlinienerklärung aktualisiert werden. Wenn nur der Administrator die Firewallregelimplementierung und CYA planen würde, würde ein intelligenter Administrator eine solche Richtlinienanweisung beibehalten, selbst wenn das Organisationsmanagement nicht die Mühe hätte, über Sicherheit nachzudenken. - pcapademic


Einige Leute haben auf die Das Debian-Handbuch sichern. Dies sollte für alles außer militärische Anforderungen völlig ausreichen.

Viele Leute denken, dass lächerlich paranoid ist cool oder professionell oder so etwas. Es ist nicht, es ist nur nervig für andere Admins und direkt repressiv für Ihre Benutzer. Die meisten Sachen, die Sie sehen werden, sind nur Fake-Working, um sich für den paranoiden Administrator nützlich zu fühlen, aber nicht wirklich hilfreich, da die wirkliche Sicherheitsverletzung wahrscheinlich durch ein nicht ausreichend aktualisiertes System und / oder von einer internen Quelle verursacht wird.

Das heißt, ich betrachte es als einen meiner Grundsätze, nichts mehr im lokalen Netzwerk als irgendetwas aus dem Internet zu vertrauen. Daher konfiguriere ich alles so, dass eine Authentifizierung auch im lokalen Netzwerk erforderlich ist. Ich verschlüssele und authentifiziere den gesamten Datenverkehr zwischen jedem Computer mit IPsec.

Ich bin dabei, für alle meine Server die Vollplatten-Verschlüsselung zu aktivieren.

Ich installiere nur Dienste, die ich verwende. Ich habe keine Firewall; Ich konfiguriere die Dienste, für die ich eine Authentifizierung benötige, oder beschränke sie (durch die eigene Konfiguration des Programms oder durch TCP-Wrapper) auf bestimmte IPs. Das einzige, was ich jemals mit iptables blockieren musste, war memcached, da es keine Konfigurationsdatei hatte und keine TCP-Wrapper verwendete.

Ich benutze gut, zufällig generiert Passwörter für meine Konten und vertraue meinem SSH-Server (und allen anderen Diensten), um diejenigen zu behalten, die das Passwort nicht kennen. fail2ban ist nur für diejenigen mit begrenztem Speicherplatz für Protokolldateien, IMO. (Sie sollten genügend Passwörter haben, um ihnen zu vertrauen.)


4





Gehen Sie durch dieses nette How-To unter www.debian.org/doc/manuals/securing-debian-howto/

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


3



Pfui. Du hattest mich bis "SSH Port wechseln". Es bringt nichts. Vor allem dann nicht, wenn jemand, der genug Zeit auf seinen Händen hat, einen Port scannen kann und sofort herausfinden kann, auf welchem ​​Port SSH läuft. Er deklariert den Dienstnamen (und die Serverversion), sobald Sie eine Verbindung herstellen. - Matt Simmons
Ja, ich weiß, dass Sie von jedem Port gescannt werden können und den richtigen Port finden. Aber die meisten Angriffe sind auf Standard-Port. Versuche einfach einige Statistiken zu erhalten, indem du den Port änderst. - Vihang D