original in fr Georges Tarbouriech
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�.
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.
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 !
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.
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
!).
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.
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.
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.
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.
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.
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.
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.
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)