Comment bloquer l'accès à son site web pour certains FAI ?
- Comment bloquer l'accès à son sites web pour certains FAI ?
- Comprendre «FAI» côté technique : IP, ASN et DNS
- Les cas où ça vaut vraiment le coup (et ceux à éviter)
- Les méthodes fiables pour bloquer un FAI
- Choisir la bonne approche : tableau comparatif
- Où trouver l'ASN et les plages IP d'un FAI (sans y passer la nuit)
- Quels codes HTTP renvoyer et quelle page afficher ?
- Effets secondaires : SEO, analytics et expérience utilisateur
- Bonnes pratiques pour éviter de se tirer une balle dans le pied
-
FAQ
- Peut-on bloquer un FAI sans bloquer ses clients mobiles ?
- Comment savoir si une IP appartient vraiment à un FAI donné ?
- Est-ce légal de bloquer un FAI ?
- Un VPN contourne-t-il le blocage ?
- Quel est le meilleur endroit pour bloquer : WAF, serveur ou firewall ?
- Que faire si je bloque des visiteurs légitimes par erreur ?
- Comment maintenir une liste de plages IP sans y passer des heures ?
Bloquer l'accès à un site pour certains fournisseurs d'accès à Internet (FAI), ça peut sembler radical. Pourtant, dans la vraie vie de webmaster, la demande revient souvent : trafic frauduleux concentré sur un opérateur, scrapers qui tournent depuis un ASN précis, pression juridique locale, ou simple besoin de limiter l'accès à un espace à des zones opérées par des réseaux particuliers.
Avant de toucher à la configuration, posez-vous une question simple : voulez-vous bloquer un FAI (au sens «réseau/opérateur»), une zone géographique, ou une source technique identifiable (IP, ASN, proxy, datacenter) ? La méthode, l'efficacité et les effets de bord ne seront pas les mêmes.
Comment bloquer l'accès à son sites web pour certains FAI ?
Dans les faits, on ne «bloque» pas un FAI en cliquant sur un bouton. On bloque ce qui le représente sur Internet : des plages IP, un ASN (numéro de système autonome), ou des routes réseau. Et comme ces éléments bougent, la meilleure approche combine une règle technique solide et un minimum de suivi.
Gardez aussi en tête un point un peu frustrant : un utilisateur peut contourner via VPN, 4G/5G, Wi-Fi public... Bref, un blocage FAI est un filtre, pas une garantie absolue.
Comprendre «FAI» côté technique : IP, ASN et DNS
Quand un visiteur arrive sur votre serveur, vous voyez une adresse IP. Cette IP appartient à une plage gérée par un opérateur, rattachée à un ASN. Un même FAI peut avoir plusieurs ASN, et des filiales aussi. Ce détail compte, sinon vous bloquez «à moitié» et vous vous demandez pourquoi ça fuit.
Le DNS n'est pas un bon levier pour bloquer un FAI. Beaucoup d'internautes utilisent des résolveurs publics. Mieux vaut viser la couche réseau (IP/ASN) ou applicative (WAF).
Astuce pratique : si votre but est de réduire du spam, un blocage IP/ASN aide, mais une règle anti-bots côté WAF peut faire encore plus mal... aux bots.
Les cas où ça vaut vraiment le coup (et ceux à éviter)
On voit souvent trois bons cas d'usage : 1) attaques DDoS ou flood concentré sur quelques réseaux, 2) scraping agressif depuis un opérateur précis, 3) contraintes contractuelles (accès réservé, distribution, droits). Dans ces situations, agir vite est parfois vital.
À l'inverse, bloquer un FAI «par principe» est rarement une bonne idée. Vous risquez de couper des clients légitimes, de déclencher des plaintes, ou de fausser vos mesures marketing (campagnes qui «ne marchent plus» sans raison claire).
Les méthodes fiables pour bloquer un FAI
1) Bloquer par ASN via un WAF ou un reverse proxy
La méthode la plus propre consiste à utiliser un WAF ou un reverse proxy qui sait filtrer par ASN. Avantage : c'est lisible, centralisé, et vous pouvez renvoyer une page dédiée (403, 451, ou même une page d'info polie).
Dans beaucoup d'interfaces, vous créez une règle du type : «si ASN = X, alors bloquer». C'est simple, et ça évite de maintenir des centaines de CIDR à la main. Bonus : vous pouvez combiner avec un challenge (CAPTCHA) au lieu d'un blocage sec, ce qui est plus doux si vous hésitez. [ En savoir plus ici ]
2) Bloquer par plages IP (CIDR) au niveau serveur
Si vous administrez votre infra, vous pouvez bloquer des plages IP directement. On parle de CIDR (ex. 203.0.113.0/24). Ça marche, c'est rapide, et c'est compatible partout.
Deux points à surveiller : les plages changent (fusions, réallocations), et vous pouvez facilement oublier une règle ancienne. Pour limiter les dégâts, gardez une liste versionnée (Git) avec un commentaire : «pourquoi on bloque» et «depuis quand». Oui, ça sauve des week-ends.
3) Filtrer au firewall (réseau) pour couper avant le serveur web
Pour les gros volumes, un filtrage au firewall est redoutable. Le trafic ne touche même pas le service HTTP. C'est utile en cas de pics, ou quand vous payez cher la bande passante.
Attention tout de même : si vous bloquez trop large, vous ne verrez plus rien dans les logs applicatifs. Pour diagnostiquer, gardez un minimum de traces côté firewall, sinon vous allez «chercher dans le noir».
4) Bloquer au niveau applicatif (moins recommandé)
Vous pouvez bloquer via votre CMS ou votre code (par exemple en comparant l'IP à une liste). Ça dépanne, mais c'est souvent le pire endroit : la requête a déjà consommé des ressources. À réserver à des cas précis, ou quand vous n'avez vraiment pas la main ailleurs.
Choisir la bonne approche : tableau comparatif
| Approche | Ce que vous bloquez | Points forts | Limites |
|---|---|---|---|
| WAF / Reverse proxy | ASN, pays, IP, bots | Gestion centralisée, règles souples, page de blocage | Dépend d'un service, configuration à maîtriser |
| Serveur web (IP/CIDR) | Plages IP | Simple, direct, peu coûteux | Maintenance des listes, risques d'oubli |
| Firewall (réseau) | IP/CIDR avant HTTP | Coupe le trafic tôt, efficace contre le volume | Moins de visibilité applicative, erreurs plus «dures» |
| Applicatif (CMS/code) | IP/headers | Possible sans accès serveur | Arrive trop tard, contournable, charge inutile |
Où trouver l'ASN et les plages IP d'un FAI (sans y passer la nuit)
Pour identifier l'opérateur à partir d'IPs vues dans vos logs, un whois/RDAP suffit souvent. Beaucoup d'outils affichent aussi l'ASN. Ensuite, pour récupérer des plages, vous pouvez vous appuyer sur des sources BGP/IRR, ou des bases publiques qui sortent les préfixes annoncés par l'ASN.
Pratique : partez de vos logs, listez 30 à 100 IP «problème», regroupez par ASN, puis décidez. Ça évite de bloquer au hasard. Et si vous avez un doute, testez en «challenge» avant de bloquer.
Quels codes HTTP renvoyer et quelle page afficher ?
Pour un blocage franc, 403 fait le job. Si vous agissez pour des raisons légales (restrictions, droits), 451 est cohérent. Vous pouvez aussi renvoyer une page courte, claire, sans agressivité : «Accès non disponible depuis votre réseau. Contact support@...».
Évitez les pages trop bavardes. Moins vous donnez d'indices, moins vous aidez un attaquant à ajuster sa stratégie. Un petit texte, un identifiant de requête, et c'est tout.
Effets secondaires : SEO, analytics et expérience utilisateur
Si vous bloquez un FAI, vous bloquez aussi des humains. Et parfois des robots légitimes (monitoring, partenaires, outils). Côté SEO, le risque majeur est de toucher des crawlers utiles si vos règles sont trop larges, ou de rendre des pages inaccessibles depuis certaines zones, ce qui peut brouiller vos signaux.
Un bon compromis consiste à bloquer uniquement des chemins sensibles (ex. /wp-login.php, /xmlrpc.php, /api/) plutôt que tout le site. Autre option : limiter le débit ou exiger un challenge sur des pages ciblées. C'est moins brutal, et souvent suffisant.
Bonnes pratiques pour éviter de se tirer une balle dans le pied
Documentez chaque règle : «qui a demandé», «quel symptôme», «quelle portée». Gardez une date interne si vous voulez, mais ne laissez pas des blocages «fantômes». Ensuite, mettez en place un test simple : une page de contrôle, et un monitoring externe depuis un réseau non bloqué pour vérifier que tout va bien.
Si vous travaillez en équipe, faites valider les changements à deux. Une seule ligne trop large dans un firewall, et vous coupez un gros pourcentage d'audience (ça arrive, même aux prudents). Et quand vous hésitez, commencez par un mode challenge plutôt qu'un refus net.
FAQ
Voici les questions qui reviennent le plus souvent quand on veut filtrer l'accès par opérateur, sans transformer son site en forteresse impraticable.
Peut-on bloquer un FAI sans bloquer ses clients mobiles ?
Pas toujours. Les réseaux fixe et mobile n'utilisent pas forcément les mêmes ASN ni les mêmes plages. Il faut identifier précisément d'où viennent vos visiteurs (logs) et cibler le bon ensemble.
Comment savoir si une IP appartient vraiment à un FAI donné ?
Un lookup RDAP/WHOIS et la correspondance ASN donnent une réponse fiable. Croisez avec vos logs : si 80% des requêtes indésirables viennent du même ASN, vous tenez une piste solide.
Est-ce légal de bloquer un FAI ?
En général, vous avez le droit de refuser l'accès à votre service, tant que vous respectez vos obligations (contrats, non-discrimination encadrée, information claire). En cas de doute, un avis juridique reste préférable, surtout si vous servez un public réglementé.
Un VPN contourne-t-il le blocage ?
Oui, souvent. Un utilisateur qui sort sur un autre réseau échappera au filtrage. C'est pour ça qu'un blocage FAI sert surtout à réduire un flux, pas à verrouiller un accès sensible.
Quel est le meilleur endroit pour bloquer : WAF, serveur ou firewall ?
Si vous pouvez, commencez par un WAF : plus souple, plus facile à ajuster. Pour des volumes élevés, le firewall est plus efficace. Le serveur web reste une bonne option quand vous voulez quelque chose de simple et maîtrisé.
Que faire si je bloque des visiteurs légitimes par erreur ?
Préparez un canal de contact sur la page de blocage, et gardez une règle d'exception (allowlist) pour des IP précises. Le combo «blocage + exceptions» évite de tout remettre en cause à la première réclamation.
Comment maintenir une liste de plages IP sans y passer des heures ?
Automatisez : générez une liste depuis les préfixes BGP d'un ASN, versionnez-la, et rechargez vos règles à intervalle raisonnable. Et surtout, supprimez les entrées qui ne servent plus, sinon votre filtre devient un musée.
Dernier conseil très concret : avant de bloquer «tout un opérateur», commencez par une règle plus fine sur les URLs qui attirent les abus (login, recherche interne, endpoints d'API). Souvent, ça règle 90% du problème sans sacrifier votre audience, et vous gardez la main pour durcir si le trafic toxique insiste.
👉 Lire aussi: Quand afficher un IBAN dans son tunnel de paiement ?

