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™ Enhancement Requests
Author Message
kguske
Site Admin


Joined: Jun 04, 2004
Posts: 6383

PostPosted: Mon Sep 06, 2004 7:34 am Reply with quote

Some of us (who unfortunately don't use Raven Web Hosting - yet) can't control php settings via php.ini (local or master). But necessity is the mother of invention, so...

Since the display errors setting is ON, I had no choice but to turn it off in Nuke to prevent full path disclosure. Occasionally, though, I'd like to have it on for testing. Thus, a new NukeSentinel™ configuration setting was born.

Image

While locked in the house (and without outside communications) during Hurricane Frances, I added a function and a little code in the /include/sentinel.php to accomplish this. It uses a get_cfg_var to display the Server setting, rather than ini_get to show the current setting.

Does this make sense?

Other than switching hosts, is there a better way to accomplish this?

Are there other PHP settings that could affect security and / or performance that might be useful to add to NukeSentinel™ to take advantage of the configuration capability and mainfile position?

If so, I would be happy to send the code...
 
View user's profile Send private message
Raven
Site Admin/Owner


Joined: Aug 27, 2002
Posts: 17077

PostPosted: Mon Sep 06, 2004 8:46 am Reply with quote

Do you have access to .htaccess? Most users do. That's where you can easily alter php.ini (local, not server).
 
View user's profile Send private message
kguske
PostPosted: Mon Sep 06, 2004 9:11 am Reply with quote

I have access, but using something like

php_flag display_errors Off

causes a server error.

Some users (few, I'm sure) might not run Nuke on Apache.
 
Raven
PostPosted: Mon Sep 06, 2004 9:23 am Reply with quote

Oh I understand. I was just wondering before I responded. One of the things that we are trying NOT to do with NukeSentinel is to bloat the heck out of it, which would/could be very easy to do (I think we will need to change our philosophy Laughing ). This first started out as an exploit catcher only, if you will. We have added much more (a good thing) and the 2.1 release will have a sophisticated IP tracker (among other things) based from Scott Rubin's (deceased) IPT. I knew Scott and since I helped him along the way with his IP Tracker, I know he wouldn't mind Wink Now, back to your original post, please send me your modifications and we will certainly look it over for inclusion. Thanks for wanting to make this a better product!
 
kguske
PostPosted: Mon Sep 06, 2004 10:55 am Reply with quote

A little research effort paid off. My current host doesn't allow php settings via htaccess. I tried changing settings in a local php.ini, but learned the hard way that a local php.ini replaces, rather than overrides, the master php.ini. So, if you don't set ALL settings in a local php.ini, the default settings (probably not what you want) are used.

I agree with the concern for bloat (bloat is a large part of what makes Nuke insecure!). I thought that since several PHP settings affect security, it would be useful to display them in NukeSentinel™. The flexible design of the nsnst_config table and the optimal placement of /include/sentinel.php minimize the impact of additional settings in the config table.

But, there IS an impact, and there ARE multiple other solutions (local/master php.ini, http.conf, .htaccess) - one of which should work regardless of host. Since the ability to change PHP settings is primarily a concern to developers, maybe a similar tool (or Nuke hack) can provide this functionality.

I'll send the code (the easy enhancement is a tribute to the great design!), but definitely won't mind if it's not included in future releases. In addition to contributing to the manual / user guide, I am happy to do whatever I can to make NukeSentinel™ better and would be MORE than happy to help integrate/develop/test/document IP Tracker functionality or any other enhancements to the GREAT tool you guys have created.
 
Raven
PostPosted: Mon Sep 06, 2004 11:26 am Reply with quote

I was wondering if you might like to write a personal and subjective evaluation/editorial of the tools you have objectively written a comparison of? This does, of course, assume that you have tried all the tools that you have documented. If you have just documented them based on THEIR documentation, then that will not really help. What I am after is someone who has tried them all, individually and not together at all, and would be willing to give an objective review. Now I am not contradicting myself with objective and subjective Wink What I mean is that it will be subjective in the sense of it will be YOUR opinion, but objective in the sense that you do not have any connections with this web site. Make sense?
 
kguske
PostPosted: Mon Sep 06, 2004 12:06 pm Reply with quote

Yes, it makes sense. I considered doing that when I wrote the original comparison. The plan was to create test sites with the tools installed and invite people to hack them - to see which could be hacked and which could not. I didn't have the time (or the web resources) to do it. I didn't install all the tools, but I did request confirmation of the information from all of the authors (all but 1 replied) of the original 5 tools (there are 7 in the current comparison). Most of the documentation was weak (or, in the case of one, in Russian only), so I did look at the code to identify and confirm some features.

However, the comparison did generate interest from several people. Chris Karakas will include the comparison in a future release of his excellent PHP-Nuke HOWTO guide. Stephen, the webmaster at Only registered users can see links on this board! Get registered or login! also republished the comparison and is testing various security scripts. You can find progress of his tests there. Pending the nature, timing and outcome of Stephen's tests and my availability, I might revisit my initial plan.

Two additional (definitely more subjective) points that I didn't include in the comparison: installation and support. These two factors can SIGNIFICANTLY impact the actual usage of a PHP-Nuke security tool.

Installation typically requires FTP, modifications to the code, and creation of datables or setting permissions on files. Most provide little assistance (a la the Sentinel nsnst.php) in doing this.

The most powerful security tool is useless without good support. New security flaws are discovered almost daily, so frequent updates are a MUST. Even with excellent documentation, there will be questions on how to use a security tool, so support must be quick and readily available.

In my opinion, those are 2 factors that make Sentinel (and those who support it) invaluable. That isn't to say that other tools are not valuable, don't have installation / upgrade functions, or don't have good support (Admin Secure and Protector are pretty active). But, as I answered the question of why I use Sentinel in the forums at Only registered users can see links on this board! Get registered or login! Sentinel has the best balance of protection, features, performance and support for my needs.
 
Display posts from previous:       
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> NukeSentinel™ Enhancement Requests

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 ©