Sender Identity and Reputation Management

Transcription

1 Dec 4 th 2008 IT IS 3100 Sender Identity and Reputation Management Guest Lecture by: Gautam Singaraju College of Information Technology University i of North Carolina at Charlotte

2 Accountability on the Infrastructure 2

3 Accountability: Two Components Identify the sender. No identifiable sender: no accountability. Reasonable assurance that the sender identity cannot be compromised. Hold senders accountable for their actions. History of adherence to a common guideline. Guideline: a policy to dealing with bounces, minimum volume to maintain history, sender feedback loop etc. 3

4 Present Technologies For Spam Classification 4

5 classification techniques Analysis on the s contents (Content-based filters) Text analysis, image analysis, audio analysis etc. Identify the senders using Blacklists. Spamhaus.org Statistics based Bayesian classifiers Grey-listing, Throttling network bandwidth. 5

6 Pros and Cons of filtering i techniques Pros of filtering technologies Excellent classification. Receivers can employ multiple techniques. Used when senders cannot be identified (rapidly changing identity). Cons of filtering technologies Classification at receivers does not hold senders accountable. Different filtering techniques are required. Huge costs. Spam classification has become an arms-race. 6

7 Sender Identity: SPF and SenderID Sender Policy Framework (SPF): Prevents return-path th address forgery ( spoofing). Senders identify their server s IP in their DNS. Receivers verify the sender s IP address of an with information from the sender s DNS records. Example: v=spf1 include:aspmx.googl .com ~all SenderID: Prevents spoofing of the sender s s Validates the s origin by verifying the sender s IP address against the purported owner of the domain. 7

8 Sender Identity: DKIM Domain Keys Identified Mail Senders publish public keys using DNS; digitally sign all s. Receivers validate the signed by retrieving the public key. Example (dkim.org) DKIM-Signature a=rsa-sha1; sha1; q=dns; d=example.com; s=jun2005.eng; c=relaxed/simple; t= ; x= ; h=from:to:subject:date; b=dzdvyofakcdlxdjoc9g2q8loxslenisb av+yuu4zgeerud00lszzvog4zhrniyzr July 2008: ebay and paypal has started using this. If an is not signed, the sender should reject it! 8

9 Reputation ti Systems Certification Schemes E.g. Hebeas, SenderPath driven by senders. Gmail s reputation ti management system. Identify senders and monitor their behavior. Use the reward-punish architecture. TrustedSource 9

10 What is effect of Granularity? Domain based solution Variable granular Feature: credential maintained by Admin and Users. Advantages: 1. Compromise between accuracy and costs. 2. Identity verified using a trusted third party. Disadvantages: 1. Deployment maintenance overhead. User based White-Lists 10

11 RepuScore: A Collaborative Reputation Management Framework History of adherence to a good practice 11

12 Problem with Sender Identities Our experiments using: From Oct 07 to present at a small organization: 92+% spammers. From March 08 to July 08 at a college: 76+% spammers. Using SpamAssassin classification rules. Sender Identity alone does not guarantee that the sender is spammer or not. 12

13 Reputation ti vs. Trust Reputation is the metric for trust. Used for partner selection since early 1980 s. Used for desired social behavior to optimize one s outcome. Senders must build and maintain reputation over time A spammer would be unwilling to invest large amount of time for the costs involved. Reputation maintained by receiver organizations, a spammer cannot change or buy its reputation overnight. 13

14 RepuScore Goals Consider reputation votes from multiple organization: Requires distributed collection and computation. Users or existing spam classification mechanisms vote. Verification of reputation votes is not required: Based on what one organization i observes; self-certifying i solution. A global reputation summary Requires centralized architecture. Assign a quantitative score for senders. 14

15 RepuScore Goals (Contd.) Organizations use multiple technologies No one technology is good enough. Share information obtained from tools they use. User-base Vs. Collaboration Large user-base implies no need to collaborate. Small user-base implies there is a need to collaborate. A reputation framework assumes an Identity SPF, DKIM, SenderID. RepuScore needs a central authority: SPF, DKIM, SenderID. 15

16 RepuScore Architecture t Single vote per organization i Central Authority RepuCollector RepuCollector Global Algorithm RepuCollector RepuServer RepuServer RepuServer RepuCollector Algorithm RepuServer RepuServer Domain 1 Domain 2 RepuServer Domain n Algorithm 16

17 RepuScore Architecture t (Contd.) td) Spam reported by users or filters. Filters classify s and report Sender Reputation. Filters use reputation to filter s. Filters can be using other classification techniques. 17

18 Features for Reputation Reputation can be maintained based on: Good Rate (RepuScore) Good Rate and volume (Volume Enhanced RepuScore) 18

19 Results For Authenticated Senders and IP addresses 19

20 RepuScore Evaluations Simulated logs to demonstrate specific properties of RepuScore; and Deployed results from RepuScore Small business in Charlotte. 11 months of deployment (50 users). Results shown from 4 months. Service provider. 9 months of logs (90,000 users: 10,000 users can identify senders). Results shown from 4 months about 4.7 million s. College in Portland, Oregon. 4 months of deployment. (2,000 users) Recent deployment. 20

21 Deploying RepuScore Using Open Source Tools 21

22 SpamAssassin Plug-in Gathers reputation data from receivers about senders and report them to RepuServer. Relies on the SpamAssassin s SPF and DKIM plug-ins to authenticate the sender. Reputation maintained for both IP addresses too. Developed using Perl and MySQL database. Reputation is computed daily using cronjob. Plug-ins are basically filters that can send information to RepuServer. 22

23 Cumulative Distribution of Sender Identities as a function of Reputation ti sender identities had reputation 0 (91.4%). 960 sender identities in between 0 and 1 (2.23%) sender identities had reputation 1 (6.35%). Minimum i Good Number of Good Reputation Domains 0 (From 0 to 1) (From 0.1 to 1) (From 0.2 to 1) (From to 1) (From 0.4 to 1) (From 0.5 to 1) (From 0.6 to 1) (From 0.7 to 1) (From to 1) (From 0.9 to 1) (Reputation of 1)

24 Cumulative Distribution of IP as a function of Reputation ti 89,992 IP had reputation 0 (87.8%) IP in between 0 and 1 (2.28%) IP had reputation 1 (9.82%). Minimum Good Number of Good Reputation Domains 0 (From 0 to 1) (From 0.1 to 1) (From 0.2 to 1) (From 0.3 to 1) (From 0.4 to 1) (From 0.5 to 1) (From 0.6 to 1) (From 0.7 to 1) (From 0.8 to 1) (From 0.9 to 1) (Reputation of 1)

25 Lifetime of a Sender Identity the time ( in days) between the first time the sender identity sent an and the most recent time the sender identity i sent an to the receiver. 25

26 Comparison between RepuScore and Vl Volume Enhanced Eh RepuScore Reputation of a popular free ESP (as observed at Organization 1) using RepuScore and Volume-Enhanced RepuScore. Volume-Enhanced RepuScore reacts based on volume of received. 26

27 Comparison between RepuScore and Volume Enhanced RepuScore for IP Reputation of an IP belonging to business news organization (as observed at Organization 1) using RepuScore and Volume- Enhanced RepuScore. Volume-Enhanced RepuScore reacts based on volume of received. 27

28 Questions? Websites: RepuScore: 28