vb.org Archive

vb.org Archive (https://vborg.vbsupport.ru/index.php)
-   Forum and Server Management (https://vborg.vbsupport.ru/forumdisplay.php?f=232)
-   -   Admincp on a different machine? (https://vborg.vbsupport.ru/showthread.php?t=211589)

kjkoster 04-18-2009 06:05 PM

Admincp on a different machine?
 
Dear All,

I am planning to move my admincp pages to a different host. I have a separate machine for monitoring and other supporting tasks and this allows me to do some really draconian IP filtering on such tools. :)

What are the risks of doing this?

Can I just install a second instance of the site on the second machine and delete the admincp pages from the main box?

Kees Jan

Dismounted 04-19-2009 05:17 AM

What you can do is remove Admin CP files off the primary box, place a set of original vBulletin files onto the other box, and setup config.php to access the database of the primary installation. Do not run install.php! (But remove it.)

kjkoster 04-19-2009 05:46 AM

Dear Dismounted,

So there is no caching in vbulletin that may make this difficult?

Dismounted 04-19-2009 05:48 AM

What kind of caches are you talking about?

kjkoster 04-19-2009 05:54 AM

Dear Dismounted,

Well, that is my question: does vbulletin or Apache cache stuff that would make moving the admincp to a different machine harder?

Kees Jan

j883376 04-19-2009 06:55 AM

Quote:

Originally Posted by Dismounted (Post 1794283)
What you can do is remove Admin CP files off the primary box, place a set of original vBulletin files onto the other box, and setup config.php to access the database of the primary installation. Do not run install.php! (But remove it.)

I would also suggest making this set of files completely inaccessible to outsiders or else you run into licensing issues with Jelsoft. That would fall under "multiple sites without multiple licenses" if not password protected from others.

kjkoster 04-19-2009 07:28 AM

Dear j883376,

Yes, I am aware of the licensing issues that such a setup would bring. The whole point of this setup would be to have the admincp inaccessible to anyone but admininstrators.


Well, from what I gather there are no real technical limitations. You guys brought up some valid points (licensing, not running install from both locations) , so I think I'll go ahead and set this up.

Thanks for your input.

Kees Jan

PS. This also ties into my post about limiting database grants. Having the admin control panel on a separate machine allows me to instruct MySQL to not give ALTER/DROP/CREATE privileges to the admin machine. This makes SQL injection just that little bit less powerful on my site.

Paul M 04-19-2009 11:47 AM

Quote:

Originally Posted by kjkoster (Post 1794311)
[/URL]. Having the admin control panel on a separate machine allows me to instruct MySQL to not give ALTER/DROP/CREATE privileges to the admin machine. This makes SQL injection just that little bit less powerful on my site.

It will also stop you doing some administration duties, since they may require such privileges.

Dismounted 04-19-2009 11:48 AM

Quote:

Originally Posted by j883376 (Post 1794307)
That would fall under "multiple sites without multiple licenses" if not password protected from others.

Actually, AFAIK, it would not. Both sets of files are pointing to the same set of data, with no domain discrimination. That does not break the license agreement.

Paul M 04-19-2009 11:48 AM

Quote:

Originally Posted by kjkoster (Post 1794311)
Yes, I am aware of the licensing issues that such a setup would bring. The whole point of this setup would be to have the admincp inaccessible to anyone but admininstrators.

Simply password protecting the admincp folder will do that, no need for another server.

kjkoster 04-19-2009 02:07 PM

Dear Paul M,

I meant to say that the regular forum mysql user should not have CREATE/ALTER/DELETE privileges and the administrative site should. My bad. :)

As for the password protecting, that would not allow me to lock down the database user for vbulletin.

Plus (and you don't know this of course) I have a lot more running on that admin machine than just the vbulletin forum. That machine also runs the monitoring for instance. I hang out of the admin machine more than on for forum. :) For me it is more logical to have all that on one machine, while for most forums it is more logical to use the default setup of having admin tasks on the forum machine as well.

Kees Jan

Paul M 04-19-2009 03:59 PM

Im pretty sure you need DELETE for the forum to run properly, not sure about ALTER/CREATE.

Angel-Wings 04-20-2009 04:36 AM

Well - conclusion first - this is maybe useless. The problem is that the second (your Admin machine) would need the SQL rights you want to take away in order to do administrative tasks.
To write them in the DB of your first machine, you either have to setup a replica - the replica user would then have the rights you want to take away or some kind of tunnel - then again the problem remains the same.
At least INSERT / SELECT is required to run Vbulletin and that's already enough to dump the passwords or add another admin to your forum - if there's an injection possible.
I just want to say that all this might not give the security enhancements you're looking for because at least one DB user needs to rights at your VB database.
Maybe, rename the AdminCP folder, add a Password Protection and if you want to lookdown IP's do it directly in the Webserver configuration.
Or move your AdminCP - at the same server - inside a SSL environment setting up a redirection, Client Cert Authentication is the key.

Like said, DB access is still required with the rights you care about, doesn't matter where your AdminCP is placed. IP's can be spoofed as well so the time is maybe better spent configuring your primary machine that injections are already as hard as possible. Moving something insecure away doesn't make it more secure anyways if there's a problem because even at the other machine, the security problems, if any, will stay.

kjkoster 04-20-2009 05:15 AM

Dear Angel-Wings,

Hmm. Excellent points. Certainly food for thought. This is beginning to sound like less and less of a good idea. Thanks for you advise.

Kees Jan


All times are GMT. The time now is 05:20 PM.

Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.

X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.01132 seconds
  • Memory Usage 1,746KB
  • Queries Executed 10 (?)
More Information
Template Usage:
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (4)bbcode_quote_printable
  • (1)footer
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (6)option
  • (1)post_thanks_navbar_search
  • (1)printthread
  • (14)printthreadbit
  • (1)spacer_close
  • (1)spacer_open 

Phrase Groups Available:
  • global
  • postbit
  • showthread
Included Files:
  • ./printthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/class_bbcode_alt.php
  • ./includes/class_bbcode.php
  • ./includes/functions_bigthree.php 

Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • printthread_start
  • bbcode_fetch_tags
  • bbcode_create
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • printthread_post
  • printthread_complete