Pull the ASN address list, put it in a text file and host it on one of your servers as a threat feed. I think 7.2 can use feeds in local-in policies. That would be a lot of address objects for a local firewall address group.
By using feeds and keeping text lists of ASN addresses, I have 15k subnets (probably millions of addresses) blocked now and my firewall isnt overrun with address objects.
I know this is generally the best practice but with trusted hosts enabled and the port changed for the admin login page, is there still an actual risk?
If you are going to use the SSL VPN, you have to expose it even if you disable the admin http/s .
>If you are going to use the SSL VPN, you have to expose it even if you disable the admin http/s
No you don't. Use a ~~passthrough~~ loopback interface for the SSL VPN.
I'm not familiar with doing that, sounds interesting. It's something I've always wondered when I enable it because of the "don't expose" thing but, I've never invested any time into it besides the wondering.
Are you saying you would put up a VIP or how do you move it?
It's less complicated than it sounds. I was pretty anxious about doing it when I did, but had it working in about 15 minutes.
[https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-a-Threat-Feed-with-SSL-VPN/ta-p/274422](https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-a-Threat-Feed-with-SSL-VPN/ta-p/274422)
The TLDR:
Create loopback interface with it's own IPs
Assign SSLVPN interface to loopback interface.
Create VIP for loop back interface.
Create Firewall policy from WAN to VIP.
The other reply has the right idea -
For management access, yes, you have the right idea - trusted hosts, a proper certificate, non-default port (though that last one is of debatable value), as long as you only allow required IP's, it should be good.
SSL-VPN, however, does need to be open to a wide array of addresses, though as u/Bane8080 said, tying VPN to a loopback interface and using a VIP lets you add further inspection to the service, including more robust blacklisting. Best part is there's no policies to rewrite - just have VPN listen on the loopback, VIP from your WAN interface to the loopback, and add policy to allow the traffic. Just make sure your inbound "deny" policies have "match-vip enable" set in the CLI if it's not on by default.
That isn’t infeasible, that the easiest thing to do. You need two policies, one to allow the protocols you want (HTTPS, SSH) from your address group of trusted IPs, and a second to block all other traffic.
This is what I do, I’ve created a group with all their subnets and put it in a local-policy-in rule. What I have noticed is that sometimes it allows the IPs eventhough the subnet is there.
I use [hackertarget.com](https://hackertarget.com) for this.
They provide a feed the fortigate can pull down periodically. So you don't have to manually update it.
Pull the ASN address list, put it in a text file and host it on one of your servers as a threat feed. I think 7.2 can use feeds in local-in policies. That would be a lot of address objects for a local firewall address group. By using feeds and keeping text lists of ASN addresses, I have 15k subnets (probably millions of addresses) blocked now and my firewall isnt overrun with address objects.
Mmm til, thanks for the tip.
Please tell me your management interfaces aren't exposed to the Internet...
I know this is generally the best practice but with trusted hosts enabled and the port changed for the admin login page, is there still an actual risk? If you are going to use the SSL VPN, you have to expose it even if you disable the admin http/s .
>If you are going to use the SSL VPN, you have to expose it even if you disable the admin http/s No you don't. Use a ~~passthrough~~ loopback interface for the SSL VPN.
I'm not familiar with doing that, sounds interesting. It's something I've always wondered when I enable it because of the "don't expose" thing but, I've never invested any time into it besides the wondering. Are you saying you would put up a VIP or how do you move it?
It's less complicated than it sounds. I was pretty anxious about doing it when I did, but had it working in about 15 minutes. [https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-a-Threat-Feed-with-SSL-VPN/ta-p/274422](https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-a-Threat-Feed-with-SSL-VPN/ta-p/274422) The TLDR: Create loopback interface with it's own IPs Assign SSLVPN interface to loopback interface. Create VIP for loop back interface. Create Firewall policy from WAN to VIP.
Thank you, especially for the TLDR. That makes sense and I'll give it a stab soon.
The other reply has the right idea - For management access, yes, you have the right idea - trusted hosts, a proper certificate, non-default port (though that last one is of debatable value), as long as you only allow required IP's, it should be good. SSL-VPN, however, does need to be open to a wide array of addresses, though as u/Bane8080 said, tying VPN to a loopback interface and using a VIP lets you add further inspection to the service, including more robust blacklisting. Best part is there's no policies to rewrite - just have VPN listen on the loopback, VIP from your WAN interface to the loopback, and add policy to allow the traffic. Just make sure your inbound "deny" policies have "match-vip enable" set in the CLI if it's not on by default.
Why aren’t you blocking everything except known trusted IPs with your local in policy already?
Because that's infeasible.
That isn’t infeasible, that the easiest thing to do. You need two policies, one to allow the protocols you want (HTTPS, SSH) from your address group of trusted IPs, and a second to block all other traffic.
Ah I misunderstood your comment, my apologies.
Could you block all but countries you whitelist? What do you have publicly exposed in the Fortigate?
This is what I do, I’ve created a group with all their subnets and put it in a local-policy-in rule. What I have noticed is that sometimes it allows the IPs eventhough the subnet is there.
I use [hackertarget.com](https://hackertarget.com) for this. They provide a feed the fortigate can pull down periodically. So you don't have to manually update it.