Share the Knowledge
RSS icon Home icon
  • How to automatically redirect the WordPress login and admin pages from HTTP to HTTPS

    Posted on November 16th, 2011 webmaster No comments         Print Print

    I always get worried every time I have to login to a website over a non-SSL enabled connection.  When my blog didn’t support SSL (before I migrated from a shared host to my own VPS) and I had to work on it at a coffee shop, I would sometimes change my password when I get home, which of course is still not that secure as my blog is hosted outside my local network which I have no control over.

    A computer with a network card (wired or wireless) that supports promiscuous mode can easily sniff out packets coming in and out of other devices on the same local network the computer belongs to using tools like Wireshark.  So if you’re using a public wireless access point, for example, other computers connected to that same wireless access point could see the data you’re sending and receiving over the network.

    Even if the login form hashes the password first (using one-way hashing algorithms such as MD5 or SHA-1), most users probably have passwords that aren’t that strong/complex, allowing the attacker to brute-force the hashed passwords in a reasonable amount of time.  Advancement in GPU technology and tools like IGHashGPU make cracking passwords much, much faster.

    There are also tools like Firesheep for Firefox which allows attackers to impersonate you by hijacking your session cookies since its content can be retrieved in plain text over an unencrypted connection.

    Automatically redirecting all WordPress pages that send out authentication-related information from HTTP to HTTPS could prevent these types of attacks.

    If you have full control over your WordPress installation, this is very easy to do.  Just edit the wp-config.php file in the root directory of your WordPress installation and add the highlighted line below before /* That’s all, stop editing! Happy blogging. */.

    define('WP_DEBUG', false);
    
    /**
    * Force SSL on login and admin pages.
    */
    define('FORCE_SSL_ADMIN', true);
    
    /* That's all, stop editing! Happy blogging. */
    
    /** Absolute path to the WordPress directory. */
    if ( !defined('ABSPATH') )
            define('ABSPATH', dirname(__FILE__) . '/');
    

    More information can be found here: http://codex.wordpress.org/Administration_Over_SSL

    If you don’t have full control over your WordPress installation (such as in a shared hosting environment), you can give this plugin a try: http://wordpress.org/extend/plugins/wordpress-https/

  • Apache warning message on Ubuntu 10.04: ‘__default__ VirtualHost overlap on port 443, the first has precedence’

    Posted on November 15th, 2011 webmaster 1 comment         Print Print

    Got this message when I restarted the apache2 daemon after I added a new virtual host in /etc/apache2/sites-available/default-ssl on Ubuntu 10.04:

    [warn] _default_ VirtualHost overlap on port 443, the first has precedence

    I checked the other Apache config files and inside /etc/apache2/ports.conf there’s a comment on what to do:

    Step 1. Add NameVirtualhost *:443 entry in ports.conf (inside <IfModule mod_ssl.c>)

    NameVirtualHost *:80
    Listen 80
    
    <IfModule mod_ssl.c>
        # If you add NameVirtualHost *:443 here, you will also have to change
        # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
        # to <VirtualHost *:443>
        # Server Name Indication for SSL named virtual hosts is currently not
        # supported by MSIE on Windows XP.
        NameVirtualHost *:443
        Listen 443
    </IfModule>
    

    Step 2. Change the VirtualHost statement in /etc/apache2/sites-available/default-ssl

    Replace <VirtualHost __default__:443> with <VirtualHost *:443> (as mentioned in the comment in ports.conf).

    Step 3. Restart Apache and check if SSL is working fine for all of your virtual hosts

  • Ubuntu 10.04: Apache using up all of your server’s memory? Consider using apache2-mpm-worker

    Posted on November 12th, 2011 webmaster 1 comment         Print Print

    I was checking my site yesterday morning and noticed it was responding very very slowly.  The server running it only has 256MB of RAM, which I estimated shouldn’t be a problem at all with the amount of traffic I’m currently getting.  I quickly logged in to the server to check the resource usage and found that the Apache daemon was using up pretty much all the RAM and virtual memory!

    After some researching, I discovered that the Apache Multi-Processing Module (MPM) that I’m using is the “prefork” one (apache2-mpm-prefork), which basically creates/forks a new process to handle each connection.  The “worker” (threaded) MPM (apache2-mpm-worker) is considered to be faster with a smaller memory footprint and I’ve seen posts in forums suggesting to switch to this one and see what happens.

    It looks like aptitude installed the “prefork” MPM by default because the PHP5 library I installed required it.  Switching to the “worker” MPM made a huge difference for me, I’m only using about half my RAM and very little virtual memory now.

    To use the “worker” MPM with PHP, do the following:

    Step 1. Stop the apache2 daemon

     sudo /etc/init.d/apache2 stop 

    Step 2.  Uninstall apache2-mpm-prefork

     sudo aptitude remove apache2-mpm-prefork 

    Step 3.  Install apache2-mpm-worker and apache2-threaded-dev

     sudo aptitude install apache2-mpm-worker apache2-threaded-dev 

    Step 4. Enable CGI and mod_actions (may already be enabled)

    
    sudo a2enmod cgid
    sudo a2enmod actions
    

    Step 5.  Create a file in /etc/apache2/conf.d with the following content (I called mine php5-cgi.conf):

    <IfModule mod_actions.c>
            Action application/x-httpd-php /cgi-bin/php5
    </IfModule>
    

    Step 6.  Start the apache2 daemon

     sudo /etc/init.d/apache2 start 

    Sources: