Sécurisez FreeBSD
Un article de Projet de documentation fug-fr .
Traduction avec l'aimable autorisation de l'auteur, d'un article intitulé Securing FreeBSD de Dru Lavigne, dans la série FreeBSD Basics sur le site BSDDevCenter d'ONLamp
Sommaire |
[modifier] Introduction:
Ces derniers jours, j'ai trié mes piles de notes, et organisé un article sur la sécurité, notes que
j'ai recueillies depuis diverses sources au fil des années. J'ai pensé à l'intérêt qu'elles
présentent pour vous, aussi, cette semaine, je fais une pause sur la série archives, et écris un peu
sur la sécurisation de votre système FreeBSD.
Evidemment, je ne pourrais pas donner l'assurance complète d'un si large sujet, dans le confinement
d'un article. Ce qui est aussi bien, puisqu'il est impossible de créer du prêt-à-porter qui
garantirait la sécurité de n'importe quel système.
Pendant que je trie mes notes, je remarque que la plupart sont adaptées à durcir la sécurité d'un
système FreeBSD qui agit en tant que serveur (par exemple serveur web, serveur de courrier). Ce
qui n'est pas forcément nécessaire, si vous utilisez votre système FreeBSD en tant que station
de travail personnelle, et désirez une pleine fonctionnalité d'ordinateur de bureau. Vous seriez
très malheureux, si une configuration de sécurité bloquait une fonctionnalité qui vous a demandé une
semaine de lutte, pour apprendre comment la faire fonctionner en premier lieu.
Pour cette raison, vous noterez que, à la différence de la plupart des cours de sécurité, cet
article ne changera aucune des permissions sur votre système FreeBSD. C'est intentionnel. A
moins que vous sécurisiez un serveur de production, et que vous savez ce que vous faites, ne changez
jamais les permissions de n'importe quel fichier. (Si vous devez user des permissions, restez en aux
fichiers de votre répertoire local). Autrement, les choses pourraient cesser de fonctionner; choses
que vous pourriez bloquer comme l'email, le système de fenêtrage de X, le son.
[modifier] Les filtres:
Les choses étranges arriveront aux heures étranges, en rendant plus difficile l'identification, du fait qu'elles sont liées à la permission avec laquelle vous avez joué une semaine auparavant. Nous savons tous que l'Internet n'est pas toujours un endroit amical, et que vous ne voulez probablement pas donner au reste du monde le même accès à votre système que vous vous donnez. Ceci signifie que vous ne voulez pas aller sur l'Internet, sans être protégé par un filtre. Heureusement, votre système FreeBSD supporte deux filtres: ipfw et ipfilter. Encore mieux, la quantité de documentation conviviale s'est solidement améliorée au cours de la dernière année. Si vous n'êtes pas derrière un filtre, consacrez un après-midi à en faire une lecture, et configurez un filtre fonctionnel sur votre système. Vous en serez heureux. Voici quelques ressources pour vous permettre de commencer:
man ipfw [1]
Handbook:Firewalls
Setting up a Dual-Homed Host using IPFW and NATD
IPFilter and PF resources
[modifier] Les services:
La bonne sécurité est toujours la "défense en profondeur", signifiant que si un mécanisme échoue, il
y en a un de sauvegarde. Quoique votre système soit maintenant protégé par un filtre, vous devriez
également invalider tous les services, exceptés ceux dont vous avez absolument besoin. Sur un système
de bureau, vous avez besoin de très peu de services.
Pour voir quels services sont à l'écoute de tentatives de connexion sur votre système, employez cette commande:
sockstat -4
votre sortie variera, selon les configurations que vous avez choisies pendant la phase finale
d'installation de FreeBSD et selon quels ports et modules ont été installés depuis. Il est très commun de voir le port 6000 (serveur de fenêtres de X) dans la sortie ; si vous ne l'avez pas, démarrez une session X, et réexécutez sockstat -4. Malheureusement, il y a eu beaucoup
d'exploits sur X au cours des années; heureusement, vous n'avez pas besoin de laisser le port
6000 ouvert afin d'utiliser X sur votre système. Ne vous inquiétez pas, vous aurez toujours une GUI
si vous fermez ce port !
Il y a plusieurs facons de fermer ce port; j'ai trouvé que le plus facile est de passer en super-utilisateur, et d'éditer /usr/X11R6/bin/startx. Trouvez la ligne serverargs, et changez la de sorte qu'elle ressemble à ceci:
serverargs="-nolisten tcp"
Une fois vos changements sauvegardés, démarrez X, et réexécutez sockstat -4. Si vous n'avez aucune sortie, X se lancera comme d'habitude, mais le port 6000 fermé sera manquant dans votre sortie sockstat -4.
Si vous voulez en savoir plus sur les risques de laisser le port 6000 ouvert, voici un cours de
sécurité sur le fenêtrage X.
OK, il y a moins de services dans votre sortie sockstat - 4. Vous avez probablement toujours deux ports qui traitent le courrier: ports 25 (smtp) et 587 (requête).
[modifier] Sendmail:
Vous n'avez pas besoin du port 587 pour envoyer/recevoir du courrier; pour le fermer, vous pouvez éditer /etc/mail/sendmail.cf. Trouvez cette ligne:
O DaemonPortOptions=Port=587, Name=MSA, M=E
et mettez un # devant pour la commenter. Puis, pour que sendmail lise votre changement :
killall -HUP sendmail
HUP n'arrêtera pas sendmail, mais lui indiquera de lire les changements que vous avez fait dans /etc/mail/sendmail.cf. Relancez sockstat -4, il ne devrait plus y avoir le port 587. Que diriez-vous du port 25 ? Vous pouvez ou pouvez ne pas devoir laisser ce port ouvert, selon le programme utilisé pour envoyer et lire votre courrier. Si vous exécutez FreeBSD 4.6-RELEASE ou ultérieurs, mettez cette ligne dans /etc/rc.conf:
sendmail_enable="NO"
Ceci indiquera à sendmail d'écouter seulement en localhost, et permettra à n'importe quel client de courrier de pouvoir envoyer un courrier. Si vous savez que votre client de courrier a son propre agent intégré smtp, ou si vous vous sentez aventureux, essayez cette ligne à la place:
sendmail_enable="NONE"
Ce qui fermera le port 25. Pour voir si vous avez toujours la capacité d'envoyer un courrier, assurez-vous d'avoir fermé tous vos terminaux, sauvegardez tout votre travail. Puis, en tant que super-utilisateur:
shutdown now
validez à l'invite de commande, puis exit. Une fois reconnecté, voyez si vous pouvez envoyer un message-test à votre compte courrier. Si vous ne pouvez pas, allez de nouveau au mot NO, et répétez ce qui précède pour rouvrir le port 25 pour localhost.
[modifier] Autres services:
Si le port 111 (portmap) apparait dans votre sortie sockstat, enlevez-le en ajoutant les lignes suivantes à /etc/rc.conf (ou, si une ligne existe déjà dans le fichier, changez le YES en NO):
nfs_server_enable= "NO" nfs_client_enable= "NO" portmap_enable= "NO"
Portmap est seulement nécessaire si vous exécutez NFS, qui vous ne sera guère utile sur un
ordinateur de bureau FreeBSD. Il a également une longue histoire d'avis de sécurité, et si vous
n'en avez pas absolument besoin, désactivez-le.
Syslog (port 514), montrera probablement également une sortie. Si vous ne voulez pas désactiver syslog complètement, pour recevoir les messages de connexions, vous n'avez cependant pas besoin d'avoir ce port ouvert. Dans votre fichier /etc/rc.conf, assurez-vous que syslog est permis, et ajoutez une deuxième ligne avec quelques options:
syslogd_enable= "YES" syslogd_flags= "-ss"
Ces deux s (assurez vous d'avoir les deux, pas simplement un) dans les flags invalideront l'enregistrement des serveurs distants, et ferment ce port, mais permettent toujours à votre localhost de conserver ses capacités d'enregistrement. Ensuite, assurez-vous qu' inetd_enable n'est pas positionné sur YES dans votre /etc/rc.conf. Si inetd se révèle dans votre sortie sockstat, quelque chose a été décommenté dans /etc/inetd.conf. Si vous n'en avez pas besoin, remettez un # devant cette ligne, et faites un killall inetd. Si vous obtenez votre adresse IP du serveur DHCP de votre ISP, maintenez dhclient (port 68) ouvert, ou vous ne pourrez pas renouveler votre adresse IP.
[modifier] Scripts de démarrage:
Si vous trouvez autre chose dans votre sortie sockstat, parcourez man rc.conf pour voir s'il y a une option pour l'invalider. S'il n'y en a pas, elle a été très probablement lancée par un script de démarrage, installé avec un module ou un port. Si c'est le cas:
cd /usr/local/etc/rc.d
Pour voir quels scripts de démarrage ont été ajoutés à votre système. La plupart des modules/ports installeront un script exemple avec une extension sample. Tant qu'elle se termine par sample, cette séquence type ne fonctionnera pas à la mise en route. D'autres modules ou ports installent un script fonctionnel, qui est lu au boot, et vous trouverez le coupable dans ce répertoire. La manière la plus facile d'invalider le script est de le renommer avec une extension sample, ce qui annihile le démon, de sorte que son port n'apparait plus dans sockstat -4. Par exemple, j'ai récemment installé ethereal, et note que snmpd est apparu dans ma sortie sockstat -4. Le daemon snmp a une longue histoire d'exploits, et je ne l'ai pas voulu à l'écoute sur mon système. Je suis passé en super-utilisateur, et ai fait ceci:
cd /usr/local/etc/rc.d mv snmpd.sh snmpd.sh.sample killall snmpd
[modifier] Visibilité Internet:
Vous pourriez également vouloir ajouter les options suivantes dans /etc/rc.conf:
tcp_drop_synfin= "YES"
Cette option empêche quelque chose connue sous le nom "d'empreinte digitale d'OS", qui est une technique de balayage employée pour déterminer le type du système d'exploitation sur un serveur. Si vous décidez de permettre cette option, vous devrez également reconstruire votre noyau avec l'option suivante inclue dans votre fichier de configuration du noyau:
options TCP_DROP_SYNFIN
Deux options associées sont:
icmp_log_redirect= "YES" icmp_drop_redirect= "YES"
Les redirections ICMP peuvent être utilisées pour lancer une attaque DDOS, comme expliqué dans
la partie redirection d'ICMP ARP and ICMP.
Faites très attention, si vous décidez d'inclure l'option icmp_log_redirect, car elle
enregistrera chaque ICMP redirigée, avec le potentiel de dépasser la capacité de votre
répertoire d'enregistrement, si vous êtes la victime de ce type d'attaque.
Quand vous avez construit votre filtre, vous avez probablement inclus cette option:
log_in_vain= "YES"
Sinon, c'est une bonne option à inclure, car elle enregistre toutes les tentatives sur les ports fermés. Une autre option intéressante est:
accounting_enable= "YES"
Ceci permettra la compatibilité systèmes. Si vous êtes nouveau avec la compatibilité entre systèmes,
lisez man sa et man lastcomm pour décider si cette option sera utile ou non.
En conclusion, une bonne option à inclure est:
clear_tmp_enable= "YES"
car elle efface /tmp à la mise en route, ce qui est toujours une bonne chose.
[modifier] Cryptage:
Regardons /etc/rc.conf, et voyons ce qui peut encore durcir notre système. J'aime changer
l'algorithme par défaut utilisé en chiffrant le mot de passe d'un utilisateur, en algorithme
blowfish, car il fournit la sécurité la plus élevée à une plus grande vitesse. Voici une
comparaison rapide des algorithmes.
En outre, si vous êtes intéressé par le cryptage, consultez Cryptogram newsletter, le bulletin écrit par l'auteur de blowfish. Pour mettre en application blowfish, éditez /etc/login.conf, et changez la ligne passwd_format de sorte qu'elle ressemble à ceci:
:passwd_format=blf:\
Sauvegardez votre modification, reconstruisez alors la base de données de procédures de connexions avec cette commande:
cap_mkdb /etc/login.conf
Vous devrez alors changer tous les mots de passe de vos utilisateurs, ainsi ils obtiendront de nouveaux criptages blowfish. Vous pouvez faire ceci en tapant:
passwd username
en tant que super-utilisateur. Quel que soit le username que vous utilisez, ce sera l'utilisateur dont le mot de passe sera mis à jour. Idem pour tous vos utilisateurs, y compris le compte root. Une fois terminé, vérifiez que cela a fonctionné, et que vous n'avez oublié aucun utilisateur:
more /etc/master.passwd
Tous les mots de passe de vos utilisateurs devraient commencer par $2. En conclusion, configurez l'utilitaire adduser pour utiliser blowfish à chaque fois que vous créez un nouvel utilisateur, en éditant /etc/auth.conf. Changez la ligne crypt_default, de sorte qu'elle ressemble à ceci:
crypt_default=blf
[modifier] Visibilité dans les consoles:
Vous avez probablement remarqué que, quand vous ouvrez une session sur votre système FreeBSD, votre demande de connexion vous rappelle que vous exécutez FreeBSD. Et après l'ouverture d'une
session, vous recevez l'information du copyright FreeBSD, qui est suivie de la version de
FreeBSD et du nom de votre noyau. Et à la fin, un motd (accueil) utile, qui vous rappelle
encore que vous exécutez FreeBSD. Vous savez probablement déjà quelle version de FreeBSD vous exécutez, et pourriez ne pas vouloir partager cette information avec le reste du monde.
Et motd est un bon endroit pour rappeler au reste du monde qu'il ne devrait pas salir votre système de toute façon.
Vous pouvez éditer /etc/motd , dire ce que vous voulez, que ce soit n'importe quoi sorti de
votre imagination, ou toutes choses méchantes qui arriveraient à quelqu'un s'il continue à tenter
d'ouvrir une session sur votre système.
Ensuite, pour retirer l'information du copyright:
touch /etc/COPYRIGHT
Changez alors le texte qui apparaît à la demande de procédure de connexion, et éditez /etc/gettytab. Trouvez la ligne dans la section default:\ qui commence par:
cb:ce:ck:lc
Soigneusement, changez le texte entre \ r \ n et \ r \ n \ r \ n: par le texte que vous souhaitez. Vérifiez une deuxième fois que vous avez la bonne quantité de \rs et \ns et sauvegardez votre changement. Par exemple, ma demande de procédure de connexion ressemble à ceci:
Je suis un noeud dans cyberespace. Qui êtes-vous ? login:
Vous pouvez tester vos changements en allant sur un autre terminal, et en vous y connectant.
En conclusion, quoi que vous ayez édité dans motd, pour enlever votre version et information de
noyau, par défaut FreeBSD les réajoutera à /etc/motd, à chaque procédure de connexion.
Pour empêcher ce comportement, ajoutez la ligne suivante dans /etc/rc.conf:
update_motd= "NO"
Ce changement exige une réinitialisation, aussi vous vous assurerez d'avoir d'abord testé aussi vos changements précédents, et sauvegardé tout votre travail sur les autres terminaux.
[modifier] Précautions:
Il y a en premier lieu quelques éditions à faire, qui limiteront aussi les procédures de connexion
sur votre système. Puisque ces changements modifient le comportement du programme de procédure de
connexion, vous voudrez tester soigneusement ces changements. Maintenez un terminal ouvert, et allez
à un autre terminal: s'y déconnecter et s'assurer de pouvoir encore ouvrir une session.
Si pour quelque raison vous ne pouvez pas ouvrir une session (ceci ne devrait pas se produire, mais vous ne pouvez pas en être sûr), vous pouvez retourner à l'autre terminal et rechercher dans les fichiers que vous venez juste d'éditer.
[modifier] Sécuriser les consoles:
Personne (vous y compris), ne devrait jamais ouvrir une session sur votre système, en utilisant le
compte root. Pour empêcher ceci de se produire, éditez /etc/ttys. Une fois passé une page
entière de commentaires, vous noterez une section qui va de ttyv0 à ttyv8. Changez le mot
secure sur chacune de ces lignes, en insecure. C'est un fichier que vous ne voudrez pas
éditer deux fois, ainsi vérifiez soigneusement une deuxième fois vos changements.
Testez par l'essai d'une procédure de connexion comme root sur un de vos terminaux. Vous devriez recevoir un message Login incorrect.
Personnellement, je tends à utiliser chacun des neuf terminaux sur mon ordinateur de bureau. Sinon, vous pouvez également changer le mot ON en OFF sur seulement quelques ttys dans /etc/ttys. Rappelez-vous de laisser au moins un terminal en fonction, ou bien, il ne sera pas possible d'ouvrir une session, ce qui entravera sévèrement l'usage de votre système. Vous noterez également que ttyv8 est OFF par défaut, ce qui signifie que vous devez lancer manuellement une session X. Si vous voulez que X démarre automatiquement au boot, changez ce OFF en ON.
[modifier] Accès aux consoles:
La suite de cet article mentionnera comment permettre l'ouverture d'une session, par qui, et d'où. Ceci se configure dans /etc/login.access.
Si vous voulez empêcher toutes les requêtes de connexion distantes (signifiant que vous pouvez seulement ouvrir une session si vous vous asseyez physiquement à votre ordinateur), retirez le # de cette ligne :
# -:wheel:ALL EXCEPT LOCAL .win.tue.nl
Et retirez .win.tue.nl, de sorte que la ligne ressemble maintenant à ceci:
-:wheel:ALL EXCEPT LOCAL
Si vous projetez d'accéder à votre système à distance, substituez .win.tue.nl avec l'adresse(s)
IP ou hostname(s) du système(s) à partir duquel vous entrerez. S'il y a des adresses
multiples, séparez-les avec un espace simple.
Si vous avez seulement un ou deux comptes utilisateurs auxquels vous souhaitez laisser ouvrir une session sur votre système, vous pouvez empêcher toutes autres procédures de connexion comme suit:
-:ALL EXCEPT USER1 USER2 :ttyv0 ttyv1 ttyv2 ttyv3 ttyv4
Substituez user1 user2 avec les noms des comptes d'utilisateurs, auxquels vous souhaitez donner l'accès. Mettez autant de ttys que vous souhaitez en restreindre.
[modifier] Groupes:
Alternativement, vous pouvez placer les utilisateurs dans une procédure de connexion par groupe, et donner plus de souplesse à ce groupe. Dans cet exemple, j'ajoute "genisis", "biko", et "dlavigne6" à un groupe appelé "mygroup", et permets seulement aux membres de ce groupe la procédure de connexion sur mon système FreeBSD. D'abord, éditez /etc/group, et ajoutez soigneusement cette ligne:
mygroup :*:100:genisis,dlavigne6,biko
Quand vous ajoutez votre propre groupe, assurez-vous que vous utilisez un GID (dans mon cas, 100), qui n'est utilisé dans aucune autre ligne du fichier /etc/group.
Puis, modifiez /etc/login.access:
-:ALL EXCEPT mygroup:ttyv0 ttyv1 ttyv2 ttyv3 ttyv4 ttyv5
Il est très important de tester ce changement. Laissez un terminal ouvert, juste au cas où quelque
chose tournerait mal. Allez dans un autre terminal, et faites différents essais d'ouverture de session, en
tant que chacun des utilisateurs successifs de votre groupe. Cela devrait fonctionner. Puis testez la procédure de connexion comme un autre utilisateur; si besoin est, créez un compte d'essai, et
essayez d'ouvrir une session dans ce compte d'essai. La tentative de connexion devrait avoir comme conséquence un message permission denied.
C'est tout l'espace dont je dispose cette semaine. Dans un prochain article, je reprendrai la série
archivage, en expliquant un utilitaire peu connu, mais très maniable, pax.
Si vous avez regardé mon email récemment, vous avez noté que mon adresse a changé. Je peux maintenant être jointe à:
Dru Lavigne enseigne les technologies Marketbridge à Ottawa, et participe à l'Open Ressource Protocole.
