Aller au contenu

Comment Parer Durablement L'attaque ?chine Teste R


Messages recommandés

Bonjour,

Depuis maintenant plus d'un mois, je reçois quatre à cinq mails par jour de ce type venant de mon NAS, seule l'IP change:

Cher utilisateur,

L'adresse IP [188.165.18.135] a eu 4 tentatives échouées en essayant de se connecter à SSH exécutée sur CHEZ_MOI dans un intervalle de 5 minutes, et elle a été bloquée à Wed Jul 9 04:09:13 2014.

Sincères salutations,
Synology DiskStation

C'est inquiétant et semble vouloir dire qu'une machine teste l'accès à mon NAS avec des IP différentes qui correspondent souvent à des pays différents. A un moment, ils arriveront probablement à tomber sur le bon mot de passe, bien que j'ai réduit le nombre d'essais avant blocage.

Comment parer cela ou au moins le rendre plus difficile?

Merci d'avance.

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

je suis bien d'accord que cette situation n'est pas terrible.

est-ce que tu as vraiment besoin d'avoir ton NAS visible en port ssh / 22 sur internet ou le NAS lui-même carrément?

Si tu l'as mis dans la DMZ zone de ton routeur (=*box), tu l'exposes peut-être trop, peut-être peux-tu réduire la façon dont le Syno est visible?

Si tu as besoin d'avoir un accès ssh, je peux te conseiller de mettre une autre machine visible depuis internet (moi j'utilise un Raspberry Pi avec Raspbian que tu peux mieux protéger -port knocking, fail2ban, etc.) et t'en servir comme relai.

Je n'utilise pas Quickconnect pour exposer les services applicatifs http://www.synology.com/en-us/support/tutorials/614 mais il semble que ce puisse être une façon de rendre accessible les services du DS sans avoir à l'exposer directement (et ne pas exposer DSM si tu n'en as pas besoin).

bonne journée,

Eric

Lien vers le commentaire
Partager sur d’autres sites

J'aurais plutôt tendance à appliquer la règle inverse qui consiste à n'autoriser que les adresses IP Françaises (et Belges, Suisses, ...), la Chine n'est pas le seul pays à l'origine d'attaques massives sur des protocoles connus.

Pour ceux qui tiennent absolument à ouvrir SSH sur leur box/routeur, préférez un port externe différent du port tcp/22 et redirigez-le en interne vers le port tcp/22 du NAS. (Ça m'apprendra à lire la dernière ligne du message précédent après avoir posté)

Modifié par PiwiLAbruti
Lien vers le commentaire
Partager sur d’autres sites

J'aurais plutôt tendance à appliquer la règle inverse qui consiste à n'autoriser que les adresses IP Françaises (et Belges, Suisses, ...), la Chine n'est pas le seul pays à l'origine d'attaques massives sur des protocoles connus.

Pour ceux qui tiennent absolument à ouvrir SSH sur leur box/routeur, préférez un port externe différent du port tcp/22 et redirigez-le en interne vers le port tcp/22 du NAS.

En ayant changé le port SSH je n'ai constaté que très peux d'attaques (quelques par mois grand maximum) et quasiment toutes venaient de Chine

Voila pourquoi j'ai appliqué cette config.

Pour ce qui passe a travers les mailles du filet le blocage auto fait son boulot

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

Un grand merci pour toutes ces pistes que je vais essayer d'exploiter:

-Ai-je besoin de SSH? Il me faut savoir à quoi cela sert. Je vais voir.

- si j'en ai besoin, je vais translater le port sur mon routeur.

-Je vais bloquer directement la Chine car je n'y avis que très rarement, mais j'ai besoin des autres pays.

-j'ai réduit e blocage auto à 4 mais l'ai prolongé à 90 jours.

Je vous tiendrai au courant. @+

Lien vers le commentaire
Partager sur d’autres sites

Arrête moi si j'écris une ânerie, mais je pense que c'est parce que j'avais créé des dossiers synchrones entre deux NAS Syno éloignés et que le protocole ssh sécurisait la com.

Mais en ce moment, je n'utilise plus la fonctionnalité. Si elle en sert qu'à cela et pas au VPN par exemple, je peux la supprimer.

Right?

Pour l'instant j'ai interdit sur le pare-feu du NAS, tout ce qui vient de Chine, Asie en général, mais si cela fonctionne, il me faudra affiner plus tard.

Lien vers le commentaire
Partager sur d’autres sites

Après quelques jours d'essai, le filtrage par pays s'avère efficace dans mon cas. J'ai supprimé l'Asie. Plus de message d'alerte d'IP bloquée.

C'est réussi.

Ca ne bloquera pas tout mais ça réduit bien

Exemple (et pourtant je n'utilise pas le port SSH par défaut) plusieurs tentatives de login SSH (le blocage d'IP à fait son job) cette nuit de ce gugusse: http://www.abuseipdb.com/check/62.210.188.89

A essayé en utilisant une liste de users/password en ordre alphabétique:

Jul 13 06:32:43 fserv sshd[9145]: Invalid user abc123 from 62.210.188.89
Jul 13 06:32:43 fserv sshd[9144]: Invalid user abel from 62.210.188.89
Jul 13 06:32:43 fserv sshd[9138]: Invalid user abby from 62.210.188.89
Jul 13 06:32:43 fserv sshd[9140]: Invalid user abc123 from 62.210.188.89
Jul 13 06:32:43 fserv sshd[9137]: Invalid user a.bogdan from 62.210.188.89
Jul 13 06:32:43 fserv sshd[9139]: Invalid user abc123 from 62.210.188.89
Jul 13 06:32:43 fserv sshd[9142]: Invalid user abc123 from 62.210.188.89
Jul 13 06:32:43 fserv sshd[9143]: Invalid user accounts from 62.210.188.89
Jul 13 06:32:43 fserv sshd[9141]: Invalid user abc123 from 62.210.188.89
Jul 13 06:32:43 fserv sshd[9146]: Invalid user ace from 62.210.188.89

Apparemment il est chez Free mais suis étonné de son reverse DNS (62-210-188-89.rev.poneytelecom.eu)

Un allemand a aussi essaye de pénétrer mon VPN, mais sans aller jusqu'a l'identification:

Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: received Vendor ID payload [RFC 3947] method set to=109
Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: ignoring Vendor ID payload [FRAGMENTATION]
Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: ignoring Vendor ID payload [Vid-Initial-Contact]
Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: ignoring Vendor ID payload [IKE CGA version 1]
Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: responding to Main Mode from unknown peer 85.10.217.54
Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: OAKLEY_DES_CBC is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: STATE_MAIN_R1: sent MR1, expecting MI2
Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: STATE_MAIN_R2: sent MR2, expecting MI3
Jul 13 04:15:12 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: max number of retransmissions (2) reached STATE_MAIN_R2
Jul 13 04:15:12 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54: deleting connection "L2TP-PSK-NAT" instance with peer 85.10.217.54 {isakmp=#0/ipsec=#0}
Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

ils sont dans "/var/log/messages", mais par défaut DSM filtre les logs SSH

Pour les rendre visibles, j'ai du ajouter un fichier que j'ai nommé "local.conf" (l'important c'est que le suffixe soit .conf) dans le répertoire "/usr/local/etc/syslog-ng/patterndb.d" avec le contenu suivant:

#+
#	Overrides filter f_messages in /etc/syslog-ng/syslog-ng.conf
#-
filter f_messages {
       level (info .. emerg)
       and not facility(mail, news, cron)
       and not program(syslog-ng)
       and not filter(f_local)
       and not filter(f_synology);
};

Ca remplace le filtre par défaut suivant, déclaré dans "/etc/syslog-ng/syslog-ng.conf":

filter f_messages { level(warn..emerg) and not facility(auth, authpriv, mail, news, cron) and not filter(f_synology); };

qui empèche les logs "auth" (la classe qu'utilise sshd) d'apparaitre dans "/var/log/message"

Faut redémarrer le syno pour qu'il soit pris en compte (en fait le redémarrage du serveur syslog est suffisant mais c'est plus simple comme ça)

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines après...

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.