> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-cloud-posture-management/cases-and-issues/investigation-and-response/automation/engines/install-an-engine/docker/docker-hardening-guide/docker-network-hardening.md). # Docker network hardening Docker creates its 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. * **Block network access to the host machine** Integrations and scripts 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 engine machine. For example, to limit all source IPs from containers that use the IP ranges 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 that use addresses in the IP address range of 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's **`daemon.json`** config file, use the configured range. Alternatively, you can limit specific interfaces by using the interface name, such as **`docker0`**, as a source. 1. Add the following iptables rule for each private IP on the tenant machine: **`sudo iptables -I INPUT -s <`*****`IP address range`*****`> -d <`*****`host private ip address`*****`> -j DROP`** 2. (Optional) To view a list of all private IP addresses on the host machine, run **`sudo ifconfig -a`** * **Assign a Docker network for a Docker image** If your engine is installed on a cloud provider such as AWS or GCP, it is 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 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`** 1. 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-metadata`** 2. Edit the engine configuration file either by editing the `d1.conf` file, or If you installed via Shell, you can edit the configuration in the UI as well as editing the file directly. For details, see [Configure engines](/cortex-cloud-posture-management/cases-and-issues/investigation-and-response/automation/engines/configure-engines.md). 3. Add the following key. **`"python.pass.extra.keys.demisto/boto3py3": "--network=aws-metadata"`** 4. Save the changes. 5. Restart the demisto service on the engine machine. **`sudo systemctl start d1`** (Ubuntu) **`sudo service d1 restart`** 6. Verify 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. We recommend this setting 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 an SSRF or DNS rebind attack to access internal network resources. 1. Create a new Docker network by running the following command: **`sudo docker network create -d bridge -o com.docker.network.bridge.name=docker-external external`** 2. Block network access to the host machine for the new Docker network: **`iptables -I INPUT -i docker-external -d -j DROP`** 3. Block network access to cloud provider instance metadata: **`sudo iptables -I DOCKER-USER -i docker-external -d 169.254.169.254/32 -j DROP`** 4. Block internal network access: **`sudo iptables -I DOCKER-USER -i docker-external -d 10.0.0.0/8 -j DROP`** **`sudo iptables -I DOCKER-USER -i docker-external -d 172.16.0.0/12 -j DROP`** **`sudo iptables -I DOCKER-USER -i docker-external -d 192.168.0.0/16 -j DROP`** 5. Edit the engine configuration file either by editing the `d1.conf` file, or If you installed via Shell, you can edit the configuration in the UI as well as editing the file directly. For details, see [Configure engines](/cortex-cloud-posture-management/cases-and-issues/investigation-and-response/automation/engines/configure-engines.md). 6. Add the following key to run integrations that use the **`demisto/chromium`** Docker image with the Docker network **`external`**. **`"python.pass.extra.keys.demisto/chromium": "--network=external"`** 7. Save the changes. 8. Restart the demisto service on the engine machine. **`sudo systemctl start d1`** (Ubuntu) **`sudo service d1 restart`** 9. Verify 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: * [Ubuntu](https://help.ubuntu.com/community/IptablesHowTo) * [Red Hat and related operating system flavors](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-setting_and_controlling_ip_sets_using_iptables) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-cloud-posture-management/cases-and-issues/investigation-and-response/automation/engines/install-an-engine/docker/docker-hardening-guide/docker-network-hardening.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.