Phil Rodrigues Sr Network Security Analyst NYU ITS

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

Automated Policy Enforcement Net. Reg Scan at UConn Net. Auth Working Group NYU’s Safety. Net 2

Automated Policy Enforcement Net. Reg Scan at UConn 3

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

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 5

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

UConn: Lessons Learned • • Existing Net. Reg 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 7

Automated Policy Enforcement Net. Auth Working Group 8

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

Net. Auth: Common Classification • • Registration Detection Isolation Remediation 10

Net. Auth: Registration • Must have it! 11

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

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

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

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

Automated Policy Enforcement NYU’s Safety. Net 16

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

Safety. Net: 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 18

Safety. Net: Pre-Existing Structure • • Pre-existing Res. Net registration system (1997!) BIND and ISC DHCPD v 3 Static assignment DHCP infrastructure perl glue 19

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

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

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

Safety. Net: 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 Live. Update • Self re-scan. If pass, assigned public IP 23

Safety. Net: Metrics • • • 9, 500 students through Res. Net 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%) 24

Conclusions • Well? 25

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