PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : was sind wichtige fail2ban Filter



PeHeller@gmx.net
20.05.13, 12:44
Hallo,

ich habe mich mit fail2ban ein wenig befasst und in ein bestehendes System integriert
Bei einem neuen Server SUSE 12.3 sieht die default jail.conf wieder anders aus (neue Filter)

Mein System
1. ssh Zugriff über Port 22 (normal.. kein public key
2. apache Port 80
3. mysql nur für apache-auth
4. eventuell Webmin (diesen starte ich aber erst nach Bedarf, und stoppe es wieder)
jedoch ist Port 10000 in der Firewall offen... es hört aber nur Webmin darauf.

Nun habe ich folgende Filter aktiviert bzw. integriert und aktiviert.

1. Filter sshd mit Port ssh
2. Filter sshd-ddos Port ssh
3. Filter apache-auth Port http,https

alles beim 3 Versuch ban und für 5 Minuten.

Reicht dies aus, wie gesagt nur Port 22 und 80 sind offen, oder sollte ich zusätzliche Filter z.B. ssh-tcpwrapper aktivieren ??

Gruß
worst_case

PS: Es gibt nun noch einen neuen Filter [recidive]. Wer kann mir diesen Filter erklären, bzw. ist der Filter nötig ?

marce
20.05.13, 14:58
was erwartest Du dir denn von f2b? Welche Art von System willst Du denn "absichern"?

PeHeller@gmx.net
20.05.13, 15:02
Hallo,


was erwartest Du dir denn von f2b? Welche Art von System willst Du denn "absichern"?

ich möchte bei x falschen Versuchen an Port 22 die ankommende ip blockieren,
dies soll auch bei http(s) an port 80 so sein. (sperren für Zeit-x)

marce
20.05.13, 15:03
Das war nicht die Frage...

PeHeller@gmx.net
20.05.13, 15:11
Hallo,


Das war nicht die Frage...

einen SUSE 12.3 Webserver mit Konfigurationsmöglichkeit über ssh.

Gruß

Detlef Paschke
20.05.13, 21:51
Hallo,

also für Eisfair (http://www.eisfair.org/) gibt es ein Paket brute force blocking was genau das macht und welches ich schon seit Jahren erfolgreich einsetze. Ich weiß nicht wie es mit der Portierung auf Suse aussieht aber die Entwickler von Eisfair sind sehr umgänglich, ich denke der Paketentwickler von brute force blocking kann Dir sicher dabei helfen.

Viele Grüße
Detlef Paschke

HirschHeisseIch
21.05.13, 03:25
einen SUSE 12.3 Webserver mit Konfigurationsmöglichkeit über ssh.


Das steht ja weiter oben auch schon alles...

Es wurde auch noch was anderes als nach dem System gefragt.


Manchmal verfolgt man einen falschen/schlechten Ansatz, statt sich nen Tipp abzuholen, wie man das gewünschte einfach umsetzen könnte.

PeHeller@gmx.net
21.05.13, 07:51
Hallo,


Das steht ja weiter oben auch schon alles...

Es wurde auch noch was anderes als nach dem System gefragt.

Manchmal verfolgt man einen falschen/schlechten Ansatz, statt sich nen Tipp abzuholen, wie man das gewünschte einfach umsetzen könnte.

dann bitte die Frage detailieren was Ihr für Infos noch braucht, bevor x mal der Satz kommt "Das war nicht die Frage" oder Sprüche

Manchmal verfolgt man einen falschen/schlechten Ansatz, statt sich nen Tipp abzuholen, wie man das gewünschte einfach umsetzen könnte.

Ich weiß nicht was ich noch Antworten soll auf die Frage


was erwartest Du dir denn von f2b? Welche Art von System willst Du denn "absichern"?.

Es tut mir Leid..... ich weiß nicht was Ihr wollt.:confused:

Gruß
worst_case

Rain_maker
21.05.13, 11:36
Dann sage ich das, was meine Vorposter wohl meinen, etwas detaillierter.

Statt eine schlechte Idee wie

'ssh ohne pubkey-authentication, aber dafür "sichere" ich das ja mit fail2ban ab'

weiter zu verfolgen, sollte man sich eher Gedanken machen, wie man das System _wirklich_ sicherer machen kann und _danach_ kann man über solche "Pflästerchen" wie fail2ban nachdenken.

Mein Vorschlag (Reihenfolge _nicht_ zufällig):

1. SSH _nur_ über pubkey zugänglich machen, login als root verbieten


************************************************** ******************************************
//edit:

1.5 Sich überlegen, ob man diese offene Wunde namens Webmin _wirklich_ haben will, falls nein 2. und 3. überspringen.

************************************************** ******************************************

2. Webmin ist _NIE_ von aussen erreichbar

a) Falls durch entsprechende Konfiguration möglich, lauscht Webmin auf dem Server _nur_ auf 127.0.0.1 (keine Ahnung, ob das geht, Doku lesen)

b) falls a) nicht machbar, listen port von Webmin per firewall blocken (bzw. erst gar nicht explizit öffnen).

3. Zugriff auf Webmin nur durch SSH-Tunnel, also Weiterleitung des listen ports auf den Client, am besten dort auch nur an 127.0.0.1 binden


4. Sich dann noch einmal Gedanken machen, ob/wozu man nun fail2ban noch braucht (und es im Zweifelsfall lassen).

Greetz,

RM

PeHeller@gmx.net
21.05.13, 14:49
Hallo,


Dann sage ich das, was meine Vorposter wohl meinen........

das ist doch ne Ansage, Danke Rain_Maker.:D

SSH _nur_ über pubkey .... da denke ich schon länger darüber nach, muss halt immer nen Stick mit dem Key mitnehmen. Das war der einzige Grund warum noch nicht benutzt.

OK... werde es mit publickey lösen. Somit ist Port 22 nicht mehr in Gefahr

Dann kann ich fail2ban immer noch für Port 80 Auth auf Webserver verwenden, um Passwortscripte wenigstens mal auszuperren ??

Webmin aktiviere (start daemon) ich nur für den Zeitraum, wo nötig.(Änderung ...10 min) Webmin ist sehr bequem und bietet alles in einem Tool. Nur deshalb bin ich überhaupt auf Webmin gekommen. Gut..... darauf kann ich auch verzichten, fast alles kann ich auf der Konsole oder mit yast auch lösen.

So gefällt mir das. Nur noch fail2ban für Port 80 Auth.... oder gibt es auch hier eine bessere Lösung. Webseite muss immer und überall ohne Hilfsmittel erreichbar sein, jedoch mit Anmeldung (htaccess + mysql)

Danke
worst_case

pibi
21.05.13, 16:55
Und nur am Rande: Wenn das stimmt, was in Deiner Fusszeile steht (SUSE 11.1 .. Server/Router..), wuerde ich dringend zu einem Update raten.

Gruss Pit.

PeHeller@gmx.net
21.05.13, 17:45
Hallo,


Und nur am Rande: Wenn das stimmt, was in Deiner Fusszeile steht (SUSE 11.1 .. Server/Router..), wuerde ich dringend zu einem Update raten.

Gruss Pit.

nein, nein, ich muss mal meine Fußzeile aktualisieren. ;)

Gruß und Danke
worst_case

Huhn Hur Tu
22.05.13, 19:10
SSH nur ueber Key, no root permit, evtl ueber eine Proxykiste mit wenig Zubehoer, aber grosser Sicherheit.

SSH auf einen anderen Port unterhalb von 1024 legen, damit sind die Bruteforce angriffe zu 95% Geschichte.

Evtl einen SS Dummy auf Port 22 schalten, nur um mal ein eigenes Woerterbuch anzulegen.

Fuer die agnz paranoiden kann es dann auch noch der Knockdeamon sein, der den SSH Port nur oeffnet wenn man "angeklopft".

Webmin ist ein Nogo, evtl nur ueber X2go local aufrufbar, mache dir aber bewust dass viele Distributionen aus den Repos geworfen haben da Webmin das System vernichtend konfigurieren kann.

Eine Frage, warum Suse, bei dem du alle 8 - 12 Monate ein Upgrade machen musst --->> Debian rulz, LTS kann man empfehlen.

Gruss Stefan

PeHeller@gmx.net
22.05.13, 20:08
Hallo und Danke für die Infos



Eine Frage, warum Suse, bei dem du alle 8 - 12 Monate ein Upgrade machen musst --->> Debian rulz, LTS kann man empfehlen.

SSH habe ich jetzt nur per publickey realisiert. Port 22 bleibt....Standard bei allen anderen Servern, von mir.

Knockdeamon :confused: habe ich noch nie gehört, muss mal googeln.

Suse.... warum Suse, ja warum eigentlich. Ich bin seit Version 7.0 bei Suse, natürlich ärgern mich die kurzen Versionszeiten, ich habe mal 2 Jahre parallel Kubuntu mitlaufen lassen, war nicht schlecht, ist aber wieder eingeschlafen.
Ich setze immer Apache-Webserver mit KDE ein. Der Server sammelt Messdaten und diese können vor Ort und von Fern verarbeitet und angezeigt werden.

Gruß
worst_case

kreol
22.05.13, 23:16
Hier liegt ssh auf einem Port weit über 1024. Erfolg: Absolut kein "Hintergrundrauschen" von Eindringsversuchern. Das entlastet a) die Nerven und b) die Logs.

Dieses "Standard bei allen anderen Servern, von mir." kapiere ich daher nicht. Warum eine simple Vereinfachung nur deshalb verwerfen, weil man es schon immer so gemacht hat?

Kreol

PeHeller@gmx.net
23.05.13, 00:12
Hallo,



Warum eine simple Vereinfachung nur deshalb verwerfen, weil man es schon immer so gemacht hat?Kreol

Ich müsste alle Scripte die kopieren/synchronisieren bei mir und beim Kunden anpassen. Der Kunde muss entweder per Aufruf der Scripte die Portnummer mitgeben oder alle Scripte doppelt haben um bei unterschiedlichen Servern (Portunterschied) anders darauf zu reagieren.

Es ist nicht so einfach, alles "einfach" zu ändern..... es hängt sehr viel mehr an dieser Portnummer ;) ... auch an SUSE.

Gruß
worst_case

kreol
23.05.13, 01:03
Ich müsste alle Scripte die kopieren/synchronisieren bei mir und beim Kunden anpassen. Der Kunde muss entweder per Aufruf der Scripte die Portnummer mitgeben oder alle Scripte doppelt haben um bei unterschiedlichen Servern (Portunterschied) anders darauf zu reagieren.

Es ist nicht so einfach, alles "einfach" zu ändern..... es hängt sehr viel mehr an dieser Portnummer ;) ... auch an SUSE.

Gruß
worst_caseAuf lange Sicht ist die einmalige Anpassung der Skripte imho einfacher, zumal die (sehr vernünftige) Umstellung auf Key-Authentification ohnehin Eingriffe in die config(s) erfordert. Und von "Kunden" war bisher nicht die Rede...

Aber das kannst nur Du entscheiden ;)

Kreol

HirschHeisseIch
23.05.13, 07:28
Port 22 kann man lassen. Unterdrückt - wie schon erwähnt - nur das Hintergrund-Rauschen. Wer rein will, findet auch den SSHd auf Port 65000.
Wen die Log-Einträge von Script-Kiddies nicht stören, fährt mit Port 22 genau so sicher wie mit jedem anderen auch.

Aber dass noch Passwort-Auth aktiv war... Vor allem bei Kundenzugriff ist schon nahezu unverantwortlich.
Zumal die Konfiguration denkbar simpel ist, und dafür Scripts sich deutlich einfacher gestalten lassen, als mit expect o.ä. den Login zu basteln.

PeHeller@gmx.net
23.05.13, 09:51
Morgen,



Aber dass noch Passwort-Auth aktiv war... Vor allem bei Kundenzugriff ist schon nahezu unverantwortlich.

:rolleyes:
Ja..Ja.. ich werde mich diese Woche noch bessern und die Umstellung mit dem Kunden besprechen. Ich bin ja lernwillig. :D

Danke
worst_case

Huhn Hur Tu
23.05.13, 13:20
Der SSH Port oberhalb kann von einem normalen User besetzt werden, was heisst dass der Port gehijackt werden kann, bei Ports unterhalt 1024 kann das nur root, dort muss der Angreifer wenigstens root Rechte haben.

Gruss Stefan

Huhn Hur Tu
23.05.13, 13:24
Bei Ports oberhalb von 1024 sollte man beachten dass unter Linux die Ports 32768 bis 61000 dynamisch vergeben werden und man dort keine Diensten keine Ports zuweisen sollte, da es sein kann das ein fest vergebener Port versucht wird dynamisch zu vergeben, was dann nach dem "wer zuerst kommt, ..." Prinzip beim zweiten schief geht.

Gruss Stefan

TheDarkRose
23.05.13, 17:36
Kunden, SSH-Passwort, grafische Oberfläche, Webmin, irgendwie passt das nicht ganz zusammen

PeHeller@gmx.net
25.05.13, 11:27
Hallo,


Kunden, SSH-Passwort, grafische Oberfläche, Webmin, irgendwie passt das nicht ganz zusammen

Kunden : Ja
SSH-Passwort : jetzt PublicKey
grafische Oberfläche : je nach Kunde Anforderung
Webmin: nur vor Ort und wird jedes mal gestartet/gestoppt. Niemals Portfreigabe nach aussen.

Ich denke das diese Konstellation jetzt sehr gut zusammenpasst :D

Gruß
worst_case

TheDarkRose
25.05.13, 14:07
Lass Webmin weg..