Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

Derniers journaux de skc :

Journal : Firewall et RPC

Posté par Sébastien Koechlin () le 15 octobre 2003
Le noyau Linux offre depuis la nuit des temps des fonctions de filtrage IP de plus en plus évoluées à chaque nouvelle version majeur [1]. On peut facilement demander que toutes les requêtes TCP vers le port 5432 qui arrivent depuis ppp0 soient purement et simplement envoyé à la trappe [2].

Sun a développé sur IP un mécanisme normalisé de RPC qui se base sur portmap [3], les services s'installent sur un port UDP ou TCP quelconque et s'inscrivent auprès du portmap.

Le port du démon portmap est fixe, on peut le filtrer, mais les services qui s'enregistrent peuvent tourner sur n'importe quel port. Comment faire pour les filtrer [4] ?

Les versions modernes viennent avec les tcp_wrapper, mais :
1- ils agissent à un niveau très élevé, on ne bloque pas au niveau IP
2- je ne sais pas si cette protection s'applique à tous les services, ou simplement au démon portmap
3- la granularité du tcp_wrapper est très grosse, pour une machine donnée, soit on autorise les RPC, soit on les interdit.

La question est donc: comment fait-on pour sécuriser tout ça ?


---


[1] Au passage, on peut même modifier le port au vol et rediriger par exemple les requêtes destinées au port 53 (DNS) vers un port non privilégié (comme le 1053), ça permet de faire tourner un serveur sans avoir à le lancer sous root, réduisant parfois les risques en cas d'intrusion.

[2] Cela évite, si on est connecté à internet via cette interface, que n'importe qui puisse venir tenter des connexions sur sa base PostgreSQL. C'est très pratique lorsque les logiciels sont un peu sensibles au buffer overflow ou s'ils ne sont pas paramétrables pour filtrer l'origine des connexions.

[3] Le portmapper est en quelque sorte un annuaire des RPCs qui sont disponibles sur une machine.

[4] En faisant un rpcinfo -p on peut voir par exemple:
programme : 100005
version : 3
protocole : tcp
port : 2049
serveur: mountd
ce qui signifit que sur le port 2049 en TCP, il y a un serveur qui réponds (mountd version 3), et rien n'interdit quelqu'un de se connecter dessus pour tenter de lui faire faire quelque-chose.

> Lire le journal (4 commentaires, moyenne: 1).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Re: Firewall et RPC

Posté par olivp () le 15/10/2003 à 13:23. (lien). Évalué à 1.

Si je me souviens, la sécurisation c'est :

man hosts.allow
man hosts.deny

et tu peux filtrer en fonction des adresses ip distantes ou des services....

  • [^]Re: Firewall et RPC

    Posté par Sébastien Koechlin () le 15/10/2003 à 13:52. (lien). Évalué à 1.

    Ce sont les deux fichiers de configuration du tcp_wrapper, le problème est que malgré ces deux fichiers, les services sont bindé sur des ports, et on peut se connecter sur ces ports depuis n'importe où rien qu'en faisant un telnet ou en contournant le démon portmap.

Re: Firewall et RPC

Posté par _seb_ () le 15/10/2003 à 13:23. (lien). Évalué à 1.

[4]
Ca ressemble pas mal à du NFS. Le serveur NFS utilise les fichiers /etc/hosts.allow et /etc/hosts.deny pour déterminer si l'accès via NFS d'un hôte donné doit être autorisé ou refusé. C'est déjà ça pris.

  • [^]Re: Firewall et RPC

    Posté par Toufou (page perso, ) le 16/10/2003 à 14:14. (lien). Évalué à 1.

    Le serveur NFS utilise les fichiers /etc/hosts.allow et /etc/hosts.deny
    Ca m'interresse mais je n'ai pas ça dans mon man, quelle version de nfsd utilises tu ?

    Pour ce qui est de rpc.mountd (celui de la slack 9.1: kmountd nfs-utils 1.0.6 ), lui il prend bien les fichiers du tcp wrapper d'après son man. Pareil pour le rpc.rquotad.

Revenir en haut de page