JNCIS-SEC cheat sheet

SRX runs Junos OS; control plane (Routing Engine) handles management, routing protocols, and CLI, while the data plane (Packet Forwarding Engine) forwards, screens, and applies services to transit traffic.

Junos configuration is hierarchical: set commands edit a candidate config; 'commit' applies it, 'commit confirmed N' auto-rolls back after N minutes unless confirmed, and 'rollback' restores prior versions.

Factory default security devices have interfaces in the untrust zone plus a management interface; 'commit' must be run after configuration changes or the change stays in the candidate config and is lost on reboot.

Two device modes matter: flow-based (default, security services, sessions) and packet-based (stateless forwarding for some platforms). SRX branch devices are predominantly flow-based.

Session setup order for flow mode: first packet performs session lookup, then screening (syn-flood, land, etc.), then policy lookup, then NAT, then services (ALGs), then forwarding.

'show security flow session' displays active sessions; 'show security flow session summary' shows counts; 'clear security flow session all' clears them.

Interface types: physical (ge-, xe-), logical units (unit 0), reth (redundant Ethernet for chassis cluster), vlan, and tunnel (gr-, st-, ip-). Zone binding is per logical interface.

Chassis cluster combines two SRX devices: redundancy groups, control link, fabric link, and redundancy-group failover. 'show chassis cluster status' reports primary/secondary per group.

Licensing controls advanced features: UTM (antivirus, antispam, web filtering, content filtering), IDP, and AppSecure each need a license; basic firewall and NAT do not.

Security zones group logical interfaces and define trust boundaries: typical zones are trust, untrust, dmz, and management. An interface can belong to only one zone.

Policy evaluation is top-down, first-match-wins. A policy action is permit, deny, or reject (reject sends TCP RST/ICMP unreachable; deny silently drops).

A policy matches on from-zone, to-zone, source-address, destination-address, and application. If no policy matches, the default action drops the traffic.

Intra-zone traffic is governed by the same zone pair (trust to trust); by default there is no implicit permit for intra-zone traffic unless a policy exists.

Address book entries (address-book) and applications/application-sets are referenced by policies; 'any' matches everything but reduces specificity and auditability.

Applications can be predefined (junos-http, junos-ssh, junos-dns-udp) or custom (protocol tcp/udp/icmp, destination-port range, inactivity-timeout, ALG).

Zone host-inbound-traffic controls traffic destined to the device itself (system-services, protocols, and all); it does not control transit traffic.

Policy scheduling and logging: 'then log' records session events; 'count' increments a counter; 'scheduler' applies time-based policy activation.

Global policies (policy without from/to zone) and apply-groups can enforce consistent rules across zone pairs; policy order matters because first match wins.

NAT types on SRX: source NAT (SNAT), destination NAT (DNAT), static NAT, and twice NAT (source and destination in one rule). NAT is applied after policy lookup in flow mode.

Source NAT pools can be interface (uses egress interface address) or address-pool (range of addresses); PAT is the default behavior when a pool has fewer addresses than sessions.

Destination NAT maps a public address/port to an internal host; proxy-ARP is typically required on the external interface so the SRX answers ARP for the NAT address.

Static NAT is one-to-one bidirectional mapping; it does not require a separate reverse rule. Twice NAT combines source and destination translation in a single rule set.

NAT rule sets are evaluated top-down; the first matching rule is applied. Rule-set 'from' and 'to' zone context narrows which traffic the rule evaluates.

Persistent NAT (address-persistent) keeps a given internal host mapped to the same translated address for consistency; useful for logging and external services.

Session setup order in flow mode: session lookup, screen checks, policy lookup, NAT translation, ALG/services, then forwarding. NAT happens after policy match.

'show security flow session' displays the translated (post-NAT) addresses; use 'show security nat source summary' and 'show security nat destination summary' for rule statistics.

Flow forwarding decisions use the route table (inet.0) after NAT; ensure return routes exist for translated addresses or return traffic will be dropped.

IPsec phases: IKE phase 1 builds the ISAKMP SA (main or aggressive mode, pre-shared key or certificate); phase 2 builds the IPsec SA (ESP, AH, or both).

IKEv2 is preferred over IKEv1 for modern deployments; SRX supports both. Proposals define encryption (AES), hash (SHA-256), DH group, and lifetime.

Policy-based VPN uses a tunnel interface with a security policy selecting traffic; route-based VPN uses a st0 interface with a static or dynamic route, which is more scalable.

IPsec parameters must match on both peers: proposal, policy, pre-shared key, identity (local/remote), and traffic selectors (proxy-ids). Mismatch is the most common failure.

'show security ike sa' and 'show security ipsec sa' verify phase 1 and phase 2 status; 'clear security ike security-associations' resets them.

NAT-T (NAT traversal) encapsulates ESP in UDP 4500 when NAT is detected; UDP 500 carries IKE. Firewall rules must permit 500/4500 and ESP.

Dead peer detection (DPD) detects failed peers and triggers rekey or failover; configure DPD interval and threshold on the IKE gateway.

Traffic inspection: SRX can apply IDP, AppSecure, and UTM to decrypted tunnel traffic; for route-based VPNs, apply services on the st0 interface's zone.

IPsec VPN monitoring uses 'show security ipsec statistics' and 'show security ipsec tunnel-events-statistics'; logs and SNMP traps report SA up/down events.

UTM on SRX bundles antivirus, antispam, web filtering, and content filtering. Each requires a valid license and signature updates via the Junos update server.

Antivirus scans traffic at the flow level using a scanning engine and signature database; large files can be limited by max file size and scan settings.

Web filtering uses categories from a URL database (surf control / Websense style) with profile actions: permit, block, or log-and-permit.

Content filtering inspects MIME types and file extensions; it blocks or logs based on protocol/content rules.

IDP (Intrusion Detection and Prevention) applies signatures to sessions; IDP policies attach to security policies and can drop, close, or alert on matches.

AppSecure identifies applications (AppID) and can enforce application firewall rules and application QoS; it is licensed separately from UTM.

Logging: 'security log mode stream' sends logs to a syslog server; 'event mode' sends to an event server. 'show log messages' on the device shows local logs.

Monitoring commands: 'show security flow session', 'show security statistics', 'show security monitoring fpc 0' (SPU utilization), and 'show chassis alarms'.

SNMP and Netflow/IPFIX export traffic and health data to external collectors; alarms can be configured for CPU, memory, and session table thresholds.