Requetes DNS et de connexions inattendues

Le
Thierry
Bonjour,

Environnment: serveurs dédiés chez OVH, Centos 7.3, vRack entre l=
es serveurs, serveur DNS dédié pour les adresses locales uniqueme=
nt (pas de forward).
Les serveurs (applicatifs) sont installés via des repos RPM locaux (EP=
EL 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.

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

J'ai sur cette même 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 à une des tentatives de résolution DNS.
La encore comment connaitre le processus qui initie la connexion ?
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Gilbert VAISSIERE
Le #26431216
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.
Thierry
Le #26431231
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.
Gilbert VAISSIERE
Le #26431246
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.
Publicité
Poster une réponse
Anonyme