1 / 41

Terry Boult C. Edward Chow Department of Computer Science University of Colorado at Colorado Springs Leland Langston Ray

Terry Boult C. Edward Chow Department of Computer Science University of Colorado at Colorado Springs Leland Langston Raytheon.

kamana
Download Presentation

Terry Boult C. Edward Chow Department of Computer Science University of Colorado at Colorado Springs Leland Langston Ray

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Terry BoultC. Edward Chow Department of Computer Science University of Colorado at Colorado SpringsLeland LangstonRaytheon Part of this work is based on research sponsored by the Air Force Research Laboratory, under agreement number F49620-03-1-0207. It was sponsored by a NISSC Summer 2003 grant.

  2. Intrusion Related Research Areas • Intrusion Prevention • General Security Policy • Ingress/Egress Filtering • Intrusion Detection • Honey pot • Host-based IDS Tripwire • Anomaly Detection • Misuse Detection • Intrusion Response • Identification/Traceback/Pushback • Intrusion Tolerance

  3. R2 R1 R3 Alternate Gateways Wouldn’t it be Nice to Have Alternate Routes? net-a.mil net-b.mil net-c.mil ... ... ... ... A A A A A A A A DNS3 DNS1 DNS2 R R R How to reroute clients traffic through R1-R3?Multi-homing R DNS DDoS Attack Traffic Client Traffic Victim

  4. Secure Collective Defense • Main IdeaExplore secure alternate paths for clients to come in; Utilize geographically separated proxy servers. • Goal: • Provide secure alternate routes • Hide IP addresses of alternate gateways • Techniques: • Multiple Path (Indirect) Routing • Enhanced Secure DNS extension: how to inform client DNS servers to add new DNS entries with alternate routes (Not your normal DNS name/IP address mapping entry). • Utilize a consortium of Proxy servers with IDS that hides the IP address of alternate gateways. • Partition clients to come in at different proxy servers. can help identify the origin of spoofed attacks! • How clients use the new multiple path indirect DNS entries and route traffic through proxy servers? Use Sock protocol, modify resolver library

  5. R2 R1 R3 Alternate Gateways Implement Alternate Routes net-a.mil net-b.mil net-c.mil ... ... ... ... A A A A A A A A DNS3 DNS1 DNS2 R R R Need to Inform Clients or Client DNS servers!But how to tell which Clients are not compromised?How to hide IP addresses of Alternate Gateways? R DNS DDoS Attack Traffic Client Traffic Victim

  6. Possible Solution for Alternate Routes net-a.mil net-b.mil net-c.mil ... ... ... ... A A A A A A A A DNS3 DNS1 DNS2 R R R New route via Proxy3 to R3 Proxy2 Proxy1 Proxy3 Blocked by IDS Attack msgs blocked by IDS block R2 R R1 R3 Sends Reroute Command with DNS/IP Addr. Of Proxy and Victim Victim Distress Call

  7. net-b.mil net-c.mil net-a.mil SCOLDPhase1 ... ... ... ... A A A A A A A A DNS3 DNS1 DNS2 R R R Proxy2 Proxy3 Proxy1 block block R R1 R2 R3 RerouteCoordinator 1. IDS detects intrusion Blocks Attack Traffic Sends distress call to Reroute Coordinator Attack Traffic Client Traffic Victim

  8. Proxy3 net-b.mil net-c.mil net-a.mil SCOLDPhase 2 ... ... ... ... A A A A A A A A DNS3 DNS1 DNS2 R R R Proxy2 2. Sends Reroute Command with (DNS Name, IP Addr. Of victim, Proxy Server(s)) to DNS Proxy1 block R R1 R2 R3 RerouteCoordinator 1. IDS detects intrusion Blocks Attack Traffic Sends distress call to Reroute Coordinator Attack Traffic Client Traffic Victim

  9. Proxy3 net-b.mil net-c.mil net-a.mil SCOLDPhase3 ... ... ... ... A A A A A A A A 3. New route via Proxy3 to R3 3. New route via Proxy1 to R1 3. New route via Proxy2 to R2 DNS3 DNS1 DNS2 R R R Proxy2 Proxy1 2. Sends Reroute Command with (DNS Name, IP Addr. Of victim, Proxy Server(s)) to DNS block R R1 R2 R3 RerouteCoordinator Attack Traffic Client Traffic Victim

  10. Proxy3 net-b.mil net-c.mil net-a.mil SCOLDPhase4 ... ... ... ... A A A A A A A A 3. New route via Proxy3 to R3 3. New route via Proxy1 to R1 3. New route via Proxy2 to R2 DNS3 DNS1 DNS2 R R R Proxy2 Proxy1 4. Attack traffic detected by IDSblocked by Firewall block 4a. Attack traffic detected by IDSblocked by Firewall R R1 R2 R3 RerouteCoordinator Attack Traffic Client Traffic Victim

  11. SCOLD Secure DNS Updatewith New Indirect DNS Entries ClientDomain Trusted Domain WANDMZ Modified Bind9 Modified Bind9 proxy2 IP Tunnel Modified ClientResolveLibrary IP Tunnel New DNS Entries: (target.targetnet.com, 133.41.96.7, ALT 203.55.57.102) 203.55.57.103 185.11.16.49 A set of alternate proxy servers for indirect routes

  12. SCOLD Indirect Routing IP tunnel IP tunnel

  13. SCOLD Indirect Routing with Client running SCOLD client daemon IP tunnel IP tunnel

  14. Performance of SCOLD v0.1 • Table 1: Ping Response Time (on 3 hop route) • Table 2: SCOLD FTP/HTTP download Test (from client to target)

  15. Current SCOLD Project Results • Proposed new DNS entries for intrusion tolerance, containing multiple proxy servers info for establishing indirect routes. • Modified Bind9 DNS server to accept secure DNS updates and to serve queries with new indirect DNS entries. • Developed new secure DNS update utility to securely update target zone file in the new enhanced Bind9 DNS server. • Implemented new secure indirect routing protocol • to allow client DNS to query target DNS during DDoS attack. • to allow client to communicate with target server through proxy server and alternate gateway.

  16. Benefits of Secure Collective Defense • Security • When attacked, users switch to different routes dynamically • Urgent/critical packets sent over multiple routes simultaneously • Encrypted content sent over multiple routes • Information on DDoS attacks used to isolate source of attacks • Reliability: • Users can choose most reliable route dynamically • Packet content spread over multiple routes • Use redundant transmission or error correction to reduce PLR • Performance: • Multiple indirect routes provide additional bandwidth • Can be used for dynamic bandwidth provisioning

  17. A2D2: Autonomous Anti DDoS • Main Idea  Integrate enhanced IDS with adaptive firewall for autonomous intrusion defense. • Goal: • Automate adaptive intrusion handling triggered by enhanced intrusion detection • Investigate the impact of various intrusion types on QoS • Techniques: • Enhanced Snort Plug-in with subnet spoofing detection • Adaptive rate limiting firewall with user defined threshold and intrusion history.

  18. A2D2 Multi-Level Adaptive Rate Limiting For Anti-DDos Defense

  19. A2D2 Results – Non-stop Attack • Packets Received: 8,039 • Retransmission Request: 2,592 • Retransmission Received: 35 • Lost: 2,557 • Connection Timed-out QoS Experienced at A2D2 Client

  20. A2D2 Results – UDP AttackMitigation: Firewall Policy • Packets Received: 23,407 • Retransmission Request: 0 • Retransmission Received: 0 • Lost: 0 QoS Experienced at A2D2 Client

  21. A2D2 Results – ICMP AttackMitigation: Firewall Policy • Packets Received: 7,127 • Retransmission Request: 2,105 • Retransmission Received: 4 • Lost: 2,101 • Connection Timed-out QoS Experienced at A2D2 Client

  22. A2D2 Results – ICMP AttackMitigation: Firewall Policy & CBQ • Packets Received: 23,438 • Retransmission Request: 0 • Retransmission Received: 0 • Lost: 0 QoS Experienced at A2D2 Client

  23. A2D2 Results – TCP AttackMitigation: Policy+CBQ • Packets Received: 22,179 • Retransmission Request: 4,090 • Retransmission Received: 2,641 • Lost: 1,449 • Screen Quality Impact QoS Experienced at A2D2 Client

  24. A2D2 Results – TCP AttackMitigation: Policy+CBQ+Rate • Packets Received: 23,444 • Retransmission Request: 49 – 1,376 • Retransmission Received: 40 – 776 • Lost: 9 – 600 QoS Experienced at A2D2 Client

  25. SGFR: Secure Groupware for First Responder • Main Idea  design a framework for enhancing security of groupware packages such as instant messenger and video monitoring/conferencing tool. • Goal: • Investigate proper interface between group rekeying system and groupware. • Develop secure instant messaging system with remote group file download and remote display. • Experiment the prototype software on PDA with mobile ad hoc network. • Integrate with stress level and tool usage effectiveness evaluation • This is a joint project with Dr. Chip Benight of psychology department at UCCS. • Techniques: • Scalable group key management (Keystone from UT Austin) • Efficient groupware (Jabber Instant Messaging System) • Mobile Ad Hoc Network (NIST)

  26. SGFR Features Psychology EvaluationStress Level Tracking Effectiveness of Tool Usage(Keyboard/Mouse Event Tracking,History of Commands, Mistakes, Popup Quiz?) Security Enhanced GroupwareInstant messenger(JabberX) Group Key ManagmentSecure Group Rekeying system(Keystone) Group Communication Server Instant Messaging Server (Jabber)

  27. Group key distribution Registration/authentication Sign-in create/join chat groups Encrypt/Decrypt msgs using group key SGFR System Architecture SGFR Client SGFR Group Key Server SGFR Instant MessengerServer SGFR Client SGFR Client

  28. SGFR System Operation

  29. Associate JabberX client with Keyserver and Jabber server • Users login to the Jabber server • If login successful, the client registers with the Keyserver. • When a user creates/joins a group, the Keyserver gives a key to the client. • When a user leaves the group, the Keyserver generates a new key for the remaining members of the group.

  30. First group key assigned to group User ganesh joining group g1 Second group key assigned to groupWhen a member joined Output of the Keystone Server User ayen joining group g1

  31. Packet captured by Ethereal Packet Sniffer Encrypted “Hello” Surrounded by <body>tag Output of the Jabber server running on a machine

  32. Testing Results Table 1 time taken for client registration group join, group leave Table 2 time taken for file transfer

  33. Conclusion • A secure group communication software package SGFR v.0 was developed. • Use Digital Certificate to authenticate client access. • Group keys are distributed when members join/leave or based on some time period. • Group key is used to encrypted the messages. • Enhanced Jabber-based text chat with remote file download and remote display. • Ported the SGFR v.0 to run on handheld devices include iPAQ PDA running Linux and Sony PalmTop with 802.11b mobile ad hoc network.

  34. Secure Wireless Access Control • Goal: • Compare performance of two proposed wireless authentication protocols, PEAP vs. TTLS. • Develop a PEAP module for freeRadius server on Linux. • Techniques/Tools used: • Xsupplicant, Window XP • freeRadius, Win 2003 server • OpenSSL

  35. UCCS Secure Wireless Access Testbed RADIUS Client

  36. Machine Spec IP Address OS Software wiper.uccs.edu 1.8 Ghz, 1 GB RAM RADIUS Server and DHCP server 128.192.61.132 RedHat 9.0 Running Linux 2.2.20-19.9 kernel FreeRadius Modified CVS snapshot radiusd-09.03.03.tar.gz willow.uccs.edu Access Point Cisco Aironet 1200 128.192.61.130 RedHat 9.0 Running Linux 2.2.20-19.9 kernel Cisco 1200 series Software Toshiba – 366 Mhz, 512 MB Wireless Client Using Cisco Aironet 350 PC Card Dynamic IP address 128.192.61.144 to 128.98.61.152 RedHat 6.2 running Linux 2.2.20-19.9 kernel Open1x Xsupplicant Version 9.0 Hobbit – 1 Ghz Dell Optiplex, 512 MB Wireless Client Using Cisco Aironet 350 PCI Card Dynamic IP address 128.192.61.144 to 128.98.61.152 Windows XP-SP1 And RedHat 9.0 Running Linux 2.2.20.9 kernel Open1x Xsupplicant for Linux and built in Service Pack for XP Client/Server Machine Configurations

  37. PEAP vs. TTLS on Toshiba machine PEAP TTLS Average 1046 949 Variance 8142 12060

  38. PEAP vs. TTLS Average Performance

  39. Conclusion • Developed a Radius Server on Linux that supports both PEAP and TTLS. • PEAP is relatively more influenced by Client’s processor speeds, distance range and network transient nature as compared to TTLS. • Although the higher performance shown by TTLS over PEAP is negligible, it is worth noting that TTLS was outperforming PEAP on an average by 10% in all the tests. • The enhanced Radius Server can serve both Windows and Linux clients.

  40. Autonomous Anti-DDoS

More Related