La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: ouno le 28 février 2023 à 17:58:35
-
Bonjour,
Par exemple:
17:33:03.312582 IP ec2-34-207-119-237.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 11, seq 2270, length 16
17:33:03.417069 IP ec2-3-234-141-109.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 11, seq 2270, length 16
17:33:03.443584 IP ec2-3-239-4-1.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 11, seq 2270, length 16
17:33:03.488548 IP ec2-3-82-247-166.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 11, seq 2270, length 16
17:33:03.493351 IP ec2-54-221-168-68.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 11, seq 2270, length 16
17:33:03.595839 IP ec2-54-81-157-67.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 9, seq 3940, length 16
17:33:03.651398 IP ec2-3-237-236-48.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 9, seq 3940, length 16
17:33:03.672096 IP ec2-35-171-47-153.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 9, seq 3940, length 16
17:33:03.679487 IP ec2-54-151-9-173.us-west-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 19, seq 691, length 16
17:33:03.696850 IP ec2-13-56-241-48.us-west-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 19, seq 691, length 16
17:33:03.699239 IP ec2-54-82-11-192.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 9, seq 3940, length 16
17:33:03.746862 IP ec2-44-201-240-231.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 9, seq 3940, length 16
17:33:03.977301 IP ec2-3-26-157-245.ap-southeast-2.compute.amazonaws.com > mon-serveur: ICMP echo request, id 29, seq 57, length 16
17:33:03.988343 IP ec2-3-26-5-177.ap-southeast-2.compute.amazonaws.com > mon-serveur: ICMP echo request, id 29, seq 57, length 16
17:33:04.007966 IP ec2-54-236-50-146.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 11, seq 2270, length 16
17:33:04.014918 IP ec2-35-74-235-241.ap-northeast-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 4395, length 16
17:33:04.065823 IP ec2-13-211-227-191.ap-southeast-2.compute.amazonaws.com > mon-serveur: ICMP echo request, id 29, seq 57, length 16
17:33:04.098285 IP ec2-18-183-127-193.ap-northeast-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 4395, length 16
17:33:04.211571 IP ec2-13-125-68-202.ap-northeast-2.compute.amazonaws.com > mon-serveur: ICMP echo request, id 15, seq 3637, length 16
17:33:04.238883 IP ec2-13-228-73-103.ap-southeast-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 5017, length 16
17:33:04.320556 IP ec2-54-179-203-114.ap-southeast-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 5017, length 16
17:33:04.362534 IP ec2-43-200-71-211.ap-northeast-2.compute.amazonaws.com > mon-serveur: ICMP echo request, id 15, seq 3637, length 16
17:33:04.389109 IP ec2-18-183-176-224.ap-northeast-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 4395, length 16
17:33:04.396005 IP ec2-13-229-150-252.ap-southeast-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 5017, length 16
17:33:04.403037 IP ec2-3-39-177-160.ap-northeast-2.compute.amazonaws.com > mon-serveur: ICMP echo request, id 15, seq 3637, length 16
17:33:04.450537 IP ec2-3-39-243-82.ap-northeast-2.compute.amazonaws.com > mon-serveur: ICMP echo request, id 15, seq 3637, length 16
17:33:04.453413 IP ec2-34-232-78-241.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 9, seq 3940, length 16
17:33:04.587422 IP ec2-52-65-136-84.ap-southeast-2.compute.amazonaws.com > mon-serveur: ICMP echo request, id 8, seq 4797, length 16
17:33:04.613563 IP ec2-35-183-234-85.ca-central-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 25, seq 5385, length 16
17:33:04.626392 IP ec2-15-222-27-182.ca-central-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 25, seq 5385, length 16
17:33:04.637324 IP ec2-54-252-223-103.ap-southeast-2.compute.amazonaws.com > mon-serveur: ICMP echo request, id 8, seq 4797, length 16
17:33:04.688949 IP ec2-13-239-176-29.ap-southeast-2.compute.amazonaws.com > mon-serveur: ICMP echo request, id 8, seq 4797, length 16
17:33:04.867704 IP ec2-99-79-192-218.ca-central-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 25, seq 5385, length 16
17:33:04.888995 IP ec2-43-218-18-176.ap-southeast-3.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 8965, length 16
17:33:04.890973 IP ec2-108-136-59-188.ap-southeast-3.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 8965, length 16
17:33:04.903636 IP ec2-43-218-8-132.ap-southeast-3.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 8965, length 16
17:33:05.052269 IP ec2-108-137-152-143.ap-southeast-3.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 8965, length 16
17:33:05.094616 IP ec2-54-176-149-247.us-west-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 17, seq 8352, length 16
17:33:05.150916 IP ec2-108-136-117-113.ap-southeast-3.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 8965, length 16
17:33:05.181893 IP ec2-108-137-172-137.ap-southeast-3.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 8965, length 16
17:33:05.364894 IP ec2-54-67-74-115.us-west-1.compute.amazonaws.com > mon-serveur: ICMP echo request, id 17, seq 8352, length 16
17:33:05.381584 IP ec2-35-181-26-138.eu-west-3.compute.amazonaws.com > mon-serveur: ICMP echo request, id 24, seq 12118, length 16
17:33:05.544014 IP ec2-35-180-21-188.eu-west-3.compute.amazonaws.com > mon-serveur: ICMP echo request, id 24, seq 12118, length 16
17:33:05.606984 IP ec2-100-26-244-74.compute-1.amazonaws.com > mon-serveur: ICMP echo request, id 10, seq 4453, length 16
17:33:05.672799 IP ec2-13-37-248-195.eu-west-3.compute.amazonaws.com > mon-serveur: ICMP echo request, id 24, seq 12118, length 16
17:33:05.964308 IP ec2-3-26-166-242.ap-southeast-2.compute.amazonaws.com > mon-serveur: ICMP echo request, id 2, seq 7539, length 16
Je m'en suis rendu compte par hasard en ajoutant des logs sur les dépassements de rate limit dans mes règles nft...
-
Tu héberges quel service sur la machine qui est pingué ?
-
La seule chose accessible publiquement est le SSH et du ICMP limité...
Après chez Orange les IPs sont dynamiques, donc j'ai peut-être récupéré l'IP de quelqu'un qui faisait des choses avec Amazon EC2...
-
Après vérification j'ai la même IP depuis le 11 janvier.
-
Petite idée en lisant le fil.
Etant donné le tir groupé des faibles longueurs de paquets depuis, mais en fait plus probablement vers, un seul et même hébergeur, regardez s'il ne s'agit pas d'une attaque smurf, tout bonnement.
-
regardez s'il ne s'agit pas d'une attaque smurf, tout bonnement.
Oui effectivement il y a de grandes chances que ce soit ça, mais je ne vois pas trop quoi regarder de plus à vrai dire.
Par contre je pense que je vais faire un petit script qui va apprendre progressivement via les logs toutes les plages Amazon EC2 ciblées et bloquer les ICMP request qui apparaissent provenir de là pour être tranquille.
Pour info j'en suis à 71 000 ping requests droppés depuis hier soir (en plus de ceux autorisés car sous le rate limit...)
-
Si tu as déjà un rate-limit, le seul dégât des requêtes c'est de pourrir tes logs.
Par contre je pense que je vais faire un petit script qui va apprendre progressivement via les logs toutes les plages Amazon EC2 ciblées et bloquer les ICMP request qui apparaissent provenir de là pour être tranquille.
Comme tu utilises nftables, tu peux regarder ici : https://www.mankier.com/8/nft#Statements-Set_Statement (https://www.mankier.com/8/nft#Statements-Set_Statement)
-
Si tu as déjà un rate-limit, le seul dégât des requêtes c'est de pourrir tes logs.
En fait ça ne pourrit pas mes logs car je ne log pas ce qui dépasse le rate limit justement, je le compte juste via nft (le log de mon premier post c'est juste une capture temporaire que j'ai faite pour comprendre ce qui générait autant d'echo request).
Par contre ce qui m'embête c'est que le rate limit d'echo request de mon serveur est constamment atteint à cause de ça, et donc il ne répond plus convenablement au ping dans les cas légitimes.
Comme tu utilises nftables, tu peux regarder ici : https://www.mankier.com/8/nft#Statements-Set_Statement (https://www.mankier.com/8/nft#Statements-Set_Statement)
Merci, oui je comptais bien utiliser des sets/maps dynamiques pour ça.
-
Oui effectivement il y a de grandes chances que ce soit ça, mais je ne vois pas trop quoi regarder de plus à vrai dire.
Ce que je voulais dire, c'était de vérifier si on vous atteint par adresse broadcast et, le cas échéant, les faire sauter par réglage de la pile IP, icmp_echo_ignore_broadcasts via sysctl ou proc.
Indépendamment vous devriez aussi pouvoir filtrer sur la longueur de paquet, du genre dans la syntaxe historique "-p icmp -m length --length xx" dès le premier paquet ou en le combinant à une logique plus raffinée.
-
J'ai du mal à voir le problème de se faire ping en continu, c'est le bruit de fond d'internet, ça ne changera pas grand chose à la face du monde :)
-
Ce que je voulais dire, c'était de vérifier si on vous atteint par adresse broadcast et, le cas échéant, les faire sauter par réglage de la pile IP, icmp_echo_ignore_broadcasts via sysctl ou proc.
Vous voulez dire via des broadcast provenant du LAN ? Non c'est sûr que cela ne provient pas du LAN, c'est vraiment des requêtes qui arrivent de l'extérieur...
Indépendamment vous devriez aussi pouvoir filtrer sur la longueur de paquet, du genre dans la syntaxe historique "-p icmp -m length --length xx" dès le premier paquet ou en le combinant à une logique plus raffinée.
Ah bien vu, je n'avais même pas pensé à filtrer via taille de paquet, qui ne semble pas bouger pour l'instant.
Après un ajout dans la ruleset de:
ip protocol icmp icmp type echo-request meta length 36 counter dropc'est déjà beaucoup mieux. J'espère juste que les echo requests de taille 20+16 ne sont pas trop courants dans un usage normal... ???
-
J'ai du mal à voir le problème de se faire ping en continu, c'est le bruit de fond d'internet, ça ne changera pas grand chose à la face du monde :)
Ah mais aucun problème bien au contraire, c'est bien pour cela que j'autorise le ping sur mon serveur !
Par contre je ne souhaite pas:
1) que mon serveur participe à une attaque de type smurf en répondant massivement à des requêtes spoofées, ce qui semble être le cas ici comme l'a justement fait remarquer pitalugue
2) que mon serveur ne réponde plus aux pings légitimes à cause d'un rate limit saturé lié à cette attaque
Mais tant que le spoofing sera possible sur Internet je ne pense pas qu'il y aura de solution satisfaisante à ça, il faut faire des compromis...
-
On peut quand même douter que l'infra AWS (idem pour Orange) soit génératrice d'attaques via broadcast non ?
-
C'est dans l'autre sens que ça marche. Si vous pouvez placer un directed broadcast ou un multicast au travers d'une infrastructure vous amplifiez non pas la taille du paquet mais le nombre de ces paquets et AWS se prend une vague d'echo reply.
Autre option pour AWS précisément est que s'ils filtrent les echo req, au moins pour partie de leurs services, une réflexion en echo rep via une population quasi aléatoire permet quand même d'atteindre certaines de leurs machines hébergées. En ce cas, pas d'amplification en soi mais juste concentration sur des cibles particulières. Et les armes pour contre-carrer sont moindres, typiquement un pseudo état (improbable avant d'atteindre la cible), un motif/pattern sur le paquet et/ou sa taille.
-
Quant à Orange si toutefois ils doivent éliminer un paquet directed broadcast sur leur routage sauf erreur ou besoin très particulier, ils ne peuvent pas forcément prévenir toute attaque en rebond ou issue de leurs réseaux.
Ils font sans doute pas mal de choses. Certaines pas toujours bien comprises comme le filtrage smtp.
Edit: clarification.