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

• LocalStatic (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 categoryHome-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 setrpc-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