campus network security and security repercussions n.
Skip this Video
Loading SlideShow in 5 Seconds..
Campus Network Security and Security Repercussions PowerPoint Presentation
Download Presentation
Campus Network Security and Security Repercussions

Campus Network Security and Security Repercussions

157 Vues Download Presentation
Télécharger la présentation

Campus Network Security and Security Repercussions

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Campus Network Security and Security Repercussions Pete Siemsen 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: • ICMP traceback proposal: see itrace • IP traceback:

  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

  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:

  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 •

  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

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

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

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

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

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

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

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

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

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

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