Suricata not detecting intrusion on other docker containers within the same network

1

Hi : )
I’m setting up Suricata in a Docker environment using docker-compose, and my setup includes an attacker container running Kali Linux and an IDS system using Suricata. This is how my docker-compose.yml file look like:

version: '3.8'

services:
  attacker:
    image: kalilinux/kali-rolling
    container_name: attacker
    networks:
      vlan_net:
        ipv4_address: 10.0.0.10
    tty: true
    privileged: true
    volumes:
      - ./shared:/shared
    command: >
      bash -c "
        apt-get update &&
        apt-get install -y nmap metasploit-framework &&
        tail -f /dev/null"

  ids_system:
    image: jasonish/suricata
    container_name: ids_system
    networks:
      - vlan_net
    volumes:
      - ./rules:/var/lib/suricata/rules
      - suricata:/var/log/suricata
    cap_add:
      - NET_ADMIN
      - NET_RAW
      - SYS_NICE
    command: suricata -c /etc/suricata/suricata.yaml -i eth0

networks:
  vlan_net:
    driver: bridge
    ipam:
      config:
        - subnet: 10.0.0.0/24
          gateway: 10.0.0.1

volumes:
  suricata:
  rules:
  shared:

I have configured the HOME_NET and Interface correctly, but I can’t detect an intrusion from my attacker container, however I can detect intrusion from the ids_system container.
I have been using this to test for intrusion:
curl https://testmynids.org/uid/index.html
Could there be anything that i’m missing in terms of configuration?

Thanks!

2

Docker’s bridge driver, which I think is just the Linux kernel bridge is more like a switch than a hub. Packets from attacker out to the network will not be seen by ids_system. Instead you will have to run Suricata on a device that does see those packets.

If you are on a Linux host system…

Just using tcpdump, on my own system I see that the interface vethc1c23eb on the host sees traffic from attacker, as does br-e558e6b95223 (note these interface names will be different on other systems). This means on the ids_system you could use host networking to bring these interfaces into the container and listen on one of them. However, I’m not sure how to make these names predictable, but may some level of discovering can be done with Docker’s inspect tooling.

If not on Linux, the above should still apply, you’ll have just to get into the VM hosting Docker.

1 Like
3

@ish Thank you : )
I’ll play around with this, then post an update.

4

Setting the network mode to host, and using linux or a different docker provider (like orbstack) that allows containers to inherit the host’s network solved the issue.