Port knocking

[MaxPecas]

Bonjour,

Je voulais savoir si quelqu'un avait testé le port knocking sur IPCOP.
Si tel est le cas, j'aimerais avoir des conseils voire un mini tuto car j'ai décidé de me lancer dans l'aventure et mes connaissances linux sont encore un peu médiocre.

Merci à tous

[ccnet]

Le problème n'est pas les connaissances linux, mais celles de tcpip en général.
Sinon, je ne m'y risquerai pas. Trop dangereux.

[jdh]

Ah la lecture de Gnu Linux magazine (ou de ses hors série) !

Comme première question, c'est étonnant (tout comme le pseudo : pas vraiment lié à la sécurité !).


En fait, le concept de "port knocking" est en apparence intéressant et attractif. (Il y a des variantes du principe avec SPA : plus sur encore !)

Avant de mettre en route cela, il faut d'abord regarder si de grands fabricants mettent cela en oeuvre (Checkpoint, Cisco, Arkoon ?, ...).

Le port knocking semble plutôt une "astuce" destinée à des firewalls "maison" ...

[ccnet]

Oui, en effet c'est le type même de l'astuce (on ne peut pas aller cela autrement) intéressante en apparence.

[MaxPecas]

Bonjour,

Merci pour votre réponse.



J'ai mis en place un IPCOP dans une petite structure (<10PC). Ceci dans le cadre d'un projet que je dois rendre à la fin de l'année.

Apparemment ( Selon GNU linux, car c'est en effet par sa faute que j'ai connu le concept), il faut installer le demon knockd.
Ma question est la suivante: puis-je installer et configurer ce démon sur mon IPCOP.

Pour répondre à JDH:

Pourquoi est-il important de savoir si de grands fabricants mettent ça en œuvre? Est-ce que cela peut avoir une incidence sur mon projet?

Le port knocking apporterait un plus indéniable à mon projet et l'idée me semble ingénieuse et très sûre pour une petite structure.

En tous cas merci pour vos réponses

[ccnet]

Bonjour,
Ma question est la suivante: puis-je installer et configurer ce démon sur mon IPCOP.

Je ne m'y risquerai pas. Ipcop est conçu comme un tout cohérent pour lequel il existe des addons en général bien pensés et bien réalisés. A ma connaissance ce daemon n'en fait pas partie. La solidité d'Ipcop pourrait en pâtir lourdement.

Pourquoi est-il important de savoir si de grands fabricants mettent ça en œuvre? Est-ce que cela peut avoir une incidence sur mon projet?

Si ces constructeurs ne les utilisent pas c'est qu'il y a une raison. Or ils sont spécialisés dans les produits de sécurité.

Le port knocking apporterait un plus indéniable à mon projet et l'idée me semble ingénieuse et très sûre pour une petite structure.
En tous cas merci pour vos réponses

Si vous nous disiez quel est le projet on pourrait en discuter plus avant. Pour le moment nous ne comprenons pas ce qui vous motive pour mettre en place cela. C'est toujours intéressant de comprendre.

Sinon je ne vois pas en quoi une solution peut être sûre pour une petite structure et pas pour une grande, ou l'inverse. Je connais des structures très petites qui ont des besoins de sécurité au plus haut niveau et d'autres beaucoup plus grandes dont les besoins sont basiques.

[jdh]

Globalement, je confirme ce qu'écrit ccnet : il a généralement (toujours ?) un avis très juste et approprié !


Cette "ruse" est intellectuellement satisfaisante. Ceci est incontestable. (Il y a mieux encore ...).

Comme il n'existe pas d'addons pour IPCOP, cela n'est pas envisageable, bien sur !

(Il semble exister un addon =doorman pour pfSense dans une version de test !).


De façon pratique, cela peut être utilisé pour qui construit lui-même son firewall. Par exemple à partir d'une Debian et en utilisant Shorewall (le firewall de feu MNF !).

[MaxPecas]

Resalut,

Merci pour la clarté des réponses.

Je prépare la soutenance d'un projet pour un diplôme en maintenance informatique et réseau.
Ceci me semblait intéressant -compte tenu de la structure dans laquelle je met en place le projet -pour la raison suivante que les utilisateurs sont peu nombreux. L'avantage qui en découle, est que la communication avec les utilisateurs s'en trouve privilégiée.
Or, cette solution implique que les utilisateurs soient formés ou tout du moins averti quant à la marche à suivre pour se connecter au serveur.

En tous cas, s'il n'existe pas d'addon ou de daemon tel que "knockd" sur IPCOP je ne me lancerai pas dans l' aventure.



A bientôt sans doute sur le forum où vous risquez de tomber sur d'autres de mes questions insolites.

Merci

[ccnet]

Si les besoins sont du type accès à distance, alors le vpn Zerina me semble raisonnable. C'est simple, d'une stabilité de fonctionnement remarquable (j'ai des utilisateurs du type "redoutables" qui en sont contents) et c'est administrable facilement (création, désactivation, révocation).

[Franck78]

En tous cas, s'il n'existe pas d'addon ou de daemon tel que "knockd" sur IPCOP je ne me lancerai pas dans l' aventure.

Petit joueur va
Il n'y a pas de raison pour échouer à obtenir un addon "bien pensé et bien réalisé" qui ne remette pas en cause IPcop.

C'est vrai que ccnet est souvent objectif (dixit jdh) mais la je trouve sa phase objectivement fausse:

Je ne m'y risquerai pas. Ipcop est conçu comme un tout cohérent pour lequel il existe des addons en général bien pensés et bien réalisés. A ma connaissance ce daemon n'en fait pas partie. La solidité d'Ipcop pourrait en pâtir lourdement.

Peu importe qui est visé par le 'je'. Ce qui est sur c'est que d'autres corrigeront le tir si vraiment il y a une erreur.

Franck

[ccnet]

Il n'y a pas de raison pour échouer à obtenir un addon "bien pensé et bien réalisé" qui ne remette pas en cause IPcop.

C'est vrai que ccnet est souvent objectif (dixit jdh) mais la je trouve sa phase objectivement fausse:

Franck

Je pense aussi que c'est réalisable (même si je n'aime pas beaucoup le port knocking) et réalisable proprement mais quelle raclée si ce n'est pas impeccable ! Mon ignorance me rend prudent. J'ai quand même écris au conditionnel.

[MaxPecas]

Ok messieurs,

Si Franck78 a des conseils pour me mettre sur la voie je suis preneur.

[Gesp]

Je vais donner mon opinion.

Apparemment ( Selon GNU linux, car c'est en effet par sa faute que j'ai connu le concept), il faut installer le demon knockd.

Si tu n'as pas ouvert de ports (pour une maintenance par l'extérieur), pas besoin de cacher des ports ouverts.

Quand on rajoute un démon, on rajoute un risque avant même de considérer si c'est contrebalancé par une protection supérieure dans un domaine particulier.
A la place de se poser la question 'Me faut-il du port-knocking sur tel port que j'ai ouvert à l'extérieur?', ne faut-il pas d'abord se poser la question 'Ai-je réellement besoin d'ouvrir ce port?'

Je conçois que la réponse à la question 'Ai-je réellement besoin d'ouvrir ce port?' soit de temps en temps 'oui' pour des questions de facilité de maintenance même si tout le monde sait que ce n'est pas nécessairement recommandé.

Après avoir considéré ce préalable, il y a grosso-modo 4 moyens de protection :
- le port-knocking (cacher les ports ouverts)
- fail2ban (repérer dans les logs les tentatives de connexion et agir avec des règles Iptables)
- simplement utiliset l'extension recent d'Iptables du genre (pas vérifié que c'est la syntaxe exacte qui marche en noyau 2.4, adapté au port SSH d'IPCop)
iptables -A INPUT -p tcp --syn --dport 222 -m recent --update --seconds 300 --hitcount 2 --name SSH -j DROP
iptables -A INPUT -p tcp --syn --dport 222 -m recent --set --name SSH -j ACCEPT
Cela drope pendant 300 s le trafic d'une IP si la troisième tentative de connexion n'a pas dépassé l'état syn.
- snort (plus guardian), c'est la grosse artillerie qui nécessite 80M de mémoire par interface pour son fonctionnement

Disons que la troisième solution me parait la plus intéressante pour le cas général, en terme de résultat/coût parce que utilisant un minimum de ressources.
Il n'y a pas de démon supplémentaire en fonctionnement ou de parcours permanent des logs (avec fail2ban). Le ban est temporaire, ce qui limite la possibilité de DOS (tant que l'attaque n'est pas permanente). Pour IPCop, il faudrait juste rajouter une case à cocher enable et une boite pour saisir la valeur de la durée du ban.

Le port-knocking n'est pas un système intrinsèquement sûr, c'est de la sécurité par obscurité en masquant des ports ouverts.
Le système distant transmettant en clair le signal sur les ports à frapper avant d'entrer, quiconque peut écouter le trafic entrant lors d'une connexion fructueuse connait le secret et peut le répliquer.
Je suis d'accord que la plupart du temps, le script-kiddies n'a pas cette capacité d'écouter le trafic et donc de ce fait, le port-knocking permet au moins d'avoir des logs plus légers.
Apparement il existe une évolution du port-knocking qui serait plus sùre (voir le détail dans http://www.cipherdyne.org/fwknop/docs/SPA.html ) fwknop devrait être disponible sur Fedora 10.

[MaxPecas]

Merci Gesp pour tes explications.

Si j'ai bien compris la troisième solution, une IP est bannie de connexion SSH pendant 5 minutes après 3 tentatives infructueuse.

Ceci est intéressant

Merci

[Gesp]

Si j'ai bien compris la troisième solution, une IP est bannie de connexion SSH pendant 5 minutes après 3 tentatives infructueuse.

Oui
Cela me parait suffisant pour alléger les logs des attaques simples, sans pour autant risquer grand-chose du genre dénis de service. Au pire, on ne peut pas se connecter à distance si la machine est testée en permanence avec l'IP contrefaite de notre machine distante.

Pour l'interface web, je vois bien cela dans les options firewall. Cela fait longtemps que j'ai prévu de le faire mais il y a tellement de choses à faire.
Il faut aussi trouver la bonne syntaxe iptables, je me souviens avoir déjà testé et qu'il y avait de petites variations entre la syntaxe 2.6 et celle en 2.4.

Pour accrocher cela proprement dans Iptables, il vaut voir où ajouter du code dans
http://ipcop.cvs.sourceforge.net/viewvc ... PCOP_v1_4_ .

Si tu veux tester tout cela et me faire un patch de la modif, je suis preneur.

Pour fwknop, c'est certainement plus sophistiqué mais il y a pas mal de prérequis coté logiciel.
Donc cela doit être beaucoup moins simple à installer que knockd.