"Christmas - the time to fix the computers of your loved ones" « Lord Wyrm

Fail2Ban als SPF Firewall für große Netze?

Viper780 01.07.2020 - 21:37 893 11
Posts

Viper780

Er ist tot, Jim!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 40257
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

"Hi!"
Avatar
Registered: Dec 2000
Location: Wien || Stmk
Posts: 10891
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!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 40257
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
Registered: Jun 2002
Location: Berndorf, NÖ
Posts: 3134
Was heißt "nicht über standard hardware drüber"?
Enterprise Hersteller schaffen das locker. Da geht auch das 10-fache.

mr.nice.

Newsposter
Here to stay
Avatar
Registered: Jun 2004
Location: Wien
Posts: 4773
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!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 40257
Zitat aus einem Post von Neo-=IuE=-
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.

Newsposter
Here to stay
Avatar
Registered: Jun 2004
Location: Wien
Posts: 4773
Sind halt mehrere Dinge die eingerichtet werden und schließlich ineinander greifen müssen, z.B.: Logstash, Kibana, Elasticsearch und Suricata. Solche Implementierungen sind im Linux-Firewallbereich soweit ich weiß, derzeit state of the art. Wir sind in der Firma bei einer kommerziellen Lösung geblieben, deshalb kam ich noch nicht dazu es in größerem Maßstab einzusetzen. Mit Splunk bzw. SELKS könntest du dir die Umsetzung erleichtern.

Hier ein paar Links dazu:
https://www.howtoforge.com/tutorial...eaver-1804-lts/
https://suricata.readthedocs.io/en/suricata-5.0.3/
https://www.digitalocean.com/commun...ack-on-centos-7

Gibt bald auch einen Kurs:
https://suricata-ids.org/news/

Ein fertiges Paket aus diesen Komponenten und anderen kostenpflichtigen Erweiterungen wäre z.B.:
https://www.stamus-networks.com/scirius-open-source

Zeek als Alternative zu Suricata dürfte auch sehr gut sein und ist speziell für highbandwidth monitoring konzipiert:
https://docs.zeek.org/en/lts/intro/index.html

Viper780

Er ist tot, Jim!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 40257
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.

Newsposter
Here to stay
Avatar
Registered: Jun 2004
Location: Wien
Posts: 4773
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!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 40257
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.

Newsposter
Here to stay
Avatar
Registered: Jun 2004
Location: Wien
Posts: 4773
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!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 40257
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.
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz