Asustor Deadbolt le retour ?

S

shaks2022

Maître Jedi
22 Février 2022
586
168
113
bonjour
je me fais juste le messager :

L'auteur de la dernière intervention à ce jour pretend avoir appliqué tous les conseils d'Asustor....Pas rassurant cette histoire ....

[edit .] Du coup, j'en profite pour rappeler la petite check-liste du moment :
- Firmware installé : 4.0.5.RTU2
- Ezconnect desactivé
- Port ADM changé
- Port ssh changé
- SSH désactivé
- user admin désactivé, et vous avez créé d'un autre compte de votre choix pour administrer le NAS
- Autoblacklist activé + settings "durs" => 3 fois en 10mn = 1 semaine de blocage + TOUS les protocoles checkés.
- Des sauvegardes , des sauvegardes, des sauvegardes...
 
Dernière édition:
  • J'aime
Réactions: Dami1
après primo - investigation, les clients qui auraient été impactés n'ont pas changé les ports 8000 et 8001 par défaut malgré la pop up les newsletters etc etc + entre autres (liste non exhaustive : pour d'autres pas de sauvegarde, pas de liste auto activée, connexion en http sur le Wan etc. etc.

Enfin, je te remercie pour ces rappels
 
  • J'aime
Réactions: shaks2022
Bonjour,

Je viens d'avoir le message en rentrant de week-end, j'ai le même problème que la personne qui se trouve sur ton lien, par contre impossible de me connecter dessus en local ou par le réseau et le fait de remettre les paramètres d'usine ne marche pas.

Il m'est impossible d'appliquer la procédure Asus car impossible de me rendre sur le NAS.

A part changer les disque il y a pas d'autre moyen ?
 
bonjour
éteignez votre NAS pour le moment. Ne le laissez surtout pas allumé sinon Deadbolt va continuer à chiffrer (crypter) les fichiers
puis attendez de nos nouvelles
cordialement
 
Ok pas de soucis, âpres j'avais des disques en RAB donc j'ai crée une nouvelle configuration en attendant et je garde les disque crypté de cotée.

Cdt.
 
En tout cas je confirme que ceux qui ont respecté les consignes qui s'affichent (cf copie d'écran ci-dessous) au lancement d'ADM ont été épargnés. Les escrocs ne peuvent pas attaquer des NAS dont les ports http et https par défaut ont été changés.
La quasi-totalité, pour ne pas dire la totalité, des possesseurs de NAS affectés n'ont aucune sauvegarde, aucun snapshot...
Nous ne savons plus quoi faire en termes de pédagogie/ bonnes pratiques.
ADM popup fr.png
 
  • J'aime
Réactions: nedrack
Dami1 a dit:
En tout cas je confirme que ceux qui ont respecté les consignes qui s'affichent (cf copie d'écran ci-dessous) au lancement d'ADM ont été épargnés. Les escrocs ne peuvent pas attaquer des NAS dont les ports http et https par défaut ont été changés.
La quasi-totalité, pour ne pas dire la totalité, des possesseurs de NAS affectés n'ont aucune sauvegarde, aucun snapshot...
Nous ne savons plus quoi faire en termes de pédagogie/ bonnes pratiques.
Voir la pièce jointe 5656
Cliquez pour agrandir...
bonjour
A part appliquer la même stratégie que les fournisseurs de box et modem ( port et mot de passe fort générés aléatoirement et collés sur ou mieux.... ..dans le nas lors de la fabrication ), je vois pas non plus ce que vous pouvez faire de plus .
 
Bonjour, les attaques DeadBolt étant passée par MyAsustor la première fois, en essayant de me connecter à EzConnect ce matin, je me suis aperçu que la connexion à EzConnect n'est plus HTTPS, impossible de passer en HTTPS en accès au site qui bascule automatiquement en HTTP.
Normal ?
Sinon, ports changés, SFTP, SSh etc. desactivés, identification à deux facteurs en place et backups en place.
 
Je fais les maj régulièrement et pourtant j'ai été attaqué également.
J'avais désactivé les services inutiles et activé adm defender
Je ne sais pas changer les ports ni à quoi ça correspond donc je n'ai pas pu le faire la dernière fois,bref...

Cette fois -ci mon nas fonctionne mais je n'ai aucun accès (message de deadbolt qui semble m'empecher d'y accéder).
et la quasi totalité de mes données sont en .deadbolt
Savez vous comment accéder à mon interface nas pour essayer de trafiquer au hasard ces ports?
Et la récupération de mes fichiers, vous penser que c'est décryptable?

merci!

EDIT: je précise que je ne m'en rends compte que maintenant, aucun email d'asustor pur prévenir de l'attaque contrairement à la dernière fois, très dommage.
 
Dernière édition:
J'ai réussi a accéder à adm uniquement via l'app et changer les ports au hasard.
Mais ça ne va pas régler mon problème de fichiers cryptés.

Si je réinitialise les 16to du nas complet, aucun risque que l'infection soit resté?
 
Dami1 a dit:
après primo - investigation, les clients qui auraient été impactés n'ont pas changé les ports 8000 et 8001 par défaut malgré la pop up les newsletters etc etc + entre autres (liste non exhaustive : pour d'autres pas de sauvegarde, pas de liste auto activée, connexion en http sur le Wan etc. etc.

Enfin, je te remercie pour ces rappels
Cliquez pour agrandir...
Bonjour,
Pour les certificats, le port 80/443 est indispensable et la signature ASUSTOR sur les requêtes HTTP/HTTPS sont problématiques.

Ensuite je suggères personnellement, un Reverse Proxy (voir tutorial que j'ai fais dans ce sens) pour protéger son NAS.

Un attaquant envoie toujours quelque requête pour obtenir toutes les informations (Version, ports, Matériel)
Ensuite il attaque et je trouves que plusieurs facteur sont mal sécurisés.
 
Alexsustor a dit:
J'ai réussi a accéder à adm uniquement via l'app et changer les ports au hasard.
Mais ça ne va pas régler mon problème de fichiers cryptés.

Si je réinitialise les 16to du nas complet, aucun risque que l'infection soit resté?
Cliquez pour agrandir...
si tu as suivi la doc, le NAS n'est plus affecté mais ce qui est chiffré le reste
 
pour moi pas d'attaque. Port http et https changé, ezconnect pas démarré ni ez router.
Le meilleur moyen de ne pas faire entrer, ce n'est pas de fermer les portes, c'est qu'il n'y ait pas de porte :)
 
  • J'aime
Réactions: Olivier71 et nedrack
Bonjour,

Pour moi la vrai faille est le protocole Upnp des opérateurs qui l'active par défaut . Sa aide pas .
 
On pourrait envisager un accès en 2 facteurs au NAS, ce qui réglerait les problèmes de brut force sur l'admin web.
Pour la partie terminal/ssh, interdire les connexions en user/mdp et forcer par clés
Ce sont des attaques et soucis très (pour ne pas dire de plus en plus) répandus
 
Bonjour,

Ne pas utiliser l'authentification par clé SSH, je l'ai déjà indiqué que c'est un problème de sécurité majeur .
Ensuite j'utilise le protocole VPN pour la gestion de l'infrastructure, et pour les protocoles accessibles depuis l'extérieur, j'utilise un Reverse Proxy pour qu'il traite les demandes .
 
Dernière édition:
Drthrax74 a dit:
Bonjour,

L'authentification par clé SSH, je l'ai déjà indiqué que c'est un problème de sécurité majeur .
Ensuite j'utilise le protocole VPN pour la gestion de l'infrastructure, et pour les protocoles accessibles depuis l'extérieur, j'utilise un Reverse Proxy pour qu'il traite les demandes .
Cliquez pour agrandir...
Bonsoir,

Merci pour le retour.
Par curiosité, en quoi les clés ssh sont une faille de sécu ?
Un reverse proxy est clairement intéressant (avec un notables, 0 soucis) mais pas à la portée de tous...

Merci
 
  • J'aime
Réactions: Drthrax74
Kojack a dit:
Bonsoir,

Merci pour le retour.
Par curiosité, en quoi les clés ssh sont une faille de sécu ?
Un reverse proxy est clairement intéressant (avec un notables, 0 soucis) mais pas à la portée de tous...

Merci
Cliquez pour agrandir...
Bonjour,

Petite erreur sur la tournure de ma phrase, c'est de ne pas utiliser de clé que sa pose problème et pas l'inverse .

Merci d'avoir remarquer ceci :)
 
Vous devez vous connecter ou vous enregistrer pour répondre ici.
Haut Bas
Retour