Viper780
Er ist tot, Jim!
|
Grüß euch
Hat von euch schon wer eine Fail2Ban Instanz für größere Netze mit mehreren tausend Webservern eingesetzt? Wir haben aktuell für jeden einzelnen Service eine eigene Fail2Ban installation und somit werden auch nur die logs des jeweiligen Servers zum blocken her genommen. Teilweise replizieren wir gewisse Filterlisten - das Problem ist aber dass wir den traffic am liebsten erst garnicht in unser Netz lassen würden.
Mit den paar GBit pro Uplink kommen aber die ersten Versuche von uns nicht so ganz zu recht. Am besten wärs wenn wir da eine entsprechende Hardware einsetzen könnten welche die Filterlisten versteht oder eben ein ähnliches Service anbieten
|
COLOSSUS
AdministratorGNUltra
|
Was hat die Anzahl der Regeln/Bans mit der Bandbreite des Uplinks zu tun? Mit ipsets und nftables ist das auf halbwegs aktueller Hardware heute gar kein Problem - schwierig wird eher die Koordination des Regelsatzes ueber (etwas aehnliches wie) fail2ban.
Wenn ihr so viele Hosts betreibt, seid ihr wohl mit einer Eigenentwicklung dazu besser bedient, die mit dem Paketfiltermechanismus eurer wahl maszgeschneidert interagiert. Aufgrund der Funktionsweise (single-threaded parsen von Logfiles mit der nicht-gerade-allerschnellsten regex-Engine) wuerde ich fail2ban nicht fuer so ein Szenario in Erwaegung ziehen.
|
Viper780
Er ist tot, Jim!
|
Anzahl der Regeln nicht unbedingt aber wir bekommen die Bandbreite von ned ganz 100GBit pro Rechenzentrum nicht über Standardhardware drüber.
Ich hätt gehofft ich komm einer Eigenentwicklung und dem nötigen Support dafür aus. Bindet halt wieder Ressourcen die man über all anders besser einsetzen kann
|
Neo-=IuE=-
Here to stay
|
Was heißt "nicht über standard hardware drüber"? Enterprise Hersteller schaffen das locker. Da geht auch das 10-fache.
|
mr.nice.
differential image maker
|
Suricata ist open source, multithreaded und skaliert daher besser, könnte man mittlerweile sogar per GPU beschleunigen, dennoch wird es jemanden brauchen um initial etwas Optimierungsarbeit zu leisten.
|
Viper780
Er ist tot, Jim!
|
Was heißt "nicht über standard hardware drüber"? Enterprise Hersteller schaffen das locker. Da geht auch das 10-fache. Gerne wennst einen Vorschlag hast. Haben jetzt nicht die neueste Hardware genommen, aber die Tests waren etwas ernüchternd @mr.nice Schau ich mir an. Das man da etwas Zeit rein steckt ist eh klar. Wenn ich da aber 1PT pro Woche fürn Betrieb aufwenden muss zahlt es sich nicht mehr aus. Deshalb gerne auch was kommerzielles
|
mr.nice.
differential image maker
|
|
Viper780
Er ist tot, Jim!
|
Ich persönlich würd auch sehr gerne den ELK Stack (bzw Elastic Stack) einsetzen, aber da sind wir noch nicht so weit - das könnte aber der Auslöser dafür sein.
Splunk kommt ja genau aus der Security Ecke - bin mir nur nicht sicher ob es da sonstige Synergien gibt (die bei Logstash da wären)
SELKS schaut sehr interessant aus, da kan man mit einer live installation das mal testen.
Was setzt ihr für kommerzielle Lösung ein und wie ist die im vergleich zu fail2ban welche du dir privat glaub ich angesehen hast
|
mr.nice.
differential image maker
|
Fail2ban ist ja dafür gedacht Einbruchsversuche zu erkennen und zu unterbinden, vorwiegend wird es zur Absicherung von ssh Zugängen verwendet, kann aber auch für andere Dienste genutzt werden.
Wir haben es bei uns unter anderem so gelöst, die Anzahl von Einbruchsversuchen von vorn herein minimal zu halten, indem die aus dem Internet erreichbaren Dienste ganz stark reduziert sind. Die allermeisten Managementzugänge benötigen daher einen VPN-Zugang, der an eine zweifaktor Authentifizierung und einen AD-User oder eine site-to-site VPN-Verbindung geknüpft sind.
Jetzt könnte man jedem VPN user eine fixe IP-Adresse in dem Management VLAN zuweisen, die widerrum nur auf die für sie freigeschalteten hosts, ports bzw. Netze connecten darf. Bei verdächtigen Verbindungsversuchen ließe sich auch feststellen, wessen Zugang kompromittiert wurde, bzw. wer der cracker ist und könnte entsprechende Gegenmaßnahmen ergreifen.
|
Viper780
Er ist tot, Jim!
|
Bei internen Services wird es auch so ähnlich gemacht. Da hängt nur der VPN und Email server im Netz.
Aber unser Business ist das Server vom Internet aus erreichbar sind. Und die werden unter anderem mit fail2ban als IPS geschützt. Aber halt mit viel Aufwand da auf jedem service einzeln.
|
mr.nice.
differential image maker
|
Verstehe, in diesem Fall macht es Sinn die Logfiles zu sammeln und an eine vorschaltete Instanz im Netzwerk zu schicken, die das filtern übernimmt, SELKS testen Ich denke man könnte recht viel Aufwand einsparen, wenn Kunden selbst definieren können, aus welchen Ländern die jeweiligen Zugänge erreichbar sein sollen, Stichwort Geo-IP filtering.
|
Viper780
Er ist tot, Jim!
|
Dafür sind die Kunden etwas zu unbedarft, aber wenn wir einen Angriff auf einen Server haben könnten wir die IP gleich für alle sperren und das direkt am jeweiligen Backbone.
Damit würden die Server und das Netzwerk nicht mehr belastet werden und besserer Schutz für alle.
|