next up previous contents Next:  Eliminer les risques potentiels: Up: Contre-mesures. Previous:  Empêcher les services non-sécurisés   Table des matières  

45.3.6  Eliminer les risques potentiels: le réseau.

Installons libsafe. Il s'agit d'une bibliothèque qui interface toutes les fonctions C connues pour être vulnérables, ce qui permet de tester les dépassements de tampon lors de chacun de leurs appels. Ensuite, envoyez un courriel à l'administrateur lors des tentatives d'attaques. Rendez-vous à l'adresse http://www.research.avayalabs.com/project/libsafe/ pour davantage d'information, ou envoyez un courriel à libsafe@research.avayalabs.com. La bibliothèque libsafe résoud environ 90% des problèmes de dépassement de tampon. Il y a une très légère perte de performances, cependant.

Désactivez tous les services en cours qui ne s'avèrent pas utiles. Ensuite, essayez d'évaluer si les services restants sont absolument nécessaires. Par exemple, avez-vous besoin d'IMAP ou POP3 suffit-il? IMAP a eu bien davantage d'alertes de sécurtié que POP3, car il s'agit d'un programme plus complexe. Est-il utile de courir le risque de l'employer?

xinetd (ou inetd) exécutent de nombreux services, dont seule une partie est réellement nécessaire. Vous devrez donc révisiter /etc/xinetd.d (ou /etc/inetd.conf) pour y laisser un minimum de services. Concernant xinetd, vous pouvez ajouter la ligne disable = yes dans le (ou les) fichier(s) adéquat(s). Il ne devrait rester que quelques fichiers fonctionnels. /etc/inetd.conf , quant à lui, ne devrait contenir qu'un minimum de lignes. Voici un exemple réel:

ftp     stream  tcp   nowait  root    /usr/sbin/tcpd in.ftpd -l -a 
pop-3   stream  tcp   nowait  root    /usr/sbin/tcpd ipop3d 
imap    stream  tcp   nowait  root    /usr/sbin/tcpd imapd 


Ce conseil devrait être pris au pied de la lettre. Le principe de base est que si vous ne savez pas le rôle joué par un service, vous devez désactiver ce dernier. Voir aussi la section 30.6.

Dans le cas cité dans l'encadré (et qui est un cas réel), les services ont été restreints afin de n'autoriser que certains réseaux à se connecter (voir les sections 30.2.3 et 30.5.1).

xinetd (ou inetd) ne constitue pas le seul problème. Il y a de nombreux autres services, sources de problèmes potentiels. Si vous saisissez la commande netstat -npl vous obtiendrez quelque chose comme ceci:

(Not all processes could be identified, non-owned process info 
will not be shown, you would have to be root to see it all.) 
Active Internet connections (only servers) 
Proto Recv-Q Send-Q Local Address    Foreign Adress  State PID/Program name 
tcp      0      0  0.0.0.0:25         0.0.0.0:*       LISTEN 2043/exim 
tcp      O      0  0.0.0.0:400        0.0.0.0:*       LISTEN 32582/xinetd 
tcp      0      0  0.0.0.0:21         0.0.0.0:*       LISTEN 32582/xinetd 
tcp      0      0  172.23.80.52:53    0.0.0.0:*       LISTEN 30604/named 
tcp      0      0  127.0.0.1:53       0.0.0.0:*       LISTEN 30604/named 
tcp      0      0  0.0.0.0:6000       0.0.0.0:*       LISTEN 583/X 
tcp      0      0  0.0.0.0:515        0.0.0.0:*       LISTEN 446/ 
tcp      0      0  0.0.0.0:22         0.0.0.0:*       LISTEN 424/sshd 
ucp      0      0  0.0.0.0:1045       0.0.0.0:*              30604/named 
ucp      0      0  172.23.80.52:53    0.0.0.0:*              30604/named 
ucp      0      0  127.0.0.1:53       0.0.0.0:*              30604/named 
raw      0      0  0.0.0.0:1          0.0.0.0:*              - 
raw      0      0  0.0.0.0:6          0.0.0.0:*              - 


Cependant, cela ne vous indique pas que le PID 446 correspond à lpd. Pour obtenir cette information, tapez ls -al /proc/446/.

Du tableau, vous pouvez déduire que sont ouverts les ports 1, 6, 21, 22, 25, 53, 400, 515, 1045 et 6000. Les ports de 1 à 6 sont des ports du noyau, 21 et 400 correspondent, respectivement, à FTP et à notre démon echo (voir la sous-section 45.1.1). Le grand nombre de ports ainsi laissés actifs prêtent le flanc à une attaque.

A ce stade, vous devriez vérifier chaque service pour:

  1. décider de sa nécessité,
  2. vous assurez que vous disposez de la dernière version du paquet,
  3. et enfin, consultez la documentation des paquets de manière à restreindre l'accès à vos ports pour certains réseaux qui seront autorisés à s'y connecter.
Il est intéressant de noter que beaucoup de personnes se livrent à des supputations du genre: ``Ce service est si populaire qu'il est difficile d'imaginer qu'il soit vulnérable''. C'est exactement l'inverse. Lorsqu'un paquet est ésotérique ou peu utilisé, il est bien plus probable que personne ne se soit attaché à en trouver une vulnérabilité. Dans le cas de named (c'est-à-dire bind), de nombreuses failles ont été rendues publiques notamment pour ce qui concerne les versions antérieurs à 9. Donc, la mise-à-jour vers la dernière version (9.2.2, au moment de la traduction) est un acte de prudence essentiel à adopter pour toutes les machines que vous administrez.


next up previous contents Next:  Eliminer les risques potentiels: Up: Contre-mesures. Previous:  Empêcher les services non-sécurisés   Table des matières  
1-01-2006