DEV Community: Jafar Tavana

🔐 FortiGate UTM Security Analyzer — v4.0 Released

Jafar Tavana — Sat, 04 Jul 2026 21:55:05 +0000

I just pushed a major version of my open-source FortiGate auditing tool. This one took significant engineering work — the codebase went from 2,555 lines to 5,695 lines and grew from 25 to 35 audit domains with 10 completely new modules.

Here's what actually changed, added, and why.

🔗 github.com/jafartavana01/fortigate-utm-analyzer

━━━━━━━━━━━━━━━━━━━━━━━━
Background
━━━━━━━━━━━━━━━━━━━━━━━━

This tool reads a FortiGate show full-configuration backup and produces severity-tagged security reports — CRITICAL / HIGH / MEDIUM / INFO — across every layer of the device. No dependencies, no cloud, no API keys. Just:

python3 utm.py -c firewall.conf --all

v1.0 covered 5 domains. v2.0 expanded to 13. v3.0 added FortiOS 8.0 syntax support. v4.0 is the biggest jump yet.

━━━━━━━━━━━━━━━━━━━━━━━━
What was ADDED in v4.0
━━━━━━━━━━━━━━━━━━━━━━━━

Policy Intelligence Module (-intel)

This is the one I've wanted to build since day one. Two checks that matter enormously in real environments:

Shadowed policy detection. If Policy #1 is "all → all ACCEPT" and Policy #2 below it is "10.0.0.0/8 → DMZ ACCEPT", Policy #2 will never be evaluated. The firewall processes rules top-down. The earlier broad rule always wins. In environments where multiple engineers have been adding rules for 5+ years without a full review, 10-20% of rules being effectively dead is not unusual. The tool now flags every one of these as HIGH.

Duplicate policy detection. Same srcintf, dstintf, srcaddr, dstaddr, service, action — two policies doing the exact same thing. Common after copy-paste policy management. HIGH severity, automated detection.

Coverage statistics with visual bars. Every accept policy is counted: how many have IPS? SSL inspection? Antivirus? DLP? The output looks like this:

IPS [████████░░░░░░░░░░░░] 40% (80/200)
SSL Inspect [██████░░░░░░░░░░░░░░] 30% (60/200)
Antivirus [████████████░░░░░░░░] 60% (120/200)
Logging [██████████████░░░░░░] 70% (140/200)

Management loves this slide. Security teams need this number.

Unused Objects Audit (-unused)

Parses every object type and cross-references against all policy fields:

Address objects
Address groups
Custom services
Service groups
VIPs (Medium severity — see below)
IP pools
Schedules

The interesting one is VIPs. An "unused" VIP — a port-forward with no matching firewall policy — may still be active at the NAT level. The FortiGate will perform the address translation even if no policy explicitly permits the traffic in some configurations. A forgotten VIP for RDP from 3 years ago is an audit finding regardless. Flagged MEDIUM to force a human decision rather than automatic dismissal.

VIP / Port-Forward Security Audit (-vip)

37 risky port definitions with per-port severity. The logic is simple: if you have a VIP that maps TCP/3389 from the internet to an internal host, that's an RDP server directly exposed to the internet. BlueKeep, credential brute-force, and ransomware operators have been scanning for this since 2019.

CRITICAL ports: RDP (3389), SMB (445), MySQL (3306), Redis (6379), PostgreSQL (5432), MongoDB (27017), VNC (5900), MS-SQL (1433), Telnet (23), Radmin (4899)
HIGH ports: LDAP (389), RPC (135), NetBIOS (137/138/139), WinRM (5985/5986), FTP (21)
MEDIUM ports: SMTP (25), HTTP (80), DNS (53)

Also checks: source filter missing (any internet IP can hit the mapped host), VIP defined but not referenced in any policy.

Full Anti-DoS Protection Audit (-antidos)

The existing -dos flag was basic. The new -antidos flag does a proper deep audit.

New anomaly sub-block parser reads every sensor individually:

Status (enable/disable)
Action (block vs monitor/pass)
Threshold value (too high = never fires, 0 = broken)
Logging enabled

Critical anomalies checked: tcp_syn_flood, tcp_ack_flood, tcp_synack_flood, udp_flood, icmp_flood, ip_src_session, tcp_port_scan, ip_bad_option, ip_land_attack, sctp_flood

Action = monitor in production is HIGH severity. The sensor is technically enabled but never drops a packet. It just logs.

Threshold = 999999 on tcp_syn_flood is also flagged. The sensor will never trigger under any realistic attack. That's as bad as disabled.

NP7/NP6 hardware offload checks: HPE (Host Protection Engine) configuration, fp-anomaly status. On NP-capable hardware, DoS mitigation that doesn't use ASIC offload hits the CPU instead. Under a real SYN flood, that's the difference between the device staying up and going unresponsive.

TCP timer hardening: tcp-halfopen-timer > 10s, anti-replay not set to strict, ip-src-check-on-tx disabled.

Scored 0-10 with ASCII bar and grade: STRONG / ACCEPTABLE / WEAK / POOR / CRITICAL.

SD-WAN Audit (-sdwan)

New nested parser handles the full SD-WAN config structure: members, health-checks, and service rules as separate sub-blocks.

The most important finding is CRITICAL: if SD-WAN is enabled but has zero health-checks configured, link failures are completely undetected. The device has no way to know a WAN member went down and will never failover. SD-WAN without health monitoring is just load-balancing with a broken failover mechanism.

Also checks: per-member monitoring gaps (each member not covered by any health-check = HIGH), missing latency/jitter/packet-loss thresholds (links with poor quality continue to carry traffic), slow probe intervals (delays failure detection by minutes), missing traffic steering rules.

Interface Exposure Score (-iface)

Each interface gets a 0-10 exposure score based on weighted protocol analysis:

Telnet weight: 10 (cleartext — worst)
HTTP weight: 9 (cleartext management)
SNMP weight: 8 (community string exposure)
FMG-Access weight: 7 (FortiManager on WAN)
Fabric weight: 6 (Security Fabric facing internet)
SSH weight: 5 (brute-force target)
HTTPS weight: 4 (GUI exposed)
Ping weight: 2 (ICMP recon)

Output per interface:
wan1 [█████████░] 9.2/10 — CRITICAL EXPOSURE
port1 [██░░░░░░░░] 2.1/10 — LOW EXPOSURE

Certificate Audit (-cert)

Parses config vpn certificate local/ca/remote.

Expiry detection with exact days remaining. CRITICAL if already expired, HIGH if ≤ 30 days, MEDIUM if ≤ 90 days. RSA key size < 2048 bits = CRITICAL (cryptographically broken). Self-signed certificate detection on external services. Auto-renew status.

Note in the report: config backups contain cert metadata but not full DER content. The tool also outputs the CLI commands to run on the device for a live expiry check.

Fabric Connector / Cloud Integration Audit (-fabric)

Covers AWS, Azure, GCP SDN connectors, external resources, EMS, ZTNA, and FortiSASE.

The AWS finding that appears most often in real configs: static access-key and secret-key stored directly in the FortiGate config. If someone emails that config backup or puts it in the wrong S3 bucket, those AWS credentials are compromised. The fix is IAM role with use-metadata-iam enable. The tool flags this HIGH and tells you exactly why.

Azure client-secret in config gets the same treatment. EMS checks include HTTPS certificate verification and fingerprint pinning — without both, FortiGate will accept any certificate from the EMS server.

ZTNA coverage check: what percentage of your accept policies actually enforce Zero Trust? 0% with ZTNA configured is flagged.

AI / LLM Application Security Audit (-ai)

This one is new territory for FortiGate auditing tools.

FortiOS 8.0 introduced LLM profiles specifically for AI traffic inspection. The audit checks every quality dimension of those profiles: DLP check (are employees sending source code to ChatGPT?), PII check (are names/SSNs/medical data going to AI APIs?), prompt injection detection, jailbreak detection, logging.

The finding that will matter most for enterprise customers in 2025: Chinese AI data sovereignty. DeepSeek, Ernie (Baidu), Qwen (Alibaba), Kimi (Moonshot) are flagged CRITICAL. Data sent to these services is subject to Chinese PIPL and national security law requirements that are incompatible with GDPR, HIPAA, and most enterprise data governance policies. This is a compliance issue, not just a security preference.

20 AI services in the risk table with per-service severity and risk description. Governance framework section in the report output with phased implementation approach.

Enhanced Local-in Hardening

Previous versions checked local-in policies in isolation. v4.0 adds a combined check that is significantly more impactful:

WAN interface with management access (HTTPS or SSH in allowaccess) AND no local-in-policy restricting source IPs = CRITICAL.

This is the check that should appear on every FortiGate hardening audit. The interface allowaccess setting says what protocols the device responds to. The local-in-policy says who can reach those protocols. Both must be configured together. Having HTTPS on wan1 with no local-in restriction means any IP on the internet can reach your FortiGate management GUI. That's not a misconfiguration — that's the default.

━━━━━━━━━━━━━━━━━━━━━━━━
What was CHANGED in v4.0
━━━━━━━━━━━━━━━━━━━━━━━━

Parser architecture refactor. main() was moved to the very end of the file. In Python, functions must be defined before they're called. With 58 parsers and 35 weakness functions, the ordering matters. The file now reads: parsers → weakness functions → report generators → main(). Adding a new module no longer risks a NameError.

Object reference engine. The unused objects module required building a full cross-reference map across all policy fields simultaneously — srcaddr, dstaddr, service, schedule, poolname, all UTM profile fields, plus what address groups and service groups reference internally. This is a non-trivial graph traversal built from scratch.

Anomaly sub-block parser. The DoS policy parser was rewritten to capture the nested anomaly config block properly. The old parser only captured top-level policy fields. The new parse_dos_policy_full() reads status/action/threshold/log per individual anomaly sensor.

SD-WAN nested parser. Standard extract_block() couldn't handle SD-WAN's three-level nesting (policy → members block → edit → set, policy → health-check block → edit → set). New dedicated parser handles all three sub-blocks correctly.

Enhanced local-in logic. The old check looked at each local-in-policy in isolation. The new check correlates interface allowaccess against the local-in-policy table to find gaps — the combination that creates real risk, not either field independently.

━━━━━━━━━━━━━━━━━━━━━━━━
What was REMOVED in v4.0
━━━━━━━━━━━━━━━━━━━━━━━━

Nothing removed. All flags from v1.0 through v3.0 still work identically. The tool is fully backward compatible — run it against a FortiOS 6.2 config and it handles the flat profile format, run it against an 8.0 config and it handles per-protocol sub-blocks. Version detection is automatic.

━━━━━━━━━━━━━━━━━━━━━━━━
Numbers
━━━━━━━━━━━━━━━━━━━━━━━━

v1.0 → v4.0 progression:

Lines of code: ~800 → 5,695
Audit domains: 5 → 35
Security checks: 40 → 300+
CLI flags: 5 → 30
Output reports: 5 → 22
New parsers (v4): 0 → 25
New weakness fns: 0 → 10

━━━━━━━━━━━━━━━━━━━━━━━━
What's next
━━━━━━━━━━━━━━━━━━━━━━━━

BGP security audit (route filtering, MD5 authentication, max-prefix, prefix-list coverage) is the biggest remaining gap. VDOM-aware parsing for multi-tenant environments. Multi-device runner that accepts a directory of config files and produces a consolidated JSON — the natural integration point for a Splunk dashboard.

Clone it, run it on a backup, open an issue if something's wrong or missing.

🔗 github.com/jafartavana01/fortigate-utm-analyzer

FortiGate #Fortinet #Python #OpenSource #NetworkSecurity #SecurityAudit #CCIE #Firewall #UTM #InfoSec #NetworkEngineering #ZeroTrust #SDWan #AIGovernance

Spanning tree

Jafar Tavana — Sat, 04 Jul 2026 08:19:19 +0000

🔍 One of the Most Overlooked STP Best Practices: PortFast Trunk

Jafar Tavana — Fri, 03 Jul 2026 09:46:48 +0000

Most network engineers remember to enable PortFast on access ports, but when it comes to ESXi hosts, Hyper-V servers, KVM environments, FortiGate firewalls, and other VLAN-aware appliances, an important detail is often missed: PortFast Trunk.
These devices frequently connect through trunk ports to carry multiple VLANs, yet they are not participating in Spanning Tree as switches.
In these scenarios, PortFast Trunk allows the port to move directly to the forwarding state after link-up, avoiding the normal STP listening and learning delays.
A few important points:
✅ PortFast is intended for Access ports.
✅ PortFast Trunk is intended for Trunk ports connected to hosts, hypervisors, and appliances.
✅ PortFast Trunk does not disable STP. The port still sends and receives BPDUs.
✅ Pairing it with BPDU Guard is often considered a best practice for additional protection.
One of the most common oversights in data centers is enabling PortFast on user-facing access ports while forgetting PortFast Trunk on server and virtualization uplinks. This can lead to unnecessary delays during reboots, link flaps, failovers, or maintenance events.
Are you using PortFast Trunk on your ESXi, Hyper-V, KVM, or FortiGate connections?

Cisco #Networking #CCNP #CCIE #DataCenter #VMware #ESXi #HyperV #FortiGate #NetworkEngineering #SpanningTree #STP #Infrastructure

🔍 VMware Beacon Probing: A Powerful Yet Often Misunderstood Feature

Jafar Tavana — Fri, 03 Jul 2026 06:15:42 +0000

Most virtualization engineers are familiar with failover based on link status, but VMware Beacon Probing takes a different approach to detecting network failures.
Instead of simply checking whether a NIC is physically connected, ESXi sends Layer 2 beacon frames between uplinks to identify failures where the link remains up, but traffic can no longer flow correctly.
Examples include:
⚠️ STP issues
⚠️ VLAN misconfigurations
⚠️ Upstream network failures
⚠️ Switch forwarding problems
In this infographic, I've broken down how Beacon Probing works, what a beacon frame contains, how ESXi detects failures, and why VMware recommends using this feature carefully in modern network designs.
Understanding the difference between "Link Status" and "Path Health" can help avoid troubleshooting headaches and unexpected failovers.
Do you use Beacon Probing in your ESXi environments, or do you prefer Link Status Only for failover detection?

VMware #ESXi #vSphere #Virtualization #DataCenter #Networking #VMwareNetworking #Infrastructure #vSwitch #NetworkEngineering #ITInfrastructure

DHCP Option 82 Explained – Why Your Clients Stop Getting IPs After Enabling DHCP Snooping

Jafar Tavana — Thu, 02 Jul 2026 07:03:49 +0000

DHCP Option 82 Explained – Why Your Clients Stop Getting IPs After Enabling DHCP Snooping
One of the most common hidden issues in Cisco networks!
When DHCP Snooping is enabled, switches automatically insert Option 82 (Relay Agent Information). If multiple switches do this — or if the DHCP server doesn’t support it — DHCP requests get dropped.
Best Practice in Multi-Tier Networks:

Enable Option 82 only on the nearest L3 switch to the DHCP server
Disable it on all Access/Downstream switches

no ip dhcp snooping information option
Save this infographic 👇 It will save you hours of troubleshooting!

Cisco #Networking #DHCPSnooping #CCNA #CCNP

Frame Flow in FortiGate UTM

Jafar Tavana — Thu, 02 Jul 2026 06:40:49 +0000

What happens to a frame as it enters FortiGate, gets processed, and exits the device.

Frame and Packet Flow in FortiGate UTM

Jafar Tavana — Thu, 02 Jul 2026 06:39:56 +0000

What happens to a frame as it enters FortiGate, gets processed, and exits the device.

FortiGate UTM Analyzer project Update

Jafar Tavana — Thu, 02 Jul 2026 04:49:16 +0000

I’m excited to share version 3 of my FortiGate UTM Analyzer project.

This tool is designed for analyzing and auditing FortiGate configurations, helping identify security gaps and improvement opportunities. The latest updates and newly added features are fully explained in the infographic.

Check out the project:
https://github.com/jafartavana01/fortigate-utm-analyzer

🔐 FortiGate UTM Security Analyzer v3.0 is live

Jafar Tavana — Wed, 01 Jul 2026 08:42:01 +0000

I just pushed a major update to one of my open-source tools — and this one comes from real pain felt on real audits.

If you've ever stared at a 10,000-line FortiGate config backup trying to manually check whether every accept policy has an IPS sensor, whether your IKEv1 tunnel is using aggressive mode, whether your SSL-VPN has brute-force protection, or whether someone left the SNMP community string set to 'public' with no host restriction — this tool does all of that automatically, in seconds, against any FortiGate backup file.

📌 Repo: https://github.com/jafartavana01/fortigate-utm-analyzer

━━━━━━━━━━━━━━━━━━━━━━
What is this project?
━━━━━━━━━━━━━━━━━━━━━━

FortiGate UTM Security Analyzer is a zero-dependency Python CLI tool that reads a plain-text FortiGate configuration backup — the output of 'show full-configuration' — and produces severity-tagged security reports across every layer of the firewall.

No pip installs. No API keys. No cloud. You point it at a .conf file and it generates structured .txt reports and a scored executive summary with JSON export.

python3 utm.py -c firewall.conf --all

That one command runs 200+ security checks across 25 audit domains and tells you exactly what's misconfigured, at what severity, and why it matters.

━━━━━━━━━━━━━━━━━━━━━━
What's new in v3.0
━━━━━━━━━━━━━━━━━━━━━━

The big change in v3.0 is full FortiOS 8.0 support. Fortinet made a breaking change in the SSL/SSH profile structure starting in 7.x — they moved from a flat config to per-protocol sub-blocks. So instead of one global 'inspection-method' field, you now have 'https.status', 'ftps.min-allowed-ssl-version', 'imaps.untrusted-server-cert', 'ssh.inspect-all' and so on. The old parser missed all of this silently. v3.0 auto-detects the config format and applies the right check set regardless of whether you're running 6.x, 7.x, or 8.0.

Same story for the AV profile — FortiOS 8.0 moved to per-protocol sub-blocks for antivirus settings, outbreak prevention, FortiSandbox submission, quarantine, and the Content Disarm & Reconstruction (CDR) engine settings. All of that is now parsed and audited correctly.

Beyond the parser fixes, v3.0 adds 13 completely new audit domains that weren't in any previous version:

→ WAF profile — checks for OWASP Top 10 signature coverage, HTTP method restrictions, URL access rules, and request size constraints. Most engineers attach a WAF profile and never check whether signatures are actually configured.

→ IKE Global — this is one that catches people off guard. You can lock down individual VPN tunnels perfectly, but if 'config system ike' still allows IKEv1 aggressive mode globally, any new tunnel someone creates inherits that weakness. One global setting, one check.

→ SNMP audit — full community string audit including default name detection (public/private/admin), host restriction checks, and SNMPv3 auth-proto/priv-proto/security-level. SNMPv3 with no-auth-no-priv is literally the same as SNMPv1 — flagged CRITICAL.

→ LLM Profile (FortiOS 8.0) — brand new in FortiOS 8.0. Checks whether policies handling AI/LLM API traffic have DLP enabled, PII detection, prompt injection blocking, and jailbreak detection. As AI traffic becomes standard in enterprise environments this is going to matter a lot.

→ System DNS — DNSSEC validation status, DNS-over-TLS for the FortiGate's own resolver, primary/secondary redundancy.

→ SSH hardening — scans 'config system ssh-config' for weak cipher algorithms (arcfour, 3DES, blowfish), weak MACs (MD5, SHA-1), and weak key exchange groups (DH group1, group14).

→ Password Policy block — the dedicated 'config system password-policy' block that most people don't know exists, separate from system global. Checks min-length, must-contain complexity, expiry, and reuse prevention.

→ Security Fabric — CSF group password (missing = any device can join), certificate-based authorization, device detection.

→ DoS Policy — checks whether flood protection rules are even configured. No DoS policies at all = flagged MEDIUM automatically.

→ IPv6 — 'firewall policy6' and 'firewall local-in-policy6' are now both audited with the same checks as their IPv4 equivalents. IPv6 local-in policies are where most people have the widest open management plane.

→ FortiGuard fail-open modes — if your FortiGuard cloud service goes unreachable and your AV/IPS/webfilter fail-open is set to 'pass', traffic flows without inspection. Flagged MEDIUM.

→ Logging expanded — now checks FA1/FA2/FA3, syslogd1 through syslogd4, per-category event filter (admin config changes, system events, VPN tunnel events, endpoint events), disk logging behavior, and disk-full action.

→ Email Filter, Video Filter, File Filter, Virtual Patch — all new, each with dedicated weakness checks.

━━━━━━━━━━━━━━━━━━━━━━
The scoring model
━━━━━━━━━━━━━━━━━━━━━━

Every finding is tagged CRITICAL / HIGH / MEDIUM / INFO. The executive summary computes a risk score:

Score = (CRITICAL × 10) + (HIGH × 5) + (MEDIUM × 2) + (INFO × 0.5)

And maps to a risk tier: CRITICAL / HIGH / MEDIUM / LOW.

Running it against the sample config (intentionally misconfigured to demonstrate everything):

Risk Rating : CRITICAL
Risk Score : 545.0
CRITICAL: 5 HIGH: 58 MEDIUM: 82 INFO: 82

The --summary flag also writes a _SUMMARY.json file — machine-readable, so you can pipe it into Splunk, a Python script, or a CI/CD pipeline if you want to automate this across a fleet of devices.

━━━━━━━━━━━━━━━━━━━━━━
How to run it
━━━━━━━━━━━━━━━━━━━━━━

git clone https://github.com/jafartavana01/fortigate-utm-analyzer.git
cd fortigate-utm-analyzer
python3 utm.py -c your_fortigate_backup.conf --all

The tool works on any FortiGate config from 6.x through 8.0. No version detection needed — the parsers handle format differences automatically.

Common targeted workflows:

VPN hardening review

python3 utm.py -c fw.conf -vpn -sslvpn -s --summary

Management plane security

python3 utm.py -c fw.conf -s -log -ha --summary

Data plane / UTM coverage

python3 utm.py -c fw.conf -f -i -av -utm --summary

━━━━━━━━━━━━━━━━━━━━━━
Why I built this
━━━━━━━━━━━━━━━━━━━━━━

Manual FortiGate config reviews are slow, inconsistent, and easy to get wrong under time pressure. The same misconfigurations show up on audit after audit — UTM disabled on accept policies, IKEv1 aggressive mode still running, SSL-VPN with no login lockout, admin accounts with no trusted host restrictions and no 2FA, SNMP community strings nobody changed from the default.

This tool doesn't replace a proper security assessment. But it eliminates the mechanical part — you get a prioritized finding list in seconds, and can spend your time on the things that actually need human judgment.

Star the repo if it's useful, and feel free to open issues or PRs if you want to add checks for your own environment.

🔗 https://github.com/jafartavana01/fortigate-utm-analyzer

NetworkSecurity #FortiGate #Fortinet #Python #OpenSource #SecurityAudit #CCIE #Firewall #UTM #InfoSec #NetworkEngineering

FortiGate Security analyzer

Jafar Tavana — Mon, 29 Jun 2026 09:01:31 +0000

🔐 I just open-sourced a tool I built from real-world pain points on the job.

As a network security engineer working daily with FortiGate firewalls, I kept running into the same problem: configs that looked fine on the surface but had serious misconfigurations buried inside — accept policies with UTM completely disabled, admin accounts with no trusted host restrictions, SSL inspection running in certificate-only mode with no actual decryption, WAN interfaces with HTTP and Telnet still open.

Manually reviewing these across dozens of policies is slow, inconsistent, and easy to get wrong under pressure.

So I built FortiGate UTM Analyzer — a zero-dependency Python CLI that reads a show full-configuration backup and generates structured, severity-tagged security reports in seconds.

🛡️ What it audits:
→ Firewall policies — UTM status, IPS/AV/WebFilter/DNS/AppControl/SSL profile coverage, logging gaps
→ SSL/SSH inspection profiles — inspection mode, cert validation posture, SNI, anomaly logging
→ Antivirus profiles — protocol coverage (HTTP/HTTPS/SMTP/FTP/CIFS), sandbox, outbreak prevention
→ System hardening — admin 2FA, trusthosts, super_admin usage, interface exposure, strong-crypto, DH params, admin lockout
→ NTP — sync status, authentication, redundancy
→ Local-in policies — management exposure, broad source addresses
→ ASCII UTM flow diagrams — per-policy visual of the full security stack from source to destination interface

40+ security checks. HIGH / MEDIUM / INFO severity. Pure Python stdlib — nothing to install.

You point it at a config file and it generates up to 5 structured .txt reports you can read, grep, or feed into a SIEM.

🔗 GitHub: https://github.com/jafartavana01/fortigate-utm-analyzer

If you work with FortiGate in your environment, try it on a backup and see what it finds. Feedback and contributions are welcome.

NetworkSecurity #FortiGate #Fortinet #Python #OpenSource #Firewall #InfoSec #NetworkEngineering #SecurityAudit #UTM #CCIE

Fortigate WAf Secure implementation

Jafar Tavana — Sat, 20 Jun 2026 12:27:53 +0000

Fortigate Inspection UTM

Jafar Tavana — Fri, 19 Jun 2026 13:54:43 +0000