attaque permanente sur mon NAS depuis MAJ DSM 7.2-64570 Update 1

[JDG]

Bonjour à tous,

Tout allait bien jusqu'a la MAJ DSM 7.2-64570 Update 1. Depuis une dizaine d'attaques tous les jours sur mon NAS, QuickConnect désactivé, IP France seulement acceptée?
Est-il possible de revenir à la version précédente sachant que je suis a distance de mon NAS.

Cordialement

[bagou91]

Bonjour,

Non pas possible.

Mais pour moi, c'est plus une coïncidence les attaques...

Sur quel port les attaques ? 

[JDG]

malheureusement 5000 et 5001 car ne suis pas chez moi et je ne peux changer a distance sans prendre de risque.

[bagou91]

Ba voilà...

C'est malin de laisser les ports par défaut.

C'est pourtant simple de choisir un autre port 🙂

[JDG]

😡 je sais erreur de débutant

[MilesTEG1]

Il est aussi préférable de ne pas ouvrir ces ports dsm sur la box/routeur .

soit passer par le reverse proxy sur le port 443 donc via le nom de domaine.

soit en passant par le serveur vpn du nas ou de la box/routeur.

[StefDS415]

J'ai fait la MAJ DSM 7.2-64570 Update 1 le 29 juin et idem, immédiatement après une vingtaine d'attaques par jour alors qu'avant il ne se passait absolument rien... Oui coïncidence sûrement, mais tout de même très bizarre.

[bagou91]

@JDG @StefDS415 vous avez relevez les IP sources des attaques ?

Regardez à qui elles appartiennent.

 

hypothèse :

Serveurs Synology qui tentent de communiquer avec des nas en dsm 7.2....

[StefDS415]

Alors de mon côté, au fur et à mesure que les jours passaient, les IP provenaient d'une trentaine de pays différents. J'ai commencé par bloquer les pays les uns après les autres, mais j'ai vite compris que c'était inutile de continuer ainsi et j'ai tout fermé par défaut, en laissant juste ouvert ce dont j'ai besoin.

Origine des attaques: Bolivie, Brésil, Biélorussie, Chine, Indonésie, Inde, Iran, Kazakhstan, Mexique, Pérou, Les Philippines, Serbie,Turquie, Venezuela, Vietnam, Chili, Algérie, Equateur, Egypte, Gambie, Corée du Nord, Corée du Sud, Lettonie, Namibie, Pays Bas, Roumanie, Fédération de Russie, Singapour, Taiwan, Ukraine, Canada, Allemagne, Guatemala, Hong Kong, Irak, Jordanie, Cambodge, Pakistan, Portugal, Arabie Saoudite, Thailande, Ouganda, Etats-Unis d’Amérique, Bangladesh, Syrie, Japon, Afrique du Sud, Tunisie, Côte d’Ivoire, Bosnie et Herzégovine.

Modifié le 27 juillet 2023 par StefDS415

[MilesTEG1]

Il y a 1 heure, StefDS415 a dit :

j'ai tout fermé par défaut, en laissant juste ouvert ce dont j'ai besoin.

C’est pourtant ce qui est dit dans le tuto sécurisation du nas …

[StefDS415]

il y a 22 minutes, MilesTEG1 a dit :

C’est pourtant ce qui est dit dans le tuto sécurisation du nas …

Oui tout à fait, ce que je n'ai pas appliqué tout de suite... Mea Culpa.

Modifié le 27 juillet 2023 par StefDS415

[Audio]

Bonjour,

Je reviens sur le post de @StefDS415 et les attaques venues de multiples pays. J'expérimente le même genre d'attaque depuis le 2 septembre sur un de mes DS 920+ en DSM 7.2-64570 Update 1.

Les attaques en force brute visent MailPlus Server avec des noms d'utilisateurs génériques du style webmaster@mondomaine.xx, info@mondomaine.xx, contact@mondomaine.xx ou encore mailer-daemon@mondomaine.xx. Elles sont visiblement portées au travers des 4 ports laissés ouverts pour MailPlus Server sur le routeur et redirigés vers le NAS hébergeant MailPlus Server.

J'utilise le pare-feu de mon routeur RT 2600 AC pour bloquer autant que possible ces attaques en bloquant les pays les plus actifs comme la Chine, la Russie ou le Brésil, mais il y en a pas mal d'autres, le dernier en date est l'Italie (27 pays blacklistés). Je répertorie toutes les IPs et regarde leur statut sur Abuse IPDB, elles sont toutes reportées comme attaquant (plus de 570 attaques depuis le 2 septembre). L'avantage du pare-feu dans SRM est de comptabiliser les attaques sur les règles établies, ce que ne fait pas le pare-feu dans DSM (ce qui serait bien pratique).

Je ne peux pas non plus blacklister toute la planète et me demande s'il existerait un moyen pour rejeter les attaques à partir des noms d'utilisateurs génériques utilisés qui sont somme toute assez pas si nombreux.

Merci pour vos suggestions si vous en avez.

Audio

[PiwiLAbruti]

il y a 40 minutes, Audio a dit :

Elles sont visiblement portées au travers des 4 ports laissés ouverts pour MailPlus Server sur le routeur et redirigés vers le NAS hébergeant MailPlus Server.

Seul le port tcp/25 de MailPlus Server nécessite d'être ouvert à tout internet.

Les autres ports nécessaires aux clients, à savoir :

• tcp/993 (IMAP),
• tcp/587 (SMTPS),
• et éventuellement tcp/995 (POP) si utilisé,

doivent être restreints au pays depuis lesquels les mails sont consultés.

Comme le port tcp/25 est toujours exposé, il est nécessaire de bien paramétrer le Blocage automatique pour bloquer les tentatives de connexion abusives.

RetEx : J'avais constaté le même comportement il y a quelques semaines. Les tentatives de connexion étaient émises par un petit botnet (862 adresses IP) mais suffisamment gros pour que les blocages ne soient effectifs que tardivement. J'avais donc activé temporairement le blocage au bout d'une seule tentative échoué, ce qui en quelques jours a suffit à bloquer l'ensemble des adresses IP du botnet. N'observant donc plus aucune tentative dans les logs de MailPlus Server, j'avais rétabli les paramètres de blocage initiaux.

il y a une heure, Audio a dit :

J'utilise le pare-feu de mon routeur RT 2600 AC pour bloquer autant que possible ces attaques en bloquant les pays les plus actifs comme la Chine, la Russie ou le Brésil, mais il y en a pas mal d'autres, le dernier en date est l'Italie (27 pays blacklistés).

En tenant compte des explications précédentes, le blocage de pays est totalement inutile.

[Audio]

Merci pour la recette @PiwiLAbruti

J'ai appliqué tout ça, je reviendrais sur le forum pour donner les résultats.

Une autre question: dans quel log de MailPlus Server et à quel emplacement peut-on avoir l'historique des tentatives de connexion ?

Merci

[PiwiLAbruti]

On pouvait le voir facilement dans les logs de sécurité de MailPlus Server, mais Synology a modifié la gestion et l'affichage des logs lors de la dernière mise à jour publiée le 24 août dernier :

Citation

1. Added transaction logs to the Auditing page, providing email information, delivery history, and security issues.
2. Transaction logs are rotated every 30 days. If needed, configure log archiving on the Log Management tab.
3. Mail logs and security logs from the last 30 days will be automatically converted to transaction logs during the package update. If needed, export logs older than 30 days.
4. Supports exporting transaction logs with customizable settings, such as file type, number of logs, and data columns.
5. Centralized administration logs into a single tab on the Auditing page to record setting changes made by administrators.

Merci Synology d'avoir tronqué les logs à 30 jours… 🤦‍♂️

Les blocages sont visibles dans le paquet Centre de journaux > Journaux > Actuel > Sélectionner Connexion au lieu de Général dans la liste déroulante.

[Audio]

Merci @PiwiLAbruti,

Effectivement les logs sont maintenant tronqués, mais je garde la trace des connexions échouées depuis longtemps: j'ai programmé une notification par mail lorsqu'il y a un journal émis avec les mots clés "authorization" et "failure". J'archive ces mails sur mon client mail.

Ce que je regrette c'est qu'il n'y a que l'IP et le User ID, pas le port. Maintenant que seul le port 25 est ouvert à tout vent pour MailPlus Server je me doute que les attaques viennent sur ce port. Depuis hier j'ai déjà 23 IPs blacklistées.

Bonne journée

[alan.dub]

@PiwiLAbruti, donc toi tu préconises de limiter les ports smtp (SSL 465 / TLS 587) et imap (SSL / TLS 993) à la France ?

Et laisser le port smtp 25 ouvert au monde entier ?

Pour l’instant chez moi tous les ports sont ouverts au monde entier. 
Mais comme je ne quitte la France que très rarement… 

Modifié le 11 octobre 2023 par alan.dub

[CMDC]

Le 02/10/2023 à 5:40 PM, PiwiLAbruti a dit :

 

Les autres ports nécessaires aux clients, à savoir :

• tcp/993 (IMAP),
• tcp/587 (SMTPS),
• et éventuellement tcp/995 (POP) si utilisé,

 

Plutôt préférer le port tcp/465 qui utilise SSL , un cryptage réputé plus sécurisé, plutôt que tcp /587 pour SMTPS

il y a 33 minutes, alan.dub a dit :

donc toi tu préconises de limiter les ports smtp (SSL 465 / TLS 587) et imap (SSL / TLS 993) à la France ?

Cela dépend si tu voyages ou non; chez c'est ouvert au monde entier car je n'utilise pas forcément un VPN pour lire ou envoyer des mails avec ma phablette .

Si, à l'étranger tu utilises un VPN situé en France, alors oui, éventuellement tu peux restreindre les accès .

Le 02/10/2023 à 4:32 PM, Audio a dit :

Je ne peux pas non plus blacklister toute la planète et me demande s'il existerait un moyen pour rejeter les attaques à partir des noms d'utilisateurs génériques utilisés qui sont somme toute assez pas si nombreux.

Il existe ICI une liste d'IP que tu peux bloquer définitivement pour ton plus grand bien 

[PiwiLAbruti]

@alan.dub Oui, c'est ce que je préconise car ces ports (465, 587, 993, et 995) ne sont utilisés qu'entre le client et le serveur (MUA). Le port tcp/25 est utilisé par les serveurs SMTP pour communiquer entre eux (MTA).

il y a 18 minutes, CMDC83 a dit :

Plutôt préférer le port tcp/465 qui utilise SSL , un cryptage réputé plus sécurisé, plutôt que tcp /587 pour SMTPS

Tu as la source de cette information ? Le port tcp/587 utilise TLS par défaut, c'est moins sécurisé que SSL ?

il y a 20 minutes, CMDC83 a dit :

Il existe ICI une liste d'IP que tu peux bloquer définitivement pour ton plus grand bien

C'est exactement ce qu'il ne faut pas faire car c'est totalement contre-productif.

[alan.dub]

Merci Piwilabruti pour ces info 👍

Modifié le 11 octobre 2023 par alan.dub

[Audio]

Bonjour,

Merci @CMDC83 pour la liste d'IP, j'ai regardé le contenu du site https://lists.blocklist.de, il y a effectivement pas mal de listes. Il faudrait cependant mettre à jour en quotidiennement, ce qui me parait assez contraignant.

@PiwiLAbruti

il y a 17 minutes, PiwiLAbruti a dit :

C'est exactement ce qu'il ne faut pas faire car c'est totalement contre-productif.

Je ne comprends pas très bien pourquoi c'est improductif.

Pour ma part je n'ai laissé que le port 25 ouvert à toute la planète et restreint les ports MUA à la France et à 2 pays où il m'arrive de voyager. Depuis j'ai eu nettement moins d'attaques (réduction de 75% environ), mais il y en a toujours, je bloque systématiquement les IP avec tentative de connexion échouée.

A suivre!

Audio

[PiwiLAbruti]

il y a 43 minutes, Audio a dit :

Je ne comprends pas très bien pourquoi c'est improductif.

Les listes d'adresses IP suspectes sont excessivement longues et impliquent que ton NAS va systématiquement vérifier chaque adresse IP source avec toutes celles renseignées, ce qui demande des ressources. En plus, la fréquence à laquelle peuvent bouger ces listes font qu'elles sont inexploitables.

Le blocage IP automatique du NAS est suffisant pour bloquer les tentatives d'authentification échouées à condition de bien le paramétrer.

[CMDC]

il y a 17 minutes, PiwiLAbruti a dit :

Les listes d'adresses IP suspectes sont excessivement longues et impliquent que ton NAS va systématiquement vérifier chaque adresse IP source avec toutes celles renseignées, ce qui demande des ressources.

J'utilise un DS216j comme serveur mail et les IP sont stockées dans un Base de Données (SQLITE de mémoire) et il est loin d'être à genoux 

il y a 19 minutes, PiwiLAbruti a dit :

En plus, la fréquence à laquelle peuvent bouger ces listes font qu'elles sont inexploitables.

Toutafé, mais au moins c'est déjà une bonne base ! J'ai testé avec et sans et franchement, il n'y a pas photo !

 

il y a 20 minutes, PiwiLAbruti a dit :

Le blocage IP automatique du NAS est suffisant pour bloquer les tentatives d'authentification échouées à condition de bien le paramétrer.

ABSOLUMENT  :+1: 
Comme il est dit dans le nouveau tuto de sécurisation , 3 essais pour sept jour avant blocage !

Bon, moi je suis passé à 5, mais c'est parce que je suis un "pignoleur"

[PiwiLAbruti]

Il y a 3 heures, CMDC83 a dit :

[...] et il est loin d'être à genoux 

Consommer des ressource ne veut pas dire les saturer. Dans le cas présent c'est de la consommation inutile vu les autres politiques de sécurité appliquées.

[CMDC]

Il y a 1 heure, PiwiLAbruti a dit :

Consommer des ressource ne veut pas dire les saturer. Dans le cas présent c'est de la consommation inutile vu les autres politiques de sécurité appliquées.

Je suis, à titre personnel, de part mes anciennes fonctions (SSI), extrêmement paranoïaque !
Donc, si, sur un autre fil, je combats la règle du "normalement", ici, j'applique la règle du "ceinture et bretelles" 

My two cents 

Modifié le 11 octobre 2023 par CMDC83