This is an ongoing blog, and one that I will update often will things that come up in security audits.
Companies are always getting external audits to make sure they comply with policies and have no outstanding vulnerabilities with their systems. This is great, but sometime the Fortigate will get pinged on SSL/SSH encryption level issues. The following blog is a few helpful commands that can get the Fortinet to pass inspection by disabling the lowest or least secure SSL and SSH protocols. Also below I have put in excerpts from a few scans.
Error: TLS Version 1 Protocol Detection – So the above was an issue with TLS Version 1.0 being enabled on port 443 (My SSL VPN port). So, we need to remove TLS 1.0 from the accepted protocols on the VPN.
The commands to do that are:
config vpn ssl settings set tlsv1-1 disable end
The disables TLSv1 from the SSL VPN
Vulnerability Details 116818
This host is susceptible to the SSL version 3 POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. By using SSL version 3 and CBC Mode ciphers this host can allow an attacker to expose encrypted data in a connection between the client and server. Impact: Over time, an attacker can steal sensitive information between the client and the server using this man in the middle attack. Hosts may default to a more secure protocol (TLS 1.2, for example), but a network attacker could potentially trigger a reconnection causing the browser to retry older protocols (SSL version 3).
The above error basically says that SSL Version 3 was enabled on SSL VPN port. Just like before we will disable that
config vpn ssl settings set sslv3 disable
set tlsv1-0 disable
set tlsv1-1 disable
This turns of SSLV3 from the SSL VPN supported protocols.
This Entry will be updated as I find more from going through audits.
As always docs.fortinet.com has the best information.
Firewalls almost always interface with the internet, and most of the time we enable remote access from the internet to make our lives easier when troubleshooting an issue, and maybe not being behind the firewall at the time. The best why to secure the device is just not enable access from insecure locations, but some times we have to enable it.
There are a few simple things we can do to help elevate vulnerable spots when allowing access from the internet.
Enable a password policy
Modify lockout policy/duration if needed
Allow admin access from only Trusted hosts
Modify default access TCP ports
Create a new admin account named something different, and then delete the default admin account.
Make sure a log in banner is active – Certain cyber laws need explicit notification that the user attempting login should have authorization.
Use dual factor authentication to gain admin access to the device.
Logging , always logging!
This blog is written with both 5.2 and 5.4 firmwares.
Enabling a password policy
This is great to do if you have multiple accounts on the device. This way a user cannot change their super complex password to something with 3-4 letters. A password policy enforces certain specifics to the password. For example you can set the character requirements as well as password reuse/expiration. Check out the below images for 5.2 and 5.4. Notice you can enable this for VPN accounts and admin accounts.
Login failure lockout duration and Threshold
When you mistype your password 3 times by default you are locked out of the firewall for 5 minutes (All docs say 60 seconds though). This is a great defense against applications that attempts to brute for the firewall user/pass. Increasing the time the user is locked out can be a good idea to keep the bad guys from knocking, but could also really put a damper in your day if you lock yourself out for X amount of time.
But the commands to lower or increase it are the same in both firmware’s:
config sys global
set admin-lockout-duration X (seconds)
To increase the threshold (how many incorrect login attempts you can have)
config sys global
set admin-lockout-threshold (1-10 attempts)
Only allow logins from Trusted hosts
Why allow logins from anywhere on the internet, when you know if you logged in it would come from only a few sources.
Under the administrators options, you can select the trusted hosts (IP networks) that can login with the Mirazon account in this case. You could also modify the default admin account.
Change default port numbers used for logins
I was in a debate one time about the security of changing default port numbers, and a friend said “Changing your login port numbers is as secure as hiding your keys under the front door mat.” He was most certainly correct, but security by obscurity is better than nothing. By changing the default port numbers from 443,80 some bots that try to log in will not find the open login due to different ports that are not in its scanning script.
In the following examples I am changing the default port of 443 to 8081.
In summary there are tons of things to do to increase device security. One of the most important, if you don’t need to allow remote logins to the device, why even enable it? Disable the login options under the interface. I believe the best practice is to have an out of band management PC that might connect directly into the MGMT port. To access the FW you have to access this machine.
Changing Port numbers and implementing the other options are great ways to help reduce login failure attempts, or unauthorized access. Another great option, not explained here is using dual factor authentication. By default you get two licenses for two factor – why not use it for admin access!
The importance of logging is one thing that cannot be underestimated. When logging is enabled you know exactly what happened – if someone tried to log in, from where, what username, and if they failed or were successful.
These were just a few of the many ways to increase device security.
Recently we were troubleshooting some network issues with a Cisco 1242 AP that suddenly stopped communicating with our WLC.
Controller firmware is 8.0.133
We consoled into the AP and found logs that looked like below. Then we logged into the WLC and saw similar logs.
*spamApTask0: %LWAPP-3-PAYLOAD_MISSING: spam_lrad.c:6433 Join request does not contain BOARD_DATA payload *spamApTask5: %CAPWAP-3-DECODE_ERR: capwap_ac_sm.c:4702 Error decoding Join request from AP 00:26:0b:10:34:70 *spamApTask6: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:844 Failed to complete DTLS handshake with peer 10.192.112.241 *spamApTask2: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:844 Failed to complete DTLS handshake with peer 10.10.91.20 *spamApTask6: %CAPWAP-3-DECODE_ERR: capwap_ac_sm.c:4702 Error decoding Join request from AP 00:26:0b:10:34:70 *spamApTask5: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:844 Failed to complete DTLS handshake with peer 10.10.75.23 *spamApTask0: %LWAPP-3-DECODE_ERR: spam_lrad.c:2364 Error decoding join request from AP 00:19:aa:35:10:88 *spamApTask0: %LWAPP-3-KEY_ERR3: spam_crypto.c:1630 The system is unable to free public key for AP 00:19:aa:35:10:88 *spamApTask0: %LWAPP-3-PAYLOAD_ERR: spam_lrad.c:7931 Join request does not contain valid certificate in certificate payload – AP 00:19:aa:35:10:88
Seems the AP cert had expired. To get around this we had to enable a command in the WLC that ignored the AP cert. The happened because the Manufacturer Installed Certificate (MIC) has now become older than ten years and has expired. This will not be accepted now.
I SSH’d into the controller and ran the below command:
config ap cert-expiry-ignore mic enable
This allowed the AP to come back online immediately.
If you happen to be on 7.0.252.X the command and logs are different:
Failed to complete DTLS handshake with peer 10.32.41.96 for AP 00:1d:45:36:97:30 *spamReceiveTask: Sep 19 21:42:59.855: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:631 Failed to complete DTLS handshake with peer 10.32.41.101 for AP 00:1d:45:56:b6:1c
Each log will of course be different due to IP/MAC. The commands to resolve this: