Transcript ITSmeeting

Network and Wireless Security
C. Edward Chow
Department of Computer Science
University of Colorado at Colorado Springs
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
NISSC Summer/Fall2003 grants.
ITS-ZeeWave Meeting 2/26/2004
1
UCCS Chow
Outline of the Talk

Overview of Network/Wireless Security Research Projects of Network/System Lab
 Secure Collective Internet Defense (SCOLD)
– Modified Bind9 server and Secure DNS update with new DNS entries
containing multiple indirect routing info
– Implemented Secure Indirect Routing Protocol
 Autonomous Anti-DDoS (A2D2)
– Integrated enhanced Snort IDS with multi-level adaptive rate limiting firewall
– Design enterprise IDS/IHS with IDIP.
 Secure Groupware for First Responders (SGFR)
– Integrated Group Rekeying with Instant Massaging
– Run on Linux-based IPAQ/Palmtop with MANET.
 Secure Mobile Ad Hoc Network (SMANET)
– Implemented PEAP module on freeRadius server
– Compared performance of PEAP vs. TTLS
– Investigate how to defense cyber attacks on MANET.
 First Responder Sensor Network (FRSN)
– Track Fire Fighters with Crossbow Mote-based Sensor Network.
– Design Interface between SMANET and FRSN.
ITS-ZeeWave Meeting 2/26/2004
2
UCCS Chow
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
ITS-ZeeWave Meeting 2/26/2004
Tolerance
3
UCCS Chow
Wouldn’t it be Nice to Have Alternate Routes?
net-a.mil
A
A
net-b.mil
A ... A
net-c.mil
...
DNS1
A
A
DNS3
DNS2
R
R
R
R
DNS
R3
DDoS Attack Traffic
Client Traffic
Victim
ITS-ZeeWave Meeting 2/26/2004
A ... A
...
R2
R1
How to reroute clients
traffic through R1-R3?
Multi-homing
Alternate
Gateways
4
UCCS Chow
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
ITS-ZeeWave Meeting 2/26/2004
5
UCCS Chow
Implement Alternate Routes
net-a.mil
A
A
net-b.mil
A ... A
net-c.mil
...
DNS1
A
A
DNS3
DNS2
R
A ... A
...
R
R
Need to Inform Clients or
Client DNS servers!
R
DNS
R3
DDoS Attack Traffic
Client Traffic
Victim
ITS-ZeeWave Meeting 2/26/2004
R2
Alternate
Gateways
6
R1
But how to tell which Clients
are not compromised?
How to hide
IP addresses of
Alternate Gateways?
UCCS Chow
Possible Solution for Alternate Routes
net-a.mil
A
A
net-b.mil
A ... A
net-c.mil
...
DNS1
A
A
DNS3
DNS2
R
A ... A
...
R
R
New route via Proxy3 to R3
Proxy2
Proxy1
Proxy3
Attack msgs blocked by IDS
Blocked by IDS
block
R
R2
R1
R3
Victim
Sends Reroute Command
with DNS/IP Addr. Of
Proxy and Victim
Distress Call
ITS-ZeeWave Meeting 2/26/2004
7
UCCS Chow
net-b.mil
net-a.mil
net-c.mil
...
A
A
A
...
...
A
SCOLD
Phase1
Victim
ITS-ZeeWave Meeting 2/26/2004
A
Proxy3
Proxy1
Attack Traffic
Client Traffic
...
R
Proxy2
block
A
DNS3
R
R1
A
DNS2
DNS1
R
A
block
R
2
R
R3
Reroute
Coordinator
1. IDS detects intrusion
Blocks Attack Traffic
Sends distress call to Reroute Coordinator
8
UCCS Chow
net-b.mil
net-a.mil
net-c.mil
...
A
A
A
...
...
A
SCOLD
Phase 2
A
A
DNS3
R
R
Proxy2
Proxy3
2. Sends Reroute Command with
(DNS Name, IP Addr. Of victim,
Proxy Server(s)) to DNS
Proxy1
block
R1
...
A
DNS2
DNS1
R
A
R
2
R
R3
Reroute
Coordinator
1. IDS detects intrusion
Blocks Attack Traffic
Sends distress call to Reroute Coordinator
Attack Traffic
Client Traffic
Victim
ITS-ZeeWave Meeting 2/26/2004
9
UCCS Chow
net-b.mil
net-a.mil
net-c.mil
...
A
A
A
...
...
A
3. New route via
Proxy1 to R1
R
A
...
A
DNS3
DNS2
R
R
Proxy2
Proxy3
Proxy1
block
R1
A
3. New route via
Proxy3 to R3
3. New route via
Proxy2 to R2
DNS1
SCOLD
Phase3
A
R
2
R
Attack Traffic
Client Traffic
R3
2. Sends Reroute Command with
(DNS Name, IP Addr. Of victim,
Proxy Server(s)) to DNS
Reroute
Coordinator
Victim
ITS-ZeeWave Meeting 2/26/2004
10
UCCS Chow
net-b.mil
net-a.mil
net-c.mil
...
A
A
A
...
...
A
3. New route via
Proxy1 to R1
R
...
A
R
Proxy2
Proxy3
Proxy1
block
R1
A
DNS3
DNS2
R
4a. Attack traffic
detected by IDS
blocked by Firewall
A
3. New route via
Proxy3 to R3
3. New route via
Proxy2 to R2
DNS1
SCOLD
Phase4
A
R
2
R
Attack Traffic
Client Traffic
R3
4. Attack traffic
detected by IDS
blocked by Firewall
Reroute
Coordinator
Victim
ITS-ZeeWave Meeting 2/26/2004
11
UCCS Chow
SCOLD Secure DNS Update
with New Indirect DNS Entries
Client
Domain
Modified
Bind9
Trusted Domain
WAN
DMZ
Modified
Bind9
proxy2
Modified
Client
Resolve
Library
New DNS Entries:
IP Tunnel
(target.targetnet.com, 133.41.96.7, ALT 203.55.57.102)
ITS-ZeeWave Meeting 2/26/2004
203.55.57.103
185.11.16.49
12
A set of alternate proxy servers
for indirect routes
UCCS Chow
SCOLD Indirect Routing
IP tunnel
ITS-ZeeWave Meeting 2/26/2004
IP tunnel
13
UCCS Chow
SCOLD Indirect Routing with Client
running SCOLD client daemon
IP tunnel
ITS-ZeeWave Meeting 2/26/2004
IP tunnel
14
UCCS Chow
Performance of SCOLD v0.1

Table 1: Ping Response Time (on 3 hop route)
No DDoS attack
direct route
DDoS attack
direct route
0.49 ms

No DDoS attack
indirect route
225 ms
0.65 ms
DDoS attack
indirect route
0.65 ms
Table 2: SCOLD FTP/HTTP download Test (from client to target)
No DDoS attack,
Doc FTP
HTTP
direct route
100k
Size 0.11 s 3.8 s
250k 0.28 s 11.3 s
500k 0.65 s 30.8 s
1000k 1.16 s 62.5 s
2000k 2.34 s 121 s
ITS-ZeeWave Meeting 2/26/2004
DDoS attack,
FTP
HTTP
direct route
8.6 s
9.1 s
19.5 s 13.3 s
39 s
59 s
86 s
106 s
167 s 232 s
15
No DDoS attack,
FTP
HTTP
indirect route
0.14 s 4.6 s
0.31 s 11.6 s
0.66 s 31.1 s
1.15 s 59 s
2.34 s 122 s
with DDoS attack
FTP
HTTP
indirect route
0.14 s 4.6 s
0.31 s 11.6 s
0.67 s 31.1 s
1.15 s 59 s
2.34 s 123 s
UCCS Chow
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.
ITS-ZeeWave Meeting 2/26/2004
16
UCCS Chow
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
ITS-ZeeWave Meeting 2/26/2004
17
UCCS Chow
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.
ITS-ZeeWave Meeting 2/26/2004
18
UCCS Chow
ITS-ZeeWave Meeting 2/26/2004
19
UCCS Chow
A2D2 Multi-Level
Adaptive Rate
Limiting For
Anti-DDos Defense
ITS-ZeeWave Meeting 2/26/2004
20
UCCS Chow
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
ITS-ZeeWave Meeting 2/26/2004
21
UCCS Chow
A2D2 Results – UDP Attack
Mitigation: Firewall Policy

Packets Received: 23,407

Retransmission Request: 0
 Retransmission Received: 0
 Lost: 0
QoS Experienced at A2D2 Client
ITS-ZeeWave Meeting 2/26/2004
22
UCCS Chow
A2D2 Results – ICMP Attack
Mitigation: Firewall Policy

Packets Received: 7,127

Retransmission Request:
2,105
 Retransmission Received:
4
 Lost: 2,101

Connection
Timed-out
QoS Experienced at A2D2 Client
ITS-ZeeWave Meeting 2/26/2004
23
UCCS Chow
A2D2 Results – ICMP Attack
Mitigation: Firewall Policy & CBQ

Packets Received: 23,438

Retransmission Request: 0
 Retransmission Received: 0
 Lost: 0
QoS Experienced at A2D2 Client
ITS-ZeeWave Meeting 2/26/2004
24
UCCS Chow
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
QoS Experienced at A2D2 Client
ITS-ZeeWave Meeting 2/26/2004
25
UCCS Chow
A2D2 Results – TCP Attack
Mitigation: Policy+CBQ+Rate

Packets Received: 23,444

Retransmission Request:
49 – 1,376
 Retransmission Received:
40 – 776
 Lost: 9 – 600
QoS Experienced at A2D2 Client
ITS-ZeeWave Meeting 2/26/2004
26
UCCS Chow
Autonomous Anti-DDoS
Enhanced
IDS
+IDIP Application Layer
Snort
Alerts
Cooperative Traceback
Cooperative Detection
Net Restructuring
Intrusion Pushback
Notification
To IDIP
Discovery
IDIP Discovery Coordinator
Coordinator
Local IDS Response
Multi-Level Adaptive
Rate Limiting
Firewall
Traceback
Msg Sent
(iptables)
Security Policy
Internet
Traffic
IDIP
Neighbor
Class-Based
Queuing
(CBQ)
Multi-Level
Rate Limiting
eth0
eth1
Rates Dependent
on Traffic Type
Firewall
IDIP Neighbor
ITS-ZeeWave Meeting 2/26/2004
27
UCCS Chow
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)
ITS-ZeeWave Meeting 2/26/2004
28
UCCS Chow
SGFR Features
Psychology Evaluation
Stress Level Tracking
Effectiveness of Tool Usage
(Keyboard/Mouse Event Tracking,
History of Commands, Mistakes,
Popup Quiz?)
Security Enhanced Groupware
Instant messenger
(JabberX)
Group Key Managment
Secure Group
Rekeying system
(Keystone)
ITS-ZeeWave Meeting 2/26/2004
Group Communication Server
Instant Messaging Server
(Jabber)
29
UCCS Chow
SGFR System Architecture
SGFR
Group Key Server
SGFR Client
SGFR
Instant Messenger
Server
Group key distribution
SGFR Client
SGFR Client
ITS-ZeeWave Meeting 2/26/2004
30
Registration/authentication
Sign-in create/join chat
groups
Encrypt/Decrypt msgs
using group key
UCCS Chow
SGFR System Operation
JabberX
client
Jabber Server
Control
Manager
Application
Data
Rekey messages
Multicast/
Unicast
Registration
Requests
Rekey messages
Registrar
ITS-ZeeWave Meeting 2/26/2004
JabberX
Client
Data
Broadcast
JabberX
Client
Key
Server
31
UCCS Chow
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.
ITS-ZeeWave Meeting 2/26/2004
32
UCCS Chow
First group key
assigned to group
Second group key
assigned to group
When a member
joined
Output of the Keystone Server
ITS-ZeeWave Meeting 2/26/2004
User ganesh joining group g1
User ayen joining group g1
33
UCCS Chow
Packet captured by Ethereal Packet Sniffer
Encrypted “Hello”
Surrounded by <body>tag
Output of the Jabber server running on a machine
ITS-ZeeWave Meeting 2/26/2004
34
UCCS Chow
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
ITS-ZeeWave Meeting 2/26/2004
35
UCCS Chow
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.
ITS-ZeeWave Meeting 2/26/2004
36
UCCS Chow
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
ITS-ZeeWave Meeting 2/26/2004
37
UCCS Chow
UCCS Secure Wireless Access Testbed
RADIUS
Client
ITS-ZeeWave Meeting 2/26/2004
38
UCCS Chow
Client/Server Machine Configurations
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
radiusd09.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
ITS-ZeeWave Meeting 2/26/2004
39
UCCS Chow
PEAP vs. TTLS
on Toshiba machine
Time in msec
PEAP vs TTLS
[Toshiba - 366.604mhz]
1500
1400
1300
1200
1100
1000
900
800
700
600
500
TTLS
PEAP
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15
No. of Runs
Average
ITS-ZeeWave Meeting 2/26/2004
Variance
40
PEAP
TTLS
1046
949
8142
12060
UCCS Chow
PEAP vs. TTLS
Average Performance
PEAP-TTLS Average Performances over varying Distances
1500
Average-Time/ msec
1400
1300
1200
PEAP
TTLS
1100
1000
900
800
DIST1
DIST2
DIST3
DIST4
DIST5
Distance Range
ITS-ZeeWave Meeting 2/26/2004
41
UCCS Chow
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.
ITS-ZeeWave Meeting 2/26/2004
42
UCCS Chow
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 (preplanned/dynamically deployed).
 Develop algorithms for tracking first responders using
wireless sensors.
 Security in SMANET+FRSN.
ITS-ZeeWave Meeting 2/26/2004
43
UCCS Chow
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.
ITS-ZeeWave Meeting 2/26/2004
44
UCCS Chow
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.
ITS-ZeeWave Meeting 2/26/2004
45
UCCS Chow
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.
ITS-ZeeWave Meeting 2/26/2004
46
UCCS Chow
Summary



We have innovated ideas on intrusion tolerance/SMANET
We have developed expertise in
 Secure DNS system
 Secure multiple path indirect routing
 Autonomous system with Enhanced IDS+Firewall
 Secure wireless access and MANET
 Group key management
 Secure groupware
 Wireless sensor network for first responders
 Content switching
 Network restoration
Very interested in research and development collaboration.
ITS-ZeeWave Meeting 2/26/2004
47
UCCS Chow