Registering users' IP addresses
Part of this is installed as a beta feature on this server.see also:
The beta security and antispam features implemented on this server are usually more intended as "let's see if this is effective" than as ready-to-release features with ready-to-copy code: No need to polish code when something isn't effective as a security measure, after all - and that can only be really tested on a "live" server.
So don't expect these beta features to be as "polished" as most beta features are: if they are effective they usually require more work to make them ready for release.
This is the development page for an anti-spam (and anti-abuse) feature intended to trace IP addresses used by (registered) users; this is intended to be able to ban spamming or abusive users by IP address if necessary.The beta security and antispam features implemented on this server are usually more intended as "let's see if this is effective" than as ready-to-release features with ready-to-copy code: No need to polish code when something isn't effective as a security measure, after all - and that can only be really tested on a "live" server.
So don't expect these beta features to be as "polished" as most beta features are: if they are effective they usually require more work to make them ready for release.
Signup IP address
The first (and essential) part is to register the IP address used by someone when signing up for an account.
This requires not only a bit of code, but also an extension to the users database table.
users table
Currently there is only a minimal change to make this possible: the addition of a column called `ipaddress` as varchar(15) DEFAULT NULL at the end of the row.
actions/usersettings.php
The UserSettings action is then adapted to actually fill this column for new registrations.
Before:
- $this->Query("insert into ".$this->config["table_prefix"]."users set ".
- "signuptime = now(), ".
After (beta as installed):
- // ipaddress logging added by JsnX 20050621 (?) to help combat spam
- // made secure by applying mysql_real_escape_string() - JavaWoman 2005-07-18
- $this->Query("insert into ".$this->config["table_prefix"]."users set ".
- "signuptime = now(), ".
actions/register.php
see also:
Since we already have a beta register action on this server, this now records the user's IP address the same way:- // create user
- // ipaddress logging as added by JsnX 20050621 (?) to usersettings.php to help combat spam
- // made secure by applying mysql_real_escape_string() - JavaWoman 2005-07-18
- $this->Query("insert into ".$this->config["table_prefix"]."users set ".
- "signuptime = now(), ".
Effectiveness
By itself, this cannot do very much yet except give us some information when needed to take manual measures.
Deleting a user vs. banning a user
In getting rid of a spamming or otherwise misbehaving registered user there are two possible options: deleting that user from the database (so he's no longer registered) and banning the user. There is also a difference between banning a user by name and banning a user by IP address. All have advantages and disadvantages depending on circumstances:
Deleting a user
- Deleting a user completely removes that user's record from the database.
- For a user who signed up merely to spam, the advantage is that no traces are left behind (provided the spammed pages are properly deleted or cleaned as well); the disadvantage is that a determined spammer could just as fast sign up again, even with the same user name
- For a user who may have actually contributed to the site but later started "misbehaving" it's not a very good solution: we merely want to stop that user from misbehaving but probably leave real contributions in place as well as the user's user page (if any)
Banning a user by name
- Banning a user would just deny access to the user
- For a user who signed up merely to spam, the advantage is that he cannot reuse the name, he just won't be able to use that user account at all any more.
- For a user who is misbehaving, it's a very good solution as it would leave everything positive in place, and could also easily be reversed.
Banning a user by IP address
- Banning a user by IP address is risky: we need to be sure we're actually banning a particular user and not other people using the same ISP who happen to be assigned the same IP address at a different moment (many large ISPs use round-robbin IP address assignments and even a request for a page may use a different IP address than a request for an embedded image!).
- On the other hand, if we are sure the user has a static IP address, it would be a very effective way to ban a spamming user: it would also prevent them from signing up for a new account (provided they still use the same IP address).
- To ban an unregistered user, banning by IP address is the only option. Caution is necessary to make sure the user always uses the same IP address (see above).
More information needed
Obviously, we'll need more information to be able to decide what to do when we find someone is spamming or misbehaving. While (manually for now) deleting a user is an option, it doesn't prevent a spammer from signing up again; and it doesn't make use of the IP address at all. For banning a user by IP address though, we need to be sure the user is actually using a static IP address: for that, we should to record not just the IP address used when registering for an account, but also the address used when creating or editing a page and when adding a comment.
Todo
So the conclusion must be that to make use of the signup IP address to ban a user (without harming innocent users) a lot more information is needed.
Information
First, we need to store more information.
users table
- First of all, the current column added to the users table should be renamed from the somewhat ambiguous `ipaddress` to something more descriptive (we already have `signuptime` so `signupipaddress` would be a lot more descriptive) and then placed next to `signuptime`. Also the size of 15 is enough for an IPv4 address (nnn.nnn.nnn.nnn - (4*4)-1) but not enough to hold an IPv6 address: such addresses are increasingly being used, so if we are going to add a column we'd better make sure it can actually hold all IP addresses. To be able to store any IPv6 address a length of 39 bytes would be needed ((8*5)-1) [1]. Finally, to gather information about IP addresses used, an index on this column would probably be needed as well (currently there isn't one).
- To be able to ban a user by name an extra column in the users table would be needed that records the user's status: an ENUM field called `status` with possible values 'active|disabled|banned' would make banning possible, as well as "disabling" (which could serve as a "recoverable" way of "deleting" a user).
pages table
- We already store the user name for edits in the `user` column; next to this we would add a new column `useripaddresss` to record the ip address the user was working from when making an edit; as with `signupipaddress` in the users table this should have a size of 39 bytes and be indexed. The edit handler should take care this is recorded.
comments table
- We already store the user name for comments in the `user` column; next to this we would add a new column `useripaddresss` to record the ip address the user was working from when adding a comment; as with `signupipaddress` in the users table this should have a size of 39 bytes and be indexed. The addcomment handler should take care this is recorded.
Utilities
Then, given the information about which IP address is used for which activity, we need the utilities to support decision-making and to action based on that decision. So two types of utilities will be needed:
- Utilities to gather and review data about user activity (signup, creating and editing pages, adding comments) and the IP addresses involved in each. When considering banning by IP address it will be necessary to not only look at the activities of a registered user, but also all activity related to the "suspect" IP address (some of which may be by unregistered users).
- Utilities to implement a decision to delete, disable or ban a user, either by name or by IP address. Banning by IP address should be possible either via the .htaccess file or (if this is not supported) via the application itself.
Obviously, a lot still needs to be done in this respect.
preliminary specifications to follow
Only today, three spam comments were added (to two pages); all three had identical content and two were made within minutes of each other - suggesting they were made by the same spammer - but all three had different origin addresses, making it quite likely the spammer was using trojaned machines (and possibly a script). All three origin addresses were listed in one or more blacklists. This is a typical case where banning by IP address would not be effective at all while carrying the risk of hurting innocent users who are not spamming at all. --JW 2005-07-19
References
[1] IPv6 Address Formats
CategoryDevelopmentAntiSpam