FortiGate: Why Series? Secure Your Device PT2 (Local-IN Configuration)

Dive into the nitty-gritty of network security with Part Two of our video series! We're ditching the trusted hosts and stepping up our game by securing administrative access to the management plane with a Local-In policy-CLI style.
No fluff, just a straightforward walkthrough that impacts HTTPS, SSH, PING, API, VPN Traffic, and more. I'll guide you through the process using two Windows jumpboxes so you can see the access changes in action.
But, a word of caution: this isn't your run-of-the-mill tutorial. The changes we make can have a serious impact, so proceed with caution. This method is known to patch various exploits, making it a valuable addition to your network security toolkit. Tune in and level up your security game.
// Configuration Example (You will need to amend to your environment//
config firewall address
edit "10.88.88.0/24"
set subnet 10.88.88.0 255.255.255.0
next
edit "10.90.90.0/24"
set subnet 10.90.90.0 255.255.255.0
next
end
config firewall addrgrp
edit "Src-Local-In-GRP"
set member "10.88.88.0/24" "10.90.90.0/24"
next
end
config firewall service group
edit "Local-In"
set member "HTTPS" "PING" "SSH" "SSLVPN"
config firewall local-in-policy
edit 1
set uuid 3062ed1e-83bb-51ee-2882-00a778dd3033
set intf "wan1"
set srcaddr "Src-Local-In-GRP"
set srcaddr-negate disable
set dstaddr "all"
set dstaddr-negate disable
set action accept
set service "Local-In"
set service-negate disable
set schedule "always"
set status enable
set virtual-patch disable
set comments "Admin-Access-Local-In-Policy"
next
edit 2
set uuid ed4a50a2-83bb-51ee-87cd-360801789f39
set intf "wan1"
set srcaddr "all"
set srcaddr-negate disable
set dstaddr "all"
set dstaddr-negate disable
set action deny
set service "ALL"
set service-negate disable
set schedule "always"
set status enable
set comments "local-in-implicit-deny"
next
end
// Timestamps //
00:00 - Video Introduction Local-In
00:45 - Lab toplogoy overview
01:23 - Removing Trusted Host Configuration
01:46 - Validating the impact via two jump boxes
02:02 - Validating that SSL-VPN is currently working
02:34 - Applying Local-In Policy (Example config below)
03:10 - Re-Validating the impact via two jump boxes (Post Config)
03:38 - Why is SSL VPN no longer working?
04:00 - Fixing the Local-In policy SSL VPN works
04:45 - Video summary + Little Trick!
// Chris SOCIAL //
/ chris-eddisford-5b676462
// Keywords //
Fortinet
Fortinet Training
Fortinet Remote Access
Fortinet Home Worker
Secure FortiGate
Hardening FortiGate
Fortgate admin access
FortiGate
FortiGate How To?
Fortinet NSE4
Fortinet FCP
// HashTags //
#cybersecurity
#networking
#fortinet

[@Maydaymayday84]

I like the newer content. Stop saying “um”. Here to support you!

[@FortiBytes]

Thank you! I will take that feedback onboard.

[@jimjam6624]

Great channel…couple of video ideas
Demo of inter vdom routing
FGSP

[@FortiBytes]

Thank you very much, both added to the list. Inter-VDOM soon as I want to show what a good segmented device looks like to follow on from the vdom video.

[@MitchBowman93]

Is there any reason that local in is the preferred method? Or is it just because it gives you the ability to control access via address and service groups like it was normal firewall policy?

[@FortiBytes]

Hi Mitch yes that is correct for example adding geo locations and tieing into a threat feed that kind of things, it also protects the entire management plane. Trusted hosts are also fine however they are limited to specific usernames and super easy to cause a conflict like I demonstrated in the previous video opening up access to the public internet.
For more information see - docs.fortinet.com/document/fortigate/7.4.1/administration-guide/363127/local-in-policy#:~:text=Local%2Din%20policies%20allow%20administrators,subject%20to%20the%20policies%20action.
Don’t forget the implicit deny because local-in isn’t configured by default you need to configure it unlike firewall policies where it’s installed by default.