Problème de performances iptables / conntrack Linux

9

J'ai une configuration de test en laboratoire avec 4 machines:

  • 2 anciennes machines P4 (t1, t2)
  • 1 Xeon 5420 DP 2,5 GHz 8 Go de RAM (t3) Intel e1000
  • 1 Xeon 5420 DP 2,5 GHz 8 Go de RAM (t4) Intel e1000

pour tester les performances du pare-feu Linux depuis que nous avons été mordus par un certain nombre d'attaques syn-flood au cours des derniers mois. Toutes les machines exécutent Ubuntu 12.04 64 bits. t1, t2, t3 sont interconnectés via un commutateur de 1 Go / s, t4 est connecté à t3 via une interface supplémentaire. Donc, t3 simule le pare-feu, t4 est la cible, t1, t2 jouent les attaquants générant une tempête de paquets (192.168.4.199 est t4):

hping3 -I eth1 --rand-source --syn --flood 192.168.4.199 -p 80

t4 supprime tous les paquets entrants pour éviter toute confusion avec les passerelles, les problèmes de performances de t4 etc. Je regarde les statistiques des paquets dans iptraf. J'ai configuré le pare-feu (t3) comme suit:

  • stock 3.2.0-31-générique # 50-Ubuntu SMP kernel
  • rhash_entries = 33554432 comme paramètre de noyau

  • sysctl comme suit:

    net.ipv4.ip_forward = 1
net.ipv4.route.gc_elasticity = 2
net.ipv4.route.gc_timeout = 1
net.ipv4.route.gc_interval = 5
net.ipv4.route.gc_min_interval_ms = 500
net.ipv4.route.gc_thresh = 2000000
net.ipv4.route.max_size = 20000000

(J'ai beaucoup modifié pour que t3 continue de fonctionner lorsque t1 + t2 envoient autant de paquets que possible).

Le résultat de ces efforts est quelque peu étrange:

  • t1 + t2 parviennent à envoyer chacun environ 200k paquets / s. t4 dans le meilleur des cas voit environ 200k au total, donc la moitié des paquets sont perdus.
  • t3 est presque inutilisable sur la console bien que les paquets le traversent (nombre élevé d'erreurs logicielles)
  • le ramasse-miettes du cache de route est loin d'être prévisible et dans le paramètre par défaut dépassé par très peu de paquets / s (<50k paquets / s)
  • l'activation des règles iptables avec état fait chuter le taux de paquets arrivant sur t4 à environ 100 000 paquets / s, perdant ainsi plus de 75% des paquets

Et cela - voici ma principale préoccupation - avec deux anciennes machines P4 envoyant autant de paquets que possible - ce qui signifie que presque tout le monde sur le net devrait être capable de cela.

Voici donc ma question: ai-je oublié un point d'importation et de configuration ou de configuration de test? Existe-t-il des alternatives pour construire un système de pare-feu, en particulier sur les systèmes smp?

linux firewall Tim
la source
Est-il possible que vous saturiez simplement le réseau? Cela expliquerait une partie de la perte de paquets.
Preston
Je ne pense pas, car le réseau est à 1 Gbit / s, chacun étant connecté via un commutateur HP 2848, le contrôle de flux est activé et les débordements élevés de cache de charge et de route sur t3 indiquent que t3 lui-même est le point faible.
tim

Réponses:

1

Je migrerais vers Kernel> = 3.6 qui n'a plus de cache de routage. Cela devrait résoudre une partie de vos problèmes.

BatchyX
la source
0

Comment est votre configuration de journalisation sur T3? Si tous les paquets abandonnés sont enregistrés, les E / S disque peuvent en être la cause.

Comme il s'agit d'un environnement de test, vous pouvez essayer le test avec la journalisation T3 désactivée.

John Siu
la source