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.

 

 

 

Almost perfect protection for websites and other services - Mutual TLS

Its hard to secure your IT services and applications. The list of possible attacks is long, as shown in the Mitre Att&ck framework, the OWASP lists and so on.

What helps drastically reducing the attack surface is to use mutual TLS (explanations see https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/ or https://en.wikipedia.org/wiki/Mutual_authentication#mTLS or https://www.youtube.com/watch?v=x7B5CwcxCDI or https://www.ietf.org/rfc/rfc5246.txt) for authentication to establish access to your service/application. If you use certificates to authenticate your clients before accessing the first byte to of your service/application, you stop attacks at OSI layer 5. The attackers cant reach OSI layer 6 and 7 which  contain the most vulnerabilites and weaknesses by far.

I've asked ChatGPT to make a list to compare regular web applications with web applications, which use mutual TLS:

Attack Type	Regular Web Application	Secured Web Application (Mutual TLS)	Mitre ATT&CK Tactic(s)
Cross-Site Scripting (XSS)	Vulnerable	Protected	Initial Access, Execution, Persistence
SQL Injection	Vulnerable	Protected	Collection, Credential Access, Execution
Cross-Site Request Forgery (CSRF)	Vulnerable	Protected	Initial Access, Collection
Session Hijacking	Vulnerable	Protected	Collection, Credential Access
Brute Force Attacks	Vulnerable	Protected	Credential Access, Execution
Clickjacking	Vulnerable	Protected	Collection, Defense Evasion
Directory Traversal	Vulnerable	Protected	Collection, Exfiltration
File Upload Vulnerabilities	Vulnerable	Protected	Execution, Collection
LDAP Injection	Vulnerable	Protected	Collection, Credential Access
Man-in-the-Middle (MitM) Attacks	Vulnerable	Protected	Collection, Credential Access, Execution
Remote File Inclusion	Vulnerable	Protected	Execution, Collection
XML External Entity (XXE) Injection	Vulnerable	Protected	Collection, Credential Access
Security Misconfigurations	Vulnerable	Way less vulnerable	Defense Evasion, Discovery
HTTP Header Injection	Vulnerable	Protected	Defense Evasion, Execution
DDoS Attacks	Vulnerable	Way less vulnerable	Impact
API Security Issues	Vulnerable	Protected	Collection, Credential Access, Execution
HTTP Parameter Pollution	Vulnerable	Protected	Defense Evasion, Execution
Session Sidejacking	Vulnerable	Protected	Credential Access, Collection
Social Engineering Attacks	Vulnerable	Protected	Collection, Defense Evasion
Cross-Site Tracing (XST)	Vulnerable	Protected	Credential Access, Collection
Fuzzing Attacks	Vulnerable	Protected	Execution, Defense Evasion
Cryptanalysis	Vulnerable	Way less vulnerable	Collection, Credential Access
Reverse Engineering	Vulnerable	Protected	Collection, Credential Access
Subdomain Takeover	Vulnerable	Protected	Initial Access, Collection
Session Token Theft	Vulnerable	Protected	Credential Access, Collection
Vulnerabilies/0days	Vulnerable	Way less vulnerable	Initial Access
Broken Object Level Authorization (BOLA)	Vulnerable	Protected	Credential Access, Authorization
Improper Rate Limiting	Vulnerable	Way less vulnerable	Defense Evasion, Impact
Insecure Direct Object References (IDOR)	Vulnerable	Protected	Collection, Credential Access
Insufficient Logging and Monitoring	Vulnerable	Way less vulnerable	Discovery, Defense Evasion
Insecure Deserialization	Vulnerable	Protected	Execution, Defense Evasion
Lack of Resources and Rate Limiting	Vulnerable	Protected	Defense Evasion, Impact
Mass Assignment	Vulnerable	Protected	Credential Access, Collection
Insecure Cryptographic Storage	Vulnerable	Vulnerable	Collection, Credential Access
Use of Components with Known Vulnerabilities	Vulnerable	Way less vulnerable	Collection, Execution
Unvalidated Redirects and Forwards	Vulnerable	Protected	Defense Evasion, Initial Access
XML External Entity (XXE) Injection	Vulnerable	Protected	Collection, Credential Access

Caution: This is a simplified point of view - it is only focusing on the inital access. Mutual TLS certificate based authentication make the initial access for attackers almost impossible. Therefore most attacks are not possible anymore without the attackers gets his hands on a client certificate with its private key. However your IT stack is still vulnerable to OSI layer 1-5 attacks as well as e.g. to vulnerabilities within OpenSSL, LibreSSL etc.

FortiGate admin interface authentication bypass

There are rumors about a vulnerability in Fortinets FortiGate firewalls where you may bypass authentication on their admin interfaces. Affected seem to be FortiOS 7.0.x and FortiOS 7.2.0/1. A fix is included in FortiOS 7.0.7 and FortiOS 7.2.2. It is written the vulnerability has CVE-2022-40684.

It is imperative that you protect your FortiGate interfaces with TrustedHosts AND Local-In-Policies. Only using TrustHosts protects HTTPS, SSH, etc but not other protocols like SIP, IPsec, CAPWAP, BGP, SSLVPN* etc which are also local services running on the FortiGate, which need to be protected, too.

*SSLVPN = Even though SSLVPN might be not configured and therefore seems to be inactive, in some cases for example vulnerability-scanners still trigger the SSLVPN service to log errors in FortiGates log. This only is solved by setting up local-in-polices.

Example for trusthost & local-in-policy:

CLI configuration:

System > Administrators >
config system admin
    edit "admin"
        set trusthost1 172.26.73.48 255.255.255.255
        set accprofile "super_admin"
        set vdom "root"
    next
end

Configuring address and address group as per the trusted hosts:

config firewall address
    edit "trusted-1"
        set type ipmask
        set comment ''
        set visibility enable
        set associated-interface ''
        set color 0
        set allow-routing disable
        set subnet 172.26.73.48 255.255.255.255
    next
end

config firewall addrgrp
    edit "trusted_grp"
        set member "trusted-1"
        set comment ''
        set visibility enable
        set color 0
    next
end

Configuring Firewall local in policies:

config firewall local-in-policy
    edit 2
        set intf "port1"
        set srcaddr "trusted_grp"
        set dstaddr "all"
        set action accept
        set service "PING"
        set schedule "always"
        set status enable
        set comments ''
    next
    edit 1
        set intf "port1"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "PING"
        set schedule "always"
        set status enable
        set comments ''
    next
end

Remember: This example shows the local-in-policy only for "ping". You want to protect all services (except for example SSLVPN or IPsec if you use them).

Citrix ICA SSO saved credentials in XOR obfuscated readable storage

The Citrix ICA application stores user credentials for its SingleSignOn SSO functionality in readable form using XOR obfuscation with the key „C“, as Benjam Delpy wrote: https://twitter.com/gentilkiwi/status/1570525137962930176

Mimikatz version 3 will be able to reveal this as shown in the following GIF with Windows 11 and Credential Guard enabled: https://video.twimg.com/tweet_video/Fcudz49XoAAfNHO.mp4

Video in higher quality

Quick win securing Azure AD

An easy quick win for securing Azure Active Directory passwords is the feature "Azure AD Password Protection". This helps you in mitre att&cks tactic credential access, for example in the technique brute force and its sub-techniques password guessing, password spraying, credential stuffing, etc.

Users are recommended to avoide simple passwords and instead should use pass-sentences. Password breaches of the recent past reveal that the majority still chose simple passwords. Azure AD Password Protection finds (audit mode) or enforces (enforce mode) stronger passwords for everybody. There is a hidden global banned password list which is applied to every user in the Azure AD tenant. Additionally you can block custom words like your companys name, your companys slogan, the founders or CEOs name, most used childerens names or your country or famous sport team names, which are often used as weak passwords.

Microsoft promises the "password validation algorithm" automatically detects/blocks variants and combinations like "password!1", "!password", "p@ssw0rd" and so on.

This is also available for on-premise Active Directory using an agent:

 

However this needs an additional license, you need to install and agent on your domain controllers, you need to reboot the domain controllers and you need Azure AD. Also you do not see the changing content of Microsofts global password list and there is no enforcement based on Active Directory groups or OUs, so you for example cant just enforce it to priviledged accounts but must enforce it for everybody.

Of course I highly recommend to use Multi Factor Authentication MFA everywhere.

Myths of IT Security

I recently saw Linus Neumann from the Chaos Computer Club in a video talking about IT security myths which I try to explain all time, however Linus listed them so elegantly in his video, I want to repeat them as text:

❔ "Why should they be interested in me?"

Answer: Their business model is not based on customers. The attackers are not interested in you. They just cast their net and you just got/will get caught as one of many fish. They go for the masses in which you are part of, not you as a person.

❔ "My password is very strong, so I use it everywhere!"

Answer: You password must be unique per site/service! If one site is hacked, you might not even know about it and your credentials can be used everywhere, because they are not unique. Follow the tipps here.

❔ "The attackers want to hurt me!"

Answer: No, mostly they just want to make money. In a ransomware attack for example they dont want to hurt you. Instead they want to get your money.

❔ "This is now secure and it stays that way."

Answer: IT-Security is an onging process. IT systems have an operating system, applications, libraries, middleware etc which all consist of many million lines of software code. And in these lines of code are many vulnerabilites, which are not found yet. But some day they will be found, get public knowledge and can be exploited. That is why IT security is an onging process.

❔ "Attackers have special technical skills."

Answer: Some might, but often they dont. Because when a vulnerability becomes public knowledge most of the time an exploit is written. And that exploit can be used by anyone. That is why its "not fair" - the attackes have and this as an advantage.

❔ "Everything can be hacked, so we are powerless!"

Answer: No, because there are many things which can be implemented and done, so an attack becomes so hard, that almost no one will try it.
Examples can be found here and here or as shown in the graphic: Start with implementing  vulnerability-management, hardening (use a framework like cis, nist, etc), implement zero trust network or microsegmentation, implement 2fa or mfa, etc.

Windows Credential Guard CredGuard active?

If you want to check if Microsofts Windows Credential Guard CredGuard is active, you may do so by either checking msinfo32.exe or powershell:

CredGuard Status - msinfo32.exe:

CredGuard Status - Powershell

[bool] (Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning -eq $true

true = active
false =inactive

 

Information about Credential Guard

"Kerberos, NTLM, and Credential manager isolate secrets by using virtualization-based security. Previous versions of Windows stored secrets in the Local Security Authority (LSA). Prior to Windows 10, the LSA stored secrets used by the operating system in its process memory. With Windows Defender Credential Guard enabled, the LSA process in the operating system talks to a new component called the isolated LSA process that stores and protects those secrets. Data stored by the isolated LSA process is protected using virtualization-based security and is not accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process.

For security reasons, the isolated LSA process doesn't host any device drivers. Instead, it only hosts a small subset of operating system binaries that are needed for security and nothing else. All of these binaries are signed with a certificate that is trusted by virtualization-based security and these signatures are validated before launching the file in the protected environment.

When Windows Defender Credential Guard is enabled, NTLMv1, MS-CHAPv2, Digest, and CredSSP cannot use the signed-in credentials. Thus, single sign-on does not work with these protocols. However, applications can prompt for credentials or use credentials stored in the Windows Vault which are not protected by Windows Defender Credential Guard with any of these protocols. It is strongly recommended that valuable credentials, such as the sign-in credentials, not be used with any of these protocols. If these protocols must be used by domain or Azure AD users, secondary credentials should be provisioned for these use cases.

When Windows Defender Credential Guard is enabled, Kerberos does not allow unconstrained Kerberos delegation or DES encryption, not only for signed-in credentials, but also prompted or saved credentials."

https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-how-it-works

Browser Client-Side Storage Partitioning - Total Cookie Protection

A step to increase it-security is segmenting client-side (cookie) storage: https://github.com/privacycg/storage-partitioning

"User agent state that is keyed by a single origin or site is an acknowledged privacy and security bug. Through side-channels or more directly, this allows:

1. A top-level site https://site-a.example A to infer that a user is also visiting top-level site https://site-b.example B, by embedding resources or documents from B in A. Beyond visiting, it can also allow A to infer specific state from B that depends on the user, thereby revealing many aspects of the user. Timing Attacks on Web Privacy, XS-Leaks, and COSI discuss this in more detail.
2. Conversely, it allows a site https://tracker.example whose resources might be embedded on many different sites, to track the end user across these sites.

To solve a key aspect of this, any such user agent state needs to be keyed by more than a single origin or site.

There are many standards that together make up a user agent and many of these standards define “problematic” state. This repository’s issue tracker is where we're coordinating the effort to address these issues in an ideally holistic manner. The actual changes will happen in each impacted standard and are collated here for visibility."

Therefore Mozilla Firefox has started Total Cookie Protection in version 86. In Mozillas blog post is a nice picture, which explains the principle of client-side cookie storage partitioning:

Source: https://blog.mozilla.org/security/2021/02/23/total-cookie-protection/

API security - How to start securing APIs

APIs are great, they are everywhere and they grow. When thinking about API security very often very basic security mechanisms are missing. This article is about the very minimum frist steps you should always take:

First steps to think about

1. Only expose the parts of the interface which are necessary, not the entire API
   
2. Only collect and publish the data which is really necessary
3. Only grant access to people/systems which need it
4. Switch sides and think like an attacker ("Write a black mirror episode about your API", Keith Casey 2019)

API gateway

Use API gateways, because they take care of:

1. Lifecycle: In which state is your API? How was it designed and built? To which gateways is it published and is it live & available?
2. Interface: What does it expose? Which resources, methods, objects and fields?
3. Access: Who can use it? Which users or groups, which authentication, which clients, which contexts?
4. Usage: How to succeed with it? API documentation, debugging and errors, tracking usage, examples & sdks?
5. Business: How does it drive business goals? Partner CRM, marketing, business analytics

API gateways like apigee, kong, apache apisix, krakenD, the list is long. Great overview about open source api gateways: https://www.predic8.de/open-source-api-management-kong-tyk-fusio-umbrella-wso2.htm

API Access

Use available standards like OpenID connect. Don't just use OAuth Core, but instead the OpenID connect, because you'd probably missing a lot of different additional important standards. A list of the few common OAuth/OIDC specifications may show why:

(Source: https://www.youtube.com/watch?v=D7AfQKxFC0U)

 

Input validation

There are so many different attack vectors. One of the most basic yet so often missing things is good input validation, which helps stopping classical attacks like XSS, injections, deserialization and so on. But it also stops breaking the programms intention or in other words its business logic. 

 

Input validation should be applied in the enforcment of correct syntax (e.g. SSN, date, currency symbol), so the syntactic level and for semantic validation to enforce correctness of their values in the specific business context (e.g. start date is before end date, price is within expected range).

There is so much more

• https://owasp.org/www-project-api-security/  
• https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
• https://attack.mitre.org/techniques/T1106/
• Regularly updating your systems of which the api is built on
• Harden your systems, applications, middleware, runtime-environment and interfaces of which the api is built on
• Do regularly penetration testing and vulnerability scanning
  
• Enhance and regularly review logging & monitoring including automized alerts based on thresholds
  

haveibeenpwned.com Cit0day pwned readmore.de and many others

This summary is not available. Please click here to view the post.

Forget the phrase "password" - it should be pass-sentence

It is unfortunate that the word "password" has the word "word" in it. That leads to people almost always use one word, add one or two numbers to it, maybe a special character and thats it:

Classic passwords:
alina11$
456peter
nadine030
target123
cowboy123
etc..

word + number (+ special char) ==> ❌very bad security

Solution

So how can that be fixed because remembering long complex passwords like oT(O§%isaB"4 is hard. Answer: Instead of using "words" in passwords, use sentences.

Example:
ilikenewyorkquitealot
natureisimportanttome
danhasbeautifuleyes
ireallylovethehow2itsecblog

=> 🔒✅ Stronger passwords
=> 🔒✅ Fast to type
=> 🔒✅ Easy to remember

Additional tipps:
1. Always use two or multi-factor-authentication (2FA/MFA)
2. Use a password-manager (like the free keepass)
3. Protect your mailaccounts! Use unique and long passwords with 2FA for them. Because that is the place were you reset your passwords.

German:

Vergessen Sie "Passwort", es sollte "Pass-Satz" heißen

Unglücklicherweise heißt es "Passwort". Darin steckt das Wort "wort". Viel besser wäre, wenn es "Pass-Satz" heißen würde. Das klassische Password sieht wie folgt aus:

alina11$
456peter
nadine030
target123
cowboy123
etc..

Wort + Zahl (+ Sonderzeichen) ==> ❌Sehr schlechte Sicherheit

Solution

Was kann man in der Praxis dagegen tun? Denn sich lange komplexe Passwörter merken wie oT(O§%isaB"4 ist schwierig. Antwort: Statt "Pass-Wörter" zu verwenden, lieber "Pass-Sätze" verwenden:

Beispiel::
ilikenewyorkquitealot
natureisimportanttome
danhasbeautifuleyes
ireallylovethehow2itsecblog

=> 🔒✅ Bessere Sicherheit
=> 🔒✅ Schnell eingetippt
=> 🔒✅ Leicht zu merken

Zusätzliche Tipps
1. Immer Zwei- oder Mehrfaktor-Authentifizierung verwenden (2FA/MFA)
2. Einen Passwort-Manager verwenden (wie das kostenfreie keepass)
3. Schützen Sie Ihre Mailaccounts! Nutzen Sie mindestens dort immer einzigartige lange Passwörter + 2FA. Denn hier werden Passwörter zurückgesetzt.

List FortiGate Certificates via CLI - CA certificates and local Certificates

You can either use the GUI of the FortiGate to list all certificates, or use the CLI. Either using the commands:

Using the "get" command

config vdom
edit root   #<--- your management vdom/your vdom of choice
get vpn certificate ca

FGT50E00000000 (root) #
FGT50E00000000 (root) # get vpn certificate ca
== [ Fortinet_Wifi_CA ]
name: Fortinet_Wifi_CA
== [ Fortinet_CA ]
name: Fortinet_CA
== [ ACCVRAIZ1 ]
name: ACCVRAIZ1
== [ AC_RAIZ_FNMT-RCM ]
name: AC_RAIZ_FNMT-RCM
== [ Actalis_Authentication_Root_CA ]
name: Actalis_Authentication_Root_CA
[...]

Using the "show" command

The show command might not be very helpful, because it does not necessarily show all certificates:

FGT50E00000000 (root) #
FGT50E00000000 (root) # show vpn certificate ca
config vpn certificate ca
end
FGT50E00000000 (root) # show full-configuration vpn certificate ca
config vpn certificate caend

FGT50E00000000 (root) # show full-configuration | grep -f 'vpn certificate ca'
config vpn certificate ca <---
end
FGT50E00000000 (root) #

Using the "fnsysctl" command

Using the fnsysctl command might be helpful:

FGT50E00000000  #
FGT50E00000000 # fnsysctl ls -la /etc/cert/local/
drwxr-xr-x    2 0    0   Wed Dec 25 21:43:14 2019        0 .
drwxr-xr-x    6 0    0   Wed Sep 18 20:39:27 2019        0 ..
-rw-------    1 0    0   Wed Sep 18 20:35:46 2019     2250 root_2020jan_sub.domain.tld.cer
-rw-------    1 0    0   Wed Sep 18 20:35:46 2019     1704 KEY-FILE
-rw-------    1 0    0   Wed Sep 18 20:35:46 2019     1407 root_Fortinet_CA_SSL.cer
-rw-------    1 0    0   Wed Sep 18 20:35:47 2019     1704 KEY-FILE
-rw-------    1 0    0   Wed Sep 18 20:35:47 2019     1419 root_Fortinet_CA_Untrusted.cer
-rw-------    1 0    0   Wed Sep 18 20:35:47 2019     1704 KEY-FILE
-rw-------    1 0    0   Wed Sep 18 20:35:47 2019     4285 root_Fortinet_Factory.cer
-rw-------    1 0    0   Wed Sep 18 20:35:47 2019     1679 KEY-FILE[...]
FGT50E00000000  #
FGT50E00000000  # fnsysctl ls -la /etc/cert/ca
drwxr-xr-x    2 0    0   Wed Dec 25 21:41:28 2019        0 .
drwxr-xr-x    6 0    0   Wed Sep 18 20:39:27 2019        0 ..
-rw-------    1 0    0   Wed Sep 18 20:35:55 2019      119 ca_bundle_ver
-rw-------    1 0    0   Tue Jan 14 20:06:15 2020 1972 root_AC_RAIZ_FNMT-RCM.cer
-rw-------    1 0    0   Tue Jan 14 20:06:15 2020 2772 root_ACCVRAIZ1.cer
-rw-------    1 0    0   Wed Sep 18 20:35:55 2019     2041 root_ACEDICOM_Root.cer
-rw-------    1 0    0   Tue Jan 14 20:06:15 2020 2049 root_Actalis_Authentication_Root_CA.cer
-rw-------    1 0    0   Tue Jan 14 20:06:14 2020 1521 root_AddTrust_External_Root.cer[...]

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.

Solution for Skybox connection issue to Fortinet FortiGate or FortiManager

If you are using the Skybox (https://www.skyboxsecurity.com/) solution for your environment, during the initial setup there might be an issue in the connection from the Skybox to your Fortinet FortiGate firewalls or your or FortiManager firewall management system. Skybox uses HTTPS (XML API with SOAP) and/or SSH to connect to the Fortinet systems.

If your hardening of the Fortinet devices changed the default minimum Diffie-Hellman Exchange-Bits from 2048 to 3072, 4096 or 8192Bits, then your Skybox is not able to connect to them, after Skybox currently does not support more than 2048Bit for DH.

FortiGate Hardening of DH-Bits:

config sys global
 set dh-params 8192
end

See also the Skybox documentation "ReferenceGuide", e.g. here "Reference Guide v10.801" or an overview of the documentation of all last versions.

Hardening FortiGate connection to FortiAnalyzer

The FortiGate uses OFTP (Fortinets proprietary Optimized Fabric Transfer Protocol, not Odette File Transfer Protocol) to transfer data between FortiGates and FortiAnalyzer. For encryption SSLv3 or TLS is used. In order to harden the connection, use the following commands:

Cfg for FortiAnalyzer 

 1. Set TLS to minimum version 1.2:


2. Change FAZ certificate to one using the correct FQDN from your/a public CA:



Debugging can be done using the fowlloing commands:

Oftpd daemon test usage:   diagnose test application oftpd <integer>

• 1: show PID
• 2: show statistics and state
• 3: show connected device name and IP
• 4: show detailed session state
• 5: show oftp request statistics
• 6: show cmdb device cache
• 7: show logfwd thread stats
• 8: show tasklist statistics
• 9: show unreg dev cache
• 10: log cluster bridge stats
• 20: show forticlent end-user stats
• 21: rebuild forticlient end-user avatar table
• 90: reload un-reg device tree
• 99: restart daemon

FAZ looks like this:

(global)# get

dh-params           : 8192

enc-algorithm       : high

fgfm-ssl-protocol   : tlsv1.2

oftp-ssl-protocol   : tlsv1.2

ssl-low-encryption  : disable

ssl-protocol        : tlsv1.2

ssl-static-key-ciphers: disable

webservice-proto    : tlsv1.2

Cfg for FortiGate

1. Change TLS ciphers to high:

config log fortianalyzer setting

    set enc-algorithm high

end

2. Change Global TLS-Settings

config system global

    set ssl-static-key-ciphers disable

    set dh-params 8192

    set strong-crypto enable

end