Protection anti-bots (crawlers “IA”) et analyse des logs Apache2

Documentation permettant d'identifier, diagnostiquer et limiter l’impact des bots automatisés (crawlers “IA”, scrapers, previewers sociaux, etc.) qui peuvent drainer un site vitrine en générant beaucoup de requêtes inutiles, parfois sur des pages dynamiques coûteuses.

Objectif

• Surveiller l’activité HTTP via les logs Apache2.
• Repérer les User-Agent agressifs (bots) et comprendre ce qu’ils font (URLs ciblées, volume, codes HTTP, IPs).
• Décider quoi bloquer (agent, chemins, IP, ASN) sans casser le référencement ni l’accès légitime.
• Appliquer des mesures de blocage ciblées au niveau Apache, en priorité sur les zones dynamiques.

Où sont les logs Apache2 (Ubuntu/Debian)

• /var/log/apache2/access.log : trafic HTTP (requêtes, codes, User-Agent, etc.)
• /var/log/apache2/error.log : erreurs Apache/PHP, timeouts, problèmes TLS, etc.

Commandes utiles pour lire les logs

Suivre le trafic en temps réel

sudo tail -f /var/log/apache2/access.log
sudo tail -f /var/log/apache2/error.log

Voir les dernières lignes (diagnostic rapide)

sudo tail -n 200 /var/log/apache2/access.log
sudo tail -n 200 /var/log/apache2/error.log

Filtrer un User-Agent suspect

Exemple : repérer un crawler en particulier (remplacer le motif).

sudo grep -i "meta-externalagent" /var/log/apache2/access.log | tail -n 50

Filtrer une URL ou une zone “coûteuse”

sudo grep -E " /(cart/|clientarea\.php|submitticket\.php|store/)" /var/log/apache2/access.log | tail -n 50

Comprendre une ligne d’access log (format "combined")

Le format combined contient typiquement :

• IP client
• Date/heure
• Méthode (GET/POST…)
• Chemin (URL appelée)
• Code HTTP (200/301/403/404/429/500…)
• Taille réponse
• Referer (source éventuelle)
• User-Agent (signature du client)

Ce qu’on cherche en priorité :

• Un volume anormal de requêtes (même UA, même IP ou même famille d’IP).
• Des requêtes répétées sur des pages dynamiques ou des endpoints déclenchant beaucoup de PHP/DB.
• Des séries de 404 (scan), 301 (crawling agressif), ou des 500 (surcharge / erreurs applicatives).
• Un UA “social preview” / “AI crawler” qui se comporte comme un scraper (fréquence, URLs non pertinentes).

Analyser rapidement : Top User-Agents, IPs, URLs

Top 20 des User-Agents les plus fréquents

sudo awk -F\" '{print $6}' /var/log/apache2/access.log \
  | sort | uniq -c | sort -nr | head -n 20

Top 20 des IPs les plus actives

sudo awk '{print $1}' /var/log/apache2/access.log \
  | sort | uniq -c | sort -nr | head -n 20

Top 30 des URLs les plus demandées

sudo awk '{print $7}' /var/log/apache2/access.log \
  | sort | uniq -c | sort -nr | head -n 30

Identifier les URLs les plus “coûteuses” (souvent dynamiques)

Astuce : si votre site a des zones dynamiques (panier, espace client, recherche, formulaires, endpoints API…), elles ont souvent des patterns (ex: /clientarea, /cart, /search, /api, *.php).

sudo awk '{print $7}' /var/log/apache2/access.log \
  | grep -E "\.php|/api/|/search|/cart|/client|/store" \
  | sort | uniq -c | sort -nr | head -n 30

Que bannir et comment décider (méthode factuelle)

Ne pas “bannir au hasard” : la bonne cible n’est pas forcément un bot connu, mais un comportement mesurable. Critères courants :

• Fréquence : un UA ou une IP qui fait des centaines/milliers de hits en peu de temps.
• Chemins ciblés : forte proportion de requêtes sur des endpoints dynamiques coûteux.
• Qualité : très forte proportion de 404 (scan), ou 301/200 sur des URLs sans intérêt.
• Impact : corrélation avec un CPU élevé, beaucoup de processes Apache/PHP, latence ou erreurs 5xx.

Exemple d’indicateurs “à bannir”

• Un User-Agent qui s’identifie comme crawler mais qui ne respecte pas un rythme raisonnable.
• Un “preview bot” (réseaux sociaux) qui martèle des pages dynamiques (ce n’est pas son usage normal).
• Un UA qui change souvent mais qui garde le même pattern (URLs, IPs, horaires), typique de scrapers.

Ce qu’il faut éviter

• Bloquer globalement Googlebot/Bingbot sans raison : cela dégrade le SEO.
• Bloquer toute une plage IP “à l’aveugle” sans confirmer via logs (risque de faux positifs).
• Bloquer un UA sur tout le site si le problème concerne surtout une zone (mieux : blocage ciblé par chemin).

Réponses Apache utiles : comprendre 200 / 301 / 403 / 429 / 5xx

• 200 : page servie (si volume massif sur dynamique → charge CPU)
• 301/302 : redirection (un bot peut reboucler et faire exploser le trafic)
• 403 : refus (effet attendu si blocage)
• 429 : rate-limit (si vous mettez des limites, mod_evasive, reverse proxy, WAF…)
• 500/502/503 : indicateurs de surcharge ou d’erreurs applicatives

Stratégie recommandée : bloquer en priorité sur zones dynamiques

La stratégie la plus propre est de :

1. Identifier le bot (User-Agent) dans les logs.
2. Le marquer avec SetEnvIfNoCase.
3. Le bloquer uniquement sur les zones coûteuses (via <LocationMatch>), en laissant le reste du site accessible.

Exemple de blocage ciblé par User-Agent (Apache)

Principe :

• On marque le bot par variable d’environnement (ex: bad_meta).
• On refuse ce bot uniquement sur certaines routes.

# Marquage UA
SetEnvIfNoCase User-Agent "meta-externalagent" bad_meta
SetEnvIfNoCase User-Agent "facebookexternalhit" bad_meta

# Blocage sur routes dynamiques (adapter la liste)
<LocationMatch "^/(submitticket\.php|cart/|store/|clientarea\.php|viewticket\.php|knowledgebase\.php|announcements\.php)">
  <RequireAll>
    Require all granted
    Require not env bad_meta
  </RequireAll>
</LocationMatch>

Résultat attendu : le bot reçoit des 403 sur les zones ciblées, mais le site reste accessible au reste du monde.

Vérifier que le blocage fonctionne

1) Recharger Apache et vérifier la syntaxe

sudo apache2ctl -t
sudo systemctl reload apache2

2) Chercher les 403 générés pour un UA donné

sudo grep -i "meta-externalagent" /var/log/apache2/access.log | tail -n 50

Vous devez voir des codes 403 sur les URLs ciblées.

3) Contrôler que la charge retombe

uptime
ps -C apache2 --no-headers | wc -l

Bonnes pratiques complémentaires (optionnel)

• robots.txt : utile pour les bots “polis”, inutile contre les scrapers agressifs (mais à maintenir propre).
• Fail2ban : utile si le problème est plutôt “IP qui scanne/force” que “UA légitime qui martèle”.
• Reverse proxy / CDN : permet d’absorber/filtrer avant Apache (rate limit, bot management, cache).
• Apache event + php-fpm : réduit l’impact des pics par rapport à prefork + mod_php sur sites dynamiques.

Checklist opérationnelle (résumé)

1. Observer : tail -f access.log, repérer UA/IP/URLs anormaux.
2. Quantifier : top UA, top IP, top URLs.
3. Décider : bannir un UA si volume + impact + ciblage dynamique.
4. Appliquer : SetEnvIfNoCase + LocationMatch ciblé.
5. Vérifier : 403 sur les routes ciblées + charge CPU stable.