Re: [FRsAG] Gérer sa communauté d'ip RBL (fail2ban et consorts)
Le 22/10/2012 09:47, cam.la...@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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Gérer sa communauté d'ip RBL (fail2ban et consorts)
Le 22/10/2012 15:08, cam.la...@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, ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Gérer sa communauté d'ip RBL (fail2ban et consorts)
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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Gérer sa communauté d'ip RBL (fail2ban et consorts)
+--On 22 octobre 2012 09:47:55 +0200 cam.la...@azerttyu.net wrote: | Ciao | | Pour commencer la semaine je m'interroge sur comment optimiser mes | bannissements IP entre mes serveurs. | Pour le moment je déploie fail2ban sur toutes mes machines et je | trouve que cela marche pas mal mais chaque machine gère du coup son | propre lot d'ip bloquée et rate parfois l'ip vu par un des autres | serveurs. On m'a suggéré de coupler avec Portsentry pour compléter la | couverture de protection. J'me suis dit que pour une fois que j'avais un truc à dire, j'allais le faire 0:-) Sur nos serveurs, on a du radius pour le ssh, et le plugin freeradius qui gère l'auth (en Perl, à base de yubikey ou motp) log tous les accès dans une table, avec la source et le résultat (oui/non) on a un autre script à base de Perl/POE qui va, toutes les 5 ou 10 secondes, je sais plus, faire un select à base de trouve moi tous les clients qui ont fait plus de 5 fail dans les 5 minutes écoulées. Il parle ensuite à un autre service sur une autre machine, pour lui filer les ip des méchants, qui est relié à un quagga qui sert de serveur de blackhole bgp, si mes souvenirs sont bons, les méchants sont punis pendant pendant 4 heures. Ça a réduit les scans de ssh à pas grand chose... :-) -- Mathieu Arnold ___ Liste de diffusion du FRsAG http://www.frsag.org/
