Campus Network Security and Security Repercussions

1. Campus Network Security and Security Repercussions Pete Siemsen siemsen@ucar.edu National Center for Atmospheric Research July 28th, 2002

2. Overview • Obstacles to security • Overview of threats and solutions • Case study: NCAR

3. Obstacles to Security • Doesn’t mesh well with research • Considered low priority (few resources) • Not always taken seriously

4. Obstacles to Security • Security implementers may not be appreciated. • Too little security, it’s your fault: “We got hacked, you should’ve done more” • Too much security, it’s your fault: “I can’t get my work done, you should do less” • When it works, no one notices

5. Types of Threats • Viruses • Packet sniffing • Denial of service • Scanning for holes • Wireless

6. Viruses: problems • Hard to battle • Mail-borne • Web-borne • Instant Messaging ?

7. Viruses: solutions • Scan email • block executable attachments • Virus scanning software helps, but new viruses are not immediately detected

8. Packet Sniffing: problems • Your users may type passwords on foreign networks • Switches are better than hubs, but do not protect you fromLayer 2 attacks

9. Packet sniffing: problems • dsniff suite for overloading switches, spoofing ARPs, man-in-middle, etc. • ettercap for injecting commands in someone else’s session

10. Packet Sniffing: solutions • Use switches instead of hubs or repeaters • Consider MAC address locking • Consider SecureID • Ban telnet in favor of ssh • Use VPNs for remote access • Run ARPwatch

11. Denial of Service: problems • Distributed DoS can’t be blocked • No magic bullet • Luckily, attacks are usually short-lived • See trinoo and stacheldracht

12. Denial of Service: solutions • Must back-track to source, installing filters as you go to reduce pain • Install patches to keep your systems from becoming part of the problem • Scan for client code on your systems • Filter ICMP

13. Denial of Service: solutions • Dave Dietrich's DDOS website: staff.Washington.edu/Dietrich/wise/ddos • ICMP traceback proposal: see itrace • IP traceback: www.cs.washington.edu/homes/savage/papers/Sigcomm00.pdf

14. Scanning for holes: problems • “script kiddies” are unsophisticated hackers who run software “kits” to attack a target. They don’t have to understand networking. • Software scans for open ports and known vulnerabilities

15. Scanning for holes: solutions • Apply vendor patches in a timely manner • Filter packets inbound • Scan your own systems • Use an intrusion detection system • See www.dshield.org

16. Wireless: problems

17. Wireless: problems

18. Wireless: problems

19. Wireless: problems

20. Wireless: problems

21. Wireless: problems

22. Wireless: problems

23. Wireless: problems

24. Wireless: problems • WEP is insecure (see Kismet, Airsnort, WEPcrack) • Can’t track down attackers easily • Physical security is harder • You may not own all the access points!

25. Wireless: solutions • Tune access point power • Don’t count on WEP: use VPNs • Requires extra network engineering • Wardrive/netstumble with Kismet, Airsnort, WEPcrack • IETF is working on better standards

26. Wireless: solutions • Current issue of SysAdmin • David Packham’s URL list: www.scd.ucar.edu/nets/projects/Westnet/prev-mtg/200206.meeting/0602.meeting/0602.presentations/dave.packham.url.list.html

27. Case study: NCAR

28. NCAR’s Environment • Academic research institution • But no students! • Collaboration with 63 member Universities • ~1500 university (external) users • Diverse, widespread field projects • ~2500 networked nodes internal to NCAR • ~1500 internal users

29. NCAR’s Motivation to Get Serious About Security • We experienced increasing malicious attacks • More hackers hacking • Availability of script kiddie “kits” • Easy to get • Don’t require network expertise • We had some strong advocates

30. Getting Started

31. NCAR Security Committee • We created a committee to develop policy • Sysadmins from all NCAR Divisions • Formal process delivered institutional buy-in • 2-hour meetings once a month • Lots of cooperation, little authority • With time, authority has grown

32. The Security Policy • Need a policy that defines • vulnerabilities • how much security is needed • level of inconvenience that is tolerable • solutions • We recommended a full-time Security Administrator for the institution • www.ncar.ucar.edu/csac

33. Define Scope of Problem • Decide which types of attacks are problems • Examples: • Hacker spoofing of source IP address • Hacker scanning for weaknesses • TCP/UDP ports, INETD services • Hackers sniffing passwords • Hacker exploitation of buggy operating systems • Inconsistent/tardy OS patching

34. Define Scope of Solution • What we won’t do • Not feasible to secure every computer • Over-reliance on timely OS security fixes • Can’t prohibit internal “personal” modems • Attacks from within aren’t a big problem • What we will do • Reduce external attacks from the Internet

35. Basic Solutions at NCAR • One-time passwords (critical devices) • Switched LANs • Packet filtering on routers • Application-proxy gateways • Filter email attachments • Encryption for wireless and remote access (VPNs and ssh)

36. A.K.A. Challenge-Response Requires little calculator things (~$50/per) Prevents password sniffing We use it on critical devices Routers, ATM Switches, Ethernet Switches, Remote Access Servers, Server hosts (root accounts) At the least, do this! One-time Passwords

37. Switched LANs • Reduces packet eavesdropping • Get this for “free” with switched network • Hackers can still steal ARP entries • Hackers can still fill CAM tables

38. Packet Filtering

39. Used to construct router-based firewall around your internal network Main security implementation tool Routers check each inbound packet against filter criteria and accept or reject Router-Based Filters

41. Routers can filter on IP address source, destination, ranges Interfaces: inbound and/or outbound Protocols, TCP ports, etc. We filter inbound and outbound packets Performance is no longer an issue with modern routers Packet Filtering At NCAR

42. Filter Stance: Strong or Weak? • Strong • Deny everything, except for the good stuff • Weak • Allow everything, except for the bad stuff • NCAR chose a Strong stance

43. Example Filter Statistics • 41 lines (rules) in NCAR’s old Cisco access-list • Hits as of 9/30/98, 28 days after filter was installed: • 3 MP Denied because of spoofing • 17 MP Denied because of “catchall” • 71 MP Permitted to exposed networks • 100MP Permitted to exposed hosts

44. Example: Web servers, data source machines, etc. Must meet stringent security standards to avoid being compromised and used as launch pads for attacking protected hosts OS restricts set of network services allowed Must keep up with OS patches Exposed Hosts

45. Intrusion Detection • NCAR uses SNORT and Network Flight Recorder to look for suspect patterns in packets.

46. VPNs • Virtual Private Network: an encrypted tunnel from one point to another over an untrusted network. • NCAR uses VPNs or ssh for all remote connections to NCAR networks. Mostly used by travelers and home users with DSL or cable modems.

47. Wireless at NCAR • We filter all wireless packets • The filters are established and removed as wireless machines connect and disconnect • VPN users are passed through

48. Internet NCAR router bridge Wireless at NCAR client BSD Unix host client AP client AP client VPN server DHCP server client client

49. Internet NCAR router bridge Wireless at NCAR client BSD Unix host NCAR staff user client AP client AP client VPN server DHCP server client client

50. NCAR Internet router bridge DNS Wireless at NCAR client BSD Unix host client AP client AP client DHCP server 1 client Guest user