Eines schönen Frühlingsabends, als ich nicht nach Hause gehen wollte und das unermüdliche Verlangen zu leben und Neues zu entdecken wie ein heißes Eisen prickle und brennen ließ, kam mir die Idee, ein verlockendes Feature an der Firewall namens „IP DOS-Policy«.
Nach einigen Vorbereitungen und dem Studium des Handbuchs stellte ich es im Modus Pass-and-Log, ein, um den Output und den fragwürdigen Nutzen dieser Einstellung zu beobachten.
Nach ein paar Tagen (natürlich um Statistiken zu sammeln und nicht, weil ich es vergessen hatte) schaute ich in die Protokolle und klatschte begeistert in die Hände — die Einträge hatten sich bis zum Überlaufen angesammelt. Eigentlich könnte es nicht einfacher sein – aktiviere die Politik im Modus, um alle spammenden, scannenden, und halb-offenen Sessions mit einem einstündigen Bann zu blockieren und schlafe in dem Wissen, dass die Grenze gesichert ist. Doch im 34. Lebensjahr überwog der jugendliche Idealismus, und irgendwo im Hinterkopf ertönte eine leise Stimme: „Lass uns die Augenlider heben und schauen, welche Adressen unsere geliebte Firewall als üble Spammer erkannt hat. Nur so aus Neugier.“ Eine Stunde zeitlich gebannte Sessions und du kannst entspannt schlafen, in dem Wissen, dass die Grenze jederzeit gesichert ist. Doch das 34. Lebensjahr hat den jugendlichen Maximalismus überwunden und irgendwo im Hinterkopf meldete sich eine kleine Stimme: „Warum heben wir nicht die Augenlider und sehen nach, welche Adressen unsere geliebte Firewall als bösartige Spammer erkannt hat? So, nur als Gedankenexperiment.“
Wir beginnen mit der Analyse der erhaltenen Daten aus der Liste der Anomalien. Ich lasse die Adressen durch ein einfaches Skript laufen. Powershell und meine Augen stoßen auf bekannte Buchstaben. Google.
Ich reibe mir die Augen, blinzele fünf Minuten, um sicherzugehen, dass ich mir nicht etwas einbilde — tatsächlich steht in der Liste derjenigen, die die Firewall als hartnäckige Spammer identifiziert hat, die Angriffsart — UDP-Flut, Adressen, die der guten Firma gehören.
Ich kratze mir den Hinterkopf, während ich gleichzeitig auf dem externen Interface die Paketerfassung für die nachfolgende Analyse einstelle. In meinem Kopf schwirren schillernde Gedanken: „Wie kann es sein, dass etwas Infiziertes im Google-Scope ist? Und das habe ich entdeckt? Das bedeutet Auszeichnungen, Ehrungen, den roten Teppich, und ein eigenes Casino mit Blackjack und, na ja, ihr wisst schon…“
Ich analysiere die erhaltene Datei Wireshark-er.
Ja, tatsächlich senden Adressen aus dem Scope Google UDP-Pakete vom Port 443 an einen zufälligen Port auf meinem Gerät.
Aber warte mal… Jetzt wechselt das Protokoll zu UDP nachzudenken findet man GQUIC.
Semyon Semyonovich…
Sofort erinnere ich mich an den Bericht von HighLoad Alexander Tobol «UDP nachzudenken gegen TCP oder „Die Zukunft des Netzwerk-Stacks“ ().
Einerseits verspüre ich eine leichte Enttäuschung — weder Lorbeeren noch Ehrungen. Andererseits ist das Problem klar, es bleibt nur zu verstehen, wohin und wie tief ich graben muss.
Ein paar Minuten mit der Wohltätigkeitsorganisation und alles kommt an seinen Platz. Um die Geschwindigkeit der Bereitstellung von Inhalten zu verbessern, kündigte das Unternehmen bereits 2012 ein Protokoll an, Google das es ermöglicht, die meisten Nachteile von TCP zu beseitigen (ja, in diesen Artikeln — QUICman spricht von einem völlig revolutionären Ansatz, aber seien wir ehrlich, wir möchten, dass Katzenbilder schneller geladen werden, und nicht all diese Revolutionen des Denkens und Fortschritts). Wie weitere Untersuchungen zeigten, wechseln viele Organisationen jetzt zu einer solchen Methode der Inhaltsbereitstellung. und Es wird von einem völlig revolutionären Ansatz gesprochen, aber seien wir ehrlich, es wäre schön, wenn die Katzenbilder schneller geladen werden würden, anstatt all dieser revolutionären Bewusstseins- und Fortschrittsgeschichten). Wie die weitere Forschung gezeigt hat, wechselt jetzt eine Vielzahl von Unternehmen zu einem solchen Ansatz für die Bereitstellung von Inhalten.
Das Problem in meinem Fall, und ich denke, auch in vielen anderen, lag darin, dass schließlich zu viele Pakete gesendet werden und die Firewall diese als Flood interpretiert.
Es gab nicht viele Lösungsmöglichkeiten:
1. Adressen zur Ausnahmeliste für DoS Policy in der Firewall hinzufügen. GoogleBei nur dem Gedanken an den möglichen Adressbereich begann mein Auge nervös zu zucken — Idee wurde als absurd abgetan.
2. Den Auslöseschwellenwert für udp flood policy erhöhen — auch nicht gerade ideal, was ist, wenn tatsächlich jemand bösartiges durchschlüpft.
3. Anfragen aus dem internen Netzwerk zu UDP nachzudenken findet man 443 außen sperren.
Nach weiteren Informationen zur Implementierung und Integration QUIC in Google Chrome wurde die letzte Variante als Handlungsanweisung akzeptiert. Es geht darum, dass, von allen geliebt und überall gnadenlos (ich verstehe nicht, warum, es wäre besser, die dreiste Rote Firefox-Schnauze bekommt für die verbrauchten Gigabyte RAM), Google Chrome anfangs versucht, eine Verbindung mit seinen mühsam erarbeiteten QUIC, herzustellen, aber wenn das Wunder nicht eintritt, kehrt er zu bewährten Methoden zurück wie TLS, auch wenn ihm das unglaublich peinlich ist.
Wir erstellen im Firewall eine Regel für den Dienst QUIC:
Wir konfigurieren eine neue Regel und platzieren sie irgendwo höher in der Kette.
Nach der Aktivierung der Regel im Anomalienverzeichnis ist Ruhe und Frieden, mit Ausnahme wirklich ernsthafter Übeltäter.
Vielen Dank für Ihre Aufmerksamkeit.
Verwendete Ressourcen:
1.
2.
3.
4.
Quelle: habr.com
