Un merveilleux soir de printemps, alors que l'envie de rentrer à la maison n'était guère présente, et que le désir insatiable de vivre et de découvrir me brûlait comme du fer rouge, l'idée de trifouiller une fonctionnalité intrigante sur le pare-feu appelée «politique IP DOS«.
Après quelques préliminaires et une prise en main du manuel, j'ai configuré en mode Pass-and-Log, pour voir ce que donnait réellement cette configuration et son utilité discutable.
Quelques jours plus tard (pour laisser le temps à la statistique de s'accumuler, bien sûr, et non pas parce que j'ai oublié), j'ai regardé les logs et, sautillant sur place, j'ai applaudi — j'avais amassé tellement d'entrées qu'il était difficile d'y croire. On pourrait penser qu'il n'y a rien de plus simple — activez la politique en mode blocage de toutes les adresses floodant, scannant, établissant des sessions half-open avec un ban d'une heure et dormez tranquillement avec la conscience tranquille que la frontière est verrouillée. Mais l'année de mes 34 ans a fait place au maximalisme juvénile, et quelque part à l'arrière de mon esprit, une petite voix a tinter : «Et si on soulevait les paupières et voyait quelles adresses notre cher pare-feu a identifiées comme malveillantes? Juste pour le fun.»
Nous commençons à analyser les données recueillies à partir des anomalies. Je fais passer les adresses par un petit script Powershell et mes yeux tombent sur des lettres familières google.
Je frotte mes yeux, clignant des yeux pendant cinq minutes pour m'assurer que je ne rêve pas — effectivement, dans la liste de celles que le pare-feu a désignées comme des flooders, le type d'attaque est inondation UDP, des adresses appartenant à la corporation du bien.
Je me gratte la tête, tandis que je règle la capture de paquets sur l'interface externe pour une analyse future. Dans ma tête, des pensées colorées affluent : «Comment est-il possible que quelque chose d'infecté soit sous le domaine de Google ? Et c'est moi qui l'ai découvert ? Mais c'est, c'est — des récompenses, des honneurs, un tapis rouge, et mon propre casino avec du blackjack et, eh bien, vous avez compris…»
J'analyse le fichier obtenu Wireshark-th.
Oui, effectivement, des paquets UDP affluent depuis une adresse sous le domaine Google sur le port 443 vers un port aléatoire sur mon appareil.
Mais, attendez… Voici le protocole qui change de UDP sur GQUIC.
Semyon Semyonovich…
Je me rappelle immédiatement d'une présentation faite lors de HighLoad par Alexandre Tobol «UDP contre TCP ou l'avenir de la pile réseau) ().
D'une part, il y a un léger désenchantement — pas de lauriers, ni d'honneurs, pour vous, cher ami. D'autre part, le problème est clair, il ne reste plus qu'à comprendre où et combien il faut creuser.
Quelques minutes de discussion avec la Corporation du Bien et tout devient clair. Dans le but d'améliorer la vitesse de livraison de contenu, l'entreprise Google avait déjà annoncé en 2012 le protocole QUIC, permettant de supprimer une grande partie des inconvénients de TCP (oui, oui, dans ces articles - et on parle d'une approche complètement révolutionnaire, mais, soyons francs, on aimerait que les photos de chat soient chargées plus rapidement, et non toutes ces révolutions de la conscience et du progrès). Comme l'a montré des recherches ultérieures, de nombreuses organisations passent actuellement à un tel mode de livraison de contenu.
Le problème dans mon cas, et je pense que ce n'est pas juste moi, est que le nombre de paquets qui circulent est vraiment trop élevé et le pare-feu les perçoit comme du spam.
Les solutions se sont avérées peu nombreuses :
1. Ajouter à la liste des exceptions pour DoS Policy sur le pare-feu un champ d'adresses Google. Rien qu'à penser à la plage d'adresses possibles, mon œil a commencé à trembler nerveusement - l'idée a été mise de côté comme étant folle.
2. Augmenter le seuil d'activation pour udp flood policy – ce n'est pas mieux, et si quelqu'un de vraiment malveillant réussit à passer ?
3. Interdire les accès depuis le réseau interne vers UDP sur 443 le port externe.
Après avoir lu davantage sur la mise en œuvre et l'intégration, QUIC dans Google Chrome le dernier option a été accepté comme directive. En effet, le bien-aimé de tous, reconnu et impitoyable (je ne comprends pas pourquoi, il vaut mieux qu'une vilaine tête rousse Firefox-a reçu pour les gigaoctets de RAM consommés), Google Chrome tente initialement d'établir une connexion en utilisant son propre QUIC, mais si le miracle n'a pas lieu, il revient à des méthodes éprouvées, même s'il en a honte. TLSNous créons une entrée sur le pare-feu pour le service
Nous configurons une nouvelle règle et la plaçons un peu plus haut dans la chaîne. QUIC:
Après l'activation de la règle, dans la liste des anomalies, c'est le calme, à part quelques contrevenants vraiment malveillants.
Merci à tous pour votre attention.
Ressources utilisées :
Rapport d'Alexandre Tobal
1.
2.
3.
4.
Source : habr.com
