xinetd, msec, tcpwrappers et compagnie

xinetd, msec, tcpwrappers et compagnie - Codes et scripts - Linux et OS Alternatifs

Marsh Posté le 27-07-2002 à 22:27:34    

Bon j'ai besoin d'une petite mise au point sur tous ces outils.
J'ai compris que xinetd remplaçait inetd. Mais a-t-il besoin de tcpwrappers pour utiliser les fonctions de limitation d'acès? Xinetd utilise-t-il les fichiers hosts.allow et hosts.deny ou les fichiers de configuration dans /etc/xinetd suffisent?
 
Et msec (outils de sécurité fournit avec Mandrake)? Pour moi il est basé sur tcpwrappers. Utilise-t-il xinetd et ses propres fonctions?
 
Y-a-t-il interet à mettre tous les services sous controle de xinetd? Si non pourquoi? Est-ce possible d'ailleurs
 
Beaucoup de questions mais chacun de vous pourra sûrement apporter sa pierre à l'édifice  :D

Reply

Marsh Posté le 27-07-2002 à 22:27:34   

Reply

Marsh Posté le 27-07-2002 à 22:38:43    

bobor a écrit a écrit :

Bon j'ai besoin d'une petite mise au point sur tous ces outils.
J'ai compris que xinetd remplaçait inetd. Mais a-t-il besoin de tcpwrappers pour utiliser les fonctions de limitation d'acès? Xinetd utilise-t-il les fichiers hosts.allow et hosts.deny ou les fichiers de configuration dans /etc/xinetd suffisent?
 
Et msec (outils de sécurité fournit avec Mandrake)? Pour moi il est basé sur tcpwrappers. Utilise-t-il xinetd et ses propres fonctions?
 
Y-a-t-il interet à mettre tous les services sous controle de xinetd? Si non pourquoi? Est-ce possible d'ailleurs
 
Beaucoup de questions mais chacun de vous pourra sûrement apporter sa pierre à l'édifice  :D  




 
pour xinetd, oui les services demarrer par xinetd utilise tcpwrapper et sont donc sensible a hosts.allow et deny
de meme ssh (bien qu'il ne soit pas demarre par xinetd :D )
 
sinon on conseille de demarrer un service via inetd ou xinetd lorsque c un service qui ne recois pas des requete regulierement, car en fait il est plus long a demarre que si il est lance en tant que daemon (standalone)


Message édité par djtoz le 27-07-2002 à 22:39:31
Reply

Marsh Posté le 27-07-2002 à 23:10:34    

donc les fichiers de configuration dans /etc/xinetd font double emploi avec hosts.allow et hosts.deny? Ce n'est pas le même daemon qui surveille les autorisations?


---------------
Gitan des temps modernes
Reply

Marsh Posté le 28-07-2002 à 02:32:12    

bobor a écrit a écrit :

donc les fichiers de configuration dans /etc/xinetd font double emploi avec hosts.allow et hosts.deny? Ce n'est pas le même daemon qui surveille les autorisations?




 
ben non, ils ont pas la meme fonction
ds tes fichiers ds /etc/xinetd, tu parametre ton service
et avec les hosts.allow et deny tu definie qui a le droit d'y acceder

Reply

Marsh Posté le 28-07-2002 à 12:36:14    

mais tu peux configurer les machines qui ont le droit d'y accéder avec le paramètres "only from". Tu le mets dans xinetd.conf pour que cela s'applique à tous les services ou dans le fichier propre au service.
 
Et c'est là où je ne vois qui travaile pour qui...
Et les services dans /etc/services? sont-ils dirigés par xinetd? Avec xinetd.conf ou hosts.allow/deny? :pt1cable:


---------------
Gitan des temps modernes
Reply

Marsh Posté le 28-07-2002 à 13:00:32    

bobor a écrit a écrit :

mais tu peux configurer les machines qui ont le droit d'y accéder avec le paramètres "only from". Tu le mets dans xinetd.conf pour que cela s'applique à tous les services ou dans le fichier propre au service.
 
Et c'est là où je ne vois qui travaile pour qui...
Et les services dans /etc/services? sont-ils dirigés par xinetd? Avec xinetd.conf ou hosts.allow/deny? :pt1cable:  




 
je ne savais pas qu'on pouvais donner les droits d acces directement ds le fichier xinetd.conf
mais ds les 2 cas, je suppose que ca fais apelle a tcpwrappers
tu peut donc soit passe tes parametres a tcpwrapper grace au fichier hosts.allow ou deny ou alors directement ds le fichier.
(suis pas sur a 100% de ce que je viens de dire :) )
 
sinon pour /etc/services c'est un fichier qui fais une correspondance entre des services et leur port d'ecoute respectifs
il est utilise par certaine appli, permettant ds les configurations de specifie soit un numero de port ou le nom du service
 
il existe la meme chose pour les protocoles:
/etc/protocols

Reply

Marsh Posté le 28-07-2002 à 13:04:37    

je ne suis pas sûr de ça. Pour l'instant je n'ai pas tcpwrappers installé. Je vais voir si je peux bloquer les services seulement avec xinetd


---------------
Gitan des temps modernes
Reply

Marsh Posté le 28-07-2002 à 13:45:20    

Bon je confirme: si je n'autorise pas depuis xinetd mes stations, les stations n'ont plus accès aux services gérés par xinetd. Or je n'ai pas tcpwrapper d'installé.
 
Donc je ne comprends pas trop la correspondance ente les services gérés ou non par xinetd, tcpwrappers, les hosts.allow/deny.


---------------
Gitan des temps modernes
Reply

Marsh Posté le 28-07-2002 à 14:00:09    

bobor a écrit a écrit :

Bon je confirme: si je n'autorise pas depuis xinetd mes stations, les stations n'ont plus accès aux services gérés par xinetd. Or je n'ai pas tcpwrapper d'installé.
 
Donc je ne comprends pas trop la correspondance ente les services gérés ou non par xinetd, tcpwrappers, les hosts.allow/deny.




 
bon j arrive pas vraiment a comprendre ce que tu comprends pas :)
 
cherche de la doc sur tcpwrapper
regarde ce lien, peut etre que ca va t aider:
http://www.tldp.org/HOWTO/Security [...] urity.html

Reply

Marsh Posté le 01-08-2002 à 00:43:57    

Je vais réexpliquer mon problème et mes interrogations sur un exemple concret:
 
 situation de départ:  
-   rien dans hosts.*  
-   xinetd configuré pour les machines locales
-   Tcpwrappers non installé
 
Là tout roule. Maintenant on complique. Je lance l'utilitaire msec fourni avec Mandrake. Il me rajoute ALL: DENY dans hosts.deny.
Là je n'accède plus aux services depuis mes stations. Normal. Enfin presque car tcpwrappers n'est toujours pas installé! Or c'est ce daemon qui doit faire le tri...xinetd toujours configuré pour les machines locales. Rien ne passe.
- donc première question: qui bloque l'accès?
 
Maintenant, le but est de rétablir l'accès pour les machines locales. Je rajoute dans hosts.allow:
ipop3d: IP locales
Et bien cela ne passe toujours pas. Pis, je peux mettre ipop3d:ALL et toujours rien ne passe. Voire même un ALL:ALL dans hosts.allow et toujours rien ne passe.
 
D'où ma question assez générale: quels sont les liens entre xinetd, tcpwrappers et msec?
Q'est-ce qui fait double emploi. Comment utiliser msec avec xinetd...
 
je ne dois pas être le seul à jouer avec msec donc il doit bien y avoir des réponses...


---------------
Gitan des temps modernes
Reply

Marsh Posté le 01-08-2002 à 00:43:57   

Reply

Marsh Posté le 01-08-2002 à 14:08:54    

En examinant les logs, je vois que c'est libwrap qui stoppe les accès. Or j'ai fait une recherche par fichier et libwrap n'est pas installé. Donc il bloque mais n'autorise pas.  :pt1cable:


---------------
Gitan des temps modernes
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed