1. 1 DACAManet Proposer’s Workshop UCCS-Raytheon Terry Boult C. Edward Chow Department of Computer Science University of Colorado at Colorado Springs Leland Langston Raytheon Terry Boult C. Edward Chow Department of Computer Science University of Colorado at Colorado Springs Leland Langston Raytheon 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. 2 DACAManet Proposer’s Workshop UCCS-Raytheon 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 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. 3 DACAManet Proposer’s Workshop UCCS-Raytheon Wouldn’t it be Nice to Have Alternate Routes? DNS1... Victim AAAAAAAA net-a.milnet-b.milnet-c.mil DNS2 DNS3... RRR R R2 R1 R3 Alternate Gateways DNS DDoS Attack Traffic Client Traffic How to reroute clients traffic through R1-R3? Multi-homing

4. 4 DACAManet Proposer’s Workshop UCCS-Raytheon 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 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. 5 DACAManet Proposer’s Workshop UCCS-Raytheon Implement Alternate Routes DNS1... Victim AAAAAAAA net-a.milnet-b.milnet-c.mil DNS2 DNS3... RRR R R2 R1 R3 Alternate Gateways DNS DDoS Attack Traffic Client Traffic 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?

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

7. 7 DACAManet Proposer’s Workshop UCCS-Raytheon SCOLD Phase1 DNS1... Victim AAAAAAAA net-a.mil net-b.milnet-c.mil DNS2 DNS3... RRR R Proxy1 Proxy2 Proxy3 R2R2 R1 R3 block Reroute Coordinator Attack Traffic Client Traffic 1. IDS detects intrusion Blocks Attack Traffic Sends distress call to Reroute Coordinator block

8. 8 DACAManet Proposer’s Workshop UCCS-Raytheon SCOLD Phase 2 DNS1... Victim AAAAAAAA net-a.mil net-b.milnet-c.mil DNS2 DNS3... RRR R Proxy1 Proxy2 Proxy3 R2R2 R1 R3 block Attack Traffic Client Traffic 1. IDS detects intrusion Blocks Attack Traffic Sends distress call to Reroute Coordinator Reroute Coordinator 2. Sends Reroute Command with (DNS Name, IP Addr. Of victim, Proxy Server(s)) to DNS

9. 9 DACAManet Proposer’s Workshop UCCS-Raytheon SCOLD Phase3 DNS1... Victim AAAAAAAA net-a.mil net-b.milnet-c.mil DNS2 DNS3... RR R Proxy1 Proxy2 Proxy3 R2R2 R1 R3 Attack Traffic Client Traffic Reroute Coordinator 2. Sends Reroute Command with (DNS Name, IP Addr. Of victim, Proxy Server(s)) to DNS 3. New route via Proxy3 to R3 3. New route via Proxy2 to R2 3. New route via Proxy1 to R1 R block

10. 10 DACAManet Proposer’s Workshop UCCS-Raytheon SCOLD Phase4 DNS1... Victim AAAAAAAA net-a.mil net-b.milnet-c.mil DNS2 DNS3... R Proxy1 Proxy2 Proxy3 R1 Attack Traffic Client Traffic Reroute Coordinator 3. New route via Proxy3 to R3 3. New route via Proxy2 to R2 3. New route via Proxy1 to R1 R block 4a. Attack traffic detected by IDS blocked by Firewall 4. Attack traffic detected by IDS blocked by Firewall RR R3 R2R2

11. 11 DACAManet Proposer’s Workshop UCCS-Raytheon SCOLD Secure DNS Update with New Indirect 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 New DNS Entries: Modified Bind9 IP Tunnel Modified Client Resolve Library Trusted Domain WAN DMZ Client Domain proxy2

12. 12 DACAManet Proposer’s Workshop UCCS-Raytheon SCOLD Indirect Routing IP tunnel

13. 13 DACAManet Proposer’s Workshop UCCS-Raytheon SCOLD Indirect Routing with Client running SCOLD client daemon IP tunnel

14. 14 DACAManet Proposer’s Workshop UCCS-Raytheon 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) Table 1: Ping Response Time (on 3 hop route) Table 2: SCOLD FTP/HTTP download Test (from client to target) No DDoS attack direct route DDoS attack direct route No DDoS attack indirect route DDoS attack indirect route 0.49 ms225 ms0.65 ms

15. 15 DACAManet Proposer’s Workshop UCCS-Raytheon 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. 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. 16 DACAManet Proposer’s Workshop UCCS-Raytheon 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 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. 17 DACAManet Proposer’s Workshop UCCS-Raytheon 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. 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. 18 DACAManet Proposer’s Workshop UCCS-Raytheon

19. 19 DACAManet Proposer’s Workshop UCCS-Raytheon A2D2 Multi-Level Adaptive Rate Limiting For Anti-DDos Defense

20. 20 DACAManet Proposer’s Workshop UCCS-Raytheon A2D2 Results – Non-stop Attack Packets Received: 8,039 Retransmission Request: 2,592 Retransmission Received: 35 Lost: 2,557 Connection Timed-out Packets Received: 8,039 Retransmission Request: 2,592 Retransmission Received: 35 Lost: 2,557 Connection Timed-out QoS Experienced at A2D2 Client

21. 21 DACAManet Proposer’s Workshop UCCS-Raytheon A2D2 Results – UDP Attack Mitigation: Firewall Policy Packets Received: 23,407 Retransmission Request: 0 Retransmission Received: 0 Lost: 0 Packets Received: 23,407 Retransmission Request: 0 Retransmission Received: 0 Lost: 0 QoS Experienced at A2D2 Client

22. 22 DACAManet Proposer’s Workshop UCCS-Raytheon A2D2 Results – ICMP Attack Mitigation: Firewall Policy Packets Received: 7,127 Retransmission Request: 2,105 Retransmission Received: 4 Lost: 2,101 Connection Timed-out Packets Received: 7,127 Retransmission Request: 2,105 Retransmission Received: 4 Lost: 2,101 Connection Timed-out QoS Experienced at A2D2 Client

23. 23 DACAManet Proposer’s Workshop UCCS-Raytheon A2D2 Results – ICMP Attack Mitigation: Firewall Policy & CBQ Packets Received: 23,438 Retransmission Request: 0 Retransmission Received: 0 Lost: 0 Packets Received: 23,438 Retransmission Request: 0 Retransmission Received: 0 Lost: 0 QoS Experienced at A2D2 Client

24. 24 DACAManet Proposer’s Workshop UCCS-Raytheon A2D2 Results – TCP Attack Mitigation: Policy+CBQ Packets Received: 22,179 Retransmission Request: 4,090 Retransmission Received: 2,641 Lost: 1,449 Screen Quality Impact Packets Received: 22,179 Retransmission Request: 4,090 Retransmission Received: 2,641 Lost: 1,449 Screen Quality Impact QoS Experienced at A2D2 Client

25. 25 DACAManet Proposer’s Workshop UCCS-Raytheon A2D2 Results – TCP Attack Mitigation: Policy+CBQ+Rate Packets Received: 23,444 Retransmission Request: 49 – 1,376 Retransmission Received: 40 – 776 Lost: 9 – 600 Packets Received: 23,444 Retransmission Request: 49 – 1,376 Retransmission Received: 40 – 776 Lost: 9 – 600 QoS Experienced at A2D2 Client

26. 26 DACAManet Proposer’s Workshop UCCS-Raytheon 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) 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)

27. 27 DACAManet Proposer’s Workshop UCCS-Raytheon SGFR Features Security Enhanced Groupware Instant messenger (JabberX) Group Communication Server Instant Messaging Server (Jabber) Psychology Evaluation Stress Level Tracking Effectiveness of Tool Usage (Keyboard/Mouse Event Tracking, History of Commands, Mistakes, Popup Quiz?) Group Key Managment Secure Group Rekeying system (Keystone)

28. 28 DACAManet Proposer’s Workshop UCCS-Raytheon SGFR System Architecture SGFR Client SGFR Group Key Server SGFR Instant Messenger Server Group key distribution Sign-in create/join chat groups Registration/authentication Encrypt/Decrypt msgs using group key

29. 29 DACAManet Proposer’s Workshop UCCS-Raytheon SGFR System Operation

30. 30 DACAManet Proposer’s Workshop UCCS-Raytheon 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. 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.

31. 31 DACAManet Proposer’s Workshop UCCS-Raytheon Output of the Keystone Server User ganesh joining group g1 User ayen joining group g1 First group key assigned to group Second group key assigned to group When a member joined

32. 32 DACAManet Proposer’s Workshop UCCS-Raytheon Packet captured by Ethereal Packet Sniffer Output of the Jabber server running on a machine Encrypted “Hello” Surrounded by tag

33. 33 DACAManet Proposer’s Workshop UCCS-Raytheon Testing Results RunsClient Registration Time (ms) Group Join Time (ms)Group Leave Time (ms) 1279.62233.46135.54 2249.28652.74126.78 3253.93706.04769.08 4259.46118.15434.12 Avg/Run260.57427.59366.38 Table 1 time taken for client registration group join, group leave File sizeTime Taken (ms) 8.5K35302.47 25K105986.05 60K305934.53 195K1007949.38 Table 2 time taken for file transfer

34. 34 DACAManet Proposer’s Workshop UCCS-Raytheon 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. 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.

35. 35 DACAManet Proposer’s Workshop UCCS-Raytheon 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 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

36. 36 DACAManet Proposer’s Workshop UCCS-Raytheon UCCS Secure Wireless Access Testbed Client RADIUS

37. 37 DACAManet Proposer’s Workshop UCCS-Raytheon Client/Server Machine Configurations Machine SpecIP AddressOSSoftware wiper.uccs.edu 1.8 Ghz, 1 GB RAM RADIUS Server and DHCP server 128.192.61.132RedHat 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.130RedHat 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

38. 38 DACAManet Proposer’s Workshop UCCS-Raytheon PEAP vs. TTLS on Toshiba machine PEAPTTLS Average1046 949 Variance814212060

39. 39 DACAManet Proposer’s Workshop UCCS-Raytheon PEAP vs. TTLS Average Performance

40. 40 DACAManet Proposer’s Workshop UCCS-Raytheon 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. 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.

41. 41 DACAManet Proposer’s Workshop UCCS-Raytheon Autonomous Anti-DDoS