1 DACAManet Proposer’s Workshop UCCS-Raytheon Terry Boult C. Edward Chow Department of Computer Science University of Colorado at Colorado Springs Leland

1DACAManet Proposer’s Workshop UCCS-Raytheon

Terry BoultC. Edward Chow

Department of Computer ScienceUniversity of Colorado at Colorado Springs

Leland LangstonRaytheon

Terry BoultC. Edward Chow

Department of Computer ScienceUniversity of Colorado at Colorado Springs

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


Intrusion Related Research AreasIntrusion Related Research Areas

Intrusion PreventionGeneral Security Policy Ingress/Egress Filtering

Intrusion DetectionHoney potHost-based IDS Tripwire Anomaly DetectionMisuse Detection

Intrusion Response Identification/Traceback/Pushback Intrusion Tolerance

Intrusion PreventionGeneral Security Policy Ingress/Egress Filtering

Intrusion DetectionHoney potHost-based IDS Tripwire Anomaly DetectionMisuse Detection

Intrusion Response Identification/Traceback/Pushback Intrusion Tolerance


Wouldn’t it be Nice to Have Alternate Routes?Wouldn’t it be Nice to Have Alternate Routes?

DNS1

...

Victim

AA A A A A A A

net-a.mil net-b.mil net-c.mil

DNS2 DNS3

... ......

R R R

R

R2 R1R3

Alternate Gateways

DNS

DDoS Attack Traffic

Client Traffic

How to reroute clients traffic through R1-R3?

Multi-homing


Secure Collective DefenseSecure Collective Defense Main IdeaExplore 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


Implement Alternate RoutesImplement Alternate Routes

DNS1

...

Victim

AA A A A A A A


DNS2 DNS3

... ......

R R R

R

R2 R1R3

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?


Possible Solution for Alternate RoutesPossible Solution for Alternate Routes

DNS1

...

Victim

AA A A A A A A


DNS2 DNS3

... ......

R R R

R R2R1 R3

New route via Proxy3 to R3

Proxy1

block

Proxy3Proxy2

Attack msgs blocked by IDSBlocked by IDS

Sends Reroute Command with DNS/IP Addr. Of

Proxy and VictimDistress Call


SCOLDPhase1SCOLDPhase1

DNS1

...

Victim

AA A A A A A A


DNS2 DNS3

... ......

R R R

R

Proxy1

Proxy2Proxy3

R2

R1 R3

block

RerouteCoordinato

rAttack TrafficClient Traffic

1. IDS detects intrusion Blocks Attack Traffic Sends distress call to Reroute Coordinator

block


SCOLDPhase 2SCOLDPhase 2

DNS1

...

Victim

AA A A A A A A


DNS2 DNS3

... ......

R R R

R

Proxy1

Proxy2 Proxy3

R2

R1 R3

block

Attack TrafficClient Traffic

1. IDS detects intrusion Blocks Attack Traffic Sends distress call to Reroute Coordinator

RerouteCoordinato

r

2. Sends Reroute Command with (DNS Name, IP Addr. Of victim,

Proxy Server(s)) to DNS



DNS1

...

Victim

AA A A A A A A


DNS2 DNS3

... ......

R R

R

Proxy1

Proxy2 Proxy3

R2

R1 R3


RerouteCoordinato

r

2. Sends Reroute Command with (DNS Name, IP Addr. Of victim,

Proxy Server(s)) to DNS

3. New route via Proxy3 to R3



R

block



DNS1

...

Victim

AA A A A A A A


DNS2 DNS3

... ......

R

Proxy1

Proxy2Proxy3

R1


RerouteCoordinato

r




R

block4a. Attack traffic detected by IDSblocked by Firewall

4. Attack traffic detected by IDSblocked by Firewall

R R

R3R2


SCOLD Secure DNS Updatewith New Indirect DNS EntriesSCOLD Secure DNS Update

with New Indirect DNS Entries

(target.targetnet.com, 133.41.96.7, ALT 203.55.57.102)

203.55.57.103185.11.16.49

A set of alternate proxy servers for indirect routes

New DNS Entries:

Modified

Bind9

Modified

Bind9IP Tunnel

IP Tunnel

Modified

ClientResolveLibrary

Trusted DomainWAN

DMZ

ClientDomai

n

proxy2


SCOLD Indirect RoutingSCOLD Indirect Routing

IP tunnelIP tunnel


SCOLD Indirect Routing with Client running SCOLD client daemon

SCOLD Indirect Routing with Client running SCOLD client daemon

IP tunnelIP tunnel


Performance of SCOLD v0.1Performance 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

with DDoS attack indirect route Doc

Size

FTP HTTP FTP HTTP FTP HTTP FTP HTTP 100k 0.11 s 3.8 s 8.6 s 9.1 s 0.14 s 4.6 s 0.14 s 4.6 s 250k 0.28 s 11.3 s 19.5 s 13.3 s 0.31 s 11.6 s 0.31 s 11.6 s 500k 0.65 s 30.8 s 39 s 59 s 0.66 s 31.1 s 0.67 s 31.1 s 1000k 1.16 s 62.5 s 86 s 106 s 1.15 s 59 s 1.15 s 59 s 2000k 2.34 s 121 s 167 s 232 s 2.34 s 122 s 2.34 s 123 s

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


Current SCOLD Project ResultsCurrent 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.


Benefits of Secure Collective DefenseBenefits 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


A2D2: Autonomous Anti DDoSA2D2: 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.


Attack

Attack Attack

Private Subnet192.168.0

Attack Network128.198.61

IP: 128.198.61.12NM: 255.255.255.128

GW: 128.198.61.1

eth0

Pluto

Titan

DMZ

Multi-LevelRate Limiting

Class-BasedQueuing(CBQ)

as Linux Router

Firewall(iptables)

Security Policy

IP: 192.168.0.1NM: 255.255.0.0

GW: 128.198.61.12

eth1

RealServer

Re

alS

erv

er

Tra

ffic

IDS

Ale

rts

tr

igg

er

Mu

lti-L

eve

lR

ate

-Lim

itin

g

IDS

70

% H

TT

P,

Re

alP

laye

r

1

5%

SM

TP

, P

OP

3

1

0%

SS

H,

SF

TP

5

% S

YN

, IC

MP

, D

NS

10 Mbps Hub

eth0

IP: 192.168.0.2NM: 255.255.0.0GW: 192.168.0.1

Public Network128.198

Internet

Alpha128.198.61.15

DDoSAgent

Gamma128.198.61.17

DDoSAgent

Beta128.198.61.16

DDoSAgent

Delta128.198.61.18

DDoSAgent

SimulatedInternet

100Mpbs Switch

Master Client& Handler

DDoS

Saturn128.198.61.11

NM: 255.255.255.128GW: 128.198.61.1

Autonomous Anti-DDoS Network(A2D2)

Client1128.198.a.195

Real Player Client

Client2128.198.b.82

Real Player Client

Client3128.198.c.31

Real Player Client

100Mpbs Switch


A2D2 Multi-Level Adaptive Rate Limiting For

Anti-DDos Defense

A2D2 Multi-Level Adaptive Rate Limiting For

Anti-DDos Defense

IP: 128.198.61.12NM: 255.255.255.128

GW: 128.198.61.1

eth0

Firewall Gateway


as Linux Router

IP: 192.168.0.1NM: 255.255.0.0

GW: 128.198.61.12

eth1

IDS

snort.confFloodPreprocessor

Threshold

snort.confFloodRateLimiter

PreprocessorThresholds

rateif.conflevels, rate,expiration,port # etc.

./snort -A UNSOCK

report.c./alert

rateif.pl

Level 4

Open(5 days)

Level 3

100 p/s

Level 2

50 p/s

Level 1

Block(2 hrs)

Level 0

Block(2 days)

Level 1Expires


A2D2 Results – Non-stop AttackA2D2 Results – Non-stop Attack

Packets Received: 8,039

Retransmission Request: 2,592

Retransmission Received: 35

Lost: 2,557

Connection Timed-out




Lost: 2,557


QoS Experienced at A2D2 Client


A2D2 Results – UDP AttackMitigation: Firewall Policy

A2D2 Results – UDP AttackMitigation: Firewall Policy


Retransmission Request: 0 Retransmission Received: 0 Lost: 0





A2D2 Results – ICMP AttackMitigation: Firewall Policy

A2D2 Results – ICMP AttackMitigation: Firewall Policy




Lost: 2,101





Lost: 2,101




A2D2 Results – ICMP AttackMitigation: Firewall Policy & CBQ

A2D2 Results – ICMP AttackMitigation: Firewall Policy & CBQ







A2D2 Results – TCP AttackMitigation: Policy+CBQ

A2D2 Results – TCP AttackMitigation: Policy+CBQ



Retransmission Received: 2,641

Lost: 1,449

Screen Quality Impact



Retransmission Received: 2,641

Lost: 1,449

Screen Quality Impact



A2D2 Results – TCP AttackMitigation: Policy+CBQ+RateA2D2 Results – TCP Attack

Mitigation: Policy+CBQ+Rate


Retransmission Request: 49 – 1,376

Retransmission Received: 40 – 776

Lost: 9 – 600


Retransmission Request: 49 – 1,376

Retransmission Received: 40 – 776

Lost: 9 – 600



SGFR: Secure Groupware for First Responder

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)


SGFR FeaturesSGFR Features

Security Enhanced GroupwareInstant messenger

(JabberX)

Group Communication ServerInstant Messaging Server

(Jabber)

Psychology EvaluationStress Level Tracking

Effectiveness of Tool Usage(Keyboard/Mouse Event Tracking,History of Commands, Mistakes,

Popup Quiz?)

Group Key ManagmentSecure Group

Rekeying system(Keystone)


SGFR System ArchitectureSGFR System Architecture

SGFR Client

SGFR Client

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


SGFR System Operation SGFR System Operation

Registrar

JabberXclient

ControlManager

KeyServer

Jabber Server

DataBroadcast

JabberXClient

JabberXClient

Multicast/Unicast

Rekey messages

Rekey messages

Registration

Requests

ApplicationData


Associate JabberX client with Keyserver and Jabber server

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.


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 groupWhen a member

joined


Packet captured by Ethereal Packet Sniffer

Output of the Jabber server running on a machine

Encrypted “Hello”

Surrounded by <body>tag


Testing ResultsTesting Results

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 1 time taken for client registration group join, group leave

File size Time Taken (ms)

8.5K 35302.47

25K 105986.05

60K 305934.53

195K 1007949.38

Table 2 time taken for file transfer


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


Secure Wireless Access ControlSecure 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


UCCS Secure Wireless Access TestbedUCCS Secure Wireless Access Testbed

Client

RADIUS


Client/Server Machine ConfigurationsClient/Server Machine Configurations

Machine Spec IP Address OS Software

wiper.uccs.edu1.8 Ghz, 1 GB RAMRADIUS Server and

DHCP server

128.192.61.132 RedHat 9.0Running Linux

2.2.20-19.9 kernel

FreeRadiusModified

CVS snapshot radiusd-

09.03.03.tar.gz

willow.uccs.eduAccess 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 ClientUsing Cisco Aironet

350 PC Card

Dynamic IP address

128.192.61.144to

128.98.61.152

RedHat 6.2 running Linux 2.2.20-19.9

kernel

Open1x XsupplicantVersion 9.0

Hobbit – 1 Ghz Dell Optiplex, 512 MBWireless Client

Using Cisco Aironet 350 PCI Card

Dynamic IP address

128.192.61.144to

128.98.61.152

Windows XP-SP1And RedHat 9.0 Running Linux 2.2.20.9 kernel

Open1x Xsupplicant for

Linux and built in Service Pack for

XP


PEAP vs. TTLS on Toshiba machine

PEAP vs. TTLS on Toshiba machine

PEAP vs TTLS[Toshiba - 366.604mhz]

500600700800900

100011001200130014001500

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

No. of Runs

Tim

e in

ms

ec

TTLS

PEAP

PEAP TTLS

Average 1046 949

Variance 8142 12060


PEAP-TTLS Average Performances over varying Distances

800

900

1000

1100

1200

1300

1400

1500

DIST1 DIST2 DIST3 DIST4 DIST5

Distance Range

Ave

rag

e-T

ime/

mse

c

PEAP

TTLS

PEAP vs. TTLS Average Performance

PEAP vs. TTLS Average Performance


ConclusionConclusion

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.


Autonomous Anti-DDoSAutonomous Anti-DDoS

IDIP DiscoveryCoordinator

FirewallIDIP Neighbor

Class-BasedQueuing

(CBQ)

Firewall(iptables)

Security Policy


eth0 eth1

Local IDS ResponseMulti-Level Adaptive

Rate Limiting

EnhancedIDS

+IDIP Application Layer

Cooperative TracebackCooperative Detection

Net RestructuringIntrusion Pushback

TracebackMsg Sent

IDIPNeighbor

NotificationTo IDIP

DiscoveryCoordinator

Rates Dependenton Traffic Type

SnortAlerts

InternetTraffic

Documents

1 DACAManet Proposer’s Workshop UCCS-Raytheon Terry Boult C. Edward Chow Department of Computer Science University of Colorado at Colorado Springs Leland