12 réponses à ce sujet

[DocIn]

Bonjour,

Avant tout, je vous souhaite à toutes et tous une excellente année 2012.

Je suis en train de me faire un bout de script pour mettre à jour automatiquement la liste de filtrage d'ip de mon QNAP
Concrêtement cela se traduit par un ajout de lignes dans /etc/config/ipsec_deny.conf.
Suite à celà j'ai 2 questions:
1/Actuellement pour que mes modifications soient prise en compte, après ma modification de ce fichier, je lance la commande "/sbin/ip_filter". Est-ce suffisant ?
2/A combien de lignes/entrées est-on limité pour ce type de filtrage?

Par avance, merci de vos lumières.

[father_mande]

Bonjour,

A ma connaissance :
... pas de limite, mais comme il y a accés à chaque fois .... c'est comme les anti-pub qui mettent les sites à bannir dans le fichier host ... au bout d'un moment cela ralenti ... mais la sécurité a un prix ...
... relancer ip_filter suffit pour mettre en place la nouvelle liste, par contre il semble qu'il faille relancer "/etc/init.d/qsyncman.sh restart" pour voir les nouveaux filtres dans l'interface Web ??? TBC .

... sachez que les iptables font (discrétement) leur apparition avec les VPN (juste pour le masquerade) ... mais qu'en quelques lignes de shell, il est possible de les valider pour tous et tout le temps et avec quelques liens ... bien fait, de récupérer les fonctions save et restore ...

Philippe.

[DocIn]

Bonjour, father_mande, et merci pour ta réponse.

father_mande, le 09 janvier 2012 - 13:31 , dit :

... relancer ip_filter suffit pour mettre en place la nouvelle liste, par contre il semble qu'il faille relancer "/etc/init.d/qsyncman.sh restart" pour voir les nouveaux filtres dans l'interface Web ??? TBC .

En fait, les nouveaux filtres apparaissent dans le WUI sans avoir à faire un restart de QSync (d'ailleurs, je ne pense pas qu'il soit utile de relançer ce script)
Par ailleurs, dans mon cas, plus je rajoute (je parle en centaines) d'adresses, plus la page contenant la liste des filtres met de temps à se générer (cela me parait logique)

father_mande, le 09 janvier 2012 - 13:31 , dit :

... sachez que les iptables font (discrétement) leur apparition ... mais qu'en quelques lignes de shell, il est possible de les valider pour tous et tout le temps et avec quelques liens ... bien fait, de récupérer les fonctions save et restore ...

Alors là, je suis preneur, mais je n'arrive pas à mettre la main sur l'iPkg qui va bien. en même temps, la méthode que j'utilise me semble plus propre, car intégrée d'origine au firmware (au delta près de mon script)

[father_mande]

Bonjour,

Désolé ... je ne suis pas des plus clairs ... en ce moment (ha! les lendemains de fête ....)

La 3.6.0 apporte, entre autre, le support du VPN serveurs (pptp et Openvpn réduit à l'identification par user / password ... )
... pour ne pas à avoir a traiter les problémes de route ... surtout avec les priorités des tables de IProute2 .. QNAP a (enfin) intégré au noyau les modules pour Iptables et fourni les librairies ... DANS un usage UNIQUE, celui de faire du MASQUERADE (NAT) avec les adresses VPN ... donc tout accés du VPN est vu comme venant de l'I.P. réelle du QNAP ...

... Qnap fourni une version bridée des iptables ...
... bridée, car il n'y a que iptables ... mais ça c'est facile à régler ...
... de même il ne load les modules que pour le VPN ... bon il ne les remove pas ... c'est ça de pris ... mais les lancer soi-même ce n'est même pas 10 lignes de shell (inclus le test de dèjà présent ... )

Il y a donc (une fois en 3.6) deux options, utilisez les outils iptables des Ipkg ... ou mon préféré, créez les liens et ce qu'il faut pour utiliser le natif QNAP ...

... je suis en train de faire la liste des librairies ou outils manquants pour éventuellement les recompiler pour le noyau ...

Mais, je pense (en fait, je suis sur), qu'il est déjà possible d'utiliser quasiment tous les outils Iptables ...

Philippe.
BON, j'espére ne pas m'être emmélé les pinceaux, ce coup ci ...

[DocIn]

Bonsoir le forum!

Je viens de me rendre compte d'une des limitations de cette version d'ipfilter : pas possible de filtrer plus de 3080 addresses (une entrée "sys_set_ipsec_rules: len xxxxx is over 3080" apparait dans dmesg)

[Kristofas]

bonjour,

sur mon TS-219PII en administration, sécurité, protection d'accès réseau, j'ai tout mis sur 1mn, 5 fois et 1 jour sauf SSH sur toujours.
dès que je rallume mon PC portable sous Windows 7 64 bits, que se soit par l'explorateur (samba) ou par internet (HTTP) mon adresse IP local de mon PC est bloquée.
donc je ne peux plus accéder à mon NAS, sauf par mon smartphone ou je dois supprimer la ligne correspondant à mon IP dans l'onglet 'niveau de sécurité.'
dans 'journaux du système, journaux des évènement du système, je retrouve cette ligne 'Security] Access Violation from 192.168.1.23 with TCP (port=8080)' login fail.m
mais quand j'allume mon pc et je vais dans l'explorateur réseau Windows ne me demande pas mon loging.

auriez vous un idée de mon problème? merci.

[father_mande]

Bonjour,

A priori, si le message d'erreur est correct ... c'est des connexions au port administratif qui bloque ...
Le blocage étant au niveau I.P. ... dès que l'I.P. est bloqué ... elle l'est pour tout ... (si j'ai bien compris ??)

Avez-vous installé QGET et est-il bien configuré ?
Car lui se connecte (essaye) automatiquement au QNAP sur le port 8080 ...

Pourquoi bloquer votre PC principal et votre réseau Local ... a priori votre box ou router doit faire blocage de ce qui n'est pas systématiquement autorisé ?

Philippe.

[McCoy]

father_mande, le 09 janvier 2012 - 13:31 , dit :

... relancer ip_filter suffit pour mettre en place la nouvelle liste

Bonjour father_mande,

J'ai une cagade dans le fichier .config/ipsec.conf (qui peut-être me bloque l'accès à l'interface Web) que je pourrais corriger via vi. Une fois fait, comment relance-t-on ip_filter à partir de ssh ?

Cordialement

EDIT: j'ai trouvé la réponse dans un autre POST: /sbin/ip_filter ; /etc/init.d/qsyncman.sh restart

Modifié par McCoy, 21 février 2012 - 15:11 .

[father_mande]

Bonjour,

Toujours en mode question et ... 8 minutes plus tard Hourra ... réponse ....

Continuez ....

Philippe.

[DocIn]

Bonjour,

me revoilà avec mon QNAP à jour en 3.6
Je vais du coup retenter mon filtrage avec iptables, mais effectivement certains modules n'ont pas l'air chargés:

iptables -L
modprobe: could not parse modules.dep
iptables v1.4.12: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Une idée Philippe, toi qui à priori à déjà gratté un peu de ce côté (ça m’évitera quelques find, lsmod et autres joyeusetés)

Par avance, merci à toi

[father_mande]

Bonjour,

Les modules ne sont chargés QUE lorsqu'on valide VPN PPTP ou OpenVPN ... même si on ne les utilise PAS ...

Je prépare un QPKG pour mettre les iptables (et outils qui vont avec) à disposition même hors VPN.

Philippe.

[zabimaru27]

Bonjour
Une petite question , je parviens à me connecter à mon VPN de l'extérieur. (pptp)

Cepandant je ne vois pas mon l'an derrière lorsque je le scan.

Ma machine distante se retrouve avec une il du style 10.x.x.x

Comment accéder à mon l'an en 192.168.0.x ??????
Est ce qu'il y a une sorte de nat à configurer. Je n'ai pas trouver l'option.

Merci d'avance.

[father_mande]

Bonjour

Dans PPTP, il y a Point à Point ... donc un Point voit un autre Point et non un réseau ...
Vous créez donc un AUTRE réseau, qui par défaut sera en 10.0.0.x, soit 10.0.0.1 pour le serveur et 10.0.0.2 pour le premier client ... etc.

Pour que deux réseaux ... se voient ... il faut, au niveau du client, ajouter des règles de routage ... , sinon vous ne pouvez accéder qu'au serveur donc au 10.0.0.1
Il faut aussi que le réseau "local" du client ne soit pas dans la même plage d'adresse que le réseau local du Server
... en effet si votre client est en 192.168.1.x et le serveur en 192.168.1.y ... le réseau 10.0.0.0 ... sera utilisable ... mais pas l’accès en 192.168.1.y

il suffit donc d'ajouter un route pour le réseau 192.168.x.y via le VPN 10.0.0.2 (pour le premier client)
ex. sous Windows cela aura la forme de :
route add 192.168.1.0 mask 255.255.255.0 metric 2 (ajoutez -p pour le rendre permanent (résistant au reboot)

Il devrait être nécessaire de faire de même sur les machine du réseau local du VPN server ... MAIS ce n'est pas nécessaire, car QNAP a implanté une version limité de Iptables et fait du MASQUERADE (NAT Network Adress Translation) ... donc, les machines du réseau voit les connexions arriver avec l'adresse IP du QNAP server VPN et non avec l'adresse du réseau VPN ...

Il reste un dernier point, c'est si vous souhaitez accéder au QNAP serveur VPN non pas en 10.0.0.1 mais avec son adresse locale ... en plus du routage, il faudra dans le QNAP autoriser les adresses dans les routes (iproute2) car QNAP a ajouté une table limitant les accès aux machines du réseau ...

Il y a un post détaillé sur le forum Anglais (je l'ai écrit ) ... mais je n'ai pas accès en ce moment, pour vous donner le lien ...

Philippe.