Mais le problème est que si c'est fait de manière automatique, le pirate peux toujours trouver une faille avant la signature, et donc la signature seras correcte... ou alors il faudrait demander à chaque validation/signature d'un article de taper la passphrase, ce qui est trops fastidieux... Surtout que le pirate peut encore une fois obtenir la passphrase, on ne sait jammais.
Et si un site comme yahoo pensse qu'une de ses clefs n'est plus sure, il devras générerune clef de révocation suivie d'une nouvelle clef... Tu parles d'un bordel...
Certes ton iddée est bonne, elle offre un certain degré de confiance, mais ne peut garantir à 100% l'integritée des infos... Mais ce serais tout de même plus sur que maintenant...
oui, c'est très pratique, et TRES TRES difficile à détecter... Mais là, je ne connait pas la portée juridique de ce genre de choses... Si c'est utilisé dans un but malveillant, c'est sur c'est interdit, mais pour s'échanger des messages? Ca peut s'apparenter à de la dissimulation, non?
attention, je n'ai pas dit que PF n'étais pas bien, et ne gère pas les groupes...
Quand à vérifier les règles avant de les modifier/ajouter dynamiquement, si tu te contente d'interdire une IP en haut de la chaine, il n'y a pas de problèmes...
C'est vrai qu'en ce moment, avec la campagne de pub Américaine : "La crypto c'est *mal*, les vilains terroristes ils l'ont utilisés", c'est pas le moment... Et c'est véhiculé par tous les médias, les médias Français en premier (qu'ils soient publics ou privés). Je comprends la réaction des américains, mais ca ne changeras pas le problème... Les terroristes utiliseront toujours des strong crypto, même si c'est interdit...
D'où l'iddée des backdoors... Mais le problème deviens alors : "qui vas avoir un full accèss sur toutes les données que l'on croirat pourtant protégées? Ne peut-il y avoir d'abus? Qu'est-ce qui me garanti que la firme concurente à la mienne ne connait pas le backdoor, ce qui vas lui permettre d'accéder à toutes mes infos secrètes?". Le débat est compliqué... Mais cela ne doit, à mon avis, en rien bloquer cette action de pétition...
Depuis des années on nous promet cette libéralisation, Lionel Jospin l'as même promis à la télé, et là, on se retrouves avec des prémices de volontées, noyés dans un texte avec d'autres choses qui n'ont strictement rien à voir... Et quand on a lu le tout, c'est limite si le résultat n'est pas inverse à l'effet escompté...
Il ne faut pas oublier que ce fameux 'bug' d'IPTables est du à un problème venant directement d'un protocole connu pour être mal concu et connu aussi pour être la plaie des firewalls et de leurs administrateurs... Je n'excuses pas ce bug/security_flaw, je dis juste qu'un bug concernant un protocole problématique dans la jeunesse d'un firewall ne doit pas t'ammener à rayer Netfilter de la liste des bons firewalls.
Quand à savoir si ce qu'a dit Fabien sur Netfilter est vrai, c'est très compliqué, car très subjectif. Mais l'on peut parler de certains avantages de netfilter sur ses concurents directs :
*/ modularitée/flexibilitée qui permet d'étendre les fonctions/targets.
*/ système de chaines très pratique et très fonctionnel
*/ statefull
*/ permet de matcher les adresses mac
*/ système de matching par limites, pour éviter les DDOS par exemple (système inteligent : edge et limit-burst)
*/ matching par owner (propriétaire), cad la personne qui a créé le paquet...
*/ rajout de targets (notement LOG qui est très pratique pour la lisibilitée de ses fichiers de logs...)
Attention, je n'ai pas dit qu'il était le seul à posséder ces attributs (ie de nombreux firewalls sont statefull de nos jours), juste qu'il a l'avantage de les réunir tous, et d'être facilement extenssible.
avec netfilter, tu peux toujours utiliser le couple iptables-save/iptables-restore (existe aussi pour ipchains) qui permet de sauver tes règles actuelles dans un fichier pour les recharger après...
exemple :
'iptables-save > mes_reges_a_moi' pour sauver et 'iptables-restore < mes_reges_a_moi' pour restaurer... ca sauve toutes les règles, user-defined chains, defaults policies, et autres...
Non, ce n'étais pas si simple que tu peux le pensser... Les auteurs d'OpenSSH (les auteurs, pas les porteurs) ont utilisés des propriétées propres à OpenBSD et à son noyeau en codant, entres autres au niveau de la génération de nombres aléatoires non prédictibles, mais aussi de la génération de digests et autres fingerprints (genre md5, ...). Et les porteurs se sont faits chier pour porter certains algos vers des systèmes qui n'avaient pas de tels générateurs... D'ailleurs dans certains cas, ils ont utilisés des algos plutots moyens...
OpenSSH est donc vachement plus secure sous OpenBSD que la version portée, et oui monssieur (et je fait pas de troll à 3 francs, les gens ici qui me connaissent savent que je suis plutôt pro-Linux que l'inverse).
les fichiers de conf ont clairement des avantages, mais le fait qu'iptables (et son prédécesseur, ipchains, ce qui n'est pas étonnant, car c'est la même personne, Rusty Russel, qui est l'auteur des deux outils) soit sous forme de programme permet un plus grand dynamisme. Je m'explique : je créé une chaine "mechants" qui contient des règles pour bloquer les vilains qui foutent leurs doigts où il faut pas (finger, netbios-ssn, rpc et consors...). je peux facilement dans mon cron ou avec atd flusher cette chaine quand je le veux... Et pluis il est plus facile/pratique de lancer une commande depuis un script/programme que de modifier un fichier de conf puis de le faire relire par le programme adéquate... Ce n'est qu'un exemple simpliste, car les aplications sont nombreuses... Enfin c'est mon avis, et ca n'engage que moi.
Je vais rechercher justement un mail ou Rusty Russel (le 'kernel_firewall_hacker' ou 'iptables/netfilter_hacker', au choix) expliques ce choix d'une commande et non d'un fichier de conf... C'est relativement interessant à lire...
Dans le même esprit, ceux qui sont interessés par netfilter/iptables peuvent lire http://netfilter.samba.org/unreliable-guides/netfilter-hacking-HOWT(...) : "The Linux netfilter Hacking HOWTO"...
Allez aussi jeter un oeuil sur http://netfilter.samba.org/unreliable-guides/(...) , c'est très interessant...
[^] # Re: Signer avec GPG une page web ?
Posté par _PinG _ . En réponse à la dépêche un pirate falsifie une info de Yahoo. Évalué à 10.
gpg --clearsign fichier
Mais le problème est que si c'est fait de manière automatique, le pirate peux toujours trouver une faille avant la signature, et donc la signature seras correcte... ou alors il faudrait demander à chaque validation/signature d'un article de taper la passphrase, ce qui est trops fastidieux... Surtout que le pirate peut encore une fois obtenir la passphrase, on ne sait jammais.
Et si un site comme yahoo pensse qu'une de ses clefs n'est plus sure, il devras générerune clef de révocation suivie d'une nouvelle clef... Tu parles d'un bordel...
Certes ton iddée est bonne, elle offre un certain degré de confiance, mais ne peut garantir à 100% l'integritée des infos... Mais ce serais tout de même plus sur que maintenant...
[^] # Re: oui mais non...
Posté par _PinG _ . En réponse à la dépêche Le OpenBSD Packet Filter HOWTO est sorti. Évalué à 1.
[^] # Re: Est-ce le bon moment ?
Posté par _PinG _ . En réponse à la dépêche Campagne pour la libéralisation de la cryptographie. Évalué à 1.
[^] # Re: oui mais non...
Posté par _PinG _ . En réponse à la dépêche Le OpenBSD Packet Filter HOWTO est sorti. Évalué à 1.
Quand à vérifier les règles avant de les modifier/ajouter dynamiquement, si tu te contente d'interdire une IP en haut de la chaine, il n'y a pas de problèmes...
[^] # Re: Est-ce le bon moment ?
Posté par _PinG _ . En réponse à la dépêche Campagne pour la libéralisation de la cryptographie. Évalué à 4.
D'où l'iddée des backdoors... Mais le problème deviens alors : "qui vas avoir un full accèss sur toutes les données que l'on croirat pourtant protégées? Ne peut-il y avoir d'abus? Qu'est-ce qui me garanti que la firme concurente à la mienne ne connait pas le backdoor, ce qui vas lui permettre d'accéder à toutes mes infos secrètes?". Le débat est compliqué... Mais cela ne doit, à mon avis, en rien bloquer cette action de pétition...
Depuis des années on nous promet cette libéralisation, Lionel Jospin l'as même promis à la télé, et là, on se retrouves avec des prémices de volontées, noyés dans un texte avec d'autres choses qui n'ont strictement rien à voir... Et quand on a lu le tout, c'est limite si le résultat n'est pas inverse à l'effet escompté...
[^] # Re: Portage Linux?
Posté par _PinG _ . En réponse à la dépêche Le OpenBSD Packet Filter HOWTO est sorti. Évalué à 5.
Quand à savoir si ce qu'a dit Fabien sur Netfilter est vrai, c'est très compliqué, car très subjectif. Mais l'on peut parler de certains avantages de netfilter sur ses concurents directs :
*/ modularitée/flexibilitée qui permet d'étendre les fonctions/targets.
*/ système de chaines très pratique et très fonctionnel
*/ statefull
*/ permet de matcher les adresses mac
*/ système de matching par limites, pour éviter les DDOS par exemple (système inteligent : edge et limit-burst)
*/ matching par owner (propriétaire), cad la personne qui a créé le paquet...
*/ rajout de targets (notement LOG qui est très pratique pour la lisibilitée de ses fichiers de logs...)
Attention, je n'ai pas dit qu'il était le seul à posséder ces attributs (ie de nombreux firewalls sont statefull de nos jours), juste qu'il a l'avantage de les réunir tous, et d'être facilement extenssible.
[^] # Re: Portage Linux?
Posté par _PinG _ . En réponse à la dépêche Le OpenBSD Packet Filter HOWTO est sorti. Évalué à 2.
exemple :
'iptables-save > mes_reges_a_moi' pour sauver et 'iptables-restore < mes_reges_a_moi' pour restaurer... ca sauve toutes les règles, user-defined chains, defaults policies, et autres...
[^] # Re: Portage Linux?
Posté par _PinG _ . En réponse à la dépêche Le OpenBSD Packet Filter HOWTO est sorti. Évalué à 6.
OpenSSH est donc vachement plus secure sous OpenBSD que la version portée, et oui monssieur (et je fait pas de troll à 3 francs, les gens ici qui me connaissent savent que je suis plutôt pro-Linux que l'inverse).
[^] # oui mais non...
Posté par _PinG _ . En réponse à la dépêche Le OpenBSD Packet Filter HOWTO est sorti. Évalué à 5.
Je vais rechercher justement un mail ou Rusty Russel (le 'kernel_firewall_hacker' ou 'iptables/netfilter_hacker', au choix) expliques ce choix d'une commande et non d'un fichier de conf... C'est relativement interessant à lire...
Dans le même esprit, ceux qui sont interessés par netfilter/iptables peuvent lire http://netfilter.samba.org/unreliable-guides/netfilter-hacking-HOWT(...) : "The Linux netfilter Hacking HOWTO"...
Allez aussi jeter un oeuil sur
http://netfilter.samba.org/unreliable-guides/(...) , c'est très interessant...