This preview shows page 1-2-3-4-5 out of 15 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

DDoS Attack Prevention by Rate Limiting and FilteringOverviewSlide 3PushbackSlide 5Slide 6Slide 7NetBouncerSlide 9Slide 10D-WARDSlide 12Slide 13Slide 14Questions for DiscussionDDoS Attack PreventionbyRate Limiting and Filteringd’Artagnan de [email protected] Network Security26 Apr 04Pushback PaperNetBouncerD-WARD PaperQuestions for DiscussionOverviewFiltering – requires real time algorithms, and most likely pre-deployment of resources for trustRate Limiting – Hard to prevent collateral damage to “good” and “poor” traffic v. just bad trafficOverviewPushbackIoannidis and Bellovin attempt to implement PushbackProblem: We can’t tell legitimate traffic from illegitimate trafficGoal: Develop heuristics that try to identify most bad packets while not disturbing most good packets.Aggregate-based Congestion ControlA subset of the traffic with an identifiable property, e.g.:Packets to destination DTCP SYN packetsIP packets with a bad checksumIdentify “attack signature” -> “congestion signature”Sort of recursive – It tells the next level of routers to back off, as it is backing off. Rationale: The packets will be dropped at the destination anyway, so why not just drop them at the routers above too?PushbackGood architecting by allowing the pushback daemon to exist out of band. Router must have some sort of inherent traffic shaping capability to take advantage of thisOnly logs packets dropped for queue discipline reasonspushbackd processes the saved drop-set to try to detect congestion. “The exact algorithm(s) to run will be an important research topic for some time to come.”The algorithm detects aggregates based only on IP destination address – the simplest implementationPushbackThe pushback daemon listens for requests from its downstream routers. => Necessitates greater deploymentProbability of keeping a packet is inversely proportional to its size – smart!“In a real router with hardware-assisted fast switching paths for the common cases, the overhead of imposing a number of rate limiting sessions may be much higher.”Pushback“Even though the prefix garnered from the routing table will be shorter than 32 bits, the address of the selected aggregate will be the full 32 bits.” Why? Because a specific machine is targeted. “It is likely that more than one attack is happening at the same time.” Why? More than one attack does happen at the same time and one should design a system that works for the real world.The algorithm should run in less time than it takes to collect the packets. Why? Queuing system theory: You want the server to operate faster than the queue can fill up.“Pushback is most effective when the attack is non-isotropic. (most attack traffic close to victim and from a subset of the in-links)” Why? Smaller area to graph. More likely to have a complete deployment of Pushback in that area.NetBouncerClaim: NetBouncer can tell the difference between legitimate and illegitimate traffic in a hardware implementation of a router.“End-point-based solution to DDoS protectionGoals: No changes in current network protocolsNo administrator intervention for legitimacy testsState safety: legitimacy tests do not become vulnerabilities“A NetBouncer device maintains a large legitimacy list of clients that have been proven to be legitimate”Not on the legitimacy list? Administer tests to prove legitimacy.NetBouncerUse of TCP SYN cookies was a good ideaInterception of SYN packetsHandles TCP connection in a “stateless manner”Good job addressing Application and Session-oriented legitimacy tests (structured- and ad hoc- composite services i.e., SCS and ACS). But…“The ACS subcategory is currently a topic if intense research and will be reported in the future.NetBouncerNetBouncer “should be placed upstream of potential chokepoints…” How is this location determined? There really aren’t great places to deploy NetBouncer. Must be placed where it can handle all of the attack traffic. Otherwise, rate limiting before NetBouncer will reduce the good and bad traffic it sees.Use of ICMP echo messages touted, and then acknowledged as not likely to be effective…How does the list of legitimate sources get instantiated? This is hard to do.“We are currently exploring how ICWFQ can be supported within the IXP-1200 based hardware prototype of NetBouncer.”D-WARDDDoS defense mechanism intended to be deployed at the source to detect and stop attacks by evaluating traffic signaturesProblems: Attack traffic is too aggregated at the victim so it makes on-the-fly packet dropping difficult.Core routers cannot spare enough resources to do a good job so much collateral damage is suffered from implementation there.Solution: Stop attacks at the sourceD-WARDConfigure outgoing addresses to be policedMonitor traffic between these addresses and the rest of the internet.Compare traffic against historical data and curtail deviating behavior. Autonomous adjustment.Addresses TCP, ICMP, and UDP – Definitions provided for “normal, suspicious, or attack”# of machines attacking is transparent to the systemD-WARD“We assume that D-WARD is able to identify the police address set.” Probably not a simple task. Fairly easy to identify what machines are in your own network.“We assume that all machines from the police address set use the source router as the exit router” (i.e., Asymmetric routes – you have to check between every possible pair, with secure communication and clock synchronization, exposing more points to be attacked.)What would be the maintenance cost of keeping the police address set up to date? Not much.Most networks DO have more than one border router. D-WARD would be most effective if deployed on each border router. Possibly, the correct assumption is that if an ISP chooses to implement this system on one border router, they would do so for all…D-WARDHardware vs. Software Router“and enable us [to] test whether D-WARD can handle traffic at high speeds.” Implemented on IXP-1200Legitimate flows that start during the attackHash table size limitationDetection of UDP packetsCannot detect “the shrew” attack from non-spoofed sources. Can now detect some UDP traffic flows too.Questions for


View Full Document

UCLA COMSCI 239 - DDOS_1

Download DDOS_1
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view DDOS_1 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view DDOS_1 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?