Dans la partie précédente, nous avons audité le système, les comptes utilisateurs et les mises à jour de sécurité. Dans ce chapitre, nous nous pencherons de plus près sur la configuration des services lancés sur la machine. Nous verrons ainsi que la configuration de chacun de ces services doit être auditée de manière indépendante.
Dans le chapitre 3 de la partie 2, vous aviez lancé deux commandes importantes permettant de :
lister les services lancés automatiquement lors du démarrage de la machine :
[root@fichesproduits ~]# ls -lrtha /etc/systemd/system/multi-user.target.wants/ total 8,0K lrwxrwxrwx. 1 root root 40 27 mars 09:30 remote-fs.target -> /usr/lib/systemd/system/remote-fs.target lrwxrwxrwx. 1 root root 46 27 mars 09:30 rhel-configure.service -> /usr/lib/systemd/system/rhel-configure.service lrwxrwxrwx. 1 root root 37 27 mars 09:30 crond.service -> /usr/lib/systemd/system/crond.service lrwxrwxrwx. 1 root root 46 27 mars 09:30 NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service lrwxrwxrwx. 1 root root 37 27 mars 09:30 tuned.service -> /usr/lib/systemd/system/tuned.service lrwxrwxrwx. 1 root root 42 27 mars 09:30 irqbalance.service -> /usr/lib/systemd/system/irqbalance.service lrwxrwxrwx. 1 root root 39 27 mars 09:30 rsyslog.service -> /usr/lib/systemd/system/rsyslog.service lrwxrwxrwx. 1 root root 37 27 mars 09:30 kdump.service -> /usr/lib/systemd/system/kdump.service lrwxrwxrwx. 1 root root 36 27 mars 09:30 sshd.service -> /usr/lib/systemd/system/sshd.service lrwxrwxrwx. 1 root root 38 27 mars 09:30 auditd.service -> /usr/lib/systemd/system/auditd.service lrwxrwxrwx. 1 root root 39 27 mars 09:30 postfix.service -> /usr/lib/systemd/system/postfix.service lrwxrwxrwx. 1 root root 39 27 mars 09:30 chronyd.service -> /usr/lib/systemd/system/chronyd.service lrwxrwxrwx. 1 root root 39 27 mars 09:46 mariadb.service -> /usr/lib/systemd/system/mariadb.service lrwxrwxrwx. 1 root root 37 27 mars 09:46 httpd.service -> /usr/lib/systemd/system/httpd.service lrwxrwxrwx 1 root root 39 27 mars 09:50 proftpd.service -> /usr/lib/systemd/system/proftpd.service lrwxrwxrwx 1 root root 40 7 mai 18:27 yum-cron.service -> /usr/lib/systemd/system/yum-cron.service
lister les services ainsi que leur état courant. Filtrez cette commande sur le mot-clé enabled pour repérer les services lancés :
[root@fichesproduits ~]# systemctl list-unit-files --type service | grep enabled auditd.service enabled autovt@.service enabled chronyd.service enabled crond.service enabled dbus-org.freedesktop.NetworkManager.service enabled dbus-org.freedesktop.nm-dispatcher.service enabled getty@.service enabled httpd.service enabled irqbalance.service enabled kdump.service enabled lvm2-monitor.service enabled mariadb.service enabled microcode.service enabled NetworkManager-dispatcher.service enabled NetworkManager-wait-online.service enabled NetworkManager.service enabled postfix.service enabled proftpd.service enabled rhel-autorelabel.service enabled rhel-configure.service enabled rhel-dmesg.service enabled rhel-domainname.service enabled rhel-import-state.service enabled rhel-loadmodules.service enabled rhel-readonly.service enabled rsyslog.service enabled sshd.service enabled systemd-readahead-collect.service enabled systemd-readahead-drop.service enabled systemd-readahead-replay.service enabled tuned.service enabled yum-cron.service enabled
Cette commande affiche tous les services lancés à un instant t, sans distinction (services système et services réseau). Le chapitre 3 de la partie 2 vous incitait à supprimer les services inutiles (nous avions pris l'exemple de postfix). Concernant les services utiles, il est nécessaire d'auditer leur configuration afin d'effectuer une opération de durcissement (hardening en anglais). Cette opération consiste à configurer les services pour retarder voire empêcher toute tentative de compromission.
Je vous propose de suivre cet audit pas à pas, dans la vidéo suivante, vous le retrouverez ensuite dans le texte ci-dessous !
Prenons ici l'exemple du service httpd.service. Afin d'afficher son statut global, lancez la commande suivante :
[root@fichesproduits ~]# systemctl status httpd.service ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Active: active (running) since lun. 2019-05-13 07:39:47 CEST; 1h 26min ago Docs: man:httpd(8) man:apachectl(8) Main PID: 817 (httpd) Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec" CGroup: /system.slice/httpd.service ├─817 /usr/sbin/httpd -DFOREGROUND ├─973 /usr/sbin/httpd -DFOREGROUND ├─974 /usr/sbin/httpd -DFOREGROUND ├─975 /usr/sbin/httpd -DFOREGROUND ├─976 /usr/sbin/httpd -DFOREGROUND └─977 /usr/sbin/httpd -DFOREGROUND mai 13 07:39:46 fichesproduits systemd[1]: Starting The Apache HTTP Server... mai 13 07:39:47 fichesproduits systemd[1]: Started The Apache HTTP Server.
Cette commande confirme que le service est bien lancé. Elle indique le fichier unit associé httpd.service, les sections de documentation, le PID du processus principal (ici 817) et la commande exécutée pour lancer ce service. Aucune trace du fichier de configuration du service. Celui-ci est pourtant bien connu : httpd.conf.
Vous pouvez afficher le contenu de ce fichier avec la commande suivante :
[root@fichesproduits ~]# cat /etc/httpd/conf/httpd.conf | grep [a-z] | grep -v "#"
ServerRoot "/etc/httpd"
Listen 80
Include conf.modules.d/*.conf
User apache
Group apache
ServerAdmin root@localhost
<Directory />
AllowOverride none
Require all denied
</Directory>
DocumentRoot "/var/www/html"
<Directory "/var/www">
AllowOverride None
Require all granted
</Directory>
<Directory "/var/www/html">
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
<IfModule dir_module>
DirectoryIndex index.html
</IfModule>
<Files ".ht*">
Require all denied
</Files>
ErrorLog "logs/error_log"
LogLevel warn
<IfModule log_config_module>
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
<IfModule logio_module>
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
</IfModule>
CustomLog "logs/access_log" combined
</IfModule>
<IfModule alias_module>
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
</IfModule>
<Directory "/var/www/cgi-bin">
AllowOverride None
Options None
Require all granted
</Directory>
<IfModule mime_module>
TypesConfig /etc/mime.types
AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
</IfModule>
AddDefaultCharset UTF-8
<IfModule mime_magic_module>
MIMEMagicFile conf/magic
</IfModule>
EnableSendfile on
IncludeOptional conf.d/*.confLe fichier de configuration de HTTPD est sûrement celui par défaut, installé avec le package de la distribution.
Concernant le service HTTPD, vous pouvez déjà relever plusieurs actions prioritaires :
ajoutez les directives ServerTokens Prod et ServerSignature Off pour ne pas afficher la bannière du service, qui renvoie par défaut les informations sur la version du service et son système d'exploitation. Une simple commande telnet ou netcat permet de récupérer ces informations très utiles pour un attaquant :
[root@fichesproduits ~]# nc localhost 80 HEAD / HTTP/1.0 HTTP/1.1 400 Bad Request Date: Mon, 13 May 2019 07:26:27 GMT Server: Apache/2.4.6 (CentOS) PHP/5.4.16 Content-Length: 226 Connection: close Content-Type: text/html; charset=iso-8859-1
pour chaque répertoire, vérifiez la présence de la directive Options -Indexes, qui permet d'empêcher de lister le contenu du répertoire. Ce n'est pas le cas ici pour les répertoires référencés, pire, pour certains elle est même explicitement autorisée :
<Directory "/var/www/html"> Options Indexes FollowSymLinks AllowOverride None Require all granted </Directory>
pour terminer, limitez les méthodes autorisées du protocole HTTP selon votre besoin. La plupart du temps, les méthodes GET, HEAD et POST suffisent largement. Les autres méthodes, OPTIONS, PUT, DELETE, TRACE et CONNECT, induisent des risques inutiles. Vérifiez alors la présence de la directive LimitExcept telle que, par exemple :
<LimitExcept GET POST HEAD> deny from all </LimitExcept>
En résumé
En prenant ici l'exemple du service HTTPD, nous avons pu constater qu'il était nécessaire de durcir sa configuration afin d'augmenter la sécurité liée aux fonctionnalités qu'il propose. Dans le chapitre suivant, nous allons étudier l'impact de ce service sur le système d'exploitation, et voir dans quelle mesure il est nécessaire de modifier sa gestion pour la minimiser.
