Transcript Decentralized Worm Detection Using p2p Networks

P2P Systems for Worm Detection
Joel Sandin
Stanford University
Worm Detection
• We want to build a distributed system to
reliably and quickly detect worm attacks
• Require both for active response
• Already have many ideas about what to
monitor – telescopes, anomalous host
behavior - and how to detect/respond
• How do we prevent an attacker from
subverting the detection system itself?
Intrusion Tolerance
• Many good solutions, few deployed
• Engineer a system that tolerates malicious
participants
• By allowing malicious participants we can avoid
“formal collaboration”, less new technology
• How do we collect “good data” for analytical
techniques in this setting?
• What are the limits of the analytical techniques?
Outline
• Discuss some attacks that detector must
withstand
• Ways to improve quality of collected data
• Honeypots to greatly reduce threat of false
positives
• P2P as a foundation for our detector
Attack 1: False Positives
• System must survive worm and related
attacks
• For new worms, we can’t rely on signatures,
so we expose the system to false positives
• Two dangers with an attacker that knows
about sensors in our system
• Can scan sensors to generate alerts
• Can develop a worm that avoids them
Attack 2: Infrastructure
• Worm might disable sensors
• Worm might target sensors themselves for
infection
• In a distributed deployment attackers may
control some networks containing sensors
• Attacker can passively watch network to
learn sensor locations
What are our sensors?
• When a worm is active, sensor should know
• 2^20 unused IP addresses
• Low cost: 2^8 IP addresses – combine 2^12
of them and you have a detector
• The “worst”? A single unused IP address
• Advantages of smaller sensors – incentive
outweighs cost of deployment, well hidden
• Disadvantage: some may be faulty
Consistency Checks to Improve
Robustness
• In our sensor network, faulty sensors might lie
about false events
• We don’t just have to listen to a sensor’s claims,
we can try to verify them
• Verification should be done by other sensors (or
aggregator)
• The more sensors that are involved in verification,
the more fault tolerant the system becomes
Option 1: Telescope Consistency
• In ‘trusted’ case, anomalous host behavior (ICMP
unreachable) and network telescope activity seen
as interchangeable
• In untrusted setting, we can monitor both
• For sensors’ claim, compute expected reaction,
“check” claims from potentially malicious sensors
• Check claims of sensors against activities in rest
of sensor network (space)
• Check claims of sensors against events in
subsequent quanta (time)
Consistency Continued
• Increases the number of sensors involved in
each round of introspection
• Use claims to make predictions for future
• Can exclude sensors from subsequent
rounds to verify claims
• Weigh trust in sensors’ claims
• Might not be enough – false positives
Option 2: Better Sensors
• Increase the cost of generating a false positive
• We know how to do this for new worms:
Honeypot
• Honeypot can run an exposed service and a sensor
can monitor the honeypot
• Outgoing network activity can indicate infection
• For services thought to be secure, a false positive
is expensive
Honeypot Consistency
• An honest sensor can verify another honeypot’s
claim of infection
• The verifying sensor reconfigures itself to accept
tunneled traffic from the infected honeypot
• If the verifying sensor observes the infection, it
raises alert
• Even with high number of malicious nodes, only a
few infections in our system needed to catch worm
• Now that false positives become hard, attacker
will work to avoid detector altogether
A Fault Tolerant Infrastructure
• Use honeypot consistency checks for high
fault tolerance
• Honeypots are expensive, so deploy cheaper
telescope sensors to snag interesting traffic,
track trends, and configure/shield the
honeypots
• High fault tolerance of the system will make
it easier to build
Foundation for a System – P2P
• Want to connect distributed sensors (IDS, NIDS,
honeypots), security problems suggest P2P
• Chord (and others) provide self-organizing
structure, efficient routing in face of faults, nodes
need only a local picture
• Work done on Byzantine fault tolerance
• Fault tolerant aggregation algorithms to synthesize
data from sensors reliably and efficiently
(mentioned in zou et al)
• Effort of deployment low – but need more
Summary: Research Problems
• Getting better data for anomaly detection
when some sensors are malicious
• Role of honeypots
• Building a resilient p2p substrate that gives
us the security primitives we need
• At the same time, limiting nodes global
knowledge