S�curiser un r�seau h�t�rog�ne avec des outils libres

ArticleCategory:

System Administration

AuthorImage:

Georges Tarbouriech

TranslationInfo:[Author and translation history]

original in fr Georges Tarbouriech  

AboutTheAuthor

Georges est un vieil utilisateur d'Unix. Il remercie la communaut� du logiciel libre de nous fournir une telle quantit� de tr�s bons outils de s�curit�.

Abstract:

Cet article a �t� publi� dans un num�ro sp�cial sur la s�curit� de Linux Magazine France. L'�diteur, les auteurs, les traducteurs ont aimablement accept� que tous les articles de ce num�ro hors-s�rie soient publi�s dans LinuxFocus. En cons�quence, LinuxFocus vous "offrira" ces articles au fur et � mesure de leur traduction en Anglais. Merci � toutes les personnes qui se sont investies dans ce travail. Ce r�sum� sera reproduit pour chaque article ayant la m�me origine.

ArticleIllustration:

secure it

ArticleBody:[The article body]

Pr�ambule

La s�curit� informatique est certainement l'une des grandes questions technologiques du 21�me si�cle.
Mais comme pour tous les domaines pr�occupants, tout le monde en parle mais ceux qui devraient se sentir les plus concern�s ne semblent pas encore avoir per�u l'�tendue du d�sastre potentiel. Les "plus concern�s" sont bien �videmment les grands �diteurs de logiciels, de syst�mes. Le plus bel exemple, vient une fois de plus de Redmond, o� la s�curit� semble n'�tre qu'un mot, au demeurant beaucoup moins bien ma�tris� que "marketing", par exemple.
Par chance, les deux derni�res d�cennies du 20�me si�cle ont connu l'av�nement du logiciel libre et de sa philosophie. Si vous "souhaitez" am�liorer la s�curit� de vos machines, de vos syst�mes, de vos r�seaux... c'est l� qu'il faudra chercher. La communaut� du logiciel libre a plus fait pour la s�curit� que tous les grands �diteurs r�unis.
Cela dit, les outils ne font pas tout, et la s�curisation d'un r�seau, par exemple, est un travail quasi permanent : tout change, tout le temps ! Ca signifie qu'on ne pourra jamais garantir qu'un r�seau est s�r � 100%. On ne pourra que diminuer les risques. Ce que nous abordons ici, n'est qu'une partie des moyens de limiter ces risques. Apr�s avoir lu ce num�ro sp�cial (NDA : rappelez-vous, cet article faisait partie d'un num�ro hors-s�rie de Linux Magazine France sur la s�curit�), vous en saurez sans doute plus sur la s�curit�, mais en aucun cas vous ne pourrez affirmer que votre r�seau est s�r. Vous voici pr�venus. Derni�re pr�cision : un tel article ne peut �tre exhaustif. Il existe une �norme quantit� de litt�rature sur le sujet et elle n'a toujours pas fait le tour du probl�me, loin de l�. Par cons�quent, n'attendez pas d'un article qu'il aborde tous les cas de figure, qu'il s'agisse d'OS, d'outils, de configuration, d'utilisation... Pour conclure ce pr�ambule, nous devons ajouter que certains paragraphes sont emprunt�s � des articles parus dans le magazine en ligne LinuxFocus, mais rassurez-vous, avec l'agr�ment de l'auteur : c'est le m�me !

Pr�sentation

Nous aborderons tout d'abord l'architecture d'un r�seau tr�s h�t�rog�ne, compos� de syst�mes plus ou moins r�pandus. Plus les OS sont nombreux, plus la t�che est complexe, ces syst�mes n'�tant bien �videmment pas �gaux face � l'adversit�... De plus les machines serveurs ont souvent un r�le diff�rent au sein d'un r�seau : nous essaierons donc de varier leurs attributions. Nous traiterons ensuite d'une panoplie d'outils indispensables � l'am�lioration de la s�curit�. Le choix sera arbitraire : il en existe beaucoup trop pour ne serait-ce que les mentionner tous. Bien �videmment nous en profiterons pour expliquer la s�curisation des machines et du r�seau gr�ce � ces outils. Le chapitre suivant servira � faire un tour d'horizon des particularit�s de diff�rents syst�mes durant la phase de s�curisation. Nous conclurons par la "relativit�" de la s�curisation, pour essayer de montrer � quel point la route est longue, sans pour autant faire de prospective.

Exemple de r�seau h�t�rog�ne

Le protocole TCP/IP poss�de comme avantage premier d'�tre "parl�" par tous les OS de la plan�te. Gr�ce � lui des syst�mes totalement diff�rents sont capables de communiquer, d'�changer. Compte-tenu du type de r�seau que nous allons traiter, TCP/IP sera toujours le protocole utilis�. En clair, ne seront pas abord�s les protocoles propri�taires, ou les moins r�pandus ou les carr�ment d�suets. Nous ne nous attarderons pas sur la structure physique, autrement dit le type de connexion, la cat�gorie utilis�e, etc.
Donc, ce r�seau, nous allons y mettre un peu de tout. Bien s�r, nous allons y trouver de l'Unix, commercial et libre : par exemple, du Solaris 2.6 ou SunOS 5.6, si vous pr�f�rez, de l'Irix 6.5, du Linux (RH 6.2), du Mac OS X. Nous aurions pu ajouter QNX ou NeXTstep, ou encore NetBSD ou OpenBSD. C�t� "conventionnel", nous int�grerons l'in�narrable Non Termin� 4.0 (non pas les autres, ils sont encore pires). L�-aussi, nous aurions pu ajouter OS2 qui est quand m�me beaucoup moins catastrophique. Enfin, nous allons ajouter du "non conventionnel", � savoir BeOS et AmigaOS (si, �a existe... enfin, plus vraiment !).
Alors, il y en a d�j� qui se plaignent : quoi, pas d'AIX, de HP-UX ? Ben non ! Si nous devions traiter tous les Unixes (oui, Unices, c'est plus classe) du march�, ce serait un article en dix volumes. Toutefois, les r�gles de base sur la s�curit� sont applicables � tous les syst�mes sans exception.

Maintenant, qu'allons-nous leur demander ?
Par exemple, nous allons supposer que Solaris soit serveur d'applications. Irix va g�rer les sauvegardes. NT va servir d'autres applications. Linux va servir de passerelle vers le monde ext�rieur. Un autre Linux pourra servir de serveur http ou de serveur de bases de donn�es. Consid�rons que tout le reste, ce sont des clients. Nous allons consid�rer qu'il s'agit d'un petit r�seau d'une trentaine de machines de mani�re � utiliser une authentification par fichiers. Nous aurions pu choisir quelque chose de plus �labor� pour l'authentification : NIS (ex Yellow Pages) ou encore LDAP ou Kerberos... Faisons simple, l'exemple n'en aura que plus de valeur ! Nous n'utiliserons pas non plus NFS, m�me si ce peut �tre parfois tr�s pratique. Question s�curit�, on fait mieux, m�me s'il y a eu certains progr�s dans le domaine.
Selon le bon vieil adage "ne mettons pas tous nos oeufs dans le m�me panier", les services ou protocoles "douteux" mais indispensables n'existeront qu'� un seul exemplaire, sur des machines qui ne feront que �a. Par exemple, un seul serveur ftp, un seul serveur http, de pr�f�rence sous Unix, bien s�r. Nous aurons �galement quelques serveurs SSH sur les machines Unix et des clients SSH sur les autres syst�mes. Nous y reviendrons. Enfin, l'adressage IP sera statique : en clair, pas de DHCP. En r�sum�, nous allons faire "basique" !
Cela bien s�r, n'est applicable que sur un r�seau de moins de 50 machines : au-del�, �a deviendrait vite cauchemardesque. (On pourrait m�me dire 30 machines !).

Outils et s�curisation

Comme toujours, il y a plusieurs fa�ons de faire (TIMTOWDI). Le cas id�al serait de partir de z�ro, avec des machines � installer et le r�seau � mettre en place. Mais, �a c'est dans les films ! Dans notre cas, consid�rons que le r�seau est en production depuis longtemps, que les machines vont et viennent au fil du temps. En raison de l'escalade ambiante, par exemple, les machines Intel d'aujourd'hui ne vivent pas tr�s longtemps. Au bout de trois ans, environ, il devient difficile de trouver des pi�ces d�tach�es. Ainsi, soit vous recyclez les machines vers d'autres fonctions "subalternes", soit vous vous en d�barrassez : triste mais vrai ! Heureusement, d'autres durent beaucoup plus longtemps et valent la peine d'�tre am�lior�es � moindre co�t... quoi que. Contrairement aux apparences, ce n'est pas hors-sujet : un administrateur n'a pas le droit de risquer la panne et les probl�mes qui en d�coulent.

Le B A BA

Dans ces conditions, le premier travail est celui que nous pourrions nommer "g�n�ralit�s". Il consiste � supprimer tout ce qui est inutile sur chaque machine : ce n'est pas une mince affaire ! Chaque OS, Unix compris, installe par d�faut un nombre incalculable de services, de protocoles dont vous ne vous servirez jamais. Le mot d'ordre, c'est : virez-les ! Une chose simple et brutale, consiste � tout mettre en commentaire dans /etc/inetd.conf sous Unix. C'est d�j� �a de moins. Bien sur, c'est un peu exag�r�, mais sur de nombreuses machines ce sera parfaitement r�alisable. C'est fonction de vos besoins. Sous Linux et quelques autres, vous pourrez utiliser la commande chkconfig pour d�sactiver certains services.
V�rifiez aussi les fichiers SUID/SGID root et n'h�sitez pas � supprimer les bits en question ou � d�sactivez le programme concern�. Une commande telle que :
find / -user root -a \( -perm -4000 -o -perm -2000 \) -print
vous fournira la liste. Ensuite, � vous de voir. Pour d�sactiver les bits "s", tapez chmod a-s nomduprogramme.
Supprimez les programmes "dangereux" ou connus pour �tre vuln�rables. Les "remote commands" telles que rsh, rlogin, rcp, par exemple. SSH les remplacera tr�s bien.
V�rifiez les permissions dans les r�pertoires tels que /etc, /var... Plus, les droits sont restrictifs, mieux c'est. Par exemple, un petit chmod -R 700 sur le r�pertoire contenant les fichiers de d�marrage (/etc/rc.d/init.d sous diff�rents Unixes) n'est pas une mauvaise id�e.
Le m�me raisonnement s'appliquera � tous les syst�mes faisant partie du r�seau : supprimer tout ce qui ne sert pas ou au moins d�sactiver. Pour NT, n'h�sitez pas � "taper" dans les services du panneau de configuration. Il existe une infinit� de choses basiques � faire.

Les outils

A tout seigneur tout honneur : commen�ons par Unix, et pour cause, c'est le seul � prendre vraiment en consid�ration les probl�mes de s�curit�. Ensuite la panoplie d'outils libres est "colossale" et fonctionne sur toutes les saveurs d'Unix (presque).

Pour l'instant, nous allons travailler sur les machines, puisque s�curiser un r�seau, c'est avant tout s�curiser ses composants. L'installation de ces outils �tant "classique", nous ne la d�crirons pas. Leur param�trage d�pend �galement des syst�mes utilis�s, des besoins... A vous de voir comment appliquer cela � votre cas.
Le premier outil indispensable, c'est shadow utils. C'est un moyen de crypter les mots de passe. Par chance, il fait maintenant partie int�grante de la plupart des Unixes. Le fichier /etc/shadow se "substitue" alors au fichier /etc/passwd.

Encore mieux, PAM (Pluggable Authentication Modules) permet de restreindre les acc�s aux utilisateurs par service. Tout se g�re dans le r�pertoire contenant les fichiers de configuration par service, g�n�ralement /etc/pam.d. De nombreux services peuvent �tre "pilot�s" par PAM tels que ftp, login, xdm, etc, permettant ainsi � l'administrateur de choisir qui a le droit de faire quoi.

L'outil suivant est incontournable sur un r�seau : TCPWrapper . Il fonctionne �galement sous toutes les moutures d'Unix ou presque. Pour faire court, il permet de restreindre l'acc�s aux services � certains h�tes. Ces h�tes sont accept�s ou rejet�s par l'interm�diaire de deux fichiers : /etc/hosts.allow et /etc/hosts.deny. TCPWrapper peut �tre configur� de deux mani�res diff�rentes : soit en d�pla�ant les d�mons, soit en modifiant le fichier /etc/inetd.conf. Nous verrons plus loin que TCPWrapper se marie � la perfection avec d'autres outils. Vous trouverez TCPWrapper sur ftp://ftp.porcupine.org/pub/security

Nous pouvons mentionner un autre outil int�ressant : xinetd. Encore une fois, pour faire court, xinetd est un remplacement de inetd en plus performant. Compte-tenu de ce qui a �t� dit sur inetd un peu plus haut, nous ne nous attarderons pas. S'il vous int�resse, vous le trouverez sur http://www.xinetd.org.

Sous Linux, il existe un outil incontournable, nomm� Bastille-Linux. Vous le trouverez sur http://www.bastille-linux.org.
Cet outil, �crit en perl a la particularit� d'�tre tr�s didactique en plus d'�tre tr�s efficace. Apr�s lancement d'un script, vous r�pondez � diff�rentes questions et Bastille-linux agit en cons�quence. Toutes les questions sont expliqu�es et des r�ponses par d�faut sont propos�es. Vous pouvez supprimer les modifications effectu�es, recommencer une nouvelle configuration, voir ce qui a �t� fait... Tout y est ! Il propose m�me de configurer un pare-feu : nous y reviendrons. Au moment d'�crire ces lignes, Bastille-linux est en version 1.1.1, mais la version 1.2.0 est d�j� disponible en "release candidate". Elle est encore am�lior�e, et propose m�me une interface graphique bas�e sur Tk et son module perl.
(NDA : cet article a �t� �crit plusieurs mois plus t�t. La version actuelle de Bastille-Linux est en r�alit� la 1.3.0).

Les outils de d�tection d'intrusion sont �galement indispensables. Les deux poids-lourds de la cat�gorie se nomment snort et portsentry. Le premier peut �tre t�l�charg� sur http://www.snort.org et le second � partir du site du projet Abacus, http://www.psionic.com.
L'approche de chacun des outils est diff�rente : le premier est un NIDS (Syst�me de D�tection d'Intrusion R�seau) qui repose surtout sur l'information, le second peut �tre consid�r� comme plus orient� machine et il est plus "actif". snort b�n�ficie d'un nombre incalculable d'options vous permettant de "surveiller" tout ce qui se passe sur le r�seau. Vous pouvez "�couter" tout ce que vous voulez : le trafic entrant, sortant, � l'int�rieur du pare-feu, � l'ext�rieur. Le revers de la m�daille : �a g�n�re des logs �normes, mais il faut savoir ce qu'on veut ! Il poss�de ausi une version Win 32, ce qui a son importance, vu le nombre de logiciels libres disponibles sur ces "syst�mes".

portsentry a une fonctionnalit� particuli�rement int�ressante : il peut bloquer les ports "scann�s", selon votre choix. Vous pouvez soit rediriger l'attaquant vers une adresse inutilis�e de votre r�seau, soit rediriger la route vers le pare-feu. Bien s�r, vous avez la possibilit� de choisir qui bloquer et qui ne pas bloquer. C'est l� que nous revenons � TCPWrapper : portsentry est capable d'�crire dans le fichier /etc/hosts.deny si vous le d�cidez. portsentry est donc particuli�rement efficace. Nous ne nous lancerons pas dans le d�bat sur la philosophie consistant � lier les ports � une application comme le fait portsentry. A vous de faire votre choix apr�s avoir approfondi le sujet. Sachez que porsentry peut rendre une machine "invisible" : ce n'est pas n�gligeable ! Derni�re pr�cision : portsentry a plusieurs modes de fonctionnement; le plus �labor� �tant r�serv� � Linux (pour l'instant).

Nous ne pouvons pas parler de s�curit�, sans aborder le cryptage. Celui-ci n'est toujours pas lib�ralis� et il est m�me encore totalement interdit dans certains pays.
Sachez qu'en France, la situation en vigueur date de 1999, c'est-�-dire "sous le r�gime 128 bits". Il se trouve que ssh utilise du 168 bits (avec 3DES), donc soumis � autorisation pr�alable. Ca signifie que si vous utilisez OpenSSL (256 bits) ou OpenSSH tels quels, vous �tes dans l'ill�galit�... c'est toujours bon � savoir !
La lib�ralisation est bien pr�vue... mais il faudra attendre encore un peu (de nouvelles �lections pour que la loi sur la soci�t� de l'information soit vot�e).
Merci � Bernard Perrot pour avoir "�clair� mes lanternes".
Pour ceux qui l'ignore, Bernard Perrot est la personne � qui nous devons de pouvoir utiliser l�galement ssh en France. Sa version de ssh, nomm�e ssf, est la seule prenant en charge la d�claration d'utilisation et l'autorisation qui en d�coule... et qui est obligatoire dans notre pays.
Vous trouverez ssf � http://ww2.lal.in2p3.fr/~perrot/ssf/. Si vous souhaitez rester dans la l�galit�, sans tracasserie administrative, c'est la version qu'il vous faut. Cela dit, c'est comme vous le sentez, mais vous devrez en assumer le risque.
Conclusion : installez serveur et client ssf sur vos machines Unix.

Pour en terminer avec les outils Unix, mentionnons ceux qui sont sp�cifiques � certains Unixes propri�taires. Pour Solaris, vous disposez de ndd, de aset; pour Irix, vous pouvez utiliser ipfilterd. Mac OS X fournit en standard certains outils issues de la communaut� du logiciel libre : ssh, ipfwadm...
Nous y reviendrons plus loin.

Passons maintenant au seul et unique (heureusement !) Non Termin� 4.0.
L�, nous ne pouvons pas vraiment parler d'outils libres... mais PetitMou nous fournit de quoi am�liorer les fonctionnalit�s du syst�me gratuitement (et non pas de quoi corriger les bogues, puisqu'il n'y en a pas !). Question s�curit�, NT 4.0 est un mod�le... d'incongruit�. Plus gruy�re, on peut se demander si c'est possible : �a fait peur ! Glissons. Donc, pour NT 4.0, il existe plusieurs solutions. Soit, vous �tes courageux et vous t�l�chargez le dernier Service Pack (le 6 au moment de cet article) ou vous t�l�chargez les HotFixes qui sont des patches de s�curit�. Ensuite... Il existe quelques outils libres (dans le sens de gratuits, et sans les sources !) mais r�serv�s aux versions anglaises. Voil�, c'est tout.

Pour les autres syst�mes, il faudra chercher. A la d�charge d'AmigaOS, le d�veloppement n'int�resse plus grand monde et la couche TCP/IP date un peu. Cela dit le Domaine Public contient toujours de quoi vous occuper. Pour BeOS, ce n'est gu�re mieux : ce fabuleux OS semble avoir un avenir compromis et sa couche r�seau nomm�e Bone n'est toujours pas finie.
(NDA : malheureusement, depuis, BeOS est mort. Un petit groupe essaie de le garder "vivant" en tant que produit libre... et il fait un tr�s beau travail.)
Mais l�-aussi, vous trouverez des outils issues du monde Unix pour am�liorer les choses.

La s�curisation des h�tes

Maintenant, il va falloir configurer tout �a !
Une fois de plus, consid�rons que toutes les machines Unix sont "�quip�es" des shadow-utils, de PAM, de TCPWrapper et que tous les services inutiles sont d�sactiv�s ou supprim�s, que les permissions sont suffisamment restrictives sur les r�pertoires "d�licats", etc.

Sur les machines Linux, c'est le moment de lancer Bastille-Linux. (Cet outil devrait fonctionner avec la plupart des distributions Linux, mais il a �t� con�u � l'origine pour RedHat et Mandrake). N'h�sitez pas � r�pondre aux questions du script de mani�re tr�s restrictive.
Sur la machine Linux servant de passerelle, il faut que le syst�me soit minimaliste. Vous pouvez supprimer la plupart des serveurs : http, ftp, etc. Retirez X11 : vous n'en avez aucun besoin ! Enlevez tous les logiciels qui ne seront jamais utilis�s... c'est-�-dire, presque tous. Arr�tez les d�mons inutiles. Vous devez vous retrouver avec un syst�me sur lequel l'�cran de la console ne sera m�me pas rempli apr�s une commande ps ax.
Si vous utilisez le masquage IP, la commande lsof -i devrait afficher une seule ligne : celle du serveur � l'�coute (nous supposons qu'il ne s'agit pas d'une connexion permanente).
Arbitrairement, nous installerons portsentry sur ces machines Linux et il sera lanc� au d�marrage, bien �videmment, en mode "stealth" (le mode avanc� r�serv� � Linux, soit les options -atcp et -audp). Cela suppose qu'un pare-feu soit install�, ainsi que TCPWrapper, nous y reviendrons.

Pour Solaris, nous utiliserons les commandes aset et ndd. Nous en reparlerons �galement. portsentry sera aussi install�. Nous pourrions ajouter IP Filter et remplacer la version standard de RPCBIND par la version 2.1 disponible sur porcupine.org.
Pour Irix, nous choisirons ipfilterd pour filtrer les paquets, comme son nom l'indique. Il existe en standard dans les distributions Irix, mais il n'est pas install� par d�faut.

Concernant NT, �a se complique... La solution "fasciste" consiste � bloquer les ports 137 et 139, � savoir le fameux NetBIOS (ou encore mieux supprimer NetBIOS)... mais vous n'avez plus de r�seau (c'est-�-dire de r�seau Windos), ce qui est g�nant pour un serveur d'applications ! Vous pouvez aussi installer snort, mais �a n'emp�chera pas les machines en question d'�tre des passoires. En cons�quence, � part limiter au maximum les permissions par partition, par r�pertoires... � condition de travailler en NTFS, of course, il y a peu de possibilit�s. Il existe un programme gratuit, susceptible de supprimer l'utilisateur "invit�", mais il ne fonctionne que pour les versions anglaises... et bien s�r les sources ne sont pas disponibles. Moralit� : installez tous les patches de s�curit� que vous pouvez trouver ! Enfin, et surtout, prenez-vous par la main pour essayer de rendre ce machin moins vuln�rable. Ca vaut le parcours du combattant, mais c'est indispensable.

Pour les OS "exotiques", ce sera � vous de chercher et de choisir. Comme toujours, avant toute autre chose, la r�gle de base devra �tre appliqu�e : moins il y aura de services actifs, mieux ce sera.

Protection du r�seau

Si les h�tes ont �t� bien "pr�par�s", vous avez fait la plus grosse partie du chemin. Il faut malgr� tout aller un peu plus loin.
Puisque nous sommes dans le logiciel libre, nous allons choisir un pare-feu libre, pour la passerelle, puisque c'est la machine qui vous permet d'acc�der au monde ext�rieur. Nous avons arbitrairement choisi une machine Linux : nous pouvons donc utiliser le pare-feu propos� par Bastille-Linux. Celui-ci fait appel � ipchains ou ipfwadm selon votre version de noyau. Ce sera encore diff�rent si vous �tes d�j� au noyau 2.4.

Une petite parenth�se : ce n'est jamais une bonne id�e "d'essuyer les pl�tres" lorsqu'il s'agit de s�curit�. La course � la derni�re version du noyau risque de mener � une situation plus n�gative qu'autre chose. Je ne mets pas en cause la qualit� des travaux effectu�s sur les nouveaux noyaux, mais leur "mariage" avec des outils existants qui n'ont pas �t� pr�vus pour fonctionner de cette mani�re. Petit conseil : patience ! La nouvelle "formule" de pare-feu int�gr�e au noyau 2.4 est certes prometteuse mais sans doute pr�matur�e par rapport � ce qui l'entoure. Cela dit, faites comme vous le sentez...

Donc, le pare-feu propos� par Bastille-Linux est � la fois simple et efficace. Toutefois, il existe un outil beaucoup plus �labor�, m�me un petit peu "usine � gaz" sur les bords, il s'agit de T.REX disponible sur http://www.opensourcefirewall.com. Si vous recherchez un outil libre tr�s sophistiqu�, le voici.

Il existe d'autres solutions telles que les proxys, mais elles ne sont pas forc�ment meilleures. Une petite parenth�se : les proxys sont souvent appel�s "firewalls". Ce sont pourtant deux choses diff�rentes. Les "firewalls" dont nous parlons fonctionnent par filtrage de paquets et n'offrent pas de moyens d'authentification. Les serveurs proxy sont de deux types : application ou socks. En bref, un proxy application, fait le travail pour vous en g�rant les communications et permet l'authentification des utilisateurs. Pour cette raison, il est plus gourmand qu'un pare-feu en terme de ressources.
R�p�tons inlassablement, que ce genre d'outil ne peut prot�ger "efficacement" que sur un laps de temps relativement court. Un pare-feu peut �tre "craqu�" en une quinzaine de minutes. C'est toujours bon � savoir, n'est-il pas ? D'o� l'int�r�t de bien s�curiser les h�tes composant le r�seau : baser la s�curit� d'un r�seau uniquement sur un pare-feu ou un proxy est une h�r�sie !

Autre moyen de "limiter les d�g�ts" sur le r�seau : le cryptage. Utiliser telnet, par exemple, consiste � faire marcher les "pirates" sur un tapis rouge. Ca sert � leur fournir les cl�s du magasin. Non seulement, ils peuvent voir tout ce qui circule mais surtout, ils b�n�ficient du mot de passe en clair : sympathique, non ?
En cons�quence, n'h�sitez pas � utiliser ssh (ssf) � outrance avec les protocoles "douteux" (ou � la place). Si vous devez imp�rativement utiliser telnet, faites circuler les donn�es par un canal s�curis�. En clair, redirigez le port telnet vers un port s�curis�. Pour plus ample explication, lisez l'article Par le tunnel ( www.linuxfocus.org/Francais/May2001/article202.shtml). (Publicit� gratuite !)

Alors, c'est bien joli de tenter de s�curiser, mais encore faut-il v�rifier l'efficacit� du travail r�alis�. Pour cela, nous allons nous transformer en "pirates" de pacotille : nous allons utiliser leurs outils. C'est laid, hein ?
Dans ce domaine, il existe aussi une belle collection de programmes, aussi nous allons, encore arbitrairement, en choisir deux : nmap et nessus. Il n'y a pas redondance, dans la mesure, o�, par exemple, le second a besoin du premier. Ces outils sont des scanners de ports, m�me si nessus va plus loin. Celui-ci vous informe des vuln�rabilit�s d'un syst�me en comparant les r�sultats obtenus pendant le scan � sa base de donn�es de vuln�rabilit�s. Lancer ces outils sur une machine de votre r�seau vous permettra de d�couvrir les vuln�rabilit�s de chaque h�te le composant, quel que soit l'OS concern�. Le r�sultat est tr�s r�v�lateur et suffit � rendre ces outils indispensables. Vous trouverez nmap sur http://www.insecure.org et nessus sur http://www.nessus.org.

Nous parlons depuis le d�but de la s�curisation d'un r�seau local dont certaines machines sont ouvertes au monde ext�rieur. Le cas du r�seau d'un prestataire de services Internet sera bien s�r diff�rent et nous n'aborderons pas le sujet en d�tail. Disons simplement que tout ce qui pr�c�de reste valable mais qu'en plus il faut utiliser des m�thodes beaucoup plus �labor�es, telles que les VPN (Virtual Private Network), LDAP pour l'authentification (par exemple), etc. C'est presque un autre sujet puisque les contraintes sont encore plus nombreuses selon le cas. Ne parlons surtout pas des sites de commerce en ligne, o� l�, �a rel�ve de l'inconscience. Sites s�curis�s qu'ils disent ! Ben voyons... Vous envoyez votre num�ro de carte de cr�dit sur Internet vous ? Si oui, vous �tes plut�t courageux. Suggestion : allez faire un tour sur le site http://www.kitetoa.com, �a vaut son pesant de cacahu�tes.

Particularit�s des syst�mes

Comme nous l'avons d�j� mentionn�, les syst�mes ne sont pas �gaux face � l'adversit�. Certains ont de tr�s bonnes dispositions, d'autres sont de v�ritables gruy�res. Paradoxalement (quoi que !), les OS dits libres sont au-dessus du lot. Les diff�rents BSD (OpenBSD, NetBSD, FreeBSD...), les diff�rents Linux disposent d'atouts s�rieux lorsqu'il s'agit de s�curit�. R�p�tons-le, c'est le r�sultat de l'extraordinaire travail de la communaut� du logiciel libre. Tous les autres, m�me estampill�s Unix, sont un ton au-dessous. Lorsqu'ils ne sont pas Unix, c'est largement pire !

Tous les outils cit�s dans cet article ont �t� d�velopp�s pour les syst�mes libres. Les syst�mes Unix propri�taires peuvent dans la plupart des cas en b�n�ficier. Toutefois, ces OS propri�taires poss�dent souvent leur propre panoplie.
Par exemple, pour Solaris, nous avons cit� ndd et aset. Contrairement � une id�e re�ue, les syst�mes de Sun ne sont pas des mod�les de s�curit�. Un outil comme aset, permet d'am�liorer un peu les choses pour ce qui concerne les droits d'acc�s. aset propose trois niveaux de protection : bas, moyen et �lev�. Vous pouvez le lancer par une commande shell ou par cron. Sur un r�seau, ce qui est vrai � 17 heures, ne l'est peut-�tre plus � 17 heures 30. D'o� l'int�r�t de lancer des commandes de mani�re cyclique pour garantir une certaine homog�n�it�. C'est pour cela qu'aset peut �tre g�r� par cron. Ainsi il v�rifiera toutes les 30 minutes ou toutes les heures, ou ce que vous voulez, l'�tat des permissions des r�pertoires, des fichiers...
Pour sa part, ndd permet de modifier les param�tres de la pile. Cela permet par exemple de cacher les empreintes du syst�me. Un syst�me identifi� est un syst�me plus vuln�rable, puisque les "crackers" savent mieux o� "taper". Gr�ce � ndd, vous pouvez modifier la taille maximum des segments TCP (MSS). Par d�faut, cette taille est � 536 sous Solaris 2.6. La commande ndd -set /dev/tcp tcp_mss_def 546 la fait passer � 546. Plus ce MSS est �lev�, mieux c'est (pas trop quand m�me !). nmap, par exemple, est capable d'exploiter cette faiblesse. En utilisant ndd, vous lui coupez l'herbe sous les pieds. Si vous avez des machines sous Solaris, n'h�sitez donc pas : servez-vous de ndd. Vous disposez d'innombrables possibilit�s : voir la page de manuel.
Vous pouvez �galement utiliser IP Filter, un syst�me de filtrage de paquets. Il est disponible sur ftp://coombs.anu.edu/pub/net/ip-filter.

Pour ce qui est d'Irix, c'est encore autre chose. A la d�charge de SGI (ex Silicon Graphics), comme son nom l'indique, son syt�me a �t� pr�vu pour le graphisme. La s�curit�, ce n'�tait pas vraiment la pr�occupation majeure. N�cessit� faisant loi, il a bien fallu proposer des moyens de limiter les risques. ipfilterd a donc �t� propos� dans Irix, m�me s'il n'est pas install� par d�faut : il faudra donc aller le chercher ! ipfilterd sert bien s�r � filtrer les paquets, permettant ainsi de refuser l'acc�s � qui vous le souhaitez. Il repose sur un fichier de configuration nomm� ipfilterd.conf, et c'est l� que �a se complique. La syntaxe de ce fichier est pour le moins particuli�re et surtout elle ne supporte pas les espaces inattendus ou les lignes vides. Ainsi, pour permettre � la machine "mars" de causer � la machine "jupiter" qui n'est autre que la station SGI, il faudra taper une ligne du style : accept -i ec0 between jupiter mars. Les machines ne figurant pas dans ce fichier ne pourront pas acc�der � jupiter (et donc encore moins � sa cuisine). Encore pire : si vous ne modifiez pas le param�tre ipfilterd_inactive_behavior par systune, plus personne n'aura acc�s � la machine ! Ca c'est de l'efficacit� ! Donc, par d�faut ce param�tre est � 1, et il faudra le mettre � 0 par la commande systune -i ipfilterd_inactive_behavior 0.
Autre chose bien connue, mais qu'il faut peut-�tre rappeler, Irix poss�de une vuln�rabilit� de choc, nomm�e fam (File Alteration Monitor). Ce programme sert � rendre Irix tr�s agr�able en permettant la communication entre diff�rents d�mons. C'est lui par exemple qui permet d'obtenir des ic�nes d'enfer dans le gestionnaire de fichiers. Pourtant, il n'y a qu'une chose � faire : le d�sactiver ! Dommage, mais c'est ainsi.

Pour en terminer avec les syst�mes Unix, signalons que QNX est extr�mement vuln�rable mais qu'il peut bien s�r b�n�ficier des outils libres. Mac OS X profite d�j� de certains de ces outils.

Il faut quand m�me parler un peu du syst�me r�seau par excellence : the one and lonely NT 4.0. S�curiser ce machin rel�ve de l'utopie quoiqu'en dise PetitMou (et plein d'autres). Si vous simulez une attaque avec nessus par exemple, vous allez en avoir des cauchemars. Tant que NetBIOS est actif, nessus vous donne les noms de toutes les machines constituant le domaine et des utilisateurs qui vont avec, administrateurs compris. Moralit� : supprimez NetBIOS ! Oui, mais comme d�j� mentionn�, si plus NetBIOS, plus r�seau... Il faut choisir son camp. nessus vous informera aimablement qu'il peut aussi se loger par l'interm�diaire de l'utilisateur invit� par une session NULL (soit avec un nom d'utilisateur NULL et un mot de passe NULL). Donc, supprimez-le ! Oui, mais comment ? Et c'est tout comme �a ! En conclusion, prenez-vous par la main et limitez les acc�s au maximum par partition (NTFS), par r�pertoire. Pour les partitions FAT... pas de solution. Toutefois, selon les logiciels utilis�s vous pouvez �tre oblig�s d'en avoir des partitions FAT : il y en a plein des logiciels qui ne fonctionnent pas sous NTFS. Pour en finir, �vitez l'in�narrable IIS, surtout comme serveur ftp. En fait, ne l'installez pas. S'il existe aujourd'hui tant de prestataires suffisamment inconscients pour utiliser ce truc, nous ne pouvons que leur conseiller de passer � Apache, mais bon... Ne nous attardons pas sur IIS, la litt�rature sur ses "tares" est suffisamment dense, n'en rajoutons pas. En r�alit�, il existe une marche � suivre pour transformer la passoire en filtre (les trous sont plus petits !). Le probl�me c'est qu'elle est plut�t du style "longue marche" et le magazine entier n'y suffirait pas. Concentrons-nous sur l'essentiel. Bien �videmment, il ne s'agit plus de s�curiser avec du logiciel libre : il s'agit du monde M$ !
La premi�re suggestion serait d'utiliser MSCE (Microsoft Security Configuration Editor) disponible sur le ServicePack 4 avec MMC (M$ MAnagement Console). Par contre, si c'est votre choix, prudence ! Avec cet outil si vous vous "loupez", c'est la catastrophe garantie. De plus il est en version anglaise, et le m�lange des "langues" n'a jamais franchement donn� de bons r�sultats dans le monde de Redmond. Vous voil� pr�venus.
Ensuite, parmi les diff�rentes mesures indispensables, vous devez "s�curiser" le compte administrateur, voire le d�sactiver. Penchez-vous sur passprop disponible � partir du SP 3. Vous pouvez aussi renforcer les mots de passe avec la dll passfilt par l'interm�diaire de la base des registres (j'ai toujours pens� que les individus qui avaient invent� ce truc �taient sous l'influence de champignons hallucinog�nes, mais bon...). D�sactivez le fameux invit�. Ca ne sert pas � grand chose (voir plus haut), mais c'est moins pire. Par contre, vous pouvez restreindre son acc�s aux logs par la base des registres. Dans "HKEY_LOCAL_MACHINE", cr�ez les cl�s System\CurrentControlSet\Services\EventLog\Application, Security et System (ces deux derniers � la place d'Application). Leur nom c'est "RestrictGuestAccess", le type REG_SZ et la valeur 1.
Vous pouvez crypter les mots de passe avec syskey. Attention, c'est une op�ration irr�versible !
Quand m�me, une bonne nouvelle : vous pouvez restreindre l'acc�s au fameux invit�. Encore une fois, jouons avec la base des registres, toujours dans "HKEY_LOCAL_MACHINE". Cette fois, la cl� se nomme System\CurrentControlSet\Control\Lsa. Le nom de la valeur est "RestrictAnonymous", le type "REG_DWORD" et la valeur 1. Mais le monde M$ est tr�s taquin : sachez que cette modification peut alt�rer certains services r�seau...
Parmi les choses importantes, vous pouvez �galement ne permettre l'acc�s qu'� certains ports, par l'interm�diaire de l'application "R�seau" dans le panneau de configuration. Dans les propri�t�s TCP/IP, s�lectionnez "Avanc�" et cochez la case "activer s�curit�" (je crois que �a s'appelle comme �a, mais je n'ai pas ce genre de truc chez moi pour v�rifier). Dans la fen�tre "S�curit�", cochez "permettre seulement" et choisissez les ports que vous souhaitez activer. L�-aussi, prudence. Il vaut mieux savoir ce que vous faites, sinon, certains services ne fonctionneront plus.
Beaucoup d'autres choses sont envisageables, mais disons qu'il s'agit de l'essentiel. Pour en savoir plus, visitez sans.org : une grande quantit� de documents y est disponible.

L'insoutenable relativit� des choses

Bon, vous avez fait tout �a. Vous lancez nessus pour scanner le r�seau entier et vous vous retrouvez encore avec des trous de s�curit�. Nous ne dirons pas d'o� ils viennent... on le sait d�j� ! Il ne vous reste plus qu'� essayer de leurrer ces succ�dan�s de syst�mes. Ca ne supprimera pas les trous d�s � NetBIOS, mais �a limitera les d�g�ts. Cr�ez des sous-domaines. Ne vous logez pas en tant qu'administrateur. Patchez comme des b�tes. Enfin, essayez de cacher tout �a derri�re des machines Unix transform�es en passerelles. Malheureusement, la relativit� de la s�curit� ne vient pas que des produits con�us "in Redmond". Un r�seau, c'est vivant : il s'y passe plein de choses. Partant donc du principe qu'un bon administrateur est un administrateur "parano", v�rifiez de mani�re quasi permanente l'�tat des lieux. Ecrivez des scripts pour automatiser toutes ces v�rifications. Par exemple pour contr�ler r�guli�rement les programmes SUID/SGID root, les fichiers critiques, les logs...
Histoire de se faire quelques amis suppl�mentaires, verrouillez les lecteurs des utilisateurs (disquettes, CD-Rom). Interdisez les t�l�chargements sans votre aval, surtout lorsqu'il s'agit d'ex�cutables comme c'est toujours le cas dans le monde M$. Interdisez l'ouverture des documents joints au format Word, Excel... par l'interm�diaire de filtrage de courrier.
Oui, c'est facho, mais on fait quoi contre les virus macro ? N'utilisez pas des produits comme Outlook. Encore une fois, il faut savoir ce qu'on veut ! Je suis tr�s conscient de me battre contre les moulins � vent, mais on ne peut plus parler de s�curit� avec des produits semblables. Le fameux "I love you" n'a servi � rien, et surtout pas de le�on.
Pour ce qui concerne Unix, les t�l�chargements doivent aussi �tre contr�l�s. Les checksums et autres cl�s n'ont pas �t� mis l� par hasard.

Prenez l'habitude de contr�ler r�guli�rement l'�tat du r�seau par l'interm�diaire des logs, de scripts, de scans... Vous verrez : �a change vite et pas forc�ment dans le bon sens. Enfin, nous n'en avons pas parl�, mais n'oubliez pas les sauvegardes. La strat�gie est immuable : quotidienne, hebdomadaire et mensuelle. M�me une machine Unix peut rencontrer des soucis, m�me si c'est tr�s rare. Et puis, les utilisateurs font parfois quelques erreurs... mais c'est rare. C'est la faute � la machine ou � l'informatique, c'est bien connu.

C'est enfin termin� !

Si vous �tes arriv�s jusque l�, c'est que vous �tes tr�s courageux. Le probl�me, c'est que nous n'avons fait que survoler le sujet !
La s�curit� est un domaine sans fin et elle ne concerne pas que les r�seaux. Des applications vuln�rables peuvent gravement compromettre un r�seau. Un pare-feu mal param�tr� est plus dangereux que pas de pare-feu du tout. Une machine Unix contient souvent des dizaines de milliers de fichiers. Qui peut affirmer qu'aucun d'entre eux n'est vuln�rable ? Qui pense qu'un "cracker" va essayer de casser une cl� de 128 bits ? Que nenni : il choisira une porte d�rob�e. Encore et encore, vous pouvez installer tous les outils de s�curit� de la cr�ation, si vous laissez un petit trou c'est par l� que passera l'ind�sirable.

La s�curit� est aussi un comportement : il faut suivre de tr�s pr�s ce qui se passe. Visitez par exemple r�guli�rement les sites consacr�s � la s�curit�, les sites de vos diff�rents OS... Sun, par exemple publie des patches recommand�s tous les mois. SGI sort une nouvelle version d'Irix environ tous les six mois. Microsoft propose des ServicePacks ou des patches de s�curit� fr�quemment. Les distributeurs de Linux publient des correctifs pour chaque nouvelle vuln�rabilit�. M�me chose pour ce qui concerne les diff�rents BSD.
Si vous n'utilisez pas les produits concern�s par les correctifs retirez-les de votre disque. Et ainsi de suite : la liste des choses � faire est tr�s longue. En clair, la corporation ne risque pas le ch�mage technique.

Enfin, r�p�tons-le, tout ce qui pr�c�de ne contribuera qu'� rendre votre r�seau moins vuln�rable. N'imaginez pas que vous pourrez obtenir un r�seau s�r � 100%, m�me � un moment donn� (sauf quand toutes les machines sont arr�t�es). Cela dit, il n'est pas n�cessaire d'�tre "parano" pour faire ce m�tier... mais �a aide ! Reste � ne pas l'�tre dans la vie, ce sera beaucoup plus agr�able pour votre entourage...

R�f�rences

http://www.linuxsecurity.com

http://www.sans.org

http://www.infosyssec.org

http://www.securityfocus.com

http://www.cs.purdue.edu/coast/hotlist/

La vie est trop triste : rions un peu !

Incontournable ! La vie quotidienne d'un sysadmin...

Si vous causez la langue de Shakespeare D�lirant, mais hilarant (de la Baltique)