UCCS Network/System Security Research

1. UCCS Network/System Security Research C. Edward ChowXiaobo Joe ZhouYu CaiGanesh Godavari Department of Computer Science University of Colorado at Colorado Springs Some of the research projects are sponsored by the Air Force Research Laboratory, under agreement number F49620-03-1-0207. It was sponsored by NISSC Summer/Fall2003 grants.Part of these results are supported by a generous gift from Fujitsu for Internet research.

2. Outline of the Talk Overview of Network/System Security Research Projects at Network/System Lab • Secure Collective Internet Defense (SCOLD): an Intrusion Tolerance System. • Autonomous Anti-DDoS (A2D2: )Integrated enhanced Snort IDS with multi-level adaptive rate limiting firewall • Secure Groupware for First Responders (SGFR): Integrated Group Rekeying (Keystone) with Instant Massaging (Jabber) on MANET • Secure Access Mobile Ad Hoc Network (SMANET): Implemented PEAP module on freeRadius server, compared PEAP with TTLS • First Responder Sensor Network (FRSN): Track Fire Fighters with Crossbow Mote-based Sensor Network. • Improving System Performance by QoS Regulations with Adaptive Resource Management under Cyber Threats • Intelligence/Information Fusion • Secure Information Sharing

3. UCCS Network/System Research Lab • Director: Dr. C. Edward Chow (Network/Protocol) • Assistant Professor: Dr. Xiaobo Zhou (Distributed Systems; QoS) • Graduate students: • John Bicknell/Steve McCaughey/Anders Hansmat: Distributed Network Restoration/Network Survivability • Hekki Julkunen: Dynamic Packet Filter • Chandra Prakash: High Available Linux kernel-based Content Switch • Ganesh Godavari: Linux based Secure Web Switch • Angela Cearns: Autonomous Anti-DDoS (A2D2) Testbed • Longhua Li: IXP-based Content Switch • David Wikinson: Secure DNS (update/query) with multiple indirect routing entries • Nirmala Bulusu: Secure Wireless Access; PEAP vs. TTLS; enhance freeRadius server with PEAP module • (the above graduated) • Yu Cai (Ph.D. research assistant): Proxy Server Based Multipath Routing; Secure Collective Internet Defense; Information Fusion; • Ganesh Godavari:(Ph.D. research assistant): Content Switching Rule Conflict Detection; Secure Groupware; First Responder Sensor Network; Secure Information Sharing • Frank Watson: enhanced TCP with multiple routes (User Mode Linux) • Paul Fong: Wireless AODV Routing for sensor networks • Murthy Andukuri/Jing Wu: iSCSI/VPN/MPLS Secure QoS Storage Network. • Patricia Ferrao/Merlin Vincent: Web-based Collaborative System • Sarah Jelinek: Enterprise Intrusion Detection and Response System (A2D2V2).

4. UCCS Network Lab Equipment • Gigabit fiber connection to UCCS backbone • Switch/Firewall/Wireless AP: • HP 4000 switch; 4 Linksys/Dlink Switches; 5 Intel 24 ports Fast Ethernet switch. • Sonicwall Pro 300 Firewall; 6 Intel VPN Firewall • 8 Intel 7112 SSL accelerators; 4 7820 XML directors donated by Intel. • Cisco 1200 Aironet Dual Band Access Point and 350 client PC/PCI cards (both 802.11a and 802.11b cards). • Intel IXP12EB network processor evaluation board • Servers: Two Dell PowerEdge Servers. • Workstations/PCs: • 8 Dell PCs (3Ghz-500Mhz); 12 HP PCs (500-233Mhz) • 2 laptop PCs with Aironet 350 for mobile wireless • 1 IPAQ3875 PDA • OS: Linux Redhat 9, Fedora; Window XP/2000/2003

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

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

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

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

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

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

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

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

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

14. SCOLD Indirect Routing IP tunnel IP tunnel

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

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

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

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

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

20. Organic Networking IDC3(data backup) • One possible approach: Dynamic provisioning of multiple paths (direct and indirect routes) • Use secure DNS update to inform the clients • Use secure indirect routing for establishing alternate routes. • Coordinate the selection of proxy servers for clients. • Critical for supporting wide area IDC system backup resource IDC2(BtoB/C portal) IDC1(inB portal) Operation resource Operation resource Sharing inB BtoB inB BtoC The Internet VPN-CUG VPN-CUG VPN Headquarters Consumer enterprise Branch

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

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

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

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

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

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

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

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

30. Autonomous Anti-DDoS Organic Security System?

31. 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)

32. 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)

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

34. SGFR System Operation

35. Associate JabberX client with Keyserver and Jabber server • Users login to the Jabber server • If login successful, the client registers with the Keyserver by presenting digital certificate. • When a user creates/joins a group, the Keyserver issues a group key to the client. • When a user leaves the group, the Keyserver generates a new group key for the remaining members of the group. • Group key can be refreshed periodically. • Group key are used to encrypt data and authenticate the group.

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

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

38. Testing Results IBM Thinkpad Intel Pentium III 800MHz Server; IPAQ PDA StrongArm200MHz; Linux 2.4 Kernel; 802.11b Ad hoc Mode with NIST driver Table 1 time taken for client registration group join, group leave Table 2 time taken for file transfer

39. 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. • Lesson1: Fire fighters do not like stylus input and they carry heavy load!! • Lesson2: Fire fighter don’t care security; Police do!! • 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.

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

41. UCCS Secure Wireless Access Testbed RADIUS Client

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

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

44. PEAP vs. TTLS Average Performance

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

46. First Responder Sensor Network Goal: How wireless sensor network can assist first responders. Status:Created a wireless sensor testbed with Crossbow Professional Mote Kits and Intel stargate gateway devices. Current Tasks: • Investigate how to deploy sensor networks (pre-planned/dynamically deployed). • Develop algorithms for tracking first responders using wireless sensors. • Security in SMANET+FRSN.

47. Scenario 1:Preplanned Wireless Sensors • Building is surveyed and deployed with wireless sensors and include floor plan info in the gateway device. • When there is fire, first responders can tap into the secure wireless sensor network to find the condition of the building and over with the floor plan picture.

48. Scenario 2: Dynamically Deploy Sensors • Fire Fighter drops the wireless sensors along the route in. • If sensors detects temperature increase or location movement!!, they relay the date through multiple hop wireless sensor network to both the team inside and the team outside.

49. Secure Access to Sensor Network • Terrorist may access the sensors and information on the gateway. • Need authentication for secure access. • Need encryption for avoid sniffing by terrorist. • Need redundancy for fault tolerance and verifying the sensor results.

50. Improving System Performance by QoS Regulations with Adaptive Resource Management under Cyber ThreatsXiaobo Joe Zhou