2 votes

Quelle est la cause de cette erreur Apache 401?

J'ai Apache 2.4 installé sur Debian 9.9, basiquement, il ne fait rien de spécial à part servir une instance de Roundcube (actuellement 1.4 RC-1).

La racine du document d'Apache est /home/web (pour des raisons), et l'instance de Roundcube est installée dans /home/web/mail.

L'utilisateur Apache (www-data) a un accès complet en lecture/écriture à tout l'arborescence du répertoire /home/web.

Le document racine a un fichier d'index qui redirige vers www.mydomain.co.uk/mail et j'utilise mod_rewrite pour changer toutes les requêtes HTTP en HTTPS.

Aujourd'hui, j'ai remarqué (et je ne sais pas depuis combien de temps cela se produit) que lorsque je vais sur mydomain.co.uk, cela génère une erreur 401 dans Apache :

192.168.10.79 - - [09/Juin/2019:18:49:59 +0100] "GET /mail/ HTTP/1.1" 401 2955 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0)
Gecko/20100101 Firefox/67.0"

Cela pose particulièrement problème lors de l'accès externe, car cela déclenche une règle de fail2ban et bannit mes clients.

L'erreur 401 signifie "authentification échouée" mais je n'ai pas mis en place d'authentification sur ce répertoire avec Apache, ce qui, d'après ce que je comprends, nécessiterait la présence d'un fichier .htpasswd - j'ai vérifié l'existence de ce fichier dans ma racine de document Apache, et il n'existe pas - ou l'utilisation d'une clause d'authentification dans le fichier virtualhost - dont il n'y a pas non plus.

Comment puis-je trouver la cause et éviter cette erreur 401 ?

Quelques informations de débogage supplémentaires depuis Fiddler :

GET https://www.mydomain.co.uk/mail/ HTTP/1.1
Accept: text/html, application/xhtml+xml, image/jxr, */*
Accept-Language: en-GB
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: www.mydomain.co.uk
Connection: Keep-Alive
Cookie: roundcube_sessid=sadh0s1j2rn769rvebhpsv6m81

HTTP/1.0 401 Non autorisé
Date: Lun, 10 Juin 2019 08:27:28 GMT
Serveur: Apache/2.4.25 (Debian)
Strict-Transport-Security: max-age=63072000; includeSubdomains;
Expires: Lun, 10 Juin 2019 08:27:28 GMT
Cache-Control: privé, doit être réévalué
Pragma: privé
Dernière modification: Lun, 10 Juin 2019 08:27:28 GMT
X-UA-Compatible: IE=edge
X-Frame-Options: sameorigin
Langue du contenu: en
Vary: Accept-Encoding
X-Robots-Tag: noindex, nofollow
Connection: fermé
Content-Type: text/html; charset=UTF-8
Content-Length: 5435

Si je regarde dans Fiddler sous l'onglet "Auth" :

Aucun en-tête Proxy-Authenticate n'est présent.

Aucun en-tête WWW-Authenticate n'est présent.

Quelques informations de débogage supplémentaire depuis wget :

Sortie DEBUG créée par Wget 1.18 sur linux-gnueabi.

Lecture des entrées HSTS depuis /home/darren/.wget-hsts
Encodage URI = ‘UTF-8’
Nom de fichier converti 'mail' (UTF-8) -> 'mail' (UTF-8)
--2019-06-10 13:34:43--  https://www.mydomain.co.uk/mail
Certificats chargés : 151
Résolution de www.mydomain.co.uk (www.mydomain.co.uk)... XX.XX.XX.XX
Mise en cache www.mydomain.co.uk => XX.XX.XX.XX
Connexion à www.mydomain.co.uk (www.mydomain.co.uk)|XX.XX.XX.XX|:443... connecté.
Socket créé 3.
Libération de 0x004bf2e0 (nouveau refcount 1).

---début de requête---
GET /mail HTTP/1.1
User-Agent: Wget/1.18 (linux-gnueabi)
Accept: */*
Accept-Encoding: identité
Host: www.mydomain.co.uk
Connection: Keep-Alive

---fin de       requête---
Requête HTTP envoyée, en attente de réponse...
---début de réponse---
HTTP/1.1 301 Redirigé définitivement
Date: Lun, 10 Juin 2019 12:34:43 GMT
Serveur: Apache/2.4.25 (Debian)
Strict-Transport-Security: max-age=63072000; includeSubdomains;
Location: https://www.mydomain.co.uk/mail/
Content-Length: 331
Keep-Alive: délai=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

---fin de réponse---
301 Redirigé définitivement
Socket 3 enregistré pour réutilisation persistante.
Analyse Strict-Transport-Security max-age = 63072000, includeSubDomains = true
Hôte HSTS ajouté : www.mydomain.co.uk:443 (max-age: 63072000, includeSubdomains: true)
Encodage contenu URI = ‘iso-8859-1’
Lieu : https://www.mydomain.co.uk/mail/ [suivant]
Passer 331 octets de corps : [

301 Moved Permanently

Redirigé définitivement
Le document a été déplacé ici.

Apache/2.4.25 (Debian) Server at www.mydomain.co.uk Port 443

] fait.
Encodage contenu URI = Aucun
Nom de fichier converti 'mail' (UTF-8) -> 'mail' (UTF-8)
--2019-06-10 13:34:43--  https://www.mydomain.co.uk/mail/
Réutilisation de la connexion existante à www.mydomain.co.uk:443.
Réutilisation fd 3.

---début de requête---
GET /mail/ HTTP/1.1
User-Agent: Wget/1.18 (linux-gnueabi)
Accept: */*
Accept-Encoding: identité
Host: www.mydomain.co.uk
Connection: Keep-Alive

---fin de requête---
Requête HTTP envoyée, en attente de réponse...
---début de réponse---
HTTP/1.0 401 Non autorisé
Date: Lun, 10 Juin 2019 12:34:43 GMT
Serveur: Apache/2.4.25 (Debian)
Strict-Transport-Security: max-age=63072000; includeSubdomains;
Set-Cookie: roundcube_sessid=9dd09n33d6k3f1kil69f90bkk6; path=/; secure; HttpOnly
Expires: Lun, 10 Juin 2019 12:34:43 GMT
Cache-Control: privé, no-cache, no-store, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Last-Modified: Lun, 10 Juin 2019 12:34:43 GMT
X-Frame-Options: sameorigin
Langue du contenu: en
Vary: Accept-Encoding
X-Robots-Tag: noindex, nofollow
Connection: fermé
Content-Type: text/html; charset=UTF-8

---fin de réponse---
401 Non autorisé

Cookie stocké www.mydomain.co.uk -1 (ANY) /   [expiration none] roundcube_sessid 9dd09n33d6k3f1kil69f90bkk6
Désactivation de toute réutilisation ultérieure du socket 3.

Identifiant/Mot de passe d'authentification échoué.
Enregistrement des entrées HSTS dans /home/darren/.wget-hsts

1voto

harrymc Points 394411

Le code d'erreur 401 Unauthorized est un code d'état de réponse HTTP indiquant que la la requête envoyée par le client n'a pas pu être authentifiée, mais peut avoir de nombreuses causes.

Je suggérerais:

  • Postez la requête et la réponse complètes pour que nous puissions les examiner. D'un intérêt particulier est l'en-tête de réponse WWW-Authenticate, qui contient une ou plusieurs chaînes de défis, indiquant chacune comment l'authentification correcte peut être obtenue pour accéder à la ressource demandée.

  • Vérifiez les journaux du serveur Apache (peut nécessiter l'activation d'un journalisation détaillée).

  • Si le client est banni, le code d'erreur est généralement 401.

  • Effacez tous les cookies et le cache du navigateur sur le navigateur client.

  • Utilisez le navigateur avec toutes les extensions désactivées. Dans Firefox, c'est le mode Sans échec, et dans Chrome le mode Incognito.

  • Recherchez sur le serveur si votre application est configurée pour renvoyer ce code d'erreur.

0 votes

Merci pour la réponse. Dans l'ordre de vos suggestions : 1. Quelle demande et quelle réponse voulez-vous dire ? Cela est causé uniquement par moi en naviguant sur la page d'accueil de mon serveur qui redirige vers la page de connexion de Roundcube. 2. Rien d'utile dans les journaux, même avec un niveau de journalisation debug. 3. Rien ne devrait interdire le client au niveau de l'application. Après avoir reçu le code 401, ils sont interdits au niveau du réseau par fail2ban. 4. J'ai testé cela sur différents navigateurs et différentes machines, donc je ne pense pas que ce soit un problème de cookie/cache. 5. Comme pour 4. 6. Ce n'est nulle part que je connaisse.

0 votes

1. Utilisez un outil de débogage Web. Sur Windows, j'utiliserais Fiddler.

0 votes

J'ai ajouté quelques données provenant de Fiddler. J'espère que c'est ce dont vous avez besoin. Merci.

1voto

Darren Points 2657

Ceci est une nouvelle "fonctionnalité" dans Roundcube.

Nous retournons 401 lorsque l'utilisateur n'est pas connecté. Le code se trouve dans index.php et il peut être modifié par un plugin.

Source

Voici les lignes problématiques dans le index.php de Roundcube:

    $plugin = $RCMAIL->plugins->exec_hook('unauthenticated', array(
            'task'      => 'login',
            'error'     => $session_error,
            'http_code' => !$session_error ? 401 : 200
    ));

    $RCMAIL->set_task($plugin['task']);

//    if ($plugin['http_code'] == 401) {
//        header('HTTP/1.0 401 Unauthorized');
//    }

J'ai commenté les trois dernières lignes pour arrêter la production de l'erreur 401.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X