Ensure there is no unrestricted inbound access to TCP port 2375 (Docker)

Security & Compliance
No items found.

TCP port 2375 is the default port used by Docker for remote management of containers. It allows remote connections to Docker daemon and control the creation, management, and deletion of containers on a remote host. If this port is left open and unrestricted, it could be exploited by attackers to gain unauthorized access to the Docker host, execute arbitrary commands or deploy malicious containers.


To ensure that there is no unrestricted inbound access to TCP port 2375, which is used by Docker, the following remediation steps can be taken:

  1. Configure Docker to use TLS encryption: By default, Docker listens on port 2375 without encryption. This can be secured by configuring Docker to use TLS encryption. This involves generating a server key and certificate, configuring Docker with these files, and configuring client authentication.
  2. Use a firewall: A firewall can be used to restrict access to the Docker daemon port to only authorized hosts. This can be done by adding firewall rules to block traffic to port 2375, except from authorized hosts.
  3. Use Docker Swarm Mode: If using Docker Swarm Mode, it is recommended to configure Docker to listen only on a specific network interface or to bind it to a UNIX socket. This will restrict access to the Docker daemon port to only authorized hosts.
  4. Restrict access to Docker API: It is recommended to restrict access to the Docker API by using a reverse proxy or by configuring Docker to only listen on a UNIX socket. This will ensure that the Docker API is not accessible from outside the server.
  5. Disable the Docker daemon: If Docker is not required on the system, it is recommended to disable the Docker daemon altogether. This can be done by stopping and disabling the Docker service.
Enforced Resources
Note: Remediation steps provided by Lightlytics are meant to be suggestions and guidelines only. It is crucial to thoroughly verify and test any remediation steps before applying them to production environments. Each organization's infrastructure and security needs may differ, and blindly applying suggested remediation steps without proper testing could potentially cause unforeseen issues or vulnerabilities. Therefore, it is strongly recommended that you validate and customize any remediation steps to meet your organization's specific requirements and ensure that they align with your security policies and best practices.