2.3.1: Banning from Tracked Menu...

Posted: Thu Jul 07, 2005 2:01 pm

Earlier posts indicated that ABBlockedIPAddSave.php needed to have it's extraneuous insert variables trimmed, but....

ABTrackedAddSave.php needs to similary be adjusted!!

I did that and now banning from tracked IP works like a charm.

registered · Posted: Fri Jul 08, 2005 11:09 pm

After getting your email I checked the inserts and they matched up. Your blocked_ips table should be as follows:

Code:

CREATE TABLE IF NOT EXISTS `bf2_nsnst_blocked_ips` (


  `ip_addr` varchar(15) NOT NULL default '',


  `user_id` int(11) NOT NULL default '1',


  `username` varchar(60) NOT NULL default 'Anonymous',


  `user_agent` text NOT NULL,


  `date` int(20) NOT NULL default '0',


  `notes` text NOT NULL,


  `reason` tinyint(1) NOT NULL default '0',


  `query_string` text NOT NULL,


  `get_string` text NOT NULL,


  `post_string` text NOT NULL,


  `x_forward_for` varchar(32) NOT NULL default 'None',


  `client_ip` varchar(32) NOT NULL default 'None',


  `remote_addr` varchar(32) NOT NULL default '',


  `remote_port` varchar(11) NOT NULL default 'Unknown',


  `request_method` varchar(10) NOT NULL default '',


  `expires` int(20) NOT NULL default '0',


  `c2c` char(2) NOT NULL default '00',


  PRIMARY KEY  (`ip_addr`)


) TYPE=MyISAM;

My delay in repling to your email is mostly due to time constraints but I also wanted to make sure I double checked the insert against a freshly installed copy of 2.3.1 . While saying this I have not gone back to a lower and slowly upgraded to make sure the table changes have taken place like they should yet, here again due to time constraints but I will check that route as well.

Long story short that newly created table matches perfectly to the insert, and upgraded table may not but I will find that out as well.

Posted: Mon Jul 11, 2005 9:33 am

Thanks, but now issue is that blocks by Sentinel into .htaccess are not being inserted into blocked ips table.

I get my admin email alerting, check .htaccess and seny deny from xxx.xxx.xxx.xxx and then it's not in tables (ranged or individual).

Is there a php script I can check to see where this action (append to .htaccess and insert into tables) is taking place?

Much help on the table though...now all inserts (manual) are working!

Posted: Mon Jul 11, 2005 9:52 am

Compare your blocked ip's table to this:

Code:

CREATE TABLE IF NOT EXISTS `bf2_nsnst_blocked_ips` (


  `ip_addr` varchar(15) NOT NULL default '',


  `user_id` int(11) NOT NULL default '1',


  `username` varchar(60) NOT NULL default '',


  `user_agent` text NOT NULL,


  `date` int(20) NOT NULL default '0',


  `notes` text NOT NULL,


  `reason` tinyint(1) NOT NULL default '0',


  `query_string` text NOT NULL,


  `get_string` text NOT NULL,


  `post_string` text NOT NULL,


  `x_forward_for` varchar(32) NOT NULL default '',


  `client_ip` varchar(32) NOT NULL default '',


  `remote_addr` varchar(32) NOT NULL default '',


  `remote_port` varchar(11) NOT NULL default '',


  `request_method` varchar(10) NOT NULL default '',


  `expires` int(20) NOT NULL default '0',


  `c2c` char(2) NOT NULL default '00',


  PRIMARY KEY  (`ip_addr`)


) TYPE=MyISAM;

It almost sounds like your db is missing an upgrade somewhere along the line.

The script that writes to the db and htaccess is the includes/nukesentinel.php file. The routine is the write_ban($banip, $htip, $blocker_row) { function that starts around line 713.

One thing to try is find:

Code:

      $db->sql_query("INSERT INTO `".$prefix."_nsnst_blocked_ips` VALUES ('$banip', '".$nsnst_const['ban_user_id']."', '".$nsnst_const['ban_username']."', '".$nsnst_const['user_agent']."', '".$nsnst_const['ban_time']."', '$addby', '".$blocker_row['blocker']."', '$querystring', '$getstring', '$poststring', '".$nsnst_const['forward_ip']."', '".$nsnst_const['client_ip']."', '".$nsnst_const['remote_addr']."', '".$nsnst_const['remote_port']."', '".$nsnst_const['request_method']."', '$abexpires', '$c2c')");

should be at line 757 and replace it with:

Code:

      if (!get_magic_quotes_runtime()) {


        $addby = addslashes($addby);


        $ban_username = addslashes($nsnst_const['ban_username']);


        $user_agent = addslashes($nsnst_const['user_agent']);


      }


      $db->sql_query("INSERT INTO `".$prefix."_nsnst_blocked_ips` VALUES ('$banip', '".$nsnst_const['ban_user_id']."', '$ban_username', '$user_agent', '".$nsnst_const['ban_time']."', '$addby', '".$blocker_row['blocker']."', '$querystring', '$getstring', '$poststring', '".$nsnst_const['forward_ip']."', '".$nsnst_const['client_ip']."', '".$nsnst_const['remote_addr']."', '".$nsnst_const['remote_port']."', '".$nsnst_const['request_method']."', '$abexpires', '$c2c')");

This is a change I'm putting in for 2.3.2 to account for servers that don't automaticly add slashes for db inserts.

Posted: Mon Jul 11, 2005 10:07 am

I can tell ya the issue is going to be this:

In the 2 php scripts that insert into blocked_ips table (basic one and the one from tracked ips).

There is an insert statement that looks like it's inserting into query_string 3 times (meaning it's phrased to insert the same variable 3 times when there is only one query_string column).

So I've seen forum posts indicating the correct action is to take the extra 2 variables off the insert...this fixes the manual inserts.

But...now in the table def you show me also query_string, get_string, and post_string and only query_string is currently in my table (which explains why trimming the inserts statements to one variable from 3 works).

My immediate soluion seems to be: add the 2 columns to my table and then go re-address the 2 manual insert php scripts to add in the 2 extra fields.

Then I'll try an attack and see if it bans correctly (to htaccess AND tables) and then also try to manuall ban an ip from basic and tracked.

Posted: Mon Jul 11, 2005 10:39 am

Which version of NukeSentinel(tm) are you using? Is it a verison prior to 2.2.0? The new fields were added for 2.2.0 and up. I just looked at the upgrades scripts and it does add them in the 2.1.3 to 2.2.0 upgrade.

Posted: Mon Jul 11, 2005 10:45 am

I'm using 2.3.1....

Issue was I came from 2.1.3 and each of the upgrade scripts worked except for one which always errored (malformed something or other)...it's the big one probably the one to get to 2.2.0.

Anyway, I'm sure that's where all this problem came from.

But just to clarify for the group:

In 2.3.1:

ABBlockIPAddSave.php: Needs all three inserts of '$temp_qs' if your table has all three columns: query_string, get_string, post_string.

Similarly ABTrackedAddSave.php needs all three inserts of '".$tidinfo['query_string']."'

These are in admin/modules/nukesentinel

Confusion is that some posts here are saying to trim the extra '$temp_qs' in the inserts from [3] to [1] but that's only if you're database table doesn't have all [3] columns.

Posted: Mon Jul 11, 2005 12:34 pm

I'll look at the 2.1.3 to 2.2.0 upgrade script to see where it could be erroring out.

Posted: Thu Jul 14, 2005 8:10 am

Thanks Bob,

Looks like I could a harvester and got the email, and saw it went in .htaccess and blocked ips table (shows up in blocked Ips module).

Question though: Now all blocked and tracked IPs listings have a (00) Unknown country yet I have a fully loaded (~35k rows) ip2c table along with having all the flag images in the correct place and the countries table (c2c) entries filled in.

I can manually flip the countries and it then shows the right flag, but I'm concerned it's not working right as Sentinel bans....

Posted: Thu Jul 14, 2005 8:14 am

Umm...might this be because everytime I look at IP address in Sentinel (from Admin panel) all the IPs are shown backwards?

e.g., 192.168.0.1 shows as 1.0.168.192 ?