SSH Keys - fail2ban noch notwendig? What about denyhosts?

S

ServerSide

New Member
Hallo.

Beim experimentieren sind mir gerade ein paar Fragen aufgekommen:

1. Wenn ich ausschliesslich SSH Keys (mit Passphrase) zum SSH Login erlaube, benötige ich dann noch fail2ban? Wenn ich es richtig verstanden habe werden Connections ohne SSH Key erst gar nicht angenommen und daher dürfte fail2bain ja eigentlich nicht mehr nötig sein. Ist dies korrekt so oder übersehe ich etwas? Erscheinen diese Login-Versuchen OHNE SSH Key dann trotzdem in auth.log? Und gibt es in diesem Fall (SSH Keys Benutzung) dann noch andere Sicherheits-Vorteile durch fail2ban oder beschränkt es sich "nur" darauf dass auth.log nicht "vollgespamt" wird?

2. Wie ist denn der derzeitige Stand in Sachen fail2ban vs denyhosts? So wie ich es verstanden habe reagiert fail2ban schneller und arbeitet direkt über iptables. Denyhosts checkt alle 30s (Intervall ist konfigurierbar) das auth.og und setzt dann entsprechende Login-Fehler-Verursacher auf hosts.deny. Dies scheint mir eigentlich keinen Vorteil im Vergleich zu fail2bain zu bringen?
Ist dies so korrekt oder übersehe ich etwas?

Vielen Dank schonmal!
 
Über den Einsatz von fail2ban scheiden sich die Geister. Einerseits werden häufige Fehllogins damit abgefangen, andererseits ist es eine zusätzliche Software, die potentiell Sicherheitslücken enthalten kann (wie alle Programme).
Die Loginversuche erscheinen weiterhin in der auth.log, denn die Verbindung wird ja aufgebaut, der Login schlägt aber per Passwort grundsätzlich fehl. Fail2ban sorgt dann eigentlich nur noch dafür, dass die Logs sich nicht so füllen - aber einen solchen Effekt erzielst du auch, indem du SSH nicht auf dem Standardport laufen läßt (was IMHO auch der einzige Vorteil des geänderten Ports wäre).
Fail2ban und Denyhosts nutzen, wie du bereits erkannt hast, unterschiedlichen Techniken. Der Vorteil von denyhosts ist, dass es auch funktioniert, wenn keine iptables zur Verfügung stehen (kann bei einigen vServers passieren, abhängig von eingesetzter Virtualisierung und Anbieter).
 
Je nach Sicherheitsbedürfnis ist es gut alle die genannten Massnahmen umzusetzen:

  • SSH-Port weg von 22(auf jeden Fall, sonst ca. >=100k Bruteforce-Logins pro Tag)
  • Fail2ban (Bei IPv6 dann nur noch begrenzt nützlich. Dort kann man eigentlich nur noch auf Subnetzebene sperren.)
  • Wenn möglich hosts.allow / hosts.deny
  • Denyhosts kannte ich jetzt noch nicht. Habe so was nur für Voip im Einsatz. Hört sich gut an.
 
Tarnen und täuschen ist für mich ein Teil einer Sicherheitsstrategie.

Und wenn Du hosts-access auch für irrelevant hältst, dann ist iptables für Dich auch nur für überflüssiger Poser-Schrott?
 
Last edited by a moderator:
Bin auch ein Fan davon auf mehr als ein Sicherheitsfeature zu setzen.

Wenn es irgendwie geht mach SSH nur über eine feste IP und konfiguriere sowohl iptables als auch hosts.allow (oder halt den Key nur von der festen IP mittels "from=" bzw. Allow-Direktive in der sshd-Konfiguration).

Wenn dann ein Fehler in der Firewall-Konfiguration vorliegt, schützt sich der Dienst immer noch selbst...

Gruß
Markus
 
greystone said:
Tarnen und täuschen ist für mich ein Teil einer Sicherheitsstrategie.
Click to expand...
Nicht wirklich. Wer in (d)ein System rein will, findet auch Angriffsvektoren, die ihm den Zugriff gewähren, wenn entsprechende Sicherheitsvorkehrungen (z.B. key-basierter SSH-Zugriff o.ä.) nicht oder nicht korrekt konfiguriert sind.

greystone said:
Und wenn Du hosts-access auch für irrelevant hältst, dann ist iptables für Dich auch nur für überflüssiger Poser-Schrott?
Click to expand...

iptables sehe ich nicht als Schrott, für entsprechende Anwendungsfälle hat es durchaus seine Berechtigung.
Aber wenn ich in irgendwelchen Deppenanleitungen lese, wie man dazu rät, alle nicht verwendeten Ports mittels iptables zu schließen, halte ich soetwas schon für sinnfrei. Oder wenn jemand seine Firewall mit Tausenden von IP-Adressen füttert (z.B. von blocklist.de), um so Angriffe zu unterbinden, dann ist ein solches Vorgehen nicht nur unnütz, es belastet auch den Ressourcenverbrauch sinnlos.

Man kann nur selten bis garnicht ein pauschales Sicherheitskonzept empfehlen. So etwas muß immer auf den Einzelfall und die entsprechenden Erfordernisse bzw. Bedürfnisse zugeschnitten sein. Und da sich das Angriffsverhalten und die Angriffsmuster immer an gegebene Situationen anpassen, muß man sein Sicherheitskonzept auch permanent pflegen und bei Bedarf auch immer wieder überarbeiten und aktualisieren.

Nachtrag:
Die wenigsten 'echten' Angriffe finden übrigens auf Systemebene statt.
Auch wenn ich keine exakten Zahlen nennen kann, so würde ich mal behaupten, daß gefühlt über 90% aller Angriffe über Sicherheitslücken in Anwendungssoftware (Foren, CMS, o.ä.) stattfinden. In so einem Fall nützt es dir dann absolut nix, wenn du den SSH verriegelt und verrammelt hast. ;)
 
Last edited by a moderator:
storvi said:
Stimmt, diese Art Anleitungen sind schon interessant.
Click to expand...

Das schlimme an solchen Anleitungen (besonders hasse ich diese Video-HowTo's) ist ja, daß einem ein völlig falsches Sicherheitsgefühl vorgegaukelt wird.
Die Leute arbeiten solche Anleitungen einfach blind ab, ohne überhaupt zu verstehen, was sie da machen und freuen sich, wenn sie so ihre Systeme ohne größere Probleme zum Laufen bekommen.
Dann denken sie, sie sind sicher und kümmern sich nicht weiter um die Kiste (Updates - was ist das? Logfiles - hab ich noch nie von gehört. usw, usw, usw...) und wundern sich, wenn der Hoster die Kiste nach ein paar Wochen oder Monaten vom Netz nimmt, weil sie inzwischen zu einem Spam-Zombie mutiert ist.

Nachtrag:
Und diese ganzen Adminpanels (Pest, Webmin und wie sie alle noch heißen) verschlimmern diese Problematik nur noch weiter...zumindest für die Leute, denen das erforderliche Basiswissen über die Vorgänge in einem Serversystem fehlt.
Dieser Klicki-Bunti Mist suggeriert nämlich auch, daß es ja angeblich total einfach wäre, einen eigenen Server zu betreiben.
Wohlgemerkt, ich bin nicht grundsätzlich gegen Adminpanels...auch sie können durchaus ihre Berechtigung haben, wenn sie dem Admin (der weiß, was er tut) die Arbeit erleichtern und immer wiederkehrende Aufgaben automatisieren helfen.
 
Last edited by a moderator:
greystone said:
Tarnen und täuschen ist für mich ein Teil einer Sicherheitsstrategie.
Click to expand...
Security by Obscurity hat noch nie funktioniert. Im Endeffekt verarscht man eher sich selbst damit als die Angreifer, weil man sich selbst eine Sicherheit vorgaukelt, die nicht gegeben ist. Es bringt nichts, ein Zettel mit "geschlossen" an die Tür zu hängen (oder einen Zettel mit "das ist keine Türe"), wenn das Schloss, Schließblech, Zargen, Rahmen, ... an sicht nichts taugen.

greystone said:
Und wenn Du hosts-access auch für irrelevant hältst, dann ist iptables für Dich auch nur für überflüssiger Poser-Schrott?
Click to expand...
(1) kein Grund, pampig zu werden
(2) ich schrieb nirgendwo, daß ich das für irrelevant oder gar für Schrott halte. Es hat nur leider so rein gar nichts mit erhöhter Sicherheit bezüglich der Konfiguration von Diensten zu tun.

Natürlich sind vernünftige Paketfilter hilfreich - sie sollten aber immer das letzte Mittel sein, weil ein sabuer konfiguriertes System auch ohne diese Dinger sicher ist und unbefugte Zugriffe sauber abfangen kann.
 
Ich hatte schon Fälle, in denen der SSH-Dienst nicht mehr erreichbar war und der Server anderweitig Netzwerkprobleme bekam, weil der auf Port 22 dermassen mit Requests zugeballert wurde. Als der SSH-Port dann gewechselt war, war Ruhe.

Speziell auch im Anwendungsbereich laufen immer wieder Brute-Force-Attacken, die den Server mit PHP mal schnell in die Knie zwingen können. Es ist natürlich die Frage wie weit man seinen Server dann runterkonfigurieren will bzgl. gleichzeitiger PHP-Requests. Auch da finde ich fail2ban derzeit noch brauchbar eingesetzt.

Nexus said:
...iptables sehe ich nicht als Schrott,...
Click to expand...

Sorry. Da war ich unklar. Das ging in Richtung marce, der den Beitrag explizit als ganzes als Unsinn bezeichnet.

Aber wenn ich in irgendwelchen Deppenanleitungen lese, wie man dazu rät, alle nicht verwendeten Ports mittels iptables zu schließen, halte ich soetwas schon für sinnfrei.
Click to expand...

Ich nicht. Ich finde das im Gegenteil sehr vernünftig, erst alles zuzumachen und dann die Ports zu öffnen, die man wirklich braucht. Macht halt mehr Arbeit, dass manche Sachen, an die man nicht gedacht hat, nicht funktionieren und man muss sich die Mühe machen vieles en Detail nachzuarbeiten. Es vermeidet das aus Versehen oder Unwissenheit Sicherheitslöcher eingebaut werden.

Nexus said:
Oder wenn jemand seine Firewall mit Tausenden von IP-Adressen füttert (z.B. von blocklist.de), um so Angriffe zu unterbinden, dann ist ein solches Vorgehen nicht nur unnütz, es belastet auch den Ressourcenverbrauch sinnlos.
Click to expand...

Code: 
root@sip:~# iptables -L -v -n | wc -l
24633

Ja. Das ist ein gewisser Aufwand für den Netzwerkstack da drauf geht. Die Sicherheit globale Angreifer in kürzester Zeit geblockt zu bekommen ist mir das wert. Die VoIP-Anlage idled sowieso nur vor sich hin. Bei Webservern ist das natürlich eine andere Geschichte.
 
marce said:
(1) kein Grund, pampig zu werden
Click to expand...

Den Sarkasmus darfst Du Dir für Deine Provokation schon auch mal gefallen lassen.

marce said:
(2) ich schrieb nirgendwo, daß ich das für irrelevant oder gar für Schrott halte. Natürlich sind vernünftige Paketfilter hilfreich - sie sollten aber immer das letzte Mittel sein, weil ein sauber konfiguriertes System auch ohne diese Dinger sicher ist und unbefugte Zugriffe sauber abfangen kann.
Click to expand...

Du schreibst, dass die genannten Massnahmen die Sicherheit nicht erhöhen. Das sehe ich anders. Software hat immer Fehler und Sicherheitslücken. Wenn man durch einen Paketfilter oder IP-Basiertem Vorabausschluss die Menge der potentiellen Angreifer drastisch reduzieren kann, dann ist das ein erheblicher Sicherheitsgewinn. Insofern gehört zur Sicherheit für mich sowohl eine saubere und sichere Anwendungskonfiguration, als auch die Einschränkung des Zugriffes - um es mal allgemein zu formulieren - auf die Benutzerkreise, die darauf überhaupt auch Zugriff benötigen.
 
Last edited by a moderator:
greystone said:
Ich nicht. Ich finde das im Gegenteil sehr vernünftig, erst alles zuzumachen und dann die Ports zu öffnen, die man wirklich braucht.
Click to expand...

Das mußt du mir jetzt aber bitte erklären, warum ich einen Port dicht machen soll, an dem sowieso kein Dienst lauscht...
 
greystone said:
Ich nicht. Ich finde das im Gegenteil sehr vernünftig, erst alles zuzumachen und dann die Ports zu öffnen, die man wirklich braucht.
Click to expand...

Das ist Unsinn. Ports, die bereits geschlossen sind, braucht man per iptables nicht noch einmal zu schließen - sie sind es ja schon. Sorgt nur dafür, dass der Kernel mehr zu tun hat, weil er erst mal sein umfangreiches iptables-Regelwerk abarbeiten muß und die Verbindung ablehnt, statt das auch auf dem direkten Weg zu machen. Der Grundsatz "erst alles schließen und dann das notwendige öffnen" macht bei dedizierten Firewalls Sinn. Die sollen ja dafür sorgen, dass unnützer Daten-Traffic gar nicht erst bis zum jeweiligen Server kommt - bei iptables direkt auf dem Server sind die Daten ja schon angekommen.
Und ja, auch ich halte von Videotutorials absolut nichts. Die werden von den Leuten verwendet, die nur stumpf abtippen. Wenn man nach einem Tutorial arbeitet, dann ist die einzig richtige Vorgehensweise: lesen, verstehen, umsetzen und NIEMALS lesen und einfach abtippen.
Wenn jemand unter Linux ein Problem hat, würde ein "rm -R /" das auf eine Art schon beseitigen - allerdings mit großem Kollateralschaden. Das ist jetzt mal ein krasses Beispiel, verdeutlicht aber sehr gut, warum man nicht ohne nachdenken einfach abtippen sollte.
 
greystone said:
Das sehe ich anders. Software hat immer Fehler und Sicherheitslücken. Wenn man durch einen Paketfilter oder IP-Basiertem Vorabausschluss die Menge der potentiellen Angreifer drastisch reduzieren kann, dann ist das ein erheblicher Sicherheitsgewinn.
Click to expand...

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.
 
danton said:
Wenn jemand unter Linux ein Problem hat, würde ein "rm -R /" das auf eine Art schon beseitigen - allerdings mit großem Kollateralschaden.
Click to expand...

Wenn schon, dann bitte
Code: 
rm --no-preserve-root -rf /

Sonst verweigert rm nämlich seinen Dienst (und das aus gutem Grund) ;)
 
Sorry... :D
Das letzte Mal, dass ich es zum Spaß mal probiert habe, war vor zig Jahren unter Slackware (ich glaube noch mit einem 2.0er Kernel) und da gab es diese Sicherung noch nicht...
 
Ihr solltet vielleicht noch anmerken das man mit diesem netten Einzeiler das gesamte System an die Wand fährt. Nur so als Warnung für die Leute die stumpf alles übernehmen was sie im Netz so finden :D
Ja es gibt sie ...
 
sbr2d2 said:
Ihr solltet vielleicht noch anmerken das man mit diesem netten Einzeiler das gesamte System an die Wand fährt. Nur so als Warnung für die Leute die stumpf alles übernehmen was sie im Netz so finden :D
Ja es gibt sie ...
Click to expand...

Dann haben sie aber etwas dazugelernt :eek::rolleyes::D

Und mal ehrlich, selbst wenn man dazuschreibt: "Bitte vorher die Manpage lesen!", glaubst du wirklich, daß das mehr als einer von 10000 macht...?
 
You must log in or register to reply here.
Back
Top