lundi, mars 14 2011

Configuration d'OpenSSH

OpenSSH est un logiciel formidable, tout le monde le sait. Quelque chose que j'aime beaucoup avec ce logiciel, c'est la manière dont son fichier de configuration permet de simplifier certaines opérations. Je vous propose de voir ou de revoir certaines options qu'on peut ajouter à la suite d'un bloc de configuration qu'on stocke généralement dans ~/.ssh/config .

La base

On va configurer l'accès à la machine "testdrive" dont l'adresse IP est 192.168.13.37. Commençons avec les informations de base :

Host testdrive
        HostName 192.168.13.37
        User nils
        Protocol 2
        Port 22
        ServerAliveInterval 5

Lorsque que je taperai la commande "ssh testdrive", OpenSSH me connectera à la machine 192.168.13.37 en tant qu'utilisateur nils, en utilisant la version 2 du protocole SSH, sur le port 22 et vérifiera toutes les 5 secondes si la machine en question est toujours joignable, ce qui peut s'avérer pratique dans certains cas où on peut être déconnecté du réseau pour cause d'inactivité (réseau de téléphonie mobile, proxy...)

Connexion au travers d'un proxy HTTP

ProxyCommand /usr/bin/corkscrew monproxy.lan 3128 %h %p ~/.ssh/proxy_auth

Ici, j'utilise un utilitaire nommé Corkscrew qui me permet de me connecter via un proxy HTTP à mon serveur. Dans mon exemple, le proxy écooute sur le port 3128 et nécessite une authentification, j'ai donc ajouté un fichier proxy_auth contenant les identifiants. Les variables %h et %p désignent l'hôte vers qui se connecter et son port. A noter que la plupart des serveurs proxy qu'on peut trouver sont configurés pour ne pas autoriser les ports autres que les ports HTTP, HTTPS, et éventuellement FTP. Il faudra donc peut-être changer le port d'écoute de notre testdrive, et mettre notre serveur SSH sur le port 80 ou 443. A noter que selon l'organisation qui administre le proxy, cette manière de faire peut être vue comme une violation de la charte informatique du réseau, ou de tout autre règlement intérieur. Ne l'utilisez donc que si vous y êtes autorisés !

Créer un tunnel SOCKS

DynamicForward 1080

Cette option est très pratique si vous ne voulez pas vous casser la tête à créer un tunnel VPN. Une fois cette option ajoutée à la configuration de votre hôte, et la connexion à celui-ci effective, un tunnel SOCKS écoute sur la boucle locale de votre machine, sur le port 1080. Un cas concret d'utilisation est la connexion à vos sites préférés depuis un point d'accès sans fil public, comme une gare : une fois connecté au réseau, on se connecte en SSH à son serveur, puis on modifie les paramètres de proxy de notre navigateur web pour utiliser un proxy SOCKS dont l'adresse est 127.0.0.1 et le port est 1080. Tout le trafic web du navigateur passe ainsi dans la connexion SSH. Si vous faites souvent le va-et-viens dans votre configuration de proxy, Firefox possède une extension nommée FoxyProxy qui vous facilitera l'existence !

Créer un tunnel pour rediriger du trafic

LocalForward 5901 192.168.13.38:5900

Encapsuler un trafic réseau dans SSH est quelque chose de connu, et l'exemple ci-dessus est lui aussi archi-connu : le protocole VNC transite en clair sur le réseau, l'utilisation de SSH permet de chiffrer la transmission entre notre client et notre serveur. On transfère donc le port 5900 de la machine 192.168.13.38 (qui doit être joignable depuis notre machine testdrive) vers le port 5901 local. On lance ensuite notre client VNC en direction la machine localhost sur le port 5901.

Spécifier l'algorithme de chiffrement

Ciphers aes128-cbc

De nombreux algorithmes de chiffrement sont disponibles avec OpenSSH, vous pourrez trouver la liste dans les pages de manuel. Certains processeurs (tels que l'AMD Geode LX ou le VIA C7) savent déchiffrer certains algorithmes, ce qui les rend plus rapide pour ces types d'opérations. Forcer le chiffrement en AES 128 si vous vous connectez à une machine ayant un CPU AMD Geode peut ainsi s'avérer très efficace pour limiter l'utilisation du CPU et alléger la charge.

lundi, janvier 17 2011

Vérifications de permissions - suite

Introduction : les astuces de ce billet sont extraites du document Guide to the Secure Configuration of Red Hat Enterprise Linux 5 édité par la NSA. Vous pouvez télécharger le document au format PDF dans son intégralité sur leur site. Cette introduction me permet d'être en conformité avec leur notice de Copyright.

Après les droits des répertoires et le sticky bit, amusons-nous un peu avec SUID et SGID : un fichier possédant l'attribut SUID ou SGID permet d'être lancé avec les droits de l'utilisateur ou du groupe qui a été placé, généralement root. Ainsi, le programme at, permettant de lancer une tâche à un moment donné, est accessible aux utilisateurs classiques alors que son fonctionnement nécessite des droits plus élevés. Ceci peut s'avérer risqué car si un programme SUID root possède une faille, celle-ci peut être exploitée avec les droits de root, même si l'attaquant n'a pas les droits.

Comme pour le sticky bit, commençons par vérifier notre environnement :

root@orgrimmar:~# whoami
root
root@orgrimmar:~# cat /etc/redhat-release 
CentOS release 5.5 (Final)

Recherchons maintenant tous les fichiers possédant un SUID ou un SGID :

root@orgrimmar:~# find / \( -perm -4000 -o -perm -2000 \) -type f -print
/bin/ping6
/bin/umount
/bin/ping
/bin/mount
/bin/su
/lib64/dbus-1/dbus-daemon-launch-helper
/usr/bin/wall
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/sudoedit
/usr/bin/chsh
/usr/bin/write
/usr/bin/at
/usr/bin/chage
/usr/bin/crontab
/usr/bin/ssh-agent
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/gpasswd
/usr/bin/locate
/usr/bin/screen
/usr/libexec/openssh/ssh-keysign
/usr/libexec/libvirt_proxy
/usr/libexec/utempter/utempter
/usr/kerberos/bin/ksu
/usr/sbin/userhelper
/usr/sbin/postqueue
/usr/sbin/postdrop
/usr/sbin/usernetctl
/usr/sbin/ccreds_validate
/sbin/netreport
/sbin/mount.nfs4
/sbin/umount.nfs4
/sbin/umount.nfs
/sbin/mount.nfs
/sbin/unix_chkpwd
/sbin/pam_timestamp_check
find: /proc/9859/task/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/task/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/fd/4: Aucun fichier ou répertoire de ce type
root@orgrimmar:~# 

Sur le coup, voir autant de lignes peut paraître effrayant, mais si on y regarde de plus près, on peut comprendre que 99% des fichiers indiqués aient besoin du SUID. Le seul qui m'inquiète, c'est screen. Je vais donc regarder sur une autre machine, bien différente cette fois-ci :

nils@tomb:~$ uname -sr
NetBSD 5.0.2
nils@tomb:~$ ls -hl /usr/pkg/bin/scree*
lrwxr-xr-x  1 root  wheel   12B Jul 11 11:23 /usr/pkg/bin/screen@ -> screen-4.0.3
-r-s--x--x  1 root  wheel  279K Jul 11 11:23 /usr/pkg/bin/screen-4.0.3*

On voit que screen sur ma machine NetBSD a aussi un bit SUID. C'est bon, je peux aller me coucher l'esprit tranquille :) Mais avant, revenons à notre serveur CentOS, et comme pour l'affaire du sticky bit, simulons un programme dont le SUID a été ajouté inutilement :

root@orgrimmar:~# cat > testbin
#!/bin/bash
echo -n "Je suis un programme SUID de test"
exit 0
root@orgrimmar:~# chmod -v +x testbin 
Le mode d'accès de `testbin' a été modifié à 0755 (rwxr-xr-x).
root@orgrimmar:~# ls -hl testbin 
-rwxr-xr-x 1 root root 63 déc 31 00:44 testbin*
root@orgrimmar:~# chmod -v +s testbin 
Le mode d'accès de `testbin' a été modifié à 6755 (rwsr-sr-x).
root@orgrimmar:~# ls -hl testbin 
-rwsr-sr-x 1 root root 63 déc 31 00:44 testbin*

Relançons notre recherche :

root@orgrimmar:~# find /root \( -perm -4000 -o -perm -2000 \) -type f -print
/root/testbin

Supprimons maintenant le SUID et relançons la recherche :

root@orgrimmar:~# chmod -v -s testbin 
Le mode d'accès de `testbin' a été modifié à 0755 (rwxr-xr-x).
root@orgrimmar:~# find /root \( -perm -4000 -o -perm -2000 \) -type f -print
root@orgrimmar:~# 

Et voilà, nous sommes tranquille :)

Que faire si j'ai un doute sur un programme ? Plusieurs possibilités : s'il s'agit d'un programme qui est fourni par les paquets de votre distribution, on peut toujours aller vérifier sur d'autres machines, dont l'OS ou la distribution peut différer (comme je l'ai fait avec screen); un même programme nécessitant le SUID sur 2 OS différents peut légèrement rassurer. Si le logiciel est libre (exemple : GNU screen :D), on peut aussi aller chercher dans les fichiers de création du paquet binaire, pour les RPM il suffit de chercher le SRPM du logiciel et de l'installer sur une machine de test. Ensuite, on regarde le contenu du fichier .spec qui sert à la création de ce paquet : en effet, ces fichiers contiennent la liste et les droits des fichiers et répertoires du paquet que l'on veut compiler :) Si un .spec n'indique pas que le programme est SUID, alors il est temps de s'inquiéter !

lundi, janvier 3 2011

Vérifications de permissions

Introduction : les astuces de ce billet sont extraites du document Guide to the Secure Configuration of Red Hat Enterprise Linux 5 édité par la NSA. Vous pouvez télécharger le document au format PDF dans son intégralité sur leur site. Cette introduction me permet d'être en conformité avec leur notice de Copyright.

Je vous propose de vérifier les permissions de certains de vos fichiers sur votre serveur ou poste fonctionnant sur un système Linux. Le but est de limiter les possibilités de tentatives d'intrusion en recherchant les moyens d'entrée possibles. Commençons par vérifier notre environnement :

root@orgrimmar:~# whoami
root
root@orgrimmar:~# cat /etc/redhat-release 
CentOS release 5.5 (Final)

Recherchons maintenant tous les répertoires dont les droits permettent à n'importe quel utilisateur d'écrire dedans, et dont le sticky bit n'est pas positionné :

root@orgrimmar:~# find / -type d \( -perm -0002 -a ! -perm -1000 \) -print

Si jamais votre machine possède de nombreuses partitions, et qu'elles sont du genre bien remplies, il est possible de limiter la recherche de find à une partition à la fois :

root@orgrimmar:~# find / -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:~# find /home -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:~# find /var -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print

Idéalement (et c'est le cas sur ma machine, ouf !), cette commande ne devrait occasionner aucun affichage. Maintenant, amusons-nous un peu :

root@orgrimmar:/tmp# mkdir insecure
root@orgrimmar:/tmp# chmod -v 777 insecure
Le mode d'accès de `insecure' a été modifié à 0777 (rwxrwxrwx).
root@orgrimmar:/tmp# find /tmp/ -type d \( -perm -0002 -a ! -perm -1000 \) -print
/tmp/insecure

Positionnons maintenant le sticky bit :

root@orgrimmar:/tmp# ls -hl /tmp/ | grep insecure
drwxrwxrwx 2 root root 4,0K déc 30 23:54 insecure/
root@orgrimmar:/tmp# chmod -v +t /tmp/insecure/
Le mode d'accès de `/tmp/insecure/' a été modifié à 1777 (rwxrwxrwt).
root@orgrimmar:/tmp# ls -hl /tmp/ | grep insecure
drwxrwxrwt 2 root root 4,0K déc 30 23:54 insecure/
root@orgrimmar:/tmp# find /tmp/ -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:/tmp# 

Qu'est-ce que le sticky bit ? Extrait de la page de manuel de chmod (man chmod) :

t (sticky-bit) conserver le code du programme sur le périphérique de swap après exécution. Il s’agit du comportement original, mais de nos jours il sert uniquement pour les répertoires. Il indique que seuls le propriétaire du répertoire, et le propriétaire d’un fichier qui s’y trouve ont le droit de supprimer ce fichier. C’est typiquement utilisé pour les répertoires comme /tmp ayant une autorisation d’écriture générale.

Vérifions cela :

root@orgrimmar:/tmp# cd /
root@orgrimmar:/# ls -hl | grep tmp
drwxrwxrwt   5 root root 4,0K déc 30 23:59 tmp/

Le sticky bit est positionné. Je suis rassuré. Néanmoins, il ne fait pas tout. Regardons donc quels répertoires sont accessibles à tous les utilisateurs, sans chercher à savoir si le sticky bit est positionné :

root@orgrimmar:/# find / -type d \( -perm -0002 \) -print
/var/tmp
/var/lib/xenstored
/dev/shm
/tmp
/tmp/insecure
/tmp/.ICE-unix

Cela fait déjà un peu plus de monde... pas très rassurant mais à part notre répertoire insecure, pas de quoi s'affoler : /var/tmp et /tmp sont des répertoires destinés aux fichiers temporaires des programmes en fonctionnement, /var/shm désigne la mémoire partagée et le xenstored sert au bon fonctionnement de l'hyperviseur Xen.

Pour finir, nous pouvons nettoyer notre petite expérience :

root@orgrimmar:/# rmdir -v /tmp/insecure/
rmdir: destruction du répertoire /tmp/insecure/
root@orgrimmar:/# ls -hal /tmp/ | grep secu

mardi, août 22 2006

On n'est jamais mieux servi que par soi-même

Ou quand un expert en sécurité informatique voit son site internet défacé...

Lire la suite...

samedi, janvier 14 2006

Mandriva Security Update

Mettez à jour votre distribution !

Lire la suite...

Propulsé par Dotclear