Upload
virginia-irwin
View
41
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Defensive Programming Using an Annotation Toolkit to Build DoS-Resistant Software. Xiaohu (Tiger) Qie Ruoming Pang and Larry Peterson Princeton University. How to DoS a Networked System. Exhaust resource on a remote target Making normal service unavailable - PowerPoint PPT Presentation
Citation preview
Dec 2002 OSDI'02, Boston, MA 1
Defensive Programming
Using an Annotation Toolkit to Build DoS-Resistant Software
Xiaohu (Tiger) QieRuoming Pang and Larry Peterson
Princeton University
Dec 2002 OSDI'02, Boston, MA 2
How to DoS a Networked System• Exhaust resource on a remote target
Making normal service unavailable Seriously degrade service quality
• Examples– Christmas tree packets
• Flood of packets with IP options• Router CPU swamped Too busy to run routing protocols
– Ping flood– TCP SYN flood
Dec 2002 OSDI'02, Boston, MA 3
• Web Servers limit the number of connections• Idea: Slow down TCP
– Slow sender: • ‘G’, ‘E’, ‘T’, ‘ ’, ‘/’, ‘/’, ‘/’, ...
– Slow receiver and acker: • Request a big file• Open receive window lazily• Pretend packets were lost
– Tie up all connections for as long as you want
• Other victims: NIS servers, NAT boxes ...
How to Slow-DoS a Web Server
Dec 2002 OSDI'02, Boston, MA 4
Renewable Resources
CPU cycles
Network BW
Disk BW
Non-renewable Resources
Processes
File descriptors
Buffers
Resources and Vulnerabilities
Busy AttackVulnerability
Claim-and-holdAttack
Vulnerability
Admission control
Recycle
Dec 2002 OSDI'02, Boston, MA 5
Proposal: Defensive Programming• Program for Robustness
– Integrate software functionality and protection– Highlight resource control– Pro-active, Systematic and Fine-grained
protection
• Annotation Toolkit– Sensors and Actuators– Protect both renewable and non-renewable
resources– Low programming burden
Dec 2002 OSDI'02, Boston, MA 6
Related Work
AnnotatioAnnotation Toolkitn Toolkit
OS Protection
Profiling
Static Analysis
Anomaly Detection
Dec 2002 OSDI'02, Boston, MA 7
Outline
• Attack and Resource Characterization• Toolkit Description• Case Study• Conclusions
Dec 2002 OSDI'02, Boston, MA 8
Renewable Resource Protection– Divide program functionality into services– Balance resource consumption– Confine damage of a DoS attack within a service
S
S
S
S
S
S
S
Renewable ResourcesServices
Client Request
SR
R
R
X
R
R
X
X
X
X
S
S
Dec 2002 OSDI'02, Boston, MA 9
Rate Limiting Options
Resource not balanced among services
Hard to set appropriate limits
foo
teebar
Yes
STOP
RESOURCE
No
rate < 100?RL
foo
teebar
RESOURCE
rate < ???
rate < ???
RL
RL
RL
Dec 2002 OSDI'02, Boston, MA 10
Rate Sensor & Service Admission
foo
teebar
RESOURCE
A
AA
void foo() { ... bar(); send_pkt();}
void bar() { ... send_pkt();}
void send_pkt() { ...}
void foo() { SERVICE_ADMISSION; bar(); send_pkt();}
void bar() { SERVICE_ADMISSION; send_pkt();}
void send_pkt() { RATE_SENSOR(100HZ);}
RATE SENSOR
Dec 2002 OSDI'02, Boston, MA 11
Time Sensor
foo
bar
compute_piDeadline
A
TIME_SENSOR
MaxTimeA
void entry() { TIME_SENSOR(100); foo(); bar();}void foo() { SERVICE_ADMISSION;}void bar() { SERVICE_ADMISSION; compute_pi();}void compute_pi() { SERVICE_ADMISSION;}
A
Dec 2002 OSDI'02, Boston, MA 12
Non-Renewable Resource Protection
– Inspect principals that hold resources– Reclaim resources from “unproductive” principals– Starvation avoidance
R
R
Non-Renewable Resources
AcceptedRequests
R
Incoming Requests
Principals
Dec 2002 OSDI'02, Boston, MA 13
• Timer-based recycle– Idle timer– One shot timer
• Progress-based recycle– User-defined progress metric
• E.g. output generated, state transitions made
– Reclaim resources from the “slowest” principal – User-defined pressure metric to trigger
reclamation
Non-Renewable Resource Protection
Dec 2002 OSDI'02, Boston, MA 14
CGIDirectory
File
Send Response
Dispatcher
Read/Parse Request
Progress Sensor & Reclamation Checkpoint
DoConnReadingBackend() { switch(ProcessRequestReading()) { case PRR_DONE: PROGRESS_SENSOR(10000); /* switch to sending */ break; ...
DoSingleWriteBackend() { sz = writev(...); /* Ok, we wrote something. */ PROGRESS_SENSOR(sz); if (all data are sent) { /* conection is finished! */ DoneWithConnection(c, FALSE); return; } ...PROGRESS SENSOR
C
PROGRESS SENSOR
PROGRESS SENSOR
Dec 2002 OSDI'02, Boston, MA 15
Toolkit Implementation• Sensors and Actuators
– 11 C-macros / library functions– Managing renewable resources
• RATE_SENSOR, TIME_SENSOR• SERVICE_ADMISSION
– Managing non-renewable resources• PRESSURE_SENSOR, PROGRESS_SENSOR ...• RECLAMATION_CHECKPOINT
• Compiler assistance– Auxiliary code generation– Annotation coverage check
Dec 2002 OSDI'02, Boston, MA 16
• Flash– Event-driven architecture– ~12,000 lines of code
• Annotating Flash Web Server– 46 services (mainly event handlers)– TIME_SENSOR in main loop, enclosing all
services– PRESSURE_SENSOR tracks connection
availability– PROGRESS_SENSOR in every stage– Added ~60 annotations
Case Study: Flash Web Server
Dec 2002 OSDI'02, Boston, MA 17
Services in FlashMain Loop
StartRequest
RegularFileStuff ProcessColdRequest SendDirRedirectScheduleDirHelp
CGIStuff ProcessColdRequestBackend2
ExpandSymlinks
RegularFileStuff ProcessColdRequest
ExpandSymlinks
Dec 2002 OSDI'02, Boston, MA 18
Slash Attack
• O(N^2) memory read/write: – ~150ms for 10,000 slashes
• “GET //////////////////…///xyz”– 7 requests per second saturates server
/* Remove any leading slashes. */
while ( rest[0] == '/' ) {
(void) strcpy( rest, &(rest[1]) );
--restlen;
}
Dec 2002 OSDI'02, Boston, MA 19
Flash Under Slash Attack• Normal Client:
– Requests a 10KB file in the hot name cache
• Attacker: – Requests cold URLs with 10000 slashes– 10 requests per second
• Average client-perceived response time:
no attackerw/ attacker
unmodified serverw/ attacker
annotated server
4.3ms >25 seconds 5.1ms
Dec 2002 OSDI'02, Boston, MA 20
• Effectiveness depends on service granularity– All clients requesting cold URLs are affected– Possible solution: refine classification
granularity
• How to set parameters– Don’t have to be precise – for disaster control
only– Fine tune from behavior profile
Limitations
Dec 2002 OSDI'02, Boston, MA 21
Conclusions• Defensive Programming:
– Protect from inside– A useful additional layer of protection
• Toolkit:– Renewable resources balanced among services– Non-renewable resources recycled based on
progress– Systematic deployment of sensors and
actuators• Not to look for specific “bugs”
– Low programming burden