Not-a-Bot Improving Service Availability in the Face of Botnet - - PowerPoint PPT Presentation

Not-a-Bot Improving Service Availability in the Face of Botnet Attacks

Overview

• Introduction to the problem
• Architecture of NAB
• A way to attest human-generated traffic
• Use of attestation to mitigate presented problems
• Results

Introduction to the problem

• Significant part of internet traffic is bot-generated
• Top 6 bot-nets generate:

– 85% of spam, which is 120 billion of messages in

95% inboxes

– 5% of web-traffic is generated through DDoS

(Distributed Denial of Service). 4000 different attacks per week on average

– 14-20% of all ad clicks

Introduction to the problem

• Problems of spam, DDoS and Click Fraud would

be significantly mitigated if it would be possible to distinguish bot and human-generated traffic.

• Unfortunately, no good solution is known today.

Introduction to the problem

• Traditional human activity solutions such as CAPTCHAs

are not suitable in most cases :

– CAPTCHAs are used today for coarse-grained actions

such as email account creation, they are considered too intrusive to be used for finer granularity requests such as sending email or retrieving web URLs.

– CAPTCHAs do not link to the actual request, so

unaware users might by redirected to solve them.

– CAPTCHAs are solvable by computer algorithms.

Introduction to the problem

• Automated way of generating attestations of

human-based origin of web traffic is needed.

• Unfortunately software or operating system of

infected machine cannot be trusted.

NAB = Attester + Verifier

• NAB consists of Attester working on a Client and a

Verifier working on a server.

• Attester automatically generates attestations of

human-based origin of actions based on monitoring of input devices (keyboard and mouse).

• Verifier verifies correctness of attestations.

NAB - Architecture

• Built prototype of NAB works with:

– Virtual machine monitor XEN, which provides

separation of infected operating system from NAB code. (30,000 LOC + 500 LOC of attester)

– Trusted Platform Module (TPM) Chip, which

provides secure access to input devices (keyboard and mouse).

• Above components together with input devices

form Trusted Computing Base (TCB)

NAB - Architecture

NAB - Architecture

• Presented approach could be implemented

without virtualization:

– Attester built into hardware – Use of platforms providing execution of

trusted code (Intel TXT, AMD Pacifica, Flicker)

NAB – Goal

• Distinguish human-generated traffic from

bot-generated traffic, without the need for additional user action.

• Reduce bot-generated traffic to at most 10%
• f current value, recognizing all the traffic

generated by human as valid.

Trusted Module Platform

• TMP is a small chip specified by Trusted Computing Group

to strengthen the security of computer systems.

• Used by NAB :

– For safe loading of Attester – To anonymously sign messages

(service Direct Anonymous attestation)

– Contains Attestation Identity Key as a basis for

the key used to sing messages.

– Other

Trusted Module Platform

Attester

• Generates attestations at the request of the client

application (browser, email client)

• May refuse to generate an attestation if it

considers that there had been no human-based activity causing a particular action.

Attester

• Certificates issued by Attester are:

– Not transferable. Certificates issued by one

Attester are not valid certificates of another.

– Associated with the certified action. Contain

a hash of the certified message.

Attester

• Attester issue a certificate if mouse or

keyboard have been used in less than ∆K i ∆M respectively.

• Values of ∆K i ∆M are determined

separately for each application

– ∆K = ∆M = 1s for the browser – ∆K = ∆M > 1s for email client

Attester

• A more sophisticated method of issuing certificates

based on characters generated with the keyboard was also considered. This method was abandoned due to the excessive complication related to multi-task nature

• f work on a modern computer.

Attester

• Attester in the created prototype needs less

than 10 ^ 7 cycles of the CPU, which is less than 10 ms on a 2GHz processor. It is less than the time needed to establish a TCP / IP connection, and therefore it's easily acceptable.

Verifier

• The verifier module operates on the server,

validating the certificates issued by the Attester.

• The verifier processes attestations at a rate of

more than 10,000 attestations per second on a 2 GHz Core 2 processor.

Verifier and Spam

• Verifier is located on the ISP's email server.
• With the attestations issued by the attester, you

can set up a classic anti-spam filters more aggressively, adding points to the messages with correct attestations.

• This policy encourages customers to use NAB as

their e-mails are rewarded in the spam filter.

Verifier and DDoS

• Server equipped with Verifier prioritizes

requests with valid attestations over those that lack them.

• In the case of DDoS attacks, users provided

with attester will not feel the effects of the attack.

Verifier and Click Fraud

• Companies displaying ads (Google, Yahoo, etc.)

can use Verifier to ensure their customers about the human origins of the clicks.

Results

• The system have been tested with 328

volunteers using it for a month.

• Tests of the system on infected computers

(honeypots) have also been performed.

Results

• The amount of spam which got to the inboxes have

been reduced by 92%, while not classifying any human-generated message as spam.

• In the simulation of a DDoS attack 89% of requests

generated by bots have been detected and it's priority has been decreased. A significant impact on the human-generated requests has not been noticed.

• 87% of bot-generated clicks have been detected,

without losing any of the human-generated clicks.

Q&A