Page d'accueil qui tombe en 404 #4900

Open
opened 1 month ago by MathieuAlphamosa · 4 comments

Voilà un problème que j'ai régulièrement sur différents sites depuis 2020.
J'en fait un ticket car j'aimerais signaler le problème, voir si d'autres le rencontre, et surtout y revenir de temps en temps pour donner de nouveaux indices au fur et à mesure que je les découvre.

Problème rencontré
La page d'accueil est remplacée par une page 404.
Parfois un recalcul de la page permet de corriger le problème, parfois on doit vider le cache pour que la page d'accueil revienne.

Indices

  • Problème rencontré sur des sites en SPIP 3.1 et 3.2 (je n'ai pas de site en SPIP 4 en prod pour le moment)
  • Affecte des sites tournant sous PHP 5.6 (oui, oui...) et PHP 7.3, sur différents serveurs.
  • Certains sites n'utilise aucun plugin.
  • Cela touche plusieurs sites chez nous, toujours les mêmes.
  • Je n'ai jamais rien trouvé dans les logs de SPIP.
  • Le problème semble être déclenché par des bots qui recherchent des failles de sécurité. J'ai eu une même IP chinoise qui était présente sur un site alors que la page d'accueil tombait en 404 deux fois, à 24h d'interval.
  • Je tente de logguer un maximum d'information avant que les requêtes soient passées à SPIP, pour le moment la seule piste que j'ai trouvée est la suivante : Quelques secondes avant que le problème apparaisse sur un site un bot à envoyé une requête POST "0x[0]=androxgh0st". Je ne suis pas certain que ce soit cette requête précise qui déclenche le problème...
  • J'utilise 7G Firewall pour protéger nos sites de certaines requêtes, aucune différence avec ou sans ce "firewall".

Il se passe parfois des mois avant que le problème ce manifeste à nouveau, j'ai donc des indices au compte goutte...

Voilà un problème que j'ai régulièrement sur différents sites depuis 2020. J'en fait un ticket car j'aimerais signaler le problème, voir si d'autres le rencontre, et surtout y revenir de temps en temps pour donner de nouveaux indices au fur et à mesure que je les découvre. **Problème rencontré** La page d'accueil est remplacée par une page 404. Parfois un recalcul de la page permet de corriger le problème, parfois on doit vider le cache pour que la page d'accueil revienne. **Indices** - Problème rencontré sur des sites en SPIP 3.1 et 3.2 (je n'ai pas de site en SPIP 4 en prod pour le moment) - Affecte des sites tournant sous PHP 5.6 (oui, oui...) et PHP 7.3, sur différents serveurs. - Certains sites n'utilise aucun plugin. - Cela touche plusieurs sites chez nous, toujours les mêmes. - Je n'ai jamais rien trouvé dans les logs de SPIP. - Le problème semble être déclenché par des bots qui recherchent des failles de sécurité. J'ai eu une même IP chinoise qui était présente sur un site alors que la page d'accueil tombait en 404 deux fois, à 24h d'interval. - Je tente de logguer un maximum d'information avant que les requêtes soient passées à SPIP, pour le moment la seule piste que j'ai trouvée est la suivante : Quelques secondes avant que le problème apparaisse sur un site un bot à envoyé une requête POST "0x[0]=androxgh0st". Je ne suis pas certain que ce soit cette requête précise qui déclenche le problème... - J'utilise [7G Firewall](https://perishablepress.com/7g-firewall/) pour protéger nos sites de certaines requêtes, aucune différence avec ou sans ce "firewall". Il se passe parfois des mois avant que le problème ce manifeste à nouveau, j'ai donc des indices au compte goutte...

Le problème est de nouveau arrivé cette nuit.
J'ai trappé le robot qui a fait tomber la page d'accueil en 404.
Voilà les infos :

------------------POST------------
52.247.226.210 à 2021-10-25 03:44:59
GET:
Array
(
)

POST:
Array
(
    [0x] => Array
        (
            [0] => androxgh0st
        )

)

SERVER:
Array
(
    [USER] => www-data
    [HOME] => /var/www
    [SCRIPT_NAME] => /index.php
    [REQUEST_URI] => /
    [QUERY_STRING] => 
    [REQUEST_METHOD] => POST
    [SERVER_PROTOCOL] => HTTP/1.1
    [GATEWAY_INTERFACE] => CGI/1.1
    [REMOTE_PORT] => 58478
    [SCRIPT_FILENAME] => /data/www/SITE/index.php
    [SERVER_ADMIN] => [no address given]
    [CONTEXT_DOCUMENT_ROOT] => /data/www/SITE
    [CONTEXT_PREFIX] => 
    [REQUEST_SCHEME] => http
    [DOCUMENT_ROOT] => /data/www/SITE
    [REMOTE_ADDR] => 52.247.226.210
    [SERVER_PORT] => 80
    [SERVER_ADDR] => 192.168.1.35
    [SERVER_NAME] => www.monbeausitespip.fr
    [SERVER_SOFTWARE] => Apache
    [SERVER_SIGNATURE] => 
    [PATH] => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    [CONTENT_TYPE] => application/x-www-form-urlencoded
    [CONTENT_LENGTH] => 20
    [HTTP_USER_AGENT] => Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36
    [HTTP_ACCEPT] => */*
    [HTTP_ACCEPT_ENCODING] => gzip, deflate
    [HTTP_CONNECTION] => keep-alive
    [HTTP_HOST] => www.monbeausitespip.fr
    [proxy-nokeepalive] => 1
    [HOST] => w7_SANEF
    [SCRIPT_URI] => http://www.monbeausitespip.fr/
    [SCRIPT_URL] => /
    [FCGI_ROLE] => RESPONDER
    [PHP_SELF] => /index.php
    [REQUEST_TIME_FLOAT] => 1635126299.4037
    [REQUEST_TIME] => 1635126299
)

Content-Type: application/x-www-form-urlencoded
Content-Length: 20
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: www.monbeausitespip.fr

Ca confirme qu'il envoie un paramètre POST.
En utilisant :

curl -X POST http://www`monbeausitespip.fr -H "Content-Type: application/x-www-form-urlencoded" -H "Accept-Encoding: gzip, deflate" -d '0x[]=androxgh0st'

J'arrive à reproduire la même trace dans mon fichier de log, si ce n'est :
-# le content-lenght est de 16 de mon côté alors qu'il est de 20 du sien
-# le site ne tombe pas en 404...

Une idée ?

Le problème est de nouveau arrivé cette nuit. J'ai trappé le robot qui a fait tomber la page d'accueil en 404. Voilà les infos : ``` ------------------POST------------ 52.247.226.210 à 2021-10-25 03:44:59 GET: Array ( ) POST: Array ( [0x] => Array ( [0] => androxgh0st ) ) SERVER: Array ( [USER] => www-data [HOME] => /var/www [SCRIPT_NAME] => /index.php [REQUEST_URI] => / [QUERY_STRING] => [REQUEST_METHOD] => POST [SERVER_PROTOCOL] => HTTP/1.1 [GATEWAY_INTERFACE] => CGI/1.1 [REMOTE_PORT] => 58478 [SCRIPT_FILENAME] => /data/www/SITE/index.php [SERVER_ADMIN] => [no address given] [CONTEXT_DOCUMENT_ROOT] => /data/www/SITE [CONTEXT_PREFIX] => [REQUEST_SCHEME] => http [DOCUMENT_ROOT] => /data/www/SITE [REMOTE_ADDR] => 52.247.226.210 [SERVER_PORT] => 80 [SERVER_ADDR] => 192.168.1.35 [SERVER_NAME] => www.monbeausitespip.fr [SERVER_SOFTWARE] => Apache [SERVER_SIGNATURE] => [PATH] => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [CONTENT_TYPE] => application/x-www-form-urlencoded [CONTENT_LENGTH] => 20 [HTTP_USER_AGENT] => Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 [HTTP_ACCEPT] => */* [HTTP_ACCEPT_ENCODING] => gzip, deflate [HTTP_CONNECTION] => keep-alive [HTTP_HOST] => www.monbeausitespip.fr [proxy-nokeepalive] => 1 [HOST] => w7_SANEF [SCRIPT_URI] => http://www.monbeausitespip.fr/ [SCRIPT_URL] => / [FCGI_ROLE] => RESPONDER [PHP_SELF] => /index.php [REQUEST_TIME_FLOAT] => 1635126299.4037 [REQUEST_TIME] => 1635126299 ) Content-Type: application/x-www-form-urlencoded Content-Length: 20 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 Accept: */* Accept-Encoding: gzip, deflate Connection: keep-alive Host: www.monbeausitespip.fr ``` Ca confirme qu'il envoie un paramètre POST. En utilisant : ``` curl -X POST http://www`monbeausitespip.fr -H "Content-Type: application/x-www-form-urlencoded" -H "Accept-Encoding: gzip, deflate" -d '0x[]=androxgh0st' ``` J'arrive à reproduire la même trace dans mon fichier de log, si ce n'est : -# le content-lenght est de 16 de mon côté alors qu'il est de 20 du sien -# le site ne tombe pas en 404... Une idée ?

Bon, je reproduis la requête à l'identique mais ça ne fait pas tomber mon site en 404.

curl -X POST http://www.monbeausitespip.fr -H "Content-Type: application/x-www-form-urlencoded" -H "Accept-Encoding: gzip, deflate" -d '0x%5B%5D=androxgh0st' -H "user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36" -H "Connection: keep-alive" --output test.txt

Retour à la case départ. Malgré tout je suis persuadé que l'activité de ce bot et mes problèmes de 404 sont liés : à chaque fois que j'ai le problème il est sur mon site en train de faire des choses.

Bon, je reproduis la requête à l'identique mais ça ne fait pas tomber mon site en 404. ``` curl -X POST http://www.monbeausitespip.fr -H "Content-Type: application/x-www-form-urlencoded" -H "Accept-Encoding: gzip, deflate" -d '0x%5B%5D=androxgh0st' -H "user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36" -H "Connection: keep-alive" --output test.txt ``` Retour à la case départ. Malgré tout je suis persuadé que l'activité de ce bot et mes problèmes de 404 sont liés : à chaque fois que j'ai le problème il est sur mon site en train de faire des choses.
Owner

Hello,

a priori ce n'est pas une requête POST qui mets en cache une 404 car les POST sont traités en ignorant le cache (on ne lit et on n'écrit pas de cache sur une requête POST.

C'est donc plutôt sur les GET qu'il faut regarder, peut être un cas qui provoque une erreur, et du coup on enregistre un cache vide qui du coup génère une 404 par la suite ?

Hello, a priori ce n'est pas une requête POST qui mets en cache une 404 car les POST sont traités en ignorant le cache (on ne lit et on n'écrit pas de cache sur une requête POST. C'est donc plutôt sur les GET qu'il faut regarder, peut être un cas qui provoque une erreur, et du coup on enregistre un cache vide qui du coup génère une 404 par la suite ?

Ah, c'est intéressant !
Je me focalisais sur la requête POST que je voyais régulièrement au moment où j'ai ce souci, mais j'ai souvent une requête GET un peu avant qui tente d'accéder à /.env
Je vais tracer ces requêtes également voir si il n'y a pas autre chose qui est passé à ce moment là. Merci pour la piste !

Ah, c'est intéressant ! Je me focalisais sur la requête POST que je voyais régulièrement au moment où j'ai ce souci, mais j'ai souvent une requête GET un peu avant qui tente d'accéder à /.env Je vais tracer ces requêtes également voir si il n'y a pas autre chose qui est passé à ce moment là. Merci pour la piste !
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.