Utilitaires de paquets en plus d'iptables? [fermé]

Question

Je recherche un utilitaire Linux capable de modifier les charges utiles des paquets réseau en fonction d'un ensemble de règles. Idéalement, j'utiliserais iptables et le module de noyau netfilter , mais ils ne prennent pas en charge la gestion générique de la charge utile: iptables modifie divers en-tête champs (adresses, ports, TOS, etc.), et il peut correspondre à octets arbitraires dans un paquet, mais il est apparemment impossible de modifier des données arbitraires dans le paquet.

Un module de noyau serait un gros avantage, car l'efficacité est une préoccupation, mais je suis heureux d'explorer toute autre option qui permettrait de faire le travail.

Merci pour vos idées!

Mise à jour attendue depuis longtemps:

Nous avons choisi d'utiliser le module NFQUEUE , qui est la dernière implémentation des modules QUEUE proposée par Robert Gamble. Cela semblait assez simple, avec un bonus de sécurité pour permettre à notre code de fonctionner dans un utilisateur, et non dans le noyau, sans espace.

L’implémentation aurait été presque triviale si nous avions simplement voulu modifier la charge utile sans en modifier la taille. Dans ce cas, nous définirions une règle iptables sur sélectionnez le " intéressant " paquets pour nous et leur envoyer une cible NFQUEUE . Nous écririons une fonction de rappel qui inspecterait les paquets de NFQUEUE , modifierait les données si nécessaire et recalculerait les sommes de contrôle dans leurs en-têtes TCP et IP.

Cependant, notre cas d'utilisation implique l'injection de caractères supplémentaires dans le flux de données. Ceci a pour effet secondaire d’augmenter les nombres SEQ / ACK correspondants dans le flux TCP et d’avoir un effet secondaire moins évident de créer une confusion entre conntrack suffisamment pour qu'il casse complètement le NAT. Après une série de recherches, de grincements de têtes et d’expérimentations, la solution la plus appropriée a été de désactiver le suivi des connexions pour ces paquets particuliers (avec la cible NOTRACK dans la liste . raw ) et le gérer dans notre callback. Sauvez vos tomates et détestez le courrier; Je ne suis pas du tout fier de vous laisser sous le capot, mais c'était le seul moyen d'obtenir un produit fiable pour le client avant la prochaine période glaciaire. Et c'est une bonne histoire. Mais j'apprécie vraiment et partage vos sentiments sincères.

La version 2 tirera parti de notre nouvelle illumination en remplaçant notre rappel et plusieurs règles iptables par un NAT personnalisé et / ou conntrack auxiliaire . Nous sommes confiants que l’exercice en cours nous a donné suffisamment d’expérience pour créer un module de noyau qui s’intègre de manière organique dans l’architecture de netfilter afin de résoudre les problèmes rencontrés.

Merci encore pour votre intérêt et vos suggestions!

Answer 1

Je ne l'ai pas utilisé, mais QUEUE cible de netfilter on dirait que ça pourrait marcher. Il utilise un socket nflink et une application utilisateur enregistrée dans le socket pour effectuer les modifications de la charge utile.

La page de manuel libipq contient des informations sur son utilisation et fournit un exemple simple. .

Answer 2

Résolution:

Nous nous sommes retrouvés avec un module personnalisé pour netfilter, qui est clairement le "droit". outil pour le travail.