Blame
|
1 | # NSE4 |
||||||
|
2 | Basics for NSE4 - FortiOS 7.6 Administrator |
||||||
|
3 | |||||||
|
4 | ## Routing |
||||||
|
5 | ### RPF - Reverse Path Forwarding |
||||||
|
6 | Anti IP Spoofing. |
||||||
| 7 | ||||||||
| 8 | ✅ Strict RPF (uRPF strict) |
|||||||
| 9 | A packet is allowed only if the best (longest‑match / preferred) route back to the source IP would exit the same interface the packet arrived on. |
|||||||
| 10 | ||||||||
| 11 | Think: “Would I send the reply back out the same interface?” |
|||||||
| 12 | If no → drop. |
|||||||
| 13 | ||||||||
| 14 | ✅ Loose RPF (uRPF loose) |
|||||||
| 15 | A packet is allowed if the firewall/router has any route at all to the source IP (regardless of interface). It’s basically a route existence check. |
|||||||
| 16 | ||||||||
| 17 | Think: “Do I have some route to that source?” |
|||||||
| 18 | If yes → allow. |
|||||||
| 19 | ||||||||
|
20 | #### RPF Example |
||||||
|
21 | |||||||
| 22 | Topology (classic multi-homed/asymmetric routing) |
|||||||
| 23 | ISP-A (WAN1) ----------------- |
|||||||
| 24 | | \ |
|||||||
| 25 | | (best route to source) \ Internet |
|||||||
| 26 | +---+---+ \ |
|||||||
| 27 | | Forti | \ |
|||||||
| 28 | | Gate | \ |
|||||||
| 29 | +---+---+ \ |
|||||||
| 30 | | \ |
|||||||
| 31 | ISP-B (WAN2) ------------------------(packet arrives here) |
|||||||
| 32 | ||||||||
| 33 | Routing table on FortiGate (simplified) |
|||||||
| 34 | 203.0.113.0/24 via WAN1 ← best/preferred route |
|||||||
| 35 | default route(s), etc. |
|||||||
| 36 | ||||||||
| 37 | Traffic event |
|||||||
| 38 | A packet arrives on WAN2: |
|||||||
| 39 | ||||||||
| 40 | Src = 203.0.113.5 |
|||||||
| 41 | Dst = your public VIP / service |
|||||||
| 42 | Ingress interface = WAN2 |
|||||||
| 43 | ||||||||
| 44 | RPF decision |
|||||||
| 45 | Strict RPF: |
|||||||
| 46 | ||||||||
| 47 | Look up route to 203.0.113.5 |
|||||||
| 48 | Best route says: send to WAN1 |
|||||||
| 49 | But packet came in WAN2 |
|||||||
| 50 | Mismatch → DROP |
|||||||
| 51 | ||||||||
| 52 | Loose RPF: |
|||||||
| 53 | ||||||||
| 54 | Look up route to 203.0.113.5 |
|||||||
| 55 | A route exists (via WAN1) |
|||||||
| 56 | Loose mode does not care that it arrived on WAN2 |
|||||||
| 57 | Route exists → ALLOW |
|||||||
| 58 | ||||||||
|
59 | ## FSSO - Fortinet Single Sign On |
||||||
|
60 | |||||||
|
61 | FSSO is about mapping an IP address → a user (and groups) so FortiGate can apply identity-based policies without prompting users to log in again. |
||||||
|
62 | |||||||
|
63 | When a user logs in, FSSO typically collects: username, domain, workstation, IP address, and group membership, and forwards it to FortiGate/FortiManager |
||||||
|
64 | |||||||
|
65 | ### Operational modes |
||||||
| 66 | ||||||||
|
67 | **A) Collector Agent (CA) (Windows FSSO agent)** |
||||||
|
68 | |||||||
|
69 | The FSSO Collector Agent runs as a service and collects logon events, then sends user/IP mappings to FortiGate (often based on group filters). |
||||||
| 70 | ||||||||
| 71 | It can collect data either from DC Agents or by polling Domain Controllers directly. |
|||||||
| 72 | ||||||||
| 73 | **B) DC Agent (domain controller plugin)** |
|||||||
|
74 | |||||||
|
75 | In DC Agent mode, each Domain Controller has a Fortinet DC Agent installed (a DLL), which reads auth events and forwards them to the Collector. |
||||||
| 76 | ||||||||
| 77 | **C) Polling mode (no software on DCs)** |
|||||||
|
78 | |||||||
|
79 | In Polling mode, the Collector Agent polls the DCs for logon events and forwards them to FortiGate. |
||||||
| 80 | ||||||||
|
81 | ### Combinations / Design |
||||||
| 82 | ||||||||
| 83 | **Option 1 — FortiGate built‑in polling (“agentless” on the FortiGate)** |
|||||||
|
84 | |||||||
|
85 | What it is: FortiGate itself acts like a collector and queries DCs for login events (no Windows CA required). |
||||||
| 86 | ||||||||
| 87 | Strengths: Simple setup; no separate CA host required. |
|||||||
| 88 | ||||||||
| 89 | Limitations: Typically supports only a limited number of monitored DCs and has no user logout monitoring in that scenario. |
|||||||
| 90 | ||||||||
| 91 | **Option 2 — Windows Collector Agent in Polling mode (CA polls DCs)** |
|||||||
|
92 | |||||||
|
93 | What it is: You install only the CA on a Windows server, and it polls DCs for logon events. |
||||||
| 94 | ||||||||
|
95 | Why choose it: “No 3rd‑party software on Domain Controllers” — simpler politically/operationally in many orgs. |
||||||
|
96 | |||||||
|
97 | Polling methods you may see/tested: |
||||||
| 98 | ||||||||
| 99 | NetAPI polling (fast, but may miss some logons if DC is heavily loaded). |
|||||||
| 100 | ||||||||
| 101 | Windows Security Event Log polling (slower but less likely to miss events under load; needs good network links). |
|||||||
| 102 | ||||||||
| 103 | Event log via WMI (also listed as an option in Fortinet guidance for polling mode). |
|||||||
| 104 | ||||||||
| 105 | Ports/traffic: Polling uses Windows remote access mechanisms (SMB/RPC/WMI), which can mean more overhead than DC-Agent mode |
|||||||
| 106 | ||||||||
|
107 | **Option 3 — Windows Collector Agent + DC Agents (DC Agent mode)** |
||||||
| 108 | ||||||||
| 109 | What it is: Install DC Agent on every DC + a Collector Agent (usually not on the DC if you want to isolate resources). |
|||||||
| 110 | ||||||||
| 111 | Why choose it: Fortinet calls this recommended for large user environments due to scalability/performance, and it’s considered very reliable for capturing logons. |
|||||||
| 112 | ||||||||
| 113 | Tradeoffs: Requires installs + typically reboots after DC Agent install, plus ongoing maintenance on all DCs. |
|||||||
| 114 | ||||||||
| 115 | Comms (useful detail): The CA communicates with FortiGate over TCP/8000, and DC/TS agents commonly use UDP/8002 to update the CA. |
|||||||
| 116 | ||||||||
| 117 | ### Collector Agent |
|||||||
| 118 | ||||||||
| 119 | **Windows Collector Agent: Standard vs Advanced** |
|||||||
| 120 | ||||||||
| 121 | This is a common exam gotcha because it affects group resolution and filtering. |
|||||||
| 122 | ||||||||
| 123 | Standard mode |
|||||||
| 124 | ||||||||
| 125 | Group/user format is simpler (e.g., DOMAIN\user). |
|||||||
| 126 | Often used when you want easier group handling and/or when LDAP access constraints exist. |
|||||||
| 127 | ||||||||
| 128 | Advanced mode |
|||||||
| 129 | ||||||||
| 130 | Uses LDAP Distinguished Name style group info (DN) and enables better parsing, including nested groups (a major real-world reason to use it). |
|||||||
| 131 | ||||||||
| 132 | Fortinet notes that certain group-filter designs and integrations require Advanced mode in practice. |
|||||||
| 133 | ||||||||
|
134 | |||||||
|
135 | ## Security Profiles |
||||||
|
136 | |||||||
|
137 | ### Anti Virus |
||||||
|
138 | |||||||
|
139 | ### Web Filter |
||||||
|
140 | |||||||
|
141 | ### IPS |
||||||
|
142 | |||||||
|
143 | ### Application Control |
||||||
|
144 | |||||||
|
145 | ## Certificates |
||||||
