Suggestions for initial FortiGate lockdown?

[tanr]

Hi All,

I'm configuring of a couple FortiGates (100D and 300D running 5.4.1) at two locations, with an always on IPSec VPN connection.

Main location with the 300D also has a FortiAuthenticator, FortiAnalyzer (in a VM), and FortiAP.  The remote location with the 100D will access the FAC and send some logs to the FAZ over the VPN.  Lots of vlans at both locations.  Both sites will also allow somewhat restricted IPSec VPN connections from other locations.  This is a move from an existing, functioning system.

I've been scanning the forums, reading the cookbook articles, and (re)reading the manuals as I set things up, and gleaning a lot of information, but one thing I haven't found is a collection of notes on doing an initial lockdown of a FortiGate (or FortiAuthenticator, or FortiAP).  

I've found many separate notes on the basics.  

For example: New super user to replace admin, default deny rule, turning off Administrative Access for any ports that should have it and limiting admin to specific devices, limiting failed auth attempts, using your own certificate, using local NTP, doing DNS checks, using FortiToken mobile OTP, opening TCP 113, using match-vip enable for some cases, NAT, general limiting of ports and protocols, etc.

Is there a general collection of all these sort of initial setup details for FortiGates in one place?

Anything that delves into more detail, such as using config firewall local-in-policy to further lock things down?

Any collection of "reasonable" profiles for Web Filter, DNS filter, and IPS for Windows and Mac clients for lan-to-wan?  (I know -- it depends.)

If there aren't any such collections, I could always post the information I've collected so far to get people's feedback on it.

Thanks.

[ede_pfau]

Or maybe the other way around: one thing that I consider "best practice" is to deny outgoing DNS. The only reliable DNS in the network is the FGT itself, with or without internal zones. The FGT in turn receives the ISP's DNS address via PPPoE, DHCP or statically so that I can trust it not being a rogue DNS.

This of course will lead to additional support calls and log entries about connection attempts to 8.8.8.8. My point of view is that this is a misconfiguration on the client which needs intervention (my network - my servers). In the sake of security.

If you absolutely have to allow outbound DNS then use an appcontrol sensor to detect non-DNS traffic on port udp/53. Nowadays often used for tunneling over DNS. The downside of this is that Avast uses the DNS port to tunnel it's "secure updates" to the clients, so the AppControl needs an exemption list of their servers. Clearly worse than just denying any DNS outbound.

[tanr]

Good point.  Blocking outbound DNS, and only allowing clients to use the FGT for DNS sounds like an effective and reasonable method.

I assume that rather than setting each interface's DNS Server to be "Same as System DNS" it would be better to set each interface's DNS Server to "Same as Interface IP" and create a new DNS server on each lan interface that just forwards to the FGT's DNS servers.  Any real perf hit or other concern with doing this?

[ede_pfau]

No, that's perfect. "Same as System DNS" would require an outbound DNS policy from every internal interface which would defeat the purpose. I haven't noticed any performance hits or raised latency for clients with this. I'd do it this way anyways, security comes first.

[tanr]

Took me a bit to realise that since I'm using the FGT's internal DNS Database to map some names to local IP's, each of those "DNS Service on Interface" entries (for the lan side interfaces) has to be set to "Recursive", rather than "Forward to System DNS".

On to local-in-policy, way to many printer services, and the rest of the lock down.