Block bogus RFC1918 traffic from reaching Internet

Author
MisterAG
Bronze Member
  • Total Posts : 41
  • Scores: 2
  • Reward points: 0
  • Joined: 2009/02/06 12:58:25
  • Status: offline
2013/08/15 09:35:48 (permalink)
0

Block bogus RFC1918 traffic from reaching Internet

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?
#1

13 Replies Related Threads

    rwpatterson
    Expert Member
    • Total Posts : 8531
    • Scores: 207
    • Reward points: 0
    • Joined: 2006/08/08 10:08:18
    • Location: Long Island, New York, USA
    • Status: online
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/15 09:44:19 (permalink)
    0
    Why would you have traffic to RFC1918 subnets that aren' t in your organization? That' s just plain weird (to me)... Anyhow...

    You could create a single policy inside->WAN and deny all RFC 1918 traffic there. That would effectively keep that stuff off the WAN.

    -Bob - self proclaimed posting junkie!
    See my Fortigate related scripts at: http://fortigate.camerabob.com


    -5.0.14-b0323
    FWF81CM (1)
     
    -4.3.19-b0694
    FWF80CM (2)
    FWF81CM (2)
     
    #2
    MisterAG
    Bronze Member
    • Total Posts : 41
    • Scores: 2
    • Reward points: 0
    • Joined: 2009/02/06 12:58:25
    • Status: offline
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/15 09:45:52 (permalink)
    0
    We don' t have any outside... But we' ve just got a static 0.0.0.0 pointing to the Internet. That default route will send out all unknown destinations (including RFC1918) to the next hop, regardless of if it is private or not.
    #3
    emnoc
    Expert Member
    • Total Posts : 6055
    • Scores: 404
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/15 11:25:30 (permalink)
    0
    What , that doesn' t make any sense ?


    Are you advertising rfc1918 or concern with rfc1918 address host going out to the internet ( leakage ).

    If your advertising osfp routes to you upstream or usptream router or whatever your trying todo, then filter the ospf routes from your advertisements.

    if your trying to prevent sources that are RFC1918, APIPA, martians, than don' t allow them by the fwpolicies. if your worried about spoof' d address, the unit will protect you from any sources not in the unicast route table.


    PCNSE 
    NSE 
    StrongSwan  
    #4
    MisterAG
    Bronze Member
    • Total Posts : 41
    • Scores: 2
    • Reward points: 0
    • Joined: 2009/02/06 12:58:25
    • Status: offline
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/16 05:24:15 (permalink)
    0
    Internal Routers speak OSPF with Fortigate. Fortigate has a default route configured to the Internet. All internal routes are advertised into OSPF.

    At this point, if you look at a routing table you' ll see entries for all of your internal networks and nothing from the Internet.

    I don' t speak BGP with anyone upstream - I just have a single static default route configured on my Fortigate out the external interface.

    At this point, my internal routers still don' t know how to reach the Internet because they still don' t have any default route configured. To solve this, you use
    #default information originate
    On your egress OSPF router from your network (Fortigate).

    Now all the internal routers know to pass any traffic for unknown networks to the Fortigate, which has been configured to pass any unknown traffic up to the default gateway that was statically configured.

    Unknown networks are anything that isn' t in the main OSPF network table or a static route. This includes routes to say Google and Amazon, but it also includes unknown routes in the RFC1918 address family.

    Try it - do a traceroute on your own Fortigate for an RFC1918 network that you don' t use on your own LAN. I bet it' ll end up trying to egress your own Fortigate.

    If you' ve got a rule for your Internal > External that allows say ICMP to any destination, you' ll even be able to send a traceroute out to an unused RFC1918 address (try 10.99.88.77). If you' re passing that traffic out of your network to the Internet, you' re generating the bogon traffic that I' m trying to block.

    My question is, is the easiest way to do so by firewall policy?
    #5
    ede_pfau
    Expert Member
    • Total Posts : 6476
    • Scores: 559
    • Reward points: 0
    • Joined: 2004/03/09 01:20:18
    • Location: Heidelberg, Germany
    • Status: offline
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/16 07:10:53 (permalink)
    0
    I' ll be lazy and just cite my own post here:
    You can prevent forwarding such traffic by creating blackhole routes with a very low priority. They will not be followed if there' s a valid route to the tunnel; and a blackhole route will discard any traffic sent to it.

    There are posts about blackhole routes on the forum, like this one here:
    https://forum.fortinet.com/FindPost/87069

    I' ve posted the CLI commands for the most common RFC1918 private networks there. Be aware of Bob' s comment on blackhole routes interfering with Policy Based Routes - which might or might not affect your setup.

    As I said, this just has the most common RFC1918 networks covered. YMMV.

    Ede

    " Kernel panic: Aiee, killing interrupt handler!"
    #6
    MisterAG
    Bronze Member
    • Total Posts : 41
    • Scores: 2
    • Reward points: 0
    • Joined: 2009/02/06 12:58:25
    • Status: offline
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/16 07:43:11 (permalink)
    0
    Thanks ede_pfau.

    This is what I wanted, and what I figured that I needed to do. I was just looking to see how anyone else was doing it. I ended up blocking the routes by way of firewall policy to ensure that it would show up in the GUI.

    I figure that blocking it by policy passes the ' troubleshooting at 03:00 AM' test better than a CLI only command, but I' ll evaluate this as well. It really is an in your face GUI option vs a CLI only option - one is very obvious from the GUI, one is very obvious from a config change archive.
    #7
    ede_pfau
    Expert Member
    • Total Posts : 6476
    • Scores: 559
    • Reward points: 0
    • Joined: 2004/03/09 01:20:18
    • Location: Heidelberg, Germany
    • Status: offline
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/16 09:34:54 (permalink)
    0
    I always thought of default blackhole routes as a means of last resort - no matter what I (mis-)configure in the policy table this sort of traffic will not make it to the WAN. As the distance parameter is set utmost high there' s no chance legitimate traffic will be blackholed.

    And regarding the ' obviousness' in the GUI, the Routing Monitor tells it all. BH routes will show up as active, with destination ' Null' . Easy to spot.

    Ede

    " Kernel panic: Aiee, killing interrupt handler!"
    #8
    MisterAG
    Bronze Member
    • Total Posts : 41
    • Scores: 2
    • Reward points: 0
    • Joined: 2009/02/06 12:58:25
    • Status: offline
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/16 11:44:33 (permalink)
    0
    Even better then.
    #9
    FortiRack_Eric
    Platinum Member
    • Total Posts : 1248
    • Scores: 23
    • Reward points: 0
    • Joined: 2007/03/12 13:54:17
    • Location: The Netherlands
    • Status: offline
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/20 04:04:41 (permalink)
    5 (1)
    this is the way to go... blackhole all not specified RFC 1918 traffic.

    config router static
    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 172.16.0.0 255.240.0.0
    next
    edit 0
    set blackhole enable
    set distance 254
    set dst 10.0.0.0 255.0.0.0
    next
    end


    This is a (part) of a standard script we provision on every FGT unit.

    Cheers, Eric


    Rackmount your Fortinet --> http://www.rackmount.it/fortirack
     
    #10
    ede_pfau
    Expert Member
    • Total Posts : 6476
    • Scores: 559
    • Reward points: 0
    • Joined: 2004/03/09 01:20:18
    • Location: Heidelberg, Germany
    • Status: offline
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/20 04:57:11 (permalink)
    0
    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.

    Ede

    " Kernel panic: Aiee, killing interrupt handler!"
    #11
    emnoc
    Expert Member
    • Total Posts : 6055
    • Scores: 404
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/20 08:25:39 (permalink)
    0
    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;





    :)

    PCNSE 
    NSE 
    StrongSwan  
    #12
    rwpatterson
    Expert Member
    • Total Posts : 8531
    • Scores: 207
    • Reward points: 0
    • Joined: 2006/08/08 10:08:18
    • Location: Long Island, New York, USA
    • Status: online
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/27 08:37:25 (permalink)
    0
    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
    < Message edited by rwpatterson -- 8/27/2013 11:49:45 AM >

    -Bob - self proclaimed posting junkie!
    See my Fortigate related scripts at: http://fortigate.camerabob.com


    -5.0.14-b0323
    FWF81CM (1)
     
    -4.3.19-b0694
    FWF80CM (2)
    FWF81CM (2)
     
    #13
    emnoc
    Expert Member
    • Total Posts : 6055
    • Scores: 404
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    RE: Block bogus RFC1918 traffic from reaching Internet 2013/08/30 17:33:13 (permalink)
    0
    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
    #




    PCNSE 
    NSE 
    StrongSwan  
    #14
    Jump to:
    © 2021 APG vNext Commercial Version 5.5