Use the Docker network hardening guide to control network access.
Docker creates its own networking stack that enables containers to communicate with other networking endpoints. You can use iptables rules to restrict which networking sources the containers communicate with. By default, Docker uses a networking configuration that allows unrestricted communication for containers, so that containers can communicate with all IP addresses.
Note
The instructions below are for integrations and automations that use Docker (Python and PowerShell). To limit JavaScript integrations, use the advanced server configuration: js.http.restricted with a comma-separated list of IPs/hosts to limit access to. For example:
Key | Value |
|---|---|
js.http.restricted | 169.254.169.254,localhost,127.0.0.1 |
The default Docker network is bridge and the default interface is docker0. To list the Docker networks, run sudo docker network ls on the server machine. To inspect the network properties, run sudo docker network inspect <. For example: network name>sudo docker network bridge.
Block Network Access to the Host Machine
Integrations and automations running within containers do not usually require access to the host network. For added security, you can block network access from containers to services running on the host machine (including the Cortex XSOAR server).
Add the following iptables rule for each private IP on the host machine:
sudo iptables -I INPUT -s <IP address range> -d <host private ip address> -j DROPFor example, to limit all source IPs from containers that use the IP range 172.16.0.0/12, run
sudo iptables -I INPUT -s 172.16.0.0/12 -d 10.18.18.246 -j DROP. This also ensures that new Docker networks which use addresses in the IP address range 172.16.0.0/12 are blocked from access to the host private IP. The default IP range used by Docker is 172.16.0.0/12. If you configured a different range in Docker'sdaemon.jsonconfig file, use the configured range. Alternatively, you can limit specific interfaces by using the interface name, such as docker0, as source.On Linux, the host incoming traffic is also exposed on the gateway IP of the default docker networking. Usually this is 172.17.0.1 but it may be different if you have a non-default configuration. To block access to the gateway IP, add the following rule:
iptables -I INPUT -i docker0 -d 172.17.0.1/32 -j DROP.(Optional) To view a list of all private IP addresses on the host machine, run
sudo ifconfig -a
Block Network Access to Cloud Provider Instance Metadata
If your Cortex XSOAR Server is installed on a cloud provider such as AWS or GCP, it is a best practice to block containers from accessing the cloud provider’s instance metadata service. The metadata service is accessed via IP address 169.254.169.254.
For more information about the metadata service and the data exposed, see the AWS and GCP documentation.
To block access from containers, add the following iptables rule:
sudo iptables -I DOCKER-USER -i docker0 -d 169.254.169.254/32 -j DROP
Note
On GCP, the metadata server is also sometimes used for DNS. To allow DNS queries to the metadata server, configure the following rule:
iptables -I DOCKER-USER -i docker0 -d 169.254.169.254/32 -p udp --dport 53 -j ACCEPT
Assign a Docker Network for a Docker Image
There are cases where you might need to provide access to the metadata service. For example, access is required when using an AWS integration that authenticates via the available role from the instance metadata service. You can create a separate Docker network, without the blocked iptable rule, to be used by the AWS integration’s Docker container. For most AWS integrations the relevant Docker image is: demisto/boto3py3
Create a new Docker network by running the following command:
sudo docker network create -d bridge -o com.docker.network.bridge.name=docker-metadata aws-metadataIn Cortex XSOAR, add a server configuration to use your new Docker network to run integrations that use the
demisto/boto3py3Docker image.Key
Value
python.pass.extra.keys.demisto/boto3py3--network=aws-metadataReset the running containers:
/reset_containersVerify the configuration of your new Docker network:
sudo docker network inspect aws-metadata
Block Internal Network Access
In some cases, you might need to block specific integrations from accessing internal network resources and allow the integrations to access only external IP addresses. This setting is recommended for the Rasterize integration when used to rasterize untrusted URLs or HTML content, such as those obtained via external emails. With internal network access blocked, a rendered page in the Rasterize integration cannot perform a SSRF or DNS rebind attack to access internal network resources.
Create a new Docker network by running the following command:
sudo docker network create -d bridge -o com.docker.network.bridge.name=docker-external externalBlock network access to the host machine for the new Docker network:
iptables -I INPUT -i docker-external -d <host private ip> -j DROPBlock network access to cloud provider instance metadata:
sudo iptables -I DOCKER-USER -i docker-external -d 169.254.169.254/32 -j DROPBlock internal network access:
sudo iptables -I DOCKER-USER -i docker-external -d 10.0.0.0/8 -j DROPsudo iptables -I DOCKER-USER -i docker-external -d 172.16.0.0/12 -j DROPsudo iptables -I DOCKER-USER -i docker-external -d 192.168.0.0/16 -j DROPAdd a server configuration to run integrations that use the
demisto/chromiumdocker image with the Docker networkexternal.Key
Value
python.pass.extra.keys.demisto/chromium--network=externalReset the running containers:
/reset_containersVerify the configuration of your new Docker network:
sudo docker network inspect external
Persist Iptables Rules
By default, iptables rules are not persistent after a reboot. To ensure your changes are persistent, save the iptables rules by following the recommended configuration for your Linux operating system: