Même si la pile TCP/IP du système d'exploitation GNU/Linux est reconnue comme étant une des plus stables, appliquer ce principe de précaution est bien loin d'être un mal, au contraire !
Ouvrir le fichier /etc/sysctl.conf, puis modifer tel que :
# Se protéger de l'IP Spoofing' (vol d'adresse IP) :
net.ipv4.conf.all.rp_filter = 1
# Se protéger des attaques 'SYN Flood' :
net.ipv4.tcp_syncookies = 1
# Ignorer les messages 'ICMP Redirects' :
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
# Interdire 'Source Routing' :
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
Et ajouter :
# Surveiller 'martians' (adresse source falsifiée ou non routable) :
net.ipv4.conf.all.log_martians = 1
# Ignorer les messages 'ICMP Echo Request' :
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_echo_ignore_all = 1
# Ignorer les messages 'ICMP Bogus Responses' :
net.ipv4.icmp_ignore_bogus_error_responses = 1
# 1024 connexions non confirmées max, limite le SYN flood
net.ipv4.tcp_max_syn_backlog = 1024
On va faire en sorte que l'authentification se fasse par un système de clés publique/privée pour contrer les futurs essais de force brute. De plus on ne sera plus obligé d'entrer un mot de passe à chaque fois.
Modifier le fichier /etc/ssh/sshd_config tel que :
Interdire la connexion en tant que super utilisateur
PermitRootLogin no
Autoriser seulement l'authentification par clefs
AuthorizedKeysFile %h/.ssh/authorized_keys
Ainsi qu'interdire l'accès à l'aide de mot de passe
PasswordAuthentication no
-c : vérifier le système entier
--rwo (report-warnings-only) : n'afficher que les erreurs ou alertes
--sk (skip-keypress) : ne pas attendre d'intervention de la part de l'utilisateur
-l rkhunter.log : insérer un résumé dans un fichier log
Afin de bloquer les attaques de type force brute, on va installer fail2ban :
root@serveur # aptitude install fail2ban
Il va falloir activer certaines prisons qui ne le sont pas par défaut.
Pour ce faire, copier le fichier /etc/fail2ban/jail.conf en /etc/fail2ban/jail.local et modifier à votre goût :
fail2ban.filter : INFO Set findtime = 600
fail2ban.actions: INFO Set banTime = 600
fail2ban.jail : INFO Jail 'apache-noscript' started
fail2ban.jail : INFO Jail 'named-refused-udp' started
fail2ban.jail : INFO Jail 'ssh-ddos' started
fail2ban.jail : INFO Jail 'apache-multiport' started
fail2ban.jail : INFO Jail 'apache-overflows' started
fail2ban.jail : INFO Jail 'ssh' started
fail2ban.jail : INFO Jail 'apache' started
fail2ban.jail : INFO Jail 'named-refused-tcp' started
Snort est un IDS qui vous permettra de détecter d'éventuelles intrusions, de gérer vos logs et sniffer votre réseau.
Il est possible d'obtenir de plus amples informations concernant ce logiciel sur Wikipédia.
Choisir le réseau qui vous convient, ici je choisis de ne surveiller que la plage d'adresses allant de 192.168.0.0 à 192.168.0.255 :
Chez moi à partir de ce moment, j'ai une erreur. Mais c'est normal étant donné que l'on n'a pas paramétré snort.
Il va falloir créer une base de données :
root@serveur # mysql -u root -p -h localhost
mysql > CREATE DATABASE `snort` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
mysql > CREATE USER `snortu`@`localhost`;
mysql > SET PASSWORD FOR `snortu`@`localhost`=PASSWORD('snortp');
mysql > GRANT CREATE, DELETE, INSERT, SELECT, UPDATE on `snort`.* to `snortu`@`localhost`;
mysql > quit
Ainsi qu'y créer les tables :
root@serveur # cd /usr/share/doc/snort-mysql/
root@serveur # zcat create_mysql.gz | mysql -u root -p -h localhost snort
Copier le fichier de configuration de snort tel que :
Note : remplacer interface par votre interface réseau, chez moi eth0.
Configuration
Ouvrir le fichier /etc/snort/snort.eth0.conf.
Modifier le réseau surveillé
var HOME_NET 192.168.0.0/24
Commenter la ligne suivante :
output log_tcpdump: tcpdump.log
Appliquer les règles sur les SellCodes
include $RULE_PATH/virus.rules
include $RULE_PATH/shellcode.rules
Optionnel : commenter certaines règles qui, ici, ne sont d'aucune utilité :
Étant donné que tout à l'heure, pendant la configuration, il y a eu une erreur, un fichier a été automatiquement créer afin de bloquer le démarrage du démon, on va le supprimer :
root@serveur # rm /etc/snort/db-pending-config
Et enfin, lancer snort :
root@serveur # service snort start
Note : lorsque l'on utilise une autre interface qu'eth0 (par exemple wlan1), il faut lancer snort manuellement[1] :
Webmin est une interface web permettant de gérer son serveur. Il est d'autant plus utile qu'il permet de voir ses logs, notammement ceux de syslog-ng et fail2ban.
Créer le fichier /etc/apt/sources.list.d/webmin.list et y inscrire :
# Dépôt Webmin
deb http://download.webmin.com/download/repository sarge contrib
Accéder à Webmin par https://www.test.sec:10000, on va passer à la configuration.
Arrivé sur la page d'accueil, si vous avez une mise à jour disponible, installez-là.
Rendez-vous dans Webmin > Webmin Configuration > Language et choisir French (FR.UTF-8).
Rafraîchir la page pour prendre en compte la nouvelle langue.
Rendez-vous dans Système > Journaux système cliquer sur Ajouter un nouveau journal système, nous allons ajouter la prise en charge des fichiers log de fail2ban :
Vous pouvez en ajouter autant que vous le souhaitez de cette façon.
Par perdus j'entends là les fichiers qui n'ont pas de propriétaires ou qui ne devraient pas avoir les droits qu'ils ont.
Deux choses, l'une concerne les fichier sans propriétaire, l'autre les fichiers qui contiennent un SUID alors qu'il n'en ont pas besoin.
Fichiers oubliés
Afin de savoir s'il y a des fichiers temporaires oubliés :
Libre à vous d'en faire ce que vous voulez, en théorie il ne devrait pas y en avoir.
Désactiver les SUID
Parfois très pratiques, le SUID vous permet de faire fonctionner une application en tant qu'autre utilisateur. Imaginez que quelqu'un ai accès à l'une de ces applications (via un shell, apache), et puisse lire votre /etc/shadow... Toute la sécurité de votre serveur serait compromise.
Pour trouver tous les binaires qui utilisent un SUID, tapez la ligne suivante :
La plupart des administrateurs systèmes recommandent de désactiver les services comme ping ou traceroute (lorsque vous n'en avez pas besoin).
Je vous conseille de désactiver /usr/bin/chfn, /usr/bin/chsh, /bin/mount, /bin/umount, /usr/bin/gpasswd, /usr/bin/newgrp, /usr/sbin/ping6 et /usr/bin/ping.
Désactiver le SUID sur ces binaires empêche tout autre utilisateur que le propriétaire de l'exécuter (tout en sachant que la plupart de ces services auront besoin d'être exécutés en tant que root pour fonctionner).
ddclient est un utilitaire très pratique qui permet d'automatiser la mise à jour d'une adresse IP dynamique reliée à un nom de domaine.
Installation :
root@serveur # aptitude install ddclient
Après la configuration, éditer le fichier /etc/ddclient.conf et ajouter cette ligne :
ssl=yes
Ceci permettra de crypter les données envoyées, à faire si vous ne voulez pas qu'avec une attaque MITM, ces informations soient récupérables facilement.
Il faut bien vérifier que le module perl IO::Socket::SSL soit installé sur votre système :
Optionnel : commenter la ligne contenant Host header is a numeric IP address du fichier /etc/modsecurity/modsecurity_crs_21_protocol_anomalies.conf pour autoriser l'accès au site par l'intermédiaire d'une adresse IP.
[notice] ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/) configured.
Bien qu'il s'agisse là d'un excellent module et d'une protection fiable, il se peut qu'il soit un peu chiant lorsque vous développez en local, le comportement de PHPmyAdmin peut être altéré, certains scripts retournerons une erreur car jugés dangereux.
Afin de parer ce problème, et ce seulement en développement, vous pouvez ajouter une règle dans les options du vhost ou dans un .htaccess qui désactivera mod-security :
SecRuleEngine Off
Bien entendu, une fois le développement terminé, il est plus que fortmement conseillé de rétablir la sécurité.
On va désactiver diverses divulgations d'informations comme la signature du serveur, la méthode TRACE, et caetera.
Éditer le fichier /etc/apache2/apache2.conf et ajouter ces lignes :
ServerSignature Off
ServerTokens Prod
TraceEnable Off
Optionnel : si le module rewrite est installé et activé, voici quelque protections supplémentaires, à placer dans un fichier .htaccess :
# Empêcher les attaques par include de fichier externe
RewriteEngine On
RewriteCond %{QUERY_STRING} =//
RewriteRule .* - [F,L]
# Bloquer l'accès au site pour libwww-perl
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} libwww [NC]
RewriteRule .* - [F,L]
Optionnel : autre protection, à placer aussi dans un fichier .htaccess :
# Protection contre les attaques se servant de register global on
SetEnv REGISTER_GLOBALS 0
Redémarrer apache :
root@serveur # service apache2 restart
Dans les fichiers d'options des vhosts ou dans un fichier .htaccess il est possible de bloquer certaines actions.
Empêcher le listage des répertoires
Options -Indexes
Empêcher de pouvoir accéder à un page par sonNom.php ou sonNom
Options -MultiViews
Ne pas suivre les liens symboliques
Options -FollowSymLinks
Note : pour combiner plusieurs options, il faut les mettres à la suite tel que :
Options -Indexes -FollowSymLinks -MultiViews
Attention : il est déconseillé de sécuriser un répertoire par un accès à l'aide de la méthode d'authentification d'Apache.
Le pourquoi du comment est simple : les informations transitent en clair, de ce fait, à l'aide d'une attaque MITM, il est très facile d'obtenir celles-ci.
Pour savoir de quoi il s'agit, c'est par là. Pour ne pas faire que pomper, je vous redirige simplement vers une page où tout est très bien expliqué, c'est sur le site www.webstrat.fr [au cas où, je garde une copie non visible, si le site tombe je recopierai les informations].
Ne pas fournir la version de PHP :
expose_php = Off
Restreindre les emplacements du site :
open_basedir = /var/www
De ce fait, si je me place à la racine du site, il me sera impossible d'inclure
le fichier ../../../../../../../etc/passwd par exemple.
Désactiver certaines commandes :
disable_functions = php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo
Interdire l'ouverture et l'inclusion de fichiers distants :
allow_url_fopen = Off
allow_url_include = Off
Si vous n'utilisez pas de formulaires pour l'envoi de fichiers, il est bon de désactivé le système d'envoi :
file_uploads = Off
Par contre si vous avez ce genre de formulaire, il faut limiter un répertoire d'envoi et une taille maximale :
upload_tmp_dir = /var/php_tmp
upload_max_filezize = 2M
Enfin, une dernière chose des plus convoitée, les sessions.
Enregistrement des sessions :
session.save_path = /var/lib/php
Il est déconseillé demanipuler vos sessions à l'aide de JavaScript.
À l'aide de cette directive, JavaScript ne pourra lire les sessions (afin d'éviter le XSS) :
session.cookie_httponly = 1
De ce fait, JavaScript ne pourra accéder qu'aux cookies.
Ne pas logguer une erreur récurrente :
ignore_repeated_errors = On
fichier log :
error_log = /var/log/php_errors.log
Ou bien configurer-le tel qu'il redirige les messages vers syslog-NG (voir section Syslog-NG).
Avant d'ajouter une quelconque information de votre base de données, échaper les caractères spéciaux à l'aide de la commande mysql_real_escape_string() :
Code PHP :
$chaine = mysql_real_escape_string($chaine);
Avant de vérifier une information sensible dans la BDD comme le nom d'un utilisateur et son mot de passe, il faut toujours s'assurer que l'on n'entre pas de caractères spéciaux qui pourraient corrompre la requête.
Dernier point, et non des moindres, créer un utilisateur ayant des droits restreints pour toutes transactions.
Notamment, la base information_schema ne doit pas pouvoir être lue.
Pour ce faire, il suffit de créer un utilisateur et de lui affecter les drois minimums sur la BDD utilisée :
root@serveur # mysql -u root -p -h localhost
mysql > CREATE USER `utilisateur_restreint`@`localhost`;
mysql > SET PASSWORD FOR `utilisateur_restreint`@`localhost`=PASSWORD('mdp_complexe');
mysql > GRANT INSERT, SELECT, UPDATE, DELETE on `base`.* to `utilisateur_restreint`@`localhost`;
mysql > quit
Tel que créé ci-dessus, votre utilisateur utilisateur_restreint pourra interroger, insérer et supprimer des données dans la/les table(s) de la base de données base mais n'aura absolument aucun accès aux autres bases.
La façon le plus fiable est de passer la commande directement grace à system('commande'), mais si vous devez le faire par l'intermédiaire d'une variable tel que system('$cmd'), il faut bien faire attention à empêcher le caractère pipe (|) :
Code PHP :
if ( (strstr($cmd, '|')) || (strstr($cmd, '%7c')) ) {
die ('Erreur : caractère interdit !');
}
Toujours vérifier les possibles fichiers à inclure, ne pas laisser un trop grand choix d'inclusions et vérifier l'extension du fichier inclu.
Note : si vous avez installer le module mod-security2 pour apache, vous ne risquez pas grand chose quant au type d'inclusion visant un fichier sortant du répertoire web.
Exemple de code si vos inclusions doivent être dynamiques (essayer d'entourer le fichier inclu par un préfixe et un suffixe).
Code PHP :
if ( isset($_GET['page']) && ! empty($_GET['page']) ) {
if ( file_exists('page-'.$_GET['page'].'.html') ) {
include 'page-'.$_GET['page'].'.html';
}
}
Exemple de code si vos inclusions sont statiques (vous connaissez la page à inclure, il n'y a pas de doute).
Code PHP :
(array)$pages_autorisees = array('accueil', 'bas');
if ( isset($_GET['page']) && in_array($_GET['page'], $pages_autorisees) ) {
include $_GET['page'];
}
Toujours vérifier les fichier envoyés, si vous demandez une image de type PNG, il est hors de question de laisser passer un fichier PHP ou je ne sais quoi d'autre. L'idéal serait de pouvoir filtrer l'extension en plus du type mime.
Si vous autorisez l'envoi de scripts, quelque soit le langage, faîtes une copie en fichier texte et n'autoriser personne à l'exécuter hormis root :
Vérifier l'extension et le nom du fichier uploadé.
Exemple de script qui va regarder qu'il n'y ait pas de caractères spéciaux comme "/" ou "\" :
Code PHP :
(array)$extensions = array('.jpeg', '.png', '.gif');
(string)$fichier = $_FILES['fichier']['name'];
if ( preg_match('#[\x00-\x1F\x7F-x9F/\\\\]#', $fichier) ) {
echo 'Le nom du fichier comporte des caratères interdits';
}
(string)$extension = strrchr($fichier, '.');
if ( ! in_array($extension, $extensions) ) {
echo 'Le format de fichier n\'est pas accepté. Seuls le jpeg, le png et le gif sont acceptés.';
}
Vérifier la taille du fichier uploadé.
Exemple de script qui va regarder si le fichier n'excède pas une taille donnée :
Code PHP :
$taille_max = 10000;
$taille_fichier = filesize($_FILES['fichier']['tmp_name']);
if ( $taille_fichier > $taille_max ) {
echo 'Le fichier est trop gros, envoi impossible, la taille maximale est de 10Mo.';
}
Certains des programmes décrits plus haut permettent l'envoi de courriel en cas d'erreur critique ou par simple avertissement régulier.
Pour donner la possibilité de sortir du local, éditer le fichier /etc/postfix/main.cf et si votre FAI est Orange :
relayhost = smtp.orange.fr
Redémarrer postfix :
root@serveur # service postfix restart
Maintenant vous avez toutes les billes pour sécuriser votre système, surtout au niveau du serveur apache.
Rappelez-vous toujours : 99% des problèmes se trouve entre la chaise et le clavier.
Mais aussi que chaque programme est susceptible de contenir une ou plusieurs faille(s), pensez à vérifier régulièrement les mises à jour de sécurité.
Non optionnel : abonnez-vous à la liste de diffusion debian-security (lists.debian.org) !
- coloration syntaxique pour le code PHP
- amélioration des codes PHP
18 octobre 2012
- MàJ de la documentation pour être en phase avec la version stable actuelle (Debian Squeeze)
- ajout de la section "Contre-mesures DDOS"
- suppression de la partie "Avant / Après"
03 mars 2010
- revue complète du système de gestion des pages (suite et fin)
- ajout d'un lien vers une version plus "sobre", sans CSS
25 février 2010
- revue complète du système de gestion des pages
- correction de quelques commandes pour les sections rkhunter, Webmin et Inclusion
- section Fichiers "perdus" étoffée
07 novembre 2009
- section Les fichiers "perdus" ajoutée
12 mai 2009
- section Snort complétée
12 avril 2009
- section Peaufiner Apache complétée
- ajout de la section ddclient
- MAJ des sources
09 avril 2009
- section Syslog-NG complétée
- section PHP complétée
- section Peaufiner Apache complétée
- information importante ajoutée à mod-security2
07 avril 2009
- section PHP complétée
- MAJ des sources
- modification de quelques propriétés CSS
03 avril 2009
- Envoi de fichiers en plus détaillé
- Inclusions en plus détaillé
02 avril 2009
- rkhunter en version détaillée
- snort couplé à ACIDbase
- Webmin
- une ptite partie Avant/Après juste histoire de dire qu'on n'a pas fait tout ça pour rien
- MAJ des sources
- possibilité d'avoir un affichage sur un ou plusieurs pages, pratique si vous voulez copier le tuto
28 mars 2009
- version initiale (avec une Debian Lenny)
Contenu modifié le 01/10/2013. moc.liamg@gitobob -
Philosophie.
