Linux Attitude

Niveau :      
Résumé : tcpwrappers ; hosts.allow ; hosts.deny

Le contrôle d'accès est généralement fourni par l'application qui fournit un service. Pour le contrôle de l'identité cette application utilise en général pam, mais de nombreuses applications effectuent des contrôles sur d'autres éléments que l'identité de la personne et en particulier le réseau. Tout comme pam il existe une bibliothèque qui s'occupe de ceci pour éviter au développeur de mal faire plusieurs choses. Parlons de tcpwrappers.

Les bases

La bibliothèque tcpwrappers permet à une application de disposer d'un contrôle du client à moindre frais. Ses deux fichiers de configuration sont /etc/hosts.allow et /etc/hosts.deny. Sa méthode de fonctionnement est très simple. Si un client a une correspondance dans hosts.allow, il est autorisé à entrer, sinon s'il a une correspondance dans hosts.deny, il est refusé, et enfin s'il ne matche aucune règle, il est accepté.

Le format de ces fichiers est assez simple :

# service : client 
sshd : 127.0.0.1

Vous pouvez remplacer le nom du service (du démon) par ALL, qui matche tous les services utilisant tcpwrappers, ou par un numéro de port (22).

Pour le nom du client, le système de matching est assez évolué. Vous pouvez donner un nom de machine (machine.toto.fr), un nom de domaine (.toto.fr), un réseau (10.0.0.0/24), un netgroup NIS (@groupe), une IPv6 (1:2:3:4:5:6:7:8/64) ou même une liste en provenance d'un fichier un peu plus complet (/etc/deny). Les wildcards shell fonctionnent aussi dans ces règles (*.toto.fr). Notez que si le serveur dns est indisponible, les règles basées sur les noms ne matchent pas, donc en l'absence de règles sur l'ip, l'accès sera au final autorisé.

Des alias existent aussi pour les clients, les plus importants sont ALL (tout le monde), LOCAL (attention, il ne fait pas exactement ce à quoi on s'attend, il matche les machines dont le nom n'a pas de domaine), et PARANOID (on vérifie que le dns direct et reverse correspondent).

Désolé pour le peu d'articles en ce moment, je suis très occupé. Et cela devrait durer tout le mois de mai.

Quoi qu'il en soit, n'oubliez pas que dans ce monde, vous ne trouverez que ce que vous y mettez. Avant que vous ne m'abandonniez, je vous propose donc d'écrire vous même quelques articles. Je sais que c'est la deuxième fois que je le propose, mais je vais en changer un peu la forme.

Étant donné que mon problème est un problème de temps et non pas d'idées, je vous propose une liste d'articles et si le sujet vous intéresse, dites-le moi, je vous enverrai les choses importantes à dire où à faire sur le sujet.

Donc imaginez vous tout savoir sur :

• l'utilisation de getopt, getopts et consorts dans vos programmes (ou scripts)
• le fonctionnement de memcached (partage de cache entre machines)
• le fonctionnement de l'anycast
• les des vpn avec vtun
• l'utilisation de tcpdump/wireshark pour mieux savoir sur ce qui se passe sur le réseau
• la différence entre archive et sauvegarde
• comment réduire votre distribution debian au plus léger possible
• utiliser des contrôles d'accès étendus sur votre système de fichier

Je laisse bien sûr place à vos idées, et il m'en reste environ 300 comme celles-là alors n'hésitez pas.

Et sinon je vous laisser patienter, il peut se passer un peu de temps avant mon prochain article.

Peck.

Niveau :      
Résumé : pam

Le contrôle d'accès est généralement fourni par l'application qui fournit un service. Pour le ftp, on effectue un contrôle des logins et mots de passe, il en va de même pour gdm et les applications qui nécessitent un utilisateur, Pour cela, la bibliothèque pam est toute indiquée.

PAM (Pluggable Authentication Module) est une bibliothèque servant exclusivement à l'authentification. Je vous en ai déjà parlé plusieurs fois ici et encore là. Comme quoi, c'est presque aussi utilisé que ssh.

La bibliothèque PAM

Pam assure une authentification sécurisée et le fait bien, dans la grande tradition unix, 'do only a single thing, but to do it well'. Il ne fournit que 4 fonctionnalités :

• auth : authentification, je m'appelle Obiwan et je peux le prouver
• account : accès au compte, j'ai le droit de rentrer dans Mos Eisley à 6h du matin
• password : gestion de l'authentification, je veux changer mon mot de passe en "Use the force Luke"
• session : sers moi un verre avant que j'entre dans le bar et fait le ménage quand j'en sors

Une application qui gère une authentification doit au moins appeler une de ces fonctions (généralement auth, account et session). Notez que pam étant une bibliothèque, l'appel est fait en tant que l'utilisateur sous lequel tourne l'application. Généralement, c'est root (il n'y a que root qui puisse devenir un autre utilisateur), par exemple dans le cas de su ou login, mais cela peut aussi être un simple utilisateur comme pour xscreensaver (il n'appelle que la fonctionnalité auth).

Ces fonctions ne sont pas rendues pas la bibliothèque pam elle-même, mais par des modules. Cette conception permet de faire fonctionner des authentifications spéciales sur des outils qui ne sont pas nécessairement conçus pour. En effet, tout le monde utilise le module pam_unix qui fournit les fonctionnalités d'authentification unix historiques, dont la gestion de /etc/shadow et /etc/passwd. Mais il existe bien d'autres modules aux fonctionnalités intéressantes que nous verrons par la suite.

La configuration de PAM

Chaque application utilisant pam est configurée séparément dans un fichier du répertoire /etc/pam.d. Bien sûr, pam autorise l'inclusion de fichiers communs pour vous faciliter la vie. Le format de ces fichiers est assez simple, il s'agit d'une succession de lignes :

# fonctionnalité   priorité   module       paramètres du module
auth               required   pam_unix.so  nullok_secure

Les priorités les plus courantes sont required et sufficient dont le sens est plutôt explicite. Vous pouvez obtenir un contrôle très fin en fonction des valeurs de retour de chaque module, tout ceci est expliqué en détail dans le man de pam.conf.

Niveau :      
Résumé : pam_tally

Aujourd'hui un conseil qu'il faut éviter de suivre. C'est pour vous éveiller l'esprit ;-) C'est aussi l'occasion de vous montrer qu'il ne faut pas prendre pour argent comptant ce qu'on trouve sur le net, il faut savoir faire correspondre à vos besoins réels les solutions toutes faites qu'on vous y propose (sauf ici bien sûr).

Nous allons donc étudier un module indispensable : pam_tally. Ce module est un module pam, c'est à dire générique à toute authentification sur unix (où presque, on me siffle dans l'oreille que slackware refuse l'utilisation de pam ...). Il permet de mettre en place une politique de limitation de tentatives d'accès.

Ça part d'une bonne idée, si vous faite 20 erreurs en tapant votre mot de passe, c'est probablement que vous êtes un méchant pirate qui tente de forcer la connexion. Par conséquent, on vous la coupe.

Comme tout plugin pam, il est presque facile a configurer :

# pam.d/common-auth
...
# deny=20 visons gros
# unlock_time=3600 si vous l'oubliez, vous risquez des ennuis
auth     required       pam_tally.so    deny=20 unlock_time=3600
...

Maintenant supposons que vous soyez vraiment un méchant pirate, quelle est la première chose que vous feriez ? 50 accès sur chaque compte que vous connaissez et hop, on rigole un coup devant Bob qui ne peut plus se connecter. Donc dans le cas de la connexion à distance c'est plutôt à l'application de faire un blocage par IP (et encore :-). Et dans le cas d'une application locale ("xscreensaver") ? Euh, vous n'avez jamais eu un ami qui vous a fait un blague sur votre poste ?

Finalement, ce plugin est-il inutile ?
Non : il a toujours son utilité, mais dans des cas très particuliers : dans votre carte de crédit, sur votre téléphone ... Son usage est en fait restreint aux applications dont on maîtrise (veut maîtriser) l'unique personne qui y a un accès physique.

Non : il peut aussi être légèrement détourné pour n'interdire que les tentatives de connexions en rafale sans vraiment bloquer l'utilisateur.

# pam.d/ssh
# lock_time=1 la fonctionnalité qui nous intéresse
auth     required       pam_tally.so   lock_time=1

Mais encore une fois, c'est à l'application de faire ceci en utilisant au mieux les données dont elle dispose (ip source, ...).