Limites IPTABLES

[sadar]

Salut la liste,

Après avoir effectué quelques recherches je n'ai pas trouvé de réponse à cette question :

Quel est le nombre raisonnable de règles que l'on peut faire avaler à IPTABLES ?

En fait je me suis amusé à faire un script perl qui reprend un fichier en entrée qui contient des adresses que je ne veux pas voir router sur l'une de mes adresses. Sauf que le fichier en question contient tout de même pas moins de 144 000 lignes en entrée ce qui en génère le double en sortie sur le principe :

iptables -t filter -N BANLIST
iptables -t filter -F BANLIST

# Create the logdrop chain to log & drop a packet
iptables -t filter -N BANLIST_LOGDROP
iptables -t filter -F BANLIST_LOGDROP
iptables -t filter -A BANLIST_LOGDROP -j LOG --log-prefix "BANLIST"
iptables -t filter -A BANLIST_LOGDROP -j DROP

# List of ip ranges to ban

iptables -t filter -I INPUT 1 -d 192.168.1.2 -s 3.0.0.0/8 -j BANLIST_LOGDROP
iptables -A OUTPUT -o eth1 -d 3.0.0.0/8 -j REJECT

ou l'on voit que @IP 3.0.0.0/8 est bloquée en entrée et en sortie

Bref j'ai constitué un fichier qui contient maintenant un peu plus de 317 000 lignes !

Mise à part un temps de traitement TRES long pour faire rentrer ces règles dans IPTABLES (+ de 6h pour le moment), quels sont les risques mise à part un ralentissement du reseau ??

Merci de votre éclairage

[antolien]

tu sais que tu peux aussi autoriser juste ce qui t'intéresse..

[sadar]

Oui je sais , mais je pense que dans ce cas cela serait bcp plus que 317 000 adresses

Merci tout de même pour ta réponse, je continue mes recherches pour savoir/voir si j'arrive à capter cette info...

Tout de même cela doit bien exister quelque part, une sorte de "best pratices" quoi !

[Franck78]

ca rime pas à grand chose d'interdire autant d'adresse.

Tu ne peux pas décement savoir à quoi elles correspondent. Tu supposes que quelques'un font quelquechose qui aboutit ....

Forcément percée comme protection.
Si le but est d'interdire les sites X par exemple, la solution s'appelle filtrage d'url.

[Gesp]

La prochaine version de dnsmasq intégrée dans ipcop permettra de résoudre de backlister de grosses listes de noms (700 000 lignes) alors que la version actuellement utilisée (2.33) ne permet pas de faire du filtrage par le /etc/host:
http://lists.thekelleys.org.uk/pipermai ... 01134.html

Cependant, ce n'est pas la même chose que de rejeter l'accès aux IP directement puisqu'il serait toujours possible d'accèder par l'IP.

Tout cela ne sera possible que si le cpu est assez puissant pour traiter toute la liste dans un temps raisonable et s'il y a assez de mémoire par rapport à la taille de la liste.

[sadar]

Effectivement le temps de traitement est très-très-très long (bientôt 24h).

Toutefois je reste positiivement impressioné puisque cela fonctionne toujours (pour surfer cela suffit) pour les transferts c'est un peu plus lent, mais cela reste raisonnable et la consommation RAM reste...stable

A la question à quoi cela sert de faire une blacklist de cet ordre ? Bah disons qu'il des sources que l'on ne souhaite pas voir dans certain cas, mais elles restent valident dans d'autres

Il existe des pgms tout fait dans le monde Zindows tels que PeerGardian (zut je l'ai dit) et un blocklist manager sous SmoothWall (merci internet pour les recherches). Mais ce dernier ressort un fichier contenant l'ensemble des adresses sous une forme comparable à ce que j'ai fait en perl.

Donc nous en sommes à 317 000 lignes, finalement iptables tient le choc, et IPCOP aussi, pour l'instant

Je continue mes recherches

A suivre

[jdh]

Je ne vois pas bien pourquoi faire cette chose, mais ...

1/ traffic ip :

Pourquoi bloquer ET en entrée ET en sortie ? Si on ne gère pas le "state", le fait de bloquer en entrée, bloque en entrée bien sur mais aussi le paquet retour en cas de sortie. Non ?

2/ navigation :

Si l'objectif est de blacklister des sites, il y a des outils capables de traiter cela avec "compilation" de liste pour optimiser le temps de traitement.

3/ performance :

Si on filtre en début de chaîne, il faut passer TOUTES les lignes avant de trouver la règle qui autorise le traffic. Cela risque de prendre du temps !!

On peut faire de même une optimisation en créant des chaînes F11 pour traiter toutes les adresses commençant par 11., F12 pour traiter 12., et ainsi de suite ...

Donc un pgm un peu astucieux peut créer bien sur autant de lignes mais réparties afin d'améliorer le temps ...


Enfin je peux présumer que ce genre d'étude a été réalisée par les créateurs de Netfilter. Il doit bien y avoir une discussion sur la mailing liste développeur ...

Ensuite générer un script de 2X lignes à partir de X lignes doit prendre largement moins de temps que cela. Si c'est Perl qui prend du temps, il faut passer à awk qui devrait pas mettre 3 à 5 minutes à générer un fichier aussi simple de ce nombre de lignes (j'ai expérimenté il y a 4 ans des fichiers de 100000 lignes de log à analyser avec awk). Où alors c'est le temps d'exécution du script produit ? Ce qui montrerais que ce n'est pas ce qu'il faut faire.

Il me semble qu'iptables a prévu la possibilité d'externaliser du filtrage via des tables mangle et des processus à définir en C (d'où l'intéret des b-arbres, cf squidguard). Il faudrait regarder vers NuFw décrit dans Linux Mag il y a qq mois ...

[sadar]

Salut jdh,

Je vois avec plaisir que nous habitons la même ville, mais là n'est pas le propos

Ok, je suis qq peu newbie sur ce domaine je l'avoue, mais arrête moi si je me trompe.

Sur le premier point que tu soulèves, concernant le filtrage en entrée et en sortie, il me semble qu'un traffic UDP peut arriver de n'importe où...mais aussi partir vers des adresses non shouaitées (cas des échanges de pair à pair par exemple)

Il ne s'agit donc pas de traffic URL

Pour le script on s'est pas compris ; le script perl va très vite, quelques secondes tout au plus, pour générer 317 000 lignes (le perl est très efficace à bien des égards). Oui tu as raison on pourrait faire la même chose avec du awk, sed, cat et autres tools standards du Linux. J'avoue sur ce coup là avoir jouer la carte de la facilité et les feignasses car il existe des morceaux de code sur les sites de SmoothWall, bluetack, etc, il y en a pour tout le monde : du javascript, du perl et même du vbs pour ceux que cela tente

2/ c'est le traitement du fichier de 317 000 lignes contenant les ordres ipatbles, qui est très long sur un PIII 512Mo en l'occurence

3/ Créer des chaines par type d'adresses rendrait le traitement plus efficace ? Faut il en déduire que créer plus de 300 000 entrée sur une chaine INPUT 1 n'est pas très efficace et qu'il vaut mieux créer une chaine F60 pour les adresses 60.x.x.x puis une chaine F61 pour les adresses 61.x.x.x et ainsi de suite ?

4/ La dernière piste que tu donnes semble très intéressante car, justement, j'en venais à me poser cette question : "comment faire pour accélérer le traitement ? et plus particulièrement j'en venais à regretter que l'on ne puisse pas sauvegarder les règles autrement qu'en rejouant un script contenant toutes les regles... ce qui peu dans ce cas être, long, long très long

Je vais donc creuser vers NUFW, les tables mangles et voir si je peux mettre la main sur ce Linux Mag.

Merci pour ces conseils éclairés. [/b]

[sadar]

humm, NUFW ne semble pas du tout correspondre à ce besoin

[jdh]

Je n'ai pas écrit que NuFW convient (parce qu'il ne convient pas).

J'ai écrit (voulut écrire) qu'il fallait s'intéresser aux techniques utilisées par NuFW à savoir la table "mangle" et la mise en oeuvre de pgm (en C) capable de faire le filtrage avec plus de rapidité (sans doute avec un btree construit pour). Lesquelles techniques (mangle) ont été décrites récemment dans LinuxMagazine au travers de 1 ou 2 numéros (milieu d'année 2006).

[sadar]

Je te l'avais bien dit, je suis mal comprenant

Merci pour l'info