Op een prachtige lentedag, toen ik niet naar huis wilde gaan, en de onstuitbare honger naar leven en ontdekken me meesleurde als een gloeiend ijzer, ontstond het idee om te gaan knoeien met een aantrekkelijke functie op de firewall genaamd “IP DOS-beleid«.
Na wat voorbereidend werk en het doornemen van de handleiding, heb ik het ingesteld in de modus Pass-and-Log, om te kijken wat de uitkomst en de twijfelachtige nuttigheid van deze instelling zijn.
Na een paar dagen (zodat de statistieken zich konden opbouwen, natuurlijk, en niet omdat ik het was vergeten) keek ik in de logs en klapte in mijn handen van blijdschap - er waren heel wat records verzameld. Het zou toch eenvoudig lijken - zet het beleid in de blokkade-modus voor alle spammers, scanners, en diegenen die half-open sessies met een ban van een uur hebben en slaap rustig met de wetenschap dat de grens gesloten is. Maar het 34ste levensjaar had de jongelingsidealismus overwonnen en ergens in de achterkant van mijn hoofd klonk een klein stemmetje: 'Waarom kijken we niet eens wie onze geliefde firewall als ongewenste spammers heeft herkend? Gewoon, ter wille van de gekheid.'
We beginnen de verkregen gegevens te analyseren met de lijst van anomalieën. Ik voer de adressen door een simpel script Powershell en mijn ogen stoten op vertrouwde letters google.
Ik wrijf in mijn ogen, knipper vijf minuten om me ervan te verzekeren dat ik me niet vergis - inderdaad, op de lijst van degenen die de firewall als flagrante spammer beschouwde, type aanval - udp flood, adressen die toebehoren aan de goede onderneming.
Ik krabbel op mijn hoofd terwijl ik tegelijk de pakketcaptatie op de externe interface configureer voor verdere analyse. Er schieten kleurrijke gedachten door mijn hoofd: 'Hoe kan het dat er iets geïnfecteerd is in het bereik van Google? En ik heb dat ontdekt? Dat zou - onderscheidingen, eer en een rode loper, en mijn eigen casino met blackjack en, nou ja, je snapt…'
Ik analyseer het verkregen bestand Wireshark-.
Ja, het komt inderdaad van een adres in het bereik van Google er worden UDP-pakketten gestuurd vanaf poort 443 naar een willekeurige poort op mijn apparaat.
Maar wacht… het protocol verandert van UDP en een werkende opdracht krijgen. GQUIC.
Semyon Semyonovich…
Ik herinner me onmiddellijk een presentatie van HighLoad Alexander Toboly «UDP tegen TCP of de toekomst van de netwerkstack"().
Aan de ene kant is er een lichte teleurstelling - geen lauweren, geen eer voor jou, baron. Aan de andere kant is het probleem duidelijk, het blijft alleen om te begrijpen waar en hoeveel we moeten graven.
En paar minuten praten met de Corporatie van Goedheid — en alles valt op zijn plaats. In een poging om de snelheid van contentlevering te verbeteren, heeft het bedrijf Google al in 2012 het protocol QUIC, aangekondigd, waarmee de meeste tekortkomingen van TCP kunnen worden weggenomen (ja-ja-ja, in deze artikelen — en er wordt gesproken over een volstrekt revolutionaire aanpak, maar laten we eerlijk zijn, we willen gewoon dat schattige kattenfoto's sneller laden en niet al jullie revolutionaire ideeën over bewustzijn en vooruitgang). Zoals verder onderzoek heeft aangetoond, stappen veel organisaties nu over op een dergelijke manier van contentlevering.
Het probleem in mijn geval, en ik denk dat ik niet de enige ben, was dat er uiteindelijk veel te veel pakketten gaan en de firewall deze als een aanval beschouwt.
Er bleken maar weinig oplossingen te zijn:
1. Voeg toe aan de uitsluitingenlijst voor DoS-beleid in de firewall met het bereik van adressen Google. Bij alleen de gedachte aan het bereik van mogelijke adressen begon mijn oog nerveus te knipperen — het idee is als onzin afgewezen.
2. Verhoog de triggerdrempel voor udp flood policy — ook niet ideaal, wat als er iemand echt kwaadaardig doorheen glipt.
3. Verbied verzoeken vanuit het interne netwerk naar UDP en een werkende opdracht krijgen. 443 de poort naar buiten.
Na verder te hebben gelezen over de implementatie en integratie, werd de laatste optie als een aanwijzing tot actie aangenomen. Het feit is dat, algemeen geliefd en onverbiddelijk (ik begrijp niet waarom, het zou beter zijn als die brutale rode QUIC in Google Chrome -achtige snuit een afronding krijgt voor de geconsumeerde gigabytes RAM), Firefoxeerder probeert verbinding te maken met behulp van zijn doorleefde Google Chrome , maar als dat niet werkt, keert hij terug naar de beproefde methodes zoals QUIC, hoewel hij zich daar ontzettend voor schaamt. TLSWe maken een regel aan in de firewall voor de service
We configureren een nieuwe regel en plaatsen deze ergens verderop in de keten. QUIC:
Na het inschakelen van de regel in de anomalielijst is er rust en kalmte, op echte aanhoudende overtreders na.
Bedankt allemaal voor jullie aandacht.
Gebruikte middelen:
Het rapport van Alexander Tobjol
1.
2.
3.
4.
Bron: habr.com
