Main Stories
Slash Boxes

Slash Open Source Project

Slashcode Log In

Log In

[ Create a new account ]

Article Poll

Poll I found this article to be
Very Helpful
Not Helpful
Not Very Helpful
[ Results | Polls ]
Comments:0 | Votes:0

Best Practices for Secure Remote Admin?

posted by Krow on 01:28 PM December 31st, 2002   Printer-friendly   Email story
What are best practices for securely administering a Slash site over the Web?

I'm trying to use SSL for the purpose, which would be ideal, but I'm meeting with only limited success. There appears to be a bug in the user login code that keeps flipping the browser back to the non-SSL index.

Is it just me, or am I barking up the wrong administrative tree?

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login
Loading... please wait.
  • SSL is exactly what you want to use for admin access. We should be adding this to the INSTALL or something before release; meanwhile here is a quick guide.

    First, make sure the var cookiesecure is set to 1, and allow_nonadmin_ssl is set how you want it (I recommend keeping it off, as a bunch of regular users could really swamp an SSL server's CPU).

    If you may be adminning the site over a network that you believe to be secure from sniffing, set the regex var admin_secure_ip_regex to something appropriate. These are the IP numbers that the code considers accesses from to be secure whether they arrive over SSL or not.

    For your first try, set to 0 the vars admin_check_clearpass and admin_clearpass_disable. We'll set them to 1 later.

    Enable SSL access to your site by compiling mod_ssl into your Apache. The way I included my SSL conf file was to append this to my httpd.conf, right after the Include that pulls in slash.conf:

    Include conf/httpd_ssl.conf

    That file is mainly created by mod_ssl as I recall, but in its VirtualHost section you'll have to make it look like a normal Slash VirtualHost. Note that there is only one SSL website allowed per IP number! Anyway, my test site's VirtualHost portion of httpd_ssl.conf looks like:

    ## SSL Virtual Host Context

    <VirtualHost _default_:443>

    #  General setup for the virtual host
    DocumentRoot "/usr/local/slash/site/daisy.jamienet/htdocs"
    Ser verName daisy.jamienet
    ErrorLog logs/daisy.jamienet-ssl_error_log
    TransferLog logs/daisy.jamienet-ssl_access_log

            PerlSetupEnv On
            PerlSetEnv TZ GMT

            SlashVirtualUser slash

            SlashCompileTemplates Off

            PerlAccessHandler  Slash::Apache::Banlist
            PerlAccessHandler  Slash::Apache::User
            PerlCleanupHandler Slash::Apache::Log
            PerlCleanupHandler Slash::Apache::Log::UserLog

            PerlTransHandler Slash::Apache::IndexHandler
            PerlTransHandler Slash::Apache::User::userdir_handler
            [...AddTypes, AddHandlers...]
                # My additions
                ServerAlias daisy.jamienet
                ServerPath /daisy.jamienet
                ErrorDocument 403 /
                ErrorDocument 404 /

    The last step, after restarting the server, is to go to . If you go straight to the homepage, you'll probably be bounced to the non-secure side (since you left allow_nonadmin_ssl turned off, and the site doesn't know you're an admin because you haven't logged in on the secure side!). / is the one URL that you can visit on the secure side without having logged in, for obvious reasons. Log in, and you should receive a secure-side cookie and be redirected to the secure-side homepage. Hooray.

    At that point, you'll want to go back to the nonsecure side and log out. Your browser should keep your secure-side cookie separate, so you will be anonymous to your site on the non-secure side, and an admin on the secure side.

    If you want to be sure your admins' passwords are not being sniffed, set the var admin_check_clearpass to 1. This will make sure that if their clients ever send their passwords in the clear, on the non-secure side, they see a warning message on every page, and you'll get a warning in your daily site email. Only after they log out on the non-secure side, and change their password securely, will the warnings go away.

    If you want to be really strict, set admin_clearpass_disable to 1. In the event that an admin's password is ever sent in the clear, this disables their admin powers, until their password is changed securely. Some admins may object to being exposed to kryptonite like this, so set it with caution, only after your admins have gotten used to the new regime :)

    • Are you speaking of the 2.2.6 release, or the latest CVS? My installed slash sources have no mention of the admin_check_clearpass or admin_clearpass_disable vars.

      Am I naked in the rain running the 2.2.6 tarball? And how safe is the upgrade path?