CMDC

On en vient donc à la fameuse règle du normalement ! Normalement on ne devrait pas recevoir des IP "non normalisées" .... Normalement, sauf que ..... Un exemple ? j'ai implémenté les fameuses règles DDoS que je cite une peu plus haut sur mes NAS ; voilà le résultat des courses : On s'aperçoit que "normalement" on rejette des IP en 0.0.0.0/8 et en 192.168.0.0/16 En en revient donc , en SSI , à rejeter cette règle du "normalement" My two cents !

Vaste débat ! Il est en effet peu probable qu'un hacker utilise ce type d'adresse ! Sauf si .... ... On ne connait pas forcément les limites du génie des hackers. Ce qui fait qu'il faut produire des règles le plus restrictives possible ! Donc changer la règle par défaut de l'interface VPN en Refuser l'Accès et donc forcement ajouter la règle d'accès par le réseau 10.0.0.0/8 si on utilise un VPN. Après, chacun fait ce qui lui plait hein ? EDIT> En tout cas merci pour ce superbe tuto @.Shad.

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 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 ! 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"

Teste et tu verras, car c'est ainsi que cela fonctionne chez moi tun0 étant l'interface VPN server

Je suis tout à fait d'accord avec toi au sujet de la règle (10.0.0.0/255.0.0.0). qu'il ne faut absolument pas mettre dans l'interface LAN1; c'est contre les règles élémentaires de protection contre le SPOOFING ; SOURCES ; si un attaquant arrive avec ce type d'adresse, c'est la "fête du slip" pour lui . Il faut l'intégrer aux règles de l'interface VPN comme par exemple ceci (car je n'utilise qu'OpenVPN) et surtout bien cocher la case Refuser accès

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 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 . Il existe ICI une liste d'IP que tu peux bloquer définitivement pour ton plus grand bien

Peut-être qu'il faut demander à Sébr ce qu'il en pense ?

Bon, alors c'est du résolu !

ssh admin@10.2.0.1 Je dis 10.2 car j'ail la flemme de regarder l'adresse du NAS en L2TP Moi c'est 10.8.0.1 car j'utilise OpenVPN EDIT> J'ai regardé et c'est bien 10.2.0.1 D'ailleurs, je ne sais pas si c'est dit dans le TUTO Sécurisation du NAS, mais c'est une excellente (car utilisée par moi ) initiative pour éviter d'ouvrir les port ssh

20230926-1043-27.2584133.mp4 Peut-être qu'il y a un filtre sur les *.pdf ?

Je ne sais pas si cela a déjà été dit (j'ai le flemme de lire les 28 pages), mais pour ces commandes qui durent très longtemps, il vaut mieux précéder la commande par nohup ex : nohup badblocks ...... & L'effet étant que le processus va continuer à tourner même si vous vous déconnectez .

Bien sur c'est ici

Pour moi, mais je peux me tromper, quand tu actives le VPN tout le trafic passe par lui

CloudStation Backup semble tout à fait dans tes cordes, c'est de la sauvegarde instantanée de ton PC sur ton NAS

A l'intérieur de votre réseau naturellement que oui et à l'extérieur, si n'importe-où veut dire internet , la réponse et oui aussi; mais par contre il faudra faire un peu de configuration, comme ouverture de ports sur la box etc.. etc... Mais c'est très faisable et de nombreux tutoriaux sont présent sur ce site

Salut mon ami , J'ai profité d'une chouette grippe de la mort qui tue qui me retient à la maison pour mettre à jour mon DS 213J en 6.0. Du coup, vu que j'ai du temps, j'ai "migré" mes reverse proxy de apache vers nginx, grâce à ce super tuto. Du coup j'ai un peu simplifié et j'ai simplement créé un fichier nommé "/etc/nginx/sites-enabled/vhosts.conf" que j'ai rempli de la manière suivante: ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; proxy_redirect http:// $scheme://; proxy_set_header X-Client-Verify SUCCESS; proxy_set_header X-Client-DN $ssl_client_s_dn; proxy_set_header X-SSL-Subject $ssl_client_s_dn; proxy_set_header X-SSL-Issuer $ssl_client_i_dn; server { listen 80; server_name ~^dsm..*$; return 301 https://$server_name$request_uri; } server { listen *:443 ssl; server_name ~^dsm..*$; underscores_in_headers on; #uniquement necessaire pour le vhost DSM location / { proxy_pass http://localhost:5000/; } } Tout ça parce-que sur internet je préfère toujours utiliser https et donc rediriger http vers https Voili voilou, si tu souhaites compléter ton super tuto et effacer ma réponse, pas de problème

C'est effectivement bien mieux pour la sécurité de ton nas; Si je peux me permettre de rappeler des règles de sécurité élémentaires: il faut créer un utilisateur qui soit superuser du nas que l'on appellera "user" pour l'exemple puis désactiver le compte admin pour empêcher les pirates de te tester avec ces deux utilisateurs archi-connus qui sont root et admin. Ensuite tu insères la ligne suivante dans le fichier /etc/sudoers user ALL=(ALL) NOPASSWD: ALL Ensuite quand tu te connectes via ssh sur ton nas avec ce compte "user" tu exécutes aussitôt la commande "sudo bash" et tu es le roi du pétrole

Webdav devrait le permettre, c'est un tout petit peu compliqué à mettre en œuvre mais on trouve de bon tutos sur le web Moi perso je préfère utiliser le filestation du synology on l'attaque à partir du navigateur de le manière suivante http://mon-syno:7000 ou de manière plus sécurisée https://mon-syno:7001 Le reste est très simple

Rien n'est perdu tes anciens scripts sont dans /usr/local/etc/httpd/sites-enabled, ils ont étés renommés avec une extension bidon, il suffit de le renommer à nouveau avec l'extension .conf. Il peut subsister un pb avec tes clés SSL Pour ma part j'ai du rajouter SSLCertificateFile "/usr/syno/etc/packages/VPNCenter/openvpn/keys/server.crt" SSLCertificateKeyFile "/usr/syno/etc/packages/VPNCenter/openvpn/keys/server.key" LoadModule ssl_module modules/mod_ssl.so

Dans le monde Linux il y a rsync qui pourrait faire l'affaire, tandis que pour windows il a SyncbackFree qui fait le même boulot. Ce sont des programmes très riches qui demandent à être manipulés avec précaution, car un malheur est vite arrivé Pour Mac, je ne sais pas; je fais une allergie pécuniaire lol

Moi, je n'ai pas pu alors je vous donne la solution: Services web -> Activer Web Station -> Hote Virtuel Puis creer un truc comme www.mon-domaine.my en HTTP et un autre en HTTPS Cela va créer tout simplement les fichiers de conf suivants dans le répertoire "/etc/httpd/sites-enabled-user" : "httpd-vhost.conf-user" et "httpd-ssl-vhost.conf-user" qu'il suffit de remplir avec les bonnes informations que l'on trouve dans tous les excellents tuto sur Apache et le Proxy Reverse Enjoy It

Si je peux donner mon avis et il vaut ce qu'il vaut: si tu ne crains pas pour tes données tu peux éventuellement faire la manip; tu ne risques que de "breaker" ton NAS. Même s'il y a peu de chances Par contre si tes données sont importantes , tu es condamné à attendre des jours meilleurs; d'autant plus que ton cas n'est pas désespéré ; en effet il m'est arrivé aussi d'être obligé de tirer la prise pour redémarrer, mais ce phénomène a disparu comme il était arrivé!

Tu télécharge la version 4.3 par exemple http://ukdl.synology.com/download/DSM/4.3/3827/DSM_DS213+_3827.pat Et ensuite tu fais une MAJ manuelle Mais ce n'est pas conseillé ; c'est faisable (je l'ai fait pour revenir temporairement en 4.2), mais pas conseillé par Syno Donc : à tes risques et perils

Ouaip et moi en 4.3 ! Va falloir être encore plus patient

Chers utilisateurs de Synology, Une faille critique touchant la plupart des sites Internet dans la librairie logicielle Open SSL, connue sous le nom de Bug Heartbleed, était aussi présente sur MyDS Center et DSM. Cependant, Synology a comblé la faille sur tous les serveurs MyDS Center et DSM 5.0. Nous aimerions vous communiquer les informations suivantes : Tous les serveurs MyDS Center ont été mis à jour et sont sûrs. Nous n'avons pas remarqué d'accès non autorisé aux données utilisateurs durant la période de vulnérabilité, mais nous recommandons à tous nos clients de changer de mot de passe MyDS, à titre de précaution. DSM 5.0-4458 Update 2 est sortie le 10 Avril. Tous les utilisateurs de DSM 5.0 et DS. 4.3 sont encouragés à suivre les instructions sur la page dédiée à la sécurité chez Synology. Nous travaillons actuellement sur une mise à jour pour DSM 4.2 et DSM 4.3. La mise à jour pour DSM 4.2 sera disponible dans une semaine. Pour les utilisateurs qui préfèrent DSM 4.3, la mise à jour sera disponible fin avril. Pour les utilisateurs de DSM 4.1, il est conseillé de mettre à jour votre système vers DSM 4.2 Les versions DSM 4.0 et précédentes ne sont pas affectées. Synology prend très au sérieux la sécurité de ses logiciels et de vos données. Nous demeurons ouverts et transparents. En cas de questions ou inquiétudes, vous pouvez nous contacter à security@synology.com. Merci Très cordialement, L'équipe de développement de Synology