Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Requetes DNS et de connexions inattendues

3 réponses
Avatar
Thierry
Bonjour,

Environnment: serveurs d=C3=A9di=C3=A9s chez OVH, Centos 7.3, vRack entre l=
es serveurs, serveur DNS d=C3=A9di=C3=A9 pour les adresses locales uniqueme=
nt (pas de forward).
Les serveurs (applicatifs) sont install=C3=A9s via des repos RPM locaux (EP=
EL custo).

Le serveur DNS logue des demandes de r=C3=A9solution bizarre:
Apr 3 13:14:37 DNS_server named[1157]: client 172.16.0.X#53823 (34.172.177=
.61.in-addr.arpa): query (cache) '34.172.177.61.in-addr.arpa/PTR/IN' denied
Apr 3 13:14:37 DNS_server named[1157]: client 172.16.0.X#38604 (34.172.177=
.61.in-addr.arpa): query (cache) '34.172.177.61.in-addr.arpa/PTR/IN' denied
Les noms DNS =C3=A0 r=C3=A9soudre varient dans le temps, un nouveau couple =
de requete toute les ~30s.

Comment d=C3=A9terminer quel processus sur la machine 172.16.0.X emet ces r=
equetes ?

J'ai sur cette m=C3=AAme machine des tentatives de connexion vers l'exterie=
ur:
? root IP_PUBLIQUE:23-181.188.19.194:14824 =
0.000 0.012 KB/sec
L'IP et le port, exotique, change a chaque tentative de connexion.
L'IP ne correspond pas =C3=A0 une des tentatives de r=C3=A9solution DNS.
La encore comment connaitre le processus qui initie la connexion ?

3 réponses

Avatar
Gilbert VAISSIERE
Le 03/04/2017 à 16:50, Thierry a écrit :
Bonjour,
Environnment: serveurs dédiés chez OVH, Centos 7.3, vRack entre les serveurs, serveur DNS dédié pour les adresses locales uniquement (pas de forward).
Les serveurs (applicatifs) sont installés via des repos RPM locaux (EPEL custo).
Le serveur DNS logue des demandes de résolution bizarre:
Apr 3 13:14:37 DNS_server named[1157]: client 172.16.0.X#53823 (34.172.177..61.in-addr.arpa): query (cache) '34.172.177.61.in-addr.arpa/PTR/IN' denied
Apr 3 13:14:37 DNS_server named[1157]: client 172.16.0.X#38604 (34.172.177..61.in-addr.arpa): query (cache) '34.172.177.61.in-addr.arpa/PTR/IN' denied
Les noms DNS à résoudre varient dans le temps, un nouveau couple de requete toute les ~30s.

Résolution reverse d'une IP en Chine (selon ip-tracker) : généralement,
une résolution reverse fait suite à l'arrivée d'un paquet en provenance
de cette adresse.
Comment déterminer quel processus sur la machine 172.16.0.X emet ces requetes ?
J'ai sur cette même machine des tentatives de connexion vers l'exterieur:
? root IP_PUBLIQUE:23-181.188.19.194:14824 0.000 0.012 KB/sec
L'IP et le port, exotique, change a chaque tentative de connexion.
L'IP ne correspond pas à une des tentatives de résolution DNS.
La encore comment connaitre le processus qui initie la connexion ?

Apparemment, un retour de connexion telnet, comme si une connexion
telnet arrivait sur votre serveur de l'extérieur et si le serveur telnet
y répondait.
Dans l'exemple que vous donnez, l'IP provient de Trinidad and Tobago.
A première vue, dans ce cas, il ne s'agit pas d'un processus qui initie
une connexion sortante, mais du serveur telnet qui répond à une
connexion entrante.
Les deux questions semblent liées.
Vérifications à faire :
- quels sont les ports à l'écoute sur votre serveur ?
- quels sont les accès entrants autorisés ?
- qu'est-ce qui implémente le filtrage ?
- le filtrage est-il efficace ?
- n'y aurait-il pas un autre point d'entrée que ceux auxquels vous pensez ?
Une capture réseau devrait vous permettre d'y voir plus clair : capturez
le trafic telnet (23/TCP) et pour l'IP pour laquelle vous avez des
résolutions DNS reverse (tcp port 23 or host 61.177.172.34).
Cdlt.
G.V.
Avatar
Thierry
Résolution reverse d'une IP en Chine (selon ip-tracker) : gén éralement,
une résolution reverse fait suite à l'arrivée d'un paquet en provenance
de cette adresse.

Bonjour,
Merci pour cette réponse rapide.
Effectivement ce sont des requetes reverse DNS des tentatives de connection .
Seul SSH écoute sur l'interface publique et est autorisé par fire walld.
Ce qui m'étonne c'est la tentative sur le port telnet...
Au final cette interface réseau sera down, mon inquiétude provena nt principalement des requetes DNS qui laissait a penser qu'un composant était malicieux et essayait de sortir du réseau pour faire une ba ckdoor.
Comment déterminer quel processus sur la machine 172.16.0.X emet c es requetes ?
J'ai sur cette même machine des tentatives de connexion vers l'ext erieur:
? root IP_PUBLIQUE:23-181.188.19.194:14824 0.000 0.012 KB/sec
L'IP et le port, exotique, change a chaque tentative de connexion.
L'IP ne correspond pas à une des tentatives de résolution DNS .
La encore comment connaitre le processus qui initie la connexion ?

Apparemment, un retour de connexion telnet, comme si une connexion
telnet arrivait sur votre serveur de l'extérieur et si le serveur te lnet
y répondait.
Dans l'exemple que vous donnez, l'IP provient de Trinidad and Tobago.
A première vue, dans ce cas, il ne s'agit pas d'un processus qui ini tie
une connexion sortante, mais du serveur telnet qui répond à une
connexion entrante.
Les deux questions semblent liées.
Vérifications à faire :
- quels sont les ports à l'écoute sur votre serveur ?
- quels sont les accès entrants autorisés ?
- qu'est-ce qui implémente le filtrage ?
- le filtrage est-il efficace ?
- n'y aurait-il pas un autre point d'entrée que ceux auxquels vous p ensez ?
Une capture réseau devrait vous permettre d'y voir plus clair : capt urez
le trafic telnet (23/TCP) et pour l'IP pour laquelle vous avez des
résolutions DNS reverse (tcp port 23 or host 61.177.172.34).
Cdlt.
G.V.
Avatar
Gilbert VAISSIERE
Le 04/04/2017 à 10:46, Thierry a écrit :
Résolution reverse d'une IP en Chine (selon ip-tracker) : généralement,
une résolution reverse fait suite à l'arrivée d'un paquet en provenance
de cette adresse.

Bonjour,
Merci pour cette réponse rapide.
Effectivement ce sont des requetes reverse DNS des tentatives de connection..
Seul SSH écoute sur l'interface publique et est autorisé par firewalld.

Une capture des demandes de connexions SSH, sur les diverses interfaces,
et des requêtes DNS, ou le rapprochement des journaux correspondants
vous permettra de confirmer, ou pas, si les reverse DNS sont bien en
réponse à des connexions SSH.
Ce qui m'étonne c'est la tentative sur le port telnet...

Peut-être une réponse à une connexion entrante arrivant sur une autre
interface ?
Une capture réseau sur les diverses interfaces, restreinte aux paquets
SYN sur le port 23/TCP devrait permettre de comprendre ce qui se passe.
Au final cette interface réseau sera down, mon inquiétude provenant principalement des requetes DNS qui laissait a penser qu'un composant était malicieux et essayait de sortir du réseau pour faire une backdoor.

Ce n'est pas mon hypothèse privilégiée, mais, si ce à quoi j'ai pensé en
premier n'est pas confirmé, ce serait à approfondir.
Cdlt
G.V.