Hosting some contents behind my Fortinet assets, I've been battling with continuous probes, scans & hacking attempts from all around the globe.
Of course, I've GEO locked my policies, allowing only the wanted countries to reach services, put local-in policies in places etc at my main NGFW etc.. But still the noise and attacks attempts are restless.
Coming with the latest FortiOS 6.2.x you're able to use so called Threat Feeds as inbound filters (within your policies). Meaning any Threat Actors present within those lists (many of them available throughout the Internet) would be denied access.
Cool, we've got some tools to clean that mess.
In order to simplify my Mr. Proper policies management, I thought about why not instantiating a FortiGate Virtual Domain implemented as L2/Transparent in order to leverage the dirty job of cleaning all the inbound traffic just ahead of my main NAT/Route vDOM.
Enabling vDOMs (Virtual Domains) on a FortiGate is achieved simply by going on your FortiGate within System >> System Settings and enabling vDOMs (for the targeted configuration we need multi-vdom)
Once vDOMs are enabled, we now need to create a new L2/Transparent vDOM for our cleaning purposes.
config vdom edit L2-wan config system settings set opmode transparent set manageip 126.96.36.199/255.255.255.0 end
We will then add two not currently in use physical interfaces to our L2-wan vDOM. This has to be achieved within the global settings of the FortiGate.
config global config system interface edit "port8" set vdom "L2-wan" set type physical set alias "L2-LAN" set snmp-index 8 next edit "port9" set vdom "L2-wan" set type physical set alias "L2-WAN" set snmp-index 9 next end end
I'm unconditionally using Zones within my FortiGate policies, it simplifies the reading and general troubleshooting. Therefore I'm configuring two Zones within my L2-wan vDOM.
config vdom edit L2-wan config system zone edit "LAN" set interface "port8" next edit "WAN" set interface "port9" next end
Once this is done, and provided you've got already a NAT/Route "root" vDOM in place, up and running, regulating all you need, we will then need a few connectivity switch in order for our former root vDOM WAN port to reach our new L2/Transparent vDOM LAN port which is now our L2 vDOM port8.
In this lab I've done that simply through virtual switches, redirecting my NAT/route vDOM WAN port within a newly created L2 port group. After that, I've switched my formerly used WAN connectivity stand point to the new L2-vDOM.
To summarize, port8 is now our L2-vDOM LAN port, port9 is our L2-vDOM WAN port and finally, port10 is our NAT/Route vDOM WAN port (no changes aside of switching it within the L2 port group).
What does this mean now?
Well, everything ingressing/egressing our NAT/Route vDOM is now controllable at the L2-wan vDOM level. And this gives us a massive flexibility.
As said, you can now leverage the power of the Threat Feeds and/or Internet Services objects within your inbound policies. Blocking many probing monkeys and incidentally ranking the best Threat Feeds as well =) (of course this is doable within a single vDOM config). But not only that, you can also enforce Application Control Security Profiles that will make sure that traffic hitting say port 443 inbound is really the traffic you want, SSL_TLS 1.2/1.3 HTTP/HTTPS.BROWSER etc.. and deny all the rest. AV, DNS filtering (DNS logging in my case) and FortiGate based WAF filtering towards Web Apps based rules are of course all enforceable on our L2-vDOM now as well.
Also, there isn't any IP scheme changes involved at all. It's all in it's name, a Transparent vDOM.
Traveling somewhere and need that Geo-location to be available to services hosted back on your NAT/Route vDOM? Just add it on your L2-vDOM & safe flight!
Last but not least, you can clean all the non-matching traffic at the L2-vDOM layer. Check for example policy #12 which cleans all the IKE/ESP hazardous attempts from countries I sure don't host any Branches... Or all the web traffic hitting policy #17 which hasn't matched any allowed geography, denied and dropped.
Here is a quick view of a few dropped attempts at the L2 vDOM..
The FortiOS IPS engine dropping attacks attempts from a German friend:
HTTP/HTTPS geo-localization failing to match, denied:
A simple verification on the host IP from the entry selected above pretty much set the intentions landscape of the "operators" behind it (IMPOV)...
As a summary, this is a way for me to enforce wanted/unwanted traffic ahead of my perimeter/edge. It also serve as a centric point at where to look at for potentially malicious activities toward protected assets/services.
I hope you've enjoyed the read, as usual, if anything is unclear, please comment or PM me. I'll of course gladly share with you my used Threat Feeds although, through PM.
Thanks, have phuuun!