Unit 3.2: Network Security: Firewall and Security Groups

Introduction

Segmentation in Unit 3.1 gave FinCorp three LANs: a public edge, a private application tier, and a private-only data tier. Topology alone does not enforce who may talk to whom. The enforcement layer sits on the server NICs, and it is the next decision in the network design: a per-NIC firewall and Network Security Groups both bind to virtual machine network interfaces, and both default to denying everything once you turn them on.

This unit ends by building that enforcement in the Data Center Designer for the FinCorp environment: firewall rules that allow only the inter-tier flows the architecture requires, plus a flow log written to an Object Storage bucket so the security team can verify, after the fact, exactly which connections were accepted and which were rejected. Before the build, two things must be clear: how the firewall evaluates traffic, and where the firewall constructs stop applying.

1. NIC firewall mechanics and the deny-by-default contract

The IONOS firewall is a property of an individual server NIC, not of a subnet, a LAN, or the VDC as a whole. A NIC with no firewall passes all traffic. The moment you activate the firewall on that NIC, the contract inverts: with the firewall on and no rules defined, all incoming traffic is blocked. Every connection you want to permit is then an explicit allow rule. There is no separate "deny" rule to write, and least privilege is achieved simply by not adding a rule, which mirrors the access-control posture you saw in governance.

The firewall is stateful. When a rule permits an outbound connection, the corresponding return packets are allowed back automatically; you do not write a mirror-image rule for the reply traffic. This matters for the FinCorp application tier: a rule allowing the app servers to reach the PostgreSQL endpoint on the data tier also permits the query results to flow back, without a second inbound rule on the app NIC for the database's response.

Rules can be applied per direction. When activating the firewall you choose Ingress, Egress, or Bidirectional, and each rule itself carries a direction of Ingress or Egress. A rule matches on protocol and the relevant fields for that protocol. The supported protocols are TCP, UDP, ICMP, ICMPv6, VRRP, GRE, AH, and ESP, plus an "Any protocol" option. For TCP and UDP you specify port ranges; for ICMP and ICMPv6 you specify type and code (for example, type 8 for echo requests). A rule can also constrain Source MAC, Source IP/CIDR, and Destination IP/CIDR, where the destination field is useful when a NIC carries virtual IP addresses.

Because hand-writing rules for common roles is error-prone, the DCD ships rule templates. The following templates are available and pre-populate a typical rule set:

A template is a starting point, not a finished policy. The Generic Webserver template, for instance, allows HTTP and HTTPS from all sources, which is appropriate for an internet-facing edge NIC but wrong for a private tier. Rules can also be cloned from another NIC, which keeps a fleet of identical servers consistent. The firewall data path is rated up to 6 Gbps of throughput per the facts matrix, which is ample for tier-to-tier filtering but is a number to keep in mind for very high-bandwidth NICs.

2. NSGs versus the NIC firewall, and the boundary where neither applies

The per-NIC firewall is local: its rules live on one NIC and are managed there. Network Security Groups solve the scaling problem. An NSG is a named, reusable set of rules created at the VDC level and then attached to servers or NICs, so one policy can govern many interfaces and a change to the group propagates to every attached member. NSGs can be managed through the DCD, the Cloud API, the Go Cloud SDK, and Terraform.

Every newly created VM in a VDC is automatically added to the Default NSG, which ships with four predefined rules: allow all IPv4 egress, allow all IPv6 egress, allow IPv4 ingress only from the VDC's 10.0.0.0/24 range, and allow IPv6 ingress only from the /56 IPv6 CIDR allocated to the data center. That default is permissive on egress and east-west by design, so a regulated tenant such as FinCorp typically replaces it with custom groups that grant only the required flows. Custom NSGs are deny-all by default, like the NIC firewall, so each allowed flow is again an explicit rule.

NSGs are stateful, support both INGRESS and EGRESS rules, and accept the protocol set UDP, TCP, ICMP, ICMPv6, GRE, VRRP, ESP, AH, and ANY. The capacity limits are worth knowing at design time: up to 10 NSGs per NIC, up to 10 per VM, up to 100 rules per NSG, and up to 200 NSGs per VDC. Attachment is granular: you can attach a group at the VM level, where it covers all NICs of that VM, or at the individual NIC level for tighter control. When a VM is a member of an NSG, all of that VM's NICs implicitly inherit the rules.

The following table contrasts the two constructs to guide where each belongs:

A common design instinct is to layer both for defence in depth. Be deliberate here: the facts matrix records that parallel use of NSGs and the NIC firewall is not the recommended pattern, so pick one enforcement model per environment rather than running overlapping rule sets that are hard to reason about. For FinCorp, NSGs are the better fit because the security posture is defined per tier and reused across many identical servers.

There is an explicit boundary that governs the rest of Module 3. NSGs and NIC firewalls bind to VM network interfaces only. They do NOT apply to the managed load balancers (the Managed Application Load Balancer and Managed Network Load Balancer) and they do NOT apply to the Managed Kubernetes cluster abstraction. Concretely, you cannot add Managed Kubernetes node-pool nodes (or suspended Cubes) to an NSG. This is why the layered architecture isolates the data tier with topology and places filtering on the targets behind a balancer rather than on the balancer itself: the Managed ALB has no dedicated firewall of its own, and the Managed NLB carries only basic, immutable firewall rules generated automatically from its forwarding rules, so all customer-configurable allow rules live on the backend VMs' NICs or their NSGs. Treat this as a design input, not a gap: the native pattern is target-side filtering plus private-by-default placement.

One operational caveat on access control: turning the NSG privilege off for a sub-user does not fully lock them out. A user who can still reach the relevant data center can continue to manage existing NSGs; the privilege gates creating and using NSGs, not managing groups that already exist. Plan group ownership and data-center access together.

DCD Implementation Walkthrough

You will apply tier-to-tier firewall rules to the FinCorp application servers and then enable a flow log on a NIC so the security team can verify what the firewall accepts and rejects. This realises the enforcement layer over the three-LAN topology from Unit 3.1. Prerequisites: the VDC and its server NICs from Unit 3.1 already exist, and a user-owned Object Storage bucket must exist before the flow log can target it (only contract administrators and owners can enable Object Storage, and the flow-log creator needs the Create Flow logs privilege).

Build goal: Apply firewall rules between tiers; enable a flow log to an Object Storage bucket.

Steps (in the Data Center Designer):

1. Open the VDC, and in the Workspace select an application-tier server that has a NIC on the private application LAN.
2. In the Inspector pane, open the Network tab, then open the properties of the NIC you want to protect.
3. Activate the firewall on that NIC by choosing the traffic flow type to enforce: Ingress, Egress, or Bidirectional. Once active with no rules, the NIC blocks all incoming traffic, so define rules before relying on it.
4. Click Manage Rules, then Create Firewall Rule, and choose the protocol for the rule (TCP, UDP, ICMP, ICMPv6, VRRP, GRE, AH, ESP, or Any Protocol). For the app-to-database flow, create a TCP rule.
5. Fill the rule fields: a Name; Direction (Egress for the app server reaching the database); Source IP/CIDR and Destination IP/CIDR scoped to the private ranges; and the destination port for the database. Leave IP Version as Auto unless you are pinning a family. The stateful firewall allows the return traffic automatically, so no inbound reply rule is needed.
6. For role-based servers, optionally use Rules from Template (Generic Webserver, Mailserver, Remote Access Linux, Remote Access Windows) as a starting point, then tighten the sources; or use Clone Rules from another NIC to keep identical servers consistent. Click Save.
7. To enable a flow log on the same NIC, open the NIC properties' Flow Log drop-down (for a Managed NLB or Managed NAT Gateway you would instead use the element's Settings tab) and enter a Name. This name becomes the first part of the object-name prefix in the bucket.
8. Set Direction (Ingress, Egress, or Bidirectional), Action (Rejected to capture only blocked traffic, Accepted to capture only allowed traffic, or Any), and the Target Object Storage bucket: a valid existing user-owned bucket name plus an optional object-name prefix. Choose Add flow log.
9. A green light on the NIC properties confirms the configuration validated. Select PROVISION CHANGES. After provisioning completes, both the firewall rules and the flow log are active, and per-flow records begin landing in the bucket as gzip-compressed .log.gz files.

Each flow record is per-flow, aggregated over a fixed 10-minute interval with no sampling (all flows in the interval are recorded), and intervals with no traffic are skipped. Each record carries fields including source and destination address and port, IANA protocol number, packet and byte counts, start and end timestamps, and an action field of ACCEPT or REJECT. The action field is precisely the verification signal: set the flow log Action to Rejected when you want to see only what the firewall is dropping, which is the fastest way to find a missing allow rule, or Accepted to confirm only the intended flows are getting through.

Common mistakes:

• Activating the firewall on a NIC and then walking away. With the firewall on and no rules, the NIC blocks all incoming traffic; define the allow rules in the same change.
• Writing a return-traffic rule. The firewall and NSGs are stateful, so a permitted outbound connection's replies are allowed automatically. A mirror inbound rule is redundant and clutters the policy.
• Running NSGs and the NIC firewall in parallel for the same NICs. Parallel use is not the recommended pattern; choose one enforcement model per environment.
• Leaving the Default NSG in place for a regulated tier. It allows all egress and east-west traffic within the VDC; replace it with custom deny-all groups that grant only the required flows.
• Expecting a firewall or NSG to protect a managed load balancer or Kubernetes nodes. Neither construct binds there. Put the allow rules on the backend VM NICs and use in-cluster network policies for Kubernetes.
• Pointing a flow log at a bucket that does not exist yet, or one not owned by your contract. The destination must be an existing user-owned Object Storage bucket; create it first.
• Assuming deleting the flow-log rule cleans up the data. Deleting the rule stops new records but does not delete existing log objects from the bucket, nor change their policies or ACLs.
• Treating flow logs as a managed retention service. There is one flow log per resource, the record format and configuration are immutable after creation, and retention is entirely customer-managed: set an Object Storage lifecycle policy on the destination bucket (or delete manually). Nothing expires automatically unless you configure it.

A short ionosctl check after provisioning confirms the firewall rules attached to the NIC, which is useful in an audit script:

ionosctl firewallrule list --datacenter-id "$DC_ID" \
  --server-id "$SRV_ID" --nic-id "$NIC_ID"

The architectural point is that the rule set is queryable and therefore auditable as configuration; the enforcement decision still lives in the design above, not in the command.

Summary

FinCorp's three-tier topology becomes a security boundary only when enforcement is applied at the server NICs. Both the per-NIC firewall and Network Security Groups bind to VM interfaces, are stateful, and deny by default once active (with the notable exception of the permissive Default NSG). NSGs win when one policy must govern many interfaces; the per-NIC firewall suits one-off exceptions. Critically, neither construct reaches the managed load balancers or the Managed Kubernetes cluster abstraction, which forces filtering onto the targets and reinforces private-by-default placement. Flow logs close the loop: they write immutable, per-flow ACCEPT/REJECT records to a customer-owned Object Storage bucket, turning "what does the firewall actually do" from an assumption into evidence.

Key Points:

• The NIC firewall and custom NSGs are deny-by-default once active; every allowed flow is an explicit rule, and least privilege is achieved by not granting.
• Both are stateful, so return traffic for a permitted connection is allowed automatically; do not write mirror rules.
• NSGs are reusable VDC-level policies (up to 10 per NIC/VM, 100 rules each, 200 per VDC); the NIC firewall is local. Parallel use of both is not recommended.
• NSGs and NIC firewalls do not apply to managed load balancers or to Managed Kubernetes node-pool nodes; filtering moves to the targets and to in-cluster network policies.
• Flow logs publish per-flow records (10-minute aggregation, no sampling) with an ACCEPT/REJECT action field to a user-owned Object Storage bucket; there is one flow log per resource, the format is immutable, and retention is customer-managed via lifecycle policy.