Slashcode

02/12/31/1821256 story

Best Practices for Secure Remote Admin?

posted by Krow on 02:28 PM December 31st, 2002      

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?

• SSL is good (Score:1)

  by jamiemccarthy (414)

  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
  ServerAdmin jamie@mccarthy.vg
  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 /404.pl
              ErrorDocument 404 /404.pl

  The last step, after restarting the server, is to go to https://yoursite.name/users.pl . 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!). /users.pl 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 :)

  • Re:SSL is good (Score:1)

    by EWillieL (4067)

    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?