Great video Mike! Giving some insights into mitigation steps that one can perform , that is sometimes overlooked in the quest for "Industry Best Practices" . Seeing a lot of Security engineers out there that stick to one way of doing things without being able to have a discussion on some issues , issues that you bring up in your videos , that makes my trust in them dwindle a little bit. Keep up the good work.
You are loved too Mike! Man I could feel it in your voice dude, that was heart felt and I know who you were thinking of when you said it. To ANYONE reading this, your life matters and is important! If you are watching Mike's videos and reading comments like mine, you are already way cooler than most people I know!!! :) Local in policy locking down remote access 100%! you also prob. wouldn't cover it on this channel but maybe on Packet Llama, but using a proper segmented management network would be a great video... locking down all the botnets from remotely reaching your FortiGate is huge of course (use that Botnet C&C DNS filter!) but not allowing just anyone on your internal interfaces to reach your firewall is also important and I find more often than not it's overlooked. Remember plenty of "incidents" are caused by human error and it's not all just malicious actors trying to get to your infrastructure. one last tip i like to use, run a full 65k port scan remotely (run once occasionally will not flag anything typically) and document all known / non-stealth (aka responding) ports... you should know what they ALL are doing and why they are responding / open... do this again any time you make any major changes / update your firmware / etc... shodan.io can be pretty eye opening too
All great suggestions, Michael! I work for a service provider/consulting company. I do sevaral things for FGTs that I have https open on the outside (I don't turn it on on all my fortigates, but some that I get in frequently, I do). I will set max login attempts to 3 with a lockout duration of 24hrs. That way a bad actor only gets 3 trys a day. config user setting set auth-lockout-threshold 3 set auth-lockout-duration 86400 end Also, we have a geoblock list that we created with about 20 foreign contries (all the worst offenders) that we create firewall policies to block in and out. If it's a 100 series and above, (more specifically if the box has the additional NP6/NP7 processor) we will add the geoblock list to the IPv4 access control list in and out. Boxes with this extra processor offload ipv4 ACL's to this processor. So, traffic denied by these ACL's gets dropped before it even hits your firewall policies - saving your cpu from having to process it. The other big thing I suggest, if you are going to open https on your outside interface, is to set up an automation stitch to email you if there is a failed login attempt or lockout. Set up an automation trigger for Event IDs "Admin Login Disabled" and "Admin Login Failed". Then create a stitch with that trigger and your email. That way you get notified of any bad attempts. This will probably cause you to turn off https managment on the outside, lol. The first time you get 400-700 emails overnight from some bot trying to hit your outside interface from all over the world, you will probably end up disabling outside access! They get creative.. they'll use 10-20 different IP's from all over, and try all kinds of diffrent usernames. I've got a running list so far of about 60 IP's that I block in addition to my geoblocking. These are IP's that I've seen across multiple disperate fortigates with multple login attempts. For clients with tighter security concerns, we will disable management on the outside interface and use the fortigate cloud remote access function to tunnel into the Fortigate management.
How? Their ips are secret AFAIK , ofc u can remove anything http other than that but the box still respond to requests then. Or do you have some trick idk about
MSP here we use localIn policy for SSH / Admin UI to limit remote access to the box only for our Datacenter IP / Jumphost :) Totally annoying that you can't configure this in the GUI.
Hi, I'm facing an issue with my Fortigate device. Since upgraded my firewall with FortiOS 7.4.2, the SD-WAN rules are visible in CLI but GUI is showing a loading page only. Please help.
Enjoying the videos, can you please share what software you as to record these, it would be great to do in house training videos like this for my staff. Cheers
Hi Mike, did you hear about the new stupid artificial limitation for the lower-end units, to kill of all proxy-based features after 7.4.4? I mainly use 40 and 60f units because I am a small MSP with small business customers, and they just killed off the most useful and security relevant features on basically all of my firewalls. Even my 60F in my home / office LAB is now essentially useless, since you can't even test a proxy feature like ZDNA or Virtual Server load balancing, before you deploy it on a larger scale. I mean most people don't have a 80F or above just for a LAB.
Question regarding FortiToken - I was thinking of how it can be applied in a multi-user team environment. If you have a team of multiple engineers that would need access to the Box, how can you utilize the FortiToken if its tied to a Mobile device? Is there a way to 'fudge' the FortiToken App in a web Browser extension in some manner?
Thank you for the video. I‘ve run into far too many FGTs that aren‘t adequately secured for the systems they protect. Can RADIUS accounts (wildcard / all in matched group) be limited to trusted hosts as well? I‘m in the pocess of moving from all local accounts to FortiAuthenticator with Radius on some FGT clusters and I can‘t come up with a way to match trusted hosts per user with wildcard Radius accounts.
Thanks for the quick reply. Do I need to configure these as individual Radius accounts (Match a user on a remote server group) on every FGT or can it be done with „Match all users in a remote server group“ by configuring the trusted hosts on the FortiAuthenticator somehow? I want to set the trusted hosts per account (only that persons office-pc) but preferrably still match all users of the radius group to avoid having to configure every account on every FGT.
@@FortinetGuru one of the issues I found doing this is trying to ssh into a box. I could never figure out how to get the Fortitoken prompt to work in Putty or Moba. So for now I just use trusted hosts and local in's. Would love to figure this out. Also I changed my admin-sport, ssh, and telnet ports to various obscure ports.
@@vewo234 You can do this via user groups on the gates that match the admin user groups on the authenticator. Each gate would need the group attached to the authenticator(Radius server, unless utilizing LDAP). This way, all your admins and 2FA's are managed by the Authenticator. If you see my comment about accessing a gate via ssh, I can't seem to get the Tokens to work in Putty or Moba. If you do, please let me know.
Hey Mike, I cannot confirm that the Fortigate will respond to HTTP/S requests if ALL Admin users have TrustedHost active. Packets will get dropped. From my understanding, all IPs from trusted host will be granted access to the GUI/SSH
Securing your device administratively is paramount in being successful.
Great video Mike!
Giving some insights into mitigation steps that one can perform , that is sometimes overlooked in the quest for "Industry Best Practices" .
Seeing a lot of Security engineers out there that stick to one way of doing things without being able to have a discussion on some issues , issues that you bring up in your videos , that makes my trust in them dwindle a little bit.
Keep up the good work.
Nice to see you're so active again. Very good Video. Thanks for sharing your Knowledge.
Thanks Mike! I attempted Local-In Policy a while ago but screwed it up, and forgot about it! This has been massively helpful. Thank you!
You are loved too Mike! Man I could feel it in your voice dude, that was heart felt and I know who you were thinking of when you said it. To ANYONE reading this, your life matters and is important! If you are watching Mike's videos and reading comments like mine, you are already way cooler than most people I know!!! :)
Local in policy locking down remote access 100%! you also prob. wouldn't cover it on this channel but maybe on Packet Llama, but using a proper segmented management network would be a great video... locking down all the botnets from remotely reaching your FortiGate is huge of course (use that Botnet C&C DNS filter!) but not allowing just anyone on your internal interfaces to reach your firewall is also important and I find more often than not it's overlooked. Remember plenty of "incidents" are caused by human error and it's not all just malicious actors trying to get to your infrastructure.
one last tip i like to use, run a full 65k port scan remotely (run once occasionally will not flag anything typically) and document all known / non-stealth (aka responding) ports... you should know what they ALL are doing and why they are responding / open... do this again any time you make any major changes / update your firmware / etc...
shodan.io can be pretty eye opening too
All great suggestions, Michael!
I work for a service provider/consulting company. I do sevaral things for FGTs that I have https open on the outside (I don't turn it on on all my fortigates, but some that I get in frequently, I do). I will set max login attempts to 3 with a lockout duration of 24hrs. That way a bad actor only gets 3 trys a day.
config user setting
set auth-lockout-threshold 3
set auth-lockout-duration 86400
end
Also, we have a geoblock list that we created with about 20 foreign contries (all the worst offenders) that we create firewall policies to block in and out.
If it's a 100 series and above, (more specifically if the box has the additional NP6/NP7 processor) we will add the geoblock list to the IPv4 access control list in and out. Boxes with this extra processor offload ipv4 ACL's to this processor. So, traffic denied by these ACL's gets dropped before it even hits your firewall policies - saving your cpu from having to process it.
The other big thing I suggest, if you are going to open https on your outside interface, is to set up an automation stitch to email you if there is a failed login attempt or lockout. Set up an automation trigger for Event IDs "Admin Login Disabled" and "Admin Login Failed". Then create a stitch with that trigger and your email. That way you get notified of any bad attempts. This will probably cause you to turn off https managment on the outside, lol. The first time you get 400-700 emails overnight from some bot trying to hit your outside interface from all over the world, you will probably end up disabling outside access! They get creative.. they'll use 10-20 different IP's from all over, and try all kinds of diffrent usernames. I've got a running list so far of about 60 IP's that I block in addition to my geoblocking. These are IP's that I've seen across multiple disperate fortigates with multple login attempts.
For clients with tighter security concerns, we will disable management on the outside interface and use the fortigate cloud remote access function to tunnel into the Fortigate management.
Risks and mitigating those risks of having the ACME engine for letsencryot certs. And limiting acme access with local-in
How? Their ips are secret AFAIK , ofc u can remove anything http other than that but the box still respond to requests then. Or do you have some trick idk about
Thank you for sharing! Love your channel, keep up the hard work Michael!
Thank you! Will do!
Another amazing video, would love to see some videos on FortiManager v7.2! 🙏Thank you!
In addition to local in policies, I do SAML SSO for admin accounts (Entra ID) and it works great 👌
I love Azure tie in! Gives you a lot more including conditional access and more!
@@FortinetGuru Agreed!
How to set this up would be great!
Can you access your firewall when the internet is down then?
Absolutely, as long as you have all possible space listed in the trusted hosts and the local in policy it will accept from the sources mentioned.
Ha, the lack of face fuzz threw me off a bit. Great video as always. Thank you sir.
😂
Great info! Thanks!
You are loved too, man. Great video
Happy new year! Great video. Can you do a video on SAML /entra based web filtering please?
Will do!
Nice!
Thanks. Do you planned to make tutorials about ZTNA? 😁
I do!
Thx dude for the content!
No problem!
Great review!
Thanks!
Great video!! 👍
Thank you! Cheers!
MSP here we use localIn policy for SSH / Admin UI to limit remote access to the box only for our Datacenter IP / Jumphost :)
Totally annoying that you can't configure this in the GUI.
I agree. It should be brought to the GUI ASAP IMO
Hey Michael, Thank man for the great video. what about setting trusted hosts to a specific internal subnet and access through VPN for remote admin
Great video!!! 👍 Any hint for protecting services like Explicit Proxy, Virtual IPs or Virtual Servers?
Good stuff
Appreciate it
Hi,
I'm facing an issue with my Fortigate device. Since upgraded my firewall with FortiOS 7.4.2, the SD-WAN rules are visible in CLI but GUI is showing a loading page only. Please help.
Enjoying the videos, can you please share what software you as to record these, it would be great to do in house training videos like this for my staff. Cheers
OBS
Hi Mike, did you hear about the new stupid artificial limitation for the lower-end units, to kill of all proxy-based features after 7.4.4? I mainly use 40 and 60f units because I am a small MSP with small business customers, and they just killed off the most useful and security relevant features on basically all of my firewalls. Even my 60F in my home / office LAB is now essentially useless, since you can't even test a proxy feature like ZDNA or Virtual Server load balancing, before you deploy it on a larger scale. I mean most people don't have a 80F or above just for a LAB.
Question regarding FortiToken - I was thinking of how it can be applied in a multi-user team environment. If you have a team of multiple engineers that would need access to the Box, how can you utilize the FortiToken if its tied to a Mobile device? Is there a way to 'fudge' the FortiToken App in a web Browser extension in some manner?
Never tried. Token should be assigned to a user. Sharing wouldn't be feasible.
Thank you for the video. I‘ve run into far too many FGTs that aren‘t adequately secured for the systems they protect.
Can RADIUS accounts (wildcard / all in matched group) be limited to trusted hosts as well? I‘m in the pocess of moving from all local accounts to FortiAuthenticator with Radius on some FGT clusters and I can‘t come up with a way to match trusted hosts per user with wildcard Radius accounts.
They can. You can do individual radius accounts with trusted hosts on them.
Thanks for the quick reply. Do I need to configure these as individual Radius accounts (Match a user on a remote server group) on every FGT or can it be done with „Match all users in a remote server group“ by configuring the trusted hosts on the FortiAuthenticator somehow? I want to set the trusted hosts per account (only that persons office-pc) but preferrably still match all users of the radius group to avoid having to configure every account on every FGT.
@@FortinetGuru one of the issues I found doing this is trying to ssh into a box. I could never figure out how to get the Fortitoken prompt to work in Putty or Moba. So for now I just use trusted hosts and local in's. Would love to figure this out. Also I changed my admin-sport, ssh, and telnet ports to various obscure ports.
@@vewo234 You can do this via user groups on the gates that match the admin user groups on the authenticator. Each gate would need the group attached to the authenticator(Radius server, unless utilizing LDAP). This way, all your admins and 2FA's are managed by the Authenticator. If you see my comment about accessing a gate via ssh, I can't seem to get the Tokens to work in Putty or Moba. If you do, please let me know.
Hey Mike, I cannot confirm that the Fortigate will respond to HTTP/S requests if ALL Admin users have TrustedHost active. Packets will get dropped. From my understanding, all IPs from trusted host will be granted access to the GUI/SSH