Block bogus RFC1918 traffic from reaching Internet

[MisterAG]

I have several RFC1918 subnets on various interfaces of my Fortigate. My Fortigate is advertising info OSPF a default route. This is causing my internal routers to pass up traffic to unused subnets (like 192.168.200.0/24) to the Fortigate. The Fortigate in turn has a default route out the the Internet by way of my provider, and is passing the same traffic upstream there. What is the most efficient (configuration / performance / administrative) way to stop that traffic from crossing the Fortigate? I' m thinking of a blackhole route for 192.168.0.0/16 with a high administrative distance vs a Firewall policy on any > external Ideas?

[ede_pfau]

OK, I will share my blackhole script (batch command) here with the full coverage of RFC1918, plus the APIPA range 169.254.x.y. It uses the " edit 0" syntax so it can be batch loaded even when other routes exist. Contrary to policies, routes are not followed top-down but by best fit, so the sequence doesn' t matter:

 config router static
     edit 0
         set blackhole enable
         set distance 254
         set dst 0.0.0.0 255.0.0.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 10.0.0.0 255.0.0.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 100.64.0.0 255.192.0.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 169.254.0.0 255.255.0.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 172.16.0.0 255.240.0.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 192.0.0.0 255.255.255.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 192.0.2.0 255.255.255.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 192.168.0.0 255.255.0.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 198.18.0.0 255.254.0.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 198.51.100.0 255.255.255.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 203.0.113.0 255.255.255.0
     next
  end
  

Feedback on omissions or errors are always welcome.

[emnoc]

You missed a few :) Here' s blacklist you can google cymru and get examples; 0.0.0.0/8; 10.0.0.0/8; 127.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; 192.0.2.0/24; 169.254.0.0/16; 127.0.0.0/8; 224.0.0.0/4; 240.0.0.0/4; 255.255.255.255/32; :)

[rwpatterson]

From RFC 5735 (Obsoletes: RFC 3330, Obsoleted by: RFC 6890, Updated by: RFC 6598), page 5:

4.  Summary Table
 
 Address Block       Present Use                Reference
 ------------------------------------------------------------------
 0.0.0.0/8           " This"  Network             RFC 1122, Section 3.2.1.3
 10.0.0.0/8          Private-Use Networks       RFC 1918
 127.0.0.0/8         Loopback                   RFC 1122, Section 3.2.1.3
 169.254.0.0/16      Link Local                 RFC 3927
 172.16.0.0/12       Private-Use Networks       RFC 1918
 192.0.0.0/24        IETF Protocol Assignments  RFC 5736
 192.0.2.0/24        TEST-NET-1                 RFC 5737
 192.88.99.0/24      6to4 Relay Anycast         RFC 3068
 192.168.0.0/16      Private-Use Networks       RFC 1918
 198.18.0.0/15       Network Interconnect
                     Device Benchmark Testing   RFC 2544
 198.51.100.0/24     TEST-NET-2                 RFC 5737
 203.0.113.0/24      TEST-NET-3                 RFC 5737
 224.0.0.0/4         Multicast                  RFC 3171
 240.0.0.0/4         Reserved for Future Use    RFC 1112, Section 4
 255.255.255.255/32  Limited Broadcast          RFC 919, Section 7
                                                RFC 922, Section 7

Interestingly, RFC 6890 includes ' 100.64.0.0/10' , but removes ' 224.0.0.0/4' .

                  +----------------------+----------------------+
                  | Attribute            | Value                |
                  +----------------------+----------------------+
                  | Address Block        | 100.64.0.0/10        |
                  | Name                 | Shared Address Space |
                  | RFC                  | [RFC6598]            |
                  | Allocation Date      | April 2012           |
                  | Termination Date     | N/A                  |
                  | Source               | True                 |
                  | Destination          | True                 |
                  | Forwardable          | True                 |
                  | Global               | False                |
                  | Reserved-by-Protocol | False                |
                  +----------------------+----------------------+
 
                        Table 3: Shared Address Space
 

[emnoc]

Yes both of those should not be in the BGP internet table 100.64.0.0/10 whois -h whois.arin.net 100.64.0.0/10 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # # Query terms are ambiguous. The query is assumed to be: # " r < 100.64.0.0/10" # # Use " ?" to get help. # # # The following results may also be obtained via: # http://whois.arin.net/rest/cidr/100.64.0.0/10/less?showDetails=false&ext=netref2 # American Registry for Internet Numbers NET100 (NET-100-0-0-0-0) 100.0.0.0 - 100.255.255.255 Internet Assigned Numbers Authority SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED (NET-100-64-0-0-1) 100.64.0.0 - 100.127.255.255 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html #