ERaw

WTF?!.... un moment d'égarement ou un compte piraté? :-D

C'est bon, j'ai trouvé dans un de tes posts. Par la même occasion, j'ai trouvé la solution. Il semblerait que Synology ait changé sa politique de sécurité pour les paquets non officiels. Il faut authoriser les pacquets non signés dans les parametres du package Center. ++ E-Raw

Salut ewfzapp! Merci pour la combine, ça marche nickel. Par contre, le package "officiel" 3.7 est sorti mais pas moyen qu'il l'installe. Pourrais-tu donner l'adresse du site source en anglais? Merci, E-Raw

Bonjour giorgio, Il y a moyen en effet, il faut voir ce que tu veux bloquer. Sache déjà que si les ports utilisés pour les réseaux p2p ne sont pas routés vers ton Syno depuis ta box(routeur) et/ou que ton Syno n'est pas dans une DMZ, ils ne peuvent plus se connecter sur les services p2p qui tournent sur ton Syno.

C'est assez "normal" d'avoir ce genre de tentatives, le fait de changer le port du SSH peut deja en eviter pas mal. Par contre ca provoque des problemes sur certaines fonctionnalité du Synology comme le Network Backup Securisé entre deux Syno... on ne sait pas spécifier le port... Maintenant si le mot de passe est complexe et que tu bloques l'ip après 5 tentatives, le brute force est quasi impossible... (j'ai bien dit quasi )

OK, je vois mieux. Est-ce que le port que tu utilise pour te connecter a l'interface web de ton Syno est forwardé depuis ta box ou est-ce que le syno est en DMZ? (perso, la DMZ c'est à proscrire!) Pour l'accès web, privilégie le HTTPS, c'est deja beaucoup plus securisé. tu peux configurer dans le Syno les restrictions d'accès et forcer le HTTPS/SSL. Le port par defaut pour le SSL est 5001 sur le syno. Sinon, le plus simple est effectivement d'utiliser DynDNS ou autre équivalent depuis le Syno (pas depuis la box), il te donnera l'IP publique de l'interface VPN lorsque celui çi est connecté ou l'IP de ta box quand le VPN est OFF. Après pour y avoir accès de manière transparente, peu importe si VPN ou pas, dépendra de la bonne configuration de ta box avec les bons ports forwardés. Pour l'accès local, il ne devrait pas y avoir de problème en LAN si ton syno n'est pas dans une DMZ. Après avoir tout configuré proprement et testé les accès depuis le LAN et le WAN, tu pourras regarder pour sécuriser ton interface VPN. Bon amusement!

Bonjour, Alors pas de panique, c'est normal. Si j'ai bien compris, tu ne sais plus te connecter sur ton syno depuis l'exterieur? avec quel moyen essaies-tu de t'y connecter (ssh, https(s),...)? Vu que ton VPN crée une interface virtuelle directement connectée à internet, elle a sa propre IP publique. Il faut voir maintenant ce que tu essaie de faire exactement. De plus, as-tu mis en place le script pour sécuriser le VPN ou pas? Bien à toi, E-Raw

Bonjour, En fait il y a une contrainte assez simple qui nécessite d'avoir le script qui tourne toute les minutes. Quand le VPN se déconnecte (peu importe la raison), l'interace tun0 (ou ppp0) disparait et donc est également effacée d'iptables (iptables n'accepte que des règles pour des interfaces valides). Il n'est donc pas possible d'avoir un iptable qui ne change pas, c'est dynamique. Si tu fais un jour un drop all sur eth0, tu auras une mauvaise surprise ton syno deviendra instantanement injoignable et donc il faudra faire un hard reboot pour le récupérer en esperant que tu n'as pas mis le drop all sur l'eth0 dans un script exécuté au démmarage... bref, oublies! eth0 est ton interface physique primaire et donc elle ne peut pas être soumise a un drop all. En plus, il faut garder en tête que ton VPN crée tun0 au travers d'eth0. C'est un peu comme si tu coupais la branche de l'arbre sur laquelle tu es assis. Il faut plutot t'arranger pour cibler ce que tu veux bloquer en sortie par eth0, hors VPN donc. Malheureusement le module iptables ipt_owner qui permet de filtrer les packets sortant par user (en toute logique les services que tu veux bloquer sont lancés par des utilisateurs en particuler comme transmission ou sabnzbd, à tout hasard ) n'est pas inclus dans les paquets fournis dans l'OS. Il reste la possibilité de le faire basé sur les ports en sortie, encore faut t'il connaitre le range a bloquer, ce qui n'est pas toujours évident. Je vais y jeter un oeil si j'ai le temps.

Bonjour gillou13 et les autres, En fait, après avoir tenté d'intégrer ça dans le routeur sans succès, je suis revenu à l'utilisation du client VPN sur le Syno mais sans utiliser up/down.sh Il ne faut pas les utiliser dans cron car ces scripts doivent être lancés uniquement pour l'état de la connection correspondant. (sinon en gros ça va mettre le brin) Le problème étant donc de s'assurer que l'interface virtuelle du VPN exposée sur le net sans aucune protection soit sécurisée. Pour ça j'ai créé à l'époque un tuto disponible là: Il est interressant de lire la suite pour certaines adaptations qui sont propre a certaines configs. Pour ce qui est de bloquer le traffic quand le VPN est down, ça devrait être faisable avec une seconde partie du script (puisque la première partie vérifie s'il est up, on pourrais faire un ELSE assez facilement) qui bloquerait le traffic indésirable en sortie. En entrée, si les ports concernés ne sont pas forwardés par le routeur vers le Syno, il seront implicitement indisponibles, donc bloqués. J'espère que ce que j'écris est compréhensible :-)

Après quelques googlages et lectures, il semple que ce script est lancé uniquement pour un VPN PPTP, pas openvpn... je n'ai pas trouvé d'affirmation explicite, c'est plutôt une déduction. Si un spécialiste passe par la? A mon avis, les utilisateurs lambda sont loin de se douter de ce à quoi ils s'exposent... j'espère me tromper!

Est-ce que ce script est également joué lors de l'instanciation d'une interface TUN/TAP?

Ca devrait normalement être disponible dans l'interface du DSM->Firewall avec les interface physique eth et le PPPoE mais ce n'est pas encore disponible. Je suppose que ça viendra avec le temps et le nombre d'utilisateurs qui configurent un VPN client sur leur Syno. En attendant on peut un peu bidouiller

Je vais modifier le script en fonction de ta remarque, c'est effectivement plus efficace. On pourrait même supprimer le grep "DROP" vu que c'est tout ou rien. Merci pour la remarque!

Bonjour, Suite à pas mal de posts traitants de conenction VPN a partir d'un Syno, j'ai remarqué que presque personne ne se soucie de l'aspect sécurité. Lorsque le NAS passe par un tunnel VPN en vue d'être anonyme sur internet, le fait d'avoir une IP publique vous expose complètement. La sécurité apportée par un routeur/box/... est innefficace car le NAS est connecté et visible directement sur internet, un peu comme si le cable réseau du syno était publique. Le DSM (4.1 dans mon cas) propose une interface pour configurer le firewall mais celle çi ne reprends pas l'interface virtuelle créée lors de l'établissement du tunnel VPN. Il n'est donc pas possible d'appliquer des règles pour bloquer les ports ouverts sur votre NAS et son interface VPN. Lorsque vous avez une connection VPN fonctionnelle (PPTP ou openVPN) il est possible d'appliquer manuellement des règles pour filtrer les connections vers votre NAS. Le problème est que ces règles disparaissent lorsque le VPN est déconnecté ou qu'il est reconnecté automatiquement après une interruption. Pour éviter de devoir scruter manuellement la présence des filtres, j'ai fais un script qui vérifiera toutes les minutes si le VPN est connecté et si oui, si les filtres sont présent. Si les filtres ne sont pas présent, il jouera les commandes nécessaires pour créer les filtres. Cron (planificateur de tâches Unix/Linux) se chargera d'exécuter le script à intervalles réguliers. Pour suivre ce tuto vous devez avoir au minimum les connaissances de base linux. Toute la marche à suivre est à exécuter en tant que root. Je tiens quand même à vous avertir que si vous ne comprenez rien à ce qui est dit, il est risqué d'aller plus loin. le script doit être accessible dans l'arborescence de votre syno (par exemple dans /usr/local/scripts/ ) et exécutable (chmod +x lenomduscript.sh ) Le script est le suivant: EDIT du 21/01/2013: La ligne iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT doit être ajoutée sinon (entre autre) l'update DDNS ne pourra se faire (cette ligne autorise les packets qui font partie d'une session déjà ouverte, dans ce cas par le client DDNS qui dois connaître son IP publique). #!/bin/ash #################################################################### # This script coverts the lack of security when machine is fully # # exposed on its public IP address once connected to a VPN. # # It is designed to work on Synology NAS running DSM 4.1 but # # general linux rules apply, it should be usefull for other # # purpose. # # e-raw [@] e-raw.be # #################################################################### # Local settings definition # # #iptables binary path iptables="/sbin/iptables" #VPN interface #Should be tun0 for openVPN instance and ppp0 for PPTP interface="tun0" # # Test if VPN is up and iptables rules have been defined yet # # if [ -n "$(ifconfig | grep "$interface")" ] && [ -z "$($iptables -L -v | grep "$interface")" ]; then #Incoming connections ACCEPT on the VPN interface # $iptables -A INPUT -i $interface -p tcp --destination-port 22 -j ACCEPT #[...] $iptables -A INPUT -i $interface -p tcp --destination-port 5001 -j ACCEPT ##EDIT: Mandatory to allow DDNS client to resolve it own public address: $iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT #if none of the rules were matched DROP # $iptables -A INPUT -i $interface -p tcp -j DROP $iptables -A INPUT -i $interface -p udp -j DROP $iptables -A INPUT -i $interface -p icmp -j DROP fi exit 0; Deux choses sont à adapter a vos besoins: Le type de VPN L'interface virtuelle créée lors de la connection est tun0 dans le cas d'openVPN et ppp0 dans le cas du PPTP Les ports à ouvrir Ceux çi doivent être l'équivalent de ce que vous avez routé sur votre box pour pouvoir y avoir accès de l'extérieur. faites attentions au protocole (udp/tcp) ainsi qu'au port (en rouge) Une fois le script modifié et exécutable, connectez-vous au VPN. Vous pourrez vérifier que il n'y a aucun filtre avec la commande iptables -L -v Lancez le script manuellement une première fois et rejouez la commande iptables -L -v Les filtres sont désormai appliqués et visibles. Pour rendre le tout automatique, il faut utiliser crontab. Dans mon cas, le script est exécuté toute les minutes. Il y aura donc maximum une minute ou le NAS sera exposé lors de chque reboot/reconnection. Sur le syno, les entrées du cron se trouvent dans le crontab dans /etc/crontab: DiskStation> cat /etc/crontab #minute hour mday month wday who command 32 18 * * 2,5 root /usr/syno/bin/synopkg chkupgradepkg 0 4 * * 1 root /var/packages/AntiVirus/target/bin/synoavscan --all * * * * * root /usr/local/scripts/vpn_iptables.sh Chaque ligne représente une tache planifiée. On remarque ici que vpn_iptables.sh (le script en question) est exécuté toute les minutes. Les autres lignes ne doivent pas être touchées! Ajoutez à l'aide de vi par exemple la ligne en rouge correspondant à votre script. Redémarrez crond avec les commandes : /usr/syno/etc.defaults/rc.d/S04crond.sh stop /usr/syno/etc.defaults/rc.d/S04crond.sh start Pour vérifier que votre script fonctionne bien, vous pouvez vider les règles de filtres avec la commande iptables -F ce qui aura le même effet qu'une nouvelle (re)connection. Après maximum une minute (suivant l'intervalle que vous avez configuré dans cron) les filtres devraient réapparaitre, à vérifier avec iptables -L -v J'espère que ça en aidera quelques uns!

Bonjour slybreiz, Les ports 7001 etc ne doivent pas être routés de ta box vers ton Syno! C'est le port 1194 (par défaut pour openvpn) qui doit l'être. Pour tester la connection du client VPN, il suffit de suivre le tuto depuis le début. Si besoin, efface toutes les configs de clients déjà présentes et recommence depuis le début. Après il sera temps de regardr pour le firewall.

Bonjour à ceux qui me liront! La méthode décrite plus haut ne fonctionne que pour une connection propre et pas une reconnection après perte de celle-çi. C'est étrange car suivant la doc openvpn, le script spécifié devrait être exécuté a chaque (re)conection... Je suppose que le problème est dû a la couche Syno par dessus openvpn. Je vais me diriger vers une config d'un router (DD-WRT) qui utilisera le VPN (tun0) pour certains ports uniquement (iptables).

Bonjour, J'étais à la recherche d'une solution pour premierement Utiliser un VPN pour certains service, ça c'est facile... et de deux, connaissant les bémols du client VPN du syno et l'impossibilité de faire pareil qu'ici : http://tech.kanka.ch/?p=153 , J'ai finalement opté pour ta solution avec le script pour le firewall. J'ai trouvé comment le lancer quand le VPN se connecte (ainsi qu'ventuellement un autre script quand il se deconnecte, pour nettoyer par exemple). Le syno crée deux fichier de conf lorsque l'on crée/modifie une connection client VPN dans /usr/syno/etc/synovpnclient/openvpn ainsi que le fichier de certificat importé DiskStation> cd /usr/syno/etc/synovpnclient/openvpn DiskStation> ls -l -rwxr-xr-x 1 root root 1265 Jan 4 12:14 ca_XXXXXXXXXXX.crt -rw-r--r-- 1 root root 290 Jan 4 17:24 client_XXXXXXXXXXX -rw-r--r-- 1 root root 385 Jan 4 12:33 ovpn_XXXXXXXXXXX.conf Le fichier client_ contient la config au formalisme de openvpn, le ovpn_.conf ressemble a une conversion a la sauce syno (avec users et mots de passe) de ces mêmes informations. Pour lancer un script après une connection réussie au VPN, il faut éditer client_XXXXXXXXXXX et ajouter a la fin: DiskStation> cat client_XXXXXXXXXXX dev tun tls-client remote anna.vpntunnel.se 1194 pull proto udp ca ca_XXXXXXXXXXX.crt comp-lzo script-security 2 float reneg-sec 0 explicit-exit-notify plugin /lib/openvpn/openvpn-down-root.so /etc/ppp/ip-down auth-user-pass /tmp/ovpn_client_up up /usr/syno/etc/synovpnclient/openvpn/up.sh DiskStation> Ce script up sera lancé après une connection réussie (voir http://askubuntu.com/questions/28733/how-do-i-run-a-script-after-openvpn-has-connected-successfully ) et avec down vous pourrez faire pareil pour la déconnection. assurez-vous que le script est exécutable! (chmod +x): DiskStation> ls -l -rwxr-xr-x 1 root root 1265 Jan 4 12:14 ca_o1357298091.crt -rw-r--r-- 1 root root 290 Jan 4 17:24 client_o1357298091 -rw-r--r-- 1 root root 385 Jan 4 12:33 ovpn_o1357298091.conf -rwxr-xr-x 1 root root 1190 Jan 4 17:20 up.sh Le seul bémol, c'est que (je suppose) si on modifie la config via le DSM, on perd la modif. J'espère que ça en aura aidé! ;-) EDIT: DSM 4.1