Lecon 6

Université Virtuelle de Côte d'Ivoire

 Table des
matières
Objectifs 3

I - Typologie des attaques : Vérification de l'identité des ports en attente de requêtes

4
1. Typologie des attaques : Vérification de l'identité des ports en attente de requêtes ....................................... 4

2. La sortie de cette commande ressemble à l'extrait suivant : ........................................................................... 4

II - Activité d'auto-évaluation 1 7

III - Sécurisation de NIS 8

1. Sécurisation de NIS ......................................................................................................................................... 8

2. Planifier prudemment le réseau ...................................................................................................................... 8

3. Utilisation d'un nom de domaine NIS et d'un nom d'hôte de type mot de passe ............................................. 9

4. Modification du fichier /var/yp/securenets ..................................................................................................... 9

5. Attribution de ports statiques et utilisation de règles IPTables ....................................................................... 9

6. Utilisation de l'authentification Kerberos ..................................................................................................... 10

7. Limitation des attaques par déni de service .................................................................................................. 10

IV - Activité d'auto-évaluation 2 11

Solutions des exercices 12

 Objectifs
À la fin de cette leçon, l'apprenant sera capable de :

• Décrire la typologie des attaques

• Identifier les solutions en fonction de la typologie

3
 Typologie des attaques : Vérification de l'identité des ports en attente de requêtes

Typologie des attaques :

Vérification de l'identité I
des ports en attente de
requêtes

1. Typologie des attaques : Vérification de l'identité des ports en

attente de requêtes
Une fois les services configurés sur le réseau, il est important de connaître les ports qui sont en attente
de requêtes sur les interfaces réseau du système. Tout port ouvert peut faire l'objet d'une intrusion.

Il existe deux approches de base pour établir la liste des ports en attente de requêtes sur le réseau.
L'approche la moins fiable consiste à interroger la pile réseau en saisissant des commandes telles que
netstat -an ou lsof -i. Cette méthode est moins fiable dans la mesure où ces programmes ne
connectent pas l'ordinateur au réseau, mais vérifient seulement ce qui est exécuté sur le système. Pour
cette raison, ces applications sont des cibles fréquentes de remplacement par des agresseurs. De cette
manière, des craqueurs tentent de dissimuler leurs traces en ouvrant des ports réseau non-autorisés.

Une manière plus sûre de vérifier l'identité des ports en attente de requêtes sur le réseau consiste à
utiliser un scanneur de ports tel que nmap.

La commande suivante exécutée à partir de la console détermine les ports en attente de connexions
TCP depuis le réseau.

nmap -sT -O localhost

2. La sortie de cette commande ressemble à l'extrait suivant :

Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2004-09-24 13:49 EDT

Interesting ports on localhost.localdomain (127.0.0.1):

(The 1653 ports scanned but not shown below are in state: closed)

PORT STATE SERVICE

22/tcp open ssh

25/tcp open smtp

4
 La sortie de cette commande ressemble à l'extrait suivant :

111/tcp open rpcbind

113/tcp open auth

631/tcp open ipp

834/tcp open unknown

2601/tcp open zebra

32774/tcp open sometimes-rpc11

Device type: general purpose

Running: Linux 2.4.X|2.5.X|2.6.X

OS details: Linux 2.5.25 - 2.6.3 or Gentoo 1.2 Linux 2.4.19 rc1-rc7)

Uptime 12.857 days (since Sat Sep 11 17:16:20 2004)

Nmap run completed -- 1 IP address (1 host up) scanned in 5.190 seconds

Cette sortie montre que le système exécute portmap en raison de la présence du service sunrpc.
Toutefois, un service mystère existe également sur le port 834. Afin de vérifier si ce port est associé à
la liste officielle des services connus, saisissez :

cat /etc/services | grep 834

Cette commande ne renvoie aucune sortie. Ce qui signifie que, bien qu'étant dans la plage réservée
(c'est-à-dire de 0 à 1023) et nécessitant un accès super-utilisateur pour son ouverture, il n'est pas
associé à un service connu.

Vous pouvez ensuite rechercher des informations sur les ports à l'aide de netstat ou lsof. Pour vérifier
les informations sur le port 834 à l'aide de netstat, utilisez la commande suivante :

netstat -anp | grep 834

La commande renvoie la sortie suivante :

tcp 0 0 0.0.0.0:834 0.0.0.0:* LISTEN 653/ypbind

La présence du port ouvert dans netstat est rassurante car un craqueur ouvrant soudainement un port
sur un système sous son contrôle ne permettrait certainement pas au port d'être exposé par cette
commande. De plus, l'option [p] révèle l'id du processus (PID) du service qui a ouvert le port. Dans le
cas présent, le port ouvert appartient à ypbind (NIS) qui est un service RPC traité de concert avec le
service portmap.

La commande lsof révèle des informations semblables puisqu'elle est capable de lier des ports ouverts
aux services :

lsof -i | grep 834

Ci-dessous figure la partie pertinente de la sortie de cette commande :

ypbind 653 0 7u IPv4 1319 TCP *:834 (LISTEN)

ypbind 655 0 7u IPv4 1319 TCP *:834 (LISTEN)

5
 La sortie de cette commande ressemble à l'extrait suivant :

ypbind 656 0 7u IPv4 1319 TCP *:834 (LISTEN)

ypbind 657 0 7u IPv4 1319 TCP *:834 (LISTEN)

Ces outils révèlent de nombreuses informations sur le statut des services exécutés sur un ordinateur.
Ces outils sont flexibles et fournissent une quantité d'informations importante sur les services réseau
et leur configuration. Il est par conséquent fortement recommandé de consulter les pages de manuel
relatives à lsof, netstat, nmap et services.

6
 Activité d'auto-évaluation 1

Activité d'auto-
évaluation 1 II

Exercice [solution n°1 p.12]

[*]

Trouvez les commandes

La sortie de cette commande ressemble à l'extrait suivant :

Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2004-09-24 13:49 EDT

Interesting ports on localhost.localdomain (127.0.0.1):

(The 1653 ports scanned but not shown below are in state: closed)

PORT STATE SERVICE

22/tcp

25/tcp

Exercice [solution n°2 p.12]

[*]

Trouvez les commandes

La sortie de cette commande ressemble à l'extrait suivant :

PORT STATE SERVICE

22/tcp open

25/tcp open

111/tcp open rpcbind

113/tcp open

631/tcp open

834/tcp open

2601/tcp open

32774/tcp open sometimes-rpc11

7
 Sécurisation de NIS

Sécurisation de NIS
III
1. Sécurisation de NIS
NIS est l'acronyme de Network Information Service. Il représente un service RPC appelé ypserv qui
est utilisé de concert avec portmap et d'autres services connexes pour distribuer des mappes de noms
d'utilisateur, mots de passe et autres informations confidentielles à tout ordinateur se disant être dans
son domaine.

Un serveur NIS se compose de plusieurs applications. Parmi ces dernières figurent :

/usr/sbin/rpc.yppasswdd — Également appelé le service yppasswdd, ce démon permet aux utilisateurs

de changer leur mots de passe NIS.

/usr/sbin/rpc.ypxfrd — Également appelé le service ypxfrd, ce démon est responsable des transferts
de cartes NIS (ou mappes) sur le réseau.

/usr/sbin/yppush — Cette application propage les bases de données modifiées aux multiples serveurs
NIS.

/usr/sbin/ypserv — Représente le démon du serveur NIS.

En fonction des standards actuels, NIS est plutôt vulnérable au point de vue sécurité. Il ne dispose
d'aucun mécanisme d'authentification des hôtes et transmet toutes ses informations sur le réseau de
manière non-cryptée, y compris les hachages de mots de passe. Dans de telles circonstances, il est
important d'être très prudent lors de la mise en oeuvre d'un réseau utilisant NIS. Le fait que la
configuration de NIS par défaut est non-sécurisée par nature, complique encore plus la situation.

2. Planifier prudemment le réseau

Puisque NIS transmet des informations confidentielles sur le réseau de manière non-cryptée, il est
important d'exécuter le service non seulement derrière un pare-feu, mais également sur un réseau
segmenté et sécurisé. Lors de toute transmission d'informations NIS sur un réseau non-sécurisé, elles
risquent d'être interceptées. À cet égard, une conception prudente du réseau peut aider à lutter contre
des brèches de sécurité importantes.

8
 Modification du fichier /var/yp/securenets

3. Utilisation d'un nom de domaine NIS et d'un nom d'hôte de type

mot de passe
Tout ordinateur au sein d'un domaine NIS peut utiliser des commandes pour extraire des informations
du serveur et ce, sans authentification, dès lors que l'utilisateur connaît le nom d'hôte DNS du serveur
NIS et le nom de domaine NIS.

Par exemple, si une personne connecte un ordinateur portable au réseau ou fait intrusion dans le
réseau depuis l'extérieur (et réussit à usurper une adresse IP interne), la commande suivante permettra
de révéler la carte /etc/passwd :

ypcat -d <NIS_domain> -h <DNS_hostname> passwd

Si un agresseur est le super-utilisateur, il peut obtenir le fichier /etc/shadow en saisissant la

commande suivante :

ypcat -d <NIS_domain> -h <DNS_hostname> shadow

Pour rendre plus difficile l'accès d'un agresseur aux cartes NIS, créez une chaîne au hasard pour le
nom d'hôte DNS, comme par exemple o7hfawtgmhwg.domain.com. De même, créez au hasard un
nom de domaine NIS différent. Ce faisant, il sera beaucoup plus difficile pour un agresseur d'avoir
accès au serveur NIS.

4. Modification du fichier /var/yp/securenets

NIS attendra des requêtes de tous les réseaux si le fichier /var/yp/securenets est vierge ou n'existe pas
(comme c'est le cas après une installation par défaut). L'une des premières choses à faire consiste à
spécifier une paire masque réseau/réseau dans le fichier afin que seul ypserv réponde aux requêtes
provenant du réseau approprié.

Ci-dessous figure un exemple d'entrée provenant d'un fichier /var/yp/securenets :

255.255.255.0 192.168.0.0

Cette technique ne protège certes pas contre une attaque par usurpation d'IP, mais elle permet au
moins d'imposer des limites quant aux réseaux dont le serveur NIS peut satisfaire les requêtes.

5. Attribution de ports statiques et utilisation de règles IPTables

Tous les serveurs en relation avec NIS peuvent se voir assigner des ports spécifiques sauf rpc.
yppasswdd — le démon permettant aux utilisateurs de changer leurs mots de passe de connexion.
L'attribution de ports aux deux autres démons du serveur NIS, à savoir rpc.ypxfrd et ypserv, permet
de créer des règles de pare-feu pour protéger davantage les démons du serveur NIS contre des
agresseurs.

Pour ce faire, ajoutez les lignes suivantes au fichier /etc/sysconfig/network :

YPSERV_ARGS="-p 834"

9
 Utilisation de l'authentification Kerberos

YPXFRD_ARGS="-p 835"

Les règles IPTables suivantes peuvent être créées afin de spécifier le réseau que le serveur devra
surveiller pour recevoir des requêtes provenant de ces ports :

iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 834 -j DROP

iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 835 -j DROP

6. Utilisation de l'authentification Kerberos

Un des principaux inconvénients associés à l'utilisation de NIS pour l'authentification réside dans le
fait que lors de toute connexion à une machine par un utilisateur, un hachage de mot de passe
provenant de la carte /etc/shadow est transmis sur le réseau. Ainsi, si un agresseur s'octroie l'accès à
un domaine NIS et renifle le trafic réseau, les hachages de noms d'utilisateur et mots de passe peuvent
être recueillis en toute discrétion. Après un certain temps, un programme de craquage de mots de
passe peut deviner des mots de passe non-hermétiques et un agresseur peut alors accéder à un compte
valide sur le réseau.

Puisque Kerberos utilise un type de cryptographie basé sur des clés secrètes, aucun hachage de mots
de passe n'est jamais transmis sur le réseau, rendant ainsi le système beaucoup plus sécurisé.

7. Limitation des attaques par déni de service

En raison de la nature même des messages électroniques, il est relativement facile pour un agresseur
déterminé de submerger le serveur de messages électroniques et d'entraîner ainsi un déni de service.
En donnant certaines limites aux directives suivantes dans /etc/mail/sendmail.mc, il est possible de
limiter l'efficacité de telles agressions.

confCONNECTION_RATE_THROTTLE — Le nombre de connexions que le serveur peut recevoir

par seconde. Par défaut, Sendmail ne limite pas le nombre de connexions. Si une limite est fixée et
atteinte, les connexions suivantes sont retardées.

confMAX_DAEMON_CHILDREN — Le nombre maximum de processus enfants pouvant être

engendrés par le serveur. Par défaut, Sendmail n'assigne pas de limite au nombre de processus
enfants. Si une limite est fixée et atteinte, les connexions suivantes sont retardées.

confMIN_FREE_BLOCKS — Le nombre minimum de blocs non-utilisés devant être disponibles

pour que le serveur puisse accepter du courrier. La valeur par défaut est de 100 blocs.

confMAX_HEADERS_LENGTH — La taille minimale acceptable (en octets) pour un en-tête de

message.

confMAX_MESSAGE_SIZE — La taille maximale acceptable (en octets) pour tout message

individuel.

10
 Activité d'auto-évaluation 2

Activité d'auto-
évaluation 2 IV

Exercice [solution n°3 p.12]

[*]

Limitation des attaques par déni de service - Complétez par les commandes

Limitation des attaques par déni de service

En raison de la nature même des messages électroniques, il est relativement facile pour un agresseur
déterminé de submerger le serveur de messages électroniques et d'entraîner ainsi un déni de service.
En donnant certaines limites aux directives suivantes dans /etc/mail/sendmail.mc, il est possible de
limiter l'efficacité de telles agressions.

conf _RATE_THROTTLE — Le nombre de connexions que le serveur peut recevoir

par seconde. Par défaut, Sendmail ne limite pas le nombre de connexions. Si une limite est fixée et
atteinte, les connexions suivantes sont retardées.

confMAX_ _CHILDREN — Le nombre maximum de processus enfants pouvant être

engendrés par le serveur. Par défaut, Sendmail n'assigne pas de limite au nombre de processus
enfants. Si une limite est fixée et atteinte, les connexions suivantes sont retardées.

confMIN_ _BLOCKS — Le nombre minimum de blocs non-utilisés devant être

disponibles pour que le serveur puisse accepter du courrier. La valeur par défaut est de 100 blocs.

confMAX_ _LENGTH — La taille minimale acceptable (en octets) pour un en-tête

de message.

confMAX_ _SIZE — La taille maximale acceptable (en octets) pour tout message
individuel.

11
 Solutions des exercices

Solutions des exercices

> Solution n°1 Exercice p. 7

Trouvez les commandes

La sortie de cette commande ressemble à l'extrait suivant :

Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2004-09-24 13:49 EDT

Interesting ports on localhost.localdomain (127.0.0.1):

(The 1653 ports scanned but not shown below are in state: closed)

PORT STATE SERVICE

22/tcp open ssh

25/tcp open smtp

> Solution n°2 Exercice p. 7

Trouvez les commandes

La sortie de cette commande ressemble à l'extrait suivant :

PORT STATE SERVICE

22/tcp open ssh

25/tcp open smtp

111/tcp open rpcbind

113/tcp open auth

631/tcp open ipp

834/tcp open unknown

2601/tcp open zebra

32774/tcp open sometimes-rpc11

> Solution n°3 Exercice p. 11

Limitation des attaques par déni de service - Complétez par les commandes

12
 Solutions des exercices

Limitation des attaques par déni de service

En raison de la nature même des messages électroniques, il est relativement facile pour un agresseur
déterminé de submerger le serveur de messages électroniques et d'entraîner ainsi un déni de service. En
donnant certaines limites aux directives suivantes dans /etc/mail/sendmail.mc, il est possible de limiter
l'efficacité de telles agressions.

confCONNECTION_RATE_THROTTLE — Le nombre de connexions que le serveur peut recevoir par

seconde. Par défaut, Sendmail ne limite pas le nombre de connexions. Si une limite est fixée et atteinte,
les connexions suivantes sont retardées.

confMAX_DAEMON_CHILDREN — Le nombre maximum de processus enfants pouvant être engendrés

par le serveur. Par défaut, Sendmail n'assigne pas de limite au nombre de processus enfants. Si une limite
est fixée et atteinte, les connexions suivantes sont retardées.

confMIN_FREE_BLOCKS — Le nombre minimum de blocs non-utilisés devant être disponibles pour

que le serveur puisse accepter du courrier. La valeur par défaut est de 100 blocs.

confMAX_HEADERS_LENGTH — La taille minimale acceptable (en octets) pour un en-tête de message.

confMAX_MESSAGE_SIZE — La taille maximale acceptable (en octets) pour tout message individuel.

13