Page suivante - Page précédente - Table des matières

8. Sécuriser votre domaine

Cette section traite de la sécurisation de votre domaine. L'accent est mis sur l'importance de la transparence de cette dernière vis à vis des utilisateurs. Si votre sécurité est trop contraignante et dérange trop les activités de vos utilisateurs, ceux-ci développeront leurs propres procédures de contournement qui peuvent nuire à l'ensemble du domaine. Le meilleur moyen d'éviter ceci est de rendre la sécurité aussi peu contraignante que possible et d'encourager les utilisateurs à vous contacter en premier lieu quand ils ont des difficultés qui pourraient être imputables aux mesures de sécurité du site. Une certaine tolérance est importante. Je sais, d'expérience personnelle, que si le règlement de sécurité est trop rigide, les utilisateurs mettront en place leurs propres tunnels à travers le firewall de façon à pouvoir se loguer depuis l'extérieur du domaine. Il est préférable que les procédures de connexion à distance, ou n'importe quoi d'autre que tentent de faire les utilisateurs soient installées, contrôlées et approuvées par vous.

Cette section traite de la sécurisation de votre réseau contre les agressions extérieures et contre un espionnage factuel depuis l'intérieur. Sécuriser votre site contre une attaque déterminée de la part d'utilisateurs légitimes à l'intérieur du réseau est une tâche beaucoup plus difficile et compliquée et reste hors du champ de ce document.

Un des points de sécurité sur lesquels se base cette section est la protection contre le « routeur hostile ». Le routeur fourni par votre ISP peut constituer à lui seul un ordinateur contrôlable à distance dont le mot de passe est détenu par votre FAI. Il y a eu, dans le passé, des problèmes de sécurité quand les mots de passe constructeur (ceux qui sont utilisés quand le FAI oublie le mot de passe qu'il a attribué) ont été connus par des « pirates ». Si possible, vous devriez planifier votre sécurité en prenant comme hypothèse que le routeur est potentiellement hostile. C'est à dire qu'il pourrait utiliser n'importe quelle adresse dans vos plages publique ou privée, qu'il pourrait rediriger les paquets sortants vers un autre site ou qu'il pourrait enregistrer tout ce qui lui passe au travers.

8.1 Configurer votre pare-feu (firewall)

Cette section traite de la configuration d'un routeur de filtrage, de masquage et de transport basé sur ipchains. Vous devriez certainement lire d'abord le IPCHAINS-HOWTO (à l'adresse ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/IPCHAINS-HOWTO ; http://www.freenix.org/unix/linux/HOWTO/IPCHAINS-HOWTO.html en version française) puis chercher ici des conseils additionnels. Ce HOWTO décrit les étapes pour configurer un noyau avec support de masquage (masquerading) et décrit en détail l'utilisation de l'exécutable. Vous devriez activer le pare-feu sur toutes les machines ayant une IP exposée.

Vérifiez vos scripts de démarrage afin de vous assurer que leur enchaînement est comme suit sur la passerelle de réseau privé :

  1. la carte Ethernet est initialisée
  2. les règles de pare-feu sont passées en revue par ipchains
  3. le transport est activé
  4. les démons des services réseau sont démarrés

Ainsi, à titre d'exemple, sur un système basé sur la Slackware, la configuration du pare-feu devrait intervenir entre l'exécution du rc.inet1 et du rc.inet2. En outre, si un quelconque problème apparaît au cours des étapes de démarrage du pare-feu, un avertissement devrait être affiché et la carte réseau externe désactivée avant que les services réseau ne soient lancés.

Un problème courant avec les pare-feu basés sur ipchains est de s'assurer que les règles sont correctement positionnées selon que les paquets arrivent sur l'interface de loopback, ou depuis l'une des deux interfaces, interne ou externe. Les paquets d'origine locale peuvent être bloqués par le pare-feu. Trop souvent, ceci est réglé par une espèce de débogage bricolé rapidement où les règles du pare-feu sont manipulées jusqu'à ce que l'application semble fonctionner à nouveau correctement sur le pare-feu. Malheureusement, ceci peut parfois aboutir à un dispositif qui a des trous de sécurité involontaires. Avec ipchains, il est possible d'écrire un script de firewall qui peut être facilement débogué et peut éviter beaucoup de problèmes. Voici un script d'exemple /sbin/firewall.sh :

#! /bin/sh
#
# Nouveau script de firewalling utilisant IP chains. Crée un routeur filtrant
# avec masquage de réseau
#
# définition de quelques variables
IPCHAINS=/sbin/ipchains
LOCALNET="192.168.1.0/24"       # le réseau privé
ETHINSIDE="192.168.1.1"         # IP privée de fred.example.com #
ETHOUTSIDE="10.1.1.9"           # IP publique de fred.example.com #
LOOPBACK="127.0.0.1/8"
ANYWHERE="0/0"
OUTSIDEIF=eth1                  # interface privée de fred.example.com
FORWARD_PROCENTRY=/proc/sys/net/ipv4/ip_forward
#
# Ces deux commandes retourneront des codes d'erreur si les règles
# existent déjà (ce qui se produit si vous exécutez le script
# de pare-feu plus d'une fois). On met ces commandes avant « set -e »
# comme ça, dans ce cas le script n'est pas interrompu.
$IPCHAINS -N outside
$IPCHAINS -N portmap
set -e                  # Abandonne immédiatement si des erreurs se produisent
 # lors de l'installation des règles.
#
# Arrête la redirection de ports et initialise les tables
echo "0" > ${FORWARD_PROCENTRY}
$IPCHAINS -F forward
$IPCHAINS -F input
$IPCHAINS -F output
$IPCHAINS -F outside
$IPCHAINS -F portmap
#
# Masque les paquets en provenance de notre réseau local
# à destination du monde extérieur. Ne masque pas les
# paquets locaux à destination locale.
$IPCHAINS -A forward -s $LOCALNET -d $LOCALNET -j ACCEPT
$IPCHAINS -A forward -s $ETHOUTSIDE -d $ANYWHERE -j ACCEPT
$IPCHAINS -A forward -s $LOCALNET -d $ANYWHERE -j MASQ
#
# Positionne les signaux de priorité. Délais minimum
# de connexion pour www, telnet, ftp et ssh (paquets sortants
# uniquement).
$IPCHAINS -A output -p tcp -d $ANYWHERE www -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE telnet -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE ftp -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE ssh -t 0x01 0x10
#
# n'importe quel paquet venant de notre classe C locale doit
# être accepté comme le sont les paquets provenant de l'interface
# de loopback  et l'interface externe de fred
$IPCHAINS -A input -s $LOCALNET -j ACCEPT
$IPCHAINS -A input -s $LOOPBACK -j ACCEPT
$IPCHAINS -A input -s $ETHOUTSIDE -j ACCEPT
#
# On va créer un jeu de règles pour les paquets provenant du grand,
# méchant monde extérieur, et puis y attacher toutes les interfaces
# externes. Ces règles seront appelées « outside ».
#
# On crée également une chaîne « portmap ». Les sockets utilisées
# par les démons référencés par le portmapper RPC ne sont pas
# fixes, il est donc un peu difficile de leur attribuer des
# règles de filtrage. La chaîne portmap est configurée dans un
# script à part.
#
# Paquets envoyés depuis n'importe quelle interface extérieure
# à la chaîne « outside ». Ceci inclut l'interface $OUTSIDEIF
# et toute interface ppp utilisée pour se connecter (ou fournir
# une connexion).
$IPCHAINS -A input -i ${OUTSIDEIF} -j outside
$IPCHAINS -A input -i ppp+ -j outside
##################################################
#
#  installe les règles de la chaîne « outside »  #
#
##################################################
#
# Personne de l'extérieur ne devrait pouvoir se faire
# passer comme venant de l'intérieur ou du loopback.
$IPCHAINS -A outside -s $LOCALNET -j DENY
$IPCHAINS -A outside -s $LOOPBACK -j DENY
#
# Aucun des paquets routés vers notre réseau local
# ne peut venir de l'extérieur car l'extérieur
# n'est pas censé connaître nos adresses IP privées.
$IPCHAINS -A outside -d $LOCALNET -j DENY
#
# Bloque les connexions entrantes sur les ports X. Bloque 6000 à 6010.
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 6000:6010 -j DENY
#
# Bloque les ports NFS 111 et 2049.
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 111 -j DENY
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 2049 -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 111 -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 2049 -j DENY
#
# Bloque les paquets xdm venant de l'extérieur, port UDP 177.
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 177 -j DENY
#
# Bloque le port 653 YP/NIS .
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 653 -j DENY
#
# On ne va pas s'embêter avec des logins sur le port TCP 80, le port www.
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 80 -j DENY
#
# Accepte des connexions données et contrôle FTP.
$IPCHAINS -A outside -p TCP -s $ANYWHERE 20:21 -d $ANYWHERE 1024: -j ACCEPT
#
# Accepte les paquets ssh.
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE ssh -j ACCEPT
#
# Accepte les paquets DNS depuis l'extérieur.
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 53 -j ACCEPT
$IPCHAINS -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 53 -j ACCEPT
#
# Accepte SMTP depuis partout.
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 25 -j ACCEPT
#
# Accepte les paquets NTP.
$IPCHAINS -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 123 -j ACCEPT
#
# N'accepte pas les paquets d'indentification, on ne les utilise pas.
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 113 -j DENY
#
# Désactive et journalise tous les autres paquets entrants,
# TCP ou UDP, sur les ports privilégiés.
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE :1023 -y -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE :1023 -j DENY
#
# Contrôle basé sur les règles de portmapper.
$IPCHAINS -A outside -j portmap
##############################################
#
#  Fin des règles de la chaîne « outside »   #
#
##############################################
#
# Bloque les paquets rwho sortants.
$IPCHAINS -A output -p UDP -i $OUTSIDEIF -s $ANYWHERE 513 -d $ANYWHERE -j DENY
#
# Empèche les paquets netbios de s'échapper.
$IPCHAINS -A output -p UDP -i $OUTSIDEIF -s $ANYWHERE 137 -d $ANYWHERE -j DENY
#
# Active le routage.
echo "1" > ${FORWARD_PROCENTRY}

Remarquez que le pare-feu peut être utilisé non seulement pour les paquets entrants mais aussi pour les paquets sortants qui pourraient dévoiler des informations sur votre réseau privé tels que des paquets « rwho » ou « netbios ».

Comme noté plus haut, les règles du portmapper sont légèrement différentes car les démons portmap s'abonnent eux-mêmes au portmapper et sont renseignés sur les ports à écouter. Les ports utilisés par un démon quelconque peuvent changer si vous modifiez les services RPC utilisés ou si vous changez leur ordre de démarrage. Le script suivant, /sbin/firewall.portmap.sh, génère les règles pour le démon portmap.

#! /bin/sh
#
ANYWHERE=0/0
IPCHAINS=/sbin/ipchains
$IPCHAINS -F portmap
# Règles pour empêcher l'accès aux services portmappés aux personnes de l'extérieur.
#
/usr/bin/rpcinfo -p | tail +2 | \
 { while read program vers proto port remainder
 do
 prot=`echo $proto | tr "a-z" "A-Z"`
 $IPCHAINS -l -A portmap -p $prot -s $ANYWHERE -d $ANYWHERE $port -j DENY || exit 1
 done
 }

Nous n'avons pas à nous soucier du fait que les paquets entrants sont des paquets « légitimes » en provenance du réseau privé ou non, la chaîne portmap n'est vérifiée que quand les paquets proviennent de l'extérieur.

Cette configuration de pare-feu note la plupart des paquets suspects par l'intermédiaire de klogd avec la priorité kern.info. Elle notera les essais de connexion normaux aussi bien que tous les scans furtifs connus.

Maintenant on assemble le tout. On aimerait s'assurer qu'il n'existe pas de petite fenêtre de vulnérabilité au démarrage du système, en conséquence on configure la séquence de démarrage comme suit :

#! /bin/sh
#
# Démarrer le réseau de façon sécurisée
#
#
/etc/rc.d/rc.inet1              # configure les interfaces réseau
 # et active le routage.
/sbin/firewall.sh || { echo "la configuration du pare-feu a échoué"
 /sbin/ifconfig eth1 down }
/sbin/ipchains -I outside 1 -j DENY     # interdit tous les paquets entrants
/etc/rc.d/rc.inet2              # démarre les démons réseau
sleep 5                         # les laisse se stabiliser
# sécurise les service portmappés
/sbin/firewall.portmap.sh || { echo "la configuration du pare-feu de portmap a échoué"
 /sbin/ifconfig eth1 down }
/sbin/ipchains -D outside 1       # autorise les paquets entrants

Ceci suppose que eth1 est l'interface ayant l'adresse IP visible. Si la moindre erreur a lieu lors de l'installation d'une des règles d'ipchains, un avertissement est produit et cette interface est désactivée. La chaine « outside » est positionnée de manière à refuser tous les paquets avant que les démons de service réseau ne soient démarrés, parce que les règles de pare-feu ne sont pas encore en place pour les services portmappés. Une fois que ces services sont protégés par le pare-feu, la chaîne « outside » est rendue à son comportement normal.

8.2 Configurer OpenSSH ou SSH1

à l'heure où j'écris, Open SSH, aussi bien que SSH1, offre désormais des possibilités de configuration permettant d'intégrer scp, ssh et slogin comme des exécutables sous les noms rcp, rsh et rlogin avec un retour transparent, dans les programmes clients ssh, aux rsh, rcp ou rlogin d'origine quand le site distant n'exécute pas sshd. Faire en sorte que l'invocation de rsh exécute à sa place le client ssh est, à mon avis, important pour conserver une sécurité facile à utiliser et pour en décharger les utilisateurs. Les scripts de tout le monde, les configurations de rdist, etc. continueront à fonctionner sans modification si le site distant exécute sshd, mais les données seront envoyées chiffrées avec une forte certification de l'hôte. La réciproque n'est pas toujours vraie. Tout spécialement si la machine distante n'exécute pas sshd, le programme rsh enverra un message à l'écran, avertissant que la connexion n'est pas chiffrée. Ce message provoque une erreur avec rdist et probablement avec d'autres programmes. Il ne peut être supprimé par des options en ligne de commande ou de compilation. Pour rdist, une solution est d'appeler le programme avec -p /usr/lib/rsh/rsh.

Récupérez ssh1 depuis le site de ssh (à : http://www.ssh.org), ou OpenSSH depuis son site (à : http://www.openssh.org), et compilez-le pour remplacer les « programmes en r » (rsh, rlogin et rcp) non chiffrés. D'abord, copiez ces trois fichiers dans /usr/lib/rsh, puis configurez le paquet ssh avec :

./configure --with-rsh=/usr/lib/rsh/rsh --program-transform-name='s/^s/r/' --prefix=/usr

Installez les exécutables et configurez-les en fonction des directives. Sur la passerelle de réseau privé, assurez-vous que la configuration de sshd comprend bien les entrées suivantes : 

ListenAddress 192.168.1.1       # l'adresse interne de fred
IgnoreRhosts no
X11Forwarding yes
X11DisplayOffset 10
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes

Vous serez amené à effectuer des réglages supplémentaires dans le fichier /etc/sshd_config, mais essayez de ne pas changer ces champs. Une fois que vous avez réglé toutes les entrées du fichier sur les valeurs qui vous conviennent, copiez le fichier vers un nouveau fichier, /etc/sshd_config.ext, pour le réseau externe. Changez deux entrées dans le nouveau fichier : la valeur de « ListenAdress » doit être remplacée par l'adresse IP de la passerelle de réseau privé (10.1.1.9 dans notre exemple de fred.example.com) et « PasswordAuthentication » doit être positionné sur « no » dans /etc/sshd_config.ext. Dans vos scripts de démarrage des services réseau, faites démarrer sshd deux fois, une fois avec 

/usr/sbin/sshd

et une fois avec 

 /usr/sbin/sshd -f /etc/sshd_config.ext

Ceci lancera deux démons sshd. Celui opérant sur l'interface interne autorisera les connexions avec mot de passe, mais l'interface externe exigera la validation d'une clé RSA avant que quiconque puisse se loguer.

Ensuite, désactivez les services telnet et shell dans le fichier de configuration de inetd (notez que la configuration proposée dans la section Configurer votre pare-feu empêche déjà les accès depuis l'extérieur, mais il est préférable de se défendre en profondeur, ne vous en remettez pas au fait que tout fonctionne correctement).

Les personnes qui veulent pouvoir se connecter depuis leur domicile ou depuis un lieu de déplacement auront besoin une clé RSA. Assurez-vous qu'elles savent comment procéder de façon à ce qu'elles ne gaspillent pas leur énergie à essayer de mettre en place un autre moyen de se connecter comme, par exemple, exécuter un telnetd sur un port sans privilège sur la machine pare-feu.

Une clé RSA est générée par la commande suivante : 

ssh-keygen -b 1024 -f new_rsa_key

Vous serez invité à entrer une phrase-clé (passphrase). Celle-ci ne doit pas être vide. Une personne ayant un accès au fichier new_rsa_key et connaissant la phrase-clé a tout ce qu'il lui faut pour réussir un défi d'authentification RSA. La phrase-clé peut être un mot de passe « introuvable » ou une phrase longue, mais choisissez quelque chose de pas banal. Le fichier new_rsa_key peut être copié sur une disquette ou sur un portable et, en association avec la phrase-clé, peut être utilisé pour se connecter sous les comptes paramétrés pour accorder l'accès à cette clé RSA précise.

Pour configurer un compte de façon à ce qu'il soit accessible par une clé RSA, créez simplement un répertoire $HOME/.ssh pour cet utilisateur sur la passerelle de réseau privé (c'est à dire la machine qui recevra la demande de connexion), et copiez le fichier new_rsa_key.pub qui a été créé par la commande « ssh-keygen » dans le fichier $HOME/.ssh/authorized_keys. Pour des détails sur les autres options que vous pouvez ajouter à la clé, telles qu'obliger la demande de connexion à provenir d'une certaine adresse IP ou d'un certain nom d'hôte, ou bien permettre à la clé de n'autoriser l'invocation à distance que de certaines commandes seulement (par exemple une clé RSA qui ne fait que commander le début d'une sauvegarde ou l'envoi par mail à l'extérieur du site d'un rapport d'état), reportez-vous à la section « AUTHORIZED_KEYS FILE FORMAT » dans la page de manuel de sshd.

Il reste une seule chose à faire pour rendre le mécanisme de chiffrement RSA aussi simple que possible pour les utilisateurs. Si l'utilisateur est obligé d'entrer la phrase-clé plus d'une fois ou deux au cours de sa session, il va vraisemblablement finir par être gêné et par prendre en main les questions de sécurité. Sous Linux, faites en sorte que son shell de login soit invoqué sous ssh-agent. Par exemple si les portables de société utilisés en déplacement exécutent xdm et basculent les utilisateurs sous une session X, allez dans le fichier /var/X11R6/lib/xdm/Xsession_0 et modifiez les lignes qui lancent le démarrage et qui sont probablement du type :

exec "$startup"

par des lignes du type :

exec ssh-agent "$startup"

Dans mon paramétrage de xdm il y a trois lignes dans ce fichier qui ont dû être modifiées. Maintenant, quand l'utilisateur ouvre une session sur le portable, il saisit la commande 

ssh-add new_rsa_key

sous n'importe quel prompt, il saisit la phrase-clé quand il y est invité et toutes les fenêtres auront accès sans phrase-clé au compte sur la passerelle de réseau privé jusqu'à ce que l'utilisateur déconnecte la session X sur le portable.

Exécutez sshd sur toutes les machines de votre réseau privé, autant que sur vos hôtes exposés. Pour les autres machines que la passerelle, l'entrée ListenAdress dans le fichier /etc/sshd_config peut-être positionnée sur « 0.0.0.0 ». Vous devez mettre en place les clés des hôtes avec la commande :

ssh-keygen -b 1024 -f /etc/ssh_host_key -N ""

puis exécuter make-ssh-known-hosts et distribuer le fichier /etc/ssh_know_hosts sur toutes les machines du réseau privé.

Désactivez le telnet entrant et les « services en r » non chiffrés. Ne supprimez pas l'exécutable telnet, il est utile pour d'autres choses que de simples connexions telnet sur le port 23. Vous pouvez autoriser l'identification par mot de passe sur le réseau privé et la désactiver sur les machines exposées, en imposant une clé RSA pour la connexion sur les hôtes exposés.

Il est pratique pour les utilisateurs que les hôtes du réseau se répertorient les uns les autres dans le fichier /etc/hosts.equiv. Les démons sshd prendront ceci en compte et permettront aux personnes de se connecter à distance ou d'exécuter des shells à distance entre machines sans mot de passe ou phrase-clé. À chacune des connexions, les machines vérifieront leurs identités respectives avec des clés RSA au niveau machine.

Une difficulté apparaît quand un utilisateur connecté sur une machine du réseau privé veut se connecter sur une machine ayant une adresse IP publique. Vous ne pouvez pas utiliser /etc/hosts.equiv ou $HOME/.shosts pour permettre une identification sans mot de passe parce que l'utilisateur est sur une machine dont l'adresse IP ne peut être déterminée - elle semblera venir du pare-feu, mais les clés-machine ne fonctionneront pas. Il y a deux solutions à cela. D'abord, si vous voulez vraiment utiliser les méthodes /etc/hosts.equiv ou $HOME/.shosts, l'utilisateur devra se connecter à la passerelle de réseau privé (fred.example.com dans notre exemple actuel) et ensuite se connecter sur la machine exposée depuis cet endroit. L'autre technique consiste à utiliser l'authentification RSA qui fonctionne toujours indépendamment des fantaisies du mécanisme de résolution et d'adresses IP occasionnées par votre configuration.

8.3 Configurer X

La quête perpétuelle de l'utilisateur pour prouver qu'il privilégie la facilité d'utilisation par rapport à la sécurité, a rendu commun l'usage de la commande 

xhost +

dans ses scripts d'initialisation de X. Ceci permet l'accès au serveur X à n'importe qui dans le monde. Maintenant, n'importe quel intrus peut remplacer votre fond d'écran par quelque chose d'embarassant juste au moment où votre chef fait visiter votre bureau à sa mère. Cet intrus peut également tranquillement surveiller tout ce que vous tapez au clavier et capturer le contenu de votre écran sur sa machine. Inutile de dire que ceci ne sied pas très bien aux mots de passe que vous utilisez pour vous connecter sur d'autres sites ou à d'autres documents sensibles affichés à l'écran. Le protocole xhost lui même a des limitations inhérentes au fait qu'il n'est pas possible d'accorder la permission d'utiliser l'affichage sur une « base utilisateur » mais seulement sur une « base machine ».

Optez pour l'identification xauth. Si vous avez xdm, vous exécutez déjà probablement l'identification xauth mais xhost fonctionne toujours et peut continuer à être utilisé par les gens pour exécuter des processus X entre machines. Une fois encore, le but est de rendre la sécurité suffisamment facile à utiliser de manière à ce que les utilisateurs ne soient plus tentés d'utiliser la commande xhost.

Le paramétrage de sshd décrit dans la section Configurer SSH1, avec l'indicateur « X11Forwarding » positionné, est actuellement plus simple d'utilisation que la technique xhost. Une fois que vous vous êtes connecté sur votre terminal, vous pouvez simplement vous « rloguer » sur une machine distante et exécuter netscape, xv ou ou ce que vous voulez sans avoir à positionner la variable $DISPLAY ou à accorder des permissions explicites. Au cours du login ssh, le système est configuré d'une manière transparente pour l'utilisateur final, et même, tous les paquets sont chiffrés avant de partir sur le réseau.

Si vous n'avez pas la possibilité d'utiliser le transfert X11 sshd pour une raison ou pour une autre, vous devrez utiliser xauth quand vous voudrez autoriser les autres machines à se connecter sur votre serveur X. Documentez ceci pour vos utilisateurs ou bien créez des scripts shell spécialisés pour les aider. La commande adéquate pour permettre une identification, « jpublic » sur la machine « barney » de façon à avoir accès au serveur est : 

/usr/X11/bin/xauth extract - $DISPLAY | rsh -l jpublic barney /usr/X11/bin/xauth merge -

Cette séquence n'est pas nécessaire pour autoriser les connexions X depuis les machines qui partagent un répertoire commun de montage NFS. La clé xauth sera immédiatement disponible aux utilisateurs de toutes les machines qui montent le même répertoire racine.

Je serais tenté d'effacer purement et simplement xhost de toutes les machines. Si ceci cause des problèmes pour quelques programmes, vous saurez au moins que ces programmes avaient une sécurité mal conçue. Il est suffisamment aisé d'écrire un script-shell qui utilise la séquence xauth décrite plus haut comme solution de remplacement pour xhost.

Notez que, si rsh n'est pas le programme de chiffrement de ssh, la clé xauth est envoyée sous forme de texte. Quiconque s'empare du texte de la clé peut accéder à votre serveur, ainsi vous ne gagnez pas beaucoup de sécurisation si vous n'utilisez pas ssh pour ces transactions. Notez également que si les répertoires home des utilisateurs sont exportés via NFS (Network File System) la clé xauth est disponible en clair pour n'importe quelle personne en mesure d'espionner ces paquets NFS, indépendamment du fait que vous exécutez ssh sur vos systèmes.

8.4 Configurer le partage de fichiers

Avec la messagerie arrivant sur une machine centralisée, les procédures de lecture et d'expédition depuis n'importe quel hôte décrites ici sont très pratiques, mais des précautions doivent être prises contre le furetage de la part d'utilisateurs locaux qui s'ennuient. NFS sans implémentation de AUTH_DES manque foncièrement de sécurité. NFS s'en remet à la machine cliente pour certifier l'accès, il n'y a pas de vérification de mot de passe sur le serveur pour s'assurer que le client est autorisé à accéder à tel fichier privé d'un utilisateur particulier. Une machine Windows peut être configurée pour lire les volumes exportés par NFS sous n'importe quel identifiant numérique en outrepassant complètement les permissions de fichiers UNIX. En conséquence, les exports NFS ne devraient être mis en place que sur les machines qui sont toujours sous Linux (ou UNIX), sous votre contrôle direct, et jamais sur celles qui ont un boot multiple avec Windows. Si vous voulez exporter le répertoire de spool de votre messagerie, ou n'importe quel autre répertoire, vers des machines qui peuvent être à l'occasion utilisées sous Windows, exportez-les avec Samba en mettant le mode d'identification sur « security=USER ». Le fait de connecter les machines sur votre réseau à l'aide d'un commutateur plutôt qu'un hub sera également bénéfique et donnera peu d'intérêt à la mise en place de renifleurs sur les machines Windows. Cependant, et en dernier lieu, il est très difficile de sécuriser un partage de fichier à travers les réseaux au moment de son écriture.

Pourquoi vous inquiéter si vous ne pouvez réellement sécuriser les disques réseau ? C'est avant tout un moyen de rendre l'ensemble de la sécurisation crédible. Si vous laissez une feuille de papier avec des informations confidentielles sur votre bureau et que quelqu'un la lit, il pourra arguer du fait qu'il n'avait pas réalisé la nature du document, sa curiosité naturelle venant juste de l'emporter quand il l'a vu posée là. Si la feuille de papier est dans un classeur ou dans un tiroir du bureau, c'est une histoire totalement différente. L'objet des mesures de sécurité en interne est surtout de s'assurer que personne ne peut accidentellement compromettre la sécurité générale.

Page suivante - Page précédente - Table des matières