Feature Request: IP location filter for users to access board

[KT Walrus]

I was thinking tonight how I might handle a DDoS attack, and it occurs to me that IPB could maintain a white-list of valid IPs that the member has accessed the board from in the past and conditionally challenge the user to validate a suspicious IP that hasn't been seen before for that user.

I'm thinking I would like to allow my users to access my board unchallenged when using an IP from within the country they registered from. MaxMind has a free database of IPs that can give you the country for an IP. Using this database, IPB could lookup the country when a user accesses my board. If outside the registration country (... there could be options for other rules to be applied), then IPB could lookup whether that Country has been approved yet for board access. If so, the access would be allowed (and the IP would be added to a list of approved IPs for the user in that Country). If not, an email could be sent to the user (like done for registration) that would have a link to add the IP and Country to the list of approved IP addresses and Countries for the user. After that, the user should have access as always unless they travel to another Country not in the list (which would be subject to email approval again). Country approvals could be expired automatically after X days. If inside the user's registration country, the IP could be added for the user as a known IP for the user (for use when mitigating a DDoS attack).

Anyway, if this feature would be implemented, I could generate a white-list of IPs for a router to filter packets during a DDoS attack. During an attack, I think it might work to allow other IPs through for up to X page requests where the IP is either known to have been used by the user previously or a challenge is generated (for IPs outside the user's country). If the challenge email link is responded to within X page requests of IPB, the IP would be added to the router's white-list. Otherwise, the IP would be added to the black-list of IPs and denied subsequent TCP access to the site.

It could also be implemented as challenging all previously unknown IP accesses (even within the approved countries for the user) during an attack (or even all the time). I'm just not sure how invasive these challenges could be (like accessing from a mobile device on the go that is switching IP addresses frequently).

This feature would also make non-authorized log in by someone that just happens to know someone's email/password harder since they could have to respond to the IP challenge email.

Just a thought... I think it might be a nice feature, especially for boards that might be vulnerable to DDoS attacks.

[Joshua F]

Even if you did something like that, since a DDoS is multiple IP's from different locations I don't think this would help much. Also, you would have to stop it somewhere with a firewall, otherwise they are still sending packets to your webserver, meaning it won't help stop a DDoS attack at all.

[KT Walrus]

Even if you did something like that, since a DDoS is multiple IP's from different locations I don't think this would help much. Also, you would have to stop it somewhere with a firewall, otherwise they are still sending packets to your webserver, meaning it won't help stop a DDoS attack at all.

I don't think you got my point. I can use the saved IP information to create a white-list of permitted IPs for the firewall during a DDoS attack and have the firewall drop all other packets. I could also use this white-list to build a black-list for the firewall during the attack so IPs could be allowed access for a limited number of requests before adding to the blacklist (giving the legitimate user a chance of validating their access). This would allow most users to continue using the site if they are coming from a previously seen IP or newly authorized IP. During the attack, some legitimate users might be rejected, but this is better than null routing the site and not being up for anyone.

Another, less intrusive method, might just be to assume logged in users are legitimate and just record their IP as legitimate. During an attack, this white-list could be enough to manage the attack (providing you would allow 10 requests/minute or so per IP to log in successfully before black-listing the IP for an hour or two).