Ubuntu-fr

Nico89

Apache détecter modules inutilisés

Bonjour à tous,
Je débute tout juste les applications réseau et le monde du serveur.
J'ai installé une application de transfert de fichier qui a nécessité l'installation d'apache.
J'ai lu pas mal de littérature sur comment sécuriser apache, et je souhaiterais approfondir l'une d'entre-elle. En effet, l'idée de cette solution est de réduire "la surface d'attaque", en gros de désactiver les modules inutiles.

Ma question : comment savoir quels sont les modules utilisés par mon application. Est-ce aussi simple que "je désactive les modules un par un et je regarde si ça fonctionne" ?
Y-a-t-il des modules indispensables à ne surtout pas désactiver ?

Je sais qu'il y a bien d'autres paramétrage à effectuer avant d'en arriver à ce point, mais ce point de sécurité m'intéresse car en plus de réduire la surface d'attaque, elle permet aussi de réduire la consommation de ressources matérielle sur une configuration matérielle légère.
Dans l'attente de vos retour.

Vobul

Re : Apache détecter modules inutilisés

Salut,

L'approche de réduction de la surface d'attaque est tout à fait valide. Mais la sécurité, il faut la mettre partout.

Concrètement, c'est bien de désactiver le mod_proxy si tu ne l'utilises pas, mais en réalité, ton serveur sera hacké car ton application web permet un RCE ou RFI. Certes il y a des failles sur Apache, mais si tu le mets à jour régulièrement t'as pas trop à t'en faire.

Si tu veux vraiment faire les choses bien tu lis ça : https://www.cisecurity.org/benchmark/ap … tp_server/

Là c'est du sérieux. Bien sûr ça va de pair avec le CIS benchmark de CentOS ou whatever version de linux que tu utilises sur ton serveur.

Regarde aussi du côté de la containerisation (Docker/podman), même si c'est encore tout un monde avec des avantages et inconvénients à bien considérer.

---

Vobul
Utilisez le retour utilisable de commandes !!!
J'aime la langue française, mais je parle franglais, deal with it.
RTFM

MicP

Re : Apache détecter modules inutilisés

Bonjour

Quand il s'agit de sécurité, il faut aussi s'informer régulièrement : https://www.cert.ssi.gouv.fr

https://www.cert.ssi.gouv.fr/alerte/CER … 1-ALE-022/

Dernière modification par MicP (Le 03/01/2022, à 15:45)

Vobul

Re : Apache détecter modules inutilisés

log4j ? jamais entendu parler....

---

Vobul
Utilisez le retour utilisable de commandes !!!
J'aime la langue française, mais je parle franglais, deal with it.
RTFM

bruno

Re : Apache détecter modules inutilisés

Il serait préférable d'éviter les liens qui demande une inscription avec tout un tas d'informations personnelles pour accéder à une documentation. Et de manière générale le hors-sujet.

Pour répondre à la question initiale : il n'est a priori pas possible de connaître exactement les modules Apache inutilisés. On peut effectivement procéder par élimination en listant les modules actifs :

apache2ctl -M

et en les désactivant un par un avec la commande a2dissmod et en vérifiant que les services web fonctionnent toujours.
Cependant les modules installées de base sur une Debian ou une Ubuntu sont tous potentiellement utiles. Les autres (issus de dépôts officiels) auront de toute façon été installés suivant les besoins.

Comme cela a été évoqué par Vobul, il me semble plus important de concentrer les efforts de sécurité sur la configuration d'Apache et de ses modules, et surtout sur les applications web hébergées qui sont toujours le maillon faible qui sera attaqué en premier.

Nico89

Re : Apache détecter modules inutilisés

Merci pour vos retours.
J'ai téléchargé un des documents sur le site de cisecurity. wouff, là j'y comprend rien du tout. Je vais y aller par étape. Je suis vraiment novice.
Je sais qu'il y a des choses qui sont à mon niveau, j'ai trouvé des tutos assez pédagogiques à suivre pour d'autres phases de la sécurité.
Dans ma question initiale, si un module est utile pour la sécurité, il ne faut pas l'enlever. Je parle vraiment des modules chargés qui sont totalement inutiles et pour l'application et pour la sécurité.

MicP

Re : Apache détecter modules inutilisés

log4j ? jamais entendu parler....

Pourtant, il y a une bannière d'alerte sur fond vert (perso, j'aurai plutôt utilisé un fond de couleur rouge) qui s'affiche tout en haut de la page web dont tu as donné le lien dans ton message,
dans laquelle on peut lire :  URGENT MESSAGE: Log4j Zero-Day Vulnerability Response| Learn more

… éviter les liens qui demande une inscription avec tout un tas d'informations personnelles pour accéder à une documentation. …

Les liens que j'ai transmis proviennent de site web du Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques
et bien sûr, il n'y a JAMAIS eu AUCUNE demande d'inscription ou d'informations personnelles à donner pour pouvoir accéder à tous les documents qu'ils diffusent.

Dernière modification par MicP (Le 04/01/2022, à 09:21)

bruno

Re : Apache détecter modules inutilisés

@MicP : il s'agissait du lien de Vobul et non du tien
Ceci dit la référence à log4j est hors-sujet.

MicP

Re : Apache détecter modules inutilisés

… Ceci dit la référence à log4j est hors-sujet. …

Je n'en serai pas si sûr étant donné que :

…L'approche de réduction de la surface d'attaque est tout à fait valide. Mais la sécurité, il faut la mettre partout.…
…J'ai installé une application de transfert de fichier …

bruno

Re : Apache détecter modules inutilisés

Et où as-tu vu que cette application est en Java et a fortiori utilise la bibliothèque log4j ?
La question de Nico89 porte sur les extensions d'Apache (cf. ma réponse en #5), le reste ce sont des supputations.

MicP

Re : Apache détecter modules inutilisés

Où as-tu vu que cette application n'utilisait pas java, et qu'elle n'utilise pas la bibliothèque log4j
et d'autre part :

… il n'est a priori pas possible de connaître exactement les modules Apache inutilisés. …

La question de Nico89 a pour but de :

… comment sécuriser apache, et je souhaiterais approfondir l'une d'entre-elle. En effet, l'idée de cette solution est de réduire "la surface d'attaque" …

Dernière modification par MicP (Le 03/01/2022, à 18:12)

Nico89

Re : Apache détecter modules inutilisés

Re-,
L'application en question est "Jirafeau" (https://gitlab.com/mojo42/Jirafeau)
J'avais posté un sujet il y a quelques semaines ici https://forum.ubuntu-fr.org/viewtopic.php?id=2067645
Du coup, n'ayant pas forcément d'éléments pour choisir, je me suis lancé avec Jirafeau (c'est le seul que j'ai réussi à installer presque seul, j'ai eu un peu d'aide )

Quand je liste les modules chargés, j'ai :

xxxx@xxxx:/var/www/html/Jirafeau/lib $ sudo apache2ctl -M
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Loaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 access_compat_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 filter_module (shared)
 mime_module (shared)
 mpm_prefork_module (shared)
 negotiation_module (shared)
 php_module (shared)
 reqtimeout_module (shared)
 setenvif_module (shared)
 status_module (shared)
xxxx@xxxx:/var/www/html/Jirafeau/lib

Si vous pensez qu'il n'est pas nécessaire de chercher à désactiver les modules non essentiels, je ne suis pas focalisé sur cette idée.

Comme cela a été évoqué par Vobul, il me semble plus important de concentrer les efforts de sécurité sur la configuration d'Apache et de ses modules, et surtout sur les applications web hébergées qui sont toujours le maillon faible qui sera attaqué en premier.

Je prends tout conseils.
Quand on tape "sécuriser apache" sur un moteur de recherche vous tombez sur tout un tas de tutos, forum, et de "conseils". Sur l'un d'entre-eux, l'auteur évoquait l'idée de réduire la surface d'attaque et l'idée m'a paru intéressante. J'ai voulu approfondir, sauf que je n'ai pas trouvé beaucoup d'autres informations sur le sujet et surtout de "mise en application", d'où ma question ici.
Maintenant, l'auteur de Jirafeau évoque aussi plusieurs "conseils" de sécurité, mais ne donne pas forcément beaucoup d'informations pour les mettre en oeuvre. J'imagine, que lorsqu'on a un peu l'habitude ces solutions sont banales, à l'inverse ça demande un peu de recherche :

var directory contains all files and links. It is randomly named to limit access but you may add better protection to prevent un-authorized access to it.
You have several options:

1] Configure a .htaccess
2] Move var folder to a place on your server which can't be directly accessed
3] Disable automatic listing on your web server config or place a index.html in var's sub-directory (this is a limited solution)

4] If you are using Apache, you can add the following line to your configuration to prevent people to access to your var folder:
RedirectMatch 301 ^/var-.* http://my.service.jirafeau

5] You should also remove un-necessessary write access once the installation is done (ex: configuration file).
6] An other obvious basic security is to let access users to the site by HTTPS (make sure web_root in you config.local.php is set with https).

Par exemple, dans le 2], il dit de mettre déplacer le répertoire /var dans un autre pas directement accessible. Que veux-t-il dire par là ?
/var fait parti des répertoires racines, je ne pense pas qu'on puisse déplacer comme ça ce répertoire ?
Bonne soirée

Dernière modification par Nico89 (Le 03/01/2022, à 23:57)

bruno

Re : Apache détecter modules inutilisés

C'est une application en PHP et les remarques sur log4j étaient donc tout à fait déplacées.

La liste des modules correspond à ce qui est installé par défaut sur une configuration basique. Je ne vois aucune raison d'en désactiver certains.
Méfie-toi des tutoriels pour « sécuriser Apache » ou « sécuriser un serveur », c'est rarement pertinent.

Je reprends les points que tu évoques :

1. configurer un .htaccess : tel qule cela n'apporte aucune sécurité, tout dépends de ce qu'on y met et quand on la main sur le serveur mieux vaut faire la configuration dans le fichier d'hôte virtuel et désactiver les htaccess( performances)

2. si un dossier contient des données qui ne doivent pas être accessibles via un navigateur web, le mieux est effectivement de le mettre en dehors du dossier racine du serveur (DocumentRoot). Je ne sais pas à quoi correspond ce dossier var-, mais en tout cas pas au /var du système !

3. c'est une précaution de base qui doit être prise au niveau des hôtes virtuels :

<Directory /dossier/racine/>
  …
  Options -Indexes
  …
</Directory>

4. totalement inutile si le point 2 a été suivi

5. C'est également une précaution de base: les droits d'accès doivent être définis à minima. Dans ton cas c'est l'utilisateur www-data qui exécute les scripts PHP,  les fichiers et dossier doivent donc lui appartenir avec un accès en lecture et éventuellement en écriture et aucun droits pour les autres utilisateurs.

Nico89

Re : Apache détecter modules inutilisés

Bonjour,

Méfie-toi des tutoriels pour « sécuriser Apache » ou « sécuriser un serveur », c'est rarement pertinent.

Le problème pour quelqu'un comme moi c'est de faire le tri entre les bons et les moins bons conseils.
Voici les 3 premiers sites sur lesquels je tombe quand je rentre "sécuriser apache" :
https://www.simplercomputing.net/commen … ur-apache/
https://www.installerunserveur.com/securisation-apache2
https://geekflare.com/fr/apache-web-ser … -security/

D'ailleurs c'est sur le premier site que l'auteur évoque le fait de diminuer la "surface d'attaque".
Alors quand je vois un conseil qui revient sur plusieurs site, généralement, c'est qu'il n'est pas trop déconnant.

1. configurer un .htaccess : tel qule cela n'apporte aucune sécurité, tout dépends de ce qu'on y met et quand on la main sur le serveur mieux vaut faire la configuration dans le fichier d'hôte virtuel et désactiver les htaccess( performances)

Du coup, j'ai recherché la commande, il faut mettre la directive "AllowOverride None" dans le fichier de configuration d'apache.
Je pense qu'il s'agit de ce fichier : /etc/apache2/apache2.conf

# not allow access to the root filesystem outside of /usr/share and /var/www.
# The former is used by web applications packaged in Debian,
# the latter may be used for local directories served by the web server. If
# your system is serving content from a sub-directory in /srv you must allow
# access here, or in any related virtual host.
<Directory />
        Options FollowSymLinks
        AllowOverride None
        Require all denied
</Directory>

<Directory /usr/share>
        AllowOverride None
        Require all granted
</Directory>

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

#<Directory /srv/>
#       Options Indexes FollowSymLinks
#       AllowOverride None
#       Require all granted
#</Directory>

Sauf erreur de ma part, les fichiers .htaccess sont déjà désactivé par défaut ?
(https://haydenjames.io/disable-htaccess … rformance/)

2. si un dossier contient des données qui ne doivent pas être accessibles via un navigateur web, le mieux est effectivement de le mettre en dehors du dossier racine du serveur (DocumentRoot). Je ne sais pas à quoi correspond ce dossier var-, mais en tout cas pas au /var du système !

Effectivement, le répertoire var-xxxxxx (xxxxxx, une suite de lettre aléatoire), est le répertoire où sont stockées les données à transférer.
Du coup, où faudrait-il le déplacer ?

ps : DocumentRoot => https://web.mit.edu/rhel-doc/4/RH-DOCS/ … onfig.html

3. c'est une précaution de base qui doit être prise au niveau des hôtes virtuels :

Tu évoques les fichiers de configuration des hôtes virtuels. Il s'agit bien de ce répertoire /etc/apache2/sites-available ?
Si oui à l'intérieur, j'ai deux fichiers
_000-default.conf = > port 80
_default-ssl.conf => port 443

Tout à l'air vierge dans ces fichiers, j'imagine que c'est ici qu'il va falloir que je rajoute des choses avec l'option "Options -Indexes".
Pour le moment je ne travaille que sur http, du coup, je ne travaille que sur le fichier "000-default.conf" ?

5. C'est également une précaution de base: les droits d'accès doivent être définis à minima. Dans ton cas c'est l'utilisateur www-data qui exécute les scripts PHP,  les fichiers et dossier doivent donc lui appartenir avec un accès en lecture et éventuellement en écriture et aucun droits pour les autres utilisateurs.

pi@raspberrypi:/var/www/html $ ls -l
total 16
-rw-r--r-- 1 root     root     10701 déc.  22 09:34 index.html
drwxr-xr-x 9 www-data www-data  4096 déc.  23 22:26 Jirafeau
xxxx@xxxx:/var/www/html $ cd Jirafeau/
xxxx@xxxx:/var/www/html/Jirafeau $ ls -l
total 140
-rw-r--r-- 1 www-data www-data 11875 déc.  20 17:13 admin.php
-rw-r--r-- 1 www-data www-data  7711 déc.  20 17:13 CHANGELOG.md
-rw-r--r-- 1 www-data www-data   146 déc.  20 17:13 composer.json
-rw-r--r-- 1 www-data www-data  5728 déc.  20 17:13 CONTRIBUTING.md
drwxr-xr-x 2 www-data www-data  4096 déc.  20 17:13 docker
-rw-r--r-- 1 www-data www-data  1153 déc.  20 17:13 Dockerfile
-rw-r--r-- 1 www-data www-data 10849 déc.  20 17:13 f.php
-rw-r--r-- 1 www-data www-data 10234 déc.  20 17:13 index.php
-rw-r--r-- 1 root     root      8196 déc.  23 19:15 install.php
-rw-r--r-- 1 root     root      8196 déc.  22 15:14 install.php.bak
drwxr-xr-x 4 www-data www-data  4096 janv.  3 10:29 lib
drwxr-xr-x 2 www-data www-data  4096 déc.  20 17:13 LICENSES
drwxr-xr-x 8 www-data www-data  4096 déc.  20 17:13 media
-rw-r--r-- 1 www-data www-data 14097 déc.  20 17:13 README.md
-rw-r--r-- 1 www-data www-data 14110 déc.  20 17:13 script.php
-rw-r--r-- 1 www-data www-data  1359 déc.  20 17:13 tos.php
drwxr-xr-x 5 www-data www-data  4096 déc.  22 13:52 var-BvWES6kPlgbewEq
xxxx@xxxx:/var/www/html/Jirafeau $

A priori, il n'y a que root et www-data comme utilisateurs
En revanche tous les fichiers sont en lecture-écriture pour l'utilisateur www-data.

Dernière modification par Nico89 (Le 05/01/2022, à 15:36)

bruno

Re : Apache détecter modules inutilisés

Je t'invite à lire la doc apache2. Tu y trouveras pas mal d'informations.

Juste deux remarques :
- en principe on ne touche pas au fichiers apache2.conf, la configuration se fait dans les fichiers d'hôtes virtuels.
- les fichiers d'un site Web, surtout si ce sont de scripts, ne doivent jamais appartenir à root.

Nico89

Re : Apache détecter modules inutilisés

J'avais été voir la doc quand j'ai débuté mon projet, mais j'en était pas à ce niveau là. Je vais re-potasser la doc.
En ce qui concerne le répertoire var-xxxxx avez-vous une idée ou le déplacer ou pas du tout ?

Vobul

Re : Apache détecter modules inutilisés

- les fichiers d'un site Web, surtout si ce sont de scripts, ne doivent jamais appartenir à root.

Je m'inscris en faux. C'est justement une bonne chose qu'ils appartiennent à root car seul root pourra les modifier. Ce qui est important c'est qu'ils soient lisibles par www-data, writable par root seulement, et executables par personne. Donc au final c'est surtout les permissions qui sont importantes, moins l'appartenance.

Bruno, as-tu une raison pour affirmer qu'ils ne doivent pas appartenir à root ? Est-ce que tu as un autre utilisateur genre "php-owner" (qui n'est pas www-data) pour own les fichiers ?

---

Vobul
Utilisez le retour utilisable de commandes !!!
J'aime la langue française, mais je parle franglais, deal with it.
RTFM

bruno

Re : Apache détecter modules inutilisés

Bruno, as-tu une raison pour affirmer qu'ils ne doivent pas appartenir à root ? Est-ce que tu as un autre utilisateur genre "php-owner" (qui n'est pas www-data) pour own les fichiers ?

Si par malheur ton application PHP présente une faille de sécurité permettant une injection de code, ce code pourra éventuellement donner un accès root. Je ne développe pas, le problème a déjà été discuté ici.

Quant au bit d’exécution, à la limite peu importe qu'il soit présent ou nom puisqu'il est toujours possible d'exécuter un fichier en appelant son interpréteur (dans ce cas php fichier.php). Ce qui est important ce sont surtout les droits de lecture et d'écriture.
Pour un maximum de sécurité l'utilisateur qui exécute les scripts PHP (ici www-data) ne devrait avoir un accès en écriture que que sur les dossiers où c'est nécessaire. Malheureusement pour pas mal de CMS qui proposent des fonctionnalités de mises à jour plus ou moins automatisés (WordPress) c'est nécessaire partout.

Effectivement le mieux est d'avoir un utilisateur différent , sans login, bloqué dans son dossier et qui n'est pas www-data, pour chaque site web. Mais cela sort largement du cadre de cette discussion.

Vobul

Re : Apache détecter modules inutilisés

Désolé Nico89 pour le troll mais bon, c'est la vie

Bruno, j'ai l'impression que tu te contredis, non ?

- ne pas rendre www-data propriétaire du dossier /var/www qui est son $HOME. Ce dossier doit appartenir à root.

Moi je comprends ça comme "/var/www" appartient à root comme tout ce qu'il y a dedans. Donc /var/www/index.php est own by root:root en 644. (On oublie les trucs de wordpress et dossiers d'uploads là, pour simplifier)

Si par malheur ton application PHP présente une faille de sécurité permettant une injection de code

Ben le code sera exécuté par www-data, pas le owner du fichier, donc ça marche pas ton truc. À moins qu'un truc m'échappe !

Après perso mes fichiers sont dans des containers docker donc y'a encore une layer de séparation mais je tiens à éclaircir ce point car c'est pas vraiment clair au final tout ça...

Sinon je suis bien d'accord avec tout le reste de ce que tu dis dans le fil dont tu donnes le lien en #18

---

Vobul
Utilisez le retour utilisable de commandes !!!
J'aime la langue française, mais je parle franglais, deal with it.
RTFM

bruno

Re : Apache détecter modules inutilisés

Regarde bien la démonstration faite dans la vidéo qui est dans le lien en #18 pour comprendre ce qu'il est possible de faire lorsqu'on obtient un shell utilisateur (www-data par exemple ) et que cet utilisateur est propriétaire d'un dossier qui contient des trucs appartenant à root.

Certains adminsys ou développeurs ignorent ou ont oublié que lorsqu'un utilisateur à les droits d'écriture sur un dossier, il peut y renommer ou supprimer n'importe quel fichier même s'il n'en est pas le propriétaire.

Par exemple, si j'obtiens un shell www-data, je peux renommer un truc.php qui appartient à root, car le dossier parent appartient à www-data, créer un nouveau fichier truc.php et y mettre le code que je veux.
Effectivement obtenir un accès root c'est plus complexe

De manière plus intuitive : il n'y a aucune raison que les fichiers d'un site web appartiennent à root.

Dernière modification par bruno (Le 06/01/2022, à 16:27)

Vobul

Re : Apache détecter modules inutilisés

Okay oui j'avoue que je n'ai pas regardé la vidéo, mais bon ça me semble bizarre d'avoir un dossier own by www-data avec des fichiers root dedans, disons qu'il y a déjà un problème à la base là !

Mais je note dans un coin de ma tête ce cas de figure !

---

Vobul
Utilisez le retour utilisable de commandes !!!
J'aime la langue française, mais je parle franglais, deal with it.
RTFM