Linux 25 meilleures pratiques de sécurité php pour les administrateurs système

PHP est un langage de script côté serveur à code source ouvert, et c'est un langage largement utilisé. Le serveur web Apache/Nginx/Lighttpd permet d'accéder aux fichiers et au contenu via le protocole HTTP OU HTTPS. Un langage de script côté serveur mal configuré peut créer toutes sortes de problèmes. PHP doit donc être utilisé avec prudence. Voici vingt-cinq meilleures pratiques de sécurité en php pour les administrateurs système de Linux et d'Unix pour configurer PHP de manière sécurisée.

Meilleures pratiques de sécurité en PHP

Notre exemple de configuration pour les conseils de sécurité de PHP

• DocumentRoot : /var/www/html
• Serveur Web par défaut : Apache ( vous pouvez utiliser Lighttpd ou Nginx à la place d'Apache)
• Fichier de configuration PHP par défaut : /etc/php.ini ou /etc/php/7.0/fpm/php.ini
• Répertoire de configuration des extensions PHP par défaut : /etc/php.d/ OU /etc/php/7.0/fpm/conf.d/
• Notre exemple de fichier de configuration de sécurité php : /etc/php.d/security.ini OU /etc/php/7.0/fpm/conf.d/99-security.conf (vous devez créer ce fichier en utilisant un éditeur de texte)
• Systèmes d'exploitation : RHEL / CentOS / Fedora Linux (les instructions devraient fonctionner avec toute autre distribution Linux comme Debian / Ubuntu ou autre Unix comme les systèmes d'exploitation tels que OpenBSD/FreeBSD/HP-UX).
• Ports TCP/UDP du serveur PHP par défaut : aucun

La plupart des actions énumérées dans cet article sont écrites en supposant qu'elles seront exécutées par l'utilisateur root qui exécute le shell bash ou tout autre shell moderne :

PHP 5.3.3 (cli) (built: Oct 24 2011 08:35:41)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

OU

PHP 7.3.7 (cli) (built: Jul  8 2019 09:58:12) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.7, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.7, Copyright (c) 1999-2018, by Zend Technologies

Pour la démonstration, je vais utiliser le système d'exploitation suivant :

Red Hat Enterprise Linux Server release 6.1 (Santiago)

Voyons quelques unes des meilleures pratiques de sécurité de php.

1. Connaître son ennemi

Les applications basées sur PHP peuvent être confrontées à différents types d'attaques. J'ai remarqué les différents types d'attaques :

1. XSS - Le scripting intersite est une vulnérabilité des applications web php, que les attaquants peuvent exploiter pour voler les informations des utilisateurs. Vous pouvez configurer Apache et écrire des scripts PHP plus sûrs (validant toutes les entrées utilisateur) pour éviter les attaques xss.
2. Injection SQL - Il s'agit d'une vulnérabilité dans la couche base de données d'une application php. Lorsque l'entrée de l'utilisateur est incorrectement filtrée, des instructions SQL peuvent être exécutées par l'application. Vous pouvez configurer Apache et écrire du code sécurisé (validation et échappement de toutes les entrées utilisateur) pour éviter les attaques par injection SQL. Une pratique courante en PHP consiste à échapper les paramètres à l'aide de la fonction appelée mysql_real_escape_string() avant d'envoyer la requête SQL.
   Usurpation d'identité
3. Téléchargement de fichiers - Il permet à votre visiteur de placer des fichiers (téléchargement de fichiers) sur votre serveur. Cela peut entraîner divers problèmes de sécurité tels que la suppression de vos fichiers, la suppression de la base de données, l'obtention de détails sur l'utilisateur et bien plus encore. Vous pouvez désactiver les téléchargements de fichiers à l'aide de php ou écrire un code sécurisé (comme la validation de l'entrée de l'utilisateur et l'autorisation d'un type de fichier image tel que png ou gif).
4. Inclure les fichiers locaux et distants - Un attaquant peut ouvrir les fichiers d'un serveur distant et exécuter n'importe quel code PHP. Cela lui permet de télécharger des fichiers, de les supprimer et d'installer des portes dérobées. Vous pouvez configurer php pour désactiver l'exécution de fichiers à distance.
5. eval() - Évaluer une chaîne de caractères en tant que code PHP. Ceci est souvent utilisé par un attaquant pour cacher son code et ses outils sur le serveur lui-même. Vous pouvez configurer php pour désactiver eval().
6. Attaque de surf de mer (Cross-site request forgery - CSRF) - Cette attaque force un utilisateur final à exécuter des actions non désirées sur une application web dans laquelle il est actuellement authentifié. Un exploit CSRF réussi peut compromettre les données et les opérations de l'utilisateur final dans le cas d'un utilisateur normal. Si l'utilisateur final visé est le compte administrateur, cela peut compromettre l'ensemble de l'application web.

2. Trouver les modules PHP intégrés

Pour voir l'ensemble des modules PHP compilés, tapez la commande suivante :

[PHP Modules]
apc
bcmath
bz2
calendar
Core
ctype
curl
date
dom
ereg
exif
fileinfo
filter
ftp
gd
gettext
gmp
hash
iconv
imap
json
libxml
mbstring
memcache
mysql
mysqli
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
readline
Reflection
session
shmop
SimpleXML
sockets
SPL
sqlite3
standard
suhosin
tokenizer
wddx
xml
xmlreader
xmlrpc
xmlwriter
xsl
zip
zlib

[Zend Modules]
Suhosin

Je vous recommande d'utiliser PHP avec un nombre réduit de modules pour des raisons de performance et de sécurité. Par exemple, vous pouvez désactiver le module sqlite3 en supprimant le fichier de configuration , OU en renommant (déplaçant) le fichier /etc/php.d/sqlite3.ini comme suit :

./configure --with-libdir=lib64 --with-gd --with-mysql --prefix=/usr --exec-prefix=/usr 
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share 
--includedir=/usr/include --libexecdir=/usr/libexec --localstatedir=/var 
--sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info 
--cache-file=../config.cache --with-config-file-path=/etc 
--with-config-file-scan-dir=/etc/php.d  --enable-fastcgi 
--enable-force-cgi-redirect

Voir Comment compiler et réinstaller php sur un système d'exploitation de type Unix ? pour plus d'informations.

3. Limiter la fuite d'informations PHP

Pour restreindre la fuite d'informations PHP, désactivez expose_php. Editez /etc/php.d/secutity.ini et définissez la directive suivante :

expose_php=Off

Lorsqu'il est activé, expose_php signale au monde entier que PHP est installé sur le serveur, ce qui inclut la version de PHP dans l'en-tête HTTP (par exemple, X-Powered-By : PHP/5.3.3). Les guides du logo PHP (voir exemple ) sont également exposés, donc les ajouter à l'URL d'un site compatible avec PHP affichera le logo approprié. Lorsque expose_php est activé, vous pouvez voir la version de php en utilisant la commande suivante :

HTTP/1.1 200 OK
X-Powered-By: PHP/5.3.3
Content-type: text/html; charset=UTF-8
Vary: Accept-Encoding, Cookie
X-Vary-Options: Accept-Encoding;list-contains=gzip,Cookie;string-contains=wikiToken;string-contains=wikiLoggedOut;string-contains=wiki_session
Last-Modified: Thu, 03 Nov 2011 22:32:55 GMT
...

Je vous recommande également de configurer les directives ServerTokens et ServerSignature dans httpd.conf pour masquer la version d'Apache et masquer la version de PHP 5/7 lorsque vous utilisez Nginx.

4. Minimiser les modules PHP chargeables (extensions dynamiques)

PHP supporte les "Extensions dynamiques". Par défaut, RHEL charge tous les modules d'extension trouvés dans le répertoire /etc/php.d/. Pour activer ou désactiver un module particulier, il suffit de trouver le fichier de configuration dans le répertoire /etc/php.d/ et de commenter le nom du module. Vous pouvez également renommer ou supprimer le fichier de configuration du module. Pour une meilleure performance et sécurité de PHP, vous ne devez activer que les extensions dont vos applications web ont besoin. Par exemple, pour désactiver l'extension gd, tapez les commandes suivantes :

5. Enregistrer toutes les erreurs PHP

N'exposez pas les messages d'erreur PHP à tous les visiteurs du site. Editez /etc/php.d/security.ini et définissez la directive suivante :

display_errors=Off

Assurez-vous de consigner toutes les erreurs php dans un fichier journal :

log_errors=On
error_log=/var/log/httpd/php_scripts_error.log

6. Interdire le téléchargement de fichiers

Modifiez le fichier /etc/php.d/security.ini et définissez la directive suivante pour désactiver le téléchargement de fichiers pour des raisons de sécurité :

file_uploads=Off

Si les utilisateurs de votre application ont besoin de télécharger des fichiers, activez cette fonctionnalité en définissant upload_max_filesize ; cela limite la taille maximale des fichiers que PHP acceptera de télécharger :

file_uploads=On
# user can only upload upto 1MB via php
upload_max_filesize=1M

7. Désactiver l'exécution de code à distance

S'il est activé, allow_url_fopen permet aux fonctions de fichiers de PHP - comme file_get_contents() et les instructions include et require - de récupérer des données à partir d'emplacements distants, comme un site FTP ou web.

L'option allow_url_fopen permet aux fonctions de fichiers de PHP - comme file_get_contents() et les instructions include et require - de récupérer des données à partir d'emplacements distants en utilisant les protocoles ftp ou http. Les programmeurs l'oublient souvent et ne filtrent pas correctement les entrées lorsqu'ils transmettent des données fournies par l'utilisateur à ces fonctions, ce qui les rend vulnérables au code. vulnérabilités d'injection . Un grand nombre de vulnérabilités par injection de code signalées dans les applications web basées sur PHP sont causées par la combinaison de l'activation de allow_url_fopen et d'un mauvais filtrage des entrées. Editez /etc/php.d/security.ini et définissez la directive suivante :

allow_url_fopen=Off

Je recommande également de désactiver allow_url_include pour des raisons de sécurité :

allow_url_include=Off

8. Activer le mode sans échec de SQL

Modifiez le fichier /etc/php.d/security.ini et définissez la directive suivante :

sql.safe_mode=On

Si cette option est activée, mysql_connect() et mysql_pconnect() ignorent les arguments qui leur sont passés. Veuillez noter que vous devrez peut-être apporter quelques modifications à votre code. Les applications tierces et open source telles que WordPress, et autres peuvent ne pas fonctionner du tout lorsque sql.safe_mode est activé. Je vous recommande également de désactiver cotes_magiques_gpc pour toutes les installations php 5.3.x car le filtrage qu'il permet est inefficace et peu robuste. mysql_escape_string() et les fonctions de filtrage personnalisées sont plus efficaces :

magic_quotes_gpc=Off

9. Contrôle de la taille des POST

La méthode de requête HTTP POST est utilisée lorsque le client (navigateur ou utilisateur) doit envoyer des données au serveur web Apache dans le cadre de la requête, par exemple lors du téléchargement d'un fichier ou de la soumission d'un formulaire rempli. Les attaquants peuvent tenter d'envoyer des requêtes POST surdimensionnées pour consommer les ressources de votre système. Vous pouvez limiter la taille maximale des requêtes POST que PHP peut traiter. Editez /etc/php.d/security.ini et définissez la directive suivante :

; Set a realistic value here
post_max_size=1K

Le 1K définit la taille maximale des données du message autorisée par les applications php. Ce paramètre affecte également le téléchargement de fichiers. Pour télécharger des fichiers volumineux, cette valeur doit être supérieure à upload_max_filesize. Je vous suggère également de limiter les méthodes disponibles en utilisant le serveur web Apache. Editez httpd.conf et définissez la directive suivante pour DocumentRoot /var/www/html :

    
        Order allow,deny
    
## Add rest of the config goes here... ##

10. Contrôle des ressources (contrôle DoS)

Vous pouvez définir la durée maximale d'exécution de chaque script php, en secondes. Une autre option recommandée est de définir le temps maximum que chaque script peut passer à analyser les données de la requête, et la quantité maximum de mémoire qu'un script peut consommer. Modifiez le fichier /etc/php.d/security.ini et définissez les directives suivantes :

# set in seconds
max_execution_time =  30
max_input_time = 30
memory_limit = 40M

11. Installer Suhosin Advanced Protection System pour PHP

De la page du projet :

Suhosin est un système de protection avancé pour les installations PHP. Il a été conçu pour protéger les serveurs et les utilisateurs des failles connues et inconnues des applications PHP et du noyau PHP. Suhosin se compose de deux parties indépendantes, qui peuvent être utilisées séparément ou en combinaison. La première partie est un petit patch contre le noyau PHP, qui implémente quelques protections de bas niveau contre les débordements de tampon ou les vulnérabilités de chaîne de format et la seconde partie est une puissante extension PHP qui implémente toutes les autres protections.

Voir comment installer et configurer suhosin sous les systèmes d'exploitation Linux.

12. Désactiver les fonctions PHP dangereuses

PHP possède de nombreuses fonctions qui peuvent être utilisées pour pirater votre serveur si elles ne sont pas utilisées correctement. Vous pouvez définir la liste des fonctions dans /etc/php.d/security.ini en utilisant la directive disable_functions :

disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

13. PHP Fastcgi / CGI - Directive cgi.force_redirect

PHP fonctionne avec FastCGI. Fascgi réduit l'empreinte mémoire de votre serveur web, tout en vous offrant la vitesse et la puissance de l'ensemble du langage PHP. Vous pouvez configurer Apache2 PHP FastCGI ou cgi comme décrit ici. La directive de configuration cgi.force_redirect empêche quiconque d'appeler PHP directement avec une URL comme http://www.hebergementwebgratuit.com/cgi-bin/php/hackerdir/backdoor.php. Activez cgi.force_redirect pour des raisons de sécurité. Editez /etc/php.d/security.ini et définissez la directive suivante :

; Enable cgi.force_redirect for security reasons in a typical *Apache+PHP-CGI/FastCGI* setup
cgi.force_redirect=On

14. ID de l'utilisateur et du groupe PHP

mod_fastcgi est un module cgi pour le serveur web Apache. Il peut se connecter à un serveur FASTCGI externe. Vous devez vous assurer que php s'exécute en tant qu'utilisateur non-root. Si PHP s'exécute en tant que root ou UID inférieur à 100, il peut accéder et/ou manipuler des fichiers système. Vous devez exécuter les CGI PHP en tant qu'utilisateur non privilégié en utilisant suEXEC d'Apache ou mod_suPHP . La fonction suEXEC permet aux utilisateurs d'Apache d'exécuter des programmes CGI sous des identifiants différents de celui du serveur web appelant. Dans cet exemple, mon php-cgi est exécuté en tant qu'utilisateur phpcgi et apache en tant qu'utilisateur apache :

phpcgi      6012  0.0  0.4 225036 60140 ?        S    Nov22   0:12 /usr/bin/php-cgi
phpcgi      6054  0.0  0.5 229928 62820 ?        S    Nov22   0:11 /usr/bin/php-cgi
phpcgi      6055  0.1  0.4 224944 53260 ?        S    Nov22   0:18 /usr/bin/php-cgi
phpcgi      6085  0.0  0.4 224680 56948 ?        S    Nov22   0:11 /usr/bin/php-cgi
phpcgi      6103  0.0  0.4 224564 57956 ?        S    Nov22   0:11 /usr/bin/php-cgi
phpcgi      6815  0.4  0.5 228556 61220 ?        S    00:52   0:19 /usr/bin/php-cgi
phpcgi      6821  0.3  0.5 228008 61252 ?        S    00:55   0:12 /usr/bin/php-cgi
phpcgi      6823  0.3  0.4 225536 58536 ?        S    00:57   0:13 /usr/bin/php-cgi

Vous pouvez utiliser un outil tel que spawn-fcgi pour lancer des processus FastCGI locaux et distants en tant qu'utilisateur phpcgi (ajoutez d'abord l'utilisateur phpcgi au système) :

15. Limiter l'accès de PHP au système de fichiers

La directive open_basedir définit les répertoires à partir desquels PHP est autorisé à accéder aux fichiers en utilisant des fonctions comme fopen(), et autres. Si un fichier est en dehors des chemins définis par open_basdir, PHP refusera de l'ouvrir. Vous ne pouvez pas utiliser un lien symbolique comme solution de contournement. Par exemple, n'autorisez l'accès qu'au répertoire /var/www/html et pas aux répertoires /var/www, ou /tmp ou /etc :

; Limits the PHP process from accessing files outside
; of specifically designated directories such as /var/www/html/
open_basedir="/var/www/html/"
; ------------------------------------
; Multiple dirs example
; open_basedir="/home/httpd/vhost/cyberciti.biz/html/:/home/httpd/vhost/nixcraft.com/html/:/home/httpd/vhost/theos.in/html/"
; ------------------------------------

16. Chemin de la session

Le support des sessions en PHP consiste en un moyen de préserver certaines données lors des accès ultérieurs. Cela vous permet de construire des applications plus personnalisées et d'augmenter l'attrait de votre site web. Ce chemin est défini dans le fichier /etc/php.ini et toutes les données liées à une session particulière seront stockées dans un fichier dans le répertoire spécifié par l'option session.save_path. La valeur par défaut est la suivante sous RHEL/CentOS/Fedora Linux :

session.save_path="/var/lib/php/session"
; Set the temporary directory used for storing files when doing file upload
upload_tmp_dir="/var/lib/php/session"

Assurez-vous que le chemin est en dehors de /var/www/html et ne peut être lu ou écrit par tout autre utilisateur du système :

drwxrwx---. root apache system_u:object_r:httpd_var_run_t:s0 session

Remarque : L'option -Z de la commande ls affiche le contexte de sécurité SELinux tel que le mode de fichier, l'utilisateur, le groupe, le contexte de sécurité et le nom du fichier.

17. Maintenez PHP, les logiciels et le système d'exploitation à jour.

L'application des correctifs de sécurité est une partie importante de la maintenance des serveurs Linux, Apache, PHP et MySQL. Toutes les mises à jour de sécurité de php doivent être examinées et appliquées dès que possible en utilisant l'un des outils suivants (si vous installez PHP via un gestionnaire de paquets) :

18. Restreindre l'accès aux fichiers et aux répertoires

Assurez-vous que vous exécutez Apache en tant qu'utilisateur non-root tel que Apache ou www. Tous les fichiers et répertoires doivent appartenir à l'utilisateur non-root (ou à l'utilisateur apache) sous /var/www/html :

Assurez-vous que les autorisations de fichiers sont définies sur 0444 (lecture seule) sous /var/www/html/ :

Une note sur la mise en place de permissions de fichiers correctes

Les commandes chown et chmod permettent de s'assurer qu'en aucun cas, DocumentRoot ou les fichiers contenus dans DocumentRoot ne sont accessibles en écriture par l'utilisateur apache du serveur Web. Veuillez noter que vous devez définir les permissions qui ont le plus de sens pour le modèle de développement de votre site Web, donc n'hésitez pas à ajuster la commande chown et chmod en fonction de vos besoins. Dans cet exemple, le serveur Apache est exécuté en tant qu'utilisateur apache. Celui-ci est configuré avec la commande Utilisateur et Groupe dans votre fichier httpd.conf. L'utilisateur apache doit avoir un accès en lecture à tout ce qui se trouve sous DocumentRoot mais ne doit pas avoir un accès en écriture à quoi que ce soit.

Assurez-vous que le fichier httpd.conf contient les directives suivantes pour une configuration restrictive :

    Options None
    AllowOverride None
    Order allow,deny

Vous ne devez accorder l'accès en écriture que lorsque cela est nécessaire. Certaines applications web telles que wordpress et autres peuvent avoir besoin d'un répertoire de mise en cache. Vous pouvez accorder un accès en écriture au répertoire de mise en cache en utilisant les commandes suivantes :

19. Écrire pour protéger les fichiers de configuration d'Apache, de PHP et de MySQL

Utilisez la commande chattr pour protéger en écriture les fichiers de configuration :

La commande chattr peut protéger en écriture votre fichier php ou les fichiers du répertoire /var/www/html également :

20. Utiliser les extensions de sécurité de Linux (telles que SELinux)

Linux est livré avec divers correctifs de sécurité qui peuvent être utilisés pour se prémunir contre les programmes de serveur mal configurés ou compromis. Si possible, utilisez SELinux et d'autres extensions de sécurité Linux pour imposer des limites au réseau et aux autres programmes. Par exemple, SELinux fournit une variété de politiques de sécurité pour le noyau Linux et le serveur web Apache. Pour lister toutes les variables de protection SELinux d'Apache, entrez :

allow_httpd_anon_write --> off
allow_httpd_mod_auth_ntlm_winbind --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> on
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_read_user_content --> off
httpd_setrlimit --> off
httpd_ssi_exec --> off
httpd_tmp_exec --> off
httpd_tty_comm --> on
httpd_unified --> on
httpd_use_cifs --> off
httpd_use_gpg --> off
httpd_use_nfs --> off

Pour désactiver le support d'Apache cgi, entrez :

21. Installer Mod_security

ModSecurity est un moteur open source de détection et de prévention des intrusions pour les applications web. Vous pouvez facilement installer mod_security sous Linux et protéger les applications basées sur apache et php contre les attaques xss et diverses autres attaques :

## A few Examples ##
# Do not allow to open files in /etc/
SecFilter /etc/
 
# Stop SQL injection
SecFilter "delete[[:space:]]+from"
SecFilter "select.+from"

22. Exécuter Apache / PHP dans une prison chroot si possible

Placer PHP et/ou Apache dans une prison chroot minimise les dommages causés par une intrusion potentielle en isolant le serveur web dans une petite section du système de fichiers. Vous pouvez utiliser une configuration traditionnelle de type chroot avec Apache. Cependant, je recommande les jails FreeBSD, la virtualisation XEN, la virtualisation KVM, ou la virtualisation OpenVZ qui utilise le concept de conteneurs.

23. Utiliser un pare-feu pour restreindre les connexions sortantes

L'attaquant téléchargera le fichier localement sur votre serveur web en utilisant des outils tels que wget. Utilisez iptables pour bloquer les connexions sortantes de l'utilisateur apache. Le module ipt_owner tente de faire correspondre diverses caractéristiques du créateur du paquet, pour les paquets générés localement. Il n'est valable que dans la chaîne OUTPUT. Dans cet exemple, autorisez l'utilisateur vivek à se connecter à l'extérieur en utilisant le port 80 (utile pour l'accès au RHN ou au repo centos) :

/sbin/iptables -A OUTPUT -o eth0 -m owner --uid-owner vivek -p tcp --dport 80 -m state --state NEW,ESTABLISHED  -j ACCEPT

Voici un autre exemple qui bloque toutes les connexions sortantes de l'utilisateur apache, sauf vers notre propre serveur smtp et le service API de validation du spam :

# ....
/sbin/iptables --new-chain apache_user
/sbin/iptables --append OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables --append OUTPUT -m owner --uid-owner apache -j apache_user
# allow apache user to connec to our smtp server
/sbin/iptables --append apache_user -p tcp --syn -d 192.168.1.100 --dport 25 -j RETURN
# Allow apache user to connec to api server for spam validation
/sbin/iptables --append apache_user -p tcp --syn -d  66.135.58.62 --dport 80 -j RETURN
/sbin/iptables --append apache_user -p tcp --syn -d  66.135.58.61 --dport 80 -j RETURN
/sbin/iptables --append apache_user -p tcp --syn -d  72.233.69.89 --dport 80 -j RETURN
/sbin/iptables --append apache_user -p tcp --syn -d  72.233.69.88 --dport 80 -j RETURN
#########################
## Add more rules here ##
#########################
# No editing below
# Drop everything for apache outgoing connection
/sbin/iptables --append apache_user -j REJECT

Voir comment configurer un pare-feu UFW sur un serveur Ubuntu 16.04 LTS (ou la dernière version)

nixcmd [name_missing] - contact @[email protected] avec l'url

24. Surveillez vos journaux

Vérifiez le fichier journal d'apache. Utilisez la commande grep/egrep :

25. Exécuter le service par système ou par instance de VM

Pour les grandes installations, il est recommandé d'exécuter la base de données, le contenu statique et le contenu dynamique sur des serveurs différents.

///////////////
/ ISP/Router /
//////////////
  
   |
   Firewall
     
      |
     +------------+
     | LB01       |
     +------------+                 +--------------------------+
                  |                 | static.lan.cyberciti.biz |
		  +-----------------+--------------------------+
                                    | phpcgi1.lan.cyberciti.biz|
                                    +--------------------------+
                                    | phpcgi2.lan.cyberciti.biz|
                                    +--------------------------+
                                    | mysql1.lan.cyberciti.biz |
                                    +--------------------------+
                                    | mcache1.lan.cyberciti.biz|
                                    +--------------------------+

Exécutez différents services réseau sur des serveurs ou des instances VM distincts. Cela limite le nombre d'autres services qui peuvent être compromis. Par exemple, si un attaquant parvient à exploiter avec succès un logiciel tel que le flux Apache, il/elle aura accès à l'ensemble du serveur, y compris aux autres services fonctionnant sur le même serveur (tels que MySQL, le serveur de messagerie, etc.). Mais, dans l'exemple ci-dessus, le contenu est servi comme suit :

1. statique.lan.hebergementwebgratuit.com - Utilisez un serveur lighttpd ou nginx pour les actifs statiques tels que js/css/images.
2. phpcgi1.lan.hebergementwebgratuit.com et phpcgi2.lan.hebergementwebgratuit.com - Serveur web Apache avec php utilisé pour générer du contenu dynamique.
3. mysql1.lan.hebergementwebgratuit.com - Serveur de base de données MySQL.
4. mcache1.lan.hebergementwebgratuit.com - Le serveur Memcached est un système de mise en cache très rapide pour MySQL. Il utilise libevent ou epoll (runtime Linux) pour s'adapter à un nombre quelconque de connexions ouvertes et utilise des E/S réseau non bloquantes.
5. LB01 - Un serveur web et reverse proxy nginx devant les serveurs web Apache. Toutes les connexions provenant d'Internet et adressées à l'un des serveurs Web sont acheminées par le serveur proxy nginx, qui peut soit traiter la demande lui-même, soit la transmettre entièrement ou partiellement aux serveurs Web principaux. LB01 assure un équilibrage de charge simple.

26. Outils supplémentaires

De la page du projet :

PHPIDS (PHP-Intrusion Detection System) est une couche de sécurité simple à utiliser, bien structurée, rapide et à la pointe de la technologie pour votre application web basée sur PHP. L'IDS ne supprime, ni n'assainit, ni ne filtre aucune entrée malveillante, il reconnaît simplement lorsqu'un attaquant tente de pénétrer dans votre site et réagit exactement comme vous le souhaitez.

Vous pouvez utiliser PHPIDS pour détecter les utilisateurs malveillants, et enregistrer toutes les attaques détectées pour un examen ultérieur. Veuillez noter que je n'ai personnellement pas utilisé cet outil.

De la page du projet :

PhpSecInfo fournit un équivalent de la fonction phpinfo() qui rapporte des informations de sécurité sur l'environnement PHP, et propose des suggestions d'amélioration. Il ne remplace pas les techniques de développement sécurisé, et ne fait pas d'audit de code ou d'application, mais peut être un outil utile dans une approche de sécurité multi-couches.

Fig.01 : Informations sur la sécurité de l'application PHP

Voir les conseils de renforcement de la sécurité de Linux qui peuvent réduire les vecteurs d'attaque disponibles sur le système.

Une note sur les backdoors PHP

Vous pouvez rencontrer des scripts php ou des backdoors dites communes telles que c99, c99madshell, r57, etc. Un script php backdoor n'est rien d'autre qu'un script caché permettant de contourner toute authentification et d'accéder à votre serveur à la demande. Il est installé par un attaquant pour accéder à votre serveur tout en essayant de ne pas être détecté. Généralement, un script PHP (ou tout autre script CGI) permet par erreur l'inclusion de code exploitant des vulnérabilités dans le navigateur web. Un attaquant peut utiliser ces vulnérabilités d'exploitation pour télécharger des shells backdoor qui peuvent lui donner un certain nombre de capacités telles que :

• Fichiers à télécharger
• Télécharger des fichiers
• Installer des rootkits
• Définir un serveur de courrier indésirable / serveur relais
• Configurer un serveur proxy pour masquer les traces
• Prendre le contrôle du serveur
• Prendre le contrôle du serveur de base de données
• Voler toutes les informations
• Supprimer toutes les informations et la base de données
• Ouvrir des ports TCP / UDP et bien plus encore

Conseil : Comment rechercher des backdoors PHP ?

Utilisez la commande grep d'Unix / Linux pour rechercher le shell c99 ou r57 :

Conclusion

Votre serveur basé sur PHP est maintenant correctement renforcé et prêt à afficher des pages Web dynamiques. Cependant, les vulnérabilités sont principalement causées par ne pas suivre les règles de programmation des meilleures pratiques. Vous devriez être consulté pour d'autres ressources pour vos besoins en matière de sécurité des applications web, en particulier la programmation php qui est au-delà de la portée du travail de l'administrateur système.

Références :

1. Sécurité PHP - du projet officiel php.
2. Apache suseexec - de la documentation du projet Apache.
3. Apache 2.2 - des conseils de sécurité du projet Apache.
4. L'Open Web Application Security Project - Types courants d'attaques contre la sécurité des applications.
5. 25 conseils de sécurité pour Nginx

Conclusion :

Cette page explique diverses astuces de sécurité PHP que les administrateurs système de Linux peuvent appliquer. Pour plus d'informations, consultez les liens suivants :

1. Sécurité essentielle de PHP (kindle édition) : Un livre sur la sécurité des applications Web écrit spécifiquement pour les développeurs PHP. Il couvre 30 des exploits les plus courants et les plus dangereux ainsi que des mesures de protection simples et efficaces pour protéger vos applications PHP.
2. Attaques et défense contre l'injection SQL Ce livre couvre l'injection SQL et les attaques liées au Web. Il explique l'injection SQL. Il explique comment trouver, confirmer et automatiser la découverte d'une injection SQL. Il contient des conseils et des astuces pour trouver l'injection SQL dans le code. Vous pouvez créer des exploits utilisant l'injection SQL et concevoir pour éviter les dangers de ces attaques.

Vous avez d'autres bonnes pratiques en matière de sécurité php ? Faites-nous en part dans la section des commentaires ci-dessous.