Gentoo Logo

1.  Apache

Apache est livré avec un fichier de configuration relativement bon, mais, encore une fois, nous devons optimiser quelques petites choses, comme lier l'écoute d'Apache à une adresse et l'empêcher de donner trop d'information. Vous trouverez ci-dessous les options que vous devriez utiliser dans le fichier de configuration :

Si vous n'avez pas désactivé ssl dans /etc/make.conf avant d'installer Apache, vous devriez être en possession d'un serveur avec SSL activé. Vous trouverez dans /etc/apache2/vhosts.d des exemples de fichiers de configuration. Ces fichiers d'exemple sont mis en production, il convient donc de les vérifier ou de les désactiver.

Il est important de préciser dans votre configuration sur quelle adresse IP attendre les connexions, plutôt que d'écouter sur toutes les adresses IP disponibles sur votre système. Par exemple, pour le fichier 00_default_vhost.conf :

Exemple de code 1.1 : /etc/apache2/vhosts.d/00_default_vhost.conf

# Faites-le écouter sur votre adresse IP.
Listen 127.0.0.1

Nous vous recommandons également de désactiver l'affichage de toute information sur votre installation d'Apache. Par défaut, la configuration indique d'ajouter la version du serveur ainsi que le vhost aux pages générées par le serveur. Pour désactiver cela, mettez la variable ServerSignature à Off :

Exemple de code 1.1 : /etc/apache2/modules.d/00_default_settings.conf

# Empêchera Apache de dévoiler sa version.
ServerSignature Off

Apache est compilé avec les options --enable-shared=max et --enable-module=all. Cela autorise tous les modules par défaut. Vous devez donc commenter les modules dont vous n'avez pas besoin dans la section LoadModule (LoadModule et AddModule) du fichier de configuration principal /etc/apache2/httpd.conf. Redémarrez ensuite le service en faisant : /etc/init.d/apache2 restart.

Pour plus d'informations, consultez http://www.apache.org.

1.  Bind

Consultez la documentation en ligne sur Internet Software Consortium. Le manuel de référence de l'administrateur de BIND 9 se trouve aussi dans doc/arm.

Les ebuilds récents pour le logiciel BIND supportent le chroot sans effort de votre part. Après avoir exécuté emerge bind, suivez ces instructions :

Exemple de code 1.1 : utiliser un chroot avec BIND

# emerge --config bind
(Avant d'exécuter la commande précédente, vous souhaiterez peut-être
changer le répertoire du chroot dans /etc/conf.d/named. Par défaut,
/chroot/dns sera utilisé.)

1.  Djbdns

Djbdns est une autres implémentation d'un serveur DNS. Son auteur est prêt à parier de l'argent pour prouver qu'il est sécurisé. Son mode de fonctionnement est très différent de celui de Bind v.9, mais il vaut la peine d'être testé. Vous trouverez plus d'informations sur http://www.djbdns.org/.

1.  FTP

Utiliser FTP (File Transfer Protocol) est en général une mauvaise idée. Ce service n'utilise aucun cryptage pour les données (les mots de passe sont échangés sous forme de texte clair), écoute sur 2 ports (habituellement 20 et 21) et supporte des utilisateurs anonymes, cette dernière caractéristique étant très attrayante pour les attaquants (qui l'utilisent afin d'échanger des fichiers illégaux (« warez »)). Puisque le protocole FTP comporte de nombreux problèmes de sécurité, vous devriez plutôt utiliser sftp ou HTTP. Si vous devez utiliser FTP, sécurisez vos services du mieux que vous le pouvez, et préparez-vous...

1.  Mysql

Si seules les applications locales ont besoin d'accéder à la base de données mysql, décommentez la ligne suivante dans /etc/mysql/my.cnf :

Exemple de code 1.1 : désactiver l'accès au réseau

skip-networking

Nous désactivons ensuite l'utilisation de la commande LOAD DATA LOCAL INFILE. Cela sert à prévenir une lecture non autorisée à partir des fichiers locaux. Cela devient pertinent lorsque de nouvelles vulnérabilités d'injection SQL sont découvertes dans des applications PHP.

Exemple de code 1.1 : désactiver LOAD DATA LOCAL INFILE dans la section [mysqld]

set-variable=local-infile=0

Ensuite, nous devons supprimer la base de donnée fournie comme exemple (test) ainsi que tous les comptes d'utilisateurs à l'exception du compte root local.

Exemple de code 1.1 : supprimer la base de donnée fournie en exemple et les utilisateurs non nécessaires

mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not (host="localhost" and user="root");
mysql> flush privileges;

Attention : faites attention avec les commandes ci-dessus si vous avez déjà configuré des comptes utilisateurs.

Note : si vous changez des mots de passe à partir de l'invite MySQL, vous devriez toujours nettoyer ~/.mysql_history et /var/log/mysql/mysql.log puisqu'ils conservent les commandes SQL exécutées avec les mots de passe en texte clair.

1.  Proftpd

Proftpd est connu pour avoir eu de nombreux problèmes de sécurité, mais la plupart semblent avoir été réglés. Il est quand même important d'appliquer les améliorations suivantes :

Exemple de code 1.1 : /etc/proftpd/proftpd.conf

ServerName "Mon démon FTP"
# Ne donnez pas l'identité du serveur.
ServerIdent on "Va voir ailleurs si j'y suis"

# Permet de créer des utilisateurs virtuels plus facilement.
RequireValidShell off

# Utilise des fichiers de groupes et de mots de passe alternatifs
# (passwd utilise un format crypté).
AuthUserFile "/etc/proftpd/passwd"
AuthGroupFile "/etc/proftpd/group"

# Permissions
Umask 077

# Délais maximum et limitations
MaxInstances 30
MaxClients 10 "Only 10 connections allowed"
MaxClientsPerHost 1 "You have already logged on once"
MaxClientsPerUser 1 "You have already logged on once"
TimeoutStalled 10
TimeoutNoTransfer 20
TimeoutLogin 20

# Tout le monde en chroot
DefaultRoot ~

# Ne pas démarrer le service en tant que root.
User  nobody
Group nogroup

# Consigner tout transfert.
TransferLog /var/log/transferlog

# Problèmes avec le « globbing »
DenyFilter \*.*/

Vous trouverez plus de documentation sur http://www.proftpd.org.

1.  Pure-ftpd

Pure-ftpd est une branche provenant du projet trollftpd, modifié par Frank Dennis pour des raisons de sécurité et pour améliorer ses fonctionnalité.

Utilisez des utilisateurs virtuels (jamais de comptes système) en activant l'option AUTH. Donnez-lui la valeur -lpuredb:/etc/pureftpd.pdb et créez vos utilisateurs en utilisant /usr/bin/pure-pw.

Exemple de code 1.1 : /etc/conf.d/pure-ftpd

## Interdire les téléchargements si la partition est plus remplie que la valeur
suivante. ##
DISK_FULL="-k 90%"

AUTH="-lpuredb:/etc/pureftpd.pdb"

## Autres options ##
MISC_OTHER="-A -E -X -U 177:077 -d -4 -L100:5 -I 15"

Configurez aussi votre paramètre MISC_OTHER pour ne pas autoriser les utilisateurs anonymes (-E), pour utiliser le chroot pour tout le monde (-A), pour que les utilisateurs ne puissent pas lire ou écrire des fichiers commençant par un . (point) (-X), pour imposer un temps maximum d'inactivité (-I), pour limiter la récursion (-L) et spécifier un umask raisonnable.

Attention : n'utilisez en aucun cas l'option -w ou -W ! Si vous voulez héberger du warez, arrêtez de lire ce document !

Pour en savoir plus, consultez http://www.pureftpd.org.

1.  Vsftpd

Vsftpd (qui signifie : FTP très sécurisé (« very secure FTP »)) est un petit démon FTP qui tourne avec un fichier de configuration par défaut plutôt correct. Il est très simple et ne possède pas certaines fonctionnalités que d'autres serveurs tels que pureftp et proftp possèdent.

Exemple de code 1.1 : /etc/vsftpd

anonymous_enable=NO
local_enable=YES

# Lecture seulement
write_enable=NO

# Active la journalisation des transferts.
xferlog_std_format=YES

idle_session_timeout=20
data_connection_timeout=20
nopriv_user=nobody

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chrootlist

ls_recurse_enable=NO

Comme vous pouvez le constater, ce service ne contient pas de permissions individuelles et pas d'action chroot de base. Mais en ce qui concerne la configuration pour les utilisateurs anonymes, il est plutôt bon. Il peut parfois être utile d'avoir un serveur FTP anonyme (afin de partager des sources par exemple) et vsftpd est vraiment parfait pour cela.

1.  Netqmail

Le serveur de courrier Netqmail est fréquemment qualifié de très sécuritaire. Il a été écrit en misant sur la sécurité (et la paranoïa). Il n'autorise pas le relais des courriels par défaut et n'a eu aucun trou de sécurité depuis 1996. Faites tout simplement emerge netqmail et configurez-le !

1.  Samba

Samba est un protocole qui permet de partager des fichiers avec des réseaux Microsoft/Novell et qui ne devrait pas être utilisé sur Internet. Il faut néanmoins le sécuriser.

Exemple de code 1.1 : /etc/samba/smb.conf

[global]
  # Lier à une interface.
  interfaces = eth0 10.0.0.1/32

  # Asurez-vous d'utiliser des mots de passe cryptés.
  encrypt passwords = yes
  directory security mask = 0700

  # Autoriser le trafic de 10.0.0.*.
  hosts allow = 10.0.0.

  # Permet l'authentification d'utilisateur.
  #(N'utilisez pas le mode partagé.)
  security = user

  # Interdit les comptes privilégiés.
  invalid users = root @wheel

  # Définit la taille maximum, en kilo-octets, affichée pour un élément partagé
  # (ce n'est pas une limite).
  max disk size = 102400

  # Définit la politique de mots de passe.
  min password length = 8
  null passwords = no

  # Utilise PAM (si ce dernier est supporté).
  obey pam restrictions = yes
  pam password change = yes

Assurez-vous que les permissions sont placées correctement sur chaque partage et lisez la documentation.

Redémarrez à présent le serveur et ajoutez les utilisateurs qui devraient avoir accès à ce service. Vous pouvez le faire grâce à la commande /usr/bin/smbpasswd avec le paramètre -a.

1.  ssh

La seule option de sécurité que vous devez activer sur OpenSSH concerne l'authentification basée sur le cryptage à clé publique. Beaucoup trop de sites (comme http://www.sourceforge.net, http://www.php.net et http://www.apache.org) ont souffert d'intrusions non autorisées sur leurs systèmes à cause de mauvais mots de passe ou de mots de passe divulgués par erreur.

Exemple de code 1.1 : /etc/ssh/sshd_config

# Autorise uniquement la version 2.
Protocol 2

# Pas d'accès en tant que root. (Les utilisateurs devront utiliser su.)
PermitRootLogin no

# Active l'authentification par clé publique.
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

# Désactive les fichiers .rhosts et l'authentification normale.
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no

# Seuls les membres des groupes wheel ou admin ont accès.
AllowGroups wheel admin

# Parmi les membres de ces groupes, seuls kn et bs ont accès.
# @<domainname> est facultatif, mais peut remplacer
# l'ancienne directive AllowHosts
AllowUsers kn@gentoo.org bs@gentoo.org

# Règle le niveau de journalisation.
SyslogFacility AUTH
LogLevel INFO

(Mettez votre adresse ici.)
ListenAddress 127.0.0.1

Veuillez vérifier que l'option UsePAM yes ne se trouve pas dans votre configuration, car cela empêche l'authentification par clé publique. Vous pouvez alternativement désactiver l'une des deux options PasswordAuthentication ou ChallengeResponseAuthentication. Vous trouverez plus d'informations à ce sujet dans les pages du manuel de sshd_config.

La seule chose que doivent maintenant faire vos utilisateurs est de créer une clé (sur la machine depuis laquelle ils veulent se connecter) avec la commande suivante :

Exemple de code 1.1 : créer une paire de clés DSA

# /usr/bin/ssh-keygen -t dsa

Entrez une phrase de passe.

Exemple de code 1.1 : sortie générée par ssh-keygen

Generating public/private dsa key pair.
Enter file in which to save the key (/home/kn/.ssh/id_dsa):[Tapez Entrée.]
Created directory '/home/kn/.ssh'.
Enter passphrase (empty for no passphrase): [Entrez votre phrase de passe.]
Enter same passphrase again: [Entrez votre phrase à nouveau.]
Your identification has been saved in /home/kn/.ssh/id_dsa.
Your public key has been saved in /home/kn/.ssh/id_dsa.pub.
The key fingerprint is:
07:24:a9:12:7f:83:7e:af:b8:1f:89:a3:48:29:e2:a4 kn@knielsen

Cela va ajouter deux fichiers dans votre répertoire ~/.ssh/, nommés id_dsa et id_dsa.pub. Le premier fichier, id_dsa, est votre clé privée et devrait être gardée précieusement pour vous-même et personne d'autre. L'autre fichier, id_dsa.pub, est à distribuer à tous les serveurs auxquels vous avez accès. Ajoutez la clé dans le répertoire personnel de l'utilisateur dans ~/.ssh/authorized_keys, puis l'utilisateur devrait être capable de se connecter :

Exemple de code 1.1 : ajouter la clé publique de id_dsa.pub au fichier authorized_keys

$ scp id_dsa.pub autre_machine:/var/tmp/currenthostname.pub
$ ssh other-host
password:
$ cat /var/tmp/currenthostname.pub >> ~/.ssh/authorized_keys

Vos utilisateurs devraient conserver leur clé privée précieusement. Il est préconisé de la placer sur un support qu'ils ont toujours sur eux ou alors sur leur station de travail (inclure cette options dans le règlement sur les (mots de passe)).

Vous trouverez plus d'informations sur le site officiel OpenSSH.

1.  Utiliser xinetd

xinetd remplace inetd (que Gentoo ne propose pas), le démon pour les services Internet. Il supporte les contrôles d'accès basés sur l'adresse de la machine distante et sur l'heure de l'accès. Il fournit également des fonctionnalités avancées de journalisation, incluant l'heure de démarrage du serveur, l'adresse de la machine distante, le nom de l'utilisateur distant, la durée de fonctionnement du serveur ainsi que les actions demandées.

Tout comme pour les autres services, il est important d'avoir une bonne configuration par défaut. Mais étant donné que xinetd fonctionne en tant que root et supporte des protocoles dont vous pourriez ignorer le fonctionnement, nous vous recommandons de ne pas l'utiliser. Mais, si vous désirez l'utiliser quand même, voici comment le sécuriser quelque peu :

Exemple de code 1.1 : installation de xinetd

# emerge xinetd tcpd

Puis, éditez le fichier de configuration :

Exemple de code 1.1 : /etc/xinetd.conf

defaults
{
 only_from      = localhost
 instances      = 10
 log_type       = SYSLOG authpriv info
 log_on_success = HOST PID
 log_on_failure = HOST
 cps            = 25 30
}

# Cela créera un pserver (cvs) via xinetd avec les paramètres suivants :
# Maximum de 10 instances (10 connexions simultanées).
# Limite le pserver en mode tcp uniquement.
# Utilise l'utilisateur cvs pour démarrer le service.
# Lie les interfaces à une seule IP.
# Autorise l'accès uniquement depuis 10.0.0.*.
# Limite l'accès des développeurs au serveur entre 8h et 17h.
# Utilise les « wrappers » tpcd (contrôlés par liste d'accès dans
# /etc/hosts.allow et /etc/hosts.deny).
# Le max_load sur la machine est de 1.0.
# L'option de désactivation est normalement inutilisée mais j'aime l'avoir
# si jamais elle doit être utilisée pour désactiver le service.
service cvspserver
{
 socket_type    = stream
 protocol       = tcp
 instances      = 10
 protocol       = tcp
 wait           = no
 user           = cvs
 bind           = 10.0.0.2
 only_from      = 10.0.0.0
 access_times   = 8:00-17:00
 server         = /usr/sbin/tcpd
 server_args    = /usr/bin/cvs --allow-root=/mnt/cvsdisk/cvsroot pserver
 max_load       = 1.0
 log_on_failure += RECORD
 disable        = no
}

Pour plus d'informations, consultez man 5 xinetd.conf.

1.  X

Xorg est configuré par défaut pour agir comme un serveur X. Cela peut être dangeureux étant donné que X utilise des connexions tcp qui ne sont pas cryptées et reste à l'écoute de clients X.

Important : si vous n'avez pas besoin de ce service, désactivez-le !

Si vous utilisez votre station comme serveur X, utilisez la commande /usr/X11R6/bin/xhost avec précaution. Cette commande permet aux clients de se connecter depuis d'autres machines et d'utiliser votre affichage. Cela peut être utile si vous avez besoin de démarrer une application X depuis une autre machine et que la seule façon de le faire est depuis le réseau, mais cela peut aussi être exploité par un attaquant. La syntaxe de cette commande est /usr/X11R6/bin/xhost +hostname.

Attention : n'utilisez jamais la fonctionnalité xhost + ! Elle permet à n'importe quel client de se connecter et de prendre le contrôle de votre session X. Si un attaquant peut contrôler votre X, il peut alors espionner vos entrées clavier et contrôler votre bureau. Si vous devez l'utiliser, souvenez-vous de toujours spécifier un hôte.

Une solution plus sécurisée est de désactiver cette fonctionnalité complètement en démarrant votre X avec l'option startx -- -nolisten tcp ou bien en désactivant complètement cette option dans le fichier de configuration :

Exemple de code 1.1 : /usr/X11R6/bin/startx

defaultserverargs="-nolisten tcp"

Pour vous assurer que startx ne soit pas écrasé lorsque vous installez une nouvelle version de Xorg, vous devez le protéger. Ajoutez la ligne suivante au fichier /etc/make.conf :

Exemple de code 1.1 : /etc/make.conf

CONFIG_PROTECT_MASK="/usr/X11R6/bin/startx"

Si vous utilisez une invite de connexion graphique, vous devez utiliser une approche différente.

Pour gdm (GNOME Display Manager) :

Exemple de code 1.1 : /etc/X11/gdm/gdm.conf

[server-Standard]
command=/usr/X11R6/bin/X -nolisten tcp

Pour xdm (X Display Manager) et kdm (KDE Display Manager) :

Exemple de code 1.1 : /etc/X11/xdm/Xservers

:0 local /usr/bin/X11/X -nolisten tcp

Dernière mise à jour le 13 juin 2008

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.