Comment Parer Durablement L'attaque ?chine Teste R

[clodsabo]

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.

[EricMotordu]

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

[CoolRaoul]

Quelques pistes:

• bloquer toute la chine (et autres pays sources de nombreuses attaques) dans le firewall du Syno:
  
• utiliser un autre port que le 22 pour ssh (en modifiant la règle de redirection dans le routeur)

[PiwiLAbruti]

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é le 9 juillet 2014 par PiwiLAbruti

[CoolRaoul]

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é le 9 juillet 2014 par CoolRaoul

[clodsabo]

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. @+

[PiwiLAbruti]

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

Ah oui quand même... pourquoi avoir ouvert ce port si tu n'utilises pas SSH ?

[clodsabo]

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.

[clodsabo]

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.

Merci pour votre aide pertinente.

[CoolRaoul]

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é le 13 juillet 2014 par CoolRaoul

[clodsabo]

Comment obtiens-tu ces logs, en particulier celui qui donne le login employé?

[CoolRaoul]

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é le 13 juillet 2014 par CoolRaoul

[synocdoche]

Depuis que j'utilise la géolocalisation pour filtrer je n'ai plus jamais d'essais de connexion contre une dizaine par jour auparavant.

[clodsabo]

Idem pour moi.

Supprimé Asie.

[synocdoche]

J'ai été un peu plus radical et j'ai juste autorisé mon pays.