[aur-dev] [PATCH] Add an IP ban list

newer
[aur-dev] [PATCH 1/2] Add "Bans"...

older
[aur-dev] [PATCH] Return 404 error...

Lukas Fleischer

19 Mar 2013 19 Mar '13

1:23 p.m.

This allows for specifying a list of IP addresses that will no longer be able to register new accounts and login. The list of banned IP addresses can be configured in "web/lib/config.inc.php". Signed-off-by: Lukas Fleischer --- web/lib/acctfuncs.inc.php | 24 +++++++++++++++++++++--- web/lib/config.inc.php.proto | 3 +++ 2 files changed, 24 insertions(+), 3 deletions(-) diff --git a/web/lib/acctfuncs.inc.php b/web/lib/acctfuncs.inc.php index aabb096..c202f47 100644 --- a/web/lib/acctfuncs.inc.php +++ b/web/lib/acctfuncs.inc.php @@ -91,7 +91,17 @@ function process_account_form($UTYPE,$TYPE,$A,$U="",$T="",$S="",$E="", $P="",$C="",$R="",$L="",$I="",$K="",$UID=0) { # error check and process request for a new/modified account - global $SUPPORTED_LANGS, $AUR_LOCATION; + global $SUPPORTED_LANGS, $AUR_LOCATION, $BANNED_IPS; + + $error = ""; + + if (in_array($_SERVER['REMOTE_ADDR'], $BANNED_IPS)) { + $error = __('The login form is currently ' . + 'disabled for your IP address, probably due ' . + 'to sustained spam attacks. Sorry for the ' . + 'inconvenience -- we hope to be back up ' . + 'soon.'); + } $dbh = DB::connect(); @@ -102,7 +112,6 @@ function process_account_form($UTYPE,$TYPE,$A,$U="",$T="",$S="",$E="", $editor_user = null; } - $error = ""; if (empty($E) || empty($U)) { $error = __("Missing a required field."); } @@ -393,13 +402,22 @@ function search_results_page($UTYPE,$O=0,$SB="",$U="",$T="", * @return array Session ID for user, error message if applicable */ function try_login() { - global $MAX_SESSIONS_PER_USER, $PERSISTENT_COOKIE_TIMEOUT; + global $MAX_SESSIONS_PER_USER, $PERSISTENT_COOKIE_TIMEOUT, $BANNED_IPS; $login_error = ""; $new_sid = ""; $userID = null; if ( isset($_REQUEST['user']) || isset($_REQUEST['passwd']) ) { + if (in_array($_SERVER['REMOTE_ADDR'], $BANNED_IPS)) { + $login_error = __('The login form is currently ' . + 'disabled for your IP address, probably due ' . + 'to sustained spam attacks. Sorry for the ' . + 'inconvenience -- we hope to be back up ' . + 'soon.'); + return array('SID' => '', 'error' => $login_error); + } + $dbh = DB::connect(); $userID = valid_user($_REQUEST['user']); diff --git a/web/lib/config.inc.php.proto b/web/lib/config.inc.php.proto index 1fe7dbc..0422ac5 100644 --- a/web/lib/config.inc.php.proto +++ b/web/lib/config.inc.php.proto @@ -59,3 +59,6 @@ $USE_VIRTUAL_URLS = true; # Maximum number of package results to return through an RPC connection. # Avoid setting this too high and having a PHP too much memory error. $MAX_RPC_RESULTS = 5000; + +# Prevent a list of remote addresses from logging in and creating new accounts. +$BANNED_IPS = array(); -- 1.8.2.480.g556678c

Show replies by date

canyonknight

19 Mar 19 Mar

9:12 p.m.

On Tue, Mar 19, 2013 at 9:23 AM, Lukas Fleischer wrote:

...

This allows for specifying a list of IP addresses that will no longer be able to register new accounts and login. The list of banned IP addresses can be configured in "web/lib/config.inc.php".

Signed-off-by: Lukas Fleischer ---

What are your thoughts on taking this a step further and adding a "bans" table to the DB schema? It could eventually be extended to allow for TUs and Developers to ban IP addresses directly from the web interface without ever having to muck around with the config file.

...

web/lib/acctfuncs.inc.php | 24 +++++++++++++++++++++--- web/lib/config.inc.php.proto | 3 +++ 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/web/lib/acctfuncs.inc.php b/web/lib/acctfuncs.inc.php index aabb096..c202f47 100644 --- a/web/lib/acctfuncs.inc.php +++ b/web/lib/acctfuncs.inc.php @@ -91,7 +91,17 @@ function process_account_form($UTYPE,$TYPE,$A,$U="",$T="",$S="",$E="", $P="",$C="",$R="",$L="",$I="",$K="",$UID=0) {

# error check and process request for a new/modified account - global $SUPPORTED_LANGS, $AUR_LOCATION; + global $SUPPORTED_LANGS, $AUR_LOCATION, $BANNED_IPS; + + $error = ""; + + if (in_array($_SERVER['REMOTE_ADDR'], $BANNED_IPS)) { + $error = __('The login form is currently ' . + 'disabled for your IP address, probably due ' . + 'to sustained spam attacks. Sorry for the ' . + 'inconvenience -- we hope to be back up ' . + 'soon.'); + }

$dbh = DB::connect();

@@ -102,7 +112,6 @@ function process_account_form($UTYPE,$TYPE,$A,$U="",$T="",$S="",$E="", $editor_user = null; }

- $error = ""; if (empty($E) || empty($U)) { $error = __("Missing a required field."); } @@ -393,13 +402,22 @@ function search_results_page($UTYPE,$O=0,$SB="",$U="",$T="", * @return array Session ID for user, error message if applicable */ function try_login() { - global $MAX_SESSIONS_PER_USER, $PERSISTENT_COOKIE_TIMEOUT; + global $MAX_SESSIONS_PER_USER, $PERSISTENT_COOKIE_TIMEOUT, $BANNED_IPS;

$login_error = ""; $new_sid = ""; $userID = null;

if ( isset($_REQUEST['user']) || isset($_REQUEST['passwd']) ) { + if (in_array($_SERVER['REMOTE_ADDR'], $BANNED_IPS)) { + $login_error = __('The login form is currently ' . + 'disabled for your IP address, probably due ' . + 'to sustained spam attacks. Sorry for the ' . + 'inconvenience -- we hope to be back up ' . + 'soon.'); + return array('SID' => '', 'error' => $login_error); + } + $dbh = DB::connect(); $userID = valid_user($_REQUEST['user']);

diff --git a/web/lib/config.inc.php.proto b/web/lib/config.inc.php.proto index 1fe7dbc..0422ac5 100644 --- a/web/lib/config.inc.php.proto +++ b/web/lib/config.inc.php.proto @@ -59,3 +59,6 @@ $USE_VIRTUAL_URLS = true; # Maximum number of package results to return through an RPC connection. # Avoid setting this too high and having a PHP too much memory error. $MAX_RPC_RESULTS = 5000; + +# Prevent a list of remote addresses from logging in and creating new accounts. +$BANNED_IPS = array(); -- 1.8.2.480.g556678c

Lukas Fleischer

9:42 p.m.

On Tue, Mar 19, 2013 at 05:12:23PM -0400, canyonknight wrote:

...

On Tue, Mar 19, 2013 at 9:23 AM, Lukas Fleischer wrote:

...
This allows for specifying a list of IP addresses that will no longer be able to register new accounts and login. The list of banned IP addresses can be configured in "web/lib/config.inc.php".

Signed-off-by: Lukas Fleischer ---

What are your thoughts on taking this a step further and adding a "bans" table to the DB schema? It could eventually be extended to allow for TUs and Developers to ban IP addresses directly from the web interface without ever having to muck around with the config file.

Exactly what I was planning to do. We should also display each user's last login IP address in his profile (only visible to developers and TUs) and add a "Ban this IP address" button next to it. The "Save last login IP address" patch I submitted already adds the IP address to the Users table. Oh, and we might want to exclude TUs and developers from IP bans.

...

...
web/lib/acctfuncs.inc.php | 24 +++++++++++++++++++++--- web/lib/config.inc.php.proto | 3 +++ 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/web/lib/acctfuncs.inc.php b/web/lib/acctfuncs.inc.php index aabb096..c202f47 100644 --- a/web/lib/acctfuncs.inc.php +++ b/web/lib/acctfuncs.inc.php @@ -91,7 +91,17 @@ function process_account_form($UTYPE,$TYPE,$A,$U="",$T="",$S="",$E="", $P="",$C="",$R="",$L="",$I="",$K="",$UID=0) {

# error check and process request for a new/modified account - global $SUPPORTED_LANGS, $AUR_LOCATION; + global $SUPPORTED_LANGS, $AUR_LOCATION, $BANNED_IPS; + + $error = ""; + + if (in_array($_SERVER['REMOTE_ADDR'], $BANNED_IPS)) { + $error = __('The login form is currently ' . + 'disabled for your IP address, probably due ' . + 'to sustained spam attacks. Sorry for the ' . + 'inconvenience -- we hope to be back up ' . + 'soon.'); + }

$dbh = DB::connect();

@@ -102,7 +112,6 @@ function process_account_form($UTYPE,$TYPE,$A,$U="",$T="",$S="",$E="", $editor_user = null; }

- $error = ""; if (empty($E) || empty($U)) { $error = __("Missing a required field."); } @@ -393,13 +402,22 @@ function search_results_page($UTYPE,$O=0,$SB="",$U="",$T="", * @return array Session ID for user, error message if applicable */ function try_login() { - global $MAX_SESSIONS_PER_USER, $PERSISTENT_COOKIE_TIMEOUT; + global $MAX_SESSIONS_PER_USER, $PERSISTENT_COOKIE_TIMEOUT, $BANNED_IPS;

$login_error = ""; $new_sid = ""; $userID = null;

if ( isset($_REQUEST['user']) || isset($_REQUEST['passwd']) ) { + if (in_array($_SERVER['REMOTE_ADDR'], $BANNED_IPS)) { + $login_error = __('The login form is currently ' . + 'disabled for your IP address, probably due ' . + 'to sustained spam attacks. Sorry for the ' . + 'inconvenience -- we hope to be back up ' . + 'soon.'); + return array('SID' => '', 'error' => $login_error); + } + $dbh = DB::connect(); $userID = valid_user($_REQUEST['user']);

diff --git a/web/lib/config.inc.php.proto b/web/lib/config.inc.php.proto index 1fe7dbc..0422ac5 100644 --- a/web/lib/config.inc.php.proto +++ b/web/lib/config.inc.php.proto @@ -59,3 +59,6 @@ $USE_VIRTUAL_URLS = true; # Maximum number of package results to return through an RPC connection. # Avoid setting this too high and having a PHP too much memory error. $MAX_RPC_RESULTS = 5000; + +# Prevent a list of remote addresses from logging in and creating new accounts. +$BANNED_IPS = array(); -- 1.8.2.480.g556678c

Xyne

20 Mar 20 Mar

9:54 p.m.

On 2013-03-19 22:42 +0100 Lukas Fleischer wrote:

...

On Tue, Mar 19, 2013 at 05:12:23PM -0400, canyonknight wrote:

...
On Tue, Mar 19, 2013 at 9:23 AM, Lukas Fleischer wrote:

...
This allows for specifying a list of IP addresses that will no longer be able to register new accounts and login. The list of banned IP addresses can be configured in "web/lib/config.inc.php".

Signed-off-by: Lukas Fleischer ---

What are your thoughts on taking this a step further and adding a "bans" table to the DB schema? It could eventually be extended to allow for TUs and Developers to ban IP addresses directly from the web interface without ever having to muck around with the config file.

Exactly what I was planning to do.

We should also display each user's last login IP address in his profile (only visible to developers and TUs) and add a "Ban this IP address" button next to it. The "Save last login IP address" patch I submitted already adds the IP address to the Users table.

Do the IPs need to be visible? In the case of a single IP a simple ban button will suffice. A proxied IP will be completely different every time so subsequent addresses are unrelated. That only leaves netmasked dynamic IPs. It would be enough to have an interface button connected to a query that returns all users with an IP in the netmasked range (/24?). You could even automatically flag user accounts that share a range with banned IPs, again without divulging the IP address.

...

Oh, and we might want to exclude TUs and developers from IP bans.

I haven't tried it, but can't TUs disable each other's TU status? The exclusion would be trivial if so.

Lukas Fleischer

11:11 p.m.

On Wed, Mar 20, 2013 at 09:54:58PM +0000, Xyne wrote:

...

On 2013-03-19 22:42 +0100 Lukas Fleischer wrote:

...
On Tue, Mar 19, 2013 at 05:12:23PM -0400, canyonknight wrote:

...
On Tue, Mar 19, 2013 at 9:23 AM, Lukas Fleischer wrote:

...
This allows for specifying a list of IP addresses that will no longer be able to register new accounts and login. The list of banned IP addresses can be configured in "web/lib/config.inc.php".

Signed-off-by: Lukas Fleischer ---

What are your thoughts on taking this a step further and adding a "bans" table to the DB schema? It could eventually be extended to allow for TUs and Developers to ban IP addresses directly from the web interface without ever having to muck around with the config file.

Exactly what I was planning to do.

We should also display each user's last login IP address in his profile (only visible to developers and TUs) and add a "Ban this IP address" button next to it. The "Save last login IP address" patch I submitted already adds the IP address to the Users table.

Do the IPs need to be visible? In the case of a single IP a simple ban button will suffice. A proxied IP will be completely different every time so subsequent addresses are unrelated. That only leaves netmasked dynamic IPs. It would be enough to have an interface button connected to a query that returns all users with an IP in the netmasked range (/24?). You could even automatically flag user accounts that share a range with banned IPs, again without divulging the IP address.

This is not the whole truth. To stop the latest spam attack, we had a look at the web server logs, noticed that the spammer was using Tor, generated a list of Tor exit nodes and added that to the IP ban list. How would you do that without seeing any IP addresses? How would you figure out if a spammer is just controlling 4-5 small subnets or using proxies at all? If you feel strongly about not showing IP addresses, we could hide IP addresses for TUs and only show them to the AUR administrator(s) who can skim through the logs anyway.

...

...
Oh, and we might want to exclude TUs and developers from IP bans.

I haven't tried it, but can't TUs disable each other's TU status? The exclusion would be trivial if so.

Yes, they can. I did not mean to allege anything here -- I just wanted to make sure that banning a range of IP addresses doesn't (unintentionally) block any Trusted Users or developers.

Xyne

21 Mar 21 Mar

8:30 p.m.

Lukas Fleischer wrote:

...

...
Do the IPs need to be visible? In the case of a single IP a simple ban button will suffice. A proxied IP will be completely different every time so subsequent addresses are unrelated. That only leaves netmasked dynamic IPs. It would be enough to have an interface button connected to a query that returns all users with an IP in the netmasked range (/24?). You could even automatically flag user accounts that share a range with banned IPs, again without divulging the IP address.

This is not the whole truth. To stop the latest spam attack, we had a look at the web server logs, noticed that the spammer was using Tor, generated a list of Tor exit nodes and added that to the IP ban list. How would you do that without seeing any IP addresses? How would you figure out if a spammer is just controlling 4-5 small subnets or using proxies at all?

Fair enough. Incidentally, can a banned IP address still be used to browse the site and download packages? There are many people who use Tor and other proxies for various reasons and it would be a shame if they have to suffer due to one basement-dwelling troll. Essentially only the login and post forms would need to respect the ban. Sorry if this has been addressed already. I haven't read through the patches.

...

If you feel strongly about not showing IP addresses, we could hide IP addresses for TUs and only show them to the AUR administrator(s) who can skim through the logs anyway.

Please do. Thanks.

...

Yes, they can. I did not mean to allege anything here -- I just wanted to make sure that banning a range of IP addresses doesn't (unintentionally) block any Trusted Users or developers.

That would make for a great post in the stupid computer mistakes thread... it would be on the same level as ssh'ing into a box and killing the network.

Lukas Fleischer

9:25 p.m.

On Thu, Mar 21, 2013 at 08:30:38PM +0000, Xyne wrote:

...

Lukas Fleischer wrote:

...
...
Do the IPs need to be visible? In the case of a single IP a simple ban button will suffice. A proxied IP will be completely different every time so subsequent addresses are unrelated. That only leaves netmasked dynamic IPs. It would be enough to have an interface button connected to a query that returns all users with an IP in the netmasked range (/24?). You could even automatically flag user accounts that share a range with banned IPs, again without divulging the IP address.

This is not the whole truth. To stop the latest spam attack, we had a look at the web server logs, noticed that the spammer was using Tor, generated a list of Tor exit nodes and added that to the IP ban list. How would you do that without seeing any IP addresses? How would you figure out if a spammer is just controlling 4-5 small subnets or using proxies at all?

Fair enough.

Incidentally, can a banned IP address still be used to browse the site and download packages? There are many people who use Tor and other proxies for various reasons and it would be a shame if they have to suffer due to one basement-dwelling troll. Essentially only the login and post forms would need to respect the ban.

We only block account creation and login. If a spammer still has a valid session, we can clear all active sessions to enforce a logout.

...

Sorry if this has been addressed already. I haven't read through the patches.

...
If you feel strongly about not showing IP addresses, we could hide IP addresses for TUs and only show them to the AUR administrator(s) who can skim through the logs anyway.

Please do. Thanks.

...
Yes, they can. I did not mean to allege anything here -- I just wanted to make sure that banning a range of IP addresses doesn't (unintentionally) block any Trusted Users or developers.

That would make for a great post in the stupid computer mistakes thread... it would be on the same level as ssh'ing into a box and killing the network.

Alexander Griesbaum

23 Mar 23 Mar

4:41 p.m.

On Thu, Mar 21, 2013 at 10:25 PM, Lukas Fleischer wrote:

...

On Thu, Mar 21, 2013 at 08:30:38PM +0000, Xyne wrote:

...
Lukas Fleischer wrote:

...
...
Do the IPs need to be visible? In the case of a single IP a simple ban button will suffice. A proxied IP will be completely different every time so subsequent addresses are unrelated. That only leaves netmasked dynamic IPs. It would be enough to have an interface button connected to a query that returns all users with an IP in the netmasked range (/24?). You could even automatically flag user accounts that share a range with banned IPs, again without divulging the IP address.

This is not the whole truth. To stop the latest spam attack, we had a look at the web server logs, noticed that the spammer was using Tor, generated a list of Tor exit nodes and added that to the IP ban list. How would you do that without seeing any IP addresses? How would you figure out if a spammer is just controlling 4-5 small subnets or using proxies at all?

Fair enough.

Incidentally, can a banned IP address still be used to browse the site and download packages? There are many people who use Tor and other proxies for various reasons and it would be a shame if they have to suffer due to one basement-dwelling troll. Essentially only the login and post forms would need to respect the ban.

We only block account creation and login. If a spammer still has a valid session, we can clear all active sessions to enforce a logout.

It does also affect account modification, doesn't it? I didn't see any differentiation in process_account_form().

...

...
Sorry if this has been addressed already. I haven't read through the patches.

...
If you feel strongly about not showing IP addresses, we could hide IP addresses for TUs and only show them to the AUR administrator(s) who can skim through the logs anyway.

Please do. Thanks.

...
Yes, they can. I did not mean to allege anything here -- I just wanted to make sure that banning a range of IP addresses doesn't (unintentionally) block any Trusted Users or developers.

That would make for a great post in the stupid computer mistakes thread... it would be on the same level as ssh'ing into a box and killing the network.

4060

Age (days ago)

4064

Last active (days ago)

List overview

Download

7 comments

4 participants

participants (4)

Alexander Griesbaum
canyonknight
Lukas Fleischer
Xyne