---
title: >-
  Publicly accessible EC2 instances should not have high-risk ports open to
  unrestricted traffic
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Datadog Security > OOTB Rules > Publicly accessible EC2 instances
  should not have high-risk ports open to unrestricted traffic
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Publicly accessible EC2 instances should not have high-risk ports open to unrestricted traffic
 
## Description{% #description %}

This rule checks whether any of these high-risk ports are reachable from the Internet on an EC2 instance. The rule validates the public subnet, the public IP on the instance network interface, and the security group attached to that interface. For load-balanced exposure, the rule follows a complete path from an Internet-facing load balancer to the EC2 instance. It validates the public listener port against the load balancer security group, follows the listener's forward action to its target group, applies any target-level port override, and verifies that the EC2 security group admits the resulting backend traffic.

High-Risk Ports are defined as:

- 20, 21 (FTP)
- 22 (SSH)
- 23 (Telnet)
- 25 (SMTP)
- 110 (POP3)
- 135 (RPC)
- 143 (IMAP)
- 445 (CIFS)
- 1433, 1434 (MSSQL)
- 3000 (Go, Node.js, and Ruby web development frameworks)
- 3306 (MySQL)
- 3389 (RDP)
- 4333 (ahsp)
- 5000 (Python web development frameworks)
- 5432 (postgresql)
- 5500 (fcp-addr-srvr1)
- 5601 (OpenSearch Dashboards)
- 8080 (proxy)
- 8088 (legacy HTTP port)
- 8888 (alternative HTTP port)
- 9200 or 9300 (OpenSearch)

Restricting access to these ports is a security best practice and is required by AWS Foundational Security Best Practices.

Findings are reported against the exposed EC2 instance.

## Remediation{% #remediation %}

### From the console{% #from-the-console %}

1. In the **AWS Management Console**, navigate to **EC2** > **Security Groups** and select the affected security group.
1. Choose **Edit inbound rules**, then remove the unrestricted rule or restrict its source to a trusted CIDR range or security group.