More Info:
Network Security Groups should not have rules allowing all ports (1-65535) or all protocols. Such rules effectively disable network-level access control.Risk Level
MediumAddress
Compliance, SecurityCompliance Standards
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- DPDPA
- Digital Operational Resilience Act (EU)
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Using Console
Using Console
To remediate “OCI Network Security Rules Should Not Allow All Ports” using the OCI Console, you need to find and fix any security list or NSG rule where the destination port is set to “all” (0–65535 or left blank).Below are the practical steps.
1. Identify non‑compliant rules
A. From Cloud Guard (if you’re using it)
- In the OCI Console, open the ☰ menu.
- Go to Security → Cloud Guard.
- Click Detections (or Problems).
- Filter by:
- Resource type: Security List or Network Security Group
- Or search text:
port,0-65535,all ports, or similar.
- Open each problem to see:
- Compartment
- VCN
- Security List or NSG name
- Offending rule (protocol/ports/source/destination)
B. Manually via Networking (if Cloud Guard not in use)
- Go to ☰ → Networking → Virtual Cloud Networks.
- For each relevant VCN, check both:
- Security Lists
- Network Security Groups
- Protocol =
TCP,UDP, orAll, and - Destination port is a range like
0-65535,1-65535, or left as “all”.
2. Fix Security List rules
- Go to ☰ → Networking → Virtual Cloud Networks.
- Click the VCN that contains the bad rule.
- In the left pane, click Security Lists.
- Click the Security List name.
- Under:
- Ingress Rules: to fix incoming rules.
- Egress Rules: to fix outgoing rules.
- Click Edit All Rules (or Add Ingress Rule / Add Egress Rule as needed).
- Note what it is being used for (SSH, HTTP, DB, etc.).
- Decide the specific port(s) required (e.g., 22, 80, 443, 1521).
-
Option 1 – Replace the rule (recommended):
- Delete the “all ports” rule from the list.
- Add one or more new rules with:
- Source (ingress) or Destination (egress) narrowed (CIDR or specific subnet).
- IP Protocol =
TCP/UDP(avoidAllif not required). - Destination Port Range = the specific port or small port range (e.g.,
22,443,1024-1040).
-
Option 2 – Narrow the port range:
- If you cannot yet fully restrict to single ports, change the Destination Port Range from
0-65535to a minimal necessary range.
- If you cannot yet fully restrict to single ports, change the Destination Port Range from
- Click Save Changes.
3. Fix Network Security Group (NSG) rules
- Go to ☰ → Networking → Virtual Cloud Networks.
- Click the VCN.
- Click Network Security Groups.
- Click the NSG name.
- Check:
- Ingress Rules
- Egress Rules
- Click the Actions menu (three dots) next to the rule and choose Remove.
- Click Add Ingress Rule or Add Egress Rule to re-create a restricted rule:
- Source Type/Destination Type: CIDR, NSG, or Service.
- Source/Destination: Narrow as much as possible.
- IP Protocol: Prefer
TCPorUDP, notAll. - Destination Port Range: Enter the exact port or narrow range (e.g.,
22,443,1433, etc.).
- Click Add Ingress Rule / Add Egress Rule to save.
4. Validate using Monitoring / Cloud Guard
-
If Cloud Guard is enabled:
- Go to ☰ → Security → Cloud Guard → Detections.
- Confirm the earlier problems are now Resolved or in a non-failing state after the next evaluation cycle.
-
Optionally, use:
- VCN Flow Logs or Network Monitoring features to verify legitimate traffic still works.
- Connectivity tests (SSH, HTTP, application checks).
5. General hardening tips (brief)
- Never leave:
- Ingress:
0.0.0.0/0toAll ProtocolsonAll Ports. - Wide open egress rules to all destinations on all ports from sensitive subnets.
- Ingress:
- Use:
- Minimal required ports.
- Private CIDRs or specific NSGs as source/destination instead of public
0.0.0.0/0where possible. - Separate NSGs per application tier (web, app, DB) to keep rules tight.
Using CLI
Using CLI
Below is a practical, CLI‑only way to identify and remediate “allow all ports” rules in OCI network security lists and NSGs.
For each security list OCID, inspect rules:You’re looking for rules with:
For each NSG:Again, identify rules that:
When done, keep only fields expected by the update API. Safest: build a minimal JSON like:Save as Repeat for each affected security list.
Find the offending rule, note its Adjust
If you paste one example of a current security list / NSG rule JSON, I can give you an exact before/after JSON and CLI line for that specific rule.
1. Prerequisites
- OCI CLI installed and configured (
oci setup config) - Your compartment OCID handy:
ocid1.compartment.oc1...
2. Identify Problem Rules
2.1. Security Lists
List all security lists in the compartment:0.0.0.0/0or wide CIDR (e.g.,0.0.0.0/0,::/0)protocol = "all"ortcpOptions/udpOptionswith:destination-port-range.min = 1andmax = 65535(or missing = all ports)
2.2. Network Security Groups (NSGs)
List NSGs:- Allow from
0.0.0.0/0or::/0 - Have
protocol = "all"or full port ranges (1–65535)
3. Remediate Security List Rules (CLI)
You cannot partially edit a single rule on security lists; you must update the list with a new JSON definition of rules.3.1. Export Existing Security List
sec-list.json will look roughly like:3.2. Edit the JSON Locally
- Remove any “allow all ports” rules, or
- Narrow to specific ports (e.g., 80 and 443) and/or CIDRs.
sec-list-update.json.3.3. Apply the Update
4. Remediate NSG Rules (CLI)
With NSGs, you can add or delete individual rules.4.1. Delete “Allow All Ports” Rule
First list rules with OCIDs:id:4.2. Add Restrictive Rule(s)
Example: allow inbound TCP 22 from a specific admin subnet only:source, ports, and direction as needed.5. Tie to Monitoring / Cloud Guard
If this finding came from Cloud Guard:- After fixing rules, you can re-evaluate problems or wait for the next assessment.
- Optionally, configure a Responder Recipe in Cloud Guard that:
- Detects rules with
0.0.0.0/0+ all ports / all protocols. - Triggers a responder that removes or restricts those rules (if you want automation).
- Detects rules with
oci cloud-guard CLI commands if needed.If you paste one example of a current security list / NSG rule JSON, I can give you an exact before/after JSON and CLI line for that specific rule.
Using Python
Using Python
Below is a practical way to detect and remediate “allow all ports” rules in OCI Network Security using Python and the OCI SDK.We’ll:
(You’ll need to slightly adapt
If you specify:
- Identify which objects to scan (Security Lists and/or Network Security Groups).
- Detect rules that allow “all ports”.
- Update them to a more restrictive configuration (or at least flag them).
0. Prerequisites
- Install the OCI Python SDK:
-
Have your OCI config file in place (typically
~/.oci/config) with a profile, e.g.[DEFAULT]. -
Know:
- The compartment OCID you want to scan.
- Whether you want to check Security Lists, NSGs, or both.
1. Logic to Detect “Allow All Ports” Rules
In OCI, “allow all ports” is usually:tcp_optionsorudp_options:- Either
destination_port_rangemissing (means any port), or destination_port_range.min == 1andmax == 65535(or 0–65535 in older configs).
- Either
- OR protocol ==
"all"/"all"in security lists. - Source CIDR often
"0.0.0.0/0", but even non-0.0.0.0/0 can be too broad depending on your policy.
2. Python Script: Scan and Remediate Security Lists
This example:- Lists all Security Lists in a compartment.
- Finds ingress rules that:
- Source is
0.0.0.0/0, and - Protocol is
6(TCP) or17(UDP) or"all", and - Ports are unrestricted.
- Source is
- Remediation example: removes those rules or replaces them with a specific allowed port (e.g., 22).
3. Python Script: Scan and Remediate NSG Security Rules (Optional)
If you’re using NSGs, similar logic applies, but usingNetworkSecurityGroupRulesClient.Skeleton:is_all_ports_ingress and build_restricted_rule for NSG rule models, but the concepts are identical.)4. Operationalizing as “Monitoring”
To make this actual “monitoring” for OCI networking:- Run this script on a schedule:
- Use a cron job on a bastion/management host or
- Use OCI Functions + Events (triggered on
CreateNetworkSecurityGroupSecurityRules,UpdateSecurityList, etc.).
- Start with
DRY_RUN = Trueto log-only. - Send findings to:
- OCI Logging,
- Email (via OCI Notifications),
- SIEM, etc.
- After validating, switch to
DRY_RUN = Falseto auto-remediate.
If you specify:
- Exact allowed ports,
- Whether to delete or tighten rules, I can tailor the code to your precise security policy.
Using Terraform
Using Terraform
protocol = "all" or a full 1-65535 port range to specific protocol/ports updates the security rule in place and does not force replacement of the NSG itself, but the rule resources will be modified and traffic not matching the new ports will be blocked.To verify, terraform plan should no longer show rules with protocol = "all" or TCP/UDP options spanning ports 1-65535, and instead show updates (or creates/destroys) that narrow each rule to the required ports and CIDRs.
