Une machine Unix associe des numéros de ports à des protocoles.

Les protocoles utilisés par le réseau InterNet sont libres et sont décrits dans des documents appelés RFC (Request For Comment). Les éditeurs de logiciels implémentent ensuite ces protocoles dans leurs produits.

Pour plus d’informations, on pourra consulter le site http://reseau.plisson.org.

1. Le niveau réseau : /etc/protocols

Sous UNIX, on trouve tous les protocoles supportés de niveau réseau dans le fichier /etc/protocols

2. Le niveau transport : /etc/services

La couche transport apporte la notion de port : identification des applications par le numéro de port unique qu’elles utilisent. On appelle socket la combinaison d’une adresse IP et d’un port.

Sous UNIX, la liste des services supportés se trouve dans le fichier /etc/services

Pour obtenir la liste des ports vous pouvez consulter le site neohapsis

On note que les applications sont disponibles soit en UDP, soit en TCP, soit dans les deux modes.

UDP

UDP offre un service sans connexion de type datagramme sans garantie de réception (protocole de transport non fiable). Il est utilisé quand TCP est trop compliqué à mettre en oeuvre, trop lent, ou inutile. UDP est utilisé pour de petits transferts, rapides où le fait de gérer les problèmes de connexion serait plus long que de retransmettre toutes les données.

TCP

TCP comble les manques d’IP en assurant un transport fiable et efficace de bout en bout (de processus à processus identifié par la paire @IP+port) déchargeant ainsi le niveau application de tout problème d’acheminement. Il fonctionne en mode connecté en utilisant IP pour maintenir cette connexion logique : ouverture et fermeture de connexion.

3. Le niveau application : inetd, xinetd et démarrage autonome

INETd

Les applications décrites ici sont toutes des application client/serveur. Dans le monde UNIX, c’est le processus INETd qui est traditionnellement chargé d’écouter tous les ports et de basculer sur l’application demandée en fonction du numéro de port de la demande. Le fichier de configuration d’INETd est /etc/inetd.conf

On remarque que l’application (ici le serveur telnet) est généralement précédée du programme in.tcpd :

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

Il s’agit de TCP Wrapper qui encapsule des applications démarrées par INETd pour en restreindre et en contrôler l’accès. TCP wrapper est configuré par deux fichiers : /etc/hosts.allow et /etc/hosts.deny

Soit l’objectif suivant : permettre à une machine quelconque du parc informatique de l’UFR de recevoir des connexions telnet uniquement en provenance des machines du domaine math-info.univ-paris5.fr à l’exclusion du domaine ens.math-info.univ-paris5.fr.

Pour atteindre cet objectif avec tcp wrapper, on laisse vide le fichier hosts.deny et on ajoute la ligne suivante dans /etc/hosts.allow (sur la machine en question) :

in.telnetd : LOCAL, .math-info.univ-paris5.fr EXCEPT .ens.math-info.univ-paris5.fr

Il faut également avoir à l’esprit que la sécurité via tcp wrapper ne concerne que la machine sur laquelle il s’exécute : si un firewall est installé à la porte d’entrée du réseau (ou sur la même machine), c’est celui-ci qui prime.

Les numéros de port ne sont pas renseignés dans le fichier /etc/inetd.conf  ; ils sont définis dans /etc/services

xinetd

Les distributions récentes de linux remplacent maintenant INETd par xinetd. Par rapport à INETd, xinetd permet notamment :

  d’individualiser la configuration de chaque application
  des contrôles d’accès plus fins
  de faire un contrôle des services basé sur le temps
  de limiter le nombre de serveurs démarrés

On peut également implémenter des méchanismes de défense contre les scanners de ports. Chaque application possède son propre fichier de configuration situé dans /etc/xinetd.d Ainsi, contrairement à proftpd, le serveur ftp wu-ftpd se configure par xinetd. Enfin il faut noter que ces services sont désactivés par défaut (au moins sur redhat/mandrake). Pour rendre actif un service, il faut remplacer :

disable                        = yes

Par :

disable                        = no

dans le fichier de configuration de l’application.

Il faut enfin noter que xinetd est également compatible avec tcp wrapper.

Démarrage autonome ou standalone

Pour des raisons de souplesse et de sécurité, les applications de type serveur/réseau ont tendance à s’affranchir du processus INETd (ou de xinetd).

Si l’on veut par exemple supprimer la gestion par INETd du serveur ftp, il faut éditer le fichier /etc/inetd.conf, commenter la ligne qui concerne ftp (par le signe #), lancer la commande ps auxw|grep inet pour connaître le numéro de processus associé à INETd et enfin envoyer un signal HUP (ou -1) à ce processus pour lui indiquer de relire sa configuration.

A l’évidence, cela n’est guère pratique et peut être dangereux si l’on se trompe de numéro de processus.

C’est pourquoi les programmes récents de type serveur sont maintenant lancés par des scripts situés dans le répertoire /etc/rc.d/init.d (ou /etc/init.d). Ces scripts permettent par les paramètres stop, start et restart d’arrêter ou de redémarrer un service. Pour démarrer le serveur ssh, il faut donc taper (en tant que root) la commande :

$/etc/init.d/sshd start

Sous redhat/mandrake, la commande service permet de ne pas taper le nom du répertoire où se situe le script. On pourra donc plus simplement taper la commande :

$service sshd start

Le démarrage automatique (au boot) des programmes se configure avec la commande chkconfig qui a pour syntaxe :

$ chkconfig --level [numéro du niveau de démarrage] [nom du script dans /etc/rc.d/init.d] [on/off]

Par exemple, pour activer automatiquement le serveur sshd lors du démarrage de la machine en mode graphique, il suffit donc de taper la commande suivante (en root, bien sûr !) :

$ chkconfig --level 5 sshd on

Si on visualise le contenu du répertoire /etc/rc.d/rc5.d, on s’aperçoit qu’un lien symbolique nommé S55sshd (S comme start suivi d’un numéro d’ordre par défaut) pointant vers le fichier ../init.d/sshd a été créé. Attention toutefois : la commande chkconfig est spécifique aux distributions redhat/mandrake de linux. Pour les autres distributions linux ainsi que pour les autres système unix, il faut ajouter le lien symbolique à la main ou utiliser autre commande spécifique.

Sous Unix, ces applications réseau lancées par inetd et/ou /etc/rc.d/init.d sont appelées démons (daemons) : elles sont exécutées sans avoir à être lancées depuis un terminal et sont prêtes à répondre à un client.

Il est également possible quoique déconseillé de démarrer l’application en configurant le fichier /etc/rc.d/rc.local, qui est exécuté à chaque démarrage de la machine.

En résumé, pour qu’une application soit lancée au démarrage d’un serveur Unix et que l’on puisse l’utiliser, il faut :

  que l’application soit installée (le serveur telnet n’est par exemple pas installé sur nos machines)

  que l’on ait le droit d’y accéder (cf. tcp wrapper, configuration propre à l’application ou règles ipchains/iptables)

  que son démarrage soit prévu dans le fichier /etc/inetd.conf (ou dans le répertoire /etc/xinetd.d), dans un script situé dans /etc/init.d (avec un lien symbolique dans le niveau de démarrage souhaité, ex : /etc/rc5.d pour le mode graphique) ou bien encore dans le fichier /etc/rc.d/rc.local

  si et seulement si le programme est lancé par inetd/xinetd, alors le numéro de port doit être présent dans /etc/services.

On peut terminer cette partie en récapitulant les changements de type serveur/sécurité apparus sous linux depuis environ deux ans :

	linux ancien	linux nouveau
Répertoire de démarrage	/etc/rc.d/init.d	/etc/init.d
Version d’INETd	inetd	xinetd
Firewall	ipchains	iptables

Seul le remplacement d’ipchains (2.2) par iptables dépend de la version du noyau utilisé (2.4).