By default, freshly installed CentOS 5.X has the following Yum repositories enabled:

addons                                             CentOS-5 - Addons
base                                               CentOS-5 - Base
extras                                             CentOS-5 - Extras
updates                                            CentOS-5 - Updates

These are all defined in /etc/yum.repos.d/CentOS-Base.repo configuration file. Repositories enabled by default provide you with the core CentOS packages and updates for them. So you must have them enabled if you want your updates to work correctly. It is also important that these repositories take precedence over other repositories that you are going to use.

I will show later how to use Yum priorities package, just note that these are going to be priority one repositories

Enable standard CentOS repositories

There are two useful repositories defined in the configuration, but not enabled:

• CentOS Plus. Packages in this repository contains upgraded versions of the software. If you enable this repository, after applying updates/upgrades your system will no longer be of the original version you have installed. Fear not though, all packages are tested by CentOS team and will no cause any issues. So unless you have really good reason to keep you installation at the same version level I’d recommend enabling this repository.
• Contrib. Packages supplied and maintained by CentOS users. These packages are not inspected by CentOS team, but they are not attempt to replace/modify core CentOS package set, so normally this repository should not cause any issues. Beware that some packages are not following mainstream CentOS very closely. I normally don’t have this enabled.

These two repositories are going to get priority two setting. If you wish to enable them, edit default /etc/yum.repos.d/CentOS-Base.repo Yum repository configuration file and remove (or rather comment out) “enabled=0” line.

Install and enable EPEL repository

I must mention, that in this article I’m mostly talking about CentOS installation that is used for server environment. Therefore I’m not really interested in repositories that provide packages such as DVD or other multimedia decoders and players.

One of the most useful repositories for your server environment is EPEL repository – Extra Packages for Enterprise Linux. This repository is maintained by Fedora project, and every effort is made to keep this repository as least  intrusive as possible, so in theory enabling and using this repository should not break or otherwise cause issues to your CentOS installation.

First of all, you need to install EPEL repository configuration files:

[root@centos54 ~]# rpm -ihv http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
Retrieving http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
warning: /var/tmp/rpm-xfer.RT5AzP: Header V3 DSA signature: NOKEY, key ID 217521f6
Preparing...                ########################################### [100%]
   1:epel-release           ########################################### [100%]
[root@centos54 ~]#

This provides you with two configuration files: base and testing. Don’t worry about testing one and leave it disabled.

Main configuration comes with three sections:

• Base packages. This is enabled by default.
• Debug packages. Disabled, and no need to enable unless you want to use debug packages.
• Source packages. Disabled. Enable only if you want to be able to install source RPMs from EPEL. Useful if you want to rebuild them to your specific needs. I’d recommend to leave it disabled and enable on yum command line only when you really need to install source RPMs.

These should be getting priority 3 setting.

Set priorities for Yum repositories

So if you enabled repositories from the previous section and installed EPEL repository configuration, here’s what you should see in you repositories list:

addons                             CentOS-5 - Addons
base                               CentOS-5 - Base
centosplus                         CentOS-5 - Plus
epel                               Extra Packages for Enterprise Linux 5 - i386
extras                             CentOS-5 - Extras
updates                            CentOS-5 - Updates

Now I need to set priorities for each repository. Install Yum priorities package:

# yum install yum-priorities

Make sure new plugin is enabled:

[root@centos54 ~]# cat /etc/yum/pluginconf.d/priorities.conf
[main]
enabled = 1
[root@centos54 ~]#

Now you can set priorities for each repository. It’s done by adding “priority=X” for each repository section in repository configuration files. Here’s what I ended up with:

[base]
...
priority=1
 
[updates]
...
priority=1
 
[addons]
...
priority=1
 
[extras]
...
priority=1
 
[centosplus]
...
priority=2
 
[contrib]
...
priority=2
 
[epel]
...
priority=3

Now you should be good to do upgrades and install packages as you see fit for your system.

Related posts:

1. Building python 2.6.4 RPM for CentOS 5.4
2. Building and running Google Chrome OS on VirtualBox
3. Use SSH to upgrade WordPress plugins automatically

• Insecure. Who knows who’s built the image and if they aren’t sending your Google login data to themselves when you login
• You’re stuck with that particular release. As I said, it’s in development, so new features and bug fixes get introduced on a daily basis

So I’ll show you how to (relatively) quickly build your very own Google Chrome OS. This instruction tells how to build Chromium OS with pre-built Chromium web browser. You will also need Sun VirtualBox.

In a nutshell:

• Install Ubuntu as a VirtualBox VM
• Download ChromeOS sources
• Build ChromeOS
• Create VMWare image
• Boot it in VirtualBox
• Enjoy

For the latest build release numbers check Chromium OS build page.

Preparation

Install Ubuntu

Do the standard installation, as you would normally do. I selected all defaults, and allocated 20GB single partition for the installation and assigned 512MB RAM.

Get OS source

Download/unpack http://build.chromium.org/buildbot/archives/chromiumos-0.4.22.8.tar.gz to /home/user/chromiumos/

NOTE! It seems that Google have removed OS tarballs and you now have to use these instructions to get the source code.

Install some additional packages required to build ChromiumOS

$ sudo apt-get install subversion pkg-config python perl g++ g++-multilib \
bison flex gperf libnss3-dev libgtk2.0-dev libnspr4-0d libasound2-dev \
libnspr4-dev msttcorefonts libgconf2-dev libcairo2-dev libdbus-1-dev
$ sudo apt-get install wdiff lighttpd php5-cgi sun-java6-fonts

OS build

Building local repository

cd ~/chromiumos/src/scripts
./make_local_repo.sh

Watch the output carefully and make sure it hasn’t failed with some errors!

Google says if the script fails, remove repo directory and call the script again. It hasn’t failed for me, so if you’ve done everything as per above you should be fine. I don’t really understand why calling the same script might make any difference…

This step is quite lengthy, so you might want to make yourself some coffee or tea. Or just take a short walk if the weather is good.

Create build environment

Another totally automated step. Just run

./make_chroot.sh

Which creates chroot’ed build environment for you. This uses all packages you downloaded in the previous step. There are adoption how to pull required packages from the remote repositories (Google and official Ubuntu), but I advise to take an easy way and download all packages first and build locally.

Get Chromium binary

make the following directory:

mkdir -p ~/chromiumos/src/build/x86/local_assets

And download chromium package from Google:

wget -O ~/chromiumos/src/build/x86/local_assets/chrome-chromeos.zip \
http://build.chromium.org/buildbot/archives/chromium-chromiumos-r32516.zip

Building OS

First you need to enter you chroot’ed build environment. Use the following command:

./enter_chroot.sh

I also recommend generating password for shared user, so that you can sudo from the terminal:

./set_shared_user_password.sh

And finally build all packages:

./build_all.sh

At this point, go and make some more tea or coffee. Which I wouldn’t recommend, though. Simply because you will have trouble getting asleep. Because sleeping is the most sane thing you might want to do at this moment. Building OS packages takes ages!…

But seriously, it’s not that bad, it took about an hour and a half on my Ubuntu VM to build it.

Make VM image and boot it in VirtualBox

Build bootable image

Once all packages have been built, you need to create OS image to boot from. Image build process creates two artefacts:
- Master boot record (mbr.image)
- Root FileSystem (rootfs.image)

./build_image.sh

Once the image files have been creates, the script will tell you where to find them. It is going to be in ~/chromiumos/src/build/images//

Here’s what you will have once the image build is done:

pulegium@ubuntu:~/chromiumos/src/build/images/999.999.33509.212332-a1$ ls -lh
total 729M
-rw-r--r--  1 pulegium 5000  512 2009-12-01 21:34 mbr.image
-rw-r--r--  1 root     root  40K 2009-12-01 21:31 package_list_installed.txt
-rw-r--r--  1 root     root  40K 2009-12-01 21:34 package_list_pruned.txt
drwxr-xr-x 22 root     root 4.0K 2009-12-01 21:29 rootfs
-rw-r--r--  1 pulegium 5000 950M 2009-12-01 21:23 rootfs.image

Tell VirtualBox to use existing image

Add new image

Image added

Selection of preinstalled application. All web based and ready to go. Make sure you have connection to the internet. Chrome OS bit dull and TBH useless without internet...

In general I think Chrome OS looks OK'ish, but this menu smells of M$ Windows...

Related posts:

1. Sorting out YUM repositories on CentOS 5.4
2. Building python 2.6.4 RPM for CentOS 5.4
3. The most unusual photocameras

Hide your identity

Well, first of all you need to hide details about who you are, or rather what your webserver is. It is a good practice to always run on the latest security patch, but not always feasible. So if you can’t upgrade in time, at least make attackers life harder by hiding details about your server:

#
# ServerTokens
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
# Set to one of:  Full | OS | Minor | Minimal | Major | Prod
# where Full conveys the most information, and Prod the least.
#
ServerTokens Prod

#
# Optionally add a line containing the server version and virtual host
# name to server-generated pages (internal error documents, FTP directory
# listings, mod_status and mod_info output etc., but not CGI generated
# documents or custom error documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of:  On | Off | EMail
#
ServerSignature Off

Allow only basic HTTP methods

HTTP protocol defines GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE and CONNECT methods. Guess how many of those are actually used (intensively). Yup, only two. Most of the webservers would do just fine with only GET and POST methods. You might however find that you need more, so enable them as you see fit. In the example below I only allow two basic, commonly used methods:

<Location />
   <LimitExcept GET POST>
     Order allow,deny
     Deny from all
   </LimitExcept>
 </Location>

Disable old and insecure SSL

Use only new protocols and only strong ciphers.

SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

Disable modules that you don’t need

Again, this depends on your installation and what you’re actually using, but in most of the cases most of the modules that Apache loads by default are not needed. Search for LoadModule instruction and remove anything you don’t need. Good list to start:

• mod_imap
• mod_include
• mod_info
• mod_userdir
• mod_status
• mod_cgi
• mod_autoindex
• mod_dav

Other settings

Reduce timeout, which is 300 seconds by default. Meaning that the server waits for 5 minutes before it decides that the client is no longer there. Reduce it to something sensible, like 20-30 seconds to avoid potential DDoS attacks.

Timeout 20

Disable directory browsing for any directory that has no index file:

Options -Indexes

Related posts:

1. Securing WordPress
2. Using OpenID for authentication in Django
3. Use SSH to upgrade WordPress plugins automatically

Related posts:

1. Military precision – Chinese way
2. Funniest pictures of animals
3. Goddesses of Karol Bak

Build and install SSH2 libraries

Depending on your linux distribution you might need to use different method. On my Debian, I had to use the following to install:

#  wget http://downloads.sourceforge.net/project/libssh2/libssh2-1.2.1.tar.gz?use_mirror=kent
#  tar zxf libssh2-1.2.1.tar.gz
#  cd libssh2-1.2.1
#  ./configure
#  make
#  make install

What’s important here is that I had to build libssh2 from sources manually. However I hate doing this, it was apparently the only way. Aptitude was only offering me an older (0.12) version of the library, which failed to build PHP ssh2 extension.

Build and install PHP SSH2 extension

Now again, for some reason simple command failed to work for me… So I had to specify beta channel to install PHP SSH2 extension. Fear not though, just try this

#  pecl install ssh2

And if it doesn’t work, then do this

#  pecl install channel://pecl.php.net/ssh2-0.11.0

Simple, isn’t it?

Generate SSH public and private keys

You need to generate both public and private keys that are going to be used to connect to your server (even if it is the same server your connecting from!). Go to your home directory:

$ cd .ssh
$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
fe:3b:5d:94:53:1e:d3:9f:87:45:73:ab:8d:9f:d7:cc user@server
$ cp id_rsa.pub authorized_keys

Private key is used to decrypt the data, whereas public key is used by the remote host to encrypt the data. You also need to create authorized_keys file, so that server knows your key is trusted and allows you to login without using actual user account password.

There is one annoying bit though. Apache user needs to be able to read both private and public keys. Normally they are kept secure in user’s .ssh/ directory, which is readable by user only, and allowing all to see it, is not a particularly good idea. So I had to copy both files to /etc/wordpress/ and make them readable to www-data group:

#  cd /etc
#  mkdir wordpress
#  cp /home/user/.ssh/id_rsa* wordpress/
#  chgrp www-data wordpress/*
#  chmod 640 wordpress/*

Configure WordPress to use public keys automatically

Add the following lines to your wp-config.php file, so you’re not asked any passwords or server names during the upgrade:

define('FTP_PUBKEY','/etc/wordpress/id_rsa.pub');
define('FTP_PRIKEY','/etc/wordpress/id_rsa');
define('FTP_USER','user');
define('FTP_PASS','');
define('FTP_HOST','localhost:22');

Related posts:

1. Securing WordPress
2. Building python 2.6.4 RPM for CentOS 5.4
3. Building and running Google Chrome OS on VirtualBox

Software development is really complex process and although  WordPress developers take security very seriously, you should also take extra measures to ensure safety and security of your blog/web site.

There are few simple steps to make your WordPress installation lot harder for attacker to compromise.

WordPress software

Always keep up to date. Flaws in security model are being identified and addressed immediately as soon as they are reported. So it’s important for you to always keep your WordPress installation up to date. It’s very easy to do now that WordPress has automatic update feature, where all you have to do is just to tell it to install the newer version of it.

File permissions

You need to make sure that webserver can modify only those files that it is allowed to. Do not rely on WordPress to enforce this, use file system permission model. All files in WordPress installation need to be owned and writeable to by the user that installed the system and not the user which is used to run webserver. Only exceprion to this is /wp-content/ directory, which contains uploaded contents.

Make sure you perform all actions in whatever your WordPress installation directory is, and not outside of it!

Let’s make all files owned by your user and set the group to web server group:

$ sudo chown -R myuser.www-data *

Then change all file permissions so that files can be written to by your user only, and read-only by other users:

$ find . -type d -exec chmod 755 {} \;
$ find . -type f -exec chmod 644 {} \;

Finally allow group write for wp-content/ directory, so that web server can do automatic updates for plugins and user content could be uploaded:

$ chmod -R g+w *

Secure wp-admin access

WordPress recommend using additional plugins and HTTP authentication to provide additional security to the administration pages, but I think this is not necessary if you implement the following two security measures: enforce SSL only traffic to /wp-admin/ and allow access only from certain IP addresses.

Make /wp-admin/ available on SSL connection only, so all traffic to and from (including passwords) is encrypted. This prevent attackers hijacking traffic and intercepting passwords and other sensitive data.

This may sound bit complicated, but bear with me, it’s not that scary as it may look like. So you will need two <VirtualServer> directives: one for normal web traffic and one for SSL.

In default HTTP definition, you then need to make a special case for /wp-admin/ URL, and enforce redirection to HTTPS, so whenever you try to access wp-admin/ using http:// you will be redirected to https:// instead. HTTPS VirtualHost on it turn has instructions to deny access from all, but only the IPs listed in the configuration:

<VirtualHost server_ip:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/virtual/www.example.com
    ErrorLog /var/log/apache2/www.example.com-error.log
    CustomLog /var/log/apache2/www.example.com-access.log combined
    <Location /wp-admin/>
        RewriteEngine on
        RewriteRule ^(.*)$ https://%{SERVER_NAME}/wp-admin/ [R=permanent,L]
    </Location>
</VirtualHost> 

<VirtualHost server_ip:443>
    ServerName example.com
    ServerAlias www.example.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.com.pem
    SSLCertificateKeyFile /etc/ssl/private/example.com.key
    DocumentRoot /var/www/virtual/www.example.com
    ErrorLog /var/log/apache2/www.example.com-error.log
    CustomLog /var/log/apache2/www.example.com-access.log combined
    <Location /wp-admin>
        Order deny,allow
        Deny from all
        Allow from trusted_ip_1
        Allow from trusted_ip_2
    </Location>
</VirtualHost>

Other security measures

Install WP Security scan plugin which will provide a good overview of how your installation looks like from the security point of view.

Also remove advertising of the WordPress version that you are using. Add the following line to functions.php file, which you are using:

remove_action('wp_head', 'wp_generator');

And did I mention that you need to make regular backups?…

Related posts:

1. Use SSH to upgrade WordPress plugins automatically
2. Basic Apache security
3. Essential WordPress plugins