Phil Rodrigues, Sr Network Security Analyst, NYU ITS

1. Phil Rodrigues, Sr Network Security Analyst, NYU ITS Automated Policy Enforcement November 12, 2004

2. Automated Policy Enforcement NetReg Scan at UConn NetAuth Working Group NYU’s SafetyNet

3. Automated Policy Enforcement NetReg Scan at UConn

4. UConn: Prelude • During DefCon hundreds of Stealther • Blaster and Welchia stressed the need • Late August move-in

5. UConn: rpcscan • Nessus was too slow, nasl did not exist? • Developed by Keith Bessette and others • Based on exploit code • Fast scanner for one or many computers

6. UConn: NetReg Scan • Developed by Mike Lang and others • Forced rpcscan before it allowed access to NetReg • If client failed, redirected to patch website

7. UConn: Lessons Learned • Existing NetReg system was critical • Ability to create code was essential (c, perl) • Making a scanner is hard, use someone else’s • Good communication made for good neighbors

8. Automated Policy Enforcement NetAuth Working Group

9. NetAuth: Brief History • Educause / Internet2 Security Task Force • Working group started in May 2004 • Draft whitepaper August 2004, me and Eric Gauthier (BU) • “Strategies for Automating Network Policy Enforcement”

10. NetAuth: Common Classification • Registration • Detection • Isolation • Remediation

11. NetAuth: Registration • Must have it!

12. NetAuth: Detection • Active (nessus) • Passive (netflow) • Agent (commercial or home-grown) • Interval (once vs on-going)

13. NetAuth: Isolation • VLAN (homogenous) • IP (heterogenous) • Gateway (inline device)

14. NetAuth: Remediation • Local  Static (website)  Dymanic (SUS) • External (Windows Update)  Proxy (remember SSL)  Translation (routing issues)  Split-DNS (domain list)

15. NetAuth: Effective Practices Guide • Looking for working examples of each category  Home-grown agent  VLAN isolation  Perfigo / Cisco  Bradford  IPS  etc

16. Automated Policy Enforcement NYU’s SafetyNet

17. SafetyNet: High Level Goals • Base it on successful systems • Fairly self-sustaining • Scalable for 11,000+ ResNet, and more! • Practical implementation of NetAuth classification

18. SafetyNet: Initially Staff Intensive • Security Analyst (did not do much…) • Network Services management and staff (5 people) • Consultant (scanning cluster and perl glue) • Client Services and Publications • NYU specific, but basic strategy should be portable

19. SafetyNet: Pre-Existing Structure • Pre-existing ResNet registration system (1997!) • BIND and ISC DHCPD v3 • Static assignment DHCP infrastructure • perl glue

20. SafetyNet: Registration • Client authentication against netid • Housing lookup for room assignment • SNMP verification of location • If all that succeeds, start detection

21. SafetyNet: Detection • Initial active external detection • nmap and nessus / scanlite • Limited plugin set  rpc-dcom / rpcss  messenger  lsass • Perl glue to return consistent results

22. SafetyNet: Isolation • IP DHCP-based isolation • Had: Home-grown host management system • Needed: Conversion to DHCPD v3 • Too many vendors and vintages for VLAN

23. SafetyNet: Remediation • External dynamic NAT/Split-DNS remediation • Based on Fairfield University’s system • Private IP -> Split-DNS -> Cisco PBR -> PIX NAT • Detailed support website • Windows Update, Symantec LiveUpdate • Self re-scan. If pass, assigned public IP

24. SafetyNet: Metrics • 9,500 students through ResNet registration • 1,000 found to be vulnerable (10%) • 200 called Client Services (20%) (800 did not?) • Order of magnitude rule • 100 slipped through the cracks (1%) • Less than 50 vulnerable at any time (0.5%)

25. Conclusions • Well?

26. Links http://www.security.uconn.edu/old_site/netregscan/ http://www.security.uconn.edu/old_site/uconn_response.html http://security.internet2.edu/netauth/ http://security.internet2.edu/netauth/docs/draft-internet2-salsa-netauth-summary-02.html