Découverte OpenBSD


Contrairement à une idée répandue, OpenBSD n’est pas un OS difficile, je dirais même qu ‘au contraire elle est très facile à installer.

Il suffit de suivre petit memo qu ‘on trouve dans la jaquette des CD ( ou sur le site ) et son installation est très rapide : guère plus de vingt minutes.

La seule chose à préparer avant est le partitionnement ( interne à OpenBSD ), car l’exemple donné est pour une toute petite partition.

Des justifications de ce partitionnement multiple et du partitionnement spécifique des BSD sont données plus loin.

Et on a un OpenBSD complet, avec le serveur X, un serveur http ( celui d’ OpenBSD , pas Apache ) installé dans les règles de l’art, et le système de bureau fwm, qu ‘on peut lancer avec startx, mais qui n’est pas très utilisable pour un desktop, quand on est habitué à Gnome ou KDE.

En moins d’ une heure on a un OpenBSD avec KDE pour découvrir cet OS .

Ce qui lui donne cette réputation est que son domaine de prédilection c’est les serveurs et les réseaux où effectivement ça peut devnir compliqué..

Deux autres préjugés sont faux : une distribution austère, je reconnais qu’ Open BSD ne fait rien coté look de leur OS, ce n’est pas vraiment leur préoccupation, mais la conf du bureau ça se passe dans KDE.

Les développeurs OpenBSD sont très nomades, ils organisent des réunions , et donc utilisent des portables, aussi OpenBSD supporte pas mal de portables, le wifi. Un portable n’est pas vraiment fait pour être un serveur.

Beaucoup de gens équipés de protables souhaitent pouvoir crypter leurs données professionnelles, pour se prémunir du vol de données stratégiques et confidentielles. Sous OpenBSD existe une solution complète de cryptage, prête à l’emploi. On voit trop de solutions incomplètes dans les divers tutos et donc pas très sûres.

Et c’est une distro en ligne de commande, comme elle est destinée aux serveurs, qui ne sont pas équipés de système graphique, oui. mais il y a de bonnes docs, de bons mans et ksh c’est pas mal : il affiche souvent des options avant qu ‘on réponde.

Si dans Linux on arrète pas de ferrailler dans le système, une fois OpenBSD installé, si on aime aller bricoler dans le système on est un peu frustré. On s’ennuye avec OpenBSD. Ca marche comme l’horlogerie suisse.

Mais on peut se concenter sur ses applis web, sur ses développements persos, et on n’ira pas mettre le souq dans le système…

C’est vrai , ce n’est pas une distro pour gamers, mais si vous voulez un Desktop classique, fiable , avec à coté un serveur HTTP et un serveur FTP, parfaitement sécurisés, c’est la distro idéale.

Surtout si vous voulez ouvrir votre serveur sur Internet.

Sur une distro Linux conventionnelle, il n’est pas toujours possible d’installer Apache dans les règles de l’art. Si vous voulez avoir une idée de la difficulté à sécuriser Linux, je vous invite à lire cette documentation d’une de mes distros préférées : Gentoo hardened.

La configuration des modules de sécurité est du niveau expert, et si on fait une erreur , le remède risque d’être pire que le mal.

Comme me le disait un gentoiste : ne pas le faire sur un site gouvernemental serait une faute professionnelle, mais pour un site perso, c’est beaucoup trop de travail vu l’enjeu des données..

Mais aujourd’hui le piratage a changé de forme, il utilise des PC persos pour s’anonymiser et des serveurs mal protégés pour infecter les visiteurs.

Il suffit de laisser tourner Apache avec sa page d’acceuil “It Works”avec un sniffer penfdant quelques semaines et d’analyser les logs. Il y a des bots qui balayent le net en permanence. D’autre part les outils comme les scans de vulnérabilités destinés à vérifier la sécurité d’un serveur et d’un site web sont disponibles sur internet, et les pirates ne se privent pas de les utiliser, pour détecter des serveurs vulnérables..

Enfin Linux vit sur le fait qu ‘il n’est pas concerné par la majorité des virus en .exe , destinés à Windows. Mais aujourd’hui, il y a les rootkits de plus en plus invisibles. Aucun OS n’est à l’abri.

Il existe un bouquin : Comment écrire un rootkit pour BSD, pour faire comprendre les techniques, et mieux se protéger..

M**** les BSD aussi ? Eh oui. D’ailleurs Free BSD que j’avais essayé avant, était équipé d’un chasseur de rootkit.

Il m’a surtout servi en prenant au hazard le nom d’un rootkit de trouver avec Google un supermarché du rootkit et autres outils decracks de captchas et autres.. Site turc quia du déménager..Mais c’est bien une réalité.

Les pirates ont analysé ces outils de détection et ont appris à les éviter.

Puis c’est une statégie de défense à la windows : on court derrière les éditeurs de virus..

Et voilà qu ‘on découvre Stuxnet qui a infecté le SCADA de Siemens, et on découvre des sytèmes infectés depuis plus d’un an.

il serait tant de changer de stratégie :

Puisqu ‘on ne sait pas les détecter, il faut les empécher de s’installer ou de s’executer.

Autrement dit : revenir aux fondamentaux de la sécurité d’un OS.

Les BSD ont créé une couche de sécurité complémentaire, dont on parle peu, et pourtant c’est vraiment le plus des BSD, mais je n’ai aucun doute qu ‘elle est utilisée dans les environnements professionnels…

Le principe est beaucoup plus simple que ce qui est fait dans les Linux hardened.

Plus simple parce qu’ intégré dès le départ.

Une chose déroute les nouveaux venus aux BSD : le partitionnement, différent de celui de Linux et windows avec la table de partitions MSDOS sur disque.. une invention de Microsoft qui a subi plusieurs évolutions.

Les BSD dérivés d’Unix, connaissaient les partitions bien avant MSDOS et le PC.

Contrairement à MSDOS où la table des partitions se trouve sur le premier secteur du disque , et dont le but est de découper le disque en morceaux, pour pouvoir installer plusieurs sytèmes, dans un système Unix le partitionnement est inscrit dans la partition Unix.

Linux, utilise la table des partitions MSDOS pour le découpage interne de son système.

Unix s’installe dans une partition MSDOS et son découpage interne en partition est en début de sa partition.

Si vous avez installé plusieurs Linux sur un disque avec un partitionnement multiple à part la swap qui peut être commune , il faut faire attention , et il est recommandé d’utiliser les labels pour ne pas se mélanger les pinceaux…

Unix au départ est concu pour s’installer sur un disque entier, non partionné ( c’est arrivé plus tard avec le PC et sa table de partiitons MSDOS )

Pourquoi des partitions ?

Pour séparer systéme, applications et données, non pas à cause des pirates, mais pour éviter qu ‘une appli boguée aille écraser le sytème, ou d’autres données.

Généralement les disques étaient composés d’un plateau inamovible, sur lequel on met le système avec quelques applis communes, et d’une cartouche amovible qui contient un deuxième plateau, avec des données et des applis particulières..

Une fois le système installé sur le “plateau fixe” il n’ y a pas de raison de le modifier.

Aussi le système est monté en lecture seule, idem pour les applis communes. Autrement dit / la / et la /usr.

Ce système a un inconvénient , rien n’empeche de modifier les options de montage.

Aussi les disques étaient équipés en plus d’une clé, qui verrouillait l’écriture sur le plateau fixe.

Le système de protection supplémentaire des BSD est inspiré de cette clé. mais il ne s’adresse pas au hard, il opère sur le sytème de fichiers: les répertoires et fichiers..

Il faut revenir aux partitions :

Un Linux grand piblic est découpé en trois partitions :

– la / avec les système, les applications avec /usr, la /tmp et la /var

– la swap

– la /home pour les donnes personnelles.

On ne peut pas monter la partition unique / en lecture seule, puisqu ‘elle contient des répertoires de données où nos devons pouvoir écrire.

Ainsi n’importe quelle appli ayant les droits root, peut aller écraser ou modifier le système ou y placer un rootkit…

Aussi OpenBSD propose d’emblée un découpage en partiitons comme ceci :

– la /

– la swap

– la /usr

– la /var

– la /tmp

– la /home

les partitions sont nommées a b c d e f g

Une est particulière la c : c’est le conteneur, autrement dit la partiion OpenBSD, en entier et elle n’est pas montable.

C’est le partitionnement minimal sécurisé. ( c’est la me chose pour Linux )

Autre avantage du partitionnement : c’est une protection contre la corruption de la partition.

Une partition est corrompue lorsqu ‘elle est pleine, et le système plante.

Il ya deux partitions qui risque de déborder : la /tmp et la /var ( avec les fichiers de logs dans /var/log si on fait fonctionner des applis en mode debug )

Mais c’est surtout la /tmp.

Dans le cas où elle est pleine, corrompue, il suffit de la reformater et le système redémarre.

Avec quoi la reformater si le système a planté..?

En redémarrant en mode minimal : juste avec la / qui contient les binaires dont l’outil de formatage. Les autres partitions ne sont pas montées, mais ce n’est pas nécessaire pour formater une partition.

Dans un système Linux grand public où tout se trouve dans la /, si on l’a remplie avec les fichiers temporaires , on ne pourra jamais la monter en / seule., et jamais relancer le système minimal. On a droit à réinstaller.

Idem sur une coupure de courant.

Si on a monté les partition sytème et appli en lecture seule, elle ne seront jamais affectées par une coupure de courant.

Reste les partitions de données, mais on est censés faire des sauvegardes, et donc en cas de corruption on peut les formater et restaurer les données.

Ce n’est pas terminé avec les options :

– readonly : lecture seule. On ne peut pas le faire à l’install, sion on ne pourrait pas configurer dans /etc ( qu ‘on ne peut pas sortir de la / on en a besoin pour le démarrage en mode minimal..)

On devra donc le faire lorsque tout est configuré.

– noexec : pas d’éxécution. Dans ce répertoire on peut attraper sans le savoir, n’importe quel fichier pourri, éxécutable.

Mais aussi dans la /home lors des téléchargements. Bien sur si c’est un .exe, les plau répandus on ne craint rien, mais c’est aussi possible pour Linux et BSD.

En montant la partition /tmp et /home et /var qui sont censées ne contenir que des fichiers de données, avec noexec on se protège des fichiers exécutables pourris.

Bien sur on ne peut pas la mettre sur la / et sur la /usr, puisqu’on doit pouvoir éxécuter les binaires de /bin et /sbin , et les applis de /usr. mais on a mis l’option readonly.

readonly empèchera l’installation d’un rootkit

noexec empêchera son exécution.

Mais ce système de base, nécessaire, est loin d’etre parfait, d’où les protection complémentaires d’ OpenBSD et des BSD en général.

J’entend beaucoup de linuxiens novices claironner ” avec Linux on ne craint rien” , alors que leur système n’est pas mieux monté qu ‘un windows, avec une seule partition pour système, applis, tmp et et var, pertition où on peut tout faire : écrire, exécuter des binaires, des scripts.

Une autre option :

– nodev : destinée à empecher l’installation d’un faux periph.

ca concerne directement les rootkits. Chaque fois qu ‘on raccorde un periph il est rangé dans un répertoire /dev , mais ce n’est pas obligatoire., pourtant ça va charger en mémoire le driver du periph. C’est une des techniques pour insérer à la place d’un driver un rootkit ( voire un rootkit driver et on ne verra rien ).

L’option nodev empêchera que le système de gestion des drivers aille chercher un faux periph dans la /home ou la /tmp.

– nodump : cette option est destinée en empêcher le dump de la mémoire ( il y a plusieurs techniques ) un des objectifs est de récupérer les clés de cryptage qui sont en mémoire.. Vous laissez votre portable cinq minutes , seul en marche , si vos hotes sont bien équipés et veulent pirater vos données cryptées, c’est fait !

C’est parce qu ‘on utilisera plus tard après l’install des options de montage différentes qu’OpenBSD et FreeBSD proposent ce partionnement multiple;

Et il est simple à faire, puisqu ‘il est interne à la partition BSD, pas de risque d’aller mettre le souq dans la table de partions MSDOS du disque.
pas de notion de primaire, étendue logique et de limitation à qutre primaires.

Seule contrainte : la partition BSD doit être une primire.

La limite du nombre de partions dans BSD est de 16, ce qui est suffisant.
si on veut amélioer on peut créer une /var/log et une /var/tmp.

Mais aussi une /usr/local.

– les applis de base sont montées dans /usr on pourra la verrouiller assez vite avec un montage readonly.

– les appllis supplémentaires sont dans /usr/local

idem pour la configuration : il y a une conf de base à ne pas toucher et on ajoute ses confs dans un local. si on fait une toile, il suffit d’effacer ce local pour revenir à la conf de base, sécurisée.

Démarrage OpenBSD :

Là aussi on revient aux fodamentaux :

Un système Unix multiutilisateur installé sur un gros ordi de l’époque, auquel les utilisateurs se connectent avec un terminal, avec sortie sur papier.. On avait plusieurs terminaux.

Ces terminaux exsitent encore ils sont au nombre de huit et accessibles avec les touches CRTRL ALT F1 à CTRL ALT F8

Les utilisateurs sont invités à se connecter LOGIN avec leur nom d’utilisateur et leur mdp.

l’interface graphique le serveur X et le windows manager sont au dessus du système.

On le lance avec startx ( vachement compliqué ).

Avec Open BSD on a fwm ( un véritable répulsif 🙂 ) )

Lorsqu ‘on a installé KDE, on le lance non pas avec start X, mais avec startkde ( toujours très compliqué )

mais on ne peut lancer qu ‘un seul interface graphique;

Cependant les autres terminaux restent disponibles pour travailler en console.

Lorsqu ‘on arrète avec le bouton STOP de KDE, on arrète que l’interface graphique et sur ce terminal on revient en console avec login.

OpenBSD étant conçu pour les serveurs est censé ne pas être mis à l’arret par un utilisateur.

Il faut se connecter en root et taper HALT.

Il est même équipé d’un chien de garde, pour des services qui exigent une grande dsiponibilité ( exemple un serveur de mail ) si jamais ça bourre, le chien de garde va fonctionner , mais il faut avoir une carte mère équipée pour, le système va redémarrer et repartir clean pour continuer son service, sans attendre l’intervention d’un opérateur..

Les terminaux étant concus pour le papier dont on peut remonter les pages, sur écran ce n’est pas très pratique pour remonter. et il y a trop longtemps que je n’utilise pas un éditeur conçu pour le papier.

C’est la même chose sous Linux .

Aussi je préfère utiliser le petit éditeur nano, beaucoup plus convivial, qui permet de faire défiler les lignes d’un fichier sur l’écran.

Si le résultat d’une commande fait 1000 ligne son ne voit pas le début . il suffit de rediriger la sortie avec > monfichier.txt et de le relire avec nano.

il m’arrive d’utiliser plusieurs terminaux, pour garder des infos à portée de la main en changeant de terminal. un terminal pour lire les man des commandes.

il y a certainement d’autres techniques, pour travailler en console lorsqu ‘on a pas une console graphique du bureau mais celle là me va bien.

Configuration de xorg pour sa carte graphique :

Sous Linux il m’est arrivé maintes fois que l’installeur ne soit pas prévu pour mon format d’écran et me que l’installeur ne fonctionne pas parce qu ‘il me met le moniteur dans les choux, ou qu ‘il se débrouille avec un framebuffer pour l’install, mais me configure mal xorg dans la conf matériel. ou qu ‘il me zappe carrément l’install de xorg. Alors qu ‘il leur suffirait de prendre une résolution plus basse , standard, comme le fait microsoft. Mais ils veulent s’amuser..

Sous OpenBSD il y a un configurateur de Xorg pour l’adapter à sa carte graphique.

Mais il démarre avec un Xorg sans fichier de conf, et ça va très bien.

Si jamais l’interface graphique plante parce qu’ on a voulu configurer sa carte, dans un terminal il suffit en root de supprimer le fichier de conf qu’on a généré, puis de se reconnecter en user et de relancer kde …

Après l’install d’OpenBSD avec le serveur X, et donc fwm ( qui pour moi ne set à rien, mais arrive d’office avec Xorg, qu ‘il est plus simple de laisser installer à OpenBSD ) il faut installer son windows manager ..

On a le choix : KDE Gnome XFCE Openbox

C’est KDE 3.5, mais je déteste KDE4 farci de gadgets inutiles et de bugs depuis sa sortie..

il existe deux systèmes : les package et les ports.

Pour l’instant on oublie le système de ports.

Contrairement aux système Linux avec une base de paquetages et de multiples dépots qui mettent un siècle à afficher la base de paquetages disponibles, c’est simple :

Une commande pour définir le miroir :

Une commande pour installer le paquetage désiré.

Donc au début si on a qu’ un PC , avant d’installer Open BSd , il faut noter le lien exact du miroir, et le nom exact des paquetages de son windows manager, ainsi que de firefox et de l’editeur nano, mais aussi du navigateur en mode texte utilisable en console lynx, nous voilà parés à toute éventualité..

le navigateur en mode texte permet d’avoir la doc d’install en ligne ( idem gentoo ) ou la liste des paquetages.

il n’est pas nécessaire de noter le numéro de version avec l’option -r de pkg-add.

Pkg-add gère les dépendances.

OpenBSD sécurisé par défaut :

Je ne crois pas sur parole et tout au long, je faisais la comparaison avec Linux et Free BSD.

Algorythme de cryptage des mdp :

De nombreux systèmes proposent encore au choix des sytèmes de cryptage consiférés aujourd’hui comme obsolètes ( les bécanes sont beaucoup plus puissantes et les méthodes de crackage des mdp ont beaucoup évolué : voir tables rainbow )

Open BSD propose blowfish un des plus résistant.

Firewall :

FreeBSD propose trois firewalls au choix ( le sien, packet filter et un autre ),
mais il démarre sans firewall… ( à savoir )

OpenBSD propose le sien packet filter, et il est intégré dans le kernel, c’est plus robuste qu’en module externe. quand on veut offrir le choix, c’est forcément en module.

La seule lecture de packet filter m’avait donné envie d’installer OpenBSD.

On peut améliorer celui de Linux avec le suivi de connection : conntrack. j’ai fonctionné longtemps avec, mais un jour un ancien bug est réapparu, au gré des mises à jour, et je démarrais sans firewall..

La conf de PF est plus simple à écrire , selon moi

Autre particularité de packet filter. AuTHPF

avec une appliction interessante pour sécuriser le wifi, vu la faiblesse des protocoles d’authentification de ce dernier, cible de nombreux pirates..

http://www.openbsd.org/faq/pf/fr/authpf.html

Connection SSH :

OpenBSD propose par défaut l’interdiction de connection SSS en root.

Si on a besoin de faire de l’administration à distance, on créra un utlisateur admin (avec un mot de passe balaise ) auquel on n’autorisera que le minimum de commandes dont il a besoin pour faire son job, avec sudo..

En utilisant Open BSD on découvre diverses sécurités :

– un jour on se fait rappeler à l’ordre : trop de processus qui tournent..

– depuis le bureau KDE on ne peut pas lancer d’applis qui ont besoin dêtre en root et qui réclament le mot de passe root. Exemple : obligée de passer en root en console pour lancer k3bsetup.

– le serveur http installé en chroot

Ce n’est pas souvent le cas des serveurs http des Linux grand public pour des raisons de commodité : accès aux répertoires de ladoc au répertoire html desutilisateurs.. on y trouve même un répertoire bin , donc pour des éxécutables…

Certains disent que chroot ne sert à rien vu qu’on peut sortir des chroot, mais enfin c’est déjà balaise, alors que sans chroot avec des CMs et certaines fonctions de php qui devraient être proscrites un pirate peut prendre le controle de tout le PC , ramasser toutes les données d’authentifications à la base MySQL écrites en clair dans un fichier…. ( le php est presquedevenu un Os virtualisé..)

c’est vrai aussi que si on doit ajouter trop de choses dans le chroot, ça ne sert plus à grand chose..

Le serveur http est celui d’ OpenBSD ( un pb de licence ), celui d’ Apache est proposé en paquetage.

Rien n’empĉhe de l’installer pour un usage interne sur le port 8080, verrouillé par packetfilter

http://www.openbsd.org/faq/fr/faq10.html#httpdchroot

Cryptage :

Si on veut un cryptage efficace, il faut absolument crypter la swap, sinon elle contiendra des données en clair..

Chez Free BSD c’est une option et celà nécessite de recompiler le kernel. ce n’est pas la chose la plus simple à faire quand on découvre un nouvel OS.

Il y a des risques d’erreur, aussi OpenBSD a fait en sorte que l’utilisateur novice n’ait pas à recompiler son kernel.

Je l’ai vu aussi pour d’autres choses dans la doc de FreeBSD, et du coup on se dit que ce n’est pas la plus facile à installer pour un novice, même si elle a une interface d’install semi graphique, avec des menus qui ne sont pas toujours clairs..

Pourtant plein de gens qui ne connaissaient pas OpenBSD m’ont dit : installe plutot FreeBSD qui est plus facile d’install

En sécurité il y a deux philosophies :

1 – Ca n’arrivera pas ! j’ai mis telle protection, j’ai mis un mot de passe à rallonge, etc..

2 – Si jamais ça arrivait…( pr exemple la découverte par un pirate d’une vulnérabilité dans une application, qui lui permette de prendre les droits root et qu ‘il installe un rootkit )

Je préfère la seconde, beaucoup plus réaliste.

Ainsi on a des sécurités redondantes, et si jamais un pirate réussissait à passer une protection , il ne pourrait pas faire grand chose et pourrait être repéré par un IDS, avant d’avoir commis des dégats.

Une des portes d’entrée des rootkits est le systeme de chargement des modules dans le kernel LKM , entre autre avec le hotplug ou plug and play. ( donc udev dans Linux qui charge un module dès qu ‘il voit un nouveau périph USB )

Le hotplug ou plug and paly est très pratique pour les utilisateurs lamda : on branche un perih et hop le driver se charge tout seul en mémoire plus une application.

Mais c’est une supervacherie au niveau sécurité, qui est très utilisée pour injecter les rootkits, qui une fois en mémoire se suppriment sur le disque, se recryptent de façon sommaire pour modifier le contenu et empécher son analyse ( partie active ) et se sauvent sur le disque sous un autre nom et une fois cryptés , chaque fois de façon différente, il est impossible d’analyser le contenu pour détecter un nouveau virus…

Même Microsoft qui utilise pourtant une clé d’identification sur les periphs installés s’est fait avoir avec une clé USB traffiquée, avec la signature de Realtek..

Sous Linux on a udev qui sniffe les nouveaux periphs et va charger lemodule correspondant… c’est à dire qu ‘il y a tout pour se faire avoir un jour.

Siemens s’est fait pirater son système de supervision d’automates programmables en Iran par le rootkit Stuxnet, via une clé USB bien étudiée. Un pirate pourrait très utiliser la même technique avec Linux.

Sous OpenBSD il n’y a pas de hotplug, parce qu ‘il est interdit de charger des modules en cours d’ utilisation. Module LKM du kernel :

http://freeworld.thc.org/root/docs/loadable_kernel_modules/openbsd-lkm.html

Pour des raisons pratiques, les developpeurs ont créé un module hotplug pour les disques USB et les SD cards à utiliser dans des conditions bien particulières ( mode singleuser )

Comment les rootkits se cachent ? Par exemple en modifiant les binaires qui listent les processus en mémoire. ils sont modifiés pour ne pas lister le processus du rootkits ( ou alors ils se tuent eux même ). La taille et la signature des binaires modifiés est refaite à l’identique. Donc les chasseurs de rootkits qui vérifient les binaires installés, sont un peu largués.

Les SECURE LEVELS et CHFLAGS

Voilà c’est le système de sécurité complémentaire qu ‘on trouve chez FreeBSD et OpenBSD avec quelques variantes..

Pour la première install d’ Open BSD , il faut considérer que c’est de la découverte et ne pas s’en occuper. parce qu’ on va être géné pour installer d’autres applis à découvrir.

On s’y interressera juste à la fin de l’install pour découvrir ce système et se familiariser avec le principe, les commandes…

Pour faire une install sécurisée, il faut repartir avec un système clean, qui n’a jamais été connecté à internet, et commencer à verrouiller le système au fur et à mesure de l’install et de la configuration.

On pourrait presque mettre le mot de passe root sur la page d’accueil du site installé sur son serveur.

C’est un problème pour un serveur distant, comme un serveur dédié, dans un local où il n’y a pas de personnel.

Pour pouvoir déverrouiller son système il faut être devant la bécane l’arréter, rebooter, et taper une cde particulière à l’invite du boot.

Ce verrouillage est le plus sûr moyen d’empécher un rootkit de s’installer, puisqu’aujour d’hui ils deviennent indécelables, la seule vraie protection est de les empêcher de s’installer..

Pour moi c’est la grande différence avec les autres OS, et au moment où se multiplient les rootkits, surtout depuis qu ‘il y a des opérations finacières sur internet.

Les BSD ne sont pas à l’abri des rootkits !

Même sans hotplug. Il existe un excellent bouquin : comment écrire un Rootkit pour BSD. Un exemple de keylogger est donné.

Le systéme de protection des BSD est composé de deux choses :

– Les securelevel ( niveau de protection )

– Les chflags

On connait les flags rwx des droits de Linux et d’Unix , que l’on peut fixer avec chmod , sur les fichiers ou répertoires, les chflags sont des flags supplémentaires qui vont soit :

– interdire la modification ou la suppression de fichiers, y compris par l’administrateur

– permettre de continuer à enregister des données complémentaires dans les fichiers de logs, mais interdire l’effacement des logs.

Parce que un pirate habile, après une intrusion pour investigations effacera ses traces dans les fichiers de logs.

Donc un chflag particulier a été prévu pour les fichiers de logs, non par parano, mais parce que c’est une réalité du piratage.

Les autres empécheront la modification des binaires, pour cacher les rootkits, l’installation de fichiers dans des répertoires, la modification des fichiers de configuration…

Les chflags se mettent en root, mais après en root on ne peut plus les enlever.

( alors qu’un pirate qui arrive à prendre les droits root, pourra modifier les droits RWX pour pouvoir ensuite modifier un fichier de configuration, remplacer un binaire, installer un exécutable dans un répertoire )

Les secure level , ou niveau de sécurité : .

Sur OpenBSD il y a quatre niveaux de sécurite : -1, 0, 1, 2

Sur FreeBSD il y en a un de plus. Ils ont besoin d’étaler davantage leurs verrouillages.

On ne peut que monter le niveau de sécurité et jamais le descendre.

Un système à cliquet !

Plus on monte le niveau de sécurité moins on peut faire de choses dans le sytème.

Le niveau -1 est non sécurisé. On va pouvoir enlever les chflags. OUF !

Sur OpenBSD , qui par défaut démarre au Niveau 1, on ne peut pas les enlever.

Pour revenir au niveau -1 , non sécurisé, il faut taper une cde spéciale au boot.

A savoir : FreeBSD après l’install démarre au niveau 0.

Open BSD démarre au Niveau 1, sans chflags, mais on peut les ajouter , au fur et à mesure de l’install et de la configuration.

Il ne faut pas le faire six mois après l’install, le PC a pu être contaminé par un virus invisible.

Il faut le faire sur une install propre.

C’est la même règle pour avoir un Linux sécurisé , mais on devra se contenter de monter la partition / en lecture seule, une fois le sytème installé depuis le CD, avant de se connecter sur Internet pour installer des applis qui ne sont pas sur le CD..

On peut donc commencer à verrouiller ses binaires et les éxécutables des applis installées dès qu ‘on a installé OpenBSD avec le CD, avant de se connecter à internet pour télécharger le premier paquet..KDE

Puis ceux des applis qu ‘on installe depuis le miroir..

Et au fur et à mesure on verrouille les fichiers de configuration.

Après, pour que ce soit plus pratique on peut faire des scripts shell

– Un qui déverouille tous les chflags

– Un qui verrouille tous les binaires, éxecutables et fichiers répertoires de conf

– Un qui ne déverouille que les fichiers de conf du /etc

Un qui ne déverrouille que les applis et leur répertoire /usr si on doit en supprimer ou en installer.

Où mettre les scripts ? dans la / répertoire root par exemple root car la / c’est la seule qui sera montée en securelevel = -1. et il n’y a pas de risque de déverrouillage en utilisant ces scripts lorsqu ‘on est en niveau 1 ou 2.

Pour les applis dans /usr pour modifier les chflags, il faudra ajouter dans le script une ligne de montage de la partition /usr et à la fin une ligne de démontage.

Au niveau maxi de sécurité 2 on ne peut plus recharger les règles de packet filter.

Pour moi c’est vraiment le plus des BSD, on arrive à avoir un système blindé de chez blindé..

http://www.openbsd.org/fr/security.html

http://www.openbsd101.com/security.html

———————————————————————————————————

SECURELEVEL(7) OpenBSD Reference Manual

NAME
securelevel – securelevel and its effects

DESCRIPTION
The OpenBSD kernel provides four levels of system security:

-1 Permanently insecure mode

– init(8) will not attempt to raise the securelevel
– may only be set with sysctl(8) while the system is insecure
– otherwise identical to securelevel 0

0 Insecure mode

– used during bootstrapping and while the system is single-user
– all devices may be read or written subject to their permissions
– system file flags may be cleared with chflags(2)

1 Secure mode

– default mode when system is multi-user
– securelevel may no longer be lowered except by init
– /dev/mem and /dev/kmem may not be written to
– raw disk devices of mounted file systems are read-only
– system immutable and append-only file flags may not be removed
– kernel modules may not be loaded or unloaded
– the fs.posix.setuid sysctl(8) variable may not be changed
– the net.inet.ip.sourceroute sysctl(8) variable may not be
changed
– the machdep.kbdreset sysctl(8) variable may not be changed
– the ddb.console and ddb.panic sysctl(8) variables may not be
raised
– the machdep.allowaperture sysctl(8) variable may not be raised
– gpioctl(8) may only access GPIO pins configured at system
startup

2 Highly secure mode

– all effects of securelevel 1
– raw disk devices are always read-only whether mounted or not
– settimeofday(2) and clock_settime(2) may not set the time
backwards or close to overflow
– pf(4) filter and NAT rules may not be altered

Securelevel provides convenient means of “locking down” a system to a
degree suited to its environment. It is normally set at boot via the
rc.securelevel(8) script, or the superuser may raise securelevel at any
time by modifying the kern.securelevel sysctl(8) variable. However, only
init(8) may lower it once the system has entered secure mode. A kernel
built with option INSECURE in the config file will default to permanently
insecure mode.

Highly secure mode may seem Draconian, but is intended as a last line of
defence should the superuser account be compromised. Its effects
preclude circumvention of file flags by direct modification of a raw disk
device, or erasure of a file system by means of newfs(8). Further, it
can limit the potential damage of a compromised “firewall” by
prohibiting the modification of packet filter rules. Preventing the
system clock from being set backwards aids in post-mortem analysis and
helps ensure the integrity of logs. Precision timekeeping is not
affected because the clock may still be slowed.

Because securelevel can be modified with the in-kernel debugger ddb(4), a
convenient means of locking it off (if present) is provided at
securelevels 1 and 2. This is accomplished by setting ddb.console and
ddb.panic to 0 with the sysctl(8) utility.

————————————————————————————————————————

CHFLAGS(1) OpenBSD Reference Manual CHFLAGS(1)

NAME
chflags – change file flags

SYNOPSIS
chflags [-R [-H | -L | -P]] flags file …

DESCRIPTION
The chflags utility modifies the file flags of the listed files as
specified by the flags operand. The flags of a file dictate special
restrictions beyond those enforced by its mode/permissions. Only the
superuser can change the user flags on block and character devices.

You can use ls -lo to see the flags of existing files.

The options are as follows:

-H If the -R option is also specified, symbolic links on the command
line are followed. (Symbolic links encountered in the tree
traversal are not followed.)

-L If the -R option is also specified, all symbolic links are
followed.

-P If the -R option is also specified, no symbolic links are
followed.

-R Recursively descend through any specified directory arguments.
Change the flags of the file hierarchies rooted in the files
instead of just the files themselves.

Flags are a comma separated list of keywords. The following keywords are
currently defined:

arch set the archived flag (superuser only)
nodump set the nodump flag (owner or superuser only)
sappnd set the system append-only flag (superuser only)
schg set the system immutable flag (superuser only)
uappnd set the user append-only flag (owner or superuser only)
uchg set the user immutable flag (owner or superuser only)

The “arch” flag is for compatibility only, and currently has no effect.

A file with the “nodump” flag set will by default only be backed up by
dump(8) during full backups. The -h option of dump(8) can be used to
alter this.

An immutable file may not be changed, moved, or deleted. An append-only
file is immutable except that data may be appended to it.

The superuser-settable “sappnd” and “schg” flags can be set at any
time, but may only be cleared when the system is running at security
level 0 or -1 (insecure or permanently insecure mode, respectively). For
more information on setting the system security level, see
securelevel(7).

Putting the letters “no” before a flag name causes the flag to be
turned off. For example:

nouchg the immutable bit should be cleared

Symbolic links do not have flags, so unless the -H or -L option is set,
chflags on a symbolic link always succeeds and has no effect. The -H,
-L, and -P options are ignored unless the -R option is specified. In
addition, these options override each other and the command’s actions are
determined by the last one specified.

——————————————————————————————————

Inconvénients :

– on ne peut pas lire les systèmes de fichiers de Linux ext3 ext4 reiser

– malgré ce qui est noté je n’ai pas pu lire les ext2 ( pb à voir )

– je n’avais plus le driver splix, pour les imprimantes samsung.

pas trop grave il y a longtemps que la mienne est naze

– pas de driver nvidia donc pas d’accélération 3D, mais vu que je ne joue pas …

– pas de wireshark , un logiciel que j’aimais bien et que j’utilisais souvent.

je ne lui ai pas encore trouvé de remplaçant

Les plus :

– la swap gérée autrement. j’avais peu de mémoire ram au début, j’y allais souvent avec Linux, et très vite on au bruit du disque on sait qu ‘on est en train de swapper et ça commence à ramer grave..

Avec Open BSD , je n’ai jamais entendu ce bruit des têtes du disque et ça ramait beaucoup moins..

– Installation des polices

je redoutais le pire, sous Linux pas toujours facile de rajouter des polices non prévues pour Linux…

la j’ai pu piquer des polices pour windows, j’ai décompressé les fichiers archives de polices, je n’ai pris que le fichier de police et je les ai mis à leur place.

une ou deux petites commandes qui concernent les polices en suivant la doc et j’ai eu de supers polices..

j’en ai usé et abusé avec gimp pour faire des logos et des boutons, des wallpapers ( je trouvais ceux d’OpenBSD un peu tristounets..).

Mon bureau personnel

bureau travail

Petit clin d’oeil sur ce wallpaper, d’une grand mère qui a connu Woodstock, puis qui a accompagné ses enfants pour voir le Satch en concert . Waouh ça décoiffe. Je suis restée fan.

Quand à l’occupation du système de la mémoire, pour une petite bécane avec 512 Mo de RAM , une image vaut mieux que des commentaires.

OpenBSD occupation system

Publicités
Cet article a été publié dans BSD. Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s