faire du DPI avec iptables (et aussi des vlans)

woinche · 31-01-2019 22:57:25

boujour a tous,

je souhaiterais faire de l'inspection de paquet sur la machine qui sert de passerelles/routeur a mes petits serveurs.
dans l'optique de securiser et controler au max les connections sortants.

j'ai suivi ce tuto afin de pouvoir utilisé la librarie nDPI avec iptables

j'ai suivi le tuto a la lettre. hormis que je n'ai pas telechargé l'archive dans /usr/src/ mais un autre dossier (/root/tmp/).
et aussi la ligne où il est donner :

cp /usr/src/ndpi-netfilter-master/ipt/libxt_ndpi.so /lib/xtables/

j'ai du copier le .so dans /usr/lib/xtables, /lib/xtables n'exitant pas sur ma becane (debian 9 strech, linux 4.9.0-8-amd64)

mon probleme est que, lorsque je tape

iptables -A FORWARD -m nDPI --skype -J DROP

ou mene

iptables -m nDPI --help

j'ai toujour ce retour, mene apres un reboot.

iptables v1.6.0: Couldn't load match `ndpi':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.

or lorsque je tape

lsmod |grep xt_ndpi

le resultat est

xt_ndpi               315392  0

nf_conntrack          114688  5 xt_ndpi,nf_conntrack_ipv4,nf_nat_masquerade_ipv4,nf_nat_ipv4,nf_nat

x_tables               36864  9 xt_nat,ip_tables,xt_ndpi,ebtables,iptable_filter,xt_tcpudp,ipt_MASQUERADE,ip6table_filter,ip6_tables

du coup selon moi le module est bien chargé. mais iptables ne semble pas le detecter... j'admet ne pas trop connaitre iptables et la doc francaise sur "iptables + ndpi" est introuvables... si quelqu'un peu m'apporté ces lumineres. je lui offre un cookie !
merci d'avance

Dernière modification par woinche (03-03-2019 11:49:31)

raleur · 31-01-2019 23:32:06

woinche a écrit :

j'ai du copier le .so dans /usr/lib/xtables, /lib/xtables n'exitant pas sur ma becane (debian 9 strech, linux 4.9.0-8-amd64)

/usr/lib/xtables, vraiment ? Ce ne serait pas plutôt /usr/lib/x86_64-linux-gnu/xtables ?

woinche · 01-02-2019 13:10:07

oups... effectivement le dossier xtables est bien présent dans /usr/lib/x86_64-linux-gnu/

j'ai regarder ça ce matin avant d'aller au taf. j'ai copier le libxt_ndpi.so dans /usr/lib/x86_64-linux-gnu/xtables/ et la commande iptables -m ndpi --help me donne un retour un peu plus chaleureux. ce soir je vais faire quelque règles et quelque tests.

du coup c'est dans le dossier /usr/lib/x86_64-linux-gnu/xtables que iptables vient charger ces librairies ? donc a l'avenir si je cherche a ajouter une fonctionnalité a iptables il faut que les libXXX.so soit dans ce dossier ?

Merci Raleur pour ta réponse ultra-rapide

raleur · 01-02-2019 19:59:31

woinche a écrit :

c'est dans le dossier /usr/lib/x86_64-linux-gnu/xtables que iptables vient charger ces librairies ?

En tout cas c'est là que se trouvent celles du paquet iptables (dans Stretch, car dans Jessie c'étant dans /lib/xtables).

Dernière modification par raleur (01-02-2019 20:00:24)

woinche · 01-02-2019 22:08:35

Ok je vois, donc il semblerais que mon tuto a été écrit pour Jessie plutôt que pour Stretch.

je viens de faire deux trois tests en bloquant l'icmp, youtube, etc.. ça marche bien. mais part contre j'arrive pas a bloquer le SSH.
le pare-feu du routeur applique ceci

iptables -A FORWARD -s 192.168.0.0/24 -m ndpi --ssh -j DROP

voici l’ensemble des règles

iptables -L

....

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination         

ACCEPT     all  --  anywhere             192.168.1.254       

DROP       all  --  anywhere             192.168.1.0/24      

DROP       all  --  192.168.0.0/24       anywhere            protocol SSH 

DROP       all  --  192.168.0.0/24       anywhere            protocol ICMP

....

et mon client (192.168.0.20) établie bien des connexions SSH et SFTP avec le serveur 10.0.0.14. c'est étrange, normalement le SSH est facilement reconnu et bloquer part le pare feu ?

raleur · 02-02-2019 09:54:57

Je ne sais pas comment fonctionne cette correspondance ndpi.

Par contre pas besoin de DPI pour détecter le protocole ICMP, un simple "-p icmp" suffit. Le DPI n'est utile que pour les protocoles au-dessus de la couche transport.

Dernière modification par raleur (02-02-2019 09:55:31)

woinche · 19-02-2019 21:47:07

salut a tous,

aujourd'hui je planche a nouveau sur ce pare feu. la raison du dysfonctionnent des instructions du type iptables -m ndpi -j DROP est tout simple.

le PC client et le serveur que j'utilise pour mes test est un PC virtualisé dans un environnement KVM/QEMU. tout ces VM utilise la mène carte réseaux, a savoir enp8s0, en mode pont, modèle virtio.

mon hyperviseur sert également de routeur avec enp9s0 comme interface WAN et l'interface enp6s0 est utilisé pour fournir les passerelle dans les differents réseaux des invités.

donc lorsque mon client 192.168.0.X va causer a un serveur distant il passe bien part le chemin suivant :
- enp8s0 (192.168.0.X)
- puis sa passerelle enp6s0 (192.168.0.1)
- puis sous le regard de iptables
- et enfin il sort sur le web via enp9s0 (NAT avec mon IP publique)

dans ce cas de figure l'on voit bien que iptables voit le trafic et peut donc bosser

le problème se pose lorsque je veux bloquer le SSH entre le réseaux 192.168.0.0/24 (dont les hosts utilise enp8s0 et la gateway est enp6s0) et le réseaux 10.0.0.16/30 (dont l'host utilise enp8s0 et la gateway est enp6s0). effectivement dans ce cas de figure, le client 192.168.0.X peut contacter le serveur 10.0.018 sans passer part le routeur !

en témoigne ces magnifique table ARP coté serveur et client.

coté serveur

? (192.168.0.45) at 52:54:00:fc:d8:a4 [ether] on ens3

? (10.0.0.17) at 50:3e:aa:02:b0:09 [ether] on ens3

et coté client

Interfaceÿ: 192.168.0.45 --- 0xa

  Adresse Internet      Adresse physique      Type

  10.0.0.18             52-54-00-91-d8-77     dynamique 

  192.168.0.1           50-3e-aa-02-b0-09     dynamique 

  224.0.0.22            01-00-5e-00-00-16     statique  

  239.255.255.250       01-00-5e-7f-ff-fa     statique

l'on vois bien que le client arrivé a trouvé son chemin des la couche 2, ainsi lorsque le client envoie ces paquets IP, il dirige directement ces trame a 52-54-00-91-dB-77 (enp8s0 utilisé par le serveur) et non vers 50-3e-aa-02-b0-09 (hyperviseur / routeur) comme je le souhaite.... du coup j'ai, me semble t'il, gagner le droit de faire des vlan.

est ce que vous savez si virsh permet de cloisonner plusieurs interface entre elle ? genre enp6s0:4 ne peut parler qu'a enp8s0:4 et ainsi de suite.
est ce qu'il est possible que j’intègre une logique de vlan a mon hyperviseur virsh - KVM/QEMU comme il ce fait sous vmware avec les vmnet ?

merci d'avance.

PS @raleur tu as raison pour l'icmp, j'avais simplement lancé quelque commande pour vérifier le fonctionnent de nDPI sans y prêter bien plus d'attention.

anonyme · 20-02-2019 02:18:27

Bonjour
je sais pas si tu a vue ceci (en #51 et #52 ) => https://debian-facile.org/viewtopic.php … 75#p292975
iptables va être remplacé par nftables dans le futur , le noyau est compatible et le paquet disponible sur stretch.

Dernière modification par anonyme (20-02-2019 02:19:05)

raleur · 20-02-2019 14:22:06

woinche a écrit :

j'ai, me semble t'il, gagner le droit de faire des vlan

Ou bien deux réseaux virtuels distincts.
Quelle idée aussi (et quel intérêt) de mettre deux sous-réseaux IP distincts sur le même segment Ethernet.

Si les VM étaient reliées à l'hôte par l'intermédiaire d'un pont style br0, il serait possible de filtrer le trafic traversant ce pont avec iptables grâce au module noyau br_netfilter.

woinche a écrit :

est ce que vous savez si virsh permet de cloisonner plusieurs interface entre elle ? genre enp6s0:4 ne peut parler qu'a enp8s0:4

Attention : la notation enp6s0:4 désigne un alias IP (mécanisme obsolète permettant d'affecter une adresse IPv4 supplémentaire à une interface) et non une interface virtuelle de type VLAN qui serait de la forme enp6s0.4 (VLAN ID 4 sur enp6s0).

Note que tu n'as pas besoin que QEMU gère les VLAN, tu peux le faire directement sur l'hôte et les VM en utilisant des interfaces VLAN enp6s0.X et enp8s0.X au lieu des interfaces simples.

Dernière modification par raleur (20-02-2019 16:04:08)

woinche · 20-02-2019 15:57:09

Merci pour vos réponses.

Merci anonyme pour l'info et le partage de ce fil qui va être intéressant de suivre.

Quelle idée aussi (et quel intérêt) de mettre deux sous-réseaux IP distincts sur le même segment Ethernet.

en effet j'ai là une installation bien poreuse.... que veux-tu je suis jeunes, débutant et j'apprend sur le tas, les erreurs font partie du jeu.

je vais modifier mon réseaux en conséquence. merci pour les pistes que tu me donne raleur.

woinche · 03-03-2019 00:04:14

je galere un peu....

j'ai configurer dans le fichier /etc/network/interfaces enp6s0.5 et une enp8s0.5 comme ceci

auto enp6s0.5

iface enp6s0.5 inet static

        address 10.0.0.17

        network 10.0.0.16

        netmask 255.255.255.252

        vlan-raw-device enp6s0

auto enp8s0.5

iface enp8s0.5 inet manual

        vlan-raw-device enp8s0

avec le gestionnaire de machine virtuelle je donne l'interface enp8s0.5 a l'invité en mode "pont". enp6s0.5 est utilisé par l'hote.

le probleme est que l'invité ne peut pas pinger l'hote (qui sert ici de paserelle vers le web). pourtant l'adresse mac de l'hote remonte bien dans la table ARP de l'invité.

si je ne me tronpe pas, l'hote devrait laisser passer a traver enp6s0.5 tout les trames tagger avec un ID de vlan "5" ? comme mon invité dispose de enp8s0.5 tout ces trames sont automatiquement tagger avec lID 5 ?

je regarderais plus en detail demain (esperons que la nuit me porte conseille). mais pour l'instant je suis dans le flou.... je ne vois pas mon erreur....

pour info,
- j'ai egalment testé avec enp8s0.5 en mode "passtrought", "VEPA" et "pont" (mode disponible dans virt-manager qui est le client que j'utilise pour administer mes VMs)
- le module 8021q est bien chargé par l'hote.
- la comande "systemctl restart networking.service" se deroule sans erreur
- je ne configure rien de particulier sur l'invité (juste l'IP)

Merci beaucoup !

EDIT : apres un "reboot" ce matin mon souci n'est plus.

Dernière modification par woinche (03-03-2019 11:48:22)

raleur · 03-03-2019 14:55:40

woinche a écrit :

avec le gestionnaire de machine virtuelle je donne l'interface enp8s0.5 a l'invité en mode "pont". enp6s0.5 est utilisé par l'hote.

Ce n'est pas ce que j'ai suggéré, et je n'ai pas la moindre idée de comment QEMU se comporte dans cette configuration.

woinche · 06-03-2019 21:43:42

Ce n'est pas ce que j'ai suggéré

certes, mais j'ai préféré utiliser les vlans car entre mes deux interfaces il y a un switch qui gère également les vlan. donc si l'hyperviseur tag toute les trames sortante de ces cartes, je peux avec le switch faire des réseaux en mélangent VM et machines physique. ce qui m'arrive de temps a autre.

donc voilà j'ai voulu tester avec les vlans avant de toucher au "br". ceci étant dit, le switch n'est pas encore configurer.... donc rien n'est valider....

en tout cas, au niveau des VM je ne vois aucun effet indésirable, les tables ARP ne traduise que des IP "intra-reseaux" et les traduction que je reste a la main me permette pas de court-circuiter le routeur. je ferait un peu plus de test semaine prochaine (là je n'ai pas de temps a consacré au projet perso). donc a voir si je garde cette solution ou pas.

encore merci raleur.

Dernière modification par woinche (06-03-2019 21:44:00)

woinche · 28-04-2019 17:10:46

bonjour,

je suis toujours en galère avec mon système de DPI.

certaines instructions marche à merveille, telle que:

iptables -I FORWARD 1 -s $mon_reseaux -m ndpi --DNS -j REJECT

mais d'autre le fonctionne pas du tout....
par exemple les différents paramètre que sont --http --http_download --http_application_activesync --http_connect --http_proxy ne "match"' rien du tout

pour en arriver a cette conclusion, j'ai procédé comme ceci:

j'ai taper cette commande afin de vérifier si l'inspection fonctionnait bien.

iptables -I FORWARD 1 -s $mon_reseaux -m ndpi --http -j LOG --log-level info --log-prefix [test_iptables_dpi] 

ensuite je génère du trafic depuis le client avec lynx

lynx http:// $site_en_http

en parallèle je vais voir dans le /var/log/syslog si le trafic apparaît

tail -f /var/log/syslog

résultat ni le SSH ni les différents "filtre" HTTP ne match, en revanche, et selon le mène protocole de test d'autre filtre fonctionne telle que DNS par exemple.
étrange non ? je fait mal les choses ? ça vous est déjà arrivé ?

merci d'avance

Debian-facile

#1 31-01-2019 22:57:25

faire du DPI avec iptables (et aussi des vlans)

#2 31-01-2019 23:32:06

Re : faire du DPI avec iptables (et aussi des vlans)

#3 01-02-2019 13:10:07

Re : faire du DPI avec iptables (et aussi des vlans)

#4 01-02-2019 19:59:31

Re : faire du DPI avec iptables (et aussi des vlans)

#5 01-02-2019 22:08:35

Re : faire du DPI avec iptables (et aussi des vlans)

#6 02-02-2019 09:54:57

Re : faire du DPI avec iptables (et aussi des vlans)

#7 19-02-2019 21:47:07

Re : faire du DPI avec iptables (et aussi des vlans)

#8 20-02-2019 02:18:27

Re : faire du DPI avec iptables (et aussi des vlans)

#9 20-02-2019 14:22:06

Re : faire du DPI avec iptables (et aussi des vlans)

#10 20-02-2019 15:57:09

Re : faire du DPI avec iptables (et aussi des vlans)

#11 03-03-2019 00:04:14

Re : faire du DPI avec iptables (et aussi des vlans)

#12 03-03-2019 14:55:40

Re : faire du DPI avec iptables (et aussi des vlans)

#13 06-03-2019 21:43:42

Re : faire du DPI avec iptables (et aussi des vlans)

#14 28-04-2019 17:10:46

Re : faire du DPI avec iptables (et aussi des vlans)

Pied de page des forums