j’ai toujours le daemon inetd qui tourne : # ps aux | grep inetd
root 2583 0.0 0.0 2572 832 ? Ss 07:19 0:00 /usr/sbin/inetd et je me demande si je vais pas le virer … et je vous demande :
comment je peux savoir les processus / daemon qui ont nécessité que inetd se lance, ou qui ont été lancé par lui … ?
si il y a des précautions à prendre avant de le remove®
comment le désinstaller ( --> connaitre le nom du pkg qui fournit inetd sur ma machine) ?
si il y a une alternative fiable à inetd, laquelle conseiller ? (parmis xinetd, rlinetd ou openbsd-inetd).
nécessité un tel daemon (l’alternative), ou si on peut se contenter des scripts déposés dans /etc/init.d ?
j’ajoute que j’ai viré tout mes rc?.d en apt-get (tant) file-rc ce qui me parait déjà une solution plus propre et plus carrée pour gérer le lancement des daemons …
[ suite de nos préoccupations en matière de sécurité ]
Dans le fichier de config de inetd a savoir /etc/inetd.conf, tu trouveras les daemons avec les binaires et les ports associés.
Non aucune, a l’epoque inetd est utilisé pour lançer les deamons, mainteant chaque deamon est capable de ce lançer en standalone (autonome).
apt-cache search inetd ???
Les deamons de nos jours ce lançe en standalone donc tu peux virer c’est issues.
[quote]
nécessité un tel daemon (l’alternative), ou si on peut se contenter des scripts déposés dans /etc/init.d ? [/quote]
Tu peux te contenter des scripts.
[quote]
Les serveurs réseau sous Unix peuvent en général être lancés de deux façons différentes : en tant que serveurs indépendants (mode standalone) ou via inetd. Dans le premier cas, le serveur est lancé au démarrage de la machine et tourne en permanence jusqu’à son extinction. Il ne cesse d’écouter le port correspondant à son service et répond aux requêtes arrivant sur ce port. Lorsqu’un service passe par inetd, le serveur associé est lancé à la demande, uniquement lorsqu’une requête arrive sur le port associé. Inetd est une sorte de « méta-serveur » qui est à l’écoute de tous les ports associés aux services qui lui sont confiés. Quand inetd reçoit une requête, il lance le serveur concerné pour répondre à cette requête particulière.
Tout cela paraît bien simple, n’est-ce pas ? Eh bien comme c’est trop simple, on va rajouter une couche ! Inetd n’étant pas très doué pour gérer la sécurité, on utilise tcpd comme intermédiaire entre inetd et les serveurs. Tcpd fait partie d’un paquetage appelé Tcp Wrappers. Le principe est le suivant : pour tous les services qui passent par inetd, on va expliquer à inetd que le serveur compétent est tcpd. Ce dernier va donc lui aussi fonctionner comme un méta-serveur et passer la main au vrai serveur, après avoir fait les contrôles de sécurité nécessaires.
Certaines distributions de Linux utilisent maintenant xinetd. Xinetd est un méta-serveur qui réunit les fonctionnalités de inetd et de tcpd en un seul programme, plus des fonctionnalités supplémentaires. [/quote]
j’ai toujours le daemon inetd qui tourne : # ps aux | grep inetd
root 2583 0.0 0.0 2572 832 ? Ss 07:19 0:00 /usr/sbin/inetd et je me demande si je vais pas le virer … et je vous demande :
comment je peux savoir les processus / daemon qui ont nécessité que inetd se lance, ou qui ont été lancé par lui … ?
[/quote]
C’est très facile, il suffit de regarder le fichier de config.
en quelquesorte oui; xinetd étant plus sécurisé qu’inetd (ne me demandes pas pourquoi lol) . Quoiqu’ils soient souvent mentionnés dans des tutos d’install de daemon, les inetd and co ne sont “plus” vraiment utiles , y’a qu’à lancer les services en standalone … (init.d et sa ‘kirielle’ de scripts).
Est ce que je mélange tout, ou file-rc, ça a encore quelque chose à voir avec inetd … je sais plus là … file-rc génére un fichier en remplacement des rc?.d dont voici un extrait chez moi :
[quote="/etc/runlevel.conf"]# This file was automatically generated by /usr/share/file-rc/rclink2file.sh.
You can use your favourite editor or update-rc.d(‘8’) to modify it.
Read runlevel.conf(5) man page for more information about this file.
Format:
01 0,1,6 - /etc/init.d/gdm
01 - S /etc/init.d/glibc.sh
02 - S /etc/init.d/mountvirtfs
03 - S /etc/init.d/udev
05 - 1 /etc/init.d/single
05 - S /etc/init.d/bootlogd
05 - S /etc/init.d/initrd-tools.sh
05 - S /etc/init.d/keymap.sh
07 - S /etc/init.d/hdparm
10 - 2,3,4,5 /etc/init.d/sysklogd
10 - S /etc/init.d/checkroot.sh
11 0,1,6 - /etc/init.d/cron
11 - 2,3,4,5 /etc/init.d/klogd
--------------------- … etc … --------------------------
[/quote] ainsi, il ne s’occupe que de init.d …
il faut que je vois ce que c’est ident et service ftp, c’est les seuls trucs qui ne sont pas commentés dans mon fichier de conf d’inetd ;(quoique le ftp, je me demande si c’est pas un résidu de quand je m’entêtais à pas le vouloir en standalone, mon proftpd …).
en effet : dpkg -l| grep inetd
ii netkit-inetd 0.10-10.3 The Internet Superserverquestion idiote …
[quote=“ed”]Attention, ce genre de daemon sont en général très fiables, et permettent un bon niveau de sécurité, ils ne sont pas donc nécessairement “Dangeureux”.[/quote]Ben oui, les suivants étant un peu plus faciles à configurer … c’est là que ça devient dangerous, quand c’est pas bien configurer … les sources de mes tracas :[quote=“Manuel de sécurisation de Debian”]Si vous voulez toujours exécuter un service du genre d’inetd, tournez-vous plutôt vers un démon inetd plus configurable comme xinetd, rlinetd ou openbsd-inetd.
Vous devriez arrêter tous les services Inetd non nécessaires sur votre système, comme echo, chargen, discard, daytime, time, talk, ntalk et les r-services (services à distance) (rsh, rlogin et rcp) qui sont considérés comme EXTRÊMEMENT dangereux (utilisez ssh à la place).
[/quote]
[quote=“stonfi”][quote]- si il y a des précautions à prendre avant de le remove®[/quote]Non aucune, a l’epoque inetd est utilisé pour lançer les deamons, mainteant chaque deamon est capable de ce lançer en standalone (autonome).[/quote]Si quand même on dirait …
J’ai donc remove --purge netkit-inetd, outre que ça m’a enlevé une 20 aine de pkg, parmi lesquels proftpd, ident, ppp*, et mis à jour cupsys, j’ai tenté le coup.
Mon souci, là, c’est que la connection internet ne se lance pas au démarrage, je lis /etc/init.d/ifupdown, mais je ne sais pas trop quoi faire.
C’est pas dramatique, un simple ifup eth0 démarre eth0 mais là où je suis vert, c’est que le cas n’est pas unique, j’ai pas non plus de sysklogd (syslogd) qui se lance …
J’ai cru comprendre que je devais jouer avec :
/etc/init.d/
/etc/runlevel.conf (depuis que j’ai installé file-rc), dont voici un extrait :
[code]# This file was automatically generated by /usr/share/file-rc/rclink2file.sh.
You can use your favourite editor or update-rc.d(8) to modify it.
Read runlevel.conf(5) man page for more information about this file.
Format:
01 0,1,6 - /etc/init.d/gdm
--------------------------- etc … -----------------------
10 - 2,3,4,5 /etc/init.d/sysklogd
--------------------------- etc … -----------------------
39 - S /etc/init.d/ifupdown
40 0,1,6 - /etc/init.d/alsa
[/code]
Bon ben je vais lire man file-rc, update-rc.d(‘8’) & runlevel.conf(5) … si vous avez des idées ??
EDIT: bon laissez tomber, j’ai installé xinetd, tout re-baigne …
[quote=“ed”]Pourquoi mettre quelque chose a la place ???
Je n’utilise PAS de inetd. Je n’en ai pas l’utilité.[/quote]
Si quelqu’un n’utilisant pas de inetd avait un peu de temps pour expliquer comment il s’en passe, ça serait chouette …
Quant à moi, je l’ai réinstallé faute de savoir faire le config adéquate … car j’avais :
plus de logs
plus de connection internet sitôt booté
aprés un ifup eth0, message d’erreur de aMSN "Unable to find socket … check your /etc/hosts files …"
J’ai vite arrêté la petite expérience …
[quote]ginkgobiloba@debian:~$ dpkg -l | grep inetd
rc netkit-inetd 0.10-10.2 The Internet Superserver
ii openbsd-inetd 0.20050402-1 The OpenBSD Internet Superserver[/quote]
J’espère que les indication satisferont usinagaz.
Cela a été installé par le système et je ne compte pas y toucher : si les développeurs debian ont jugé utile que cela soit installé, je n’ai pas les compétances pour savoir si c’est bien ou pas et je choisi de faire confiance.
Du coup je me pose la question de la gestion des ressources.
Etant donné que lors de l’utilisation d’un méta-serveur, les démons sont chargés à la demande, n’y a-t-il pas un avantages à gérer ses démons par ce biais pour ne charger que ce qui est sollicité ?
Peut-on rééellement charger n’importe quel démons en mode inetd ? Par exemple, mon serveur Wesnoth ou Tremulous, ne démarraient-t-ils que lorsqu’une session cliente solliciterait le port concerné ?
Enfin de la même façon, un méta-serveur, arrète-il automatiquement un démon dès que celui-ci n’est plus sollicité ?
Voilà, il est vrai que je ne gère mes démons que par la méthode stand-alone avec les /etc/init.d/ et /etc/rc?.d. Mais là du coup j’aimerais bien connaitre les avantages et les inconvénients d’une architecture basée sur un méta-serveur.
[quote=“salokine”]Voilà, il est vrai que je ne gère mes démons que par la méthode stand-alone avec les /etc/init.d/ et /etc/rc?.d. Mais là du coup j’aimerais bien connaitre les avantages et les inconvénients d’une architecture basée sur un méta-serveur.
[/quote]
Tu pourras lire certains inconvénients évoqués ici : debian.org/doc/manuals/secur … .html#s3.6
J’ai installé file-rc, ce qui a eu pour effet de supprimer tout les rc?.d, et de reprendre tous les scripts présents dans init.d en les listant dans un fichier /etc/runlevel.conf … j’ai cru que ça me dispenserait d’un inetd, erreur … J’ai pas encore compris le fonctionnement …
Donc toi, tu n’as pas d’inetd ? c’est ce que j’aurais aimé comprendre … comment fait on sans les inetd ? j’avais plus grand chose de fonctionnel …
ginkgo biloba : merci, apparemment openbsd-inetd , xinetd sont plus fiables en terme de sécurité, ça dépend encore de ce qu’on autorise ou pas comme service, à être lancer … (cf. lien).
