Friday, July 25, 2008

Scheduling Scripts in FortiManager

You can schedule scripts to execute automatically in FortiManager. Once you have created a script select a group of firewalls which you have created (the "All Fortigate" group cannot be used to schedule scripts). On the top of the screen select Script -> Create New. Select one of the available scripts and click on the Right Arrow -> button. Under Schedule set the Execute Schedule Type to Schedule and now you can select either One-Time or Recurring.

Please note that when you want to run the same script multiple times per day you have to use the following process:
  • Create your script
  • Make x number of copies of the script (x being the number of times you want to run it per day)
  • Create one schedule for each script
If you schedule the same script to run multiple times the FortiManager simply changes the time of day you had previously configured. When using copies of the same script FortiManager treats them as separate scripts and this allows you to work around this limitation.

Software

Fortinet has released 3.0 MR4 for Fortimail and 3.0 MR7 for Fortimanager. Your Fortimanager needs to be at or above the same software level as the firewalls you want to manage.

FortiManager 3.0 MR7 sports a newly revamped GUI. Also the web interface speed is extremely quick now. This was one of our biggest gripes in the past. Thanks for listening Fortinet ;)

Monday, July 21, 2008

Recommendation: Do Not Upgrade to FortiOS 3.0 MR6 Patch 2 Under Certain Conditions

If you have seen your firewall CPU utilization go to 100% and stay there my recommendation is to NOT upgrade to FortiOS 3.0 MR6 Patch 2 at this time. Where before the firewall would continually run high CPU utilization it did not appear to affect traffic. After the upgrade to MR6 Patch 2 traffic is now being impacted. The firewalls will still pass ICMP but services such as http, snmp and others are being effectively blocked. See my June post about further details and how to temporarily work around the problem.

*** Update ***

Fortinet Engineering has confirmed this as an infinite loop problem in the IPS Engine triggered by DCE/RPC type traffic. In 3.0 MR5 the impact was not noticeable. In 3.0 MR6 the IPS engine has a higher priority which is why traffic is now affected.

** Update to the previous Update **

Fortinet Engineering has fixed the issue. The new IDS package 1.097 should take care of it.

Friday, July 18, 2008

Software Updates

Fortinet today released FortiOS 3.0 MR7.

Deny Rules are counter intuitive in 3.0 MR6

Say you want to block traffic from a known bad IP on the Internet to all systems on your DMZ. All machines in the DMZ are natted to the outside world using Virtual IPs. Generally you would expect to create a rule like this:

From: External, IP address of bad external system
To: DMZ, Any
Action: Deny

In 3.0 MR6 (and potentially other versions) this does not work. You have to block traffic to specific NAT addresses. The fastest way to do this is to create a VIP Group under Firewall -> Virtual IP -> VIP Group and add all your natted addresses to the group, let's call it "All NAT" for example. You would then build the following rule:

From: External, IP address of bad external system
To: DMZ, "All NAT"
Action: Deny

As per the official response from Fortinet this is working as designed and is not a bug.

Wednesday, July 16, 2008

Packet Capture for non-Admin Users

Any user on the Fortigate platform used to be able to capture traffic on the ANY interface using

diag sniffer packet any

In FortiOS 3.0 MR6 Fortinet has imposed some restrictions. The admin user can still utilize this syntax. However any non-admin user must now specify an interface to capture traffic on as in the following examples.

diag sniffer packet wan1
diag sniffer packet internal

Trying to capture traffic using the ANY interface results in the following error if you are not the admin user:

diag sniffer packet any
No permission to sniff on interface any
Command fail. Return code -37

Tuesday, July 15, 2008

Fortimail - A Basic Setup

The Fortimail appliance is a great tool for combatting spam. Here is a basic setup that will eliminate most spam even without the latest and greatest anti-spam updates from Fortinet.

  • Configure the domains you want to receive email for under Mail Settings -> Domains
  • Enable Verify Recipient Address. If your mail server responds to unknown recipients with a "User not found" message you can utilize the Use SMTP Server option. If your mail server discards invalid recipient addresses without notifying the sender you have the alternative of defining an LDAP server which lists all valid email accounts. The setup of an LDAP server is beyond the scope of this introduction. The advantage of verifying the recipient address is that anti-spam tests don't ever need to be performed on invalid addresses and invalid emails can be quickly discarded this way.
  • Under Profile - Antispam click the copy button next to the antispam_basic_predefined_medium profile to create a copy. Name it something like medium_strength_profile. This process creates a copy of the default system scan profile which you can edit.
Enable the following options in your scan profile
  • FortiGuard-Antispam scan - If you have purchased a Fortinet support contract for your Fortimail unit. You can leave Black IP scan disabled.
  • Greylist scan - This option tells every unknown sender to wait and try again later. Most spammers won't try again but any RFC compliant mail server will attempt to redeliver the mail every few hours at least. When the remote email server tries to deliver the same message again they are put on the passthrough list. This means that in the future they will not be challenged again. This is a very effective option and is highly recommended. The only slight drawback is that the initial email delivery can be delayed by a short while. Don't use greylisting if you require every email to always be delivered in real time.
  • DNSBL scan - Allows the FortiMail unit to communicate with DNSBL (DNS Block List) servers to check the IP address of the mail server that delivered the message. If a match is found, the FortiMail unit treats the message as spam. Under config you can use the defaults of bl.spamcop.net and sbl-xbl.spamhaus.org.
  • SURBL scan - Complementing the DNSBL component, which blocks messages based on spam origin, SURBL technology blocks messages that have spam hosts mentioned in message bodies. By scanning the message body, SURBL is able to determine if the message is a known spam message regardless of origin. Under config you can use the default of multi.surbl.org.
  • Heuristic scan - Allows the FortiMail unit to examine messages for patterns common to spam messages. The heuristic scores are based on rules. For example, if the email header contains "As seen on national TV!", it gets a certain score toward being likely a spam email. The heuristic rules require no administrator modification or updating. A default rule set is provided and it is updated through the FortiGuard service as needed. New rules are added and rule scores are adjusted for maximum advantage.
Using these basic settings should be pretty effective to reduce most spam. You should of course use settings that work for you but this should be a pretty good starting point.

Thursday, July 3, 2008

Asymmetric Routing through Fortigate Stateful Firewalls

Sometimes it is necessary to forward traffic through Fortigates in an asymmetric fashion. Here is one example:

Host A: 192.168.1.1 (internal firewall interface)
Syslog Host B: 10.1.1.1 (dmz firewall interface)
Syslog Host C: 172.16.1.1 (internal firewall interface)

Host A sends log information to syslog host B which resides behind the Fortinet on the DMZ interface. The firewall policy is configured to permit all traffic from the internal interface to the DMZ and vice versa. Syslog host B stores a copy of the syslog data it receives. For the purpose of redundancy or further analysis by another system it then sends a copy of the syslog packet to syslog host C.
For syslog host C to be able to correctly interpret the syslog data syslog host B "spoofs" the source IP address of the original sender when forwarding the data. In other words syslog host B sends the data to syslog host C with a source address of host A. This allows syslog host C to determine who the original sender was. The logical packet looks something like this:

Physical sender: Syslog Host B
Source IP: 192.168.1.1 (spoofed)
Destination IP: 172.16.1.1
Syslog Data

The firewall will prevent this traffic from reaching the destination. It first saw the traffic from host A to syslog host B pass from the internal to the DMZ interface and created a corresponding entry in the session table. Now the firewall sees another packet purporting to be coming from host A to syslog host C but the source is now on the DMZ and the destination is on the internal network. This violates the firewall's state tables.

In order to work around this problem you can configure the firewall to support asymmetric routing. Please be aware that by doing this you are slightly reducing the effective security level of your firewall since spoofed packets can now more easily traverse the firewall. However in some cases you might require this option.
Asymmetric routing is configured on a per virtual domain (as of FortiOS 3.0 MR5). On the command line configure the following:

config system settings
set asymroute enable
end

Wednesday, July 2, 2008

Software Updates

FortiMail 3.0 MR3 Patch 1 is now available on the Fortinet Support Website.
There is improved logging when using recipient address verification. The system will now populate the "To" field even if the recipient is invalid. This allows you to see who people are attempting to send email to.