1. 1 Network Security Issues Pete Siemsen siemsen@ucar.edu National Center for Atmospheric Research April 24 th, 2002

2. 2 Obstacles to Security Doesn’t mesh well with research Security is a lose-lose proposition! 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 And when it works, no one notices Considered low priority (few resources) Security not always taken seriously

3. 3 Types of Threats Viruses Packet sniffing Denial of service Probing for holes Wireless

4. 4 Viruses Hard to battle Mail-borne Web-borne Filtering

5. 5 Packet Sniffing Switches are better than hubs Try to reduce cleartext passwords on the net: ban telnet in favor of ssh

6. 6 Denial of Service Usually short-lived Must back-track to source, installing filters as you go Distributed DoS can’t be blocked No magic bullet

7. 7 Probing for holes “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

8. 8 Wireless security Built-in WEP is insecure Your wireless net may be wide open to anyone Details at http://www.scd.ucar.edu/nets/projects/wirele ss/ http://www.scd.ucar.edu/nets/projects/wirele ss/

9. 9 Case study: NCAR

10. 10 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

11. 11 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

12. 12 Getting Started

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

14. 14 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 http://www.ncar.ucar.edu/csac

15. 15 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

16. 16 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

17. 17 Basic Solutions at NCAR One-time passwords Switched LANs Router packet filtering Application-proxy gateways Filter email attachments

18. 18 One-time Passwords 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!

19. 19 Switched LANs Reduces packet eavesdropping Get this for “free” with switched network Can still steal ARP entries

20. 20 Packet Filtering

21. 21 Router-Based Filters 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 Filters reject dangerous packets Filters accept all useful packets

22. 22

23. 23 Packet Filtering At NCAR Cisco access-lists filter on IP address source, destination, ranges Interfaces: inbound and/or outbound Protocols, TCP ports, etc. We filter inbound and outbound packets Performance can be an issue

24. 24 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

25. 25 Example Filter Statistics 41 lines (rules) in NCAR’s 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

26. 26 Exposed Hosts 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

27. 27 Security Administrator Provides focus for security for the entire institution Helps deal with break-ins Central point of contact Tracks CERT advisories for sysadmins Advocates security solutions, like ssh Scans exposed hosts for standards violations Generally helps/educates sysadmins

28. 28 Impacts of NCAR’s Security

29. 29 Benefits >99% of NCAR hosts are protected Outbound Telnet, HTTP, etc. still work Relatively cheap and easy Dial-in users are “inside”, no changes

30. 30 Drawbacks UDP is blocked Some services are no longer available Inbound pings are blocked !!! To use FTP, must use passive mode, or use an exposed host, or proxy through the Gateway DNS and email can get complicated

31. 31 Drawbacks (cont.) Crunchy outside, chewy inside Modems in offices are a huge hole Users must install VPN or ssh software for remote access

32. 32 Wrapup

33. 33 Security is Never “Done” How do you know if you’re being hacked? “Silent” attacks very hard to detect “Noisy” attacks hard to distinguish from other network (or host) problems Network keeps changing Software keeps changing Hackers keep advancing

34. 34 Security is Never “Done” (cont.) Policy and security mechanisms must evolve Security committee continues to meet

35. 35 Conclusion NCAR struck a balance between: Convenience and Security Politics and Technology Cost and Quality