Journal Apache n'apprécie pas le HTTP Range

Posté par  . Licence CC By‑SA.
Étiquettes :
37
25
août
2011

Un bug exploitable à distance a récemment été découvert sur le serveur HTTP Apache et affecterait toutes les versions depuis la 1.3.

Le bug provient de la façon dont Apache traite une requête HTTP demandant plusieurs rangées de données se chevauchant. En effet, il est possible de spécifier dans l'en-tête HTTP la rangée des données que l'on veut recevoir au lieu des données complètes. Ceci est notamment utilisé lors du téléchargement d'un fichier et permet de reprendre le téléchargement là où il s'était arrêté.

L'attaque est assez simple puisqu'il suffit d'envoyer un ensemble de requêtes demandant des rangées se chevauchant. Un simple script Perl permet donc de mettre à genou un serveur. Celui-ci va prendre toutes les ressources CPU et consommer toute la mémoire. Ceci entraîne inévitablement la consommation du swap et donc l'asphyxie du système.

Pour l'heure aucun patch n'est disponible mais des solutions sont proposées, à savoir, limiter les requêtes de ce type.

On notera que la version Apache 1.3 d'OpenBSD ne semble pas être affecté par ce phénomène. OVH à quant à lui complètement désactivé les requêtes HTTP Range sur les serveurs mutualisés en attendant la résolution du problème.

  • # Debian Security

    Posté par  . Évalué à 9.

    Je te remercie pour cette traduction (tant technique que linguistique), de ce que j'ai pu lire sur le sujet.
    Étant administrateur d'un serveur web (le miens) mais pas du tout du "milieu" de l'informatique, j'avais du mal à saisir cette histoire sur la newsletter Debian-security.
    J'avais bien compris les conséquences et la gravité du problème, mais pas le fonctionnement de cette faille.

    C'est d'ailleurs mon gros problème avec cette newsletter : je ne comprend pas tout ce qui s'y dit, alors que c'est quand même important.

    Bref, si quelqu'un connait un endroit où les problématiques soulevées, et surtout les solutions à mettre en oeuvre, sont traduites en français, je suis preneur!

    En l'occurrence, il faut faire quoi concrètement ?

    • [^] # Re: Debian Security

      Posté par  . Évalué à 10.

      En l'occurrence, il faut faire quoi concrètement ?

      http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/browser

      However there are several immediate options to mitigate this issue until
      a full fix is available:

      1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
      either ignore the Range: header or reject the request.

      Option 1: (Apache 2.0 and 2.2)

            # Drop the Range header when more than 5 ranges.
      # CVE-2011-3192
      SetEnvIf Range (,.*?){5,} bad-range=1
      RequestHeader unset Range env=bad-range

      # optional logging.
      CustomLog logs/range-CVE-2011-3192.log common env=bad-range

      Option 2: (Also for Apache 1.3)

            # Reject request when more than 5 ranges in the Range: header.
      # CVE-2011-3192
      #
      RewriteEngine on
      RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
      RewriteRule .* - [F]

      The number 5 is arbitrary. Several 10's should not be an issue and may be
      required for sites which for example serve PDFs to very high end eReaders
      or use things such complex http based video streaming.

      2) Limit the size of the request field to a few hundred bytes. Note that while
      this keeps the offending Range header short - it may break other headers;
      such as sizeable cookies or security fields. 

            LimitRequestFieldSize 200

      Note that as the attack evolves in the field you are likely to have
      to further limit this and/or impose other LimitRequestFields limits.

      See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

      3) Use mod_headers to completely dis-allow the use of Range headers:

            RequestHeader unset Range

      Note that this may break certain clients - such as those used for
      e-Readers and progressive/http-streaming video.

      4) Deploy a Range header count module as a temporary stopgap measure:

       http://people.apache.org/~dirkx/mod_rangecnt.c

      Precompiled binaries for some platforms are available at:

      http://people.apache.org/~dirkx/BINARIES.txt

      5) Apply any of the current patches under discussion - such as:

      http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3cCAAPSnn2PO-d-C4nQt_TES2RRWiZr7urefhTKPWBC1b+K1Dqc7g@mail.gmail.com%3e

    • [^] # Re: Debian Security

      Posté par  . Évalué à 10.

      Il y à plusieurs solutions proposées. Elles concernent toutes une façons de limiter les requêtes contenant des rangées.

      Rejeter Range

      Apache 2

      Pour Apache 2, on définit une variable d'environnement si on détecte plus de 5 rangées dans la requête et on retire le champ Range.

      SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range

      Il est aussi possible de ne pas s'embêter et de carrément le retirer dès qu'il est présent.

      RequestHeader unset Range

      Apache 1.3

      Pour Apache 1.3 même chose mais en utilisant mod_rewrite.

      RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]

      Limiter la taille des champs

      Deuxième solution, limiter la taille des champs de l'en-tête.

      LimitRequestFieldSize 200

      Inconvénient, cela peut casser certaines communications et le champ Range est toujours présent.

      Utiliser un compteur

      Le module mod_rangecnt dont les binaires sont disponibles permet de compter les rangées et de rejeter la requête.

      Suivre l'évolution

      La dernière solution est de suivre l'évolution de la résolution du problème et d'appliquer les patchs proposés.

      • [^] # Re: Debian Security

        Posté par  . Évalué à -2.

        OK merci, surtout à Spark pour la traduction, et la dernière solution, que je vais appliquer comme à chaque fois...

        Mon problème est que je suis qu'un gros noob qui sait pas ce qu'est Range, et qui ne sait pas où écrire ces lignes de correction si ce n'est pas explicitement indiqué. Là, à force de regarder les différents liens, je suppose qu'il faut définir des options dans le fichier de config de Apache?

        Bref, il me faudrait un tuto à la site du zéro ...

        • [^] # Re: Debian Security

          Posté par  (site web personnel) . Évalué à 8.

          Bref, il me faudrait un tuto à la site du zéro ...

          ... Ou un admin système (c'est un métier, dont les compétences sont l'anglais technique et un verni sur les protocoles).

          • [^] # Re: Debian Security

            Posté par  . Évalué à 6.

            Oui tu as raison sur le fond, mais bon, pour un serveur perso et auto hébergé...
            Je suis conscient de mes lacunes, et je fais tout pour y remédier, en m'informant lorsque un tel sujet se présente à moi.

            J'avais bon pour le fichier de configuration?

        • [^] # Re: Redhat/Fedora

          Posté par  . Évalué à 7.

          Pour Redhat/Fedora (ça doit être similaire pour Debian/Ubuntu):
          Tu crées un fichier /etc/httpd/conf.d/fix-range-CVE-2011-3192.conf dans lequel tu écrits:

          # Drop the Range header when more than 10 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){10,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range

          Puis tu redémarres apache.
          # service httpd restart
          Les attaques seront enregistrées dans /var/log/httpd/range-CVE-2011-3192.log

          • [^] # Re: Redhat/Fedora

            Posté par  . Évalué à 3.

            Merci koopa!

            Je ne sais pas si c'est ma question qui était mal formulée, ou trop débile pour susciter une envie de réponse pertinente, mais je commençais à désespérer.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 5.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Debian Security

        Posté par  . Évalué à 0.

        En fait la barrière se situe plus au niveau de la technique (je me débrouille bien en anglais et même technique, mais dans ma branche professionnelle).
        Ensuite, comme les termes anglais se retrouvent aussi dans les fichiers de configuration, certaines traductions sont carrément inutiles, le plus important à mon niveau est de bien comprendre les solutions à appliquer.
        En l’occurrence, les gars suggèrent de rajouter des lignes (que j'arrive même en faisant un effort), mais il ne m'est pas évident de savoir où les coller!

      • [^] # Re: Debian Security

        Posté par  . Évalué à 3.

        J'ai cherché un petit moment sur comment traduire range et à aucun moment intervalle ne m'est venu à l'esprit. Effectivement le terme serait plus adapté.

      • [^] # Re: Debian Security

        Posté par  . Évalué à 2.

        "Segment de donnée" me semble familier aussi.

        • [^] # Re: Debian Security

          Posté par  . Évalué à 2.

          Ou encore portée (bof), zone, étendue.
          Ça ne manque pas.
          Mais rangée, non :-)

          • [^] # Re: Debian Security

            Posté par  . Évalué à 5.

            Surtout quand on voit la gueule de certains fichiers de config Apache, on se dit que "rangée" ne fait pas partie du vocabulaire de l'admin...

            ------------> [ ]

  • # Contournements

    Posté par  (site web personnel) . Évalué à -2.

    http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/%3C20110824161640.122D387DD@minotaur.apache.org%3E

  • # Pas compris

    Posté par  (site web personnel) . Évalué à 3.

    Celui-ci va prendre toutes les ressources CPU et consommer toute la mémoire.

    Pas tout suivi : en quoi ça prend toutes les ressources? Est-ce dire que la taille de la requête (quelques octets par range) est suffisamment petit par rapport à la taille de la réponse (et son coût CPU) et que tout est mémorisé en mémoire avant d'envoyer?

    Car j'ai du mal à comprendre le rapport entre les deux (bêtement, je me dis qu'Apache gère les ranges un par un, en les envoyant un par un, et donc pas de conso RAM donc pas de conso swap qui tue).

    • [^] # Re: Pas compris

      Posté par  . Évalué à 10.

      C'est la manière interne dont Apache gère la requête qui pose problème.
      Comme personne n'avait pensé à cette astuce, le code n'est pas "optimisé" pour cela.

      Chaque demande de "range" est traitée en recopiant en interne la ressource (une partie du fichier demandé).
      Si tu demandes un seul range par requête, ça reste une demande normale. Ou une attaque normale.
      La présente astuce utilise le fait qu'une seule requête puisse spécifier un nombre énorme de ranges. Genre:

      HEAD / HTTP/1.1
Host: 127.0.0.1
Range: bytes=0-,10-20,10-21,10-22,10-23 [...] 10-10000,10-10001,10-10002 etc etc

      Une seule requête va demander à Apache de dupliquer des milliers de fois en mémoire un morceau de fichier. Puis il va envoyer les données.
      L'implémentation n'est clairement pas terrible, mais tant que personne n'avait eu cette idée à la con, il n'y avait pas de problème.

  • # Full Disclosure

    Posté par  . Évalué à -1.

    Est-ce que quelqu'un peut m'expliquer pourquoi cette faille a été dévoilée en public ?

    Je comprends que c'est un moyen de pression pour les boites qui font la sourde oreille jusqu'à ce qu'elles soient alors obligées de corriger, et je trouve ça très bien. Par contre je ne pensais pas que c'était utilisé "contre" des LL, pourquoi ne pas discuter de ça entre devs et ensuite annoncer la faille une fois le patch sorti ?

    • [^] # Re: Full Disclosure

      Posté par  (site web personnel) . Évalué à 2.

      Est-ce que quelqu'un peut m'expliquer pourquoi cette faille a été dévoilée en public ?

      Parce qu'un mec avait envie.
      Maintenant, si tu arrives à raisonner tous les informaticiens de la planète sans exception...

    • [^] # Re: Full Disclosure

      Posté par  . Évalué à 1.

      Parce qu'au moins comme ça tout le monde est sur un pied d'égalité ?

      discuter de ça entre devs

      Je pense qu'il y aura toujours des fuites sur ce genre de chose. Les dev LL sont le contraire de profiteurs mais il y a toujours des licornes galeuses.

    • [^] # Re: Full Disclosure

      Posté par  . Évalué à 10.

      Parce que ça permet aux administrateurs de prendre des mesures en attendant qu'une solution soit trouvée.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Full Disclosure

      Posté par  . Évalué à 10.

      Si tu lis les liens fournis dans l'article (en plus, c'est le premier lien, c'est pas comme s'il fallait chercher beaucoup) :
      1/ il existe déjà au moins un outil automatique pour exploiter cette faille
      2/ et l'utilisation de cet outil à déjà été constatée

      Donc il est infiniment préférable de prévenir les cibles potentielles pour qu'elles puissent se protéger plutôt que de les laisser se faire attaquer librement.

      Ou alors tu inventes le concept de "la sécurité par l'obscurité, mais juste pour les cibles" (ça va plaire aux crackers et aux script kiddies, mais assez moyennement aux gestionnaires de sites web, je pense ...).

      • [^] # Re: Full Disclosure

        Posté par  . Évalué à 3.

        D'après ce que j'ai vu passer sur Slashdot, le bug aurait été rapporté il y a quatre ans par un gars qui travaillait chez google, mais les gens d'Apache n'avaient pas considéré ca comme grave (du genre , oui mais pour que ca arrive, il faut que le serveur soit configuré comme ci ou comme ca)...

        • [^] # Re: Full Disclosure

          Posté par  . Évalué à -6.

          Slashdot...

        • [^] # Re: Full Disclosure

          Posté par  . Évalué à 6.

          C'est vrai que sur Slashdot, ils s'y connaissent en DDOS...

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Full Disclosure

      Posté par  (site web personnel) . Évalué à 1.

      Je ne sais pas... par exemple
      - transparence
      - partage
      - responsabilité

      Bref, quelques principes du développement d'application libre.

      • [^] # Re: Full Disclosure

        Posté par  (site web personnel) . Évalué à 0.

        Bref, quelques principes du développement d'application libre.

        Ah oui? Ben justement, la responsabilité dit qu'on ne fait pas de full disclosure avant qu'un patch soit disponible.
        Ici, c'est exceptionnellement que le full disclosure est utile, car la faille est utilisée, donc faut la faire connaitre au maximum. Mais sans cet argument, c'est l'inverse qu'il est habituel de faire pour être un "gentil".

        C'est fou ça, de faire l'apologie du full disclosure comme ça, de dire c'est bien sans avertissement, et donc de faire croire que c'est un principe "bon" dans le cas général. Non, ce n'est pas bien dans le cas général.

        Faudrait voir quand ça arrivera sur un logiciel à toi, comment tu apprécieras de te prendre un full disclosure dans la gueule alors que ce n'était pas utile sauf pour foutre le bordel.

        (bon, après, je répond à ce commentaire en particulier, car les autres commentaires mettent plus de pincettes en précisant bien que c'est parce que la faille est utilisée que c'est utile, ce qui m'a fait réagir est de balancer que c'est bien sans mette d'avertissement sur les raisons exceptionnelles de ce cas)

        • [^] # Re: Full Disclosure

          Posté par  (site web personnel) . Évalué à 3.

          Tu parles de responsible disclosure, toi...
          Et bien en l'occurence ça a tout l'air d'en être puisque Apache a l'air d'avoir été prévenu et des moyens de contournement proposés en attendant un patch (expected in the next 48 hours.)

          Je préfère largement être prévenu avec les infos qui vont bien et attendre un fix plutot que ça soit utilisé dans l'ombre. Donc oui, apologie du full disclosure, avec préférence pour le responsible disclosure, qui n'en est qu'une variante.

          Sinon, je suis preneur de tes arguments contre le full disclosure, parce que pour le moment, tu t'indignes et dis que c'est mal, mais t'explique pas pourquoi, à part avec le mot "bordel".

          Aller, bon moinssage...

          • [^] # Re: Full Disclosure

            Posté par  (site web personnel) . Évalué à 0.

            Sinon, je suis preneur de tes arguments contre le full disclosure

            Déjà été dis mais bon... Juste pose-toi la question de savoir si toi tu apprécierais un full disclosure dans la tronche. A moins que tu sois masochiste, je ne pense pas que tu aimerais.
            Tant que la faille n'est pas exploitée, laisser un peu de temps aux devs est le minimum du respect. Et seulement si ils ne réagissent pas balancer dans la nature pour faire réagir.

            • [^] # Re: Full Disclosure

              Posté par  (site web personnel) . Évalué à 2.

              "Tant que la faille n'est pas exploitée"

              Mais tu n'en sais rien. Comment tu vérifies sur le parc mondial si c'est exploité ?

              Alors selon ce que le mec qui trouve une faille juge être le plus adapté, j'apprécie un full ou responsible disclosure.
              Je pense que le mec qui me code un poc pour péter mon soft est plus au courant sur l'exploitabilité et l'exploitation de la faille que moi, et s'il juge qu'il est préférable de faire un full full plutot qu'un responsible disclosure, et bien c'est que c'est probablement le cas.

              Y aura toujours des connards pour se faire mousser sans penser aux conséquences, mais c'est comme l'histoire du couteau. Y'aura toujours des malades qui s'en serviront pour planter leurs voisins, or le couteau n'est pas mauvais par nature.

    • [^] # Re: Full Disclosure

      Posté par  . Évalué à 1.

      La faille a été dévoilée car elle est déjà largement exploitée. C'est ce que dit Apache.
      Il faut donc informer les utilisateurs pour qu'ils prennent des dispositions si nécessaire.
      Si la faille n'était pas exploitée, ils n'en parleraient évidemment pas.

    • [^] # Re: Full Disclosure

      Posté par  . Évalué à 2.

      Parce que, plus qu'une faille, c'est un bug qui peut être rancontré dans la marche "normal" du service.
      Ce n'est pas le cas nominal, mais un cas limite qui aurait dû être prévu et testé.
      Donc c'est pour avertir les utilisateurs du produit en attendant un contournement ou une correction.
      Il ne faut pas voir le mal partout.

  • # Test

    Posté par  (site web personnel) . Évalué à 4.

    Dans la discussion sur slashdot, on peut lire un commentaire qui donne un test à effectuer afin de voir si on est vulnérable.

    /bin/echo -en "HEAD / HTTP/1.1\r\nHost:localhost\r\nRange:bytes=0-,$(perl -e 'for ($i=1;$i<1300;$i++) { print "5-$i,"; }')5-1300\r\nAccept-Encoding:gzip\r\nConnection:close\r\n\r\n" | nc localhost 80

    Si on est vulnérable, on devrait voir des entêtes anormalement longues. Il parle de 900k. Je n'ai pas les connaissances techniques pour juger la qualité du test mais d'autres ici les ont et pourront peut-être nous éclairer.

  • # Comment ça se voit dans les logs ?

    Posté par  (site web personnel) . Évalué à 2.

    J'ai subi une belle attaque ce matin et mon serveur s'est écroulé. J'ai dû y aller de mon reboot sauvage car plus rien ne répondait (enfin si, au bout de 10-15 minutes).

    Y a moyen de voir si c'est une attaque de ce genre dans les logs ? Parce que j'ai rien trouvé…

    Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # OpenBSD

    Posté par  (site web personnel) . Évalué à 7.

    Au sujet du cas OpenBSD (et de leur version forkée d'Apache qui est censée être invulnérable à ce DoS) il est bon de lire ce commentaire trouvé sur LWN :

    https://lwn.net/Articles/456350/

    Let's not get ahead of ourselves, the Apache advisory itself says that some of the POC / test scripts don't actually work on a typical out-of-box install, not because it isn't vulnerable, but because they're making bad assumptions. Real bad guys could fix this, but obviously the Apache team isn't going to spell out how.
    If we look at Red Hat's security numbers we see that a significant number of POCs fail out-of-box against RHEL, but a knowledgeable hacker could fix them because RHEL was actually vulnerable. This means you're safer than you might appear to be against script kiddies (who won't know how) but could get a false sense of security if your adversaries are sophisticated. The same probably applies here to Apache on OpenBSD.

    En résumé ce n'est pas parce que le script d'exploitation ne marche pas "out of the box" sur OpenBSD que ça veut dire que ce système est protégé. Peut-être qu'une simple adaptation du script permettra de DoSer l'Apache d'OpenBSD.

    • [^] # Re: OpenBSD

      Posté par  . Évalué à 4.

      Peut-être qu'une simple adaptation du script permettra de DoSer l'Apache d'OpenBSD.

      Le tout est de bien « doser » l'attaque :-)

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: OpenBSD

      Posté par  . Évalué à 3.

      ce n'est pas parce que le script d'exploitation ne marche pas "out of the box" sur OpenBSD que ça veut dire que ce système est protégé

      C'est valable pour l'immense majorité des protections.
      Cela dit, ça écrème déjà les quasi-100% de script-kiddies. Les serveurs touchés au hasard ne sont pas vulnérables. Les serveurs touchés à-cause-qu'il-a-dit-du-mal-de-ma-team sont tranquilles aussi. Les petites vengeances de merdes, etc, tout cela passe à la trappe.
      Ne restent que les attaquants compétents. Ils sont peu nombreux.

      • [^] # Re: OpenBSD

        Posté par  . Évalué à 4.

        Ne restent que les attaquants compétents. Ils sont peu nombreux.

        Ce sont aussi les plus dangereux. Donc, dès que le site est un peu sensible (e-commerce, site officiel…), il faut en tenir compte.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: OpenBSD

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 31 août 2011 à 16:16.

      D'ailleurs on voit passer un correctif sur la liste de dev OpenBSD donc peut-être que le bouzin était vulnérable après tout ?

      http://www.mail-archive.com/ports@openbsd.org/msg36545.html

  • # mod_rangecnt + fail2ban

    Posté par  (site web personnel) . Évalué à 10.

    Je viens d'activer le module mod_rangecnt + une règle de fail2ban : super efficace !

    Comment faire (Sous Ubuntu Server 10.04):
    Installer le package apache2-dev (sudo apt-get install apache2-dev)

    1. wget http://people.apache.org/~dirkx/mod_rangecnt.c
    2. sudo apxs2 -i -c -n mod_rangecnt.so mod_rangecdnt.c
    3. Créer le fichier /etc/apache2/mods-available/rangecnt.load avec dedans :

    LoadModule rangecnt_module /usr/lib/apache2/modules/mod_rangecnt.so

    1. cd /etc/apache2/mods-enabled/ puis sudo ln -s /etc/apache2/mods-available/rangecnt.load
    2. Redémarrer Apache

    Ensuite créer la règle fail2ban (si vous avez déja une install de fail2ban !) :
    * Ajouter le fichier /etc/fail2ban/filter.d/apache-range.conf avec dedans :

    [Definition]
failregex = [[]client <HOST>[]] (Rejected on a Range: header with more than 5 ranges)
ignoreregex =

    • Editez /etc/fail2ban/jail.conf et ajoutez :

      [apache-range]
      enabled = true
      port = http,https
      filter = apache-range
      logpath = /var/log/apache/*error.log
      maxretry = 10

    • Relancez votre fail2ban

    Utilisez le script contre votre serveur, vous devriez voir des lignes :

    /var/log/apache2/error.log:[Thu Aug 25 17:20:51 2011] [warn] [client xx.xx.xx.xx] Rejected on a Range: header with more than 5 ranges (has 1300)

    Dans votre log apache puis dans votre log Fail2ban :

    2011-08-25 17:26:33,814 fail2ban.actions: WARNING [apache-range] Ban xx.xx.xx.xx

    Victoire !

    • [^] # Re: mod_rangecnt + fail2ban

      Posté par  . Évalué à 3.

      Chez moi j'ai du faire ça
      sudo apxs2 -i -c mod_rangecnt.c -n mod_rangecnt.so

    • [^] # Re: mod_rangecnt + fail2ban

      Posté par  . Évalué à 6.

      Au lieu de faire:

      cd /etc/apache2/mods-enabled/ puis sudo ln -s /etc/apache2/mods-available/rangecnt.load

      Est-ce que ceci ne fonctionnerait pas?:

       sudo a2enmod rangecnt

    • [^] # Re: mod_rangecnt + fail2ban

      Posté par  . Évalué à 1.

      en quoi cela te protège des
      > des rangées se chevauchant
      si il y en a moins de 5 ?

      • [^] # Re: mod_rangecnt + fail2ban

        Posté par  . Évalué à 2.

        S'il y en moins de 5, il y a peu de chance que l'attaque réussisse.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Autre entête

    Posté par  (site web personnel) . Évalué à 4.

    Pour info Range-Request est lui aussi affecté par le bug. Et d'après ce que l'on peut lire sur FD on n'en est qu'au début.

    D'autre part Apache ne serait pas le seul serveur vulnérable selon certains contributeurs de la liste.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.