TR Forums

Hey guys,

I've been working on a website where contestants for a contest are posted, and each has their own vote button. People are allowed to vote 20 times per day.

I store IP addresses in an XML file with the date they last voted and how many votes they used.

What has happened now is that a few contestants are using the Tor network to change their IPs and give themselves a ton of votes. It's a pretty big prize, and the contest is advertised a lot. So the obvious cheating is making the client look bad, me look bad, and has caused the contestants who don't know how to cheat to stop voting.

What options do I have to stop this?

We don't want to do user registration, because it's obviously annoying, and also because it isn't in the budget haha.

Blocking foreign IPs isn't a good solution, because Tor can easily just change to Canada only exit nodes.

I don't know too much about de-anonymizing Tor, but from what I've read, it is very difficult. For every way to detect it, there is a way for them to stop me from detecting it. A cool way would be to use client-side programs to get me their local IP, but unfortunately, it is likely they will be behind a router anyways.

As of now, I have no idea how we will get around this. I just added a field to the DB showing which contestant the IPs are voting for. That way, I can check the foreign IPs, and see who they are voting for. But if we disqualify someone based on that, it won't be long before other cheaters just starting using Canada-only IPs.

Help would be much appreciated.

Honestly, unless a proxy deliberately announces itself (in headers and such), it is very hard to find and stop.
You may want to had some extra hoops, user registration (with email), CAPCHTAs, etc.. at least to slow them down. I don't see you ever stopping such cheating.

Ya, it will definitely be hard. User registration isn't an option because it's not in their budget, and CAPTCHAs won't help. The cheaters may vote less, but then they will just keep themselves a few hundred votes above the legit contestants instead of a few thousand.

What I need to find out is if I can get access to a list of the Tor network exit nodes, and just block all those IPs. Blocking proxies in general would be impossible, but the only reason these guys are cheating is because Tor is making it so easy. I'm pretty sure if I stop Tor, I won't have any other issues with proxies.

OutlawRecon wrote:

What options do I have to stop this?

The Tor project itself provides a DNS-based and query-based lists of exit nodes. There are pretty decent actual lists of Tor exit nodes for blocking too (as well as known open proxies): http://proxy.org/lists.shtml

You could also try the various DNSBLs for open relays. None will have perfect coverage, but good enough.

Thanks man!

I think what I will do is write an offline program that compares the IP address database with the list from torproject. That way I won't have to iterate through that list every time someone votes. I'll give someone maybe 5 matches on the torproject list, and then I'll suggest they be disqualified.

yeah we used to have that problem too, people would use this thing called ultrasurf to vote, then we just banned all the anonymous proxies. (by ban meaning disqualify any known anonymous proxies) not sure how the tech guys did it though will ask tomorrow. and wats the prize?

OutlawRecon wrote:

I think what I will do is write an offline program that compares the IP address database with the list from torproject. That way I won't have to iterate through that list every time someone votes.

As an aside, if you want to do matching versus a list of IP addresses without iterating through the entire list, you can build a trie or a radix tree out of the banned IPs.

Basically, a path through the tree represents an IP address. The structure of the tree itself implicitly encodes the bits of all of the blocked IPs, and searching the tree is matching against those IPs by finding a path through it. For example, at the root node, going left implies that the first bit of the IP address is 0, while going right implies it is 1. After that, you mask off the next bit and again branch left/right and so forth. If you run into a sentinel node (null or whatever) before you complete the match, the IP isn't in the list. An interesting thing about this representation is that it also allows you to make it more compact by merging "subnets" (full subtrees) when you are building the trie. So at the bottom levels, if you have 1.1.1.0 and 1.1.1.1, you can merge them into 1.1.1.0/31 node which indicates that you have a full subtree (a wildcard match). You can then recursively merge all full subtrees into these nodes which basically short circuit the traversal -- these special merged nodes tell you that you can stop traversal immediately because all possible permutations of bits will be present*. Matching each IP address then only requires 32 traversal steps maximum, one for each bit.

Alternately, the pragmatist in my says you could use gperf to generate a perfectly hashed table of IPs and be done with it (which will probably end up being more compact anyway unless there's a lot of subtree merging), but then I couldn't pontificate about algorithms that I find elegant or interesting.

* Of course, in practice, you'd have to have real subnetting information to properly merge everything possible since the broadcast and network addresses of proper subnets won't ever appear on the list since they aren't valid host IPs (but you'd still want to merge those together since you have the full usable subnet).

Haha that is slick, but I just finished an assignment on binary search trees in C++ yesterday, and the radix tree would not be fun. But I bet I could get that hash table made in C# pretty fast.

Just stuff the banned IPs into a database table, and let the database engine do the searching... as long as the table is indexed, the overhead should be negligible for an application like this.