A colleague messaged me last week because he could not import a certificate on a FortiGate (that had been exported from a Cisco ASA). He was seeing this error;
Incorrect certificate file format for CA/LOCAL/CRL/REMOTE cert.
FortiGate Certificate Problems
A brief Google led me to ask “Is the FortGate licensed or on a Free/Trial license?” As that can produce this error {apparently}. But for us this was not the problem.
This was happening because the ASA (like Windows) exports its certificates in ‘base64‘ encoding and the FortiGate does not like that, so it throws its toys out of the pram. Firstly ENSURE you exported the certificate as a PKCS12 file like so,
Otherwise the certificate will NOT be exported with its private key, and if you import a certificate into a FortiGate without the private key you will get this error;
Certificate file is duplicated for CA/LOCAL./REMOTE/CRL cert.
We now have a copy of our exported ‘base64 encoded’ certificate. (Note: It has no file extension, don’t panic!) If it was extracted from Windows, it might have a .PFX extension. If yours does, simply use the following commands with that file extension.
And put it on a machine that has OpenSSL installed, or if like me you’re a macOS user copy it there, (OpenSSL is installed by default). Firstly we have to decode the extracted certificate;
If you are applying polices with your FortiGate, e.g. Web Filtering or IPS, then the ability to track actual users rather than IP addresses is advantageous, it’s all very well blocking access to adult material or gambling sites, from the corporate network, but most companies want to know WHO is attempting to connect to what and when.
To do that the firewall needs to learn what users are where, we can make all users actively authenticate to the firewall as they attempt to get on the web, but that does not make for a great user experience, it’s better to passively learn where your users are, and what machines they are using, then we can the use that in a policy. (let’s not get to far ahead for the moment).
Q. How do we learn where your users are, and what machines they are on?
A. FSSO
To enable FSSO you need to understand the difference between two pieces of software, the FSSO Collector, and FSSO DC Agent. The DCAgent (as the name implies) run on each of your DCs, it captures login events and then does DNS lookups to see what machines people are using. The Collector takes the output from one or more DC Agents and collates it for the firewall, it does not have to run on a domain controller (but it can).
I only have one server! Well thats OK, both the collector and agent can be on the same box
However most networks will have multiple Domain Controllers, so your FSSO topology may look a little more like this.
Or if you have an even larger network, you may want to build in a backup collector(s)
Deploy FSSO
In my small test environment I’m going to put the collector and agent on a single DC. Your first challenge is actually getting the FSSO software. Log into your FortiCloud portal and proceed as if you want to download some FortiGate firmware.
Then in the version of FortiGate firmware that matches your firewall you will find an FSSO directory, (unless your’e in the dark ages your domain controllers will be x64 bit) so in my case I want FSSO_Setup5.0.0306_x64.exe (that will download the collector setup, that also includes the DC Agent software as well, which you can also download separately if you wish).
Install Collector
Accept the EULA, change the install directory if you don’t want it on the C: Drive > Enter some administrative credentials > Next.
My FortiGate has LDAPS Lookups so I’m going for Advanced > Next.
Install > When complete, Im installing the DC Agent on the same server so MAKE SURE ‘Launch DC Agent Install Wizard” IS ticked, and click finish.
Warning: Installing a DC Agent will result in the reboot of this DC, (you might want to do the next step out of hours).
Install DC Agent
Accept the defaults > Next > Select the Domain > Next > Select any user(s) you want to be exempt > Next.
Select DC Agent Mode > Next > It will prompt for a reboot, let it do so.
Post reboot launch FortiGate Single Sign On Agent Configuration > And change the password to something memorable, (you will need to enter this onto the FortiGate in a minute).
Register FSSO on FortiGate
Back on the Fortigate > Security Fabric EXTERNAL Connectors > FSSO Agent on Windows AD.
Give it a sensible name > Enter the IP address and the password you set above > Apply and Refresh > OK.
You will know it’s working because it will give you a free up arrow (it can take a little while, be patient).
Create FSSO Groups
Now you can add GROUPs based on FSSO learned groups, like so.
Once you have the FSSO groups defined, you can use them in policies. Below I’ve added Domain Users to my default outbound policy.
WARNING: If you have any devices, or assets that need access out you will need to add a new rule to alow them out explicitly before this rule, or their internet access will suddenly stop.
Monitor FSSO Events
To make sure the system is working you can go to Events > User Events > Make sure your user logon activity is getting logged.
Related Articles, References, Credits, or External Links
If you want to employ the IPS service of a FortiGate firewall then you need a license for that privilege. At the time of writing you can get IPS as part of the following subscription licenses;
Enterprise Protection
SMB Protection (Only on firewalls SMALLER than 100F)
Unified Threat Protection (UTP)
Advanced Threat Protection (ATP)
But Forti love to change the names of things, so double check with your vendor.
Fortigate IPS (A Quick Tour)
OK let’s see if we have a valid IPS Licence. Dashboard > Status > Licences > IPS > If it’s green and ticked we are good.
Now let’s make sure all our Intrusion Prevention definitions and engines etc are all up to date.
Note: Notice the Malicious URLs – I’ll mention that again in a minute.
The next couple of steps are purely informational, (so you can understand how IPS works, and how everything hangs together). Go to Security Profiles > IPS Signatures. Spend a few minutes looking at this page so you will better understand how they are applied. First each one is assigned a Severity,
1. Informational (green) 2. Low (blue) 3. Medium (yellow) 4. High (orange) 5. Critical (red).
In addition it’s given a Target (Server, Client , or BOTH), and an applicable OS, Action is set by default to BLOCK or PASS
Note: You can also find specific CVE-IDs (if applicable) for each signature, this will hyperlink to the info for that CVE, but also lets you quickly check you are protected against a new CVE, (you can type them in the search section).
Why is all that important? Well if you know that then, how the IPS profiles work is pretty self explanatory, it uses all the above to group signatures together by severity, target and OS, which enable you to make your own very granular profiles (if you wanted to).
So let’s have a look at them, Security Profiles > Intrusion Protection.
To take a look at each one, select it and edit, to be honest most of the time you will be wanting default or all_defaultthough (as you can see there are specific profiles for web servers and mail servers etc.
Note: Remember I mentioned the Suspicious URLs above? This is where you can enable that if you wish, be aware this is a dynamic list of URLs that you cannot edit (or whitelist) you need to make a request to FortiNet if you want to remove a URL from it. The documentation says;
“To use this IPS signature to block malicious URLs, select Block malicious URLs. This feature uses a local malicious URL database on the FortiGate to assist in drive-by exploits detection. The database contains all malicious URLs active in the last one month, and all drive-by exploit URLs active in the last three months. The number of URLs controlled are in the one million range.“
Also Note: Logging is disabled by default, (more on that in a minute).
Enable FortiGate IPS
To actually enable IPS is simple, in any normal Firewall Policy (or IPv4 Policy if you’re on ‘old code’) you enable the IPS Policy you require inside it like so.
Testing FortiGate IPS
Do a search for this and the web is full of articles on creating a custom signature adding that to a policy then testing it, which is a bit ‘bobbins’ IMHO. It’s an IPS, let’s put on our black hat and do something nefarious to make sure it’s working, (obviously ask a grown ups permission before launching attacks on your own network, and don’t send your IT security manager to PeteNetLive to complain, because I’ll just laugh at them).
OK, really straight forward, I’ve got KALI Linux running Armitage (a Metasploit tool) on my LAN. Which I’m going to use to attack a Windows server that’s sat just outside my FortiGate. Using a known RDP vulnerability. But first let’s enable logging on our IPS Profile.
Edit the policy (make sure it’s the one that’s actually getting inspected!) Enable packet logging > OK.
Launch Armitage, connect using the default settings, search for MS12_020 and you should see it listed (as shown) > Double click it > Enter the IP of the server to attack > Launch. After some code scrolls by eventually it will probably say ‘RDP service unreachable‘ (because our IPS has earned its wages).
Note: At this point I’d say go and have a coffee, IPS blocks instantaneously, but it takes a couple of minutes for it to appear in the logs.
Log and Report > Intrusion Prevention > Boom ‘time for tea and medals!’ (remember give it a few minutes). Dont forget to go back and disable logging on your IDS Policy.
Related Articles, References, Credits, or External Links
Imagine the following scenario, you have a PUBLIC web server and it’s either in the same network your uses are or attached to a DMZ on your FortiGate.
So above our users open a web browser and attempts to go to www.ubique.com (1) Their PC will do a DNS lookup for www.ubique.com and (in this case) a public web server returns an ip of 192.168.100.200 (2). The browser then attempts to HAIRPIN to that IP which is external to your FoirtiGate and the traffic is blocked.
FortiGate Hairpin Solution
If you have internal DNS servers you can of course solve this problem with Split DNS with a Cisco firewall, you could also solve this problem with DNS Doctoring, In fact if your from a Cisco background then even the name Hairpin is confusing because in Cisco when we mention Cisco Hair pinning we are usually talking about VPN traffic. Anyway I digress.
So to replicate the scenario above, i.e. it being broken on my LAN PC, I cannot browse to that site, and you can see my DNS is resolving to its public IP.
Polices and Objects > Virtual IPs > New > Virtual IP > Give it a Name > Interface = any > Set External IP > Set Internal IP > Note: You don’t have to set port forwarding but I’m only using TCP 80 > OK.
I already Have a Virtual IP: If your existing web server already has a Virtual IP object MAKE SURE it’s NOT bound to the outside interface, (or you won’t be able to select it in a minute). If you can’t edit it (because it’s in use), then you might need to remove it from the existing policy, and recreate it.
Policy and Object > Firewall Policy > Create New > Give the Policy a Name > Set the incoming and outgoing interface to the internal one > Source = All > Destination > the Virtual IP you just Created > Schedule = always > Service = HTTP > Disable NAT > OK.
I can’t see Virtual IP in the Policy: Then it’s either bound to an interface that ISN’T the inside one, or you have Central NAT enabled. If you don’t want to change your global NAT policy create an address object for the internal IP and use that instead.
Now the website should work
Related Articles, References, Credits, or External Links
I was asked by a colleague at work the other day, can we replace the Cisco firewalls with FortiGate firewalls for a client? As a business we are heading towards Forti, but before I said yes I wanted to know what the firewall was actually doing before I said yes. On closer inspection the firewall in question didn’t appear to be doing anything too scary, but I did notice that the LAN interface was sub-interfaced to the various internal VLANs. I didn’t know how FortiGate handled this, so I fired it up on the test bench to test FortiGate Sub Interfaces.
So I needed to create TWO sub interfaces on the FortiGate (on port3).
Creating FortiGate Sub Interfaces
Simply put, on a FortiGate if you want what a Cisco engineer would refer to as a ‘sub interface‘, then you simply add a VLAN interface to a physical interface. Like so, Network > Interfaces > {Physical Interface} > Create New > Interface.
Give the new interface a name (and alias if required) > Interface Type should be VLAN > Select the parent physical interface > Add the VLAN ID (Tag) and specify an IP address of the interface.
Just for testing I’ll allow PING, on the VLAN interface also > OK.
Repeat the procedure to add further sub interfaces (VLANs).
Remember this is just a ‘Router on a stick‘ configuration, to further allow traffic to the internet, (or between VLANs) you still need to add that traffic to the firewall policy to let the traffic through, (it is a firewall after all!)
Setting up Switches for FortiGate Sub Interfaces?
I’ve probably got this covered elsewhere on the site, but the core switch is Cisco so I just created a trunk port, and allowed ALL VLANs, (because I’m lazy, in production, you might want to lock that down a little!)
While attempting to connect to a FortiGate firewall (with Firefox over HTTPS) you may see this error;
Secure Connection Failed
An error occurred during a connection to {x.x.x.x} SSL received a record that exceeded the maximum permissible length error code : SSL_ERROR_RX_RECORD_TOO_LONG
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem
Solution: SSL_ERROR_RX_RECORD_TOO_LONG
My colleague went all round the houses trying to fix this, then asked If I knew what was wrong, annoyingly one Google search gave me the answer;
You can only manage the FortiGate via HTTP when using an evaluation licence!
Related Articles, References, Credits, or External Links
I’ve been getting through my NSE4, and one of todays topics was NAT, just as an offhand comment the ‘narrator‘ (I say narrator because it’s a monotonous robot AI voice,) mentioned Fortigate Load Balancing.
In the past (with my Cisco hat on) when I’ve been asked about load balancing, I’ve said ‘If you want to load balance, buy a load balancer‘. But the Fortigate does try to be ‘all things to all men‘ so I wondered just how good a load balancer can it be?
Turns out, quite a decent one, if you just want simple http round robin, it does that, it you want weighted traffic routing, or host health monitoring, or HTTP cookie persistence, and even SSL offload. It’s as good as anything I’ve ever worked on before. Here’s my Fortigate ‘Test Bench‘, you will see I’ve added three web servers (on the right) called Red, Green, and Blue (the significance of which will become apparent). Note: Yes there’s another web server at the bottom, (I’m too lazy to remove it from the lab!)
I’m going to setup simple round robin load balancing between these three web servers, and I’m going to get the Fortigate to monitor their health by simply making sure they respond to ping packets. (Note: it can monitor http availability or something a little better if you wish).
Solution
This tripped me up for a while! Load balancing is a feature, you need to turn it on first, System > Feature Visibility > Load Balancing > Enable.
Policy & Objects > Health Check > Create New > Give it a name > Type = Ping > Interval = 10 > Timeout = 2 > Retry = 3 > OK
Now create a Virtual Server (not a VIP!) Policy & Objects > Virtual Servers > Create New > Name = Give it a sensible name > Type = HTTP > Interface = Your Outside/WAN interface > Virtual Server IP (Externally!) > Virtual Server Port = 80 > Load Balancing method = Round Robin > Persistence = HTTP cookie > Heath Check = Select the one you created above.
Scroll down > Real Servers > Create New.
Add in the first (internal server IP) > Port = 80 > Max connections = 0 (that’s unlimited) > OK.
Repeat the process to add the remaining servers > OK.
FortiGate Load Balancing: Enable Firewall Policy
Now you need to ‘allow’ traffic in (it is a firewall after all!) Policy & Objects > Firewall Policy (or IPv4 policy on older firewalls) > Create New > Name = Give it a sensible name > Incoming Interface = Outside > Outgoing Interface = Inside > STOP Change Inspection Mode to PROXY Based > Destination = Your Virtual Server (it’s not visible unless you have enabled proxy based!) > Schedule = Always > Service = All > Action = Accept > NAT = Enabled > You may also enable AV inspection > OK.
FortiGate Load Balancing:Testing and Tweaking
So from ‘Outside’ let’s hit our load balanced page.
That’s great but if you hit refresh a few times nothing changes (in production nothing would change anyway, but to prove my back end servers are getting used and load balanced, each of mine serves a different coloured page (hence the red, green and blue server names). The reason I’m only seeing the blue one, is because we enabled ‘HTTP cookie Persistence‘ let’s just nip back onto the firewall and disable that (set it to None > OK).
Now when I refresh by browser I can see it cycling though the back end servers.
FortiGate SSL Offload
To use and process SSL requires some CPU power, some websites (like this one) serve their webpages protected by https and the certificate that enables that lives on the web server, for sites like mine that are getting about 12k hits a day that’s fine but if you are getting hundreds of thousands of hits a minute that’s a MASSIVE drain on CPU resources. That’s what SSL offload is all about, getting another device (in this case the Fortigate) to do all the heavy lifting for you. Then the back end servers can get on with the job of serving web pages.
Upload the Certificate to the FortiGate
For HTTPS you will need a web certificate that will be trusted by your visitors. I’m lazy and tight so I’ll just create one in Microsoft Certificate Services, but in Production you will need Publicly Signed Certificate. System > Certificates (if you can’t see certificates) > Import > Local Certificate.
Mine’s in PFX format so I need to select PKCS#12 > upload the certificate and supply a password > OK
FortiGate: Enable SSL Offload
On your Virtual Server, change the Type to HTTPS > Virtual ServerPort to 443 > Certificate to the one you just uploaded > OK.
We are now serving pages securely even though the web servers are not configured for https.
Related Articles, References, Credits, or External Links
Nice quick easy one today, while setting up SSLVPNs for a client I needed to import their Root CA certificate, and found the Fortigate Certificates Missing? Usually they are under System > Certificates. But the tab was simply not there?
Solution: Fortigate Certificates Missing
Fortunately it was simple to fix, it’s a ‘feature‘ you simply need to ‘enable‘. Go to System > Feature Visibility > Enable Certificates, et voila!
If only all my problems were that simple!
Related Articles, References, Credits, or External Links
When considering Securing FortiGate remote administration, I’ve written about changing the https management port to something other than TCP 443 before, I suppose that’s security by obfuscation (though even a script kiddy with one hours experience, will be able to spot an html responses). Typically with other vendors you limit remote administration access, to specific IP addresses (or ranges). So how to do the same in Fortigate?
FortiGate Trusted Hosts
With FortiGate the approach is slightly different, (to Cisco anyway) in that, you allow access from ‘Trusted Hosts‘ and you do that ‘Per Administrator’ not for the entire remote access solution (like HTTPS or SSH). On reflection I like this, because by default you will have a user called ‘admin’ and an attacker will ‘possibly’ know that. With FortiGate you can restrict the admin account so it can only log on from inside, or from management hosts/networks or from an Out of Band management network.
You can also give an administrative password to one partner and only allow access from that partner’s public IP/Range, or if like my firm we need to support a lot of firewalls we can hard code this into our default deployments and retain remote administration. (Though FortiManager is the direction you want to be headed in, for that!)
System > Administrators > Create New > Administrator.
Create a username/password > Select the admin level required > Enable ‘Restrict Login to Trusted Hosts’
Here’s an example where the admin account can only manage the firewall form the 192.168.1.0/24 network, and a management host 192.168.2100.3 For ‘external‘ access I’ve got a new administrator, who can get access from my management host, (for belt and braces), a single public network, and a public IP address.
Related Articles, References, Credits, or External Links
Here’s a brief one that tripped me up a couple of weeks ago, I was deploying FortiGate LDAPS authentication for some FortiClient SSLVPN connections into a FortiGate firewall like so;
Despite my best efforts I was getting authentication failures? If I tested the username and password in the GUI web management portal, that worked fine?
Testing FortiGate LDAPS
First step is to test authentication at command line, like so;
[box]
Forti-FW # diag test auth ldap My-DC test.user Password123
authenticate 'test.user' against 'My-DC' failed!
[/box]
Note: My-DC is the domain controller, test, user is the username, and Password123 is the password for my AD user. (The fact I need to explain that is depressing, but c’est la vie).
So despite what the GUI is telling me, authentication is actually failing, remember I’m using LDAPS, so the FortiGate needs to have the CA certificate, (that issued the Kerberos certificates on my domain controller(s)), in its trusted CA list! And TCP port 636 needs to be open between the firewall and the domain controllers.
Debugging FortiGate LDAPS
So now we need to debug what’s going on;
[box]
Forti-FW # diagnose debug enable
Forti-FW # diagnose debug application fnbamd 255
Debug messages will be on for 30 minutes.
[/box]
Then simply attempt to authenticate via FortiClient, or recall the ‘diag test’ command from above.
[box]
Forti-FW # diag test auth ldap My-DC test.user Password123
[1932] handle_req-Rcvd auth req 1296531457 for test.user in My-DC opt=0000001b prot=0
[424] __compose_group_list_from_req-Group 'My-DC', type 1
[617] fnbamd_pop3_start-test.user
[970] __fnbamd_cfg_get_ldap_list_by_server-
[976] __fnbamd_cfg_get_ldap_list_by_server-Loaded LDAP server 'My-DC'
[1131] fnbamd_cfg_get_ldap_list-Total ldap servers to try: 1
[1713] fnbamd_ldap_init-search filter is: sAMAccountName=test.user
[1722] fnbamd_ldap_init-search base is: dc=testbench,dc=co,dc=uk
[1146] __fnbamd_ldap_dns_cb-Resolved My-DC:192.168.1.122 to 192.168.1.122, cur stack size:1
[919] __fnbamd_ldap_get_next_addr-
[1152] __fnbamd_ldap_dns_cb-Connection starts My-DC:192.168.1.122, addr 192.168.1.122 over SSL
[874] __fnbamd_ldap_start_conn-Still connecting 192.168.1.122.
[591] create_auth_session-Total 1 server(s) to try
[1097] __ldap_connect-tcps_connect(192.168.1.122) failed: ssl_connect() failed: 337047686 (error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed).
[930] __ldap_error-My-DC:192.168.1.122, addr 192.168.1.122
[725] __ldap_stop-Conn with 192.168.1.122 destroyed.
[919] __fnbamd_ldap_get_next_addr-
[902] __ldap_try_next_server-No more server to try for 'My-DC'.
[785] __ldap_done-svr 'My-DC'
[755] __ldap_destroy-
[2870] fnbamd_ldap_result-Error (3) for req 1296531457
[217] fnbamd_comm_send_result-Sending result 3 (nid 0) for req 1296531457, len=2044
authenticate 'test.user' against 'My-DC' failed!
Forti-FW # [747] destroy_auth_session-delete session 1296531457
[755] __ldap_destroy-
[1764] fnbamd_ldap_auth_ctx_free-Freeing 'My-DC' ctx
[2099] fnbamd_ldap_free-Freeing 'My-DC'
[/box]
OK so it’s SSL related? For SSL to work you need the following;
To trust the CA that issued the certificate
To be able to resolve (via DNS) the common name (or Subject Alternative Name) on the certificate
If you’ve specified the LDAP server by IP address the IP address of the server needs to be on the certificate as a Subject Alternative Name (SAN).
Your firewall and the AD/LDAP server need to have compatible SSL ciphers.
So I had number 1 covered, and the chance of it being number 4 are rare, (server and firewall are fully updated).
So my problem was initially number 2 I’d specified the LDAPS server via its internal IP. I needed to use its FQDN, then of course the firewall needed to be able to resolve that IP with a DNS lookup (try execute ping server-name.doman-name if you’re unsure!)
[box]
Forti-FW # execute ping win-server.testbench.co.ukUnable to resolve hostname. <---OOPS THAT'S NOT GOOD!
Forti-FW # execute ping 192.168.1.122 <---CONNECTIVITY IS OK!
PING 192.168.1.122 (192.168.1.122): 56 data bytes
64 bytes from 192.168.1.122: icmp_seq=0 ttl=128 time=5.4 ms
64 bytes from 192.168.1.122: icmp_seq=1 ttl=128 time=2.0 ms
64 bytes from 192.168.1.122: icmp_seq=2 ttl=128 time=1.9 ms
^C
--- 192.168.1.122 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.9/3.1/5.4 ms
[/box]
Once DNS was setup correctly;
[box]
Forti-FW # execute ping win-server.testbench.co.uk
PING win-server.testbench.co.uk (192.168.1.122): 56 data bytes
64 bytes from 192.168.1.122: icmp_seq=0 ttl=128 time=1.9 ms
64 bytes from 192.168.1.122: icmp_seq=1 ttl=128 time=2.3 ms
64 bytes from 192.168.1.122: icmp_seq=2 ttl=128 time=2.1 ms
^C
--- win-server.testbench.co.uk ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss <---BOOM THAT'S BETTER
round-trip min/avg/max = 1.9/2.1/2.3 ms
[/box]
Then retest.
[box]
Forti-FW # diag test auth ldap My-DC test.user Password123
authenticate 'test.user' against 'My-DC' succeeded!
Group membership(s) - CN=GS-VPN-Users,OU=Securty-Groups,DC=testbench,DC=co,DC=uk
CN=Domain Users,CN=Users,DC=testbench,DC=co,DC=uk
[/box]
Related Articles, References, Credits, or External Links
