Terry Boult C. Edward Chow

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
Wouldnt 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
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
R2
block
R
R1
R3
Sends Reroute Command with DNS/IP Addr. Of
Proxy and Victim
Victim
Distress Call
7
SCOLDPhase1
net-b.mil
net-c.mil
net-a.mil
...
...
...
...
A
A
A
A
A
A
A
A
DNS3
DNS1
DNS2
R
R
R
Proxy2
Proxy3
Proxy1
block
block
R
R2
R1
R3
RerouteCoordinator
1. IDS detects intrusion Blocks Attack
Traffic Sends distress call to Reroute
Coordinator
Attack Traffic
Client Traffic
Victim
8
SCOLDPhase 2
net-b.mil
net-c.mil
net-a.mil
...
...
...
...
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
R2
R1
R3
RerouteCoordinator
1. IDS detects intrusion Blocks Attack
Traffic Sends distress call to Reroute
Coordinator
Attack Traffic
Client Traffic
Victim
9
SCOLDPhase3
net-b.mil
net-c.mil
net-a.mil
...
...
...
...
A
A
A
A
A
A
A
A
3. New route via Proxy3 to R3
3. New route via Proxy2 to R2
3. New route via Proxy1 to R1
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
R2
R1
R3
RerouteCoordinator
Attack Traffic
Client Traffic
Victim
10
SCOLDPhase4
net-b.mil
net-c.mil
net-a.mil
...
...
...
...
A
A
A
A
A
A
A
A
3. New route via Proxy3 to R3
3. New route via Proxy2 to R2
3. New route via Proxy1 to R1
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
R3
R2
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
(target.targetnet.com, 133.41.96.7, ALT
203.55.57.102) 203.55.57.103 185.11.16.49
New DNS Entries
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)

No DDoS attack direct route DDoS attackdirect route No DDoS attack indirect route DDoS attack indirect route
0.49 ms 225 ms 0.65 ms 0.65 ms
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
(No Transcript)
19
A2D2 Multi-Level Adaptive Rate Limiting For
Anti-DDos Defense
20
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
21
A2D2 Results UDP AttackMitigation Firewall
Policy

• Packets Received 23,407
• Retransmission Request 0
• Retransmission Received 0
• Lost 0

QoS Experienced at A2D2 Client
22
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
23
A2D2 Results ICMP AttackMitigation Firewall
Policy CBQ

• Packets Received 23,438
• Retransmission Request 0
• Retransmission Received 0
• Lost 0

QoS Experienced at A2D2 Client
24
A2D2 Results TCP AttackMitigation PolicyCBQ

• Packets Received 22,179
• Retransmission Request 4,090
• Retransmission Received 2,641
• Lost 1,449
• Screen Quality Impact

QoS Experienced at A2D2 Client
25
A2D2 Results TCP AttackMitigation
PolicyCBQRate

• Packets Received 23,444
• Retransmission Request 49 1,376
• Retransmission Received 40 776
• Lost 9 600

QoS Experienced at A2D2 Client
26
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)

27
SGFR Features
Psychology EvaluationStress Level
Tracking Effectiveness of Tool Usage(Keyboard/Mou
se Event Tracking,History of Commands, Mistakes,
Popup Quiz?)
Security Enhanced GroupwareInstant
messenger(JabberX)
Group Communication Server Instant Messaging
Server (Jabber)
Group Key ManagmentSecure Group Rekeying
system(Keystone)
28
SGFR System Architecture
SGFR Client
SGFR Group Key Server
SGFR Instant MessengerServer
SGFR Client
SGFR Client
29
SGFR System Operation
30
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.

31
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
32
Packet captured by Ethereal Packet Sniffer
Encrypted Hello Surrounded by ltbodygttag
Output of the Jabber server running on a machine
33
Testing Results
Table 1 time taken for client registration group
join, group leave
Runs Client Registration Time (ms) Group Join Time (ms) Group Leave Time (ms)
1 279.62 233.46 135.54
2 249.28 652.74 126.78
3 253.93 706.04 769.08
4 259.46 118.15 434.12
Avg/Run 260.57 427.59 366.38
Table 2 time taken for file transfer
File size Time Taken (ms)
8.5K 35302.47
25K 105986.05
60K 305934.53
195K 1007949.38
34
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.

35
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

36
UCCS Secure Wireless Access Testbed
RADIUS
Client
37
Client/Server Machine Configurations
38
PEAP vs. TTLS on Toshiba machine
PEAP TTLS Average 1046 949 Variance 8142 12060
39
PEAP vs. TTLS Average Performance
40
Conclusion

• Developed a Radius Server on Linux that supports
  both PEAP and TTLS.
• PEAP is relatively more influenced by Clients
  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
Autonomous Anti-DDoS