Clean-up your traffic with a FortiGate Transparent vDOM

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 1.1.1.1/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!
Obuno