blackhole problems within fortiOS

I ran into something interesting with blackhole  routes  in the past for  ipv4 and ipv6 that I wouuld like to  share.

The native behavior  in fortiOS has limitations with blackhole'ing routes for networks that we deem as a BOGON/MARTIANs.

Even with  ipv6 , we have no ability to set  "blackhole"  interface like that within ipv4,  which plain out sucks. Even if you tried to stick it off on a loopback interface,  the ipv6 bogon sources can't be applied as  ipv6 extra addresses since FortIOS doesn't see  them as valid networks to begin with.

Here's a typical standard blackhole route listings for ipv4 and with the keyword of "blackhole" in the "config router static"




ipv4

These are source networks that should never enter a public network interface. Now ideally you will enable  this on a router or as  remote  trigger blackhole  route injection  aka  ( Remotely triggered black hole  RTBH )

Or even better yet have your upstream ISP(s)  blackhole these networks for  your business.

https://en.wikipedia.org/wiki/Martian_packet
https://en.wikipedia.org/wiki/Bogon_filtering


But let's look at what's wrong with the fortigate and blackholes..

1st ; various  ipv4 source can not be added as with the true standard blackhole methods.


e.g ( a packet with a src of 0.0.0.0/8 ) can not have a route installed as blackhole route the typical fashion and the same holds true for the multicast networks or the reserved class E network.

IPv6 static routes also has no means for applying a static route for ipv6 with blackhole enabled per network source.

That option just doesn't exists in FortiOS which is just shocking


So what's a security engineer todo? 

1st: You should never use the old method of a  fwpolicy at the top of sequence with the action set as "deny"

The above still requires action via the firewall and generates excess noise and logging. It also requires  the packet to transverse your local interfaces jus to be dump and dropped.

2nd: You should review your ISP blackhole'ing capabilities and if your receiving a full-bgp table, always use  unicast RPFs checks  aka  unicast source verify.

3rd, blackhole bogon and martians at the edge via static route and with the distance or admin value set for the highest.

The goal is for the unicast rpf checks to fail traffic that could be spoof'd with a martian as a source. This is a simple means for eliminating bad sources from entering from the untrusted networks and  provides for a mean to ensure that you don't cause  leakage of bad source packets to  the public internet which is common with Windows/MAC hosts that uses APIPA (Automatic Private IP Addressing).

BLACKholes routes is a good way to  mitigate not only BOGONs but  just  about any other bad sources. In the DDoS communities we use RTBH routes on a /32 to drop bad or known bot hosts or malicious sources.


Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^
=(  @  @ )=
         o 
        /  \