SSH Keys - fail2ban noch notwendig? What about denyhosts?

[danton]

Jepp, der Lerneffekt ist definitiv gegeben - und ich schrieb ja bereits, dass dieser Befehl erheblichen Kollateralschaden anrichtet...

 

[greystone]

Aber gerade das macht ein Paketfilter eben nicht. Der kennt nur auf oder zu und regelt nach Quelle und Ziel. Was du meinst ist eine Application-Firewall und das ist iptables nämlich genau nicht.

Wenn ich für den Zugriff auf Port X nur IP-Range Y zulassen möchte, dann kommt da a) eine iptables-Regel davor b) wenn möglich noch tcpd Beschränkung dazu(was redundant zu a) ist, aber falls bei a) eine Lücke ausgenutzt wird ist immer noch b) da) und weiterhin wird c) die Anwendung die auf Port X lauscht noch entsprechend sicher konfiguriert. Dabei wird die Menge der potentiellen Angreifer definitiv reduziert.

Natürlich wäre es bei einem Webserver, der möglichst von jedem benutzt werden können soll, kontraproduktiv iptables-Sperren zu setzen, falls Du das meinst.

Das mußt du mir jetzt aber bitte erklären, warum ich einen Port dicht machen soll, an dem sowieso kein Dienst lauscht...

Der oben geschriebene Satz von mir ist ein Grund dafür: Es vermeidet, das aus Versehen/Hektik/Unwissenheit oder anderen Gründen unbeabsichtigt Sicherheitslöcher aufgerissen werden. Sprich: Wenn man sein System sauber konfiguriert, dann mag das nicht nötig sein. Das überlasse ich jetzt mal jedem selbst.

Das iptables Regeln eine relevante Performancebremse wären würde mich wundern. Bei grossen Servern/Clustern, wo wirklich viel Traffic durchgeht, wäre das vielleicht genauerer Betrachtung würdig. Aber Webservern würde ich sagen, da belastet jedes PHP-Script einen Server um ein vielfaches dessen, was iptables an Resourcen benötigt. Ich lasse mich aber gerne auch eines besseren belehren.

 

[nexus]

Der oben geschriebene Satz von mir ist ein Grund dafür: Es vermeidet, das aus Versehen/Hektik/Unwissenheit oder anderen Gründen unbeabsichtigt Sicherheitslöcher aufgerissen werden.

Beabsichtigt reißt man sich keine Löcher ins System, das sollte schon mal klar sein.
Aus Versehen oder wegen Hektik kann sicher mal passieren (wir sind alle nur Menschen), sollte aber nur ein extremer Ausnahmefall sein und ein Admin mit entsprechendem Wissen sollte solche Schnitzer auch umgehend erkennen und korrigieren können.
Unwissenheit oder andere Gründe lasse ich nicht gelten. Denn da sind wir wieder beim Grundproblem: Wer nicht genügend Ahnung von Serveradministration hat, soll bitteschön die Finger von Servern lassen und erstmal die Basics lernen...und zwar daheim in einer oder mehreren lokalen VM. Ich gehe ja auch nicht ins Krankenhaus und schnipple einfach an Patienten rum, nur weil ich mich für die menschliche Anatomie interessiere und vielleicht sogar schon ein paar Wikipedia-Artikel oder ein Buch zu dem Thema gelesen habe (Das ist natürlich eine völlig überspitzte Analogie, einfach nur um den Bezug deutlich zu machen).

Und nochmal:
Es bringt nur sehr wenig, wenn ich auf Systemebene absichere (dazu noch mit wenig tauglichen Mitteln), wenn nahezu alle richtigen Angriffe über Anwendungssoftware stattfinden, weil auf dieser Ebene die meisten und größten Sicherheitslücken nicht oder nur unzureichend gestopft wurden.
Anders ausgedrückt: Die Absicherung auf Systemebene macht nur einige Prozent eines vollständigen und durchdachten Sicherheitskonzepts aus.

P.S.:
Ich freue mich schon auf Joe's Statement zu dem Thema

 

[Deleted member 11740]

Wenn jemand auf deinem Server ohne Root-Rechte unterwegs ist, der dort nichts zu suchen hat, kann einem das schon ein besseres Gefühl geben, wenn man alle nicht genutzten Ports schließt, was den Angreifer dann aber nicht davon abhält z.B. eine reverse Shell zu öffnen.

Szenario:

• Angreifer erlangt Zugangsdaten zu einem Webinterface für Gameserver
• Angreifer verändert das Startscript ganz bequem via FTP
• Angreifer startet den Server über das Webinterface neu und hat somit auch die reverse Shell geöffnet.
• Der Anbieter hatte zwar alle nicht verwendeten Ports gesperrt, aber das hat die reverse Shell nicht verhindert.

EDIT: Dieses Szenario entspricht dem Beispiel der unsicheren Webanwendungen. Wahrscheinlich ist es bei den meisten WI für Gameserver gefixt. Falls nicht, viel Glück :-D

PS: fail2ban ist für Python 2 geschrieben und müsste mal portiert werden. Wäre auch toll die Hacks aus dem Code zu entfernen. Bis 2020 haben wir Zeit.

 

[danton]

Es vermeidet, das aus Versehen/Hektik/Unwissenheit oder anderen Gründen unbeabsichtigt Sicherheitslöcher aufgerissen werden.

Der einzige Punkt, wo es was bringt (wir reden hier davon, erst mal alle Ports zu schließen und dann gezielt zu öffnen), ist, wenn du in einer Software einen offenen Port konfigurierst, denn du nicht wolltest. Das läßt sich aber z.B. mit netstat selbst überprüfen. Wenn du eine Fehlkonfiguration an einem Dienst vornimmst, der im Internet lauschen soll, hilft dir der Paketfilter mal eben überhaupt nicht mehr.
Den Zugriff auf bestimmte Dienste per Quelle/Ziel-Regel in der Firewall zu steuern, kann durchaus Sinn machen - das kommt immer aufs Szenario an. Hier sind aber auch oft nicht Sicherheits- sondern andere Gründe der Ausschlag für ein solches Szenario. Und auch an dieser Stelle sehe ich iptables eher als Notlösung - eine Hardware-Firewall wäre aus Security-Sicht hier das Mittel der Wahl.
Wie aber bereits hier im Thread angesprochen wurde, finden die meisten Angriffe über andere Angriffsvektoren statt (z.B. Lücken in Scripts auf Webseiten). Gängiges Szenario: Erst mal alles, was rein kommt, droppen (sollte aber IMHO normalerweise besser ein Reject sein), dann die erlaubten Ports öffnen. Gegen die Folgen einer ausgenutzen Lücke können u.U. ausgehende Regeln helfen, da geht es aber oft "ans Eingemachte".
Bezüglich Performance von iptables: Es ist ziemlich bekannt, dass die Performance mit zunehmender Anzahl an Rules sinkt. Jedes Paket wird der Reihe nach gegen alle Regeln getestet, bis eine zutrifft. Wenn die Allow-Regeln ganz am Ende stehen, haben legitime Pakets einen langen Weg vor sich. Hierbei handelt es sich oft nur um minimale Verzögerungen, aber bei einigen Anwendungen kann sich das schon bemerkbar machen (bei VoIP wird viel Aufwand betrieben, um die Latenz zu drücken, weil hier auch minimale Verzögerungen sehr schnell auffallen).

 

[greystone]

Bezüglich Performance von iptables: Es ist ziemlich bekannt, dass die Performance mit zunehmender Anzahl an Rules sinkt. Jedes Paket wird der Reihe nach gegen alle Regeln getestet, bis eine zutrifft. Wenn die Allow-Regeln ganz am Ende stehen, haben legitime Pakets einen langen Weg vor sich. Hierbei handelt es sich oft nur um minimale Verzögerungen, aber bei einigen Anwendungen kann sich das schon bemerkbar machen (bei VoIP wird viel Aufwand betrieben, um die Latenz zu drücken, weil hier auch minimale Verzögerungen sehr schnell auffallen).

Kommt natürlich auch immer drauf an, wie man die Regeln gestaltet.

Sobald die erste Regel mit ESTABLISHED/RELATED sofort das Paket durchlässt, wäre die Verzögerung nur beim Verbindungsaufbau überhaupt zu messen.

 

[storvi]

Gerade bei einer Hardware-Firewall ist es häufig so, dass man nicht direkt Einfluss auf die Regeln hat, da der Betreiber der Firewall ein anderer / eine andere Abteilung ist.

Ich hatte es schon häufig, dass die HW-Firewall durch eine Fehlkonfiguration, einen Bug, eine nicht gespeicherte Regel plötzlich offener war, als benötigt.
Auf den Servern, die ich kontrolliere, setze ich also sehr gern einen Paketfilter, sowie sämtliche Sicherheitsmechanismen ein, die der Dienst (Whitelist) mitbringt und die sinnvoll einsetzbar sind. Eine Hardware-Firewall schützt auch nicht vor Servern aus dem gleichen Subnetz / VLAN.

Das bei Diensten, welche im Internet erreichbar sind teilweise andere Konfigurationen nötig sind, als im Unternehmensnetzwerk sollte klar sein. Am Ende des Tages muss ein schlüssiges Konzept vorhanden sein.

Wir hatten auch schon Fälle, wo ein Paket-Maintainer meinte die Dienst-Konfiguration, welche die Whitelist enthält auf "0" zurückzusetzen und der Dienst dann offen gegenüber Zugriffen war - der Paketfilter konnte hier zumindest die Erreichbarkeit einschränken.

Angriffsvektoren, welche aus der eingesetzten Software resultieren sind natürlich schwieriger zu behandeln. SELinux oder weitere Segregation können hier helfen, sind jedoch auch schwieriger zu verwalten. Wenn im größeren Rahmen agiert wird, kann natürlich auch ein IDS-System (host- und netzbasiert) eingesetzt werden, um Änderungen zumindest zu alamieren.

Wie gesagt - es kommt immer auf die Gesamtbetrachtung an.

Gruß
Markus

 

[ServerSide]

Na, da hab ich ja eine interessante Unterhaltung losgetreten.

Es ist also trotz SSH-Key-Nutzung noch immer empfehlenswert fail2ban zu nutzen, wenn auch nur um die Logs sauber(er) zu halten.

Ich bin in Sachen Software-auf-dem-Server-installieren ja eher ein Minimalist, aber ich teste fail2ban dann evtl. doch mal aus

 

[danton]

Es ist also trotz SSH-Key-Nutzung noch immer empfehlenswert fail2ban zu nutzen, wenn auch nur um die Logs sauber(er) zu halten.

Nein, um die Logs ein wenig sauberer zu halten, reicht es aus, den SSH-Port zu verlegen (sofern nicht andere Gründe dagegen sprechen). Fail2ban ist (wie jede andere installierte Software auch) ein potentieller Kandidat für Sicherheitslücken und sorgt für keinen positiven Effekt, der nicht auch problemlos anders erreicht werden könnte.

 

[killerbees19]

Bei der Sache mit allen Ports sperren habt ihr eine Kleinigkeit vergessen: DROP != REJECT

Dass es bei den typischen "Tutorials" aber nicht darum geht, ist schon klar. Ich wollte das nur kurz einwerfen.


MfG Christian

 

[danton]

Diejenigen, die die Tutorials einfach nur abarbeiten, machen sich aber i.d.R. wohl auch keine Gedanken darüber, ob ein Drop überhaupt sinnvoll ist.
Und ich denke auch, dass die wenigsten, die die Default-Policy der Firewall auf Drop setzen, dies machen, weil sie unbedingt ein Drop statt Reject haben wollen, sondern vielmehr aus den bereits hier im Thread genannten (sinnvollen oder unsinnigen) Gründen.