2. Configurer NetworkManager - netplan, pour retirer complètement l'adresse ip de eth2, pour les captures Suricata :

[admin]

Regarder le contenu de netplan :
-

Code: Select all

ls -la /etc/netplan

Si le fichier 90-… existe (crée par NetworkManager), créer un fichier (supérieur à 90, pour qu'il soit pris en compte, par-dessus au 90-… ), par ex :

Code: Select all

 nano 95-custonm.yaml :

Code: Select all

network:
  version: 2
  renderer: NetworkManager
  ethernets:
    eth2:
      optional: true
      dhcp4: false
      link-local: []
    eth4:
      addresses:
      - "172.0.0.1/24"
      nameservers:
        addresses:
        - 192.168.10.2
      dhcp4: false
      routes:
      - to: "0.0.0.0/0"
      via: "192.168.10.1"
 

Enregistrer et fermer.
Puis :

Code: Select all

sudo chmod 600 /etc/netplan/95-custom.yaml
sudo netplan generate    # vérifie l’absence d’erreurs
sudo netplan apply

tapez :
-

Code: Select all

nmcli connection show

NAME UUID TYPE DEVICE
netplan-eth4 111... ethernet eth4
netplan-eth2 222... ethernet eth2
lo 333... loopback lo
Wired connection 1 444... ethernet --
Wired connection 2 555... ethernet --
/etc/netplan#

alors, supprimez les interfaces inutilisés :

Code: Select all

nmcli connection delete "Wired connection 1"

Code: Select all

nmcli connection delete "Wired connection 2"

rechargez netplan :
-

Code: Select all

nmcli connection reload
sudo netplan apply

puis, mettez eth2 en unmanaged :
-

Code: Select all

sudo nmcli device set eth2 managed no

Vérifier :
-

Code: Select all

nmcli device status

nmcli device status DEVICE TYPE STATE CONNECTION
eth4 ethernet connected netplan-eth4
lo loopback connected (externally) lo
eth2 ethernet unmanaged --

Désactiver l'adresse ip de eth2 :
-

Code: Select all

sudo ip addr flush dev eth2
sudo sysctl -w net.ipv4.conf.eth2.arp_ignore=1
sudo sysctl -w net.ipv4.conf.eth2.arp_announce=0

puis recharger sysctl :
-

Code: Select all

sysctl -p

puis, pour désactiver ces option au redémarrage :
-

Code: Select all

nano /etc/sysctl.conf

Code: Select all

net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=0

Enregistrez et fermez.
Sortie (rem: il n'y a plus d'adresse ip sur "eth2", elle ne comporte plus de champs "inet") :
-

Code: Select all

ip a show eth2

2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether a1... brd ff:ff:ff:ff:ff:ff

Pour que ça marche après redémarrage, il faut encore faire :
Il faut utiliser un hook NetworkManager qui s’exécute après la configuration d’interface :
-

Code: Select all

nano /etc/NetworkManager/dispatcher.d/95-disable-linklocal

-

Code: Select all

#!/bin/bash
IFACE="$1"
STATUS="$2"
		
if [ "$IFACE" = "eth2" ] && [ "$STATUS" = "up" ]; then
  /usr/sbin/ip addr flush dev "$IFACE"
  /usr/sbin/sysctl -w net.ipv4.conf."$IFACE".arp_ignore=1
  /usr/sbin/sysctl -w net.ipv4.conf."$IFACE".arp_announce=0
fi

-

Code: Select all

sudo chmod 755 /etc/NetworkManager/dispatcher.d/95-disable-linklocal

-

Code: Select all

reboot

Et là, ça marche.




Source : ChatGPT.

[Doramaland_acits]

---

Bonjour à tous,

Je débute actuellement avec Suricata sur une machine virtuelle sous Kali Linux et je souhaite l’utiliser comme IDS/IPS capable de surveiller tout le trafic de mon réseau local, y compris les communications entre les machines physiques et virtuelles. Jusqu’à présent, j’ai testé Suricata en mode Host‑Only et il ne capture que le trafic qui passe par l’interface virtuelle de la VM, ce qui limite grandement son efficacité pour détecter des attaques ou des comportements anormaux sur le réseau complet.

Voici ce que j’ai déjà essayé :

1. Interface réseau – J’ai indiqué `-i eth0` (ou `enp0s3` selon la distribution) dans le fichier de configuration, mais Suricata ne semble pas recevoir les paquets provenant des autres hôtes.
2. Mode promiscuité – J’ai activé le mode promiscuité sur l’interface avec `ifconfig eth0 promisc`, mais le problème persiste.
3. Sniffing en mode bridge – J’ai créé un bridge entre l’interface physique de la machine hôte et la VM, puis j’ai branché Suricata dessus, mais le bridge ne transmet pas le trafic vers la VM.
4. Utilisation de `tcpdump` – En lançant `tcpdump -i eth0 -w capture.pcap` je constate que le trafic est bien capturé, ce qui indique que le problème vient probablement de la configuration de Suricata elle‑même.

Je cherche donc à savoir :

- Quelle est la configuration exacte (dans `suricata.yaml` ou via la ligne de commande) à appliquer pour que Suricata écoute tout le trafic du réseau (y compris les communications entre machines physiques) ?
- Faut‑il placer Suricata sur un port mirroring d’un switch, ou existe‑t‑il une solution logicielle (ex. : `iptables` → NFQUEUE, `ebtables`, ou utilisation d’un tap virtuel) qui permette de rediriger le trafic vers Suricata sans matériel additionnel ?
- Quelles sont les meilleures pratiques pour éviter les pertes de paquets (buffer overflow) lorsqu’on utilise Suricata en mode de capture « full‑wire » ?
- Enfin, avez‑vous des recommandations de règles ou de tuning (détection de flux, `af-packet`, `pfring`, etc.) qui facilitent la surveillance d’un réseau complet depuis une VM ?

Merci d’avance pour vos conseils, vos retours d’expérience et éventuellement des exemples de configuration fonctionnelle. Toute aide (scripts, captures d’écran, liens vers la documentation) sera la bienvenue.

Топ романтических дорам, заставят вас растаять! Оценивайте (no spam plz)

[admin]

Salut, et merci à toi pour le post.

Ensuite, je me suis permis de déplacer ton post, dans ce forum... Je ne sais pas si tu a consulté déjà ce sujet (je pense que oui...)
Je t'avoue que je débute aussi sous Suricata, et je crains que je ne puisse pas totalement te répondre (je m'aide beaucoup de l'IA, tu sais)...
En effet, j'ai un switch manageable, sur lequel, est, en effet connecté Suricata, sur un port mirroring. Sur ma machine Debian 13, j'ai 2 interfaces IP, une pour Suricata, en mode promisc, et l'autre, surtout pour le SSH, mais aussi pour internet. Mais, je pense que sur une seule interface IP promisc, ça ne devrait pas bloquer, je vois pas pourquoi...

Je me suis servi de "netplan" de NetworkManager(sous Debian 13), à la place de ifupdown et /etc/network/interfaces (de Debian 12)
Puis,
Je me suis servi de :

Code: Select all

ip link set dev eth0 promisc on

à la place de :

Code: Select all

ifconfig eth0 promisc

Pour activer le mode "promisc" de eth0
Essaye voir, ça coûte rien, peut-être que c'est mieux...

Ensuite, j'avais complètement oublié de préciser ce block ci, dans la configuration de suricata.yaml :

Code: Select all

af-packet:
  - interface: eth2
    cluster-type: cluster_flow
    cluster-id: 99
    defrag: yes
    use-mmap: yes
    tpacket-v3: yes
    mmap-locked: no
    ring-size: 2048
    block-size: 32768
    block-timeout: 10
    buffer-size: 32768
    disable-promisc: no
    checksum-checks: auto

  - interface: default

Et je m'en suis rendu compte grâce à toi. Tu devrais vérifier si tu as la bonne config.

Ensuite, en mode "full-wire", comme tu le décris, de machine physique -> interface VM et bridge, ou en host-only, tu ne devrais pas avoir de pertes. Si je peux me permettre de te conseiller sur quelques points (si tu achètes un switch, il y en a un bien dans les annonces de mon site), c'est que si tu as 10 ports physiques sur ton switch, sur lesquels suricata doit surveiller le trafic, l'idée, c'est de diviser le débit maximal du port physique de suricata par 10 : par ex. : 10Go / 10 = 102.4 donc, il faut que tu limites leur taffic à 64Mo (arrondi par défaut). Ensuite, si tu veux limiter le trafic directement sur le port, je te conseille de pas le limiter sur l'ingress (du réseau -> ta machine). Tu laisses l'ingress tel quel (10Go), et tu limites sur l'egress (l'autre sens), sinon, tu aura beaucoup de CRC. De plus, il est mieux de limiter le trafic logiquement (QoS, couche Liaison - Réseau), plutôt que physiquement (limiter le port, couche physique), et donc, de te servir des QoS.
Ensuite, il faut que tu vérifie que le SPAN de ton switch, soit pas unidirectionnel.

Sur ce, bonne soirée.

[admin]

Bonjour,

Je viens d'apprendre une chose que je ne connaissais pas auparavant :
NetworkManager et netplan, sont la nouveauté de Debian, mais plus orientés "Desktop", et plus Ubuntu...
Alors que ifupdown, sont legacy et toujours supportés par Debian 13. Et en plus je préfère ifupdown... C'est un tuto que j'avais entrevu (ou peut être un biais de l'IA) qui m'a induit dans l'erreur... Je croyais que pour Debian 13, NetworkManager et netplan sont le standard et que ifupdown est déprécié...
Donc, les deux types de gestion des interfaces ethernet sont valables...

Bonne soirée.

[admin]

Bonjour,
Je vous conseille de supprimer le hook NetworkManager (/etc/NetworkManager/dispatcher.d/95-disable-linklocal)... C'est beaucoup trop agressif comme comportement...

Normalement, en faisant ça :

Code: Select all

nmcli dev set eth2 managed no

Code: Select all

nmcli con del "netplan-eth2"

Code: Select all

nmcli con reload

testez :

Code: Select all

nmcli con sh

Code: Select all

nmcli dev stat

Vous devez plus voir l'interface eth2 gérée par NetworkManager (donc, il ne peut pas lui réattribuer un code IP)
redémarrez, normalement, l'interface est "up" "non-managée par NetworkManager" "PROMISC" et sans IP, après redemarrage.

Bonne soirée.