Bug Alert - FortiOS 4.0.2 and FortiManager

When adding a Fortigate 4.0.2 to a Fortimanager 4.0.1 the CPU on the firewall spikes to 100%, the culprit being the FGFMD process which handles communication with the FortiManager. Simply removing the firewall from FortiManager resolves the problem.
Recent forum posts suggest that this is an issue that might be fixed in FortiOS 4.0.3

** Update **
Rather than removing the unit from FortiManager you can also disable Central Management on the firewall itself: System -> Admin -> Central Management -> Uncheck "Enable Central Management".

** Update #2 **
Based on Fortinet's response I looked at the certificates which are installed on the firewall being affected. Turns out that I had a custom generated certificate loaded. After I deleted the certificate the CPU utilization remains normal, even when connected to the FortiManager.

FortiOS 4 - New Feature Spotlight - Application Control

One of the greatest new features in FortiOS 4 in my opinion is application control. Using application control you can now getter a better understanding of what your users are doing on a daily basis and you can control the applications which they are using. Application control not only gives you the ability to see what users are doing but it also allows you to block and in certain cases traffic shape the applications as well.

Most organizations today probably do not have a very good understanding of the types of applications in use. Application control gives you the ability to baseline application usage and to write policies around it.
As a simple example consider a business which permits port 80 for their employees. Instant Messaging applications are blocked by not permitting any traffic other than HTTP. Management is starting to get concerned that people are spending too much time using web based instant messaging clients to get around this restriction. In the past there was no real way to tell the two apart. Now with application control Fortinet is building on their IPS signatures to let you determine if users are simply browsing the web or using Facebook Chat. IT now has the ability to block any unwanted web based chat clients.

Fortinet already has a list of over 1000 applications which they can distinguish today. They are categorized so you can easily build them into your policies. If you need additional applications recognized you can easily submit them at the FortiGuard Center (http://www.fortiguardcenter.com/applicationcontrol/appcontrol.html). Updates can be pushed down to your firewall via IPS signature packages and no longer require a firmware upgrade.

Creating Self Signed Certificates for your Firewalls

Here is a quick step-by-step walk through to show you how to create a certificate signing request (CSR) and submit it to a public or local certificate authority (CA) for signing.

First you need to generate a certificate signing request on your firewall. Go to System -> Certificates -> Generate and fill in the appropriate information. For example:


Click OK. On the next screen download the certificate request you just created.

Now you have a couple of options. You can either pay a public root Certificate Authority such as GoDaddy or Verisign to sign your certificate. They can also provide you with information on how to submit your request.

Another option is to create your own Certificate Authority using free software. In this scenario I am using XCA, a great graphical front end for the somewhat complex procedure of creating a CA and signing certificates.

• Download XCA from http://sourceforge.net/projects/xca and install it
• In XCA create a new Certificate Database: File -> New Database
• Assign a complex pass phrase to the database
  

Create a Root Certificate Authority in XCA

• Certificates Tab -> New Certificate and fill in your information (example screenshots below)

In the "Template for the new certificate" select "[default] CA" and click Apply.


Click "Generate a new key", fill in the name and then click "Create".



Click OK. You now have a Root CA with public and private keys.

Sign the Certificate Signing Request

Click the "Certificate Signing Requests" tab, then "Import" and load the CSR you downloaded from the firewall. When loaded you can select the CSR and click "Show Details" to validate the information in the request.

Now right click on the CSR and select "Sign". Set your options according to the next screenshots.


After setting the "Template for new certificate" to "[default] HTTPS_Server" click Apply. By default the certificate will be valid for 1 year from date of issue. If you need this to be valid for longer you can adjust it in the "Extensions" tab in the "Validity" section. Please note that your end device certificates cannot be valid longer than the Root CA which by default is 10 years.

Click OK.

On the "Certificates" tab expand the Root CA and select the firewall certificate. Then click "Export" and save the file using PEM as the Export Format.

Back at your firewall return to System -> Certificates and click "Import". Select the certificate (*.crt) that you exported from XCA and click OK. The certificate is now ready for use in your firewall.

Software Updates

Current Updates

FortiOS:

• 3.0 MR6 Patch 6 Build 678

FortiMail:

• 3.0 MR5 Patch 5 Build 508

FortiManager:

• 3.0 MR7 Patch 4 Build 672

FortiDB:

• 3.2.2 Build 18

Contribute to Firewall Guru

Do you have a knack for writing helpful tips and tricks with a specific focus on anything Fortinet? Are you looking to share your creative outlet with the rest of the Fortinet community?
Why not contribute to Firewall Guru? It's fun and free and other people get to rub off on your smartness :)

Contact sebastiankt@ymail.com if you are interested in becoming a contributing author.

Problems with UDP streams and STUN - Follow Up

Ok, Fortinet has found and resolved the problem. The fix should be in 3.0 MR7 Patch 6 which is tentatively scheduled for sometime in June. Here is a link to the original problem description.

When LiveMeeting initiates a video session it uses STUN. However STUN is generally used in the initial stages of communication to determine the external IP address of an internal client. Then some random ports are opened for the data stream.
Microsoft however uses STUN throughout the entire LiveMeeting video session to not only determine the external IP of your client but to also pass the data stream.
The IPS feature of the firewall was killing the STUN data stream because it was open "too long" since the IPS was not expecting STUN to be used to pass the actual data. Of course the next STUN packet from the internal client would open another outbound port but with a different externally mapped source port which in turn breaks the video stream.

As I mentioned this has been fixed and the branch build we have from Fortinet works like a champ. Thanks Bryan and team. Great job up there in Vancouver for getting to the bottom of this so quickly :)