acces_securitaire_grappes.html from Gulus at Krugle
Show acces_securitaire_grappes.html syntax highlighted
<PRE>
Accès sécuritaire pour grappes Linux
------------------------------------
Originalement: Secure Linux Cluster Access Infrastructure
By David Gordon and Ibrahim Haddad
Traduit par David Gordon
Adapté de l'original
-------------------------------------------------------------------------
Avec l'augmentation des grappes Linux sur l'Internet, le besoin pour
une infrastructure d'accès sécuritaire se fait sentir davantage. Cet
article tentera de démontrer comment établir un accès à distance
sécuritaire à la grappe.
-------------------------------------------------------------------------
Introduction et Historique
--------------------------
L'importance des grappes Linux continue de prendre de l'ampleur ces dernières
années en raison du faible coût matériel, la disponibilité d'une connection
Ethernet rapide, et le grand nombre d'applications open source. Linux est le
système d'exploitation de préférence pour les grappes, parce que son noyau est
très versatile et supporte plusieurs protocoles réseau.
Un critère essentiel pour une grappe est un accès à distance sécuritaire. Cet
accès est utile pour l'administration et l'utilisation à partir de l'extérieur
de la grappe. Dans cet article, nous allons expliquer comment utiliser OpenSSH,
version open source du protocol SSH, pour sécuriser son accès.
Grappes Linux: survol rapide
----------------------------
Typiquement, les grappes Linux seront connectées à l'Internet tout dépendant du
type de service qu'ils offrent. Par exemple, il existe des grappes dédiées aux
services web, alors que d'autres font du High Performance Computing (HPC).
Certaines grappes ne requiert pas de connection à l'Internet, mais souvent,
elles doivent avoir accès à un réseau externe quelconque comme un campus
universitaire.
Les grappes sont généralement composées de deux types de noeuds, soit:
- Le noeud maître, ou serveur: ce noeud est responsable de la distribution du
traffic, de la distribution de la charge, et/ou agit comme passerelle entre
l'extérieur et l'intérieur de la grappe. Certaines grappes High Availability
(HA) possède plusieurs noeud maître.
- Le noeud client: ces noeuds offrent le service qui détermine le type de grappe
Pour l'admistration de la grappe et l'usage externe, l'accès à
distance est essentiel, voire même obligatoire.
Concernant la sécurité de la grappe, l'accès externe et interne à la grappe
doivent être considérés. À l'intérieur de la grappe, les noeuds doivent pouvoir
se faire confiance. La confiance est fonction des mesures de sécurité installées
et non pas la supposition que les autres noeuds sont sécurisés par défaut.
Un accès interne se produit lorsqu'un noeud à l'intérieur de la grappe accède à
un autre noeud également à l'intérieur.
Puisqu'une grappe typique est branchée sur un réseau externe, l'authentification
et l'encryption des sessions sont très importants. Seuls les clients autorisés
doivent être en mesure de se connecter à la grappe, et ce, de façon sécuritaire.
Quand un client externe à la grappe tente de se connecter à celle-ci, cet accès
est appelé externe. Habituellement, le noeud maître doit agir comme passerelle
pour le client externe vers les noeuds de la grappe. Donc, un accès externe se
fait en deux étapes:
- Le client externe se connecte au noeud maître, du noeud maître,
- le client externe peut accèder aux noeuds internes
Nous allons essayer d'expliquer comment configurer une architecture qui
sécurisera à la fois l'accès interne et externe pour une grappe Linux en
utilisant les outils de la suite OpenSSH.
OpenSSH
-------
OpenSSH est premièrement un projet du groupe OpenBSD. OpenSSH a été inclus pour
la première fois dans la version 2.6 de OpenBSD. Ce logiciel est développé à
l'extérieur des États-Unis, utilisant du code source d'environ 10 pays sous la
license BSD.
Pour installer OpenSSH sur Linux, il faut d'abord installer OpenSSL. Par contre,
la plupart des distributions Linux l'ont déjà inclus (voir la liste dans la
section référence). Il est toujours recommandé d'utiliser la dernière version
d'OpenSSH.
Si vous voulez mettre à jour votre version d'OpenSSH, commencez par OpenSSL. À
cet effet, pour compiler OpenSSL:
% tar xzvf openssl-0.9.6g.tar.gz
% cd openssl-0.9.6g
% ./config
% make
% make install
La prochaine étape est d'installer la plus récente version d'OpenSSH:
% tar xzvf openssh-3.4p1.tar.gz
% cd openssh-3.4p1
% ./configure
% make
% make install
Ceci installera les binaires OpenSSH dans /usr/local/bin, les fichiers de
configuration dans /usr/local/etc, et le serveur dans /usr/local/sbin.
Pour tester votre installation, démarrez le serveur OpenSSH sur le noeud courant
et essayez de vous connecter localement:
% sshd
% ssh localhost
your_user@localhost's password:
Last login: Tue Oct 8 12:48:54 2002 from :0
%
Remarquez que par défaut ssh tentera de valider votre clé publique et ensuite,
votre mot de passe système ("ssh -v localhost" pour plus de détails). Puisque
nous n'avons pas encore créé de clé publique/privée, l'authentification se fait
par mot de passe système.
OpenSSH contient un script pour chaque distribution Linux qui permet de démarrer
et arrêter le serveur ssh en même temps que le système d'exploitation.
Parfois, il est utile d'avoir un accès externe toujours disponible. Dans la
réalité, il arrive que le serveur ssh plante. Le script qui suit s'assure que le
serveur est toujours fonctionnel, sinon il le repart. En introduisant ce script
dans le crontab, il est possible de vérifier le serveur ssh tous les 5 minutes
par exemple.
Le script /etc/chk-sshd.pl:
#!/usr/bin/perl -w
#process entry
$ps_entry = "/usr/local/sbin/sshd";
$sshd_path = "/usr/local/sbin/sshd";
@processes = `ps -ax`;
$n = @processes;
$is_running = 0;
for ($i = 0; $i < $n; $i++) {
if ($processes[$i] =~ /$ps_entry/) {
$is_running = 1;
}
}
if (not $is_running) {
`$sshd_path &`;
}
Pour exécuter ce script tous les 5 minutes, modifiez le crontab
('crontab -e') en ajoutant la ligne suivante:
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /etc/chk-sshd.pl
La prochaine section explique comment sécuriser l'accès à la grappe.
Accès par mot de passe
----------------------
Pour différentes grappes, différents accès sont nécessaires et OpenSSH nous
fournit différentes possibilités d'accès. L'accès par mot de passe peut utiliser
les 2 protocols SSH et est une des méthodes d'accès par défaut à l'installation
d'OpenSSH. Il est préférable d'utiliser le protocol 2 de SSH (SSH2), puisqu'il
est plus robuste que SSH1. Pour une description complète de SSH2, référez-vous
au Internet Engineering Task Force draft pour le Secure Shell (SecSH).
À des fins démonstratives, nous allons utiliser server-node pour représenter les
noeuds ayant un serveur ssh et client-node pour représenter les noeuds accèdant
au server-node. À noter, le server-node n'est pas le noeud maître.
L'avantage de l'accès par mot de passe demeure dans le fait qu'aucune
configuration supplémentaire n'est requise. Par contre, il serait plus
sécuritaire de s'assurer que la ligne "Protocol 2" soit dans le fichier de
configuration du serveur ssh (/usr/local/etc/sshd_config). Ceci nous assure
que le protocol SSH1 ne sera pas utilisé.
Une fois le serveur ssh en fonction sur server-node, initialisez une connection
de client-node vers server-node pour vérifier si l'installation s'est bien
produite:
client-node% ssh server-node
The authenticity of host 'server-node (192.168.10.1)' can't be established.
RSA key fingerprint is 32:a1:54:e3:2d:84:88:26:5f:f0:70:8b:34:0f:4d:7a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server-node,192.168.10.1' (RSA) to the list of
known hosts.
your_user@server-node's password:
Last login: Mon Oct 28 14:10:26 2002
server-node%
Le message d'avertissement signifie que c'est la première fois que client-node
se connecte à server-node. Le mot de passe correspond à celui que l'on retrouve
dans ie. /etc/passwd.
Attention, il faut être conscient des dangers potentiels que pose ce mode
d'accès. Premièrement, l'idée d'envoyer un mot de passe système via le réseau,
surtout celui de root, n'est pas sécuritaire pour dire le moins. À la place, il
serait plus avantageux d'utiliser une paire de clés privée/publique protégée par
passphrase. Le dommage que peut causer un utilisateur mal intentionné pourrait
causer dépend largement du mode d'accès choisi. En général, un mot de passe
système est plus compromettant qu'une clé privée, supposant qu'elle est seulment
utilisée pour l'accès avec ssh.
Pour une couche supplémentaire de sécurité, le serveur ssh peut être exécuté
à l'intérieur d'un TCP-wrapper. On peut ainsi contrôler l'accès en spécifiant
quels clients peuvent se connecter à la grappe. À noter, utiliser un TCP-wrapper
n'implique utiliser tcpd, même lorsque sshd (daemon) est démarré à l'intérieur
d'inetd. Le serveur sshd est en mesure de vérifier /etc/hosts.allow et
/etc/hosts.deny par lui-même. Par contre, faites attention lorsque vous
configurez ces deux fichiers d'accès, car d'autres applications les consultent
également. Pour activer l'option de TCP-wrapping dans le server sshd d'OpenSSH
(le serveur qui serait sur server-node):
% ./configure --with-tcp-wrappers
% make
% make install
# Restart OpenSSH daemon
Ceci n'affectera que le serveur sshd et non pas le client ssh. Pour vérifier,
ajouter la ligne "sshd: ALL" dans le fichier /etc/hosts.deny et remarquez que
vous ne serez plus en mesure d'ouvrir une session ssh vers localhost (qui roule
le serveur sshd bien entendu). Ensuite, enlever cette ligne et rajoutez-la
à /etc/hosts.allow. La connection devrait s'établir maintenant:
% ssh localhost
your_user@localhost's password:
Last login: Tue Oct 29 10:49:59 2002 from localhost.localdomain
%
Dans la prochaine section, nous présenterons une infrastructure de clés
publiques/privées qui devraient assurer une meilleure sécurité d'accès à
la grappe que l'accès par mot de passe.
Infrastructure d'accès à clé publique
-------------------------------------
Pour l'accès externe à la grappe, l'authentification par clé publique est
fortement recommandé. Notre infrasture d'accès à clé publique utilisera SSH2.
De plus, voici quelques avertissements:
a) Ne jamais permettre à root une connection directe: seulement permettre à
un usager, une fois connecté, de faire 'su' à root.
b) Il est recommandé d'utiliser des clés 1024 bits. Une clé moins longue que
1024 signifie qu'elle est plus facile à cryptanalyser et plus longue, aucune
sécurité n'est ajoutée, mais la communication est ralentie.
Pour la démonstration suivante, un client externe (remote-host) se connectera
au noeud maître, représenté par server-node.
Premièrement, expliquons comment configurer une infrastructure d'accès à clé
publique.
1) Sur remote-host: exécuter "ssh-keygen -t dsa" pour générer une paire de clés
publique/privée DSA. Ceci créera 'id_dsa' et 'id_dsa.pub' qui sont la clé
privée et publique dans l'ordre. Elles devraient se retrouver dans le
répertoire ~/.ssh par défaut.
Assurez-vous que la clé privée, 'id_dsa', reste dans le répertoire par défaut
~/.ssh. Ensuite, envoyez la clé publique 'id_dsa.pub', à server-node. Vous
pouvez utiliser 'scp' pour envoyer la clé à server-node. Dans ce cas, server-
node doit être en train de rouler un serveur ssh:
remote-host% scp id_dsa.pub server-node:~/.ssh/
your_user@server-node's password:
id_dsa.pub 100% |*****************************| 616 00:00
2) Sur server-node, ajouter le contenu de la clé publique à la fin du fichier
authorized_keys2, par défaut situé dans ~/.ssh:
server-node% cd ~/.ssh
server-node% cat id_dsa.pub >> authorized_keys2
3) La dernière étape est de configurer le serveur sshd pour utiliser seulement
SSH2 ainsi que l'accès à clé publique. Voici un fichier de configuration
pour /usr/local/etc/sshd_config:
Port 22
Protocol 2
HostKey /usr/local/etc/ssh_host_dsa_key
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 600
PermitRootLogin no
AllowUsers your_user
StrictModes yes
RSAAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys2
RhostsAuthentication no
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication yes
IgnoreUserKnownHosts yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
KerberosAuthentication no
AFSTokenPassing no
KerberosTgtPassing no
PAMAuthenticationViaKbdInt no
X11Forwarding no
KeepAlive yes
UseLogin no
UsePrivilegeSeparation yes
Ci-dessous, nous expliquons certaines lignes importantes du fichier de
configuration:
- "Protocol 2" signifie que seulement le second protocol (SSH2) sera
utilisé, sinon SSH1 serait utilisé si SSH2 échouait.
- "ServerKeyBits 1024" force le serveur à utilisé des clés 1024 bits
- Le seul type d'accès permis est par clé publique
"PubkeyAuthentication yes".
- "PermitRootLogin no" et "AllowUsers your_user" nous permet de
spécifier quels usagers nous voulons permettre l'accès en plus de
désactiver l'accès à root. L'usage de clés publiques accomplit un
effet semblable.
- Toutes les autres lignes désactivent des options indésirables pour
notre infrastructure.
Il est possible d'exécuter en mode batch avec l'accès par clé publique. Il
s'agit simplement de n'entrer aucun mot de passe lors de la création de la
paire de clés publique/privée. Ce n'est pas une méthode d'accès recommandée,
sauf que la sécurité retient aussi de la gestion du risque. Parfois, il est
nécessaire d'exécuter en mode batch. Mais, la sécurité d'un ensemble est
seulement aussi solide que le plus faible des éléments. Alors, supposons
que le serveur sshd est en écoute sur internal-node2 et que le client est
internal-node. Avec aucun mot de passe spécifié, l'accès au serveur se fera
automatiquement:
internal-node% ssh internal-node2
Last login: Sun Oct 13 19:44:11 2002 from internal-node
internal-node2%
Important: le serveur sshd ne lira pas
/user_home/.ssh/authorized_keys2 à moins qu'il soit read-write pour le
propriétaire uniquement. Après avoir redémarré le serveur sshd, un accès par
clé publique (DSA) à server-node de remote-host devrait ressembler à ceci:
remote-host% ssh server-node
Enter passphrase for DSA key '/user_home/.ssh/id_dsa':
Last login: Tue Oct 1 05:33:00 2002 from remote-host
server-node%
Maintenant, vous pouvez considérer que vous avez un accès sécuritaire à votre
grappe Linux. Par contre, il y a quelques faiblesses que nous devrions examiner
afin de les éviter si possible.
Faiblesses SSH
--------------
"La force du Mur dépend du courage de ceux qui le défendent."
- Genghis Khan lorsqu'il conquérit le Mur de Chine
Historiquement, le protocol SSH a évolué du protocol SSH1 à SSH2. SSH2 est
la version courante du protocol, mais une interopérabilité est préservée
avec SSH1 (ce qui cause plusieurs faiblesses). Le protocol SSH2 remédie à
quelques limitations (et non vulnérabilités) dans SSH1 telles que l'absence
des 'message authentication codes' (MACs).
Il y a une vulnérabilité possible dans le serveur sshd d'OpenSSH dans le
'challenge response authentication', à moins que "UsePrivilegeSeparation yes"
est défini dans le fichier de configuration du serveur sshd. Cette
vulnérabilité peut être exploitée à distance and permettrait à un usager
malicieux d'exécuter des commandes en tant que root.
Dernièrement, il est fortement recommandé de garder la version
d'OpenSSH à jour. Des vulnérabilités et limitations sont fréquemment
trouvées and remediées dans les nouvelles versions.
Conclusion
----------
Dans cet article, nous avons présenté une solution open source pour
sécuriser l'accès externe et interne. OpenSSH rejoint les besoins de
base en matière d'accès sécuritaire. Nous avons démontré comment créer
une infrastructure d'accès par clé publique.
Nous recommandons OpenSSH comme solution open source pour l'accès aux
grappes. OpenSSH assure l'intégrité d'une session et demeure assez
flexible pour s'adapter à différents scénarios.
References
----------
IETF SSH2 protocol <A HREF="http://www.ietf.org/internet-drafts/draft-ietfsecsh-transport-15.txt">http://www.ietf.org/internet-drafts/draft-ietf-</A>
<a href="http://www.ietf.org/internet-drafts/draft-ietfsecsh-transport-15.txt">secsh-transport-15.txt</A>
Man-in-the-middle <A HREF="http://sysadmin.oreilly.com/news/silverman_1200.html">http://sysadmin.oreilly.com/news/silverman_1200.html</A>
OpenSSH <A HREF="http://www.openssh.org/">http://www.openssh.org/</A>
OpenSSH advisory <A HREF="http://www.ciac.org/ciac/bulletins/m-095.shtml">http://www.ciac.org/ciac/bulletins/m-095.shtml</A>
SecSH IETF draft <A HREF="http://www.ietf.org/internet-drafts/draft-ietf-secsh-dh-group-exchange-02.txt">http://www.ietf.org/internet-drafts/draft-ietf-</A>
<A href="http://www.ietf.org/internet-drafts/draft-ietf-secsh-dh-group-exchange-02.txt">secsh-dh-group-exchange-02.txt</A>
</PRE>
See more files for this project here