CoolRaoul

Il s'agit d'ouvrir des ports dans un *routeur*, si ça ne fonctionne pas c'est un probleme de compatibilité avec le routeur, les bornes wifi ne sont pas en cause.

Merci pour tous ces détails Un de ces jours j'avais bien envie de me faire plaisir (ce n'est pas que j'en ai vraiment besoin ...) avec un modèle 4 Baies, mais le différentiel de consommation avec mon DS213j (donné pour moins de 4Watts en idle, hors conso disques! (*) ) me chiffonne un peu (http://www.synology.com/fr-fr/products/compare_products/DS415play/DS213j) (*) à moins que ce soit une coquille?

Non; ce que je veux dire c'est quand le système ne fait pas de transfert de données (en gros pas d'utilisateurs connectés, quelque soit le service) mais pas en hibernation pour autant

Oups, les 2 baies supplémentaires (par rapport à la 213play) ça met un coup à la conso électrique. **EDIT** Synology ne communique que 2 valeurs pour la consommation: "accès" et "hibernation du disque dur", serait intéressant d'avoir un 3ème, en mode "idle": pas d"hibernation mais pas d’accès non plus. Cette info est-elle disponible quelque part?

Non, le dossier restera crypté. Le reset permet juste de remettre à zero le mot de passe du compte admin. En plus en désactivant l'option "monter automatiquement au démarrage", quelqu'un qui vole le syno avec ses disques n'aura aucun moyen d'accéder au contenu crypté, même si il connait le mot de passe d'un des comptes ayant accès au dossier crypté. (a vérifier, mais le reset hardware doit normalement effacer le mot de passe du montage auto) Tous les détails ici: http://www.synology.com/fr-fr/support/tutorials/455

Et pourquoi ne pas avoir simplement essayé ? "Panneau de configuration" -> "dossier partagé" -> sélectionner le dossier -> "modifier" -> "emplacement" et le tour et joué.

Pour la "recherche par appliance" comme vous avez demandé, faut aller dans l'onglet "autres serveurs" ("others servers"), et là on a le filtre détaillé

Quels champs faudrait-il ajouter selon vous dans le formulaire de filtrage des logs ci dessous pour répondre a votre besoin?

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)

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}

Trouvé, c'est bien le responsable du site! http://www.nas-forum.com/forum/index.php?app=forums&module=extras&section=boardrules Tout est normal alors!

C'est pas exactement un problème de vie privée ici: je n'en sais pas beaucoup plus sur celle de ce monsieur après avoir lu sa page Google+ et après tout il ne partage que ce qu'il choisit. Et pour ce qui est de *ma* vie privé, elle n'est pas impactée par cette anomalie non plus. Je trouvais juste étonnant qu'il soit si facile de passer pour un officiel du forum vis à vis de Gmail/Google+ juste en mettant "NAS-Forum" dans son champ "employeur".

Depuis ce matin, gmail affuble les message de notification du forum de la photo d'un gus dont la page Google+ indique que son employeur est "NAS-Forum", ça fait "bizarre"! (Je me demande pourquoi je l'ai flouté car je suppose que beaucoup de membres du forum ont accès à son profil public Google+)

@dhalfon: Peut-on voir à quoi ressemble le script? est-il exécutable (chmod +x) ? contient-il une commande PATH= ? (*toujours* mettre dans les scripts lancé en cron, et systématiquement tant qu'a faire) quel est le contenu de sa première ligne (celle commençant par #!) ?

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

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)

No pb, je surveille régulièrement les nouveaux post du forum, et je suis abonné à ce fil également :

Les champ serveurs DNS sont devenu grisés parce que tu as décoché la case "configurer manuellement ..." Suffit de la recocher, saisir les bonnes IP et normalement tout fonctionnera

Par "manuellement" je pensais à la commande "ntpdate -d" en ligne de commande

Le serveur de temps qui tu utilise a la main ne doit pas être le meme que celui déclaré dans la config sous la console DSM De plus, apparemment tu as encore des problèmes de résolution DNS, essaie de mettre les DNS google (8.8.8.8 et 8.8.4.4) à la place des DNS orange ou carrément remet l'IP de la box comme DNS primaire, on a vu que ça doit fonctionner aussi.

Que tu n'a pas voulu écouter le conseil de domlas qui te disais, des le 2eme post du fil:

Oui en DSM5 dans "/usr/bin". pour les versions "pré DSM5" je ne sais pas

méoui méoui, au moins depuis DSM 5: fserv> which tcpdump /usr/sbin/tcpdump

Yep aussi, la nuit porte conseil.