Firewall deployments can be characterised by episodes of intense activity interspersed with long periods of “I assume it’s working ok”. However, between the cutover and Business as Usual (BAU) transition the long term feed and watering some aspects of Firewall maintenance are often overlooked. Nailing down your FortiGate fleet’s interaction with the FortiGuard Distribution Network (FDN) is such a task.
Enabling your FortiGate estate to dial home to the FDN is an important, but simple step towards firewall deployment finalization. Most Fortinet products are configured to use our public DNS and NTP servers from the factory. Once the FortiGate can reach its default gateway, it will retrieve licenses, support status, and updates for the AV/IPS database from the FDN. For many deployments, no special effort is required.
The hands off approach is fine when dealing with a few branch-office FortiGates. However, if you have dozens of branches, or are dealing with datacentre class devices then it’s worth reviewing your FortiGuard update and distribution philosophy. Essentially, a decision needs to be made on whether to centralise or localise your updates.
Thinking about the branch
Branch firewalls tend to have a handful of LAN-side interfaces, and one, maybe two WAN connections in a single VDOM. If your WAN interface is Internet connected, letting the FortiGate feed and water itself is probably a good idea. However, if your branches are connected to private MPLS circuits or even satellite links, then centralisation would provide more control.
FortiManager (FMG) can act a FortiGuard distribution point for your entire Fortinet fleet. This allows the administrator to set a central download policy and distribute to many devices at once. In distributed branch scenarios, this makes a lot of sense. It gives the administrator control over the cadence of the updates, and prevents them from being pushed many times across an expensive or contended WAN.
The update cadence should be considered in the context of your desktop protection policy. Many security vendors, Fortinet included, are moving to hourly signature updates. Whatever you choose, ensure the time windows for gateway and desktop AV are complementary. If the desktop AV and gateway update every 24 or more hours, the window for bad stuff to get through may be uncomfortably large.
Configuring the FortiGate
To configure the FortiGate, a little bit of CLI is required. This can of course be pushed from the FMG via a script, but for the first time you’ll want to test it manually.
You’ll need to be in config global if you have VDOMs enabled.
config system central-management
set type fortimanager
set fmg "172.16.1.184" <-IP address of FMG server
set server-type update rating <- Type to fetch
set server-address 172.17.16.180 <- FMG IP address
set include-default-servers disable <-Avoid public FDN
The config server-list specifies the local FMG servers that you wish to use as distribution points. In most cases you will only have one, but you could specify a backup. This adds your local FortiManager instance(s) to the local list of public FortiGuard servers. To prevent the FortiGate from contacting external servers you’ll need to set include-default-servers to disable.
Whilst you are at it, you’ll probably want to turn on automatic updates. Again this is set globally.
config system autoupdate schedule
set status enable
set frequency every
set time 01:60
In this example, with set time set to 01:60 the FortiGate will dial home every (01) hour, but will randomly select the specific minute (:60). If you have a large estate, this is an elegant way of making sure that the FortiManager isn’t hammered on the hour, every hour.
You can check the current status with this command, and it will show what time updates will be pulled.
FG600B-4 # get system auto-update status
FDN availability: available at Wed Sep 23 11:20:06 2015
Push update: disable
Scheduled update: enable
Update every: 1 hours at 20 minutes after the hour <- “20” randomly selected
Virus definitions update: enable
IPS definitions update: enable
Push address override: disable
Web proxy tunneling: disable
In the DC
In datacentre class firewalls (a misnomer if there ever was one; I’ve seen gigabits of unused capacity in branches, and “branch” devices thrashed within an inch of their lives in datacentres) priorities differ. DC devices may have many interfaces and separate control and forwarding VDOMs. When the firewall dials home to the FDN, the connection is initiated from the designated management VDOM (root, by default). Many DC environments will not have a route to the Internet from the management/root VDOM. Whilst it is possible to “cheat” and introduce an Internet connected interface to the management VDOM or an inter-vdom link, hacks like this make the security guys (understandably) twitchy. A better option is to use FortiManager as a distribution point. The FMG of course needs its own path to the Internet, but this could be via a conventional SOCKs proxy and/or via an alternate Internet connection.
There is no single best way to distribute your updates across the network. However, as a rule of thumb, independence should be the priority for devices that are spread across the world. A firewall shouldn’t miss an update just because the VPN is down or they’ve been forgotten about. For datacentre devices, it is a different story. The typical separation of management and forwarding traffic typically makes “in-band” collection of FortiGuard updates unpopular. The availability of the FortiGate-protected services is important and highly visible. As a result, the dependence upon a local FortiManager is less likely to be an issue. Given that there are really two options on how to configure FortiGuard updates on your network, there is quite a lot to think about. If you have any other scenarios you’d like to talk about, please put them in the comments below!