Derniers journaux de skc :
- [22/06@19:42] Radio france semble avoir rebooté le serveur Ogg
- [12/06@07:23] Vol de matériel informatique a Annecy
- [25/02@10:05] Mozilla et JavaScript
Journal : Firewall et RPC
Posté par Sébastien Koechlin () le 15 octobre 2003Sun 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).
Re: Firewall et RPC
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
[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.

Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser 

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.