Journal Firewall et RPC

Posté par  .
Étiquettes : aucune
0
15
oct.
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.
  • # Re: Firewall et RPC

    Posté par  . É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  . É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  . É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  (site web personnel) . É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.

Suivre le flux des commentaires

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