Qnap ? Deadbolt est de retour ?

FX Cachem

Administreur
Membre du personnel
8 Décembre 2013
13 502
504
203
Paris
www.cachem.fr
Bonjour à tous,

Un message d'alerte pour vous informer que Deadbolt est de retour. Selon les informations récoltées sur les réseaux sociaux et le forum QNAP (US), il semblerait que la faille exploitée soit dans Photo Station (y compris ceux avec QTS 5.x). Si vous avec Photo Station sur votre NAS et qu'il est exposé sur Internet, dépêchez-vous de le désactiver ou de le couper d'Internet.

[edit] Mon article est en ligne...

Merci
 
Dernière édition:
Bonjour,

Je suis aussi victime de Dead Bolt alors que j'étais passé au travers.

Je sollicite votre aide car mon NAS contient beaucoup de données personnelles auxquelles je tiens...

J'ai :
1) déconnecté mon NAS d'internet
2) exécuté Malware Remover
3) mis à jour photo station
4) payé la rançon demandée 0.05 bitcoins
5) probleme : je ne parviens pas à trouver la clé de déchiffrement car le code 0P_RETURN n'est pas présent dans ma transaction (en utilisant le site internet blockchain explorer).

Savez vous comment et ou trouver ce code ?

Est ce génant d'avoir exécuté Malware Remover ? Je me demande si je pourrais toutefois effectuer le déchiffrement avec la clé (si je la trouve ...)

Je sollicite votre aide, car je suis assez désemparé ...

Par avance, merci et bon courage.

jckfun
 
Je suis un peu surpris du nb de personnes concernées . Ils serait intéressant de savoir si les concernés utilise les ports par défaut .
Pour ma part avec des ports personnalisés je passe à travers depuis pas mal de temps . Il est utile de rappeler que les applis natives comme photo station ; music station utilise le même port que QTS et à ma connaissance Qnap ne permet pas de dissociés le port des ces applis de QTS .
 
je ne suis plus seul :)

pour info :



la faille est comblé depuis samedi pour ceux qui n'ont pas mis a jour photostation ...

on répétera jamais assez n'exposez pas les ports ports standards ... et faire les transactions en HTTPS (tout le temps)
installez Qufirewall en bloquant les autres Pays
 
  • J'aime
Réactions: schwinny
Tous les ports par défaut doivent être changées ! En particulier le port HTTP 8080 qu permet l'acces a QTS.
Et le port 443 qui par défaut est le https de QTS . Voir ici
Je n'ai jamais compris pourquoi Qnap à fait ce choix :confused:
 
Passer par le reverse proxy ça aide un peu mais ça n’est pas une barrière infranchissable ?
Ça permet surtout de n’ouvrir qu’un minimum de ports, le 443 . Et de tout faire passer (toutes les applications) par ce port là.
Dans le cas de qnap si l’os est par défaut sur ce port ?
Ensuite il faut que le pare-feu soit aussi bien configuré.
Sur mon nas , je n’autorise que le port 443 , et qu’aux IP françaises.
(J'ai aussi un autre port pour la synchronisation Drive)
Ps : j’ai un synology ?

Pps : si je met en place RustDesk, je risque de ne pas avoir le choix que d’ouvrir quelques ports supplémentaires ? car ce service ne semble pas trop pouvoir passer par un seul port…
 
Salut à tous,
Et le port 443 qui par défaut est le https de QTS . Voir ici
Je n'ai jamais compris pourquoi Qnap à fait ce choix :confused:
D'autant qu'il me semble que LetsEncrypt a besoin lui aussi du 80 et du 443 si on force le https pour mettre à jour son certificat. Enfin, c'est en activant ces 2 ports sur mon NAS dans "Serveur Web" que les MaJ se font correctement. J'ai, bien sûr, changé le port de connexion à QTS.
 
je tourne depuis le debut sur 26589 en HTTPs (seul port ouvert) et jamais eut de problème pour créer et renouveler mon letsencrypt lié à mon nom myqnapcloud
 
je tourne depuis le debut sur 26589 en HTTPs (seul port ouvert) et jamais eut de problème pour créer et renouveler mon letsencrypt lié à mon nom myqnapcloud
La validation du certificat LE pour le nom de domaine qnap ne se ferait-elle pas via la méthode DNS ? Plutôt que HTTP qui elle nécessite les ports 80 et 443.
 
pas forcément, si tu changes les ports... 80 c'est pour le serveur Web intégré (si tu gère un site web sur ton NAS donc autre methode pour généré LE) cela n'a rien avoir avec le port de QTS
 
Ce matin, les logs QFireWall de mes 2 Nas TS-251A et TS-653D ont montrés une activité suspecte :
Pensez-vous que cela ait un lien avec l'épisode DeadBolt en cours ?
S'agit-il bien de tentatives d'accès rejetées par le firewall ?

TS-251A :
"Deny amount=1438",---,"Permission=Deny","Time=None","date=2022-09-05 07:19:01"
"Deny amount=958",---,"Permission=Deny","Time=None","date=2022-09-05 06:19:02"
"Deny amount=479",---,"Permission=Deny","Time=None","date=2022-09-05 05:19:02"
"Deny amount=3",---,"Permission=Deny","Time=None","date=2022-09-05 04:19:03"
"Deny amount=1",---,"Permission=Deny","Time=None","date=2022-09-05 01:07:02"

TS-653D :
"Deny amount=480",---,"Permission=Deny","Time=None","date=2022-09-05 07:19:01"
"Deny amount=961",---,"Permission=Deny","Time=None","date=2022-09-05 06:19:00"
"Deny amount=482",---,"Permission=Deny","Time=None","date=2022-09-05 05:19:00"
"Deny amount=2",---,"Permission=Deny","Time=None","date=2022-09-05 04:19:01"
"Deny amount=1",---,"Permission=Deny","Time=None","date=2022-09-05 01:11:00"

J'ai débranché immédiatement les Nas du Net, et vérifié les données.
Rien à signaler, et les Nas sont bien à jours des dernières MAJ.
D'habitude quand il y a un event QFireWall, le nombre rapporté est faible (1 ou 2).
J'applique la plupart des recommandations préconisées, sauf pour le moment les ports qui sont toujours par défauts.
 
Je pense que j'ai eu chaud et que j'ai déconnecté mes Nas avant que cela ne dégénère.
Je consultais les derniers articles de Cachem au petit déjeuner quand j'ai lu l'article sur DeadBolt et que j'ai décider de vérifier l'état de mes Nas.

Pour les ports, j'ai du mal, j'ai déjà fait des essais infructueux par le passé... plus rien ne marchait, donc j'avais laissé tomber.
je vais donc ré-étudier ce point (si vous avez un tuto simple à me conseiller ?) et ré-essayer en espérant moins galérer que la dernière fois.
 
  • J'aime
Réactions: FX Cachem