netsec-sig - [Security-WG] Internet2 border anti-spoofing
Subject: Internet2 Network Security SIG
List archive
- From: Karl Newell <>
- To: "" <>
- Subject: [Security-WG] Internet2 border anti-spoofing
- Date: Wed, 16 Aug 2017 18:54:26 +0000
- Accept-language: en-US
- Authentication-results: internet2.edu; dkim=none (message not signed) header.d=none;internet2.edu; dmarc=none action=none header.from=internet2.edu;
- Ironport-phdr: 9a23:j0ncGBRl6zPY9lHbPHR7qfgyK9psv+yvbD5Q0YIujvd0So/mwa6yYhON2/xhgRfzUJnB7Loc0qyN4vCmATRIyK3CmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+KPjrFY7OlcS30P2594HObwlSijewZbB/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbDVwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4qF2QxHqlSgHLSY0/mHJhMJtkKJVrhGvpx1jzIHbe4yVMeZyfqbHcN8GWWZMXMBcXDFBDIOmaIsPCvIMM+NCoInno1sFsAOwCheiBezxzj9IgmL90Ko50+QnDw7H0hIvH9YKsHnPrdX1MrsSXv6vzKnO0zrDc+1a1S3j54fVbxAsuPeBVq9zf8rJ0UQjCRnKgkmNpYHgIj+Zy/kBvm2V7+dvSe6jl2sqpgNvrTWg2sshj4zEipwJxl3F7Sl13YY4KcGiREJmb9OpEIFcuzybOoZ2WM8uXn1ktSk8x7Ybo5C0ZjIKx44ixxPHa/yIbYyI4hX7WeiJPTp2g25pdK+mixiv6Uas1/TwVs6v31lUtCZFlcTMtmwW2BzU98iHTOZy8l252TaV0ADT9v9LLlwolaraLJ4hxKQ8lp0OsUTfGi/2n0L2jKyMeko4/eio7vzrYrTgppCCK495kh/yPb4ylsCiBOk0LxUCU3We9OSy27Dv4VH1TbBIg/IonaTVrJXXKMEFqqKlAgJZyoMj5Ay+Dzei3tQYh34HLFdddRKEiYjmJV/PL+78Dfe7mFmskTFrx+zYMb37BJXCMGTDnKn7cblj9kFc1RI/zcpD6JJMFrEBPPXzV1fqtNPGEhA5Lha0w+f7CNR9z48fV22PD7SdMKPTql+I+vkvL/eWaI8Uvjb9N+Yq5+TojXAnhV8RY7Ol0oUKZ3ClTbxaJBDTenfnn80ADXZPoQUWTer2hUeEXCIJIXu+Quh0sio2A5+8DJvSA5+iqL2HwCqhGJBKPCZLBk3aQlnycIDReP4WbGq0L9BsljhMAbunRpAs0RWGtQnmxqBhI/aOvCAUqMSwh5BO++TPmERqpnRPBMOH3jTVQg==
- Spamdiagnosticoutput: 1:0
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 |
Attachment:
I2_ashb_anti-spoofing.pdf
Description: I2_ashb_anti-spoofing.pdf
- [Security-WG] Internet2 border anti-spoofing, Karl Newell, 08/16/2017
- Re: [Security-WG] Internet2 border anti-spoofing, Andrew Gallo, 08/16/2017
- Re: [Security-WG] Internet2 border anti-spoofing, Karl Newell, 08/16/2017
- RE: [Security-WG] Internet2 border anti-spoofing, Michael Hare, 08/17/2017
- Re: [Security-WG] Internet2 border anti-spoofing, Karl Newell, 08/16/2017
- [Security-WG] RE: Internet2 border anti-spoofing, Michael Hare, 08/17/2017
- Re: [Security-WG] Internet2 border anti-spoofing, Andrew Gallo, 08/16/2017
Archive powered by MHonArc 2.6.19.