VMworld 2016: Migrating from a hardware based firewall to NSX to improve performance and compliance, with iain leiter
Download as PPTX, PDF4 likes1,605 views
Iain Leiter from A.T. Still University discussed their organization's migration from a hardware-based firewall to NSX to improve performance and compliance. Some key advantages of NSX include distributed firewalling for high performance and scalability, pay-as-you-grow flexibility, and advanced security features like microsegmentation. Their deployment process involved installing NSX, defining security groups, building security policies using syslog data from "recon rules", and applying a common services policy. Discoveries included many backdoors, application architecture issues, and the security benefits of microsegmentation.
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to VMworld 2016: Migrating from a hardware based firewall to NSX to improve performance and compliance, with iain leiter (20)
Ad
More from VMworld (17)
Recently uploaded (20)
VMworld 2016: Migrating from a hardware based firewall to NSX to improve performance and compliance, with iain leiter
- 1. Group Discussion: Migrating from a Hardware Based Firewall to NSX to Improve Performance and Compliance, with Iain Leiter Iain Leiter, ATSU NET10706-GD #NET10706
- 2. Introduction Who are you and what is A.T. Still University? iain leiter Network Engineer 10+ years of IT networking experience – Certified VMware VCIX6-NV Responsibilities include LAN, WAN, Wireless, Network Security, plus lots more in a technologically diverse medical university environment www.linkedin.com/in/iainleiter
- 3. Agenda • Technical and business challenges • Technology evaluation process • The advantages of NSX as a firewall solution • Our microsegmentation design • Our deployment process • Discoveries we’ve made along the way
- 4. Technical and Business Challenges • Need to separate sensitive clinical, academic, and business systems • Firewall sizing risks - possible future scalability issues • Performance Requirements • High Resolution Histology Imaging application • Academic classroom video capture and VOD • Ongoing firewall bandwidth constraints • Reduce costs
- 6. Firewall Technologies Considered or Evaluated • More physical firewalls • OS-based software firewalls • Windows Firewall • Linux Firewalls • AV Firewalls • Virtualized firewalls from other vendors • Cisco ASAv • Cisco ASA1000V • Cisco VSG • SDN/SDDC solutions • ACI + hardware • NSX
- 7. The advantages of NSX (DFW) as a firewall solution • Distributed firewalling provides high performance and scalability • Security Policies applied to the VM’s vNIC • Firewall bandwidth capacity grows as server hardware is added
- 8. The advantages of NSX (DFW) as a firewall solution • Pay as you grow flexibility • Buy what you need • No firewall sizing risk
- 9. The advantages of NSX (DFW) as a firewall solution • Firewall capacity mobility – move firewall capacity between sites (licenses)
- 10. The advantages of NSX (DFW) as a firewall solution • Additional visibility for improved compliance Monitor firewalling between VMs on the same segment
- 11. The advantages of NSX (DFW) as a firewall solution • Advanced Security Features – Microsegmentation & Automation! • Security Benefit - Firewall policy is enforced at the VM’s vNIC • Independent of the guest OS or underlying network hardware • BONUS – Additional NSX Features (*VXLAN, Routing, Load-Balancing) • SIDENOTE: *NSX Distributed Firewall is not dependent on VXLAN • Simplified incremental migration • Enable Security Policy one application or VM at a time
- 12. Our microsegmentation design • Use Service Composer • Application X and Y are isolated from each other even though they are on the same subnet. • The Security Policies of the tiers of each application only permit the necessary ports required for inter-tier communication
- 13. Our deployment process (“brown field”) • Install NSX Manager Virtual Appliance ova & register with VCenter • Deploy the firewall VIB bundles to hosts • Change Security Policy ”Default Applied To” value: Security Groups • Use centralized logging (Log Insight or Splunk) • Create ”COMMON-SERVICES” Security Policy • With last rule of DENY ANY-ANY • Define Security Groups and their members • Build Security Policy for each Security Group (based on Syslog) • Final Step – Apply “COMMON-SERVICES” Security Policy to the SG
- 14. Set Security Policy to apply to Security Groups 1 2
- 15. Use centralized logging (Log Insight or Splunk) CRITICAL STEP! • Visibility • Troubleshooting
- 16. Create ”COMMON-SERVICES” Security Policy With last rule of DENY ANY-ANY Ports required by all • NTP-OUT • DNS-OUT • SYSLOG-OUT • SNMP-IN • DHCP-OUT? • WINDOWS UPDATES • AV-OUT • ADMIN-PORTS-IN • LAST RULE • ANY-ANY DENY (enable logging)
- 17. Brown Field Firewall Policy Assumptions • Default allow all traffic any-any out of the box (don’t kill the environment!) • Incremental migration to zero-trust (whitelist) for all applications • Use “recon rules” with Splunk to build policy for brown field systems (this process could also be used to troubleshoot green field deployment)
- 18. Rule creation process using ”Recon Rules” & Splunk • Create a new Security Group & Security Policy for the Application • Assign SP to the SG and create two firewall “recon” rules • ANY-OUT (allow and LOG) • ANY-IN (allow and LOG) • Monitor Splunk and use the log data to build new rules for valid traffic • Each new permit rule should be created ABOVE the recon rules (no logging) • Once all valid traffic is defined, remove the recon rules and assign the ”COMMON-SERVICES” Security Policy (any traffic not matching a rule will ultimately be dropped by implicit deny).
- 19. Security Groups and Security Policies 1. Define Security Groups for each Application and Application Tier (Add VMs or Create Dynamic Membership Rule) 2. Build Security Policy & apply to Security Group (Create rules for traffic based on Syslog data) 3. Final Step – Apply “COMMON-SERVICES” Security Policy to the SG (FIREWALL IS NOW ACTIVE – Drops will be logged)
- 20. Discoveries we’ve made along the way • Prevalence of vendor installed remote support backdoors • Identification and mitigation of internal application architecture security issues • The profound security implications of a microsegmented design • (VM) Monitor > Service Composer > Firewall Rules (See ALL rules assigned to the VM!) • Centralized Syslog provides great visibility for troubleshooting and auditing • Self-cleaning Firewall Policies – Less stale ACLs to pick through! • Basic firewall policy automation – Not difficult
- 21. Firewall Policy Automation .. Dynamic SG Membership
- 22. Firewall Policy Automation .. for mere mortals
- 23. Key Feature: View all rules applied to a VM
- 24. Recommended Resources NSX Hands on Labs (HOL) http://labs.hol.vmware.com/ • HOL-SDC-1603 VMware NSX Introduction • HOL-SDC-1625 VMware NSX Advanced VMworld Sessions • SEC8348 Deploying Security in a Brownfield Environment • NET7944 NSX Brownfield Deployment Best Practice LucidChart.com – 100% Web-based diagramming tool with live collaboration Splunk or LogInsight
- 25. Questions? iain leiter Network Engineer 10+ years of IT networking experience – Certified VMware VCIX6-NV Responsibilities include LAN, WAN, Wireless, Network Security, plus lots more in a diverse medical university environment www.linkedin.com/in/iainleiter
- 26. CONFIDENTIAL26
- 28. Group Discussion: Migrating from a Hardware Based Firewall to NSX to Improve Performance and Compliance, with Iain Leiter Iain Leiter, ATSU NET10706-GD #NET10706