Suggestions for initial FortiGate lockdown?

Question

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 · Answer

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.

Sign up

Login with SSO

Login to the community

Login with SSO