Bonjour tout le monde,
J'utilise un serveur SYS-1-SAT-32 qui a été avant-hier soir la cible d'une plainte du service abuse d'OVH en ces termes :
> Your server nsXXXXXXX.ip-xxx-xxx-xxx.eu is using too much IPv6 addresses for a normal use. We observed more than 145000 IPv6 being used which we cleared on the infra side.
Avec la mention suivante à la fin :
> Veuillez procéder immédiatement à la correction. Une nouvelle vérification sera effectuée sous 24 heures. Si le problème persiste et sans aucun retour de votre part votre offre sera suspendu.
Je ne suis pas une grosse brute en sécurité, mais je me défends tout de même bien en Linux, firewall et réseau. Après inspection sur ma machine, rien de suspect et ma table neighbor IPv6 (arp) n'est pas surchargée, loins de là. Je n'ai aucun accès SSH par mot de passe par exemple. Ce ticket m'a été envoyé à 21h passé, donc impossible de contacter le support et d'en savoir plus. J'ai donc désactivé l'IPv6 sur mon interface principale le temps d'en savoir plus.
Le lendemain, après un échange, je tiens à le souligner au passage, très efficace avec au moins deux personnes du service de support So-You-Start, par téléphone (réponse quasi immédiate) et par écrit, voici une première analyse personnelle :
OVH a constaté sur leur équipement(s) réseau(x) une liste d'association avec la MAC de mon serveur avec plusieurs centaines d'IPv6 sur mon préfixe en partant de ::0 à :::xxxx:yyyy (je n'ai pas plus de détails sur la fin). La liste d'IPv6 est contiguë partant de 0 (1, 2, 3, …) et sur cet élément, il considère que mon serveur utilise trop d'IPv6 alors que de mon côté, j'ai au qu'une petite poignée de déclarée.
Me première réaction, c'est que ça ressemble beaucoup à un scan d'un bot qui chercherait à savoir la liste des IPv6 que j'utilise sur mon préfixe `/64`.
Jusque-là, test à l'appui (je mettrai les détails dans un autre post pour ne pas surcharger celui-ci), mon serveur qui agit en routeur (proxy NDP IPv4 et IPv6 pour mes VMs) renvoie une réponse `icmpv6` de type `destination-unreachable` avec ma MAC au routeur en amont si une IP de mon préfixe n'existe pas. Je suppose que la réponse de mon serveur engendre tout de même une entrée dans leur table, ce qui a déclenché cette alerte.
Si mon analyse est bonne, il y a quand même un gros souci d'interprétation du côté du service abuse… En tout cas, avant d'envoyer ce genre d'alerte, ils devraient au moins s'assurer que ça vient bien de mon serveur et que ce n'est pas un faux positif, ce qui n'est pas du tout reflété dans le ton employé dans le message du mail.
En attendant plus de détails de leur côté, j'ai rajouté deux règles IPTables (IPv4 et IPv6) pour dropper les paquets de type `destination-unreachable` en sortie sur mon interface réseau principale.
Voilà ! J'espère que ça en aidera d'autres qui tomberaient dans cette situation. Suite au prochain épisode…
Emeric
Voici les détails techniques :
Test effectué avant et après ma modification de règle firewall :
je test une connexion sur une ip (2001:41d0:xxxx:xxxx::99)dans mon préfix mais qui n'existe pas, depuis chez moi.
Dans le premier cas mon serveur envoie un "Destination Unreachable"
Dans le deuxième cas, il fait le mort
### Avant l'ajout de la règle DROP
#### côté client (commande telnet):
$ telnet 2001:41d0:xxxx:xxxx::99
Trying 2001:41d0:xxxx:xxxx::99…
telnet: Unable to connect to remote host: No route to host
#### côté serveur (capture réseau) :
8 2024-04-24 14:13:39,266238 2a02:8429:b2f8:xxxx::20 2001:41d0:xxxx:xxxx::99 TCP 94 46790 → 23 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM=1 TSval=3091432958 TSecr=0 WS=128
11 2024-04-24 14:13:40,293155 2a02:8429:b2f8:xxxx::20 2001:41d0:xxxx:xxxx::99 TCP 94 [TCP Retransmission] [TCP Port numbers reused] 46790 → 23 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM=1 TSval=3091433985 TSecr=0 WS=128
18 2024-04-24 14:13:42,309080 2a02:8429:b2f8:xxxx::20 2001:41d0:xxxx:xxxx::99 TCP 94 [TCP Retransmission] [TCP Port numbers reused] 46790 → 23 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM=1 TSval=3091436001 TSecr=0 WS=128
21 2024-04-24 14:13:42,312934 2001:41d0:xxxx:xxxx:: 2a02:8429:b2f8:xxxx::20 ICMPv6 142 Destination Unreachable (Address unreachable)
22 2024-04-24 14:13:42,312940 2001:41d0:xxxx:xxxx:: 2a02:8429:b2f8:xxxx::20 ICMPv6 142 Destination Unreachable (Address unreachable)
23 2024-04-24 14:13:42,312943 2001:41d0:xxxx:xxxx:: 2a02:8429:b2f8:xxxx::20 ICMPv6 142 Destination Unreachable (Address unreachable)
### Après l'ajout de la règle DROP
iptables -t filter -I OUTPUT -o eth0 -p icmp --icmp-type destination-unreachable -j DROP
ip6tables -t filter -I OUTPUT -o eth0 -p icmpv6 --icmpv6-type destination-unreachable -j DROP
#### côté client (commande telnet):
$ telnet 2001:41d0:xxxx:xxxx::99
Trying 2001:41d0:xxxx:xxxx::99…
#### côté serveur (capture réseau) :
5 2024-04-24 14:14:37,322245 2a02:8429:b2f8:xxxx::20 2001:41d0:xxxx:xxxx::99 TCP 94 37604 → 23 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM=1 TSval=3091491013 TSecr=0 WS=128
13 2024-04-24 14:14:38,341095 2a02:8429:b2f8:xxxx::20 2001:41d0:xxxx:xxxx::99 TCP 94 [TCP Retransmission] [TCP Port numbers reused] 37604 → 23 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM=1 TSval=3091492033 TSecr=0 WS=128
18 2024-04-24 14:14:40,361094 2a02:8429:b2f8:xxxx::20 2001:41d0:xxxx:xxxx::99 TCP 94 [TCP Retransmission] [TCP Port numbers reused] 37604 → 23 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM=1 TSval=3091494053 TSecr=0 WS=128
155 2024-04-24 14:14:44,421156 2a02:8429:b2f8:xxxx::20 2001:41d0:xxxx:xxxx::99 TCP 94 [TCP Retransmission] [TCP Port numbers reused] 37604 → 23 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM=1 TSval=3091498113 TSecr=0 WS=128
Bonjour à tous,
Je viens à l'instant d'avoir la confirmation du support concernant mon analyse.
J'ai eu quand même une bonne frayeur au passage, mais me voilà rassuré 
Encore merci aux quelques personnes de l'équipe support So-You-Start qui ont servi d'intermédiaires, qui ont assuré un bon suivi qui ont été très efficaces pour avoir les réponses auprès du service abuse.
Emeric
Bonjour @EmericV1,
Je vous remercie d'avoir partagé la solution avec la communauté 
Passez une bonne semaine,
^FabL