Monitor UniFi WLAN Access Point with PRTG with SNMPv3 Auth+Encrypted

This is a tiny guide howto monitor your UniFi wireless accesspoint, in this case a Unifi U7 pro with SNMPv3 with AES-Encryption and SHA-Authentication using PRTG:

1. Configure SNMP Monitoring in UniFis settings --> CyberSecure --> Traffic Logging --> SNMP Monitoring --> SNMPv3 --> set a unique username and unique long password
   
2. UniFi will use SNMPv3 with Encryption Type AES-128 and Authentication Method SHA1. The selected password will be used for Authentication and Encryption.
3. Create a device in PRTG and edit the device settings to:
   
   
   
   
   
   
4. Add PRTG sensors like e.g. the SNMP traffic sensor to monitor the UniFi access points physical (e.g. eth0) and virtual ports VLAN ports (e.g. eth0.100 for VLAN ID 100):
   
    
   

 

Do not forget to set ACLs and network segmentation, so the SNMP and other management interfaces are only reachable from dedicated source ip-addresses. Also keep in mind, that in SNMPv3 AuthPriv the username is sent in plaintext over the network eventhough you chose with AuthPriv authentication and encryption, as shown in the following screenshot or mentioned in my article from 2018.

 

 

 

Powershell Website "Ping" using the winsystems web proxy

If you want to monitor/check (every 10s) continuesly if a website (in this exampe http://www.google.de) is reachable using powershell and also using the configured webproxy in your windows system, then you can use the following example:

while ($true) {
    $webClient = New-Object System.Net.WebClient
    $proxy = [System.Net.WebRequest]::GetSystemWebProxy()
    $proxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials
    $webClient.Proxy = $proxy

    $proxyUri = $proxy.GetProxy([System.Uri]::new("http://www.google.de"))
    $proxyIp = $proxyUri.Host
    $proxyPort = $proxyUri.Port

    $startTime = Get-Date
    try {
        $response = $webClient.DownloadString("http://www.google.de")
        $endTime = Get-Date
        $latency = ($endTime - $startTime).TotalMilliseconds
        $statusCode = 200 # WebClient doesn't expose status code directly, assuming success here
        Write-Output "[$startTime] Latency: ${latency}ms, HTTP Status Code: $statusCode, Proxy:         $proxyIp :$proxyPort"
    } catch {
        $endTime = Get-Date
        $latency = ($endTime - $startTime).TotalMilliseconds
        $errorMessage = $_.Exception.Message
        Write-Output "[$startTime] Latency: ${latency}ms, Error: $errorMessage, Proxy: $proxyIp :$proxyPort"
    }

Start-Sleep -Seconds 10
}



Small/Medium Businesses - New network devices (switches, routers,..) - Minimum ToDo list

Most small/medium businesses don't do much configuration, monitoring, cfg-baselineing or follow best practises with their network devices like switches, routers, wireless controllers, access points etc. Here is a short list of things you should do at minimum:

1. Extend your monitoring of your network devices

Not only ping them, check their uptime by snmp, but:
1.1 Monitor all uplinks (e.g. SNMP bandwidth)
1.2 Monitor all important ports (ports of the servers, firewalls, storage, etc; again e.g. with SNMP bandwidth)
1.3 Monitor device health, fan status, temperature, etc
1.4 Monitor the routing table, especially if you use dynamic routing protocols and/or have many routes
1.5 Monitor utilization of cpu, mem, i/o, etc..
1.6 Monitor everything with secure protocols like SSH, SNMPv3 AuthPriv AES+SHA
1.7 Send SNMP traps from devices to your monitoring system
1.8 Send Syslog from your devices to your monitoring system & logging solution

2. Harden your network

2.1 Disable telnet
2.2 Disable http
2.3 Implement ACLs for allowing access only from dedicated trusted hosts
2.4 Implement ACLs for dynamics routing protocols like BGP, OSPF, etc
2.5 Use LDAPS/Radius authentication for LDAP/AD-authentication for device mgmt
2.6 Send Syslog from your devices to your monitoring system & logging solution
2.7 Disable SNMPv1/v2c
2.8 Use DHCP-Snooping for Rouge DHCP server protection
2.9 Use ARP Spoofing Protection
2.10 Think about disabling link-layer discovery protocols like LLDP, CDP, EDP, etc
2.11 Allow local admin account login only if LDAPS/Radius server is not reachable
2.12 Delete default users, groups and communities

3. Authentication & dynamische vlan assignment

3.1 Use IEEE 802.1x with certificates (at least two AAA Radius Serves (e.g. FreeRadius) with EAP-TLS)
3.2 Use rfc3580 for dynamic vlan assignment
3.3 Think about using either a quarantine fallback vlan for not authenticated clients or a guest vlan with internet access only
3.4 Think of using DHCP Snooping (forwarding) for your devices which does device fingerprinting

4. Documentation

4.1 Create a layer1 and layer2 network plan (e.g. in visio)
4.2 Create a layer2 and layer3 network plan (e.g. in visio)
4.3 Use the l2&l3 plan as background for your monitoring system in a map to have a live-overview

5. Testing

5.1 Test your loop protection (m/r/stp, loop-protect, elrp, + broadcast limit thresholds like max 200 broadcasts per second, etc) in a maintenance window
5.2 Test your "CrossVlan Protection" in a maintenace window. By "CrossVlan" I mean not wanted connections between to vlans, which should be separated (m/r/stp, loop-protect, extra VLAN which is tagged on all ports and sends ELRP or similar loop protection protocols, etc)
5.3 Test your monitoring alerting - is an alert really send when e.g. an important uplink is full or disconnected, if an important lacp lag is down, etc (test using simulation, e.g. via jPerf, Observer etc)
5.4 Check and test if all best practises of the vendor are applied

6. IP-Subnetting

Yes, so many small and medium companys still have a huge flat layer2 network per site :(
6.1 The more subnets, the more a network issue stays only in that tiny subnet
6.2 The smaller the subnet, the less background noise
6.3 Microsegmentation is key! The smaller the subnet and the more it is separated (using private vlans, ACLs, a firewall, filtering device, host firewalls, a microsegmentation solution, NSX-T or something similar), the more it is protected and lateral movement gets harder.

There are many more things, like using LACP instead of static link aggregation groups, using LACP Mode Fast instead of the default slow, using Bidirectional Forwarding Detection "BFD" for everything, using multi-chassis link-aggregation (like MC-LAG, MLAG, etc) instead of Stacking (firmware-updates & reboots mostly cost the whole stack-topology to reboot, which is not the case in MLAG), using Out of Band management, and much more.

The listed items are the things which should be done at minimum.

How to Securely Monitor a FortiGate Firewall with PRTG Network Monitor

Introduction

The FortiGate firewall offers a lot of different management interfaces. This article is about the secure and recommended interfaces from 10 years of experience with hundreds of FortiGates and PRTG-installations all over the world. There are many more ways to monitor the FortiGate with PRTG but this article focuses only on the ones which really work and are secure.

Overview of recommended secure monitoring interfaces

The FortiGate firewalls offers the following management-interfaces which are secure:

Protocol	Secure	Comment	Direction (Default FGT-Port)
SNMPv3 AuthPriv AES+SHA	Encrypted	SNMPv3 AuthPriv is recommended for authenticated and encrypted monitoring of the FGT	PRTG pulls from FGT (UDP:161)
SNMP Trap	Not encrypted	Enables the FortiGate to send information to PRTG	FGT sends to PRTG (UDP:162)
SSH	Encrypted		PRTG pulls from FGT (TCP:22)
HTTPS	Encrypted		PRTG pulls from FGT (TCP:443)
NetFlow	Not encrypted	Only recommended with setups where FortiGate has Network Processes ASIC NP6, NP7 or above. On FGTs without NPs NetFlow is done in CPU, which might cause high CPU utilization	FGT sends to PRTG (UDP?)
Syslog	Not encrypted		FGT sends to PRTG (UDP:514, Syslog Reliable TCP:514)

Overview of all FortiGate Interfaces:

 

A full list of all FortiGate interfaces with a description of them can be found here: 

https://docs.fortinet.com/d/fortigate-communication-ports-and-protocols-60

 

Harden interfaces

Important:
1. All access to the firewall should be limited to internal interfaces only
2. All access to the firewall should be strictly limited to trusted host IPs/IP-networks only using TrustedHosts AND Local-In-Policies, see: https://how2itsec.blogspot.com/2022/10/fortigate-admin-interface.html

3. All not used management access protocols/interfaces should be deactivated
4. Only secure protocols should be used (e.g. SSH instead of Telnet, SNMPv3 AuthPriv instead of SNMPv1/v2c,..). Secure encrypted protocols will cause a higher load on PRTG and the firewall, however due to the sensible nature of a firewall, which is often heart of the network backbone, it is highly recommended.
5. Consider using two-factor-authentication for administrative login, this is highly recommended for strong authentication. Every FortiGate unit includes two trial tokens for free
6. Rename the default admin administrator account, create backup-administrator accounts, use for both complex passwords (length 20+) and keep them in a safe. For regular administrative work use LDAPS authentication with personalized dedicated administrator accounts.

Hardening Guide for FortiOS 6.0: https://docs.fortinet.com/d/fortigate-hardening-60

Hardening Guide for FortiOS 5.6: https://docs.fortinet.com/uploaded/files/3624/fortigate-hardening-your-fortigate-56.pdf
Hardening Guide for FortiOS 5.4: https://docs.fortinet.com/d/fortigate-hardening-your-fortigate-1 
Hardening Guide for FortiOS 5.2: https://docs.fortinet.com/d/fortigate-hardening-your-fortigate
Fortinet Product Security Incident Response Team: https://www.fortiguard.com/psirt

 

Configuring Trusted Hosts

Setting trusted hosts for administrators limits what computers an administrator can login the FortiGate unit from. When you identify a trusted host, the FortiGate unit will only accept the administrator’s login from the configured IP address or subnet. Any attempt to login with the same credentials from any other IP address or any other subnet will be dropped. To ensure the administrator has access from different locations, you can enter up to ten IP addresses or subnets. Ideally, this should be kept to a minimum. For higher security, use an IP address with a net mask of 255.255.255.255, and enter an IP address (non-zero) in each of the three default trusted host fields. Trusted hosts are configured when adding a new administrator by going to System > Administrators in the web-based manager and selecting “Restrict login to trusted hosts”:

Or config system admin in the CLI:

config system admin
    edit "admin-username"
        set trusthost1 “Any IPv4 address or subnet address”
        ip6-trusthost1 “Any IPv6 address”

The trusted hosts apply to the web-based manager, ping (keep in mind that your FGT only responds to trusted hosts), snmp and the CLI when accessed through SSH. CLI access through the console port is not affected. Also ensure all entries contain actual IP addresses, not the default 0.0.0.0.

SNMPv3 AuthPriv monitoring

Depending on the FortiGate size/ressources, the amount of sensors and and interval of how often you query the FortiGate depends. You should closely monitor the CPU and memory utilization of your device in order to not cause too much of utilization to your device. Some sensors are more important than others, therefore they should be queried more often than others. For example it might not be a good idea to ask for the uptime every 30seconds, but it might be a good idea to check for the interface utilization of your most crucial (vlan-)interfaces like WAN/LAN/DMZ or VPN.

SNMPv3 AuthPriv is recommended for its authentication and encryption. Howevery SNMPv3 AuthPriv will cause a higher load on PRTG and your FortiGate firewall compared to SNMPv1/v2c, which are not encrypted. Due to a firewalls sensivity­, it is recommended to only use SNMPv3 AuthPriv.

Do NOT use the same SNMPv3 username, password and key. Instead use 3 different values with more then 20 numbers length, for example TbYrHh7zWiqF88cBcn63. This very important due to the username is sent in plaintext over the network eventhough you chose with AuthPriv authentication and encryption. The following screenshot shows the example of SNMPv3 AuthPriv from wireshark-examples https://wiki.wireshark.org/SampleCaptures#SNMP were you can see although encryption is chosen, the username is sent in plaintext. The whole security would be compromised if you chose the same username, password and/or key for SNMPv3 AuthPriv.

Fortinet SNMP OID-Tree:

1 ISO
1.3 identified-organization
1.3.6 dod
1.3.6.1 internet
1.3.6.1.4 private
1.3.6.1.4.1 IANA enterprise numbers
1.3.6.1.4.1.12356 fortinet

OID	Name	Description
1.3.6.1.4.1.12356.0	fnTraps	None
1.3.6.1.4.1.12356.1	fnSystem	None
1.3.6.1.4.1.12356.2	fnFirewall, fnDomains	None
[…]
1.3.6.1.4.1.12356.10	fortinetTrap	None
[…]
1.3.6.1.4.1.12356.100	fnCoreMib	None
1.3.6.1.4.1.12356.101	fnFortiGateMib	MIB module for Fortinet FortiGate devices
[…]

PRTG SNMPv3 Configuration:

Add the FortiGate using a IPv4/IPv6/FQDN to PRTG and edit the device settings as shown in the following screenshot:

FortiGate SNMPv3 Configuration

In the FortiGate with activated VDOMs, select Global and go to System\SNMP. In a FortiGate with deactivated VDOMs, go to System\SNMP. Activate SNMP and create a SNMPv3 user as follows:

 

Using the Create New Button (or Edit button) you can enter a new SNMPv3 user:

SNMP OIDs

SNMP OID	Description	Importance	Recommended interval	Recommended Threshold	Recommended Notification
1.3.6.1.4.1.12356.101.4.1.7.0	Total hard disk capacity (MB).	Low, normally hard disks of FGTs have log rotation activated	10 Minutes	-	-
1.3.6.1.4.1.12356.101.4.1.8.0	Number of active sessions on the device.	Medium	60 Seconds	Warning – Half of the maximum of the supported sessions of your device Alert – 85% of the maximum of the supported sessions of your device	When reaching alert for the second time
1.3.6.1.4.1.12356.101.4.1.4.0	Current memory utilization (percentage).	High, FGT might be close to converse mode (overload protection)	60 Seconds	Warning – Utilization over 70% Alert – Utilization over 80%	When for over 2 hours at Warning, Once while Alert
1.3.6.1.4.1.12356.101.4.1.3.0	Current CPU usage (percentage).	High, your device might be too small for the traffic load and/or your UTM-settings to high or you have some kind of incident	60 Seconds	Warning – Utilization over 90% over 5 minutes Alert – Utilization at 100% over 10 minutes	When reaching alert for a second time
1.3.6.1.4.1.12356.101.13.2.1.1.5	Network bandwidth usage of the cluster member (kbps)	Medium	120 seconds	Warning – Half of the maximum of the supported bandwidth of your device Alert – 85% of the maximum of the supported bandwidth of your device	When reaching alert for the second time
1.3.6.1.4.1.12356.101.3.1.2.0	The maximum number of virtual domains allowed on the device as allowed by hardware and/or licensing.	Low	4 hours	-	-
1.3.6.1.4.1.12356.101.3.1.1.0	The number of virtual domains in vdTable	Low	4 hours	Warning – when number is 90% of maximum number of VDOMs Alert – when number is equal to maximum number of VDOMs	When reaching alert
1.3.6.1.4.1.12356.101.8.2.1.1.1	Number of virus transmissions detected in the virtual domain since start-up	Low	4 hours	-	-
1.3.6.1.4.1.12356.101.9.2.1.1.1	Number of intrusions detected since start-up in the VDOM.	Low	4 hours	-	-
1.3.6.1.4.1.12356.101.4.1.11.0	The average session setup rate over the past minute	Medium	60 Seconds	Warning – Half of the maximum of the supported new sessions per second of your device Alert – 85% of the maximum of the supported new sessions per second of your device	When reaching alert for the second time
1.3.6.1.4.1.12356.101.4.1.12.0	The average session setup rate over the past 10 minutes	Low	10 minutes	-	-
1.3.6.1.4.1.12356.101.4.1.13.0	The average session setup rate over the past 30 minutes	Low	10 minutes	-	-
1.3.6.1.4.1.12356.101.4.1.16.0	The average ipv6 session setup rate over the past minute	Medium	60 Seconds	Warning – Half of the maximum of the supported new sessions per second of your device Alert – 85% of the maximum of the supported new sessions per second of your device	When reaching alert for the second time
1.3.6.1.4.1.12356.101.4.1.17.0	The average ipv6 session setup rate over the past 10 minutes	Low	10 minutes	-	-
1.3.6.1.4.1.12356.101.4.1.18.0	The average ipv6 session setup rate over the past 30 minutes	Low	10 minutes	-	-
1.3.6.1.4.1.12356.101.13.2.1.1.2.1	The serial number of the cluster unit	High	60 Seconds	Alert when value changes, the active node of your A-P HA-cluster has changed	When value changes
1.3.6.1.4.1.12356.101.13.2.1.1.12.1	Current HA Sync status	High	60 Seconds	0 = not synchronized 1 = synchronized Alert - when return value is 0	When reaching alert for the third time

SNMP Traps

Standard traps RFC 1215

OID 1.3.6.1.4.1.12356.1.3.0

1.3.6.1.4.1.12356.1.3.0.1
ColdStart              

1.3.6.1.4.1.12356.1.3.0.2
WarmStart         

1.3.6.1.4.1.12356.1.3.0.3
LinkUp

1.3.6.1.4.1.12356.1.3.0.4
LinkDown

CommonFortiGate traps

OID 1.3.6.1.4.1.12356.101.2

1.3.6.1.4.1.12356.101.2.101      
CPU usage high – fnTrapCpuThreshold, see CLI:
config system snmp sysinfo
      set trap-high-cpu-threshold

1.3.6.1.4.1.12356.101.2.102
Memory low – fnTrapMemThreshold, see CLI:
config system snmp sysinfo
      set trap-low-memory- threshold

1.3.6.1.4.1.12356.101.2.103
Log disk too full – fnTrapLogDiskThreshold
Only when FGT has log disk, check Fortinet Product Matrix, see CLI:
config system snmp sysinfo
      set trap- log-full-threshold

1.3.6.1.4.1.12356.101.2.104
Temperature too high - fnTrapTempHigh

1.3.6.1.4.1.12356.101.2.105
Voltage outside acceptable range - fnTrapVoltageOutOfRange

1.3.6.1.4.1.12356.101.2.106
Power supply failure – fnTrapPowerSupplyFailure
Only when FGT has redundant power supplies, check Fortinet Hardware Manual

1.3.6.1.4.1.12356.100.1.3.0.108
A fan failure has been detected - fnTrapFanFailure

1.3.6.1.4.1.12356.101.2.201
Interface IP change – fnTrapIpChange
Useful for Interface with dynamic IP-addresses (e.g. DHCP or PPPoE)

HighAvailability FortiGate traps

OID 1.3.6.1.4.1.12356.101.13.3 

1.3.6.1.4.1.12356.101.13.3.401
HA switch – fgTrapHaSwitch

1.3.6.1.4.1.12356.101.13.3.402
HA State Change – fgTrapHaStateChange

1.3.6.1.4.1.12356.101.13.3.403
HA Heartbeat Failure – fgTrapHaHBFail, check Fortinet HA Guide, see CLI:
config system ha
      set hb-interval
      set hb-lost-threshold
      set hello-holddown

1.3.6.1.4.1.12356.101.13.3.404
HA Member Unavailable – fgTrapHaMemberDown

1.3.6.1.4.1.12356.101.13.3.405
HA Member Available – fgTrapHaMemberUp

VPN FortiGate traps

OID 1.3.6.1.4.1.12356.1.3.0

 1.3.6.1.4.1.12356.1.3.301
VPN tunnel is up – fgTrapVpnTunUp

1.3.6.1.4.1.12356.1.3.302
VPN tunnel down - fgTrapVpnTunDown

AntiVirus & Intrusion Prevention System FortiGate Traps

OID 1.3.6.1.4.1.12356.101.2
OID 1.3.6.1.4.1.12356.101.9

1.3.6.1.4.1.12356.101.2.0.503
An IPS signature has been triggered - fgTrapIpsSignature

1.3.6.1.4.1.12356.101.9.506
The IPS network buffer is full - fgTrapIpsFailOpen  

           

1.3.6.1.4.1.12356.101.2.0.601
A virus has been detected by the anti-virus engine - fgTrapAvVirus

1.3.6.1.4.1.12356.101.9.605
The anti-virus engine has entered conservation mode due to low memory conditions - fgTrapAvEnterConserve

1.3.6.1.4.1.12356.101.9.606
The anti-virus engine has been bypassed due to conservation mode – fgTrapAvBypas

SSH

SSHv1 is disabled by default. To enforce large values for Diffie-Hellman exchanges in SSHv2 and to use strong ciphers use the following command:

config sys global
      set strong-crypto enable
      set dh-params 4096
end

You can also change the default TCP-SSH-port of the FGT to a random one, for example TCP:23345. This does not add additional security but default port-scanners have to execute a full scan, normal quick scans might not find your used port:
config system global
      set admin-ssh-port 23345
end

For authentication SSH with certificates can be used:
config system admin
    edit "name-of-admin-account”
        set accprofile "super_admin"
        set vdom "root"
        set ssh-certificate "your-imported-certificate"
    next
end

HTTPS

Use the following command to require TLS 1.2 for HTTPS administrator access to the GUI:

config system global
      set admin-https-ssl-versions tlsv1-2
end

TLS 1.2 is currently the most secure SSL/TLS supported version for SSL- encrypted administrator access to your FortiGate. Restrict access to dedicated trusted hosts (see above) and deactivate HTTPS web access on all interfaces except your management-network. Also only use HTTPS, not HTTP.

For HTTPS use official or certificates from your certificate authority (Certificates with RSA 4096 or 2048Bit and SHA2-256 or SHA2-384 signature). Instead of browsing to the FGT ip address, use the FQDN so make sure no certificate warning is shown.

You can also change the default TCP-port of the FGT webinterface to a random one, for example TCP:33026. This does not add additional security but default port-scanners have to execute a full scan, normal quick scans might not find your used port:
config system global
      set admin-sport 33026
end

Enable strong ciphers using “strong-crypto enable”, disable statics keys for TLS sessions and enforce large values for Diffie-Hellman exchanges using the following commands:

config sys global
      set strong-crypto enable
      set ssl-static-key-ciphers disable
      set dh-params 4096
end

NetFlow

Only recommended with setups where FortiGate has Network Processes ASIC NP6, NP7 or above. On FGTs without NPs NetFlow is done in CPU, which might cause high CPU utilization:
“NP6 and NP6Lite offloading is supported when you configure NetFlow for interfaces connected to NP6 or NP6Lite processors. Offloading of other sessions is not affected by configuring NetFlow. Configuring sFlow on any interface disables all NP6 and NP6Lite offloading for all traffic on that interface.”
https://docs.fortinet.com/d/fortigate-hardware-acceleration-2