8. Analyse de vulnérabilité

J'essaie de couvrir ici les trous de sécurité naissant de cette mise en oeuvre en particulier, et des VPNs en général. Tous les commentaires seront vivement appreciés.

• sudo : en fait, j'utilise sudo de manière excessive. Je crois que c'est toujours plus sûr que d'utiliser les bits setuid. C'est encore un inconvénient de Linux de n'avoir pas un contrôle d'accès plus rigoureux. On attend la compatibilité avec POSIX.6 <http://www.xarius.demon.co.uk/software/posix6/>. Ce qui est pire, c'est qu'il y a des scripts shell qui vont être lancés avec sudo. Plutôt mauvais. Quelqu'un a une idee ?
• pppd : lui aussi lance suid root. Il peut être configuré par le .ppprc de l'utilisateur. Il se pourrait qu'il y ait de beaux dépassements de la mémoire tampon. Ligne de défense : sécurisez votre compte esclave autant que possible.
• ssh : faites attention au fait que les versions de ssh antérieures à la 1.2.20 contiennent des trous de sécurité. Pire, nous avons établi une configuration telle que lorsque le compte maître a été compromis, le compte esclave l'est lui aussi, et est grand ouvert aux attaques utilisant des programmes lancés avec sudo. C'est parce que j'ai choisi de ne pas avoir de mot de passe sur la clé secrète du maître pour permettre la configuration automatique du VPN.
• firewall : avec des règles de firewall incorrectes sur un des bastions, vous ouvrez les deux intranets. Je recommande d'utiliser le camouflage d'adresse IP (car l'installation de routes incorrectes est un peu moins évidente), et faire des contrôles très sérieux sur les interfaces VPN.