Ravens PHP Scripts: Forums
 

 

View next topic
View previous topic
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> NukeSentinel™
Author Message
arlinorlando
New Member
New Member


Joined: Oct 09, 2006
Posts: 2

PostPosted: Thu Dec 21, 2006 7:45 pm Reply with quote

Hi,

Nuke Sentinel seems to be blocking "none" for an IP when it is unable to determine Clients Ip, for example:

Forwarded For: none
Client IP: none
Remote Address: 81.182.246.8
Remote Port: 35176
Request Method: GET

He is actualy adding "none..." to the blocked IP list... And when "none..." is on the blocked IP list, everybody with "Client IP: none" are blocked...

So every time that I notice a "none..." was added to the blocked list I have to manualy remove it as soon as possible to allow people with "Client IP: none" to see the site...

Anyone knows how can I avoid "none..." to be inserted to the blocked list ?

Thanks,
Arlin
 
View user's profile Send private message
kguske
Site Admin


Joined: Jun 04, 2004
Posts: 6383

PostPosted: Thu Dec 21, 2006 8:23 pm Reply with quote

You could try adding it to the protected list, but that could be risky.

_________________
I google, therefore I exist...
Only registered users can see links on this board! Get registered or login!
 
View user's profile Send private message
arlinorlando
PostPosted: Thu Dec 21, 2006 10:41 pm Reply with quote

Well... I cant do that since the protect list field is a int and "none..." is a char...

Shouldn't sentinel always block the IP from Remote Address ?
I dont know why, but some times it block the IP "none..." and it's even not a number...
 
khaled_dxb
Regular
Regular


Joined: Jan 15, 2007
Posts: 66

PostPosted: Fri Jun 15, 2007 7:21 am Reply with quote

Did u ever manage to get an answer as to why nukesentinel is checking for the remote_ip instead of the remote_addr?

I am always getting none as a client IP and nukesentinel always blocks it.

what is the difference between the two - i noticed that always remote_addr is correct while remote_ip can be none.

in nukesentinel.php i have changed on line 142:

Code:
// Invalid ip check

if(isset($bypassNukeSentinelInvalidIPCheck) AND $bypassNukeSentinelInvalidIPCheck) {;}
elseif ($nsnst_const['remote_ip']=="none") { die(_AB_INVALIDIP); }


to

Code:
// Invalid ip check

if(isset($bypassNukeSentinelInvalidIPCheck) AND $bypassNukeSentinelInvalidIPCheck) {;}
elseif ($nsnst_const['remote_addr']=="none") { die(_AB_INVALIDIP); }


in order to get around the problem of being blocked every single time!

Thanks for your input.
 
View user's profile Send private message
evaders99
Former Moderator in Good Standing


Joined: Apr 30, 2004
Posts: 3221

PostPosted: Fri Jun 15, 2007 6:06 pm Reply with quote

$nsnst_const['remote_ip'] is a custom variable used by Sentinel. It is set using the function get_ip() and can represent one of several things if they are set

client_ip
forward_ip
remote_addr

_________________
- Only registered users can see links on this board! Get registered or login! -

Need help? Only registered users can see links on this board! Get registered or login! 
View user's profile Send private message Visit poster's website
khaled_dxb
PostPosted: Sat Jun 16, 2007 3:05 am Reply with quote

yes, i did work my way backwards to that function, however why is it that one constant returns "none" while the other (remote_addr) returns the valid ip address.

Have i compromised the security in any way by changing the code as i have done to get around the "none" problem?

Basically what i'd like to know is Where does this "none" come from? when you say "if they are set" - set where? does the user set them? does the browser?

I've seen quite a number of posts about this "none" issue, but none seem to get to the root of the problem?

Here's another one for you!

If i change the table name "nuke_nsnst_ip2country" to anything else "nuke_nsnst_ip2country_old" for example, then the "none" goes away!?? the valid ip address now shows up and the invalid ip check passes

in mainfile.php - i modified the online() function as follows for troubleshooting only.

Code:
function online() {

  global $nsnst_const, $user, $cookie, $prefix, $db;
  if(!file_exists('includes/nukesentinel.php')) {
    $ip = $_SERVER['REMOTE_ADDR'];
  } else {
    $ip = $nsnst_const['remote_ip'];
   echo "IP ADDRESS: " . $ip;  //TROUBLESHOOTING


so i can see what the function is returning each time and when i changed that table name it shows me correct IP, if i change the table name back - then it shows "none" again!

Thanks!
 
evaders99
PostPosted: Sat Jun 16, 2007 6:58 pm Reply with quote

My guess is that your IP2Country data has not been updated. You can download the most recent updates from Only registered users can see links on this board! Get registered or login!
 
khaled_dxb
PostPosted: Sun Jun 17, 2007 8:20 am Reply with quote

Thanks evaders99,

I did this step already, since it was recommended in many of the "none" posts i've read so far.

i dont believe that this is contributing to the problem, although it is linked somehow - why would the IP2C table have any effect on what IP address is retrieved by NukeSentinel? am i missing something?

The ip address using one method (remote_addr) works fine, whereas the other using the remote_ip function does not?

In any case, i guess it's some kind of bug - im no expert programmer, as as long as the little work around is working, i'lll keep it there.

Thanks for your help.
 
gregexp
The Mouse Is Extension Of Arm


Joined: Feb 21, 2006
Posts: 1497
Location: In front of a screen....HELP! lol

PostPosted: Sun Jun 17, 2007 9:19 am Reply with quote

Code:
if(isset($nsnst_const['client_ip']) && !stristr($nsnst_const['client_ip'], "none") && !stristr($nsnst_const['client_ip'], "unknown") AND !is_reserved($nsnst_const['client_ip'])) {

    return $nsnst_const['client_ip'];
  } elseif(isset($nsnst_const['forward_ip']) && !stristr($nsnst_const['forward_ip'], "none") && !stristr($nsnst_const['forward_ip'], "unknown") AND !is_reserved($nsnst_const['forward_ip'])) {
    return $nsnst_const['forward_ip'];
  } elseif(isset($nsnst_const['remote_addr']) && !stristr($nsnst_const['remote_addr'], "none") && !stristr($nsnst_const['remote_addr'], "unknown") AND !is_reserved($nsnst_const['remote_addr'])) {
    return $nsnst_const['remote_addr'];
  } else {
    return "none";
  }
//snippet from nukesentinel.php


Now you need to see what is failing, If you would like,

print_r($nsnst_const);

will output the array, Now you need to tell where it is failing, it will return none when all the variables fail to meet the criteria of the if statement, here are the criteria to NOT return none, it has to
1. Be set.
2. It cannot contain the word none in it
3. It cannot contain the word unknown
4. It cannot be reserved.

Now you need to figure out where it is failing, probably in the reserved list.
That is the most common and most likely, and updating your ip2c will update your reserved ip list, but may not fix the problem at hand if the ip remains in the reserved ip list. I hope that helps.

_________________
For those who stand shall NEVER fall and those who fall shall RISE once more!! 
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number
Display posts from previous:       
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> NukeSentinel™

View next topic
View previous topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2007 phpBB Group
All times are GMT - 6 Hours
 
Forums ©