Proposing to Remove IP Blacklist in Dashboard

Projects ID Dashboard
1

While fixing issue and scrutinizing the code, I noticed that we’ve been using IP blacklists provided by DNSBL providers like spamhaus.

However, I think it’s redundant and sometimes blocks our users.

My considerations are,

  • We’ve already used ReCAPTCHA, field name hash, timestamp etc. These methods could effectively filter requests sent by bots.
  • IP in DNSBLs is for email, not for signup page
  • IP in HTTP headers could be spoofed. (We used Apache as reversed proxy. If it’s configured correctly, this could be avoided)
  • Spammers could easily change his IP, while most our users must wait for us to add him into whitelist.

So I think, blacklist is useless and sometimes annoying.

That’s few thoughts I came about, how do you think? @michael, @r0bby, @elliott and others who concerns about Dashboard.

2

I agree that maybe those are not the most appropriate lists for blocking the type of spam we see. These may be more appropriate lists to work from:

If you think there is a security issue please email security■■■■■■■■■■■■ with details on your findings.

3

We see some false positives on this so we know it’s working … but unclear how well it’s working. We have hundreds if not thousands of spam accounts in the system. I don’t know of a good way find an exact number but I know it’s high. The blacklist has certainly not fixed that.

My guess is that the same IP’s are signing up many accounts, but I don’t know this for sure.

We need to do something more/better, so it’s worth looking at other approaches that work better than what we have now.

4

In my opinion… As long as we could stop requests sent by bots, we are fine.

If the spammers register by himself… then I think, on Dashboard’s perspective, he’s a “normal” user.

1 Like
5

Yeah. I don’t think most of the accounts in questions are purely bots, but perhaps human-assisted scripts.

6

I disabled it and removed any migration instructions – instead suggested destroying the SQL db entirely…and defaulted it to not enabled in the example conf and the migration guide does the same.