NSG versus security list failure and flow-log monitoring
Tailspin has a VCN 10.40.0.0/16 with an app subnet 10.40.2.0/24 and a database subnet 10.40.3.0/24. The database NSG allows TCP 1521 from the app NSG. The database subnet security list allows TCP 1521 from 10.40.2.0/24 only. Existing app servers connect successfully. A new batch subnet 10.40.4.0/24 was added; its instances are placed in the same app NSG, but batch jobs intermittently time out connecting to the database. The database host is healthy and listens on 1521. VCN flow logs are enabled for the VCN but are not reviewed. The team also sees repeated SSH attempts from the internet against a public subnet and wants alerts without buying a third-party tool.
1. Identify the likely cause of the batch connection failures and explain why the existing app servers still work.
Read the worked answer
The batch instances are in the same app NSG, so the database NSG allows them. However, the database subnet security list allows TCP 1521 only from 10.40.2.0/24, not from the new batch subnet 10.40.4.0/24. OCI requires traffic to be allowed by both the security list and the NSG. Existing app servers work because their source CIDR is in the security list; batch instances are dropped at the security-list layer.
Fix by adding an ingress rule to the database subnet security list for TCP 1521 from 10.40.4.0/24, or by standardizing the allowed application CIDR if the batch subnet is part of the same application tier. Prefer an NSG reference where possible, but remember that security lists cannot reference NSGs. Validate with Network Path Analyzer from a batch VNIC to the database VNIC on 1521, and confirm accepted flows in VCN flow logs. If timeouts persist, check the database host firewall and the return route, but the CIDR mismatch is the first failure.
2. How would you use OCI native logging and monitoring to detect the SSH attempts and future rejected traffic?
Read the worked answer
Send VCN flow logs to OCI Logging, then use Service Connector Hub if you need to route them to Object Storage or Streaming for retention and correlation. Create a Logging search or saved query for ingress traffic to the public subnet on TCP 22 from 0.0.0.0/0 where the action is rejected. Convert that query into a Monitoring alarm or use a Logging alarm so the security team is notified when the rate exceeds a baseline.
Also create a second query for rejected traffic from unexpected CIDRs to database port 1521, which would have caught the batch-subnet issue earlier. Keep flow-log retention long enough for investigations, and restrict who can disable flow logs. This gives native detection without a third-party SIEM, while still allowing export if the organization later adds one.
3. Why is removing the database subnet security list not the right fix, and what is a safer long-term design?
Read the worked answer
Security lists apply at the subnet level and affect every VNIC in the subnet. Removing or broadening the database security list to fix one batch subnet would weaken isolation for all database VNICs and make the NSG the only effective control. It also makes the change harder to audit because the subnet baseline no longer expresses the database tier's allowed sources.
A safer design keeps a narrow subnet baseline and uses NSGs for workload-level intent: database NSG ingress on 1521 only from the app NSG, with batch instances explicitly added to that NSG or to a dedicated batch NSG if their risk profile differs. If batch and app have different trust levels, create a separate batch NSG and add a specific rule on the database NSG. Then document both layers and test with Network Path Analyzer after each subnet or NSG membership change.