OpenBSD et la sécurité

Une seule vulnérabilité à distance dans l'installation par défaut, en 7 ans .
voilà comment vous accueille le site OpenBSD.

La politique de sécurité

Contrairement à beaucoup d'autres OS, ici, la sécurité prime les fonctionnalités. Les différentes versions des logiciels sortent toujours plus tard qu'ailleurs, les logiciels bureautiques ou utilitaires sont fort rares.Vous en connaissez beaucoup des OS qui, après une installation par défaut, ont:

des communications chiffrées (OpenSSH Client & Serveur ) immédiatement utilisables
la pile de données non-executable.(Sur les architectures qui le supporte)
la plupart des sources de Buffer Overflow détectées et corrigées par l'audit du code source.
un nombre de binaires Setuid-root «sensibles » absolument ridicule (40 sur la 3.1, 9 sur la 3.2!!)
une implémentation d'ACL (listes de contrôle d'accès) au niveau du noyau pour surveiller les binaires exécutés:systrace
une authentification forte Blowfish 448 bits et pas du vieillissant DES 56 bits.
La sécurité au niveau réseau : IPSEC ,sa conséquence la création de VPN (Réseau Privé Virtuel) (Bonne chance, quand même pour la configuration !!), et son pendant au niveau application : SSL.
une authentification réseau unique (SSO: Single Sign On): Kerberos Client & Serveur
Pas de pile IP !!! Et oui, contrairement aux autres OS, lors de l'installation, il n'y a pas de configuration réseau; et ce, jusqu'au prochain redémarrage. Ainsi, vous avez tout le temps de sécuriser la machine avant de la mettre en réseau.

Le chiffrement fort est d'ailleurs la cause du développement canadien du projet OpenBSD. Aux USA, comme dans pas mal d'autres pays, dont la France, le chiffrement fort est assimilé à une arme de guerre dont la déclaration est obligatoire (128 bits en France pour du chiffrement asymétrique) et dont l'exportation est interdite.

Enfin, il faut signaler la sécurité par défaut : Un système fraichement installé est tout à fait sécurisé, sans aucun service potentiellement dangereux en service. L'administrateur débutant peut progresser dans une relative sécurité. Un bon résumé dans la langue de Shakespeare.

Une remarque cependant : En ce qui concerne l'unique vulnérabilité de l'installation par défaut, il serait honnete de faire remarquer que personne n'utilise l'installation par défaut.... On va tous ouvrir qui un DNS, qui un relais de messagerie,, qui un serveur Web.... et on sort par là de l'installation par défaut. C'est aussi honnète que la certification C2 de windows NT à l'époque qui n'était valide que.... sans cable réseau...

l'audit

Depuis 1996, l'équipe OpenBSD analyse TOUTES les sources du noyau et des autres logiciels (MAIS pas des PORTS, attention!) à la recherche de trous découverts pour des techniques déja utilisées (débordement de tampons,..) ou à venir , en épurant le code des choses inutilisées ou mal construites. Ces vérifications ont lieu plusieurs fois par des personnes différentes aux connaissances variées.

Cet audit fait régulièrement ses preuves; Quasiment à chaque fois qu'une vulnérabilité est découverte dans un Unix libre (ou non), elle a déja été comblée dans OpenBSD depuis longtemps.

Attention, une version de l'OS n'est maintenue (Publication de patches et veille sécuritaire) que sur deux versions, approximativement : La 3.4 venant de sortir, la 3.2 n'est plus maintenue à compter du 1er Novembre 2003.

Niveau du kernel

Le noyau OpenBSD peut tourner sous différents niveaux numérotés de -1 à 2. tout processus root peut augmenter ce niveau, mais seul init peut le diminuer, et ceci, seulement au redémarrage en mode single user; c'est une excellente protection! Attention, vous pourriez passer outre ces restrictions si vous ne désactiviez pas les fonctions de débugging du noyau.(sysctl ddb.panic = 0,sysctl ddb.console = 0 )

Niveau	Mode	Caractéristiques
-1	Non-sécurisé permanent	- Init ne va pas augmenter ce niveau - Ne peut être généré que par sysctl depuis le mode non-sécurisé - Identique au mode non-sécurisé
0	Non-sécurisé	- Utilisé durant la phase de boot, pendant que le système est en mode single-user. - Tous les périphériques peuvent subir des opérations de lecture/écriture (selon leurs droits !) - Les attributs peuvent être désactivés.
1	Sécurisé	- Mode par défaut en système multi-user. - Le niveau ne peut plus être diminué que par init. - Les périphériques en mode raw (écriture directe) montés sont en mode read-only. - Les attributs immuable ou append-only ne peuvent plus être désactivés. - Les modules du noyau ne peuvent plus être chargés, ni déchargés.
2	Hautement-sécurisé	- Les effets du mode sécurisé plus : - Les périphériques en mode raw (écriture directe) sont en mode read-only, qu'ils soient montés ou non. - On ne peut pas faire reculer l'heure système. - pfctl ne peut modifier aucune règle de filtrage, ni de translation. - Les variables ddb.panic et ddb.console de la commande sysctl ne peuvent pas être modifiées.

Quelques applications :

- Vous mettez vos fichiers de logs en mode append-only (Ajout uniquement). Votre pirate ne pourra pas effacer ses traces, les fichiers de logs ne pouvant pas être modifiés. En effet, il faudrait que votre pirate soit devant la console au redémarrage (mode 0)

- Les répertoires et les fichiers sensibles (tous ceux des répertoires précédents, ainsi que certains autres), qui n'ont pas de raison d'être modifiés doivent être marqués immuables.

En vrac : /bin , /sbin , /usr/sbin , /usr/bin , /usr/libexec et leurs fichiers. Certains fichiers ont cet attribut dès l'origine (makekey, pour chiffrer les mots de passe, par exemple)

Dans /etc : pf.conf ( indispensables ), d'autres fichiers de config de /etc
Remarque :
L'usage des fichiers append-only et immutable est assez pénible. Si vous voulez les modifier, faire tourner, archiver ou quoi que ce soit d'autre, vous devez redémarrer la machine. Pas terrible pour une machine en production.

Syntaxe :

sysctl kern.securelevel = Niveau_souhaité

chflags -R schg /rep Positionne l'attribut immuable-système au répertoire et à tous ses sous-répertoires.Dans certains cas obscurs, le système vous affichera un message de refus 'Operation not permitted' sur certains fichiers qui récupéreront l'attribut quand même.

chflags sappnd ./fic Positionne l'attribut append-only-système au fichier.

Ajouter no en préfixe de l'attribut le désactive :

chflags noschg ./fic Désactive l'attribut immuable-système au fichier.(Vous êtes superuser, et en mode single-user)

Deux scripts pour verrouiller ou déverrouiller les fichiers sensibles.

Un serveur https en 3 lignes et 10 minutes !

Comment sécuriser encore plus l'installation par défaut ?

sshd

inetd

Le Super-serveur Internet est chargé au démarrage avec quelques bricoles à l'écoute. Si rien ne cela vous sert, désactivez le tout dans /etc/rc.conf

et bien sûr : le firewall

Sudo
    Par défaut sudo est installé sur OpenBSD. Par contre il vous fait le paramétrer. Je vous en conseille vivement l'utilisation cela vous évitera bien des problèmes. Pour le mettre en oeuvre aller dans /etc/sudoers. Vous trouverez une documentation plus complète ici.

mtree
   mtree est un équivalent du très connu tripwire. Pour des questions de licence, tripwire n'existe pas dans les ports d'OpnBSD. Toutefois si vous êtes habitué à lui, vous pouvez toujours l'utiliser.
Vous disposez de "Aide" un équivalent qui se trouve dans les ports dans security.
Toutefois, mtree est un bon outil, que je conseille d'utiliser pour surveiller l'intégrité de vos fichiers.
Si vous ne connaissez pas tripwire, ce type de produit permet de prendre une empreinte des fichiers que vous voulez, avec les règles que vous souhaitez contrôler, à savoir par exemple : le propriétaire, le groupe, les droits, md5, la taille, la date....etc. Vous placez cela dans un fichier, puis à intervalle régulier ou éventuellement si vous pensez que cela est nécessaire, vous refaites un contrôle. mtree indique alors les différences. Il faut bien sur tenir compte du type de fichier lorsque l'on met cela en oeuvre. On ne traite pas de la même façon un fichier de log et un binaire.
Une fois l'empreinte prise, que je vous conseille de prendre avant de mettre votre machine en ligne, il faut penser à crypter le fichier obtenu ou le placer sur une autre machine.
Enfin il faut penser à refaire cela à chaque modification de votre machine (nouvelle installation d'un applicatif, patch, mise à jour...)

La syntaxe est assez simple, pour créer la première empreinte de vos fichiers sur la machine, vous pouvez passer la commande suivante :
mtree -c -Ksha1digest -p / > base-mtree             On garde une empreinte à partir de la racine et on place le résultat dans le fichier base-mtree.

Puis pour faire le contrôle
mtree -f base-mtree -p /

systrace

Les différents mécanismes de protection de la mémoire

    Différents mécanismes ont été introduits avec la 3.3; tous ne s'appliquent pas à toutes les architectures.
1. ProPolice
    C'est l'équivalent sous OpenBSD de Stackguard sous Linux. Intégrée au système, au compilateur gcc et activée par défaut, cette technique est une protection de la pile de données. En gros, lors d'un appel de fonction, l'adresse de retour est vérifiée avant et après; en cas de différence, le processus est terminé avec envoi dans syslog. Ceci devrait rendre plus difficile la modification des adresses de retour, et par là meme, l'exploit des attaques par débordement de tampon. Notez que l'intégration à gcc permet d'étendre ProPolice à tout ce qui est compilé par vos soins (ports, donc packages) et les sources classiques. C'est la seule protection actuellement disponible sur architecture Intel 32 bits !
Un autre intéret est le débuggage. un soft buggé sera intercepté et l'info remontée dans syslog. Ceci devrait permettre d'épurer encore le code source des petits bugs rémanents.

2. W^X (Write XOR eXecution)
    Ne fonctionne, pour l'instant, que sur sparc, sparc64,hppa et alpha. A partir de la 3.3-current et dès la 3.4, ceci devrait fonctionner aussi sur i386 et PowerPC. Le principe est le suivant :Un segment de mémoire doit etre soit réinscriptible(W), soit executable(X), mais certainement pas les deux simultanément (XOR). Le but est de limiter l'utilité des attaques par débordement de tampons (buffer overflow). L'attaque consistant à injecter du code (W) puis à l'executer (X), ce qui est devenu impossible (Xor = l'un ou l'autre, amis pas les deux.).
PB : Afin de rendre cette technique utilisable sur architecture Intel 32, le format des binaires openBSD a changé du format a.out au format ELF. La compatibilité avec les binaires compilés en statique est assurée, pas celle des binaires compilés en dynamique....

Openbsd-maj:
    L'upgrade des sources de a.out en ELF ne sera pas supporté.
Par conséquent, il est fortement conseillé d'installer un snapshot puis de recompiler à partir des sources.
Et encore, tout cela doit se faire dans un ordre précis.
Le passage de 3.2 en 3.3 semble donc, assez délicat en lui-meme; A cela s'ajoute la compatibilté???maj???? des binaires
ce pb ne se pose que sur i386.
www.openbsd.org/faq/upgrade-minifaq.html#3.3.2

3. .rodata
    Le format ELF des binaires permet de définir deux types de segment de code, le code réel et le code ro (read-only). Toutes les portions de code ro ne seront pas executables. Ca reste dans la ligne du principe de moindre privilège; pourquoi tout devrait etre executable si, seulement un petit bout en a besoin ?

4. Prot_Purity.
    Encore une fois, il s'agit de définir précisement ce qui, en mémoire, est inscriptible, lisible ou executable, et de séparer autant que faire se peut, le tout. Encore une fois, ceci n'est supporté que sur sparc, sparc64, alpha, hppa, pas sur i386, ni PowerPC. Ces deux dernières architectures permettent une granularité de la protection beaucoup moins fine; Là où les premières architectures descendent à la page mémoire, les secondes ne peuvent que définir les protections sur deux parties, au maximum.

Notons que ces quelques techniques durcissent encore OpenBSD, mais qu'apparemment, des techniques similaires dans d'autres OS (PaX,LIDS,Stackguard, sous Linux) ont été défaites d'une façon ou d'une autre par le passé.

    En conclusion, et pour finir, je me contente de citer Théo de Raadt :
"We feel that these 4 technologies together will be a a royal pain in the ass for the typical buffer overflow attacker."

Je ne suis pas développeur, et encore moins un expert en architecture de la mémoire, aussi je prierais toute personne assez compétente dans
ce domaine de me signaler les éventuelles énormités écrites plus haut.