Transcript Eclipse Attack

Sybil & Eclipse Attacks
Disrupting Peer-to-Peer Networks
Lee Brintle
University of Iowa
Motivations
Many organizations may wish to disrupt some part of a P2P network
•Intellectual Property Owners
Both piracy and legitimate content
•Governments
Banned content, censorship
•Corporations
Advertising, reputation, public relations
Sybil & Eclipse Attacks
Disruptions
More subtle actions than just shutting it down
•Missing Results
Only censor some items
•Degraded Results
Intentionally provide damaged or slow results
•Delayed Actions
Function normally until a point in the future
Sybil & Eclipse Attacks
Sybil Attack
Single entity posing as multiple entities
•One attacker with many identities
•Named after character with MPD
•Many real-world examples
John R. Douceur, Microsoft Research
Sybil & Eclipse Attacks
Three Sources of Information
How does a peer know about the trustworthiness of other peers?
•Itself
Results of protocol interactions
•Other peers
Trust in a large number of strangers
•External agencies
Direct or indirect vouching for uniqueness of peers
Sybil & Eclipse Attacks
Direct Entity Validation Tests
Weed out duplicates by asking all to performing a task that a single entity cannot
•Ask all to perform task that one cannot do
Make the attacker “too busy” to simulate all of them
•Simultaneously validate peers
The attacker should not be allowed to focus on one
•Limit number of Sybil identities
Ratio of resources – attacker / weakest legitimate
user
Sybil & Eclipse Attacks
Sample Validation Tests
Ways to see if a number of peers are sharing resources
•Communication
Require each to prove they have X Mb/s bandwidth
•Storage
Require each to prove they can store Y GB
•Computation
Require each to solve a “hard” puzzle
Sybil & Eclipse Attacks
Vouched-For Entities
Trust a new entity based on the word of an already-verified entity
•One Sybil Vouches for them All
Pushes the problem around
•Verified Users May Vouch for Sybils
Once they gain your trust, invite in other Sybils
•Faulty Verifications are Amplified
Sybil & Eclipse Attacks
Attackers Have Resources
Attacking entity has more resources than the average user of the network
•Lots of Bandwidth
•Lots of Disk Space
•Lots of CPU
•Lots of Identities
Sybil & Eclipse Attacks
Direct Physical Knowledge
Knowing information about a peer beyond the peering protocol
•Explicit
Signing authorities, well-known users, software autho
•Implicit
IP address allocation, network locale
•Irrelevant
Ignore bad results, accept performance loss
Sybil & Eclipse Attacks
Eclipse Attack
Attackers gain disproportionate influence compared to legitimate users
•Fewer attackers
•Disproportionate level of influence
•Attackers eclipse legitimate users
Singh, Ngan, Druschel, Wallach
Sybil & Eclipse Attacks
Structured Networks
Constrained routing table networks are difficult to attack – but perform poorly
•Topology is “fixed” – nodes have constant
influence
The routing is hard-wired based on address
•No flexibility in neighbor selection
Cannot take advantage of proximity
•Some resistance to Eclipse attacks
The more structure, the less susceptible
Sybil & Eclipse Attacks
Unstructured Neighbor Selection
Eclipse attacks target the neighbor peering decision
•Neighbors are selected, not assigned
Each node picks “good” neighbors
•Nodes that look “good” have influence
If a node is selected more often, gains more influence
•Potentially vulnerable to Eclipse attacks
Attacking nodes become more influential
Sybil & Eclipse Attacks
Eclipse Defenses
Mitigate Eclipse attacks by additional network structure, proximity, or degree bounds
•Enforce strong structural routing
Routes are dictated randomly, but performance
suffers
•Select neighbors based on proximity
But... most non-LAN nodes have roughly same delay
•Place a limit on number of degrees
Degree bounds prevent nodes from being too influenti
Sybil & Eclipse Attacks
Profile of a Hostile Node
Detect hostile nodes, so they can be avoided in neighbor selection
•High in-degree
Must have higher influence than average
•High out-degree
Tries to consume resources of average nodes
•Extremely effective
20% of nodes eventually have almost complete contro
Sybil & Eclipse Attacks
Enforce In-Degree Bounds
Avoid peers with large numbers of in-degree links
•Refuse to peer with overloaded nodes
Force each node to have “typical” influence
•Bound based on expected average degree
Lower bounds more defense, worse performance
•Performance hit is 25% at average degree
Degree bounds mean that less-optimal nodes are
selected
Sybil & Eclipse Attacks
Catch a Lying Node: Audit Links
Anonymously verify link set contains known nodes
•Ask each peer for list of in-nodes
For now, assume peer tells truth
•Drop peer if list is too long
Do not allow a peer to gain too much influence
•Drop peer if list does not contain us
If peer returns sub-set of true list, drop peer
Sybil & Eclipse Attacks
Catch Lying Nodes: Distributed Audit
Ask someone else to verify the node list
•Use random seed point
•Select multiple nodes
•Audits are aggregated
Random node among the l
closest to H(x)
(chart from paper)
Sybil & Eclipse Attacks
Distributed Audit Results
The auditor may be lying too...
Fail
Audit legit, Target hostile
Audit hostile, Target legit
Pass
Auditor legit, Target legit
Auditor hostile, Target hostile
Auditor legit, Target lucky hostile
Sybil & Eclipse Attacks
Distributed Audit Tuning
Parameters which impact detection and performance
f: fraction of hostile nodes (.2)
n: number of audits (24) (.2% false ID)
k: number of successful audits (n/2)
r: overload ratio on hostile nodes (1.2)
t: permitted overload ratio (1)
audit period (2 minutes)
churn rate (0%, 5%, 10%, 15%)
Sybil & Eclipse Attacks
Distributed Audit Results
Profile before auditing starts
Without prevention, malicious nodes have great influence
(chart from paper)
Sybil & Eclipse Attacks
Distributed Audit Results
Profile during auditing
f/(1-f)
Auditing is effective in mitigating Eclipse attacks
(chart from paper)
Sybil & Eclipse Attacks
Performance Gain
Optimized neighbors with auditing is still faster than non-optimized neighbors
At t=.2, auditing rate=2 min, churn = 5 min:
4.75 msg/node/min messaging overhead
Sybil & Eclipse Attacks
Caveats
Yeah, but....
“The idea of churn as shelter from route poisoning
attacks...”
•Unstructured networks need structured
auditing
BitTorrent can use a distributed tracker, for example
•Does not help super-node networks (KaZaAa)
Asymmetry is part of performance gain
•Still weak against localized attacks
Can target users on same network
Sybil & Eclipse Attacks