Design and Implementation of Alternative Route Against DDOS
Download
Report
Transcript Design and Implementation of Alternative Route Against DDOS
Design and Implementation of
Alternative Route Against DDOS
Jing Yang and Su Li
Introduction
In general, three categories of DDoS
research:
Intrusion Prevention
Intrusion Detection
Intrusion Response/Tolerance
A Typical DDoS Architecture
www.victim.com
Client
(Commander)
Handler
(Middleman)
Agent (Attacker)
Mastermind
Intruder
Objective
Focus on Intrusion Tolerance
Explore Alternative Routes Against DDoS
Approaches
1. Updated DNS along with IP-Over-IP between
the alternative firewall and real server.
•
•
Alternative routes established from clients to the real
server through an alternative firewall (IP-Over-IP).
Relatively easy to implement, and work reasonably well,
but does not resolve the DDoS problems completely.
2. Updated DNS along with Proxy Server
•
•
•
Alternative routes established from clients to real server
through an alternative firewall (Proxy Server).
Adding new fields to DNS and new features to web
browsers/network applications.
Attacker can hardly detect the new route – better for
trusted clients.
Design and Implementation of
Approach 1
Architecture
Client
FireWall
Alternative
Firewall
DNS Server
Real Server
Software Developed
SendMessage: a client program that sends out
“Attacked” msg to the alternative firewall.
PM (ProcessManager): a server program that listens
for “Attacked” msg, and manages Updated_DNS and
IP-Over_IP server programs.
Updated_DNS: a UNIX shell script that updates DNS
server for the alternative firewall information (IP).
IP_Over_IP_Svr: a program that transfers data back
and forward between clients and the real server
(Only for HTTP request/data in the current version).
Software/Tools used
Bind Version 9: only Bind 8/9 allows
updating DNS record.
VMWare: A freeware used to create two
additional operating environments (ex.
Argo.uccs.edu and Ardent.uccs.edu are
created on Athena.uccs.edu machine)
Hardware Configuration
Client
FireWall
(Athena)
Alternative
Firewall
(Ardent)
Real Server
(Argo)
DNS Server
(Argo)
Process Flow (Approach 1)
Step 1: Upon detection of an attacker (ex. by Snort),
MessageSend (client) running on the real server
sends a “Attacked” message to the alternative
firewall.
Step 2: Upon receiving an “Attacked” message,
Process Manager (server) running at the alternative
fire wall server will do the following:
Start updateDNS process to update DNS servers with the
alternative firewall IP address.
Start IP-Over-IP process that will relay request/data
between the real server and client ….an alternative route is
established.
Design of Approach 2
Add three new fields to the current DNS specifications:
1. Proxy Server IP address.
2. Proxy Server Port Number.
3. A field for a list of trusted client IP addresses or identifiers or
digital signatures.
Add client network interface, which add SOCK protocol when
the DNS query returns the new type of DNS query results (more
transparent solution)
Modify web browsers to read the three DNS fields and configure
web browsers automatically, if and only if the client info such as
IP or identifier matches the client information from DNS server.
Conclusion
1. Updated DNS along with data transfers using IPover-IP between real server and alternative firewall
(approach 1) reasonably establish the alternative
route.
2. Approach 1 dynamically provides the alternative
route and thus increases intrusion tolerance.
3. Limited testing results (browsed a couple of personal
web pages through the alternative route –Approach
1) show no performance issue.
(More testing with simulating attacking situation
is needed)
Conclusion (continues)
3.
However, approach 1 can not eliminate completely
the DDoS problems since attackers may go through
the new route after detecting the alternative route
(The IP_Over_IP_Svr only handle HTTP request/data
in this version).
4. Approach 2 does guarantee continuous service for
trusted clients since only the trusted clients are
allowed to go through the alternative route when the
original route is attacked.
Future Work
Approach 1 can be expanded into a
failover/failback systems or load balancer.
IP_Over_IP_Svr can be expanded to handle
other protocols such as FTP, SNMP.
DNS server can be improved with additional
rules or policies to increase internet security –
this is the main lesson learnt.
References
Design of An Autonomous Anti-DDOS Network
(A2D2). Angela Cearns. Thesis. Department of
Computer Science. 2002.
Detection, Defense and tracking of Internet-Wide
Illegal Access in a Distributed Manner. Kohel Ohta, et
al.
www.isoc.org/isoc/conferences/inet/00/cdproceeding
s/if/if_2.htm
http://www.shakabuku.org/writing/dyndns.html
http://www.freesoft.org/CIE/Topics/77.htm