Gründe für meinen Hoster Fail2Ban zu untersagen

[einsiedler]

Hallo liebe Forumer, ich möchte euch mal fragen welche guten Gründe es gibt Fail2Ban zu untersagen, denn mein Hoster möchte dies nicht für mich installieren. Meine website ist nicht allein auf dem Server, es werden mehrere sein, eine genaue Zahl weiß ich nicht. Ich sehe da keinen Sinn mir diese "Art von möglicher Sicherheit" vorzuenthalten und habe sogar erwähnt meinen Hoster zu wechseln. Doch er ist ziemlich günstig auf das Jahr gerechnet. Was kann / sollte ich nun tun.

Liebe Grüße der einsiedler

[Robert B.]

Moin einsiedler,

ich möchte euch mal fragen welche guten Gründe es gibt Fail2Ban zu untersagen, denn mein Hoster möchte dies nicht für mich installieren.

welche (guten oder andere) Gründe hat denn dein Hoster angegeben?

Viele Grüße
Robert

[Rolf B]

Hallo einsiedler,

Fail2Ban scans log files like /var/log/auth.log and bans IP addresses conducting too many failed login attempts. It does this by updating system firewall rules to reject new connections from those IP addresse

Das klingt für mich so, als wäre fail2ban nur auf einem dedizierten Server einsetzbar.

Ein shared hoster hat mehr als einen VHost auf einer Kiste. Und er möchte sich vorbehalten, VHosts nach Bedarf zu verschieben, um die Auslastung des RZ balancieren zu können.

Fail2Ban schießt bei beidem quer. Die Firewall gehört zum Server, nicht zum VHost. Und Fail2Ban ist ein Daemon, der den Server überwacht, nicht einen VHost. D.h. ein Bann einer IP träfe alle VHosts auf dem Server, und der Umzug eines VHosts würde die für ihn gebannten IPs nicht automatisch mitnehmen.

Ich denke, in einer shared hosting Umgebung braucht man andere Tools. Welche auch immer das sind.

Hast Du Lust auf 2FA? Ich hab es noch nicht gemacht, aber es gibt eine TOTP^[1]-Library für PHP (https://github.com/lfkeitel/php-totp), mit der Du TOTPs erzeugen kannst. Zusammen mit einer Handy-App wie Authy oder Google Authenticator (da gibt's etliche) kannst Du dann Zweifaktor-Authenfizierung betreiben.

Vorgehen:

Beim Erstellen eines Users:

• Festlegen eines Usernamens
• Erzeugen eines Zufallskeys für diesen User (bspw. 16 Bytes) und speichern dieses Zufallskeys für diesen User
• In der Authenticator-App den Usernamen und Zufallskey hinterlegen.

Beim Anmelden:

• Eingeben von Username, Passwort und TOTP von der Authenticator App.
• Am Server:
  • Fehlt das Token, brich gleich ab.
  • Setze ZEIT auf JETZT, setze DELTA auf 0
  • Generiere TOTPs für ZEIT +- DELTA und den User, der sich anmelden will
  • Stimmt eins: Prima
  • Wenn nicht: Erhöhe DELTA um 30s
  • Wenn DELTA nicht zu groß ist, neuer Versuch.

Was "Nicht zu groß" ist, ist Dir überlassen. Heutige Server und Handys sind gut synchron, ich würde bei DELTA > 60s aufhören.

TOTPs gelten nur 30s, da hast Du mit brute force keine Chance. Die Serverlast hast Du natürlich weiterhin. Aber ich bin nicht der Apache-Experte, vielleicht kann man bereits im .htaccess sicherstellen, dass ein bestimmter POST-Parameter vorhanden ist. Das TOTP als Query-Parameter zu übermitteln (dafür wüsste ich, wie man im Apache die Parameterexistenz prüft) ist aber keine Alternative.

Ich glaube, dazu muss ich mal Versuche machen und was ins Wiki schreiben…

Rolf

---

1. Time-based One Time Password ↩︎

[einsiedler]

Das klingt für mich so, als wäre fail2ban nur auf einem dedizierten Server einsetzbar.

Ein shared hoster hat mehr als einen VHost auf einer Kiste. Und er möchte sich vorbehalten, VHosts nach Bedarf zu verschieben, um die Auslastung des RZ balancieren zu können.

Fail2Ban schießt bei beidem quer. Die Firewall gehört zum Server, nicht zum VHost. Und Fail2Ban ist ein Daemon, der den Server überwacht, nicht einen VHost. D.h. ein Bann einer IP träfe alle VHosts auf dem Server, und der Umzug eines VHosts würde die für ihn gebannten IPs nicht automatisch mitnehmen.

Ich denke, in einer shared hosting Umgebung braucht man andere Tools. Welche auch immer das sind.

DAS wäre mal eine verständliche und vorallem klärende Antwort, die mir mein Hoster vorenthalten hat, er neigte auf die Fragen meiner Mail zu antworten: "Ja dann wechseln sie doch, eine Rückmail genügt". Ich muss noch darüber nachdenken, ich bezahle so knapp 17 Euronen im Jahr.

Danke euch.

Grüße der einsiedelnde

[Mitleser 2.0]

DAS wäre mal eine verständliche und vorallem klärende Antwort, die mir mein Hoster vorenthalten hat, er neigte auf die Fragen meiner Mail zu antworten: "Ja dann wechseln sie doch, eine Rückmail genügt". Ich muss noch darüber nachdenken, ich bezahle so knapp 17 Euronen im Jahr.

Jetzt setze mal Deine 17,- Euro / Jahr ins Verhältnis zur Arbeitszeit, die Rolf mutmaßlich in seine Antwort gesteckt hat.

[Raketenwilli]

Ich muss noch darüber nachdenken, ich bezahle so knapp 17 Euronen im Jahr.

Anders ausgedrückt: Bei einer einzigen Supportanfrage per anno wird Deine Zahlung komplett dafür verbraucht. Denn eine Arbeitsstunde kannst Du getrost mit 100 Euro kalkulieren.

er neigte auf die Fragen meiner Mail zu antworten: "Ja dann wechseln sie doch, eine Rückmail genügt".

Das ist aus Sicht der Betriebswirtschaftslehre leicht nachvollziehbar. Der Hoster macht mit Dir Verlust. Und die reine Lehre schlägt das Offensichtliche vor.

DAS wäre mal eine verständliche und vorallem klärende Antwort, die mir mein Hoster vorenthalten hat,

Vielleicht hat er es Dir ja erklärt. Nur hat diese Erkärung das Dunkel für Dich nicht erhellt.

Ich bin mir sicher, dass Dein Hoster (oder dessen Dienstleister) die hinter Deiner Frage stehenden Sicherheitsbedenken selbst hegt und - weil er oder dwer andere kein ganz Dummer ist - also dafür eine (andere) Lösung hat. Fail2ban ist im Massenhosting schon im Hinblick auf die Performance keine Antwort, die Firewall ist zudem eine eigene, zentral für alle oder wenigstens mehrere Server agierende Maschine.

Anders ausgedrückt: Was sich bei einem Sonstwas-Server in einem kleinen Unternehmen anbietet ist keine Lösung für mindestens zweitweise gut ausgelastete Server in einem Rechenzentrum. Bei solchen ist es schon fraglich, ob überhaupt lokale Logs existieren (die können auf einen speziellen Server weggeschrieben werden) - und was für einen Performance-Horror es bedeutet, denn Fail2ban diese dann via Netzwerk auswerten will.

Außerdem zieht Fail2ban bei manchen Kunden dann - wegen der Sperren - wieder Supportaufwand - also Kosten - nach sich.

[Mitleser 2.0]

Hallo liebe Forumer, ich möchte euch mal fragen welche guten Gründe es gibt Fail2Ban zu untersagen, denn mein Hoster möchte dies nicht für mich installieren. Meine website ist nicht allein auf dem Server, es werden mehrere sein, eine genaue Zahl weiß ich nicht. Ich sehe da keinen Sinn mir diese "Art von möglicher Sicherheit" vorzuenthalten und habe sogar erwähnt meinen Hoster zu wechseln. Doch er ist ziemlich günstig auf das Jahr gerechnet. Was kann / sollte ich nun tun.

M.E. eine müßige Fragestellung. Wenn Du in einem Shared-Hosting unterwegs bist und bleiben willst: take it or leave it.

Die werden ihre eigenen Automatismen für die Setups haben und insbesondere bei "günstigen" Paketen nachvollziehbar keinen Bock haben, für jede Kundenanfrage irgendwas daran zu basteln. Jedes zusätzliche Ding bedeutet Aufwand. Initial und in der Wartung.

Pro-Tipp noch dazu: Trenne DNS vom Hosting, das macht den Hoster-Wechsel dann deutlich einfacher.