Download
1 / 19
190 likes | 414 Views
In retrospect…. We saw at previous paper that ‘little’ George was unable to counterattack And that the only thing he could do is to detect a DoS attack, but never avoid it. George is desperate for help …
E N D
In retrospect… • We saw at previous paper that ‘little’ George was unable to counterattack • And that the only thing he could do is to detect a DoS attack, but never avoid it. • George is desperate for help … • Three people from Columbia university propose a system that is able to counter DoSattacks and, thus, help George.
SOS: Secure Overlay Service Angelos D. Keromytis1 Vishal Misra2 Dan Rubinstein2 1 Department of Computer Science 2 Department of Electrical Engineering Columbia University - New York, NY Presented by YannisKlonatos
The proposed scheme… • We must allow moderate number of legitimate usersto communicate with a target destination, where: • DoS attackers will attempt to stop communication to the target • The target is difficult to replicate (e.g., info highly dynamic), • Legitimate users may be mobile (source IP address may change) • Such a scenario is not uncommon / surreal : • FBI/Police/Fire personnel in the field may need communicating with their agency’s database. • Bank users’ commonly access their banking records and • On-line customers completing a transaction in a e-shop.
Related Work Requires Global Router participation Localized Filtering + end-system participation Route-based packet filtering Detect/Prevent Spoofing Identify/Shut down ongoing attacks Proactively Prevent attacks IP traceback Pattern match & filter (ASTA, MAZU) More secure IP pushback IPsec SOS Less Deployment Overhead
SOS: The players • Legitimate (Good) User: The node, end-system, user who is authenticated (in advance) to communicate with the target. • Target: The node, end-system, server that MUST be protected from DOS attacks • Attacker (Bad User): The node, end-system, user that wishes to prevent legitimate users’ access to targets
SOS: Basic Idea • DoS Attacks are effective because of their many-to-one nature: many machines attack one (remember DDoS attacks) • The basic idea is to send traffic across an overlay: a virtual network whose “links” are routing paths in the underlying physical network. • By doing so we achieve to: • Force attackers to attack many overlay points in order to mount successful attack: • Since the paths to the target are numerous and all hidden, all paths need to be brought down. • Allow our network to adapt quickly: the “many” that must be attacked can be changed
The goal… • Is to allow pre-approved legitimate users to communicate with a target, while • Preventing illegitimate attackers’ packets from reaching the target. • Ideally, we would like a solution that: • is easy to distribute: and doesn’t require modifications in all network routers (this would be an unreasonable requirement) • does not require high complexity (e.g., crypto) operations at/near the target • Important assumption: Attacker cannot succeed in a DoS attack to the core network routers and can only simultaneously attack a bounded number of distributed end-systems.
Solution: Step 1Source Address Filtering • Routers “near” the target apply simple packet filter based on IP address: • legitimate users’ IP addresses are allowed through • illegitimate users’ IP addresses aren’t • But… Problems: What if: • good and bad users have same IP address? • bad users know good user’s IP address and spoofs? • good IP address changes frequently (mobility)? (frequent filter updates) • Fast Light-weight authenticator
Solution: Step 1IFiltering + Proxies • Improvement: • Place a proxy server between a legitimate user and the target • The proxy only forwards authenticated packets • Only packets from the proxy can reach the target • Problems (again!): • If the attacker learns the IP of a proxy, they can spoof packets with this address and successfully reach the target . • Attackers can directly DoS attack on the proxy to drag it down. • Thus, again preventing legitimate user communication.
Solution: Step IIIFiltering + Hidden proxy server • To resolve the above issues, just keep the identity of the proxy “hidden”. • The hidden proxy called a Secret Servlet • Only target, the secret servlet itself, and a few other authenticated users in the network know the secret servlet’s identity (IP address). • Thus, attacker can not be sure which node is a proxy for the target.
Solution: Step IV+VFiltering + Hidden Proxy + Overlay Routing + SOAP • Additional security can be obtained by sending traffic to the secret servlet via a network overlay: • nodes in virtual network are often end-systems • verification/authentication of “legitimacy” of traffic can be performed at each overlay end-system hop (if/when desired) • This requires advertising a set of nodes that can be used by the legitimate user to access the overlay: • these access nodes that participate within the overlay are called Secure Overlay Access Points (SOAPs) • The path now is as follows: User SOAP overlay Secret Servlet Filtering target
The SOS so far… and more… • With filters, multiple SOAPs, and hidden secret servlets as described above, we have managed to confuse the attacker: • He now does not have a clue of what the entry point to the network is. • However, we must still get from SOAP to Secret Servlet in a “hard-to-predict manner”. Random routing doesn’t help since: • the routing complexity is O(n). • Routes should not “break” as nodes join and leave the overlay (i.e., nodes may leave if attacked) • Solution: Use DHT (Dynamic Hash Table) routing with the distributed protocol Chord
SOS with Chord • SOS (via Chord) now utilizes a Beacon to go from overlay to secret servlet • Secret Servlet chosen by target (arbitrarily) • Legitimate user forwards packet to SOAP • SOAP forwards verified packet to Beacon (via Chord) • Beacon forwards verified packet to secret servlet • Secret Servlet forwards verified packet to target
Adding Redundancy in SOS • Each special role can be duplicated if desired: • Any overlay node can be a SOAP • The target can select multiple secret servlets • Multiple Beacons can be deployed in CHORD. • An attacker that successfully attacks a SOAP, secret servlet or beacon in fact brings down only a subset of connections, and only while the overlay detects and adapts to the attacks.
To the point:Why attacking SOS is difficult • George (remember him?) comes back and ask “does it worth it?” . Well… • If one attacks the target directly (without knowing secret servlet ID), we have the filter to protect the target. • If one attacks the secret servlets… • Well, he can’t, since they are hidden. • Moreover, we can have attacked servlets automatically “shut down” and new servlets to be selected. • If one attacks the beacons: • Well, beacons also “shut down” (they leave the overlay) and new nodes automatically become beacons. • The attacker must continuously attack a “shut down” node or it will return to the overlay at some point in the near future. • If one attacks other overlay nodes: • The nodes themselves (surprise!) shut down or leave the overlay and the routing in the network self-repairs . • George can rest now. He is safe.
Results:Static Attack Success Analysis • Static attack: Attacker chooses M of N nodes at random and focuses attack on these nodes, shutting them down • We observe that almost all overlay nodes must be attacked to achieve a high likelihood of DoS, • And that the more the beacons, the less the likelihood of a successful DoS attack.
Results:Dynamic Attack Results Analysis • Dynamic Attack: Ongoing attack/repair battle: • SOS detects & removes attacked nodes from overlay, repairs take time TR • Attacker shifts from removed node to active node, detection/shift takes time TA (freed node rejoins overlay • So (by removing the math ) we expectthat if TA is significantly smaller than TR the attacker can take down the SOS infrastructure. • A single definition: • Attacking rate • Repairing rate • Attack Load Ratio = /
Conclusions • SOS protects a target from DoS attacks • lets ONLY legitimate (authenticated) users through • Approach: • Filter around the target, • Allow “hidden” proxies to pass through the filter, • Use network overlays to allow legitimate users to reach the “hidden” proxies • Analysis Results show that an attacker without overlay “insider” knowledge must attack a significant amount of overlay nodes to deny service to target.
