Internet2 Network Security SIG

[Michael Hare <>]

Tread carefully, for there be dragons.

 

I will assume you are concerned about the possibility of access from an unauthorized source or some sort of resource exhaustion.

 

I will also assume reasonable best practices are being followed for lo0 protection (checking source IPs, etc) and dropping fragmented packets.

 

For now AS 3128 blocks (fw filter) on ingress untrusted connections subnets I have set aside for backbone point to points, loopbacks and management server subnets.  About your specific filter, I would replace border-localv4-subnets with the entire CIDR you use for point to points AND whatever point to points have been given to you by peers/connectors.  I keep this list sync'd across all of our ASBR's.  This will address some of the asymmetry issues.

 

I am moving towards pushing device management into an L3VPN (fxp0 looped back to front facing ports).  End goal is to put a deny on world reachable inet0 and inet6 lo0 for things like (S)FTP, SNMP, SSH, HTTP(S), etc.  As a bonus you can also use MPLS QoS to make sure this class of traffic survives (is prioritized) during congestion.

 

We haven't yet moved our customer/connectors/transit out of the main table but if I had them inside a L3VPN like I2 I might be willing/curious to try dropping IGP and label distribution protocols at the border as well [or at least investigate the feasibility of doing so with the 'log accept' approach]

 

I will also reiterate that looking into Juniper's ddos-protection control plane policing scheme is a valuable tool that doesn't replace these ACLs but augments resiliency for what gets admitted.  The approach is simple if not time consuming; collect, analyze, deploy, monitor, adjust.

 

-Michael

 

From: [mailto:] On Behalf Of Karl Newell
Sent: Wednesday, August 16, 2017 1:54 PM
To:
Subject: [Security-WG] Internet2 border anti-spoofing

 

I’m looking for your thoughts and feedback on the following.  tl;dr – we’re looking into border anti-spoofing of packets sourced from Internet2 IP address space to further protect the Internet2 network. 

 

One project we’ve been working on at Internet2 is vulnerability management of the network infrastructure, initially focusing on the Juniper MX960s.  While running code that addresses known vulnerabilities is the first line of defense, it’s not always feasible or, at least, not feasible to roll out fixes immediately.  So, we’re working on methods to mitigate the associated risks and one we’re experimenting with we call border anti-spoofing. The idea is to discard packets using spoofed Internet2 IP address space as the source IP.  “uRPF you say?”…a limited form; we’ll save the uRPF discussion for a later date.  The relevant Juniper configs are below and the firewall filter is applied to the interfaces we use to peer with connectors.  We first accept traffic sourced from any point-to-point link and then log packets sourced from Internet2 IP address space.  To actually enforce this border anti-spoofing we would change the “next term” to “discard”.  Ideally, any packets that get logged are spoofing the source IP with an Internet2 IP address.  In reality, we saw lots of traffic, predominantly related to ICMP.  Most of this is a result of asymmetric routing and the peer having a better path through another I2 interface when sending ICMP Time Exceeding packets from a peering interface.  I’ve attached a Splunk report graphing what we see in a 24-hour period.  We plan to allow the ICMP traffic and are wondering what to do with the TCP traffic.  Based on port numbers and related IPs the TCP traffic is related to scanning for vulnerable services.

 

Questions I have for this group:

-Is this a valid and useful method to protect the network?

-Is there anything you would suggest we do differently?

-What do we do with the TCP traffic?  We can continue to log and monitor or we could start to discard the traffic.

-Any other thoughts…

 

Thanks in advance for any feedback,

Karl

 

 

 

filter connector-in {

    term border-exceptions {

        from {

            source-prefix-list {

                border-localv4-subnets;

            }

        }

        then {

            count border-exceptions;

            accept;

        }

    }

    term border-discard {

        from {

            source-prefix-list {

                INTERNAL;

            }

        }

        then {

            count border-i2-discard;

            log;

            syslog;

            next term;

        }

    }

 

 

prefix-list border-localv4-subnets {

    apply-path "interfaces <*> unit <*> family inet address <*>";

}

 

 

 

 

 

--

Karl Newell

Cyberinfrastructure Security Engineer

Internet2

520-344-0459