> Tech > Recherche DNS inverse

Recherche DNS inverse

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Des API de type Unix fournissent l'accès aux API de sockets nécessaires à  UPDHTTPLOG pour effectuer des recherches DNS inverses. Au centre du programme RPG IV UPDHTTPLGR se trouvent les API gethostbyaddr et inet_addr. L'API gethostbyaddr émet une requête pour une recherche DNS inverse, et inet_addr traduit une

Recherche DNS inverse

adresse IP décimale de type nnn.nnn.nnn.nnn en adresse Internet
binaire sur 32 bits utilisée dans l’appel à  gethostbyaddr. Les prototypes de
ces API sont présentés dans la section A de la figure 5. J’ai déclaré les
procédures GetHostByAddr et XlateDotTo32, et les ai fait correspondre à  leur
nom externe respectif à  l’aide du mot clé ExtProc.

           
GetHostByAddr admet comme paramètres :



  • un
    pointeur de champ contenant l’adresse Internet 32 bits sur laquelle la
    recherche DNS inverse sera effectuée

  • la
    longueur de l’adresse

  • le
    type du domaine de l’adresse (qui est toujours 2)

GetHostByAddr
renvoie un pointeur vers une structure qui contient les informations récupérées
sur le système hôte. Cette structure (section B) contient :



  • un
    pointeur de champ contenant le nom du système hôte

  • un
    pointeur de tableau de noms en alternance pour l’hôte

  • le
    type d’adresse de l’hôte

  • la
    longueur de l’adresse

  • un
    pointeur de tableau d’adresses réseau pour le système hôte

Notez
que la structure ne contient qu’un champ pour le nom du système hôte. Les
autres éléments de la structure ne sont pas indispensables, aussi je ne définis
que des substituts de réservation les concernant. Si GetHostByAddr ne parvient
pas à  trouver une entrée, il renvoie un pointeur nul.

           
XlateDotTo32 admet un seul paramètre, l’adresse IP décimale de type
nnn.nnn.nnn.nnn, et renvoie une adresse Internet sur 32 bits à  utiliser dans la
procédure GetHostByAddr. Si l’appel à  la procédure échoue, la valeur retournée
est -1. La définition du champ retourné par XlateDotTo32 est également donnée
dans la section B.

           
Les cartes C de la routine principale sont simples. Le programme lit le
fichier de log système et, pour les enregistrements n’ayant pas précédemment
bénéficié d’une recherche réalisée avec succès et qui possèdent une
adresse IP valide, tente une recherche DNS inverse.

           
La sous-routine RtvHostName réalise la plus grosse partie du programme.
Dans la section C, elle vérifie d’abord si l’adresse IP de l’enregistrement de
log système courant a déjà  été enregistré. Si l’adresse IP a été
enregistrée et ne se trouve pas dans le cas d’erreur (D), RtvHostName extrait
le nom de l’hôte de l’enregistrement de log défini par l’utilisateur. Le
programme n’invoque l’API de recherche DNS inverse que lorsqu’il ne peut pas
trouver l’adresse IP dans le fichier de log défini par l’utilisateur. Ceci
minimise la pénalisation des performances concernant les recherches DNS car
l’adresse IP ne doit être traduite qu’une fois.

           
Lorsque l’adresse IP doit être traduite (E), RtvHostName octroie par défaut
au nom de l’hôte la valeur spéciale *ERROR pour le cas où la routine de
traduction de l’adresse IP ou le processus de recherche DNS inverse échoue. Il
traduit ensuite l’adresse IP décimale de type nnn.nnn.nnn.nnn en une adresse
Internet sur 32 bits. Lorsque cette traduction est effectuée avec succès, le
programme entreprend d’extraire le nom du système hôte en réalisant une
recherche DNS inverse (appel de l’API GetHostByAddr). Lorsque cette recherche réussie,
le pointeur (HostNamePtr) vers le champ du nom de l’hôte (HostName) est réglé
sur la valeur du pointeur retournée par l’API. Pour finir, le nom de l’hôte
est extrait en utilisant %Str. Cette fonction intégrée est indispensable car
le champ HostName est une chaîne de caractères terminée par un caractère
nul.

à€
l’exception d’une confusion possible entre les pointeurs et les chaînes de
caractères terminées par une valeur nulle, le programme est assez simple. En
fait, je suis surpris de voir combien il est facile d’effectuer une recherche
DNS inverse en utilisant le RPG.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010