Le 22/10/2012 09:47, cam.lafit@azerttyu.net a écrit :
Ciao
Coucou
[../..]
J'ai vu des initiatives comme http://www.blocklist.de qui fournit une approche de communauté de serveur, je me dit que cela ne doit pas être la seule et m'intérroge sur leur pertinence. Je me demande aussi comment vous vous gérez en interne ce genre de liste et comment vous les interfacez avec vos scripts.
Personnellement je n'utilise blocklist.de (et dshield.org également) que pour la partie reporting. Après concernant la mutualisation je ne serai pas vraiment chaud pour ça ;) A moins de bien connaitre et maitriser les peers avec qui tu mutualises ces informations ça peut vite se retourner contre toi ...
C'est un pue comme les RBL pour le scoring du spam, si tu ne maitrises pas le RBL difficile de lui faire confiance ;)
My 2cts Renaud
Ciao
Personnellement je n'utilise blocklist.de (et dshield.org également) que pour la partie reporting.
Ok
Après concernant la mutualisation je ne serai pas vraiment chaud pour ça ;) A moins de bien connaitre et maitriser les peers avec qui tu mutualises ces informations ça peut vite se retourner contre toi ...
C'est un pue comme les RBL pour le scoring du spam, si tu ne maitrises pas le RBL difficile de lui faire confiance ;)
Dans le cas des RBL je citais block.de car il semble s'appuyer uniquement sur une communauté de log fail2ban. Dans la question, je penais plutôt à une gestion propre de RBL via une liste de pairs maitrisés. Dans ce cas je me demande comment optimiser l'échange entre ces pairs. Est ce qu'une sorte d' API dns, requete http, ou du genre rsyslog
Peut être aussi que cela n'a aucun sens et qu'il vaut mieux laisser chaque pair faire sa vie.
Km
Le 22/10/2012 15:08, cam.lafit@azerttyu.net a écrit :
Ciao
Personnellement je n'utilise blocklist.de (et dshield.org également) que pour la partie reporting.
Ok
Après concernant la mutualisation je ne serai pas vraiment chaud pour ça ;) A moins de bien connaitre et maitriser les peers avec qui tu mutualises ces informations ça peut vite se retourner contre toi ...
C'est un pue comme les RBL pour le scoring du spam, si tu ne maitrises pas le RBL difficile de lui faire confiance ;)
Dans le cas des RBL je citais block.de car il semble s'appuyer uniquement sur une communauté de log fail2ban. Dans la question, je penais plutôt à une gestion propre de RBL via une liste de pairs maitrisés. Dans ce cas je me demande comment optimiser l'échange entre ces pairs. Est ce qu'une sorte d' API dns, requete http, ou du genre rsyslog
Peut être aussi que cela n'a aucun sens et qu'il vaut mieux laisser chaque pair faire sa vie.
Km
Une première piste :
http://www.kloth.net/internet/dnsbl-howto.php
Avec qq lignes supplémentaires : - Tu interroges ton serveur DNS pour savoir si l'IP blacklistée est dedans - Si elle n'est pas présente tu ajoutes ton entrée via un accès remote avec un truc du genre : http://www.howtoforge.com/forums/showthread.php?t=53039
Cordialement,
Hello,
Le 22 oct. 2012 à 16:23, jean-yves@lenhof.eu.org a écrit :
(...)
Une première piste :
http://www.kloth.net/internet/dnsbl-howto.php
Avec qq lignes supplémentaires :
- Tu interroges ton serveur DNS pour savoir si l'IP blacklistée est dedans
- Si elle n'est pas présente tu ajoutes ton entrée via un accès remote avec un truc du genre :
Bon c'est sympa, mais quitte à lancer un pavé dans la marre.... Quid des IPv6 ?
Si 2001:db8:1337::dead:beef arrive a ton fail2ban tu colles quoi dans ta RBL : - l'ip en /128 ? - le subnet en /64 ? - le subnet en /56 ? - ?
Parce que bon quand en SLAAC tu as un /64 chez certains fournisseurs, voire un /56 ou /48... Quid de l'utilité (ou inutilité) d'une RBL en IPv6...
/Xavier PS: ceux qui disent que l'IPv6 ne sert à rien qu'ils essayent de demander un PI IPv4 au RIPE ... :)
Et pourtant, une solution toute simple serait que chaque FAI indique la taille du subnet IPv6 attribué aux end-users, dans son whois (l'idée est passée ici il y a quelques temps).
Le 22/10/12, Xavier Beaudouinkiwi@oav.net a écrit :
Hello,
Le 22 oct. 2012 à 16:23, jean-yves@lenhof.eu.org a écrit :
(...)
Une première piste :
http://www.kloth.net/internet/dnsbl-howto.php
Avec qq lignes supplémentaires :
- Tu interroges ton serveur DNS pour savoir si l'IP blacklistée est
dedans
- Si elle n'est pas présente tu ajoutes ton entrée via un accès remote
avec un truc du genre : http://www.howtoforge.com/forums/showthread.php?t=53039
Bon c'est sympa, mais quitte à lancer un pavé dans la marre.... Quid des IPv6 ?
Si 2001:db8:1337::dead:beef arrive a ton fail2ban tu colles quoi dans ta RBL :
- l'ip en /128 ?
- le subnet en /64 ?
- le subnet en /56 ?
- ?
Parce que bon quand en SLAAC tu as un /64 chez certains fournisseurs, voire un /56 ou /48... Quid de l'utilité (ou inutilité) d'une RBL en IPv6...
/Xavier PS: ceux qui disent que l'IPv6 ne sert à rien qu'ils essayent de demander un PI IPv4 au RIPE ... :) _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 22/10/2012 16:46, Xavier Beaudouin a écrit :
Bon c'est sympa, mais quitte à lancer un pavé dans la marre.... Quid des IPv6 ?
Si 2001:db8:1337::dead:beef arrive a ton fail2ban tu colles quoi dans ta RBL :
- l'ip en /128 ?
- le subnet en /64 ?
- le subnet en /56 ?
- ?
Parce que bon quand en SLAAC tu as un /64 chez certains fournisseurs, voire un /56 ou /48... Quid de l'utilité (ou inutilité) d'une RBL en IPv6...
/Xavier
Fail2ban ne sait pas gérer l'ipv6, pour être plus précis les jails savent lancer que iptables ou shorewall mais pas les versions v6 ip6tables et shorewall6. Certes on peut changer la commande mais du coup on choisit entre v4 et v6...
Pour ce qui est à banir, je dirais le plus petit subnet attribuable soit /64. Vu qu'une liaison fai, un loueur de serveur, ... ne sont pas sensé te donner moins que /64 c'est que tu as forcément à faire à une seule et même entité.
Après si l'ip fait parti d'un bloc plus grand, ma fois c'est qu'il n'en est pas digne si il fait des bétises ou si il est vérolé dans tous les sens et en plus en ipv6...
PS: ceux qui disent que l'IPv6 ne sert à rien qu'ils essayent de demander un PI IPv4 au RIPE ... :)
Les PI c'est fini depuis longtemps, la seule solution c'est d'être ton propre LIR avec les coups que cela comporte... Bien regarder d'ailleurs les nouveaux montants de cotisation à partir de janvier, les small LIR ont pris une sacrée augmentation.
De mon côté ayant besoin de refaire mon architecture à cause d'un fournisseur de serveur défaillant niveau réseau, j'en profite pour faire sauter l'adresse ipv4 interne et tout passer en ipv6. C'est pas gagné, j'espère ne pas être bloqué sous peu par des softs en production, déjà pour la métrologie Munin ne sait pas correctement se mettre en ipv6 ...
Bonjour,
Le 22 oct. 2012 à 17:14, Wallace a écrit :
Pour ce qui est à banir, je dirais le plus petit subnet attribuable soit /64. Vu qu'une liaison fai, un loueur de serveur, ... ne sont pas sensé te donner moins que /64 c'est que tu as forcément à faire à une seule et même entité.
Je plussoie sur ce point. Le minimum à bloquer est le /64. C'est le plus grand préfixe pour lequel on puisse supposer qu'il est géré par une entité administrative unique. Si un administrateur réseau ne sait pas contrôler ce qu'il se passe sur son réseau, c'est son problème. On peut même dire que l'on met généralement un /64 IPv6 là où en IPv4 on met une adresse IPv4 unique (connexion résidentielle NATée par exemple). Certains opérateurs attribuent des plus petits préfixes (/127 pour l'interco ou des liaisons point-à-point), dans ce cas ce sont des préfixes qui n'auraient jamais dû se retrouver dans les internets. Bloquer au /128 reviendrait à flooder son propre parefeu et on va pouvoir transformer un simple bruteforce SSH en une magnifique attaque DoS à moindre coût.
Le 22/10/2012 16:46, Xavier Beaudouin a écrit :
Bon c'est sympa, mais quitte à lancer un pavé dans la marre.... Quid des IPv6 ?
Si 2001:db8:1337::dead:beef arrive a ton fail2ban tu colles quoi dans ta RBL :
- l'ip en /128 ?
- le subnet en /64 ?
- le subnet en /56 ?
- ?
Parce que bon quand en SLAAC tu as un /64 chez certains fournisseurs, voire un /56 ou /48... Quid de l'utilité (ou inutilité) d'une RBL en IPv6...
Sur ce point, j'en discutais récemment avec un collègue, et dans l'attente d'une solution supportée et déployée par tout le monde, on peut imaginer un palliatif: - On stocke tous les /64 à l'origine d'une attaque (SSH, spam, etc) dans une base de donnée adaptée - A chaque nouvelle entrée, on calcule sa proximité avec les autres entrées, si plus de x% de /64 bloquées dans le /60 conteneur depuis un temps n, la granularité monte au /60, et on remonte comme ça jusqu'au /48 L'algo est simple, je pense en faire un proto un de ces jours si ça n'existe pas encore.
Cordialement Emmanuel Thierry
Salut,
Vu qu'une liaison fai, un loueur de serveur, ... ne sont pas sensé te donner moins que /64 c'est que tu as forcément à faire à une seule et même entité.
Je plussoie sur ce point. Le minimum à bloquer est le /64. C'est le plus grand préfixe pour lequel on puisse supposer qu'il est géré par une entité administrative unique. Si un administrateur réseau ne sait pas contrôler ce qu'il se passe sur son réseau, c'est son problème. On peut même dire que l'on met généralement un /64 IPv6 là où en IPv4 on met une adresse IPv4 unique (connexion résidentielle NATée par exemple). Certains opérateurs attribuent des plus petits préfixes (/127 pour l'interco ou des liaisons point-à-point), dans ce cas ce sont des préfixes qui n'auraient jamais dû se retrouver dans les internets. Bloquer au /128 reviendrait à flooder son propre parefeu et on va pouvoir transformer un simple bruteforce SSH en une magnifique attaque DoS à moindre coût.
Je vais me faire l'avocat du diable en tant que LIR.
Pour avoir du SLAAC un /64 est obligatoire. Mais dans le cas d'une IP fixe traditionnelle tu peux te mettre un /128 (type routage anycast) voire du /127 cas de liaison PtP :)
Et c'est pas parce que on utilise des /128 ou /127 (en ipv6) qu'ils vont se trouver dans les internets (sic). Regarde ce qu'il se fait avec l'ipv4...
Donc un /64 n'est pas le plus grand prefixe que peux avoir dans un réseau.
Et on parlais de RBL donc de protection "logicielle".... Pas de protection firewall.... (en passant il y a des firewalls qui se demerdent bien avec /128 en ACL...).
Xavier
Bonjour,
Le 23 oct. 2012 à 14:48, Xavier Beaudouin a écrit :
Je plussoie sur ce point. Le minimum à bloquer est le /64. C'est le plus grand préfixe pour lequel on puisse supposer qu'il est géré par une entité administrative unique. Si un administrateur réseau ne sait pas contrôler ce qu'il se passe sur son réseau, c'est son problème. On peut même dire que l'on met généralement un /64 IPv6 là où en IPv4 on met une adresse IPv4 unique (connexion résidentielle NATée par exemple). Certains opérateurs attribuent des plus petits préfixes (/127 pour l'interco ou des liaisons point-à-point), dans ce cas ce sont des préfixes qui n'auraient jamais dû se retrouver dans les internets. Bloquer au /128 reviendrait à flooder son propre parefeu et on va pouvoir transformer un simple bruteforce SSH en une magnifique attaque DoS à moindre coût.
Je vais me faire l'avocat du diable en tant que LIR.
Pour avoir du SLAAC un /64 est obligatoire. Mais dans le cas d'une IP fixe traditionnelle tu peux te mettre un /128 (type routage anycast) voire du /127 cas de liaison PtP :)
Et c'est pas parce que on utilise des /128 ou /127 (en ipv6) qu'ils vont se trouver dans les internets (sic). Regarde ce qu'il se fait avec l'ipv4...
Donc un /64 n'est pas le plus grand prefixe que peux avoir dans un réseau.
Je suis d'accord, ce n'est pas le plus grand préfixe possible. Moi même pour fournir de la connectivité IPv6 à des VMs sur un serveur j'ai redécoupé un /64 en plusieurs réseaux. Par contre on peut considérer raisonnablement que j'étais l'administrateur de ce /64 et que j'étais responsable de ce qui se passait sur mon /64.
Concernant les /127 utilisés pour les interco ou les liens PtP, ce sont des IPs dédiées à l'opération de ton service d'opérateur et ne sont pas sensées sortir de ton AS, ou pour des cas très spécifiques liées à l'opération du réseau, est-ce que je me trompe ? Je ne vois justement pas de cas concret dans lequel un client pourrait utiliser de toute bonne foi son /128 attribué par son opérateur pour envoyer un mail. C'est pour cela que si je reçois un spam venant d'une IPv6 j'ai bien envie de bannir le /64 parce que: - si le client final a reçu un /64 de son opérateur il est responsable de ce qui se passe dessus - si le client final a reçu un /128 de son opérateur il n'était pas sensé l'utiliser pour ce genre de choses (?) Est-ce que j'ai raté un bout de ton explication sur l'utilisation des /128 dans la vraie vie ?
Et on parlais de RBL donc de protection "logicielle".... Pas de protection firewall.... (en passant il y a des firewalls qui se demerdent bien avec /128 en ACL...).
Cela dépend de ce que tu entends par "se démerder avec des /128". Je veux bien admettre que les firewall acceptent des règles définies sur des adresses /128, mais que ce soit une protection logicielle ou un firewall je ne pense pas qu'ils supportent que l'on ajoute successivement à leur banlist tous les /128 d'un /64 (parce que l'attaquant aura changé d'interface ID entre chaque scan). C'est pour cela que ça me paraissait assez inenvisageable de bannir sur la base du /128, rien que la quantité de mémoire nécessaire pour stocker cette information est faramineuse. C'est en cela que filtrer sur la base du /128 donnerait à mon sens une capacité de nuisance faramineuse à un attaquant.
Cordialement Emmanuel Thierry
-
cam.lafit＠azerttyu.net -
Emmanuel Thierry -
jean-yves＠lenhof.eu.org -
Renaud RAKOTOMALALA -
Rémi Bouhl -
Wallace -
Xavier Beaudouin