<p class="spip">Un service réseau est un logiciel ayant pour but de répondre à une demande provenant du réseau.<br />
Il n’est pas rare d’avoir un certain nombre de services démarrés en même temps que son système d’exploitation.<br />
Le but de se document est de comprendre l’utilité d’un certain nombre de services reseaux et ainsi jugé s’il est util de le conserver. Puis nous nous attacheront à voir comment utiliser les mécanismes internes aux logiciels pour contrôler les accès et les informations fournies.</p>

<h2>Liste des services</h2>
<p class="spip">Pour connaitre les services réseau :<br />
<i class="spip">netstat -tanp | grep LISTEN</i><br />
Voici un exemple de service :<br />
<i class="spip">tcp 0 0 *:111 * :* LISTEN 1505/rpc.portmap </i></p>

<p class="spip">Les informations qui nous interessent ici sont :</p>
<ul>
<li> *:111 : le port 111 est utilisé ...</li>
<li> 1505/rpc.portmap : ... par l’application rpc.portmap (ayant le PID 1505)</li>
</ul>

<p class="spip">Pour question de facilité, je vais prendre la syntaxe retourné par l’outil nmap : <i class="spip">nmap -sV 192.168.1.76</i> (la machine utilisé aura l’ip 192.168.1.76).<br />
Cette outil donne la liste des services réseaux démarré sur la machine cible.<br />
La syntaxe de la réponse est : Port/Protocole Etat Nom_du_service.<br />
Voici une liste de service couremment ouvert :</p>

<hr />
<h3>9/tcp    open  discard ?</h3>
<h4>but</h4>
Le service discard peut être considéré comme l’équivalent du fichier <i class="spip">/dev/null</i> sur le réseau : les octets qu’on lui envoie seront oubliés ("discard").
<h4>utilisation</h4>
<i class="spip">telnet 192.168.1.76 9</i>
<h4>arret, protection</h4>
voir inetd
<hr />
<h3>13/tcp   open  daytime</h3>
<h4>but</h4>
Donne la date système en clair.
<h4>utilisation</h4>
<i class="spip">telnet 192.168.1.76 13</i>
<h4>arret, protection</h4>
voir inetd
<hr />
<h3>22/tcp   open  ssh      OpenSSH 3.8p1 (protocol 2.0)</h3>
<h4>but</h4>
Serveur ssh. Permet d’executer des commandes sur une machine a distance, de transmettre des fichiers ... de façon sécurisé.
<h4>utilisation</h4>
<i class="spip">ssh 192.168.1.76</i>
<h4>arret, protection</h4>
Sous slackware : <i class="spip">/etc/rc.d/rc.sshd stop</i><br />
<i class="spip">chmod -x /etc/rc.d/rc.sshd</i>
<hr />
<h3>25/tcp   open  smtp ???</h3>
<h4>but</h4>
Serveur smtp. Il sert à envoyer et recevoir des courriels. Ce serveur n’est pas utile si vous utilisez une client courrier comme evolution, mozilla-mail ou kmail.
<h4>utilisation</h4>
<i class="spip">telnet 192.168.1.76 25</i><br />
<i class="spip">HELO</i><br />
Pour vérifier si un utilisateur existe sur le systeme :<br />
<i class="spip">VRFY root</i><br />
<i class="spip">250 <root> is deliverable</i><br />
<i class="spip">VRFY existepo</i><br />
<i class="spip">550 <existepo> Unrouteable address</i><br />
Plus interessant, il est possible de savoir a qui est rediriger un mail :<br />
<i class="spip">EXPN root</i></br />
<i class="spip">250 <gnunux@192.168.1.76></i><br />
<h4>protection</h4>
Il est possible pour certain serveur mail d’interdire les commandes VRFY et EXPN.
<strong class="spip">Attention a l’openrelay !</strong>
<h4>arret</h4>
Il est possible d’arrêter le serveur smtp. 
<hr />
<h3>37/tcp   open  time</h3>
<h4>but</h4>
Donne la date système.
<h4>utilisation</h4>
<i class="spip">rdate 192.168.1.76</i>
<h4>arret, protection</h4>
voir inetd
<hr />
<h3>79/tcp open  finger  Linux fingerd</h3>
<h4>but</h4>
Le serveur finger donne des informations à propos des utilisateurs existants sur l’ordinateur. Les utilisateurs distants peuvent obtenir des informations comme le nom complet, l’adresse, le numéro de téléphone, le titre ...
<h4>utilisation</h4>
<i class="spip">finger @192.168.1.76</i><br />
<i class="spip">finger utilisateur@192.168.1.76</i><br />
Pour changer les informations de l’utilisateur :<br />
<i class="spip">chfn utilisateur</i>
<h4>arret, protection</h4>
voir inetd
<hr />
<h3>80/tcp   open  http     Apache httpd ???</h3>
<h4>but</h4>
Partage de page internet
<h4>utilisation</h4>
Un client internet (mozilla par exemple) suffit ;)<br />
Nous allons tester tout de même notre serveur avec <i class="spip"><a href="http://www.cirt.net/code/nikto.shtml" class="spip_out">nikto</a></i><br />
Pour mettre a jour la base<br />
<i class="spip">nikto -update</i><br />
Lancer les tests<br />
<i class="spip">nikto -h 192.168.1.76</i><br />
<h4>protection</h4>
<ul><li>Suppression du numero de version : <i class="spip">ServerSignature Off</i> (donner avec <i class="spip">telnet 192.168.1.76 80</i> puis <i class="spip">GET /index.html HTTP/1.0</i> et deux fois "<i class="spip">entrée</i>").</li>
<li>Verification des répertoires partagés sur internet : regarder les sections <Directory "...">. Par exemple chez moi j’ai (en faisant <i class="spip">grep "<Directory" /etc/apache/httpd.conf</i> dans une console) :
<i class="spip">
<ul><li><Directory /></li>
<li><Directory "/var/www/htdocs"></li>
<li>#<Directory /home/*/public_html></li>
<li>    <Directory "/var/www/icons"></li>
<li>    <Directory "/var/www/htdocs/manual"></li>
<li>    <Directory "/var/www/cgi-bin"></li>
</ul>
</i>
Les lignes commençant par # sont commenté. Ils n’ont donc pas d’effet.
Comme je n’ai pas de manuel et de cgi-bin, je peux commenté sans problème ces sections (une section commencant par <i class="spip"><Directory "..."></i> et finissant par <i class="spip"></Directory></i>).</li>
<li>Empêcher la lecture d’un repertoire : dans les sections <i class="spip"><Directory ...></i>, supprimer l’option <i class="spip">"Indexes"</i></li>
<li>Controle des acces : modifier les lignes suivantes (toujours dans les sections voulues) :<br />
<i class="spip">Order allow,deny</i> -> <i class="spip">Order deny,allow</i><br />
<i class="spip">Allow from all</i> -> <i class="spip">Deny from all</i>
<ul><li>Nous pouvons ensuite autoriser un nom de fichier particulier : <br />
<i class="spip"><Files test.html><br />
 Allow from all<br />
</Files></i><br />
(ici tous les fichiers test.html inclut dans la section seront accessible par tout le monde).
</li>
<li>Autoriser le poste local d’acceder au serveur : <i class="spip">Allow from 127.0.0.1</i></li>
<li>Autoriser le reseau local d’acceder au serveur : <i class="spip">Allow from 192.168.1.0/255.255.255.0</i></li>
<li>Demande d’identification pour les autres :<br />
    <i class="spip">AuthName "Et oui, il faut s’identifier ici !"<br />
    AuthType Basic<br />
    AuthUserFile /etc/apache/htpasswd<br />
    Require valid-user<br />
    Satisfy Any</i><br />
puis creer le fichier /etc/apache/htpasswd :<br />
<i class="spip">htpasswd -c /etc/apache/htpasswd test</i> (pour creer l’utilisateur test).<br />
Attention :l’option -c n’est utile que pour créer le fichier.</li></ul></li>
</ul>
<h4>arret</h4>
Sous slackware : <i class="spip">/etc/rc.d/rc.httpd stop</i><br />
<i class="spip">chmod -x /etc/rc.d/rc.httpd</i>
<hr />
<h3>111/tcp  open  rpcbind  2 (rpc #100000)</h3>
<h4>but</h4>
SUN Remote Procedure Call (RPC) est technique permettant de gérer des applications client/serveur. Il permet à une application d’appeler une sous-application sur une autre machine. Ce port est utilisé en tant que des moyens bien définis pour déterminer les ports sur lesquels d’autres services fonctionnent sur le système.  Il désigné sous le nom d’un "portmapper" parce qu’il fournit un annuaire, ou de "mappage" entre les services disponibles et leurs ports.  Les ports étant éphémère.
<h4>utilisation</h4>
<i class="spip">rpcinfo -p 192.168.1.76</i> (ou <i class="spip">nmap -sR 192.168.1.76</i>)<br />
Une liste de service rpc lancé apparait. La liste contient des numeros inscrit dans <i class="spip">/etc/nfs.</i><br />
Un certain nombre de serveur rpc existe :<br />
si <strong class="spip">mountd</strong> -> <i class="spip">showmount -e 192.168.1.76</i> (le demon mountd receptionne le requete de montage de la machine cliente)<br />
si <strong class="spip">ruserd</strong> -> <i class="spip">rusers -l 192.168.1.76</i> (donne les mêmes informations que who en local)<br />
si <strong class="spip">rstatd</strong> -> <i class="spip">rup</i> (un broadcast est envoyé. En retour on obtient l’uptime)<br />
Le client peut faire des demande RPC seulement si le demon portmap est lancé. Lors qu’un serveur RPC demarre, il donne à pormap son numero de port d’écoute et sont numéro RPC (voir <i class="spip">/etc/nfs</i>).
<h4>protection</h4>
RPC utilise les mêmes fichiers de configuration que tcpwrapper (voir inetd).
<h4>arret</h4>
<strong class="spip">pormap</strong> -> voir inetd<br />
les serveurs rpc sont lancé seul. Leur nom est généralement rpc.nom_du_service (exemple <i class="spip">rpc.mountd</i>).
<hr />
<h3>113/tcp  open  ident    OpenBSD identd</h3>
<h4>but</h4>
L’idée derrière ce protocole était de fournir un service pour identifier automatiquement les utilisateurs qui essaye de se connecter. Le service distant regarde si la personne qui accède est déjà identifier sur le poste. Cela permettait des authentifications automatiques sur FTP par exemple. Mais les protocoles etaient tellement simple qu’il était facile à contourner.
Il sert aujoud’hui encore pour des serveurs IRC ou serveur mail.
<h4>utilisation</h4>
<i class="spip">nmap -sT -I 192.168.1.76</i>
<h4>arret</h4>
voir inetd
<hr />
<h3>6000/tcp</h3>
<h4>but</h4>
Offrir a des personnes extérieurs la possibilité de lancer des applications X.
<h4>utilisation</h4>
Il est nécessaire d’avoir un cookie sur le serveur. Celui est stocké dans le fichier dans le répertoire $HOME/.Xauthority (ou autre suivant le contenu de la variable $XAUTHORITY).<br />
Si le fichier n’existe pas faire :<br />
<i class="spip">xauth add :0 . `mcookie`</i><br />
Le programme <i class="spip">xauth</i> est utilisé pour editer et afficher les information d’authentification des utilisateurs pour se connecter sur un serveur X.<br />
<strong class="spip">serveur</strong> : <i class="spip">xauth extract fichier $DISPLAY</i><br />
Copier le fichier sur le client<br />
<strong class="spip">client</strong> : <i class="spip">xauth merge fichier</i><br />
puis <i class="spip">xauth generate :0 .</i>
ou<br />
<strong class="spip">serveur</strong> : <i class="spip">xauth list</i><br />
<strong class="spip">client</strong> : <i class="spip">xauth add ???????</i>
<h4>arret</h4>
<ul><li>Si vous lancer X avec startX :
Dans <i class="spip">/usr/X11R6/bin/startx</i> mettre : <i class="spip">serverargs="<strong class="spip">-nolisten tcp</strong>"</i></li>
<li>Si vous utilisez xdm :
Dans <i class="spip">/etc/X11/xdm/Xserver</i> mettre : <i class="spip">:0 local /usr/X11R6/bin/X <strong class="spip">-nolisten tcp</strong> </i></li>
<li>Si vous utilisez gdm :
Dans le panneau de configuration <strong class="spip">gdmconfig</strong>, onglet <i class="spip">Sécurité</i>, cochez <i class="spip">Toujours interdir les connexions TCP au serveur X</i>(option par défaut).</li>
</li>Si vous utilisez kdm, cherchez et donnez moi la solution ;).</li>
</ul>
<h2>Inetd</h2>
<p class="spip">Inetd permet de lancer des services au moment où ils sont appelés.<br />
Pour désactiver un service, il suffit de commenter la ligne correspondante dans <i class="spip">/etc/inetd.conf</i>.</p>

<p class="spip">Inetd n’a aucun mecanisme de contrôle d’accès aux services (contrairement a xinetd). Voila pourquoi la plupart des services sont lancés avec le démon tcpd (le démon tcpwrapper).<br />
Tcpwrapper fait un contrôle au niveau de l’adresse IP. Deux fichiers de configuration sont utilisés :</p>
<ul><li>Hôte rejeté : /etc/hosts.deny</li>
<li>Hôte accepté : /etc/hosts.allow</li>
</ul>
La syntaxe des deux fichiers est la suivante :<br />
<i class="spip">service : hôte</i><br />
exemples :
<ul><li>finger : ALL :</li>
<li>portmap : 127.0.0.1 192.168.1.3</li>
</ul>
Il semble interessant par défaut d’interdir tout le monde (<i class="spip">ALL : ALL :</i> dans <i class="spip">/etc/hosts.deny</i> et d’autorisé les hôtes suivants le service)