Adresse IP bogon : définition et enjeux
Une adresse IP bogon est une adresse issue d’un espace privé, réservé ou non alloué qui ne devrait jamais apparaître comme source de trafic sur l’Internet public. Le nom vient de « bogus » (faux), et les plages concernées sont fixées par l’IANA et un ensemble de RFC ; vérifier si une adresse est un bogon revient donc à une recherche dans une liste publiée et normalisée, et non à une supposition.
Les principales plages bogon
Il y a deux groupes à distinguer. Les plages réservées à usage spécial sont définies par des normes et ne seront jamais routées publiquement. L’espace non alloué, parfois appelé « full bogons », est de l’espace d’adressage qu’aucun registre n’a encore attribué. Les plages réservées ci-dessous sont celles que vous rencontrerez le plus souvent.
0.0.0.0/8: « ce réseau » ; apparaît comme source lorsqu’un hôte n’a pas encore d’adresse.10.0.0.0/8,172.16.0.0/12,192.168.0.0/16: réseaux privés de la RFC 1918.100.64.0.0/10: espace d’adressage partagé pour le NAT de niveau opérateur (RFC 6598).127.0.0.0/8: bouclage.169.254.0.0/16: lien local, attribuée automatiquement lorsque DHCP échoue.192.0.0.0/24: affectations de protocoles de l’IETF.192.0.2.0/24,198.51.100.0/24,203.0.113.0/24: blocs de documentation (RFC 5737) que vous verrez dans les exemples et les tutoriels.198.18.0.0/15: tests de performance des réseaux (RFC 2544).224.0.0.0/4: multidiffusion.240.0.0.0/4: réservé à un usage futur, plus255.255.255.255, l’adresse de diffusion limitée.
Pour l’IPv6, les équivalents comprennent ::/128 (non spécifiée), ::1/128 (bouclage), fc00::/7 (adresses locales uniques), fe80::/10 (lien local), ff00::/8 (multidiffusion) et 2001:db8::/32 (documentation). Les adresses IPv4 mappées, comme ::ffff:0:0/96, et le préfixe NAT64 64:ff9b::/96 méritent aussi l’attention, car ce sont des mécanismes de traduction qui ne devraient pas non plus apparaître comme adresses clientes. Certains anciens articles listent aussi 192.88.99.0/24 (anycast des relais 6to4), qui a été déprécié.
Pourquoi un bogon dans vos journaux est important
Si un bogon apparaît comme client apparent d’une requête venue de l’Internet public, l’une de quelques explications est vraie, et ce n’est pas toujours malveillant. Souvent la cause est la tuyauterie : un proxy inverse ou un répartiteur de charge ne transmet pas la véritable adresse du client, et votre application voit donc l’adresse privée du proxy ; une entrée X-Forwarded-For a été prise à la mauvaise position ; ou une configuration NAT a laissé fuiter une adresse interne dans un champ public. Ce sont des bugs de configuration qui valent la peine d’être corrigés, car ils cassent la limitation de débit, la géolocalisation et le signalement des abus.
L’autre cause est délibérée. Les adresses sources peuvent être falsifiées dans les paquets et dans les en-têtes, et les attaquants utilisent des sources bogon pour des inondations usurpées ou pour sonder le filtrage. Le trafic légitime ne pouvant pas provenir de ces plages, les opérateurs en amont les filtrent à la périphérie du réseau (l’idée du filtrage en entrée du BCP 38), et votre propre pare-feu devrait rejeter les sources bogon arrivant sur des interfaces publiques. Notez la nuance : à l’intérieur de votre réseau, les adresses privées sont normales ; n’appliquez donc la règle qu’à la frontière publique.
Espace réservé ou non alloué
La distinction compte lorsque vous construisez votre propre filtre. Les plages réservées sont fixées par des normes et changent rarement ; une table statique de celles-ci reste donc correcte pendant des années. L’espace non alloué est différent, car les registres attribuent des blocs au fil du temps et une adresse qui était un bogon l’an dernier peut appartenir aujourd’hui à un vrai réseau. Les filtres qui codent en dur des blocs non alloués ont historiquement bloqué de nouveaux clients de plages nouvellement attribuées, ce qui explique pourquoi la liste des plages réservées est la plus sûre à intégrer dans le code applicatif, et pourquoi les questions de propriété sur les adresses publiques relèvent des données de registre plutôt que d’une liste de bogons.
Vérifier une adresse
Vous pouvez tester n’importe quelle adresse dans le vérificateur de bogons IP, qui la compare aux plages réservées IPv4 et IPv6 publiées et montre le bloc correspondant avec un tableau de référence. Dans l’API, la réponse de la recherche d’IP inclut bogon et bogon_type, de sorte qu’un pipeline de journaux peut signaler ces adresses sans table de plages personnalisée. La documentation de l’API liste la réponse complète.
Une limite mérite d’être connue. Le vérificateur utilise une liste réservée fondée sur les normes, et non une vue en direct de ce qui est routé. Une adresse hors des plages réservées n’est pas garantie d’être allouée ni joignable. Pour savoir si une adresse publique a réellement un propriétaire, utilisez la recherche WHOIS d’IP pour l’enregistrement du registre, ou la recherche d’ASN pour voir le réseau qui l’annonce.
Gestion pratique
- Normalisez et validez les adresses tôt ; rejetez les bogons dans les champs qui attendent une IP cliente publique.
- Rejetez les sources bogon à votre périphérie publique avec des règles de pare-feu, mais ne les appliquez pas au trafic interne.
- Lorsqu’un bogon apparaît de façon inattendue, vérifiez d’abord la configuration du proxy et du répartiteur de charge, car la mauvaise configuration est plus courante que l’attaque.
- Rappelez-vous que les adresses bogon n’ont aucune géolocalisation ; ignorez donc les recherches de géolocalisation et de réputation pour elles et économisez la requête.