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
Sécuriser Microsoft 365 avec une approche Zero-Trust
Découvrez comment renforcer la cyber-résilience de Microsoft 365 grâce à une approche Zero-Trust, une administration granulaire et une automatisation avancée. La technologie Virtual Tenant de CoreView permet de sécuriser et simplifier la gestion des environnements complexes, tout en complétant vos stratégies IAM, y compris dans les secteurs réglementés.
Les articles les plus consultés
- Afficher les icônes cachées dans la barre de notification
- Cybersécurité Active Directory et les attaques de nouvelle génération
- N° 2 : Il faut supporter des langues multiples dans SharePoint Portal Server
- IBM i célèbre ses 25 ans
- Partager vos images, vidéos, musique et imprimante avec le Groupe résidentiel
Les plus consultés sur iTPro.fr
- Mythos révèle les limites d’un Zero Trust centré sur le réseau
- Faire évoluer la souveraineté des données du statut d’ambition politique à son application opérationnelle
- Mythos et modèles-frontières : quel avenir pour la cybersécurité en France et en Europe face à l’IA ?
- IA agentique : des investissements massifs freinés par des données insuffisamment préparées
Articles les + lus
Analyse Patch Tuesday Mai 2026
Les coûts cachés des merge requests générées par l’IA
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Avril 2026
À la une de la chaîne Tech
- Analyse Patch Tuesday Mai 2026
- Les coûts cachés des merge requests générées par l’IA
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Avril 2026
