[Help] Tentative De Piratage..

[KZL]

Bonjour,

Je pense être actuellement la cible d'une tentative de piratage. Je ne sais ni comment s'y prends la personne, ni comment l'arrêter.

J'ai remarqué une extrême lenteur sur ma machine depuis l'extérieur (je ne suis actuellement pas chez moi).

J'ai donc utiliser tcpdump pour scanner mon réseau et j'ai observé des trames réseaux assez étranges entre mon serveur Syno et une machine dont l'adresse m'est inconnue.

J'ai enregistré 10Mo de trames en moins de 30 secondes.

Voici en image ce que cela donne avec Wireshark.

http://hpics.li/17673ac

Qu'est-ce que je peux faire contre ça ? J'ai bloqué l'adresse IP depuis l'interface de mon DSM, mais rien n'y fait..

Toujours les même requêtes à la même vitesse..

Need help.. quickly !

[Einsteinium]

Ferme les ports de ta box et consulte les logs savoir ce qui a était fait sur ton nas ?

Après si tu héberge un site ou autre, peu être que la personne l'aspire pour en avoir une copie ?

Et change tes mdp aussi..

Modifié le 3 août 2014 par Einsteinium

[KZL]

Arf, je les change régulièrement, maintenant je vais pas les changer à chaque tentative de piratage.

J'ai surtout l'impression que cette adresse inconnue, surcharge juste mon réseau et le rend indisponible.

[Einsteinium]

Après as tu dsm a jour ? Car il y a eu quelques failles bouchées depuis le début d'année

[KZL]

Biensur !!

J'ai beaucoup suivi les problèmes avec OpenSSH ces derniers temps.

Mais maintenant je pense que fermer les ports n'est pas la solution pour rebondir sur ce que tu as dit, car déjà si je les fermes, je n'y gagne rien.

Lui il peut revenir quand il veut si je les réouvre et ça changera rien ^^"

[KZL]

J'ai trouvé la solution.. Attaque avortée si s'en était une.. Je suis preneur si un pro passe par ici !

Et qu'il a une solution durable pour résoudre ces problèmes

Ma solution :

iptables -A INPUT -s XXXXXXXXXX -j DROP
iptables -A OUTPUT -d XXXXXXXXXX -j DROP

Remplacer XXXXXXXXX par l'adresse de votre suspect pour définitivement le dégager de votre réseau.

Semblerai que le pare-feu des syno ne soit pas très efficace contre des attaques sur la couche tcp.

Elle se contente de dégager le hacker du protocole SSH/FTP/..

Tout est redevenue instantanément à la normale, après avoir lancé mes commandes je précise :-)

Modifié le 3 août 2014 par KZL

[Einsteinium]

Oui enfin c'est déjà que ta box est mal configuré, maintenant s'il y a eu intrusion dans ton syno et que ton pass est fort. C'est qu'il y a faille, donc est ce que ton synology est a jour ? ;-)

La tu as juste interrompue la connection, il pourra la reprendre par la suite

[CoolRaoul]

Semblerai que le pare-feu des syno ne soit pas très efficace contre des attaques sur la couche tcp.

Elle se contente de dégager le hacker du protocole SSH/FTP/..

Euh.. ce qu tu appelle "le pare-feu des syno" n'est pourtant en fait qu'une simple interface graphique à iptables.

Devrait suffire de définir la règle avec l'option "ports:tous."

Ensuite un simple "iptables -L" permet de constater que ça a bien été traduit par

target     prot opt source               destination         
DROP       all  --  XXXXXXXXXX           anywhere            

NB:

Infos complémentaires sur l'IP source des attaques: http://www.abuseipdb.com/check/78.232.112.34

[KZL]

Merci CoolRaoul pour le lien, et les explications, parcontre il n'y a aucune option permettant de configurer "bloquer toutes les adresses" comme tu dis. Je suis preneur si tu peux m'expliquer depuis le DSM.

Néanmoins je pensais surtout utiliser un script maison ou qqchose dans le genre, car l'ip n'a pas été bloquée par la sécurité syno. Normal puisqu'il n'a pas tenté de ce connecter, il a juste surchargé, donc je ne trouve pas cette sécurité très bien ficelé.

Modifié le 3 août 2014 par KZL

[CoolRaoul]

Merci CoolRaoul pour le lien, et les explications, parcontre il n'y a aucune option permettant de configurer "bloquer toutes les adresses" comme tu dis. Je suis preneur si tu peux m'expliquer depuis le DSM.

"Tous les ports", pas "toutes les adresses":

Modifié le 3 août 2014 par CoolRaoul

[KZL]

Ouais mais ça je le fais plus vite par le terminal, c'est pas automatique. Je pensais que tu parlais de cchose d'automatique ! :-)

[CoolRaoul]

Ouais mais ça je le fais plus vite par le terminal, c'est pas automatique. Je pensais que tu parlais de cchose d'automatique ! :-)

Ma réponse initiale ne portait pas sur le coté plus ou moins rapide ou automatique de la manip, je répondais juste à "Semblerai que le pare-feu des syno ne soit pas très efficace contre des attaques sur la couche tcp".

Un autre avantage est que les settings fait sous DSM sont conservés lors des reboot.

Modifié le 3 août 2014 par CoolRaoul

[KZL]

Bon je reformule ma phrase alors comme ça se sera plus clair ^^

"Semblerai que l'option blocage ip automatique des syno ne soit pas très efficace contre desattaques sur la couche tcp"

Merci pour les explications encore.

Modifié le 3 août 2014 par KZL

[CoolRaoul]

Bon je reformule ma phrase alors comme ça se sera plus clair ^^

"Semblerai que l'option blocage ip automatique des syno ne soit pas très efficace contre desattaques sur la couche tcp"

Ah je comprend mieux, comme tu parlais de *firewall* j'ai bloqué la dessus.

En effet, le blocage IP s'applique exclusivement aux connexions aux service DSM utilisant une authentification compte/mot de passe.

Ca se comprend puisque ça se déclenche sur un nombre d'échecs de mot de passe.

Voila pourquoi une connexion en mode "socket" tcp, ne peut pas faire l'objet de ce genre de mesures défensives.

PS: note bien que ton filtre iptables, non seulement ne résistera pas à un reboot , mais qu'une simple modif de la config du firewall va aussi réinitialiser tous les filtres.

Modifié le 3 août 2014 par CoolRaoul

[mikijone]

Bonjour,

Quels ports as tu ouverts dans ta box internet? Je suppose que tu as du ouvrir quelques ports sur ta box pour te connecter au nas via internet.

Personnellement, je juge que le firewall du syno n'est pas fait pour être en première ligne contre ces attaques. C'est le dernier rempart le syno, donc la sécurité se fait en amont au niveau du routeur de ta box. C'est là que tu crée vraiment un goulot d'étranglement contre les chinois du FBI...

Sur ma box je n'ai ouvert que ce qui est nécessaire et j'ai mis des ports complètements différents. Par exemple: le port 22 dédié au ssh : sur le NAT de ma box j'ai mis 7575 en port externe (coté internet) et j'ai laissé 22 en port interne. Le but est de ne pas utiliser les ports par défaut.

Miki

[Einsteinium]

Euh si pour ce genre d'attaque... Protection ddos a activé dans ton nas, il aurait était dégager directement =)

Cool Raoul pas d'accords, il y a un bug dans le firewall en wifi, à chaque reboot le firewall ne filtre rien sur celle ci, il faut répliquer à chaque fois (et les règles sont toujours la), certainement due au fait que la clef est montée après le démarrage du firewall et n'applique pas les règle ne voyant pas l'interface... Maintenant depuis qu'il faille faire un compte pour remontée les bug... Je ne le fais plus...

[CoolRaoul]

Cool Raoul pas d'accords, il y a un bug dans le firewall en wifi, à chaque reboot le firewall ne filtre rien sur celle ci, il faut répliquer à chaque fois (et les règles sont toujours la), certainement due au fait que la clef est montée après le démarrage du firewall et n'applique pas les règle ne voyant pas l'interface...

Tu parles sans doute de ma phrase "les settings fait sous DSM sont conservés lors des reboot" je suppose?

Tu conviendras que ce problème du wifi est quand même très spécifique. De plus ça ne doit pas courir les rues les personnes utilisant une interface wifi (clé ou intégré) sur le NAS comme interface principale (pour y rediriger les ports de la box).

Maintenant depuis qu'il faille faire un compte pour remontée les bug... Je ne le fais plus...

Si le support Synology n'est pas au courant, alors ce bug n'est pas près d'être corrigé, vu qu'il doit toucher bien peu de monde en plus.

[Einsteinium]

Bon je me suis motivais, j'ai fait un ticket au support par acquis de conscience.

[Einsteinium]

Mon message :

Voilà je dispose d'un ds413j, je l'utilise via un d'ongle wifi mis en usb, j'ai remarqué qu'après chaque reboot, le pare-feu est inactif, j'entends pas la qu'un port scan, m'indique la totalité des ports ouverts, pourtant les règles sont bien présente dans le pare feu, pour que celle ci soit appliquées, je dois décoché une règle, sauvegarder pour que celle ci soit bien appliquée (après je recoche ma règle et sauvegarde à nouveau pour avoir ma configuration normale)

Si vous voulez, je peux vous faire une vidéo du problème, je pense que celui vient du fait que le firewall démarre avant que la clef soit prise en compte, ce qui rend la clef sans aucun filtrage.

La réponse :

Je vous remercie pour ces précisions, mais vous pouvez me faire une vidéo ça m'aiderait certainement pour mieux comprendre.

Vous avez un Firewall dans votre réseau sur lequel sont appliqués des règles de firewalling ?

C'est le Nas Synology qui vous sert de Firewall ?

Quel est l'équipement qui fait le routage, et qui vous apporte la connexion internet ?

Si c'est vous avez un équipement de firewalling (Checkpoint etc...)

Je ne vois pas le rapport avec le Nas, son redémarrage n'a aucun impact sur ce dernier

Si c'est le Nas qui vous sert de Firewall, comment voulez fermer les ports d'un autre équipement (le routeur ) depuis le Nas ?

Veuillez m'excuser, mais je ne crois pas avoir tout compris. Je vous remercie pour votre compréhension et pour votre aide.

Question 1 ? Euh... Nan déconne je parle d'un paquet de chips vide alors que je viens de l'ouvrir.

Question 2 ? Euh... Foutage de gueule ?

Question 3 ? Aucun rapport

Mais il ne voit pas le rapport avec le nas... il m'a tué le mec...

Pourquoi mettre des gas dit de support français, alors qu'il ne le comprenne pas, si quelqu'un ce sent le courage, en anglais, à vos plumes, je déteste les dialogues de sourd >.>