Aliasing réseaux parasite persistant

Support Debian
#1

Bonjour à tous.
Je me permets de solliciter votre aide, je suis à court d’idée et de
solutions.
J’ai depuis plusieurs années un serveur dédié chez un hébergeur sur lequel
j’ai Debian Lenny upgradé en Jessie (j’ai upgradé au fur et à mesure des
années).

Mais voilà depuis plusieurs semaines, un aliasing réseau est apparu.
eth0:0 Link encap:Ethernet HWaddr 00:--:--:--:--:-- inet adr:192.5.5.213 Broadcast:0.0.0.0 Masque:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interruption:16 Mémoire:80400000-80420000

Cette interface a une IP qui ne correspond a rien de ce qui m’appartiens ni même a l’hébergeur que j’ai contacté par précaution (au cas ou ils auraient mis cela pour du monitoring ou autre)

Source: whois.arin.netIP Address: 192.5.5.213 Name: ISC-NET1 Handle: NET-192-5-4-0-1 Registration Date: 12/03/84 Range: 192.5.4.0-192.5.5.255 Org: Internet Systems Consortium, Inc. Org Handle: ISC-94-Z Address: 950 Charter Street City: Redwood City State/Province: CA Postal Code: 94063 Country: UNITED STATES

J’ai donc commencé par vérifier le trafique qu’il pouvait générer :
iptables -t filter -A OUTPUT -p tcp --source 192.5.5.213 -j LOG_DROP iptables -t filter -A OUTPUT -p udp --source 192.5.5.213 -j LOG_DROP iptables -t filter -A INPUT -p tcp --dst 192.5.5.213 -j LOG_DROP iptables -t filter -A INPUT -p udp --dst 192.5.5.213 -j LOG_DROP

j’ai ensuite vérifié mon fichier interfaces qui ne contiens aucun
aliasing, mais uniquement ma config :
auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 5.--.--.-- netmask 255.255.255.0 network 5.--.--.0 broadcast 5.--.--.255 gateway 5.--.--.---

J’ai donc soupçonné un script ou un deamon avec un fichier de config contenant un aliasing
grep -r 192.5.5.213 / grep -r eth0:0 /

Mais toujours rien. il me rester plus qu’un bon vieux :
ifconfig eth0:0 down
En cron toutes les heures pour le moment.

Merci d’avance à tous pour votre aide et vos idées

Cordialement

#2

Tu veux dire que l’alias revient spontanément après que tu l’as supprimé ?

Qu’affiche ip -4 addr show dev eth0 concernant cette adresse ?

Le serveur fait-il tourner un service qui pourrait manipuler la couche réseau comme un système de virtualisation ou d’isolation (QEMU/KVM, LXC, OpenVZ…), Avahi/Zeroconf, VPN… ?

#3

Bonjour Pascal,
Merci pour votre réponse.
Oui je vous firme que l’alias revient de lui-même.
Je vous confirme que j’ai un serveur VPN mais sous tun0 mais indépendant de
cet alias.

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet adr:192.168.2.1 P-t-P:192.168.2.2 Masque:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

De plus l’alias revient même si mon serveur VPN est stoppé

Résultat de ip -4 addr show dev eth0

4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 5.39.83.24/24 brd 5.39.83.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.5.5.213/32 scope global eth0:0 valid_lft forever preferred_lft forever

À ma connaissance je n’ai pas de zeroconf présent.

Concernant Avahi je possède bien la bibliothèque

libavahi-client3 / libavahi-common-data / libavahi-common3

Si vous avez un technique qui permet d’extraire cette information de manière plus précise, je suis preneur

Cordialement

#4

Non, je n’ai pas plus d’idées.

Les bibliothèques avahi sont passives et ne contiennent pas de démon. D’autre part avahi utilise la plage d’adresses “link local” 169.254.0.0/16.

Voir s’il y a quelque chose d’inconnu dans la liste des processus
ps -Af
et des socket réseau ouvertes en écoute.
netstat -nlp4

Le noyau peut avoir son propre client BOOTP/DHCP pour le boot réseau, mais cette option est désactivée dans le noyau Debian standard.

J’espère que ce n’est pas un signe que la machine a été compromise.

#5

Cela a été ma première déduction, mais j’ai passé tous mes
logs et mes systèmes de sécu au crible.

du Fail2ban, rootkit detector, portsentry, aux IP qui aurai
ne serait que réussi a obtenir une réponse du serveur.

Oui pas mal de log, car je suis souvent scan 2 jours de log
palucher ça donne le tournis.

Ayant que peut de service et de plus plus la plupart
uniquement accessible depuis le tunnel SSH. Très peu d’éléments sont accessibles
de l’extérieur.

Je doute sur la compromission de la machine, mais cela n’est
pas à proscrire.

Je suis quand même étonné que nous n’ayons pas moyen de
trouvé l’origine d’une action qui monterait cet alias.

Lorsque je le coupe, il y a forcément un script/service qui
lance une action de montage et cela doit bien être loggé quelque part.

Par contre voilà une info intéressante obtenue par le

netstat -nlp4
udp 0 0 192.5.5.213:123 0.0.0.0:* 1526/ntpd

L’arrêt du service NTP serveur a couper l’écoute de cet IP,
mais l’alias est toujours présent je vais donc le coupé est voir s’il remonte.

Merci Pascal pour votre aide.

Je vous tiens informé dès que j’ai plus d’infos.

Cordialement

#6

ntpd n’écoute que sur cette adresse ou bien il y a une ligne similaire avec l’adresse légitime du serveur ? Certains services comme BIND ouvrent des sockets différentes avec chaque adresse locale au lieu d’une seule socket avec l’adresse indéfinie 0.0.0.0 qui écoute sur n’importe quelle adresse locale.

Rien d’autres qui éveille l’attention ? Pas de port, protocole ou processus inconnu ?

PS : les règles iptables mentionnées dans le message initial ne traitent que les paquets TCP et UDP. C’est restrictif. Je ferais tourner tcpdump pour voir s’il y a du trafic entrant ou sortant avec cette adresse.
tcpdump -ni eth0 host 192.5.5.213

#7

Rien d’autres qui éveille l’attention ? Pas de port, protocole ou processus inconnu ?

Non tout les process et ports sont légitime sauf 2 port que je ne connait pas
udp 0 0 0.0.0.0:43220 0.0.0.0:* 26884/dhclient udp 0 0 127.0.0.1:921 0.0.0.0:* 1547/lwresd

Mais les services si, seulement les port ne sont pas les ports rattacher que je connais.

Excellente idée pour le dump j’ai totalement zappé.
tcpdump -nvi eth0 host 192.5.5.213 0 packets captured 7 packets received by filter 0 packets dropped by kernel

Est ceux malgré mon FW

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Par contre impossible d’obtenir les paquet eux même. J’ai regarder le manuel tcpdump je ne trouve pas pourquoi avec le -v je n’obtiens pas les paquets eux même.

#8

Que fabrique un client DHCP (dhclient) alors que l’interface réseau est configurée en statique ? pstree pourra peut-être dire par quoi il est lancé.

lwresd est le résolveur DNS léger de BIND.

#9

Bonjour Pascal,

j’ai désinstallé dhclient et kill le process. Plus de trace dans deamon log de sont activité.

Avant pstreene démontre aucune incohérence.

init─┬─apache2───7*[apache2]
     ├─cron
     ├─dbus-daemon
     ├─fail2ban-server───10*[{fail2ban-server}]
     ├─6*[getty]
     ├─irqbalance
     ├─lwresd───6*[{lwresd}]
     ├─mdadm
     ├─murmur.x86───{QProcessManager}
     ├─mysqld_safe───mysqld───16*[{mysqld}]
     ├─openvpn
     ├─perl
     ├─2*[portsentry]
     ├─proftpd
     ├─rsyslogd─┬─{in:imklog}
     │          ├─{in:imuxsock}
     │          └─{rs:main Q:Reg}
     ├─2*[sshd───sshd───bash───su───bash───tail]
     ├─sshd───sshd───bash───su───bash
     ├─sshd───sshd───bash───su───bash───pstree
     ├─sshd───sshd───sshd───bash
     ├─tmux───bash───tsdnsserver_lin───2*[{tsdnsserver_lin}]
     ├─ts3server_linux───24*[{ts3server_linux}]
     ├─udevd
     └─vnstatd
#10

Je n’ai pas dit que dhclient devait être désinstallé mais qu’il nétait pas censé tourner en configuration statique. Le but d’exécuter pstree n’était pas de trouver des incohérence mais quel processus avait lancé dhclient. Mais là, on ne voit pas de processus dhclient. C’est vraiment le résultat obtenu avant d’avoir tué dhclient ?

Je n’avais pas pensé aux messages laissés par dhclient dans les logs. Ils peuvent contenir des informations intéressantes. Qu’est-ce qu’ils disaient ?

J’oublie le plus important : est-ce que l’adresse parasite revient encore ?

#11

Bonjour Pascal et joyeux Noel,

J’ai désinstallé dhclients afin de dégagé la possibilité que ce soit lui qui génère cette alias.

Le pstree me semble a être fait après.

log daemon.log :

Dec 18 06:29:35 srv dhclient: DHCPREQUEST on eth0 to 10.16.101.135 port 67
Dec 18 06:29:35 srv dhclient: DHCPACK from 178.33.124.65
Dec 18 06:29:35 srv dhclient: bound to 5.39.83.24 – renewal in 287 seconds.
Dec 18 06:34:22 srv dhclient: DHCPREQUEST on eth0 to 10.16.101.135 port 67
Dec 18 06:34:22 srv dhclient: DHCPACK from 178.33.124.65
Dec 18 06:34:22 srv dhclient: bound to 5.39.83.24 – renewal in 266 seconds.
Dec 18 06:38:49 srv dhclient: DHCPREQUEST on eth0 to 10.16.101.135 port 67

L’alias persiste toujours a monté.

Cordialement

#12

Bonjour,
Depuis l’arrêt de mon service VPN pour faire une refonte de ce système en VPN overssh l’interface ne se monte apparemment plus.

Je ne peux pour le moment définir ci cela vient réellement de lui, mais je verrai lors du relance ment de ce VPN refait a neuf.

Merci de votre aide