Linux Attitude

Niveau :
Résumé :

Maintenant que nous connaissons le processus de boot, si on examinait ce processus d'un point de vue de la sécurité !

Lorsqu'on parle de sécurité, il faut d'abord savoir dans quel cas on se positionne et de quoi on cherche à se prémunir. Ici, je considère que le système lui-même est sécurisé. Je suppose que l'attaquant est devant la machine et cherche un accès root.

On considère que chaque élément est sécurisé pour ce qui est de ses propres fonctionnalités, ce qui veut dire que si le bootloader est protégé par mot de passe, il n'y a pas de faille dans le bootloader lui-même permettant d'outrepasser ce mot de passe. Nous nous attacherons donc à chercher ce qui peut être détourné dans le flux d'exécution en entrée et en sortie de chaque élément.

Je vais commencer par la fin, du plus facile au plus difficile.

rc

Rc est lancé par init et ne prend ses paramètres que de init. Ceux-ci sont fixés en dur dans /etc/inittab. Son démarrage ne peut donc être détourné que d'une façon : par modification du contenu du disque. GoTo partition /

Parmi ces paramètres il y a le paramètre 1 qui lance rc dans le runlevel 1, ce qui dans la plupart des cas se termine par un sulogin. Ouf on est protégé par le mot de passe root.

Mais vérifiez bien, dans certains cas il se termine par un simple shell et donc réussir à passer un tel paramètre permettrait à l'attaquant un accès root à votre machine.

Pour passer 1 en paramètre GoTo init

Bookmarks:

Niveau :
Résumé : pam_unix sha512

Il y a quelques années, le format de stockage des mots de passe unix a changé, permettant de passer du trop simple DES à un algorithme de votre choix. Au passage le stockage s'est fait dans /etc/shadow pour limiter encore plus l'accès à la version chiffrée de ces mots de passe.

Traditionnellement on utilise un hashage MD5 des mots de passe, ce qui se reconnaît par un $1$ au début des mots de passe dans le fichier shadow.

Mais il se peut que vous n'ayez plus confiance en MD5, dans ce cas, rien ne vous empêche d'utiliser un autre algorithme. C'est très simple; il suffit de modifier /etc/pam.d/common-password ou l'équivalent de votre distribution avec la ligne suivante :

password   sufficient  pam_unix.so min=4 sha256

Et changez votre mot de passe, vous verrez alors le préfixe devenir $5$ dans le fichier shadow. Les valeurs possibles sont les suivantes :

• md5 : $1$
• sha265 : $5$
• sha512 : $6$
• blowfish : $2a$ (déclaré comme fonctionnel seulement sur certaines distributions)

Si la valeur n'est pas comprise par pam_unix c'est la valeur par défaut (MD5) qui sera utilisée.

Sinon tant que vous êtes là à regarder bêtement votre configuration pam, profitez-en pour mettre en place pam_cracklib.

Bookmarks:

Niveau :
Résumé :

Suite de la formidable série :

Et après les comptes ?

Il est aussi possible d'utiliser libnss-ldap pour autre chose que pour les comptes utilisateurs. La bibliothèque NSS étant une bibliothèque générique de résolution de nom, il est possible d'utiliser le ldap pour :

• les groupes (attention pas de login pour newrp à travers pam de prévu)
• les noms de machine
• et d'autres qui ne pas très intéressants pour l'instant ...

Pour cela, rien de plus facile, tout est déjà fait, il suffit de modifier la ligne correspondante dans /etc/nsswitch.conf et de commencer à peupler le LDAP.

Un groupe est définit comme suit :

objectClass: posixGroup
cn: mongroupe
description: goupe a moi
gidNumber: 1000
memberUid: peck
memberUid: amiami

Notez que la description est optionnelle et que les membres sont décrits par uid. Le userPassword est aussi disponible mais n'est pas utilisable actuellement pour les groupes du système.

Exemple de machine (plus besoin de DNS local ;-) :

objectClass: ipHost
cn: mamachine
ipNetworkNumber: 1.2.3.4

Bookmarks:

Niveau :
Résumé : libmap-ldap ; passwd ; chsh ; chfn ; adduser

Désolé, j'ai oublié la suite de la série LDAP. On peut faire un peu mieux que la dernière fois.

Changer son mot de passe

Nous n'avons pas activé le changement de mot de passe. Pour cela, c'est assez simple, il suffit de modifier common-password (cela peut être ailleurs pour certaines distributions ...) :

password   sufficient   pam_unix.so nullok obscure min=4 max=8 md5
password   sufficient   pam_ldap.so

Il faut aussi modifier /etc/pam_ldap.conf pour que pam ne modifie pas directement le mot de passe, mais utilise les fonctions de ldap prévues à cet effet. Cela permet qu'il ne soit pas stocké en clair, mais avec la méthode définie dans la configuration de ldap ({SSHA} par défaut).

# A ajouter dans /etc/pam_ldap.conf
pam_password exop

Et voilà vous pouvez tester la commande passwd. Mais vous constaterez qu'il y a quelque chose qui cloche. Si vous lancez la commande en root, l'ancien mot de passe vous est quand même demandé. C'est parce que vous n'avez pas les droits d'administrateur sur le ldap.

Pour remédier à cela, il vous faut un compte ldap qui a le droit de modifier le champ password des autres utilisateurs, par exemple l'administrateur ldap. Puis renseignez ce compte dans pam_ldap.conf :

# /etc/pam_ldap.conf
# Il faudra stocker le mot de passe correspondant en clair dans /etc/pam_ldap.secret
# Ce fichier doit appartenir à root et être en mode 600
rootbinddn cn=admin,dc=linux-attitude,dc=fr

Ça y est vous êtes prêts.

Bookmarks:

Niveau :
Résumé : libpam-ldap

Hier nous avons créé un compte sur le ldap. Bien, mais on ne pouvait pas en faire grand chose. Il faut maintenant pouvoir se connecter. Il est théoriquement possible de tout faire avec libnss mais c'est à la fois plus difficile et moins fonctionnel qu'avec pam.

Comme vous le savez l'authentification sous linux se fait avec PAM. Nous allons donc utiliser un module dédié : libpam-ldap (cool le paquet porte le même nom).

LDAP

Cette fois ne nous force à utiliser aucun objectClass, mais comme il sait utiliser les attributs de la classe shadowAccount, on peut utiliser celle-ci pour se simplifier la vie.

Ajoutons le mot de passe à notre utilisateur. On crée le mot de passe LDAP à la main, mais par la suite vous verrez que ce n'est pas indispensable.

$ slappasswd -s test
{SSHA}l5X6sBFomfk3tk02HEMWK4YLep7pqZDk

On ajoute ce mot de passe à l'utilisateur déjà créé :

$ ldapmodify -x -D "cn=admin,dc=linux-attitude,dc=fr" -W
dn: uid=peck,ou=people,dc=linux-attitude,dc=fr
changetype: modify
add: userPassword
userPassword: {SSHA}l5X6sBFomfk3tk02HEMWK4YLep7pqZDk

Un test de connexion avec ldapsearch vous montrera que le mot de passe est bien pris en compte :

$ ldapsearch -x -D "uid=peck,ou=people,dc=linux-attitude,dc=fr" -w test "uid=peck"

Bookmarks:

Niveau :
Résumé : openssl

Vérification

Maintenant que nous avons des certificats propres et bien signés il va falloir les vérifier. Mais il ne s'agit pas simplement de vérifier que le certificat est valide et signé par une autorité de confiance. Tout d'abord, il fautde vérifier toute sa chaine de confiance. Ensuite il faut vérifier ses extensions, par exemple s'il va être utilisé pour les usages auxquels on l'a prévu.

Openssl permet de faire la vérification de la chaine de certification ainsi que la vérification de l'usage. Pour cela il faut installer l'autorité de confiance :

# On trouve le hash du certificat de l'AC
$ hash=$(openssl x509 -hash -noout -in cacert.pem)
# On installe l'AC en utilisant ce hash (il faut être root ici)
$ cp cacert.pem /etc/ssl/certs/$hash.0

Du coup la vérification d'un certificat se fait simplement :

$ openssl verify -purpose sslclient certificat.crt

Pour la vérification des extensions, il faut voir au cas par cas.

Mais contrairement à ce qu'on pense souvent, ce n'est pas tout. Il faut aussi vérifier que le certificat n'est pas révoqué, c'est-à-dire invalidé avant la date limite.

Révocation

La révocation d'un certificat se fait dans plusieurs cas :

• perte de la clé
• départ du propriétaire de la clé
• renouvellement de la clé
• ...

En gros à chaque fois qu'on veut garantir que la clé ne sera plus utilisée.

Pour révoquer un certificat alors qu'on a installé une AC openssl comme dans l'article précédent :

# On en profite pour indiquer pourquoi on le révoque
# les raisons possibles sont : unspecified, keyCompromise, CACompromise,
#   affiliationChanged, superseded, cessationOfOperation, certificateHold or removeFromCRL
$ openssl ca -config openssl.cnf -revoke client.cert -crl_reason keyCompromise

Il existe 2 mécanismes pour faire savoir au monde qu'on a révoqué un certificat : les CRL et le protocole OCSP.

Bookmarks:

Niveau :
Résumé :

Après avoir vu il y a longtemps comment créer le certificat d'une autorité de certification personnelle et comment l'installer là où c'est nécessaire, nous allons voir les méthodes pour gérer une autorité de certification.

Une fois l'autorité créée, l'activité principale d'une autorité est de signer des certificats. Et plutôt que de taper tous les paramètres à la main, il est plus simple de disposer d'une configuration, ce qu'openssl nous propose. De plus, openssl dispose d'une commande permettant une gestion simplifiée d'une autorité.

Passons en revue la configuration (reprise du fichier par défaut /etc/ssl/openssl.cnf). Parlons directement de la section gérant l'autorité elle-même :

# Section pour la commande ca
[ ca ]
# Autorité par défaut (pour en gérer plusieurs)
default_ca      = Peck_authority 

# Section spécifique à mon autorité
[ Peck_authority ]

# Tous les répertoires de base
dir             = /srv/Authority        # Where everything is kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/index.txt        # database index file.
new_certs_dir   = $dir/newcerts         # default place for new certs.

certificate     = $dir/cacert.pem       # The CA certificate
serial          = $dir/serial           # The current serial number
crlnumber       = $dir/crlnumber        # the current crl number
                                        # must be commented out to leave a V1 CRL
private_key     = $dir/private/cakey.pem# The private key
RANDFILE        = $dir/private/.rand    # private random number file

Ensuite les options spécifiques :

# Mettre à no pour permettre à une entité de disposer de plusieurs certificats
#unique_subject = no

# Section contenant les extensions à utiliser
x509_extensions = usr_cert              # The extentions to add to the cert

# Format d'affichage des données en ligne de commande
name_opt        = ca_default            # Subject Name options
cert_opt        = ca_default            # Certificate field options

# Ne pas utiliser sauf à faire infiniment confiance aux demandeurs (ou tout vérifier à la main)
# copy_extensions = copy

# Durée de validité des certificats émis
default_days    = 365
# Fonction de hashage à utiliser (ne pas utiliser md5 :-)
default_md      = sha1
# Réécrire le DN passé par le demandeur
preserve        = no

# Politique à utiliser pour la vérification de la demande
policy          = policy_match

Et maintenant les sous-sections.

Bookmarks: