User Agent Access Denied

Posted: Sat Apr 14, 2007 10:26 am

Some of my users are still getting user-agent access denied problems.

They are all using IE. And yes, I've suggested deleting history, cookies, etc.

I have set
$bypassNukeSentinelInvalidIPCheck = TRUE;

So, I don't get why this check is still being performed? Am I missing something?

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

User-agent and invalid ip are not the same check. Please post the complete user agent that is getting blocked.

Posted: Sun Apr 15, 2007 6:10 pm

ahhhhhhhhhhh ... well, there goes my theory that I knew what I was doing. Wink

Could you please explain what's going on with this UserAgent check? Are they getting blocked because the UserAgent is None? And what would make it None, an older version of IE?

btw, this issue is a problem with IE ... and users have told me they have deleted their cookies/history/etc. Seems the only thing that clears it up for them is to use firefox.

You have attempted to access this site with an invalid User Agent.

If you think this is a mistake you can contact the site webmaster at admin(at)xxx(dot)ca.

Be SURE to include the following information in any email!
User Agent: none
Remote Address: 24.xx.xxx.xxx
Client IP: none
Forwarded For: 24.xx.xxx.xxx

registered · Posted: Mon Apr 16, 2007 6:22 am

Yes, CodyG, that is why they are being "blocked". Sounds to me like they have some form of anonymizer on their PC or a browser plugin or they are coming through an on-line version of this.

Unfortunately, they cannot access a PHP-Nuke site with NS in this manner, unless you want to make a code hack.

Of course, if I am wrong, Raven will (should) correct me. LOL.

Posted: Mon Apr 16, 2007 9:18 am

In includes/nukesentinel.php you will find this code

Code:




// DOS Attack Blocker


if($ab_config['prevent_dos'] == 1 AND !stristr($_SERVER['PHP_SELF'], "backend.php") AND !stristr($nuke_config['nukeurl'], $_SERVER['SERVER_NAME'])) {


  if(empty($nsnst_const['user_agent']) || $nsnst_const['user_agent'] == "-" || !isset($nsnst_const['user_agent'])) { die(_AB_GETOUT); }


}

Without detailing it all, some of the checks are for User_Agent being equal to (none, -, EMPTY). If your issue is with the EMPTY User_Agent, it would be a simple change to just turn the prevent_dos off. You could also just comment out

Code:

  if(empty($nsnst_const['user_agent']) || $nsnst_const['user_agent'] == "-" || !isset($nsnst_const['user_agent'])) { die(_AB_GETOUT); }

at your own risk, of course Wink

registered · Posted: Wed Apr 18, 2007 11:18 am

CodyG wrote:

ahhhhhhhhhhh ... well, there goes my theory that I knew what I was doing. Wink

Could you please explain what's going on with this UserAgent check? Are they getting blocked because the UserAgent is None? And what would make it None, an older version of IE?

btw, this issue is a problem with IE ... and users have told me they have deleted their cookies/history/etc. Seems the only thing that clears it up for them is to use firefox.

You have attempted to access this site with an invalid User Agent.

If you think this is a mistake you can contact the site webmaster at admin(at)xxx(dot)ca.

Be SURE to include the following information in any email!
User Agent: none
Remote Address: 24.xx.xxx.xxx
Client IP: none
Forwarded For: 24.xx.xxx.xxx

Yes, it will block a user agent of "None". Old versions of Internet Exploder still send a user agent string however some firewalls and all anonymizer software block this string therefore it is reported as "None".

The reason for blocking a "None" user agent is because DOS attacks use an empty user agent string as well as many other attack methods.

Does this help?

Posted: Wed Apr 18, 2007 11:25 am

While I'm able to think of and remember it, turning dos protection off does not complete shut off the "None" check. Look in your includes/nukesentinel.php file around line 126 and you will find:

Code:

// Invalid user agent


if($nsnst_const['user_agent']=="none" AND !stristr($_SERVER['PHP_SELF'], "backend.php") AND ($nsnst_const['remote_ip'] != $nsnst_const['server_ip'])) {


  echo abget_template("abuse_invalid2.tpl");


  die();


}

In order to completely shut off the "None" user agent checking you have to comment this out like so:

Code:

// Invalid user agent


//f($nsnst_const['user_agent']=="none" AND !stristr($_SERVER['PHP_SELF'], "backend.php") AND ($nsnst_const['remote_ip'] != $nsnst_const['server_ip'])) {


//  echo abget_template("abuse_invalid2.tpl");


//  die();


//}

I've been on way to many pain meds lately Sad

Posted: Thu Apr 19, 2007 5:13 am

Hope you dont mind, but I've made this a Sticky. Excellent info!

Posted: Thu Apr 19, 2007 10:01 am

Posted: Mon May 07, 2007 9:21 am

Interesting and totally helpful, thank you.

with a little bit of clarity, always another question ...

why is the 'none' user-agent not an issue with firefox and dos attacks?

how does an IE user at home, or anywhere, ensure their browser is sending a valid user-agent? iow, as sysadmin, how would you respond to a user email who is being blocked by their 'none' user-agent?

thanks again

sentinel rocks!

Posted: Mon May 07, 2007 11:07 am

IE when setup and not altered sends a userabent string similar to:

Code:

Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; NetCaptor 6.5.0RC1)

Let's break it down:
Mozilla/4.0 = A browser
compatible =
MSIE 5.01; = Internet Explorer 5.01
Windows NT 5.0; = Windows XP
NetCaptor 6.5.0RC1 = A browser plugin

Now IF, and this is the key, they are running anonymizer software or if their virus protection has a firewall they won't be passing that string. When you reply to their email start by asking if their firewall blocks the user agent string or if they are using anonymizing software.

Also ask them to copy the info on the NukeSentinel(tm) page they see and email it to you. You can then start checking to see if there is anything in the string that would cause NS to nullify it.

If you want to get real deep into it you can compare their agent string to:
http://www.user-agents.org/index.shtml

This list shows tons of proxies, crawles, browsers, and rippers. I refer to this often when I'm checking refers on my site Smile

Lastly, if they are passing what appears to be a valid string go thru your "Havester" list to see if you have a string in it that would cause NS to trip.

Posted: Mon May 07, 2007 12:52 pm

wow ... i'm totally impressed and much more enlightened and will dig further and not disable anything in the core files. Wink

I'm still a little confused how user firewalls work with nuke. With other login issues, I have often suggested users make the domain a safe place in browser and firewalls. Does this not have any effect?

Posted: Mon May 07, 2007 7:45 pm

Quote:

how user firewalls work with nuke

CodyG, it really boils down to is there software running on their PC, such as some firewall or anonymizer type tools which help hide your identity, they get in-between your browser before the request is actually sent out from your PC and alters the HTTP header information.

With regards to this:

Quote:

have often suggested users make the domain a safe place in browser and firewalls. Does this not have any effect?

That is an interesting thought. I have not tried it. Good question. Wink

But, if there is some form of anonymizer in place, it might not make any difference unless there is a way within that tool to be selective as to which domains to share the more informative HTTP headers with.

Posted: Mon May 07, 2007 9:18 pm

If the firewall hides the useragent or the anonynizer hides it then "Making A Site Safe" won't change the setting to not block the useragent string. As montego pointed out some of these firewalls and anonymizers are much more advanced then they use to be and may very well allow a "Safe Site" to get more info then a Unsafe one. Still I believe there would be a setting for safe sites within the program as to what info would be shared (not proven).

registered · Posted: Tue May 08, 2007 5:51 am

Bob,

What's the chances of making this an on/off switch within the Admin interface in the next version or so? This issue may get more common as more and more users become concerned with Security and Online Privacy.

Cody,

If you have your users type this into their address bar, it should show them the exact UA they are broadcasting:

Code:

javascript:document.writeln(navigator.userAgent)

Posted: Tue May 08, 2007 7:14 am

Thanks, manukind!

And Bob, thank you. This whole thing is much more clear.

Posted: Tue May 08, 2007 8:00 pm

I will discuss it with the NS/RVN team and see what would be the best way to make it possible to turn it off.

Posted: Wed May 09, 2007 6:08 am

For those of you who develope and test, This tool Might be usefull.
http://www.wannabrowser.com/

Might help to test your site with a different browser extension, IMO its designed a lot like a proxy to test sites abilities.

Have fun with it, might be usefull in this thread, I am currently looking into some things that might help on this particular issue.