Year End Software Updates

Here's all the latest and greatest. Based on my experience using this on production equipment the upgrades have resolved a number of significant bugs.

FortiAnalyzer

• 4.0 MR1 Patch 2, Build 128

FortiClient

• 4.0 MR1 Patch 2, Build 138

FortiManager

• 4.0 MR1 Patch 2, Build 221

FortiOS

• 4.0 GA Patch 4, Build 113
  

Also, if anyone uses FortiClient, FortiDB or FortiWeb on a regular basis do post a comment if you are interested in contributing articles about these products.

Bugs in FortiManager 4.1 MR1 Patch 1

When attempting to apply a script to a group of firewalls the following error message is received:

"error: failed to create task for executing script"

Fortinet came back with bug ID 112165 - B214:Failed to execute script on device group
Fixed in next release patch 4.1.2 early December.

CLI Magic: Renaming Existing Interfaces

If you ever run into a situation where you have configured a VLAN interface on a Fortigate firewall and the purpose of the VLAN changes you might have to rename it. The GUI will not let you rename an existing VLAN interface. However there are workarounds, ranging from very impacting to transparent:

• Remove the VLAN interface and create a new one with the updated name. This method incurs downtime since you first have to remove any rules, routing, etc that reference the VLAN.

• Download the firewall config, rename the interface in the backup file and restore the config. This will reboot the firewall and also impact user traffic.

The fastest, easiest and least impacting method is:

• #config system interface
• #rename "VLAN Name" to "New VLAN Name"
• #end

Software Updates

FortiMail

• 4.0 GA, Build 91
  

FortiOS - Application Control Logging Gotcha

FYI,

if you are using FortiOS 4.x and a Fortimanager. When configuring application control on your FortiGate units you have the option to "Enable logging for undefined applications". Another possibility is to create a rule something like this:

• Category: All
• Application: All
• Action: Pass
• Log: Enable

I have found that creating a rule to log undefined applications can cause problems. When you use this second method rather than checking the "Enable logging ..." box the Fortigates will send an SNMP trap for EVERY detected application to the FortiManager. This leads to the SNMP daemon process on the FM using up all available memory and eventually crashing the FM box completely.

Fortinet is currently investigating this behaviour.

Firmware Update via USB Stick

Recently I performed a software upgrade on a Fortinet Active/Passive Cluster. The primary firewall took the upgrade ok but the secondary unit got hung up. When I rebooted the secondary unit it had remained at the old firmware version. I did not have a working USB-to-Serial converter available so was unable to perform a CLI tftp upgrade of the secondary unit. Here is how I used a USB stick to upgrade the secondary unit:

• Format a USB stick using FAT16. This works best on a PC. The CLI USB commands on the firewall did not work for me very reliably.
• "format : /FS:FAT /V:" where Label is a short text string to name the drive. So for example "format e: /fs:fat /v:usbdrive"
• Copy the appropriate firmware to the USB stick as "image.out".
• Insert USB stick into firewall you want to upgrade and reboot the firewall
• After several minutes the firewall will reboot again. Remove the USB at the beginning of this reboot.

Voila, your firewall should now be upgraded to the firmware on the USB stick.

Software Updates

FortiOS:

• 3.0 MR7 Patch 7, Build 750 - Recommended for Production
  
• 4.1 Patch 1, Build 185 - Bleeding Edge so be careful

FortiClient:

• 4.1 Patch 1, Build 132

FortiManager:

• 3.0 MR7 Patch 5, Build 676
• 4.1 Patch 1, Build 214

FortiAnalyzer:

• 4.0.3, Build 50
• 4.1 Patch 1, Build 123

FortiWeb

• 3.0 MR3 Patch 1, Build 121

Software Updates

FortiMail:
3.0 MR5 Patch 3, Build 527

Software Upgrades Removed - Fortimanager

Fortimanager 4.0 MR1 has been pulled, citing issues in certain FortiManager models. The recommendation is to wait to upgrade until mid-October when a new version will be available.

Software Updates

FortiManager:
4.0 MR1, Build 206

Resetting a lost Fortigate Admin Password

If you have lost the admin password for a Fortigate you can reset it if you have physical access to the box.

Heads up: You have to type the userid and password within a 15 seconds of the login prompt first appearing. If you take too much time you should reboot the firewall again.

• Connect the console cable to the Fortigate and fire up your favorite terminal emulator

• Reboot the firewall unit.

• At the console login prompt, type in "maintainer" as the userid.

• Type in bcpbFGTxxxxxxxxxxxxx as the password. xxxxxxxxxxxxx will be the S/N of the Fortigate. The serial number is case sensitive so for example you should use FGT60B, not FGT60b. If that does NOT work try bcpbxxxxxxxxxxxxx as the password.

• After logging in, change the admin password:

config system admin
edit admin
set password
next
end

Syslog Problem in FortiAnalyzer 4.1

If you have devices reporting to your FA you might want to hold up on an upgrade to 4.1. One of the things I noticed on various FA platforms is that Syslog devices still send logs but the content of the logs appears blank in FA. Ticket with Fortinet is pending.

** Update **

Fortinet has corrected the bug and will include the fix in FortiAnalyzer 4.1.1.

** Second Update **

4.1 Patch 1 restores access to all the syslogs that were previously received

Software Updates - FortiAnalyzer 4.1 (AKA 4.0 MR1)

Log Reduction and Optimization
· WAN Optimization Reports
· System Migration
· Vulnerability Management – PCI Compliance Reports
· Vulnerability Management – Achieve CVE Compatible
· Web Clicks vs Hits Algorithm
· Custom Charts
· Quarantine and Report Extensions
· Per-VDom Quarantine
· Improved Log Rolling Mechanism
· Viewing of Real and Historical logs for multiple and mixed devices
· Support for encrypted mail protocols (SMTPs, POP3s, IMAPs) - log viewing, searches, and reports

Openswan - Host to Subnet Configuration

Sometimes you may want to have a single host running Openswan connecting to your firewall.
Here are some tips on how to configure this scenario.

• Configure Openswan using this article for guidance.

• On your host running Openswan put the following information in your connection definition:

conn office
#left side is home
left=%defaultroute
#leftsubnet is the IP of your host with a /32 bit subnetmask
leftsubnet=2.2.2.2/32
#right side is work
#set right to vpn remote gateway
right=1.2.3.4
#set rightsubnet to remote network
rightsubnet=192.168.1.0/24
keyexchange=ike
#auth=esp
#Automatically bring up VPN tunnel auto=start
auto=start
authby=secret
#specify encryption FortiGate VPN uses
esp=3des
#perfect forward secrecy (default yes)
#optionally enable compression
compress=yes

The key here is that the leftsubnet parameter is the IP address of your Openswan host.

On the Fortigate firewall configure your Phase 1 parameters with the appropriate settings.
In Phase 2 edit the Quick Mode Selectors in the "Advanced" section as follows:

Source Address: 192.168.1.0/24
Source Port: 0
Destination Address: 2.2.2.2
Destination Port: 0
Protocol: 0

This tells the firewall that on one side it is expecting the 192.168.1.0/24 network and on the remote side it is only expecting to connect to a single host, 2.2.2.2.

Site-to-Site VPN - Openswan to Fortinet

Openswan IPSec is an open source implementation of IPSec that is included in many Linux distributions. When appropriately configured, it can interoperate with FortiGate VPNs.

Global settings

The global settings for the Openswan IPSec service are found in /etc/ipsec.conf. Unless you are certain that you don't need NAT traversal, ensure that the following line appears in ipsec.conf:

nat_traversal=yes

The line must begin with whitespace and be in the config setup section of the file.

There is also an include line that defines the name and location of your connection definition files. For example,

include /etc/ipsec.d/*.conf

Put your definition file in this location with an appropriate name.

Connection definition

You need a connection definition for each remote network you want to access.

An Openswan connection definition does not use the terms "source" or "destination". Instead, you define the two ends of the VPN as "left" and "right". The software determines for itself which definition applies to its end of the tunnel.

Example -- /etc/ipsec.d/office.conf

conn office
#left side is home
left=%defaultroute
#right side is work
#set right to vpn remote gateway
right=1.2.3.4
#set rightsubnet to remote network
rightsubnet=192.168.1.0/24
keyexchange=ike
#auth=esp
#Automatically bring up VPN tunnel auto=start
auto=start
authby=secret
#specify encryption FortiGate VPN uses
esp=3des
#perfect forward secrecy (default yes)
#optionally enable compression
compress=yes

For more information, see the ipsec.conf man page.

Secrets file for preshared keys

If you use a preshared key for authentication, you need to specify the key for the connection. Check the /etc/ipsec.secrets file. Typically this contains an include statement that defines the location and naming for the file, for example:

include /etc/ipsec.d/*.secrets

Put your definition file in this location with an appropriate name, typically ipsec.secrets. This file contains sensitive information, so it should be accessible only to the root user.

Entries in the secrets file should take either one of these two forms:

1.2.3.4 : PSK "pre_shared_key" # specify remote gateway only if your host's IP address is dynamic
2.2.2.2 1.2.3.4 : PSK "pre_shared_key" # specify remote and local IPs

(2.2.2.2 is the local address, 1.2.3.4 is the remote gateway you are connecting to)

The definition that specifies only the remote gateway address does not always work. You might get an error message that no PSK was found for your connection. The definition that specifies both local and remote gateway addresses is useful only if you have a fixed local IP address.

Starting the IPSec service

Typically, the IPSec service is configured to start at boot-up. If you are not sure that it is running, enter the following command as root:

/sbin/service ipsec restart

The startup messages will show if there are problems with the installation or syntactic problems with your configuration files.

Starting and stopping the VPN

If you used the auto=start option in your connection definition, the VPN is established when the IPSec service starts. Otherwise, you need to use the ipsec command to start and stop the vpn.

You might need to use the whereis command to locate the ipsec command unless it is on the command path. /usr/sbin is a typical location.

In these examples, the connection is called office.

To start the VPN

/usr/sbin/ipsec auto --add office
/usr/sbin/ipsec auto --up office

To view VPN status

/usr/sbin/ipsec auto --status

To stop the VPN

/usr/sbin/ipsec auto --down office
/usr/sbin/ipsec auto --delete office

(Using information from Fortinet Knowledgebase Article at http://kc.forticare.com/default.asp?id=1835&Lang=1&SID)

Software Updates - FortiOS 4.1 (AKA FortiOS 4.0 MR1)

· Supports Log Storage in SQL Format
· Supports IKEv2
· Supports Multiple FortiAnalyzer and/or Syslog Devices Per-VDom
· Supports IPv6 Dynamic Routing
· Introduction of Per-VDom Dashboard
· SNMPv3 Encryption & Authentication
· Supports Enhanced DHCP over IPSec as IKE Configuration Method
· Enhanced DNS Server
· Introduction of Strict Password Options
· Safe Search Feature for Web Filtering
· IPv6 Extensions
· DLP International Character Sets
· Web Content Block/Exempt List Merge
· Schedule Groups
· Traffic Shaping Extensions
· Support for Replacement Message Groups
· SSL-VPN Enhancements
· Supports Reliable Syslog
· Supports Multiple Schedule Objects per Firewall Policy
· LDAP Authentication Improvements
· Enhanced Application Control Statistics
· Supports IPv6 AV scanning and Management Access
· Supports Reporting based on SQL Logs
· Supports Cookie-based Overrides on FortiCarrier Platforms
· Supports SIP over IPv6
· DLP Archive
· SIP Enhancements
· Log Reduction & Optimization
· Supports Wireless Controller
· Easy FortiCare and FortiGuard Services Registration and Renewal
· Endpoint Control Enhancements
· Supports Per-VDom Replacement Messages
· Alert Message Console Enhancements
· Interface Status Detection for Gateway Load Balancing
· Dynamic Profile Enhancements for FortiCarrier Platforms

Software Updates

Current Updates

FortiDB:
3.2.3, Build 21

FortiMail:
3.0 MR5 Patch 2, Build 522

Got DoS? ERP and Fortinet Anti-Virus Scanning Problems

I ran into a situation where a customer utilized an embedded Telnet/Web application to their ERP vendor. Using Cacti to monitor bandwidth, we noticed their connection was completely saturated. Everything pointed to INBOUND traffic. First impression was that we are getting hit by a Denial of Service attack. This went on for a couple of days. After working with Fortinet’s support, we determined the issue was our “Oversized File/Email Threshold (1 - 139 MB)” setting specifically in one of our Protection Profiles. It was set to 5MB; however, the default is 10MB. Apparently, the application during the 5MB scanning phase was not receiving a TCP ACK within an adequate amount of time, therefore, would resend the data, hence DoS. We lowered the “Oversized File/Email Threshold (1 - 139 MB)” to 2MB with immediate resolution. Although not malicious, this was a true DoS experience and seems to be more common than not especially with streaming services.

(Article by Joseph Finley)

CLI Magic: Finding out where your Objects are used in the Config

A firewall setup may get quite involved with many complex settings and user additions such as addresses and protection profiles. Sometimes you are desperately looking to delete an old unused object but that darn trash can icon just won't show up. Fortunately the FortiOS CLI includes a command to allow you to find all places where an object is used.

From the CLI, enter the following command:

diagnose sys path.object.mkey

This will return all objects where the specified object key is referenced.

For example:

diagnose sys checkused sytem.interface.name dmz

entry used by table system.interface:name 'vlan1‘

** If someone out there knows of a place where Fortinet lists all the object references please post a comment and I will update this article **

Software Updates

Current Updates

FortiOS:
3.0 MR7 Patch 6, Build 744

FortiOS, Sonos Network Music Players and Pandora

If you happen to own one of these cool things (http://www.sonos.com) and you listen to music via their Pandora plugin you might experience some problems with firewall protection profiles in FortiOS 4.x. After upgrading to the latest beta version of 4.1 I was unable to play Pandora music any longer. Playing with the protection profiles I noticed that you have to ensure that under Firewall -> Protection Profile -> Anti-Virus the "Comfort Clients" option is enabled. Pandora receives music via port 80. Apparently the firewall tries to scan the music stream for viruses which causes the Sonos Pandora plugin to timeout.

Combining Firewall Interfaces

Sometimes there is a need to combine multiple firewall interfaces to function like a switch or hub (for those of us who remember what a hub is :). A good example would be the internal interface of a FortiWifi and the WLAN interface. If your firewall is in NAT mode you have to assign separate IP addresses in different subnets to each interface.

Now let's assume you have some kind of device on your network like a Sonos music player. Your laptop is on the wireless network provided by the FortiWifi and the Sonos is on the wired net. Even if you have rules permitting all traffic between your wired and wireless network you will not be able to connect to your Sonos player. This is because the Sonos is detected via broadcasts that stay local to each subnet. The same principle is used for Slingboxes and other devices.

The answer is to combine the WLAN and internal interfaces into a new "switch" interface. This can be done from the command line. As a prerequisite you must not have anything referecing the interfaces you wish to combine, such as firewall policies, routes, etc. Also you have to be running at least FortiOS 3.0 MR6. Here's an example of how to set it up:

** Important: You should enable https or ssh access to some other interface other than the ones you are combining. When you combine the internal interface with another one you will loose connectivity to the internal interface until you access the firewall either via the console or another interface and configure an IP on the newly create interface. (Thanks for the heads up Simon). **

config system switch-interface
edit Lan
set member internal wlan
end

You now have a new interface in the GUI called Lan which you can use to create policies with and combines the internal and wlan interfaces. Any traffic between the two interfaces will always be allowed, including broadcasts, since they are now part of the same "switching zone".
There are a number of other options for this command. For more information go ahead and check out the FortiOS CLI reference at http://docs.forticare.com

** It appears that combining interfaces using this "software switch" causes problems with various forms of spanning tree (STP) **

Software Updates

Current Updates

FortiAnalyzer:
4.0.3, Build 50

Software Updates

Current Updates

FortiOS:
4.0.3, Build 106
(I had been anxiously awaiting this one but still managed to leave it off the list, so thanks Guzik for reminding me ;)

FortiAnalyzer:
3.0 MR 7 Patch 5, Build 733

FortiMail:
3.0 MR5 Patch 1, Build 517

FortiWeb:
3.22, Build 98

Extended Ping in FortiOS CLI

Many of you Cisco throwbacks know how an extended ping can save your bacon. There are times when you need to test your ping from various source interfaces to verify reachable networks for instance to bring up IPSEC tunnel policies. Using an extended PING in Cisco was your friend and Fortinet also has the ability to do this.

Internal: 192.168.42.1
DMZ: 192.168.100.1
WAN1: 10.10.100.254
Customer Side Network: 172.15.30.1


# exec ping-options source 192.168.100.1
(The interface IP you want to source from - in this case the DMZ interface)

# exec ping 172.15.30.1

Pings to 172.15.30.1 on the customer side network will now originate from the DMZ interface.

(Article by Joseph Finley)

Software Updates

Current Updates

FortiManager:
4.0.2, Build 102

FortiWeb:
3.20, Build 94

Software Updates

Current Updates

FortiClient:

• 4.0.2, Build 57
  

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 :)

Software Updates

Current Updates:

FortiOS:

• 3.0 MR7 Patch 5, Build 741

FortiManager:

• 4.0.1, Build 89

FortiAnalyzer:

• 4.0.2, Build 45

New FortiGate Hardware

Fortinet has released the FortiGate 51B and FortiGate 111C platforms. While on paper the specs are very similar to the FG50B and FG 110C respectively the new units have onboard flash storage for local logging and also support the WAN optimization feature. WAN optimization is a new feature introduced in FortiOS 4.0.

Software Updates - Now Bi-weekly

Going forward I will post software updates twice a month, around the 15th and the 30th or so to accumulate all software updates that occur over those two week periods.

Current Updates:

FortiOS:

• 3.0 MR7 Patch 4, Build 740
• 4.0.2, Build 99 (Note the new revision naming conventions)

FortiMail:

• 3.0 MR4 Patch 5, Build 438

FortiClient:

• 4.0.1, Build 52

FortiDB:

• 3.2.1, Build 17

FortiAnalyzer Funkiness

When you configure your FortiAnalyzer and you have firewalls reporting to it that are not in the same subnet, make sure you configure the correct default gateway under "System -> Network -> Routing". This might seem pretty obvious but has caught me off guard a couple of times.

Fortigate firewalls use UDP port 514 (a connectionless protocol) to send log data to the FortiAnalyzer. The FA can receive those logs without knowing how to route back to the firewalls, therefore the correct default gateway is not required.
In addition the firewalls also use TCP port 514 (a protocol requiring a three-way handshake). If the correct default gateway is not set on the FA strange things happen. With a large number of reporting devices some will show up under "Device -> All", some will not. In our most recent incarnation after rolling out a new FA we had about half our firewalls listed, the other systems were attempting to connect but could not.

So, if you are missing firewall devices after a new FA rollout or rebuild make sure you verify that default gateway setting.

FortiScan 1000B

Today, Fortinet announced the release of its newest platform, the FortiScan 1000B. The FortiScan is a Unified Threat Management system. Stay tuned for a review. More information can be found here:
http://www.fortinet.com/press_releases/090406.html

FortiOS 4 Device Support

Fortinet has released FortiOS 4.0.1 which has added support for an extended set of firewall hardware such as Fortigate 60, 100, 200, 400, etc.

** Update **

FortiOS 4.0.1 has been removed from the support site as of April 06. Looks like some interim builds made their way into the release somehow.

** Update #2 **

There was a major issue with IPSEC aggressive mode tunnels. This has been fixed in 4.0.2 which has now been released.

Problems with UDP streams and STUN

I recently came across a problem with longer lasting UDP sessions that use STUN for NAT traversal. More specifically when using a Microsoft LiveMeeting session to share real time video.

The client PC initiates a connection to the Microsoft servers and starts sending UDP data to which the Microsoft servers respond. The response packets contain other users' video or if you are in the conference by yourself your own video. NAT traffic through the firewall looks something like this in a packet capture:

• Before reaching the firewall
  
• Client Source IP, UDP Source Port, STUN Destination Port (e.g. 192.168.1.100, Source Port 43000, Destination Port 3478)
• After passing through the firewall
• NAT Source IP, UDP translated Source Port, STUN Destination Port (e.g. 100.100.100.1, Source Port 56565, Destination Port 3478)

In this example the firewall translates the source IP and source port in a PAT or many-to-one NAT situation.
After about 7 minutes the firewall all of a sudden changes the translated Source Port, for example 56565 becomes 61616. The original source port on the client however has not changed. Therefore the destination server on the far end no longer sees the correct UDP source port and after several seconds ends the connection due to lack of UDP data. This behaviour has been confirmed in FortiOS 3.0 MR7. In further testing I found that FortiOS 4.0 does not exhibit this behaviour.

The temporary workaround is to use static NAT where possible. Static NAT uses a one-to-one relationship between the original and translated source port and IP addresses. Therefore no translation is done on any ports, only the source IP, and the connection stays alive.

** Update from Fortinet **

Fortinet has identified two bugs which have been fixed in FortiOS 4.0. The bugs are "Port changed in SIP header" and "SDP contact not modified correctly". There are currently no plans to resolve this in 3.0 MR7.

Internet Malware - Anatomy of a Forensic Investigation

I wanted to take a second and write down some notes on a recent malicious code attack and how Fortinet was able to help stamp out the culprit.

I first noticed some irregular activity when doing some routine reviews of our Cacti monitoring system. In a previous post I described how to monitor firewall statistics such as CPU, session counters and interface traffic with Cacti. One of our low volume web servers all of a sudden spiked to several thousand active sessions which is highly unusual.


Upon further investigation using our FortiAnalyzer I determined that the server was trying to access a particular website at a rapid pace.


Initially it looked like the server was participating in a denial of service attack. I dug a little deeper and manually connected to port 8080 on the destination server and was greeted with the following message:

:irc.dvast8.us NOTICE AUTH :*** Looking up your hostname...
:irc.dvast8.us NOTICE AUTH :*** Found your hostname
:irc.dvast8.us 451 GET :You have not registered
:irc.dvast8.us 451 Host: :You have not registered
:irc.dvast8.us 451 User-Agent: :You have not registered
:irc.dvast8.us 451 Accept: :You have not registered
:irc.dvast8.us 451 Accept-Language: :You have not registered
:irc.dvast8.us 451 Accept-Encoding: :You have not registered
:irc.dvast8.us 451 Accept-Charset: :You have not registered
:irc.dvast8.us 451 Keep-Alive: :You have not registered
:irc.dvast8.us 451 Connection: :You have not registered

irc.dvast8.us (devastate, they are so clever :) seemed a weird place for my system to connect to, further confirming my suspicions about bad things going on. Since I did not yet know why this machine was behaving strangely I installed various Linux rootkit detection systems to see if the machine had actually been penetrated. However all the systems came up blank.

As a next step I reviewed my FortiAnalyzer IDP attack logs but nothing there either even though I had cranked up the IDP settings to full force by enabling all signatures and setting them to log and block bad traffic.

Next I turned up Content Archiving to see what my system was accessing and more importantly what was being accessed on my server. By this point I was leaning in the direction that somewhere on the webserver I had a vulnerable script with a buffer overflow or similar exploit.
After sitting back and watching for a while I saw my server accessing an odd text file on a server in China. I attempted to download the text file to a machine specifically configured for forensics and found a nasty little script which opens various backdoors on an infected machine. My PC's anti-virus actually picked it up and quarantined it which means it made its way through the firewall's anti-virus scanners without the Fortinet picking it up.


An additional tool I installed on the server was OSSEC. OSSEC is an open source host intrusion detection system. Installing it was very straightforward and later the same evening I got the first alert via email. The server was attempting to download and save the file from the server in China again but failed due to the limited permissions of the web server process.
I then went back to the logs to see if I could find out what was triggering the download attempts. And sure enough just before my server went active there was a POST operation to a PHP script on the box. I immediately modified my firewall policies to deny all traffic to and from the machine to prevent any further exploit of the script.


I googled the php script that was being accessed and wouldn't you know it the developers had issued a security alert for a code injection vulnerability that I had missed. Obviously the safest thing to do was to entirely remove the application since it was only used for a proof-of-concept and then discontinued. I then re-enabled access for the server at the firewall level.

Follow-Up with Fortinet

To enhance security for other systems protected by Fortinet firewalls I went ahead and submitted the different pieces of the above investigation to Fortinet for dissemination:

• Online Virus Sample Submission at FortiGuard Center - Since the firewall anti-virus scanners did not pick up the malicious script file I sent in a copy
• Report an Exploit/Vulnerability - Since the firewall IDP did not detect the code injection vulnerability in the PHP script I sent the team a URL describing the vulnerability
• Submit a URL for WebFiltering - The FortiGuard WebFilter did not have the site in China rated as hosting malware.

I was very happy to see that within six hours I had received responses to all my requests. The virus is now being detected by a signature in the Fortinet A/V, the IDP signature will be able to block the code injection as soon as Fortinet releases their new signatures and the URL has now been rated as a malware hosting site. The obvious benefit here is that anyone else around the world using FortiGuard services will be able to profit from this experience.

Software Updates

Fortinet has release the following software updates:

FortiAnalyzer: 4.0 GA, Build 36
FortiAnalyzer: 3.0 MR 7, Patch 4, Build 729

Please note that Fortinet has discontinued support for the FortiAnalyzer 100 and 100A platforms in the 4.0 software releases.

FortiClient: 4.0 GA, Build 47

FortiMail: 3.0 MR4 Patch 4, Build 432

FortiManager: 4.0 GA, Build 76

Please note that only the following FortiManager platforms are supported

• FortiManager100
• FortiManager400A
• FortiManager400B
• FortiManager3000
• FortiManager3000B
  

I have confirmed with our Fortinet rep that the FortiManager 400 will not be supported in version 4.0. You can contact sales@sactechgroup.com if you are interested in upgrading. (No, I don't work there :)

Fortinet and Cisco MARS Integration - Part II

If you haven't already please read Part I of the Fortinet with Cisco MARS integration. This post talks about configuring additional custom parsers for MARS as well as using the Keyword field in MARS for freeform syslog text matching. In the following example I will describe how to detect administrative login failures for SSH and HTTPS access to a Fortigate unit.

In your MARS Global Controller or standalone Local Controller perform the following steps:

• Click Admin -> Custom Setup (tab at the top) -> User Defined Log Parser Templates
• Under Vendor select Fortinet and click Edit, then click Next
• Add a new Device Event ID by clicking Add and Add again on the next screen
• Fill out the following fields: Event ID=Event Log, Description=Event Log, Severity=Green
• In the Event Type Group section select Info/Misc from the right hand side and click on the Add button with the double left arrow. Then click Submit.
• On the next page in the Choose Event Type From section select the newly created Event Log's radio button and click the double arrow to the left. At the top of the page enter Event Log in the Device Event ID and Description fields. Then click Apply on the bottom right of the page.
• The Patterns link at the top of the page now becomes available, click there and add the following patterns:

1. Position= 1, Key pattern: date\=, Parsed Field=Device Time, Value Type=Time, Pattern Name=%Y-%m-%d time=%H:%M:%S, Value Format=%Y-%m-%d time=%H:%M:%S, Value Pattern=\d{4}-\d{1,2}-\d{1,2} time=\d{1,2}:\d{1,2}:\d{1,2}
2. Position=2, Key pattern=.+user\=\", Parsed Field=Reported user, Value Type=String, Pattern Name=STRING_WORD_QUOTES, Value Pattern=\w+
3. Position=3, Key pattern=.+ui\=, Parsed Field=Workstation Name, Value Type=String, Pattern Name=STRING_SERVICE_IP (enter this in the Or enter new field), Value Pattern=\S+ (notice that the S must be capitalized)
   

• When you are done defining the three patterns click Submit on the Patterns for Device ID: Event Log page, the Done on the next page.
• Now click on the Rules tab at the top of the page and click Add to add a new rule. Give the rule a descriptive name and description and click Next
• Define applicable zones or leave blank to apply this rule to all zones. Click Next
  
• Set Source IP, Destination IP, Service Name, Event, Device and Reported User to Any
• Leave the IPS Risk and Threat rating at default and click Next
• Set Keyword to action=login status=failed and click Next
  
• Leave Severity at Any and for Counts enter the amount of failed logins the firewall must report before triggering the rule, for example 5.
  
• Click Yes on the next page to finish defining the rule conditions
  
• Select the appropriate action to perform when the rule is triggered
• Set the time range to 10 minutes or another appropriate value. This will trigger the rule if any firewall reports 5 failed login attempts within a 10 minute period for example
  
• On the Rule Summary page click Submit
• Activate the changes

To enhance security you can add additional conditions to the rule, such as adding another statement looking for action=login status=failed in the keyword section. This rule would trigger on attempts to log into the firewall which fail followed by a successful login. This could indicate a successfull brute password attack.