Next-Generation Network Security: TechNet Augusta 2015
•Download as PPTX, PDF•
1 like•970 views
Tracy Ashton Senior Systems Engineer Juniper Networks
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Next-Generation Network Security: TechNet Augusta 2015
Similar to Next-Generation Network Security: TechNet Augusta 2015 (20)
More from AFCEA International
More from AFCEA International (20)
Recently uploaded
Recently uploaded (20)
Next-Generation Network Security: TechNet Augusta 2015
- 1. Next-Generation Firewall Security Updated for 2015 Tracy Ashton Juniper Networks tashton@juniper.net
- 2. Agenda – Next-generation firewall policies (RBAC) – Suite B and new IPSec protocols – Commercial Solutions for Classified (CSfC) – Real-time reputation-based threat blocking 9/3/2015
- 3. Typical stateful firewall policy • Source and Destination are IP addresses or networks – can be named, but names are usually local • Service usually maps to a TCP or UDP port number – some protocols are more sophisticated and use ALGs 9/3/2015
- 4. Source and Destination • We need a way to replace addresses with a standardized, organization-wide naming scheme • DNS names can be difficult to use in firewall policies – need to iterate through multiple addresses per name – reverse lookup often fails • User’s addresses change constantly • VM-based server addresses can change too – different techniques for users and servers 9/3/2015
- 5. Users • Firewall polls the domain controller: “best effort” – not an option for complex domain schemes • Complete internal security: 802.1x – local access requires the same security standards as remote access – must be implemented on all internal switches and APs – 802.1x controller can also populate user lists on next- generation firewalls – no more “hard on the outside, soft on the inside” 9/3/2015
- 6. 802.1x 802.1x looks very complex, but it’s easy to understand if you go step by step, and everyone will be using it soon... 9/3/2015 AD/LDAP/PKI/RSA Tablet/Notebook/Laptop Domain A Domain B Tablet/Notebook/Laptop Switches and APs Network Access Controller Protected Resource
- 7. 802.1x and dynamic firewall policies • Network access controller can add an authorized user to one or more firewall rules • Can be based on AD group membership • Control user access by adding and removing from AD groups, not by writing firewall policy per user • Controller to firewall communication is an emerging standard, so early implementations are proprietary 9/3/2015
- 8. Server movement • Modern datacenters use virtual machines • VM controllers move VMs during operation • Solution: VM controllers must provide an interface for firewall queries • Emerging standards, mostly proprietary today • Using DNS to define internet-based servers is difficult – but internal DNS is easier to control, and may be an option 9/3/2015
- 9. Source and Destination are no longer static, local objects: But what about the protocols? How do we know that TCP port 80 is carrying legitimate HTTP, not hidden P2P traffic... or worse? 9/3/2015
- 10. Track state at all protocol levels (courtesy of w3.org) 9/3/2015
- 11. Firewall plus intrusion detection and prevention • Advanced intrusion prevention techniques use protocol- specific state engines • Every communication between client and server is carefully matched against expected behavior • This allows for reliable identification of protocols, regardless of port number • We can also prevent the majority of zero-day attacks by imposing common-sense limits on communication • Intrusion detection signatures are integrated with state engines to reduce or eliminate false positives 9/3/2015
- 12. Next-generation firewalls: • Provide multiple methods for replacing static, address-based policies with dynamic, up-to-date lists of users and servers • Examine packets more thoroughly to guarantee that protocols are not being misused • Support scripting languages and provide an API for customization and integration with mgmt systems • Support advanced VPN features... 9/3/2015
- 13. Suite B – new algorithms for IPSec • NSA’s latest set of cryptographic algorithms: – 3DES replaced with AES-128, AES-256 – MD5 and SHA1 replaced with SHA-256, SHA-384 – RSA replaced with ECDSA, DH replaced with ECDH • The NSA never attempted to push weak algorithms; this was an over-interpretation of an EC-RNG error that the NSA later corrected 9/3/2015
- 14. Commercial Solutions for Classified http://www.nsa.gov/ia/programs/csfc_program/ If you select FW/VPN products from the NSA’s list... And layer one IPSec tunnel inside another... You can carry classified information on commonly available, off-the-shelf hardware 9/3/2015
- 15. Botnets, DDoS, and CnC hosts • User clicks on something, installs malware • User’s machine is now a ‘bot • Malware is quiet, evades detection, occasionally contacts internet-based Command and Control host • CnC operator waits for enough hosts to become bots, then issues attack command • Bots begin a Distributed Denial of Service attack against the CnC operator’s target 9/3/2015
- 16. Real-time reputation-based threat intelligence • For many years, DISA has provided a daily list of IP addresses that were involved in malicious activity • Service providers and major corporations are now joining together to produce similar intelligence • Addresses involved in attacks are uploaded to a community operated cloud service • Next-generation firewalls can subscribe to the service, and dynamically block known baddies • Still in development, but represents a fundamental advance in security techniques and capabilities 9/3/2015
- 17. Thank you for listening! Feel free to contact me with questions: tashton@juniper.net 9/3/2015
Editor's Notes
- RMS Early days Mainframe login account “rms” Richard Matthew Stallman, often known by his initials, rms, is a software freedom activist and computer programmer. Founder of the GNU project and Free Software Movement He campaigns for software to be distributed in a manner such that its users receive the freedoms to use, study, distribute and modify that software. Million dollar mainframes connected directly to the Internet with no firewalls to inspect traffic Server maintenance and security was costly. A well designed fw could protect poorly-secured Only stateless router filters(ACL’s) were available src; dst; protocol; port; header flags
- This policy allows the inside network to contact an internet-based DNS server. Because the firewall is stateful, no policy is needed to allow return packets; the outbound DNS request to the server will create a session, and reply packets will match that session entry, and will be allowed. I could replace the 192.168.1.0/24 with a local name like “home network” and replace the 4.2.2.2/32 with a local name like “DNS server”. In large networks, these firewall-specific naming schemes are hard to maintain and can lead to confusion.
- client has no IP address. User connects to physical switch port, or tries to connect to wireless AP switch/AP initiates 802.1x negotiation if client doesn’t support 802.1x, fall back to MAC authentication, or fail to connect if client supports 802.1x, client provides user’s certificate (from CAC) and endpoint security information this data is encapsulated in RADIUS by the switch or AP, then sent to the network access controller the controller performs AAA: verifies user certificate, does revocation checking, looks up the user’s Active Directory entry and downloads details like group membership if 802.1x supplicant supports additional checks, the controller might also examine the endpoint security status controller combines all security and user information received so far, and makes an access decision – normal access, special user group, endpoint needs remediation... controller sends the access decision to the switch or AP, and assigns a VLAN client receives an IP address in that VLAN controller can also send the user’s assigned address and their access rights to a next-generation firewall firewall can now add that user to a dynamic rule – for instance “HR Group” members get access to the “HR database server” resource
- A traditional stateful firewall monitors the state of TCP, UDP, and ICMP sessions (at layer 4 of the OSI model), so that reply packets that match an existing session are automatically allowed. A next generation firewall tracks layer 4 state, but also maintains the state of higher levels of protocol communication – NFS, HTTP, DNS, etc. at layers 5-7 of the OSI model. Even protocols that don’t maintain state between client and server (like UDP and HTTP) can be treated as state engines by the firewall. A traditional intrusion detection system examines individual packets for predefined patterns (signatures.) A next generation firewall’s intrusion prevention system examines entire flows, not individual packets, and associates signatures with particular protocol states, greatly reducing false positives. In the case of TCP, the finite state machine can be considered to describe the “life stages” of a connection. Each connection between one TCP device and another begins in a null state where there is no connection, and then proceeds through a series of states until a connection is established. It remains in that state until something occurs to cause the connection to be closed again, at which point it proceeds through another sequence of transitional states and returns to the closed state. The full description of the states, events and transitions in a TCP connection is lengthy and complicated—not surprising, since that would cover much of the entire TCP standard. For our purposes, that level of detail would be a good cure for insomnia but not much else. However, a simplified look at the TCP FSM will help give us a nice overall feel for how TCP establishes connections and then functions when a connection has been created.
- Example for state engine: DNS -- examine outbound request, does it look like a legitimate DNS query? Expect server response, examine for legitimacy. Examples for port number changes: HTTP carried over 8080 is just “HTTP”; bit torrent hidden in port 80 is identified as bit torrent, NOT http. Examples for zero-day attack prevention: HTTP queries should never be over 8092 characters, should never contain a binary zero; SMB filenames should only contain human-readable characters. Example for eliminating false positives: “wizard” is only an attempt to break into a mail server if issued at the very beginning of the SMTP session; “wizard” anywhere in an email is definitely not a malicious packet.