Security on Shared Host ? ? ?

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • scottperkins
    Member
    • Sep 2000
    • 40

    Security on Shared Host ? ? ?

    VBulliten masters- I have picked up some advice on PHP
    shared hosts setup and I am a little unnerved about the
    difficulty of gaining a secure shared host. Does everyone
    agree with the following or are there some things being overlooked here? Can PHP installed as Module be secure for VBulliten in a shared virtual host ?

    Here are excerpts of what I've picked up elsewhere.


    questions to your prospective provider :

    1) Must have Telnet / SSH access.
    2) Do they allow to scheduling of nightly cron jobs? This makes backups a lot easier.

    3) Is it possible for other users or scripts created by other users (running as the webserver's user ID -- typically "nobody") to view files in your web space?

    4) If so, do they provide a way for you to run CGI scripts as your user ID so that your database passwords (which must be included in the Phorum configuration file) are not viewable by other users? This is typically done by installing PHP as a cgi script and either running it through Apache's SuEXEC module or calling it from a setuid wrapper.


    If questions 3 and 4 are not answered to your satisfaction, then you will have to take into account that it may be possible for other users on your server to hack your database just by trolling through your installation files. Since they allow cgi-bin access, then just running PHP in safe mode is not enough. If they run PHP in safe mode "AND" run all cgi scripts through SuExec, then we may be able to set permissions adequately to avoid this.

    Apparently it works well as a CGI. But MUCH slower because a process has to fork on every call.

    In monitoring the PHP maillist, to hear the guys talk the CGI was about 100 times slower to the point of madness. Maybe some hosting sites allocates machine resources to overcome inefficiency ? ?

    I think for pair.com it is probably the best policy, as they are not very sharp and for them it is probably the safest although I would love to see a module version there as well. The PHP code is served slower for the small percentage of users that are working with PHP, but less server resources are taken up by the additional bloat in each server process so it might work out ok if only a small
    percentage of users on the server is using PHP.

    One major drawback to the module version is that there is no way of making it run under your userid. To install Phorum and any other scripts that store your database password, you would have to install the CGI version anyways.

    As far as setting up the account, the only part where it pays to ask for some modifications over default settings is when requesting a domain name setup. The rest of it (the basic account and a MySQL database) is pretty straightforward. For the domain name, it is best of you ask for:

    1) Domain name mapped to subdirectory of public_html:
    ~/public_html/www.yourdomain.com

    2) Separate CGI-BIN for domain mapped to:
    ~/public_html/www.yourdomain.com/cgi-bin

    3) WWW logs separated by domain name.

    The MODULE implementation of PHP can be secure if the host is running PHP in SQL Safe Mode, then you don't have to specify your database passwords at all, so the module version is secure. The host could also make it secure by requiring all CGI scripts to run through SuEXEC as the owner of the file and enabling PHP Safe Mode (not SQL).
    Of course, this has major implications on the way Phorum needs to be set up, but it works.

    Even having PHP as a CGI build doesn't guarantee that you will be able to run Phorum securely. If the host is not running PHP through SuEXEC or hasn't created a wrapper so that PHP can be run as you userID, then you're out of luck as far as good security goes.

    It all boils down to whether or not you have a host that
    understands the security implications of requiring a password to access a database, and does something to accommodate it. Many hosts just write off the possibility that a user on the same server as you might be malicious enough to write a CGI script that trolls through user
    directories looking for open files, let alone that someone on the server might have a vested interest in disabling/modifying your site.

    Most users are totally confused by the notes in security.txt, and many just choose to take the minimal security precautions of renaming the admin dir, adding htaccess permissions, and moving the include files.

    This will generally deter casual hackers, but not one that is really going after your site.

    Most scripts that include password information don't even bother informing their users of the security risks in doing so.

    If server were dedicated then PHP module would be OK.

    If you're on a dedicated server that doesn't allow direct access (FTP/Telnet/SSH) to anyone but trusted users, then you can just place the sensitive files outside the web space and you'll be completely secure. You could even just place a directive in an .htaccess file that denies access to the config files, but this relies on proper
    configuration of the webserver.
widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
Working...