Securing the Network
Securing the Network
This domain tests zone-based security design on SRX and vSRX: policy structure, screens, NAT, IPsec VPNs, application security and threat prevention. The exam expects you to design least-privilege flows, not just list features.
Core rules
- Use zones to express trust boundaries and policies to permit only required applications. Order matters; the first match wins and an implicit deny follows. Log denies and session closes.
- Apply screens on untrusted zones: SYN flood, IP spoofing, land attack, ping of death, session limits and fragmentation checks.
- NAT is evaluated in a fixed order. Destination NAT occurs before policy lookup, so policy addresses must match post-NAT destinations; source NAT occurs after policy, so logs show pre-NAT sources.
- For IPsec, prefer route-based VPNs with st0 interfaces and IKEv2. Use certificates for scale, DPD for failure detection, and ADVPN when spokes need direct spoke-to-spoke paths.
- AppSecure adds AppID, AppFW, AppQoS and AppTrack. ATP Cloud adds malware detection, infected-host detection and SSL forward proxy for encrypted traffic.
Worked example
Sixty branches must reach two hubs, with occasional branch-to-branch collaboration. Reasoning: route-based IPsec to both hubs with IKEv2 and certificates gives simpler routing and scale than policy-based VPNs. DPD detects dead peers; ADVPN permits shortcut tunnels for branch-to-branch traffic while keeping hub policy control. Policies allow only named business applications from trust to VPN, return traffic from VPN to trust, and deny everything else with logging. Screens run on the untrusted zone, and SSL forward proxy feeds ATP Cloud.
Traps that cost marks
- Permitting any/any across a VPN and calling it connectivity.
- Choosing policy-based VPNs for large hub-and-spoke estates.
- Forgetting IKE and NAT-T in the policy.
- Ignoring certificate trust chains for SSL proxy.
- No DPD, so dead tunnels persist.