To troll or not to troll?

Question

Similar to this question but not a duplicate.

On my current project, we've already had a few problems with trolls and kiddie-hackers trying to get at our backend. We've now asked some other companies to help us out by giving us any data they have on known trolls, such as IP address.

Most of the attacks are coming through XSS on one particular page, and although we're working on a fix for this it could take quite a while. So I was thinking what would be best as a temporary fix?

One possibility: flat 403 deny access to known trolls' IPs. Problem: they can move to a different computer.

Another: I thought of trolling them back. So, on the one page, I could subtly alter some things, detect keypresses and the like, and use this data to mess up their interaction. For example: they start typing something into a text field, I could periodically erase some of it at random, or change what they've typed. This would have the advantage of them being more likely to stay at the same computer for longer, and it would change any code they try to write.

What do you think? Out of those two, to troll or not to troll? Of course, feel free to suggest other ideas.

Answer 1

Don't troll.

Sure, you could attempt to mess around with the people trying to get into your systems, but there are a number of issues with this approach.

First of all, there is the risk that you'll catch legitimate customers/users who are trying to access your project. This could happen for a number of reasons, such as a banned IP address getting reassigned, the attacker using a public computer/VPN/spoofing their IP address, or a whole host of other reasons. It's worth pointing out the fact that a legitimate user won't be happy about being banned either, but as long as it is clear why they seem to be banned (such as by providing an error message), they're more likely to be accepting of it. If you lower the quality of your project by making it seem buggy, a user isn't going figure out the real reason that they getting these bugs, they'll think "this is a low quality project and I don't want to use it". Blocking them with an error message will help them understand what's gone wrong, but introducing subtle bugs that ruin the experience will make sure that they leave with a low opinion of your project. Banning them is the lesser of two evils.

The second problem is that you're poking the bear. At the moment, these attackers may simply be trying to see if they can break into a project for the fun of it, or to cause a bit of mischief (I will make a point that this doesn't make it OK, but it's certainly better than if they were attempting to disrupt service, steal passwords etc.). If they find out that you're attempting to retaliate against them, I'd posit that they would be much more willing to attempt to cause more costly damage. Retaliating isn't likely to make them stop, but it is likely to make them annoyed. It's worth mentioning that this point is making the assumption that the attackers aren't attempting to cause real damage from the offset. It's worth taking this with a grain of salt depending on your actual situation.

Thirdly, writing and testing the code that performs these actions (randomly deleting portions of their search field for example) takes time and effort that I'm sure could be much better spent either trying to prevent the problem or generally improving the project. You didn't specify whether this is a personal project or if it is for a business, but in either case I wouldn't be comfortable spending time on something unlikely to give you any kind of benefit.

In regards to other options available to you to help prevent this issue, I would recommend one of the following (dependent on what kind of project it is of course):

• Require an account (either from the outset or only for blocked IP addresses, similar to how Wikipedia does it)
• Temporarily block IP addresses
• Add more security to the backend

All in all, retaliating may make you feel better for a short while as you feel like you're "getting them back", but I would say that the negatives easily outweigh the positives in this situation.

Answer 2

Firstly, how reliable is the IP list?

Plus, it is most probable that the hacker's IP will not be listed in the list(due to proxies etc).

Now, lets say that the IP is inside the list then out of the two solutions the cool one is definitely the second one, the relief you get when you know that the messers are being messed with. Although, I am speaking from experience that this only makes them more desperate towards their cause(this might vary from person to person).

So for the time being the first solution seems fine as your work will be more in the second solution, but fixing the XSS should be your top priority.

Answer 3

Don't troll back. Paying them attention is the worst you can do. Or as George Bernard Shaw put it:

"I learned long ago, never to wrestle with a pig. You get dirty, and besides, the pig likes it."

If possible ignore their attempts and silently revert their comments after some time. Ideally an automatic process can do this.

It might sound strange, but a troll always using the same IP/same user name is actually the best that can happen (apart from going away of course). This way you can always keep track of their actions and thus have a better control over them.

I've been working with trolls for some years now, and added some thoughts and findings about trolls in my answer over here.