Security Controls For an Energy Science DMZ - PowerPoint Presentation

1. Security Controls For an Energy Science DMZRobert Marcoux01/13/2013

2. Science DMZ RequirementsThe Science DMZ Model addresses several key issues in data intensive science, including:Reducing or eliminating the packet loss that causes poor TCP performanceImplementing appropriate security architectures and controls so that high-performance applications are not hampered by unnecessary constraintsProviding an on-ramp for local science resources to access wide area science services including virtual circuits, software defined networking environments, and 100 Gigabit infrastructures.Incorporating network testing, network measurement, and performance analysis through the deployment of perfSONAR

3. Security controls

4. Security Controls – Aggressive FilteringFirewall Filters -Firewall Filters are a tool for controlling and restricting access to network resources. A Firewall Filter examines the Layer 3 and Layer 4 headers on a packet-by-packet basis. Based on configured rules, a Firewall Filter decides whether the router forwards or drops the packet. Firewall Filters differ from a stateful firewall, which examines the packet’s data and monitors the activity of TCP sessions. Firewall Filters use the data obtained by the Internet Processor ASIC on the Packet Forwarding Engine.Filter-Based Forwarding (Policy Based Routing) -Filter-based forwarding allows you to control the next-hop selection for traffic by defining input packet filters that examine the fields in a packet’s header. If a packet satisfies the match conditions of the filter, the packet is forwarded using the routing instance specified in the filter action statement.

5. Security Controls Remotely Triggered Black Hole (RTBH)Remotely Triggered Black Hole -Destination based RTBHRequires pre-configuration of discard route on all edge routersMonitoring via separate mechanism identifies destination of attackMonitoring router injects a discard route in forwarding target prefixBGP community used to distribute the discard routeRouters drop traffic taking the target completely offline Attack completed however collateral damage limitedS-RTBHBehavior for match and filtering action defined in RFC 5635Requires pre-configuration of discard route on all edge routersMonitoring identifies source of attack and injects discard routeBGP community used to distribute the discard routeRouters drop traffic taking the target completely offline Each participating router can take 2 actions based on capabilities:Strict uRPF: On packet associated with a flow look up FIB determine if no route to originating prefix from the same interface discard else forwardLoose uRPF: On packet associated with a flow look up FIB determine if no route to originating prefix from any interface discard else forwardJunos Implementation12.1 T-series uRPF loose mode to recognize discard nH behavior12.2 MX uRPF loose mode to recognize discard nH behavior

6. Jflow Monitoring: versions and availabilityRE based monitoringSampled packets are sent to RERE generates flow recordsFlow v5 and v8 are supportedPerformance is ~7KppsService PIC based monitoring Sampled packets are sent to a PICPIC generates flow recordsFlow v5 ,v8 and v9 are supported for v9 (IPv4, IPv6, MPLS)Performance starts from 1Mpps (IPv4)Forwarding plane/Trio based monitoringAll processing done inside Trio (including flow records)IPFIX (version after v9) (IPv4 only)Performance is line rate (no sampling needed)

7. Security controls – BgP flowspec (RFC-5575)BGP Flowspec - Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements.Flow spec addresses the limitations of existing solutions by allowing the “flow”-based NLRI to convey additional information about traffic filtering rules for traffic that should be discarded Since a new address family is defined, filtering information is now separated from the routing information (and in fact this information is kept in a separate RIB: instance-name.inetflow.0) Provides a tool for Network Operators to quickly react to DDOS attacks, saving valuable time between identification of attack and implementation of various remediation schemes.

8. What is in the bgp flow spec NLRI?A Flow Specification NLRI is defined which may include several components in order to identify particular flowsThe NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as a 1 or 2 octet NLRI length field followed by a variable length NLRI value. The NLRI length is expressed in octets +------------------------------+ | length (0xnn or 0xfn nn) | +------------------------------+ | NLRI value (variable) | +------------------------------+  Type 1 - Destination Prefix Type 2 - Source Prefix Type 3 - IP Protocol Type 4 – Source or Destination Port Type 5 – Destination Port Type 6 - Source PortType 7 – ICMP TypeType 8 – ICMP Code Type 9 - TCP flagsType 10 - Packet lengthType 11 – DSCPType 12 - Fragment Encoding   

9. Flow Route OriginationThere are a couple of options:Configure static flow routes from a central control point (RR or IRCP) or from distributed control points (PE or Peering Edge) Supported today by Arbor Networks Flow Routes are automatically advertised by BGP once the Flow NLRI Control Plane is established

10. BGP address family: Flow-specA flow-spec “route” includes information about the action that should be taken for matching traffic (using BGP extended communities):Drop the packetSample the packet for CFLOW exportRate limit traffic to a rate included in the BGP updateMark traffic with a DSCP value included in the BGP updateRedirect traffic into a VRF routing instance specified by the BGP update

11. Flow-Spec exampleFlow-spec route is advertised into the networkAll web traffic from host A to host B should be droppedMatching traffic is automatically dropped by the first router that sees the dataFlow-spec route:Host A to Host B, TCP, HTTP: DropAB

12. Secure Clean Routing Using BGP (SCRUB)Traffic matching flow-spec routes can be redirected, not just droppedCreate tunnels (such as MPLS LSPs) from every router to a special scrubber routerTraffic matching the flow-spec routes is redirected into the tunnelsThe scrubber router directs traffic through security devices to inspect the trafficClean traffic is released back into the network

13. Secure Clean Routing Using BGP (SCRUB)A flow-spec route is currently advertised that selects all traffic from host A matching UDP port 53Matching traffic is tunneled to the SCRUBnet router and fully inspectedLegitimate traffic is released back into the network and routed normally to host BABFlow-spec route:Source: Host A, UDP, DNS: Redirect

14. Secure Clean Routing Using BGP (SCRUB)Traffic that doesn’t match any active flow-spec routes is routed normallyNo impact to non-suspect trafficABFlow-spec route:Source: Host A, UDP, DNS: Redirect

15. Additional Security controls – Services dpc/mpcServices DPC/MPC – Security Controls that can be scaled across multiple services blades in lieu of being processed in the RE (Better Performance - Scalable)Statefull FirewallNetflow (offloaded) Full IPSIPSEC Tunnels

16. Security Contols Development – JUNOS sDKJUNOS Software Development Kit (SDK) - Applications run on either a Routing Engine or a services module and so can be thought of as being either Routing Engine applications or service applications, respectively.Routing Engine applications run on the control plane. Typically, these applications perform network management and protocol signaling. They also initiate servers. Positioned on the control plane, Routing Engine applications can coordinate other subsystems and services. A Routing Engine is always present in any device, so these applications are always deployable without the addition of any extra hardware or software. Service applications run on the services plane. The services plane is specialized to enable high-performance, customized, and stateful packet processing on the transit or monitored traffic selected for servicing. Service applications may also perform operations similar to Routing Engine applications, but such activities typically supplement packet processing.On some of the smaller Juniper Networks devices, physical modules do not necessarily plug in to a chassis. Rather a single box contains the necessary hardware. Nonetheless, applications are still supported in the control and services planes and we continue to use the Routing Engine and services modules terminology.

17. Protecting the Routing Engine

18. Protecting the Routing Engine Firewall FilterUsing Prefix-lists to Group Hosts or Networks Using Apply-path to Build Dynamic Prefix-lists Using Policers to Rate-limit Traffic Firewall filters must be told in which direction to inspect traffic, and there are two directions in which to apply the filters: Input: Packets are matched against the firewall filter as they enter the interface from the network. Output: Packets are matched against the firewall filter as they leave the interface prior to reaching the network.

19. DDoS Protection To protect against DDoS attacks, you can configure policers for host-bound exception traffic. The policers specify rate limits for individual types of protocol control packets or for all control packet types for a protocol. You can monitor policer actions for packet types and protocol groups at the level of the router, Routing Engine, and line cards. You can also control logging of policer events. The policers at the Trio MPC are the first line of protection. Control traffic is dropped when it exceeds any configured policer values or, for unconfigured policers, the default policer values. Each violation generates a notification to alert operators about a possible attack. The violation is counted, the time that the violation starts is noted, and the time of the last observed violation is noted. When the traffic rate drops below the bandwidth violation threshold, a recovery timer determines when the traffic flow is consider to have returned to normal. If no further violation occurs before the timer expires, the violation state is cleared and a notification is generated. DDoS policers are present: One at the Trio chipset, two at the line card, and two at the Routing Engine.

20. Links

21. LinksDDoS Protection Configuration Guide http://www.juniper.net/techpubs/en_US/junos12.2/information-products/topic-collections/config-guide-ddos-protection/config-guide-ddos-protection.pdfThis Week: Hardening Junos Devices http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/hardening-junos-devices-checklist/Day One: Configuring Junos Policies and Firewall Filtershttp://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/configuring-junos-policies/ Day One: Securing the Routing Engine on M, MX, and T Serieshttp://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/ For iPads and iPhones, use your device’s iBook app. Search for “Juniper Networks” in the iBookstore. Download directly to your iPhone or iPad. For Kindles, Androids, Blackberry, iPhones/iPads, Macs. and PCs, download the free Kindle app for your device. Go to the Kindle Store using your device’s Kindle app and search for “Juniper.” Download directly to your device. 

22.