For customers that have adopted Docker, Alert Logic® can provide support for Docker containers in specific deployment types. While this option is not without challenges, which are detailed below, the Alert Logic agent can be used to collect network traffic from a host with containers.
The following sections describe the requirements needed to use the Alert Logic agent, a description of how the agent works with Docker containers, and considerations that need to be made prior to and during deployment and configuration.
In This Article
- How the Agent Works
- Additional Resources
To use the Alert Logic agent to collect network traffic from a host with containers, the host must be running an operating system (OS) type that is supported by the agent. To review a list of supported OS types, refer to Requirements for the Alert Logic agent. Once installed, the agent handles nearly everything on its own without the need for further configuration.
In addition, this solution is ideal for deployments with single containers. However, hosts with multiple containers can still deploy the agent in this method to capture traffic.
How the Agent Works
When the Alert Logic agent is installed, it is automatically configured to listen on all interfaces, and this setting cannot be changed. The only exception is that the agent will avoid binding to loopbacks. It does bind to Docker0, which is responsible for switching traffic between containers, between containers and the host, and between containers and the outside world. This functionality results in the agent capturing all available traffic on the host that would need to be inspected.
There are some nuances to a few aspects of deploying the Alert Logic agent to capture container traffic. The following points should be considered prior to and during deployment and configuration.
It is important to note that when configuring container networking, you must set Docker0 to run in promiscuous mode by running the following command:
ip link set docker0 promisc on
This setting ensures that packets traversing from container to container in the same host will be captured properly.
The agent binds automatically to all interfaces so that no additional configuration is required. However, just binding to Docker0 does not give you full visibility to intra-container traffic. Docker0 works more like a switch, so since the agent does not set any interface in promiscuous mode, it does not capture all traffic by binding to Docker0 alone. As seen in testing, when Internet Control Message Protocol (ICMP) traffic is sent to the base host or to the outside world, the traffic becomes visible on Docker0.
Instead, to capture all of the traffic between containers, each container has its own virtual network stack by default. Docker also creates IP-less virtual ethernet (veth*) interfaces. These are effectively the endpoints of the eth* interfaces inside containers and whose traffic is forwarded to the Docker0 bridge to be switched or routed. Because of this, the agent running on the host notices and binds them, which is how it sees traffic between containers.
In addition, the agent will interrogate the Docker API to collect the container's IP address. This IP address will be registered into Alert Logic appliances as part of the Protected Hosts (agent) IP address and will be used to determine which container's IP address will be protected on that given Docker host.
The major limitation here is that these interfaces are dynamic. They are created and destroyed as containers start and stop, so it could be up to 180 minutes before containers IP address will be registered. If containers are constant in their activity and do not stop, then this should be less of a problem.
Traffic duplication is a potential problem that must be accounted for in this design. Alert Logic's Intrusion Detection System (IDS) engine does use a preprocessor, known as Stream6, that will help with traffic duplication but does not completely eliminate all duplicate packets. The amount of traffic duplication depends upon where the traffic is routed.
Container-to-Container Traffic: In the case of container-to-container traffic, the agent will capture traffic twice (once on each veth* interface). In this case, the Stream6 preprocessor should be beneficial in eliminating duplicate packets.
Container-to-Base Host Traffic: In the case of container-to-host traffic, the traffic would also be captured twice: once on veth* and once on Docker0. In this case, the Stream6 preprocessor should be beneficial here in eliminating duplicate packets.
Container-to-Outside Traffic: For traffic to the outside world, the agent will capture the traffic three times: once on veth*, once on Docker0, and once on eth0. Stream6 does not reduce traffic duplication in this scenario and is further complicated by the fact that Network Address Translation is occurring in this use case. As a result, the traffic would be treated as different sessions because the IP addresses will be different.
For more information about installing the Alert Logic agent, refer to Installing the Alert Logic agent for Linux.