110 likes | 225 Views
Performing unreliable check using unreliable ID. By: Shiva Srivastava Sankalp Kohli. A temporary solution!! No name of the email provider? What about multi home users. Source spoof network attacks. No proper handling of NAT / proxy No reason for using values while identifying proxies.
E N D
Performing unreliable check using unreliable ID By: Shiva Srivastava SankalpKohli
A temporary solution!! No name of the email provider? What about multi home users. Source spoof network attacks. No proper handling of NAT / proxy No reason for using values while identifying proxies
What is the source of software update data • What about proxy having single hardware id. • Why they checked the remaining 4% manually. • Not sufficient proof.
Are they really bots? • Only 1-2 IP per user. • Single email per user per month!! • Bots send 20 email per month! • If you move around, you are a bot. • Not able to find, then you are a bot. • Email Signup burst because of an advertisement. • Bots use US country code? Random numbers!
What is the source of initial malicious host? • Not capable of the online detection and blocking of responsible activities. • Better solution is crypto-graphical approaches (i.e., AIP, CGA) • What about admins who don’t have any application servers. • Is user IDs the best way to track host-IP binding? • Even if you get host-IP binding then also how can we stop attacks?
First overview Why short term planning. Internet is a dynamic place, this would be outdated in a min.
Design Flaws • They track the user based on email IDs, • I can just use multiple email and get past their traking or just shield myself with NAT. • “Our goal is to generate the host tracking using logs with unreliable ID” • So they are tracking with something that is not even necessarily there.
Design Flaws II • Again they are using email login as an input event. • I am logged in almost all the time at two locations! • They pair up user based on login patter, but this could be totally random too, as incase of neighbors with same schedule.
Result Flaw. • ‘In practice concurrent bindings are a small portion of all the conflicts, and not many groups are affected in this step’ • But again this is for their system, not really true for real world scenario.
Validation flaw • Their accuracy would fall down in case of multiple email. • And basically the malicious users cannot be tracked, so they only track the good guys. • Also they nitpicks the user so that their system can work. Good job. • Oh yeah we are better than naïve approach, yay!
Application flaw • They cannot track NAT users, so how is this good.? • Too many flase positive 20,000. • They want to mess with the end user…. Coz that’s a good idea.