Port 19 utilisé par SAMBA sur Fedora Core 6 [Résolu/Fermé]

Signaler
Messages postés
10
Date d'inscription
samedi 29 septembre 2012
Statut
Membre
Dernière intervention
14 janvier 2018
-
Messages postés
29519
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
27 janvier 2021
-
Bonjour,

Suite à des lenteurs sur mon serveur samba Version 3.0.23c-2,
supputant des problèmes réseau je fais un netstat -apn et

la ligne suivant apparais.

tcp 0 0 0.0.0.0:19 0.0.0.0:* LISTEN 15011/smbd -D

Quelqu'un à déjà entendu parler du port 19 ouvert par Samba ?



Merci d'avance.



3 réponses

Messages postés
29519
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
27 janvier 2021
7 017
Ça me paraît extrêmement louche. Les ports samba par défaut sont indiqués ici :
http://doc.ubuntu-fr.org/samba#ports_lies_au_partage_de_fichiers_par_les_protocoles_smb_et_cifs

Maintenant, il faudrait vérifier comment ton serveur samba est configuré, car après tout rien n'oblige à utiliser le port par défaut (du moment que le port qu'une application à la fois écoute sur un port donné).

Si tu t'es fait hacké rien n'empêche quelqu'un d'avoir appelé une backdoor smbd pour être "plus discret". Si tu regardes dans /etc/services, tu verras que normalement le port 19 sert à autre chose :
http://kb.prismmicrosys.com/evtpass/evtpages/PortNo_19_chartgen_ttytstsource_9421.asp

(mando@silk) (~) $ grep 19 /etc/services 
chargen         19/tcp          ttytst source
chargen         19/udp          ttytst source


La première chose que je ferais, c'est regarder où est placé smbd. Dans ton exemple on voit que le PID est 15011, donc tu dois pouvoir retrouver son chemin via la commande ps :

ps aux | grep 15011


Si tu vois que le chemin n'est pas du tout logique (par exemple /usr/local/...) alors que tu as installé samba via un paquet tu peux déjà te dire que ça va mal. En admettant que ce soit ce qui s'est passé, il n'a pas dû écraser le vrai samba, sinon ce service se serait mis à partir en vrille et tu t'en serais rendu compte plus rapidement.

Maintenant ce qu'il ne faut pas perdre de vue c'est que si tu t'es fait hacké et que le mec n'est pas trop stupide, il a également piraté ps, netstat, ls etc... pour masquer son activité avec un rootkit.
http://www.mistra.fr/tutoriel-linux-pirates-rootkit.html

Bonne chance
Messages postés
10
Date d'inscription
samedi 29 septembre 2012
Statut
Membre
Dernière intervention
14 janvier 2018
1
Bonjour, et merci pour ta réponse.

En effet je crains le pire,
Nombre de dossiers et commandes système semble ne pas fonctionner correctement.
Pour faire fonctionner le netstat correctement j'ai du upgrader la version des net-tools.
(j'utilise yum).
J'ai fais cela avant d'ouvrir cette discussion.

L'upgrade se plantais sur des problèmes de droits alors que j'étais root.
Les attributs des dossiers et fichiers ne permettaient pas les mise a jours.
(cpio ne pouvais pas accéder au fichiers systèmes).


Donc j'ai du commencer par modifier les attributs des fichier, pour lancer les upgrades.

Il vas me falloir vérifier complètement le système.
Merci pour les liens, je vais les exploiter.

Pour ce qui est du démon qui écoute sur le port 19, j'ai beau le killer, il reviens.

Je suis aller voir dans /proc/<PID>/statut, il m'a donnée le chemin du fichier et en effet ce n'est pas le fichier /usr./sbin/smbd qui est normalement le fichier lancé pour le service SMB.

mais un fichier situé dans /usr/bin et le nom de fichier est "smbd\ -D" ou -D n'est pas un parametre mais fais parti du non de fichier. Je pense bien que ça n'a rien à faire ici.

Je m'en vais nettoyer tout ça..
Merci mamiemando pour ton aide.
Messages postés
29519
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
27 janvier 2021
7 017
L'upgrade se plantait sur des problèmes de droits alors que j'étais root.
Les attributs des dossiers et fichiers ne permettaient pas les mise a jours.
(cpio ne pouvais pas accéder au fichiers systèmes).


À mon avis ça confirme le fait que tu t'es fait hacké. Quand tu as une erreur de droits en root, c'est
- soit que tu fais une manipulation sur un système de fichiers distant monté avec des droits restants (ce qui n'est clairement pas le cas lors d'une mise à jour),
- soit des fichiers dont les droits ont été bidouillés par exemple avec chattr (je suppose que c'est ce que tu as fait pour corriger les droits ?).

Tu peux vérifier les permissions affectés aux fichiers qui provoquent l'erreur en utilisant la commande lsattr. Si tu vois autre chose qu'une série de traits (par exemple les droits s, i, a), c'est probablement des binaires injectés par un rootkit et dont les droits ext3 ont été modifiés pour qu'ils ne se fassent pas dégager à la prochaine mise à jour.

Voir 3.6.2 ici pour plus de détails :
http://www.mistra.fr/tutoriel-linux-pirates-rootkit.html

Honnêtement je t'invite vivement à réinstaller ta machine si c'est simple (c'est le meilleur moyen d'être sûr de ne plus avoir de binaires corrompus), si c'est compliqué cf rootkit dans le lien précédent pour les remplacer par des binaires sains. En effet si tu t'es réellement fait hacker, tu ne peux plus avoir confiance dans les résultats affichés par les commandes que tu lances.

C'est d'ailleurs pour ça que dans le lien ci-dessus, tout est fait à partir d'un live CD (ainsi les commandes utilisées ne sont pas celles du système infecté). Mais bon a priori lancer chkrootkit est suffisant

Je suis allé voir dans /proc/<PID>/statut, il m'a donnée le chemin du fichier et en effet ce n'est pas le fichier /usr./sbin/smbd qui est normalement le fichier lancé pour le service SMB.

C'est probablement le programme qui permet au hacker de piloter ta machine d'une quelconque manière (ou de faire en sorte qu'elle ait un usage nocif ou non voulu). En regardant le contenu de ce pseudo fichier tu auras sans doute une meilleure idée du rôle réel de ce programme.

Juste au passage si tu t'es réellement fait hacker, quelques conseils :
- éviter tous les trucs qui utilisent une authentification en claire (par exemple telnet, rsh...) au profit de solutions chiffrées (ssh)
- privilégier des authentifications par clé (pour ssh) à des authentifications par mot de passe
- ne pas permettre les connexions (ssh typiquement) en root
- utiliser des mots de passe non triviaux (normalement passwd n'autorise que root à configurer des mots de passe triviaux)
- mettre à jour régulièrement sa distribution (un programme comporte parfois des bugs qui permettent à un hacker de le détourner de son rôle initial (exploit))
- et on pourrait en ajouter encore d'autres, par exemple si tu as un site PHP/mysql sur cette machine, s'assurer que le code ne permet pas de faire d'injections de code etc...

Bonne chance
Messages postés
10
Date d'inscription
samedi 29 septembre 2012
Statut
Membre
Dernière intervention
14 janvier 2018
1
Oui en effet j'ai joué du lsattr pour vérifier tout ça et du chattr pour pouvoir écraser les fichiers.

Comme tu dis il fraudais que je réinstalle le serveur.
Ce n'est pas si simple car ell est en production et qui plus est c'est une conf qui a été réalisée par un prestataire de service.

Je pense que je vais opter pour une examen minutieux de mon serveur en premier lieux,
puis reconfigurer les services sur un autre serveur en m'appuyant sur les fichiers de conf de celui-ci. et déplacer mes données lorsque les services seront ok.

Merci pour ton aide.
Messages postés
29519
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
27 janvier 2021
7 017
En tout cas ton serveur a tous les symptômes d'une machine hackée.

Vu que ta machine est en production, le mieux c'est de stopper le processus qui écoute sur le port 19 et lancer chkrootkit pour faire l'essentiel du message. C'est a priori suffisamment pour corriger les binaires essentiel.

Ensuite chose que tu peux faire c'est réinstaller l'ensemble des paquets et vérifier avec debsums que tout est clean (cf tutoriel précédent).

Après on peut raisonnablement espérer que la machine soit "saine", mais une réinstallation complète reste plus prudente.
Messages postés
10
Date d'inscription
samedi 29 septembre 2012
Statut
Membre
Dernière intervention
14 janvier 2018
1
Bonjour,


J'ai :

-Commencé par essayer de voir avec qui discuté la machine sur le port 19 (tcpdump) mais si le binaire du tcpdump est corrompus, je ne suis pas sur qu'il me "parle". donc je suis passé à la suite


- renommé le binaire du service exécute,
- killé le process, (Il ne remonte plus et le port n'est plus écouté.

Il me faut finir en installant le chkrootkit, et vérifier ou réinstaller mes paquets.

Merci.
Messages postés
29519
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
27 janvier 2021
7 017
Oui ou d'ailleurs tu pourrais commencer par chkrootkit si tu veux vraiment faire le tcpdump.
Messages postés
10
Date d'inscription
samedi 29 septembre 2012
Statut
Membre
Dernière intervention
14 janvier 2018
1
Bonjour,

J'ai installé rkhunter...
En effet, il y avais 3 rootkit, rien que ça....

J'ai viré tout ça (Le log fournit donne de bonnes indications concernant les fichiers impactés).
J'ai mis a jour certains packages, et, ais comparer les binaires avec ceux d'une autre machine saine (md5sum).
je pense que mon serveur est sain.


Par contre pas moyens de voir d'ou viennent ces rootkits.

Un grand merci à mamiemando.
Messages postés
29519
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
27 janvier 2021
7 017
Tu peux peut-être voir dans les log /var/log/auth.log par exemple mais le hacker a pu effacer les traces. Même principe avec les serveurs "sensibles" qui écoutent sur le réseau (apache etc...), qui peuvent être victimes d'une attaque par "injection" ou qui ont pu être cassé par un "exploit". Après ça ne sera pas forcément simple de le retrouver par où il est entré, et même si tu le sais, ce ne sera pas forcément simple de le retrouver dans les logs.

Bonne continuation.