You could try and use iptables
and tee
on the Docker host to mirror the traffic to another (bridge network) interface, which could be the one used by your Suricata container.
You would:
Create a bridge, e.g., br0
, in the Docker host and assign it an IP address. (you may need to install the bridge-utils
package first)
sudo brctl addbr br0 # create a new bridge named br0
sudo ip addr add 192.168.1.1/24 dev br0 # assign the IP address 192.168.1.1 with a netmask of 255.255.255.0 to br0
Assign the "attacker
" and "suricata
" containers to the same Docker network, which is associated with br0.
(see docker-compose.yml
below)
Use iptables
and tee
to duplicate the traffic:
iptables -t mangle -A PREROUTING -i br0 ! -s <suricata IP> -j TEE --gateway <suricata IP>
Setup Suricata to listen on its network interface.
Check first the name of the interface name with docker exec -it suricata bash -c "ip addr"
: Look for the interface that has an IP address on the same network as your "attacker" container.
Then edit /etc/suricata/suricata.yaml
, section af-packet:
, put - interface: eth1
. Once edited: service suricata restart
.
Here is an updated docker-compose.yml
based on your file:
version: "3.8"
services:
suricata:
container_name: suricata
build: ./suricata
networks:
attacknet:
ipv4_address: 172.16.238.10
attacker:
container_name: attacker
build: ./attacker
networks:
attacknet:
ipv4_address: 172.16.238.11
networks:
attacknet:
driver: bridge
ipam:
driver: default
config:
- subnet: 172.16.238.0/24
In that configuration, Suricata and attacker are on the same Docker network. You can set up iptables
to mirror the traffic from attacker to Suricata as mentioned above.
This remains a high-level sketch, and it might need adjustments based on your particular setup.
And the iptables
rule mentioned above is just a simplistic example, to be adjusted it based on the traffic flow you are interested in (inbound, outbound, etc.), making sure to not create a traffic loop.
If you are trying to run this setup on a cloud platform, the network interface mirroring option might not be available due to the limitations imposed by the cloud provider's network virtualization. You might want to consider running this setup on a bare-metal or self-managed virtualized environment, at least for testing it out.
An alternative to this would be to use a Network Function Virtualization platform, such as TNSR or pfSense, which can mirror packets from one interface to another.
When you say "Assign the "attacker" and "suricata" containers to the same Docker network, which is associated with br0.", how do you actually define this in the docker-compose file?
I don't see the relation in the file not the Ips nor any mentioning of the interface br0.
In Docker, when you define a network in a docker-compose.yml
file and assign that network to a service, Docker will automatically create a bridge for that network and connect the service's container to it. The bridge will be automatically assigned a name by Docker and not explicitly mentioned in the docker-compose.yml
file.
In your docker-compose.yml
file, you have defined a network named attacknet
and assigned it to your suricata
and attacker
services:
services:
suricata:
container_name: suricata
build: ./suricata
networks:
attacknet:
ipv4_address: 172.16.238.10
attacker:
container_name: attacker
build: ./attacker
networks:
attacknet:
ipv4_address: 172.16.238.11
networks:
attacknet:
ipam:
driver: default
config:
- subnet: 172.16.238.0/24
When you start these services with docker-compose up
, Docker will create a new bridge for the attacknet
network and assign the suricata
and attacker
containers to it. The actual name of the bridge (which might be something like br-<random ID>
) is not specified in your docker-compose.yml
file, but you can find it by running the command docker network inspect attacknet
.
So when I referred to br0
, it was a hypothetical example. In the context of your setup, you can replace br0
with the actual bridge interface Docker has created for your attacknet
network.
The IPv4 addresses you are assigning to your services (172.16.238.10
and 172.16.238.11
) are the addresses these services will have within the attacknet
network. The subnet for the attacknet
network (172.16.238.0/24
) is also defined in the docker-compose.yml
file.