Im Jahr 2010 hatte das Unternehmen 50 Server und ein einfaches Netzwerkmodell: Backend, Frontend und Firewall. Die Anzahl der Server wuchs, das Modell wurde komplexer: Staging, isolierte VLAN mit ACL, dann VPN mit VRF, VLAN mit ACL auf L2, VRF mit ACL auf L3. Verwirrend? Es wird noch spannender.
Als die Anzahl der Server auf 16.000 anstieg, wurde es unmöglich, mit so vielen heterogenen Segmenten ohne Schwierigkeiten zu arbeiten. Daher wurde eine andere Lösung entwickelt. Der Netfilter-Stack wurde genutzt und mit Consul als Datenquelle kombiniert, was zu einer schnellen verteilten Firewall führte. Damit wurden ACLs an Routern ersetzt und als externe sowie interne Firewall eingesetzt. Für das dynamische Management des Werkzeugs wurde das BEFW-System entwickelt, das überall angewendet wurde: von der Benutzerzugriffsverwaltung im Produktnetzwerk bis zur Isolierung von Netzwerksegmenten voneinander.
Wie das alles funktioniert und warum Sie dieses System in Betracht ziehen sollten, wird Ivan Agarov () — Leiter der Gruppe für Infrastruktur-Sicherheit bei der Maintenance-Abteilung im Entwicklungszentrum in Minsk. Ivan ist ein Fan von SELinux, liebt Perl und programmiert. Als Leiter der IS-Gruppe arbeitet er regelmäßig mit Logs, Backups und F&E, um Wargaming vor Hackern zu schützen und den Betrieb aller Spielserver im Unternehmen zu gewährleisten.
Historischer Hintergrund
Bevor ich erzähle, wie wir das gemacht haben, möchte ich erläutern, wie wir überhaupt dazu gekommen sind und warum das notwendig wurde. Dazu reisen wir 9 Jahre zurück: ins Jahr 2010, als gerade World of Tanks aufkam. Wargaming hatte etwa 50 Server.
Wachstumskurve der Server des Unternehmens.
Wir hatten ein Netzwerkmodell. Für die damalige Zeit war es optimal.
Das Netzwerkmodell im Jahr 2010.
Frontend wird von bösen Akteuren bewohnt, die uns beschädigen möchten, aber es gibt eine Firewall. Im Backend gibt es keine Firewall, aber dort befinden sich 50 Server, die wir alle kennen. Alles funktioniert gut.
Innerhalb von 4 Jahren hat sich der Serverpark auf das 100-fache vergrößert, auf 5000. Es entstanden die ersten isolierten Netzwerke – Staging: sie dürfen nicht ins Produktionsumfeld, da dort häufig potenziell gefährliche Dinge ablaufen.
Das Netzwerkmodell im Jahr 2014.
Wir haben aus Gewohnheit die gleichen Hardware-Ressourcen verwendet, und die gesamte Arbeit wurde auf isolierten VLANs durchgeführt: Für VLANs wurden ACLs geschrieben, die bestimmte Verbindungen erlauben oder verbieten.
Im Jahr 2016 erreichte die Anzahl der Server 8000. Wargaming übernahm andere Studios und es entstanden zusätzliche Partnernetzwerke. Sie scheinen zwar zu uns zu gehören, funktionieren jedoch nicht immer: Für Partner funktionieren die VLANs oft nicht, und es muss auf VPN mit VRF zurückgegriffen werden, was die Isolierung komplizierter macht. Das Mischungsverhältnis der ACL-Isolierungen wuchs.
Netzwerkmodell im Jahr 2016.
Bis Anfang 2018 wuchs der Fuhrpark auf 16.000 Maschinen. Es gab 6 Segmente, die anderen zählten wir nicht, einschließlich der geschützten, in denen Finanzdaten gespeichert waren. Container-Netzwerke (Kubernetes), DevOps, und cloudbasierte Netzwerke, die beispielsweise über VPN aus dem Rechenzentrum verbunden sind, kamen hinzu. Es gab unzählige Regeln – es war schmerzhaft.
Netzwerkmodell und Isolierungsmethoden im Jahr 2018.
Zur Isolierung verwendeten wir: VLAN mit ACL auf L2, VRF mit ACL auf L3, VPN und vieles mehr. Viel zu viel.
Die Probleme
Alle arbeiten mit ACL und VLAN. Was ist also das Problem? Diese Frage beantwortet Harold, der den Schmerz verbirgt.
Es gab viele Probleme, aber nur fünf davon waren massenhaft.
- Geometrisches Wachstum der Kosten für neue Regeln. Jede neue Regel dauerte länger als die vorherige, da zuerst geprüft werden musste, ob es nicht bereits eine solche Regel gab.
- Es gibt keine Firewall innerhalb der Segmente.. Die Segmente wurden irgendwie voneinander getrennt, es mangelte bereits an Ressourcen.
- Die Regeln wurden langsam angewendet. Ein lokales Regelwerk konnten die Operatoren von Hand in einer Stunde schreiben. Ein globales dauerte mehrere Tage.
- Schwierigkeiten bei der Prüfung der Regeln.. Genauer gesagt, eine Prüfung war nicht möglich. Die ersten Regeln wurden bereits 2010 verfasst, und die meisten ihrer Autoren arbeiteten nicht mehr im Unternehmen.
- Niedriges Niveau der Infrastrukturkontrolle.. Das ist das Hauptproblem – wir wussten schlecht, was bei uns überhaupt vor sich ging.
So sah ein Netzwerkingenieur im Jahr 2018 aus, als er hörte: „Wir brauchen noch ein bisschen ACL“.
Lösungen
Anfang 2018 wurde beschlossen, etwas dagegen zu unternehmen.
Die Kosten für Integrationen steigen kontinuierlich. Ausgangspunkt war, dass große Rechenzentren die Unterstützung für isolierte VLANs und ACLs eingestellt hatten, weil der Speicher auf den Geräten erschöpft war.
Lösung: Der menschliche Faktor wurde beseitigt und der Zugang so weit wie möglich automatisiert.
Neue Regeln werden langsam angewendet. Lösung: Die Anwendung von Regeln beschleunigen und parallelisieren. Dazu ist ein verteiltes System erforderlich, damit die Regeln selbstständig ohne rsync oder SFTP auf tausend Systeme geliefert werden.
Fehlender Firewall innerhalb der Segmente. Die Firewall in den Segmenten wurde notwendig, als in einem Netzwerk verschiedene Dienste auftauchten. Lösung: Verwendung von Host-basierten Firewalls. Überall haben wir Linux, und überall gibt es iptables, das ist kein Problem.
Schwierigkeiten bei der Überprüfung der Regeln. Lösung: Alle Regeln an einem zentralen Ort für Überwachung und Verwaltung speichern, so können wir alles auditen.
Niedriger Kontrollgrad über die Infrastruktur. Lösung: Eine Bestandsaufnahme aller Dienste und Zugriffe zwischen diesen durchführen.
Es handelt sich mehr um einen administrativen Prozess als um einen technischen. Manchmal haben wir 200-300 neue Releases pro Woche, insbesondere während Aktionen und Feiertagen. Dies gilt nur für ein Team unserer DevOps. Bei dieser Anzahl an Releases ist es unmöglich zu erkennen, welche Ports, IPs und Integrationen erforderlich sind. Daher benötigten wir speziell geschulte Service-Manager, die die Teams befragten: "Was gibt es überhaupt und warum habt ihr das hochgezogen?"
Nach allem, was wir gestartet haben, sieht ein Netzwerkingenieur im Jahr 2019 bereits so aus.
Consul
Wir haben beschlossen, alles, was wir mit Hilfe der Service-Manager gefunden haben, in Consul zu speichern und von dort aus die iptables-Regeln zu schreiben.
Wie haben wir uns entschieden, das zu tun?
- Wir sammeln alle Services, Netzwerke und Nutzer.
- Auf dieser Basis erstellen wir iptables-Regeln.
- Wir automatisieren die Überwachung.
- ….
- PROFIT.
Consul ist keine entfernte API; es kann auf jedem Knoten arbeiten und in iptables schreiben. Es bleibt nur, automatische Kontrollmittel zu entwickeln, die Überflüssiges beseitigen, und der Großteil der Probleme wird gelöst sein! Den Rest klären wir im Prozess.
Warum Consul?
Hat sich gut bewährt. In den Jahren 2014-2015 haben wir es als Backend für Vault verwendet, in dem wir Passwörter speichern.
Verliert keine Daten. Während der Nutzung hat Consul bei keinem einzigen Vorfall Daten verloren. Das ist ein großer Vorteil für das Firewall-Management-System.
P2P-Verbindungen beschleunigen die Verbreitung von Änderungen. Mit P2P kommen alle Änderungen schnell, man muss nicht stundenlang warten.
Benutzerfreundliche REST API. Wir haben auch Apache ZooKeeper in Betracht gezogen, aber es hat keine REST API, also müssten wir eine workaround-Lösung implementieren.
Funktioniert sowohl als Schlüsselwertspeicher (KV) als auch als Katalog (Service Discovery). Man kann sowohl Services, Kataloge als auch Rechenzentren speichern. Das ist nicht nur für uns praktisch, sondern auch für benachbarte Teams, denn beim Aufbau eines globalen Services denken wir groß.
In Go geschrieben, das Teil des Tech-Stacks von Wargaming ist. Wir lieben diese Sprache, wir haben viele Go-Entwickler.
Leistungsstarkes ACL-System. Mit ACL in Consul können wir steuern, wer was schreiben darf. Wir garantieren, dass die Firewall-Regeln nichts überlappen und wir damit keine Probleme haben.
Aber Consul hat auch Nachteile.
- Skaliert nicht innerhalb des Rechenzentrums, es sei denn, Sie haben die Business-Version. Es kann nur durch Föderation skaliert werden.
- Sehr abhängig von der Netzwerkqualität und der Serverauslastung. Consul wird nicht richtig funktionieren, wenn es als Server auf einem überlasteten Server läuft und es Netzwerkprobleme gibt, wie beispielsweise eine inkonstante Geschwindigkeit. Dies steht im Zusammenhang mit P2P-Verbindungen und den Modellen zur Verbreitung von Updates.
- Schwierigkeiten bei der Überwachung der Verfügbarkeit. Der Status von Consul kann anzeigen, dass alles in Ordnung ist, während es bereits ausgefallen ist.
Die meisten dieser Probleme haben wir während des Betriebs von Consul gelöst, weshalb wir uns für ihn entschieden haben. Das Unternehmen hat Pläne für ein alternatives Backend, aber wir haben gelernt, mit Problemen umzugehen und leben derzeit weiterhin mit Consul.
Wie Consul funktioniert
In einem hypothetischen Rechenzentrum installieren wir Server — zwischen drei und fünf. Eins oder zwei Server sind unzureichend: Sie können kein Quorum bilden und entscheiden, wer recht hat, wenn die Daten nicht übereinstimmen. Mehr als fünf macht keinen Sinn, die Leistung würde abnehmen.
Die Server können in beliebiger Reihenfolge mit den Clients verbunden werden: dieselben Agenten, nur mit dem Flag server = false.
Danach erhalten die Clients eine Liste der P2P-Verbindungen und bauen Verbindungen untereinander auf.
Auf globaler Ebene verbinden wir mehrere Rechenzentren miteinander. Diese sind ebenfalls über P2P verbunden und kommunizieren.
Wenn wir Daten von einem anderen Rechenzentrum abrufen möchten, erfolgt die Anfrage serverseitig. Dieses Verfahren wird genannt Serf-Protokoll. Das Serf-Protokoll, ähnlich wie Consul, wurde von HashiCorp entwickelt.
Ein paar wichtige Fakten über Consul
Consul verfügt über eine Dokumentation, die seine Funktionsweise beschreibt. Ich werde nur einige ausgewählte Fakten anführen, die wichtig sind.
Consul-Server wählen aus den Abstimmenden einen Master aus. Consul wählt den Master aus der Liste der Server für jedes Rechenzentrum aus, und alle Anfragen laufen nur über ihn, unabhängig von der Anzahl der Server. Ein Ausfall des Masters führt nicht zu einer Neuwahl. Wenn kein Master gewählt ist, werden Anfragen von niemandem bearbeitet.
Sie wollten horizontale Skalierung? Tut uns leid, das gibt es nicht.
Die Anfrage an ein anderes Rechenzentrum erfolgt von Master zu Master, unabhängig davon, auf welchem Server sie ankommt. Der ausgewählte Master übernimmt 100% der Last, abgesehen von der Last für die Weiterleitung von Anfragen. Eine aktuelle Kopie der Daten befindet sich auf allen Servern des Rechenzentrums, aber nur einer antwortet.
Der einzige Weg zu skalieren, besteht darin, den stale-Modus auf dem Client zu aktivieren.
Im Stale-Modus kann ohne Quorum geantwortet werden. Dies ist ein Modus, in dem wir auf Datenkonsistenz verzichten, aber schneller lesen können als gewöhnlich, und jeder Server antwortet. Natürlich erfolgt das Schreiben nur über den Master.
Consul kopiert keine Daten zwischen den Rechenzentren.Bei der Zusammenstellung einer Föderation hat jeder Server nur seine eigenen Daten. Für andere Daten fragt er immer bei einem anderen nach.
Die Atomarität von Operationen ist außerhalb einer Transaktion nicht garantiert.Denken Sie daran, dass nicht nur Sie etwas ändern können. Wenn Sie es anders möchten, führen Sie eine Transaktion mit Sperre durch.
Blockierende Operationen garantieren keine Sperre.Die Anfrage geht vom Master zum Master und nicht direkt, daher gibt es keine Garantien, dass die Sperre funktioniert, wenn Sie beispielsweise in einem anderen Rechenzentrum eine Sperre vornehmen.
ACL garantiert ebenfalls keinen Zugriff (in vielen Fällen).ACL kann fehlschlagen, da es in einem Rechenzentrum der Föderation gespeichert ist – im ACL-Rechenzentrum (Primäres Rechenzentrum). Wenn das Rechenzentrum Ihnen nicht antwortet, funktioniert die ACL nicht.
Ein hängender Master führt dazu, dass die gesamte Föderation hängt.. Zum Beispiel in einer Föderation mit 10 Rechenzentren, von denen eines ein schlechtes Netzwerk hat und ein Knotenpunkt ausfällt. Alle, die mit diesem verbunden sind, hängen im Kreis: eine Anfrage wird gesendet, aber es gibt keine Antwort, der Thread hängt. Man kann nicht vorhersagen, wann es passiert, nach einer Stunde oder zwei wird die gesamte Föderation ausfallen. Sie können dagegen nichts unternehmen.
Der Status, das Quorum und die Wahlen werden von einem separaten Thread verarbeitet. Es wird keine Neuwahl stattfinden, der Status wird nichts anzeigen. Sie denken, Sie haben einen aktiven Consul, stellen Anfragen, und es passiert nichts – es gibt keine Antwort. Währenddessen zeigt der Status an, dass alles in Ordnung ist.
Wir sind auf dieses Problem gestoßen und mussten bestimmte Teile der Rechenzentren neu konfigurieren, um es zu vermeiden.
In der Business-Version von Consul Enterprise sind einige der oben genannten Mängel nicht vorhanden.. Es bietet viele nützliche Funktionen: Wählerauswahl, Verteilung, Skalierung. Es gibt nur einen Haken – das Lizenzierungssystem für die verteilte Infrastruktur ist sehr teuer.
Life Hack: rm -rf /var/lib/consul – das Allheilmittel für alle Probleme des Agenten. Wenn bei Ihnen etwas nicht funktioniert, löschen Sie einfach Ihre Daten und laden Sie sie aus einer Sicherung wieder hoch. Wahrscheinlich wird Consul dann wieder funktionieren.
BEFW
Jetzt sprechen wir darüber, was wir zu Consul hinzugefügt haben.
— ist ein Akronym für BackEndFireWalle. Ich musste einen Namen für das Produkt finden, als ich das Repository erstellt habe, um die ersten Testcommits darin abzulegen. So blieb der Name bestehen.
Regelvorlagen
Die Regeln sind im iptables-Syntax geschrieben.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
- -A INPUT -i lo -j ACCEPT
- -A INPUT -j BEFW
Alles fließt in die Kette BEFW, außer ETABLISHED, RELATED und localhost. Die Vorlage kann beliebig sein, das ist nur ein Beispiel.
Was ist der Nutzen von BEFW?
Dienste
Wir haben einen Service, bei dem es immer einen Port gibt, auf dem die Node läuft. Von unserer Node können wir lokal den Agenten fragen und herausfinden, dass wir einen bestimmten Service haben. Außerdem können Tags gesetzt werden.
Jeder Service, der läuft und in Consul registriert ist, wird zu einer iptables-Regel. Wir haben SSH — wir öffnen den Port 22. Das Bash-Skript ist einfach: curl und iptables, mehr braucht man nicht.
Windows XP, Vista, 7, 8, 10, Server 2003, Server 2008, Server 2012
Wie öffnet man den Zugang nicht für alle, sondern selektiv? Man speichert die IP-Listen im KV-Speicher nach dem Servicenamen.
Zum Beispiel möchten wir, dass alle aus dem zehnten Netz auf den SSH_TCP_22-Service zugreifen können. Wir fügen ein kleines Feld TTL? hinzu und jetzt haben wir temporäre Berechtigungen, zum Beispiel für einen Tag.
Zugriffe
Wir verbinden Dienste und Kunden: Für jeden Dienst haben wir ein bereitgestelltes KV-Storage. Jetzt gewähren wir den Zugang nicht für alle, sondern selektiv.
Gruppen
Wenn wir jedes Mal tausende IP-Adressen für Zugriffe schreiben, werden wir müde. Wir entwickeln Gruppierungen – ein separates Subset im KV. Wir nennen es Alias (oder Gruppen) und speichern dort Gruppen nach demselben Prinzip.
Wir verbinden: Jetzt können wir SSH nicht nur konkret für P2P, sondern für eine ganze Gruppe oder mehrere Gruppen öffnen. Ebenso gibt es TTL – man kann Gruppen temporär hinzufügen oder entfernen.
Integration
Unser Problem ist der menschliche Faktor und die Automatisierung. Momentan haben wir es so gelöst.
Wir arbeiten mit Puppet und übertragen alles, was zum System gehört (Anwendungscode). In puppetdb (normaler PostgreSQL) wird eine Liste der dort laufenden Dienste gespeichert, die man anhand des Ressourcentyps finden kann. Dort kann man ebenfalls sehen, wer wohin zugreift. Zudem haben wir ein System für Pull- und Merge-Requests dafür.
Wir haben befw-sync geschrieben – eine einfache Lösung, die hilft, Daten zu übertragen. Zuerst greifen die Sync-Cookies auf puppetdb zu. Dort ist ein HTTP API eingerichtet: Wir fragen, welche Dienste wir haben und was zu tun ist. Danach erfolgt die Anfrage an Consul.
Gibt es eine Integration? Ja: Wir haben die Regeln geschrieben und Pull Requests genehmigt. Brauchen wir einen bestimmten Port oder müssen wir einen Host zu einer Gruppe hinzufügen? Pull Requests, Reviews – keine weiteren „Finde 200 andere ACLs und versuche etwas damit zu machen“ mehr.
Optimierung
Der Ping zu localhost mit einer leeren Regelkette beträgt 0,075 ms.
Wir werden dieser Kette 10.000 Adressen in iptables hinzufügen. In der Folge wird sich der Ping verfünffachen: iptables ist vollständig linear, die Verarbeitung jeder Adresse benötigt eine gewisse Zeit.
Für die Firewall, in die wir Tausende von ACLs migrieren, haben wir viele Regeln, was zu Verzögerungen führt. Für Spieleprotokolle ist das schlecht.
Aber wenn wir 10.000 Adressen in ipset packen, wird der Ping sogar geringer.
Der Punkt ist, dass "O" (Algorithmuskomplexität) für ipset immer 1 beträgt, egal wie viele Regeln es gibt. Es gibt allerdings eine Beschränkung – die Anzahl der Regeln darf 65.535 nicht überschreiten. Aktuell leben wir damit: Man kann sie kombinieren, erweitern und zwei ipsets in einem erstellen.
Speicherung
Ein logischer nächster Schritt im Prozess der Iterationen ist die Speicherung von Kundeninformationen für den Dienst in ipset.
Jetzt haben wir dasselbe SSH und schreiben nicht sofort 100 IPs, sondern geben den Namen des ipset an, mit dem wir kommunizieren müssen, sowie die nächste Regel. LÖSCHEN. Man könnte es in eine Regel umformulieren: „Wer nicht hier ist, wird ausgeschlossen“, aber so ist es anschaulicher.
Jetzt haben wir Regeln und Sets. Die Hauptaufgabe besteht darin, ein Set zu erstellen, bevor die Regel geschrieben wird, denn sonst wird iptables die Regel nicht speichern.
Übersicht
In Diagrammform sieht alles, was ich erklärt habe, so aus.
Wir committen in Puppet, alles wird auf den Host gesendet, die Dienste sind hier, ipset dort, und wer dort nicht eingetragen ist, wird nicht hereingelassen.
Erlauben & verbieten
Um die Welt schnell zu retten oder um schnell jemanden auszuschalten, haben wir am Anfang aller Ketten zwei ipsets erstellt: rules_allow und rules_deny. Wie funktioniert das?
Wenn jemand mit Bots Last auf unser Web erzeugt. Früher musste man seine IP in den Logs suchen, zu den Netzwerkingenieuren gehen, damit sie die Quelle des Datenverkehrs finden und sie sperren. Jetzt sieht das anders aus.
Wir senden es an Consul, warten 2,5 Sekunden, und es ist erledigt. Da Consul aufgrund von P2P schnell verteilt, funktioniert es überall, egal wo auf der Welt.
Einmal habe ich völlig WOT gestoppt, weil ich einen Fehler mit der Firewall gemacht habe. rules_allow - das ist unsere Versicherung gegen solche Fälle. Wenn wir irgendwo einen Fehler mit der Firewall gemacht haben und etwas blockiert wird, können wir immer einen sogenannten 0.0/0, um alles schnell wieder in Betrieb zu nehmen. Danach werden wir alles manuell reparieren.
Andere Sets
Es können beliebige andere Sets im Raum hinzugefügt werden $IPSETS$.
Warum? Manchmal benötigt jemand ipset, um beispielsweise das Abschalten eines Teils des Clusters zu simulieren. Jeder kann beliebige Sets mitbringen, sie benennen, und sie werden aus Consul abgerufen. Dabei können die Sets sowohl an den iptables-Regeln teilnehmen als auch als eine Art Befehl fungieren. NOOP: die Konsistenz wird durch einen Daemon aufrechterhalten.
Benutzer
Früher war es so: Der Benutzer stellte eine Verbindung zum Netzwerk her und erhielt die Einstellungen über die Domain. Bis zur Einführung neuer Firewall-Generation konnte Cisco nicht verstehen, wo sich der Benutzer und wo die IP befand. Daher wurde der Zugang nur über den Hostnamen der Maschine gewährt.
Was haben wir gemacht? Wir haben uns in den Moment des Adressabrufs eingeklinkt. Normalerweise geschieht dies über dot1x, WLAN oder VPN – alles läuft über RADIUS. Für jeden Benutzer erstellen wir eine Gruppe mit dem Benutzernamen und fügen die IP mit einer TTL hinzu, die der dhcp.lease entspricht – sobald diese abläuft, verschwindet die Regel.
Jetzt können wir den Zugang zu Diensten wie in anderen Gruppen über den Benutzernamen öffnen. Wir haben die Probleme mit Hostnamen, die sich ändern, beseitigt und die Last von Netzwerkingenieuren genommen, da sie nun nicht mehr auf Cisco angewiesen sind. Jetzt schreiben die Ingenieure selbstständig die Zugriffsrechte auf ihren Servern.
Isolierung
Parallel dazu haben wir mit der Überprüfung der Isolation begonnen. Die Service-Manager haben eine Bestandsaufnahme erstellt, und wir haben alle unsere Netzwerke analysiert. Wir teilen sie in dieselben Gruppen auf, und auf den erforderlichen Servern wurden diese Gruppen beispielsweise in die Deny-Listen hinzugefügt. Jetzt gelangt dasselbe Staging-Isolationsschema in die rules_deny der Produktionsumgebung, jedoch nicht in die Produktionsumgebung selbst.
Das System funktioniert schnell und einfach: Wir entfernen alle ACLs von den Servern, entlasten die Hardware und verringern die Anzahl der isolierten VLANs.
Integritätsüberwachung
Früher hatten wir einen speziellen Trigger, der informierte, wenn jemand manuell eine Firewall-Regel änderte. Ich habe einen umfangreichen Linter zur Überprüfung der Firewall-Regeln geschrieben, was kompliziert war. Jetzt überwacht die BEFW die Integrität. Sie sorgt gewissenhaft dafür, dass die Regeln, die sie erstellt, nicht geändert werden. Wenn jemand die Firewall-Regeln ändert, wird alles zurückgesetzt. ‚Ich habe hier schnell einen Proxy eingerichtet, um von zu Hause zu arbeiten‘ – solche Optionen gibt es nicht mehr.
Die BEFW überwacht das IP-Set aus den Services und der Liste in befw.conf sowie die Service-Regeln in der BEFW-Kette. Sie überwacht jedoch nicht andere Ketten und Regeln sowie andere IP-Sets.
Havarie-Schutz
BEFW speichert immer den letzten funktionierenden Zustand direkt in der binären Struktur state.bin. Wenn etwas schiefgeht, wird er immer zu diesem state.bin zurückkehren.
Das ist eine Versicherung gegen instabile Arbeitsweise von Consul, wenn keine Daten gesendet wurden oder jemand einen Fehler gemacht hat und Regeln verwendet hat, die nicht angewendet werden können. Damit wir nicht ohne Firewall dastehen, wird BEFW auf den letzten Zustand zurückgesetzt, wenn an irgendeinem Punkt ein Fehler auftritt.
In kritischen Situationen ist das eine Garantie, dass wir mit einer funktionierenden Firewall bleiben. Wir öffnen alle grauen Netze in der Hoffnung, dass der Administrator kommt und es repariert. Irgendwann werde ich das in die Konfigurationen aufnehmen, aber momentan haben wir einfach drei graue Netze: 10/8, 172/12 und 192.168/16. In unserem Consul ist das eine wichtige Eigenschaft, die uns hilft, weiter zu wachsen.
Demo: Während der Präsentation zeigt Ivan den Demomodus von BEFW. Die Demo lässt sich am besten ansehen auf . Der Quellcode der Demo ist verfügbar .
Herausforderungen
Ich möchte über die Bugs berichten, mit denen wir konfrontiert wurden.
ipset add set 0.0.0.0/0. Was passiert, wenn ich 0.0.0.0/0 in ipset hinzufüge? Werden alle IPs hinzugefügt? Wird der Zugang zum Internet geöffnet?
Nein, wir bekommen einen Bug, der uns zwei Stunden Ausfall gekostet hat. Dieser Bug existiert seit 2016, ist unter der Nummer #1297092 in RedHat Bugzilla vermerkt, und wir haben ihn zufällig entdeckt – durch den Bericht eines Entwicklers.
Jetzt gibt es in BEFW eine strikte Regel, dass 0.0.0.0/0 es zu zwei Adressen wird: 0.0.0.0/1 und 128.0.0.0/1.
ipset restore set < datei. Was macht ipset, wenn Sie ihm sagen, dass er restore? Вы думаете, он работает также, как iptables? Восстановит данные?
Nein, das Gegenteil ist der Fall – es wird zusammengeführt, und die alten Adressen verschwinden nicht, der Zugang wird nicht geschlossen.
Wir haben den Bug entdeckt, als wir die Isolation getestet haben. Jetzt gibt es dort ein recht komplexes System – anstelle von restore wird durchgeführt create temp, dann restore flush temp und restore temp. Am Ende swap: für die Atomarität, denn wenn zunächst flush ein Paket ankommt, wird es verworfen und etwas geht schief. Daher gibt es dort ein bisschen schwarze Magie.
consul kv get -datacenter=other. Wie ich bereits erwähnt habe, denken wir, dass wir einige Daten abfragen, aber wir erhalten entweder Daten oder einen Fehler. Wir können das lokal über Consul machen, aber auch in diesem Fall werden beide Systeme einfrieren.
Der lokale Consul-Client ist eine Wrapper über das HTTP-API. Aber er friert einfach ein und reagiert weder auf Ctrl+C noch auf Ctrl+Z, nichts, nur auf kill -9 in der benachbarten Konsole. Das haben wir festgestellt, als wir einen großen Cluster aufgebaut haben. Aber bisher haben wir noch keine Lösung, wir bereiten uns darauf vor, diesen Fehler in Consul zu beheben.
Der Consul-Leiter antwortet nicht. Unser Master im Rechenzentrum reagiert nicht, wir denken: „Wird der Wahlalgorithmus jetzt wohl funktionieren?“
Nein, es wird nicht funktionieren, und das Monitoring wird nichts anzeigen: Consul wird sagen, dass der Commitment-Index existiert, ein Leiter gefunden wurde, alles in Ordnung.
Wie gehen wir damit um? service consul restart im Cron jede Stunde. Wenn Sie 50 Server haben, ist das nicht schlimm. Wenn es 16.000 werden, werden Sie verstehen, wie das funktioniert.
Fazit
Am Ende haben wir folgende Vorteile erzielt:
- 100% Abdeckung aller Linux-Maschinen.
- Geschwindigkeit.
- Automatisierung.
- Wir haben Hardware und Netzwerkingenieure von ihrer Last befreit.
- Die Integrationsmöglichkeiten, die sich ergeben, sind praktisch unbegrenzt: sei es mit Kubernetes, Ansible oder Python.
Nachteile: Consul, mit dem wir jetzt leben müssen, und der Preis für Fehler ist extrem hoch. Zum Beispiel habe ich einmal um 18 Uhr (Hauptzeit in Russland) etwas an den Netzwerkliste geändert. Genau zu diesem Zeitpunkt haben wir die Isolation auf BEFW gebaut. Ich habe irgendwo einen Fehler gemacht, anscheinend die falsche Maske angegeben, und innerhalb von zwei Sekunden war alles down. Das Monitoring springt an, der Support-Mitarbeiter kommt gerannt: „Bei uns läuft nichts!“ Der Abteilungsleiter wurde grau, als er dem Geschäft erklären musste, warum das passiert ist.
Der Preis für Fehler ist so hoch, dass wir ein eigenes komplexes Präventionsverfahren entwickelt haben. Wenn Sie dies in einer großen Produktionsumgebung implementieren, sollten Sie nicht den Master-Token für Consul an alle weitergeben. Das würde schlecht enden.
Kosten. Ich habe 400 Stunden allein Code geschrieben. Mein vierköpfiges Team benötigt jeden Monat 10 Stunden für den Support für alle. Im Vergleich zu den Kosten für eine beliebige Next-Gen-Firewall ist das kostenlos.
Pläne. Der langfristige Plan besteht darin, nach einem alternativen Transportmittel statt oder zusätzlich zu Consul zu suchen. Möglicherweise wird es Kafka oder etwas Ähnliches sein. Aber in den nächsten Jahren werden wir mit Consul leben.
Zukünftige Pläne: Integration mit Fail2ban, inklusive Monitoring, mit nftables, eventuell auch mit anderen Distributionen, Metriken, erweitertem Monitoring und Optimierung. Unterstützung für Kubernetes steht ebenfalls auf der Agenda, da wir derzeit über mehrere Cluster verfügen und den Wunsch haben.
Weitere Pläne:
- Anomalien im Verkehr erkennen;
- Netzwerkkartenverwaltung;
- Kubernetes-Unterstützung;
- Paketerstellung für alle Systeme;
- Web-UI.
Wir arbeiten kontinuierlich an der Erweiterung der Konfiguration, der Erhöhung der Metriken und der Optimierung.
Schließen Sie sich dem Projekt an. Es ist ein großartiges Projekt geworden, leider ist es derzeit jedoch nur ein Projekt einer Person. Kommen Sie zu und versuchen Sie, etwas zu tun: committen, testen, Vorschläge machen oder Ihr Feedback geben.
In der Zwischenzeit bereiten wir uns auf , das am 6. und 7. April in St. Petersburg stattfinden wird, vor und laden Entwickler von hochbelasteten Systemen ein, . Erfahrene Referenten wissen bereits, was zu tun ist, während wir neuen Sprechern empfehlen, zumindest . Die Teilnahme an der Konferenz als Redner bietet verschiedene Vorteile. Welche das sind, kann man beispielsweise am Ende lesen. .
Quelle: habr.com
