pig-monkey.com - slicehost

Back to Dreamhost

2009-05-22T00:00:00-07:00

I’ve moved this domain back to Dreamhost. It’s been a good run with Slicehost. I still think that they are the superior host (I’ve already noticed a slowness with Dreamhost compared to Slicehost) and I greatly prefer the freedom and control of a VPS over shared hosting, but Dreamhost is cheaper and I need to cut down expenses. In the future I may move back to Slicehost again.

If anybody finds anything broken due to the move, let me know.

Thoughts on SSH Security

2008-10-03T00:00:00-07:00

OpenSSH has a history of security. Only rarely are holes found in the actual program. It’s much more likely that a system will be compromised through poor configuration of the SSH daemon. Ideally, an SSH config would allow only protocol 2 connections, allow only specified users to connect (and certainly not root), disable X11 forwarding, disable password authentication (forcing ssh keys instead), and allowing connections only from specified IPs. These config options would look like this:

Protocol 2
PermitRootLogin no
AllowUsers demo
X11Forwarding no
PasswordAuthentication no

Allowing connections from only specified IP addresses would be accomplished by adding something like the following to /etc/hosts.deny:

sshd: ALL # Deny all by default
sshd: 192.168.1.0/255.255.255.0 # Allow this subnet
sshd: 4.2.2.1 # Allow this IP

(You could also accomplish this with iptables, but I think editing the above file is simpler.)

But the last two options – disabling password auth and allowing only certain IP addresses – limits mobility. I constantly login to my slice from multiple IPs, and I also need to login during travel when I may or may not have my key on me.

The main thing these two options protect against is a brute force attack. By allowing password logins from any IP, we give the attacker the ability to exploit the weakest part of SSH. This is where DenyHosts comes in.

DenyHosts is a python script which attempts to recognize and block brute force attacks. It has many attractive features and is included in the default Ubuntu repositories.

1	`$ sudo aptitude install denyhosts`

The config file is located at /etc/denyhosts.conf. It is very simply and readable. I recommend reading through it, but most of the default options are acceptable. If any changes are made, the daemon must be restarted:

1	`$ sudo /etc/init.d/denyhosts restart`

Default Ports

Many people also advocating changing SSH’s default port to something other than 22 (more specifically, something over 1024, which won’t be scanned by default by nmap). The argument in support of this is that many automated attack scripts look for SSH only on port 22. By changing the port, you save yourself the headache of dealing with script kiddies. Opponents to changing the port would argue that the annoyance of having to specify the port number whenever using ssh or scp outweighs the minute security benefits. It’s a heated argument. I lean toward leaving SSH on the default port.

An Ubuntu VPS on Slicehost: Basic Setup

2008-06-10T00:00:00-07:00

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part One of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part Two, Part Three, and Part Four.

Slicehost has an excellent article repository, containing guides on a number of subjects. After building a fresh Slice, you should first follow Part 1 and Part 2 of Slicehost’s basic setup articles.

I use slightly different coloring in my bash prompt, so, rather than what Slicehost suggests in their article, I add the following to ~/.bashrc:

export PS1='\[\033[0;32m\]\u@\[\033[0;35m\]\h\[\033[0;33m\] \w\[\033[00m\]: '

This is a good time to protect SSH by installing DenyHosts, which I discuss here:

1	`$ sudo aptitude install denyhosts`

Ubuntu’s default text editor is nano, which I abhor. Real men use vim. Ubuntu comes with a slimmed down version of vim, but you’ll probably want the full version:

1	`$ sudo aptitude install vim`

To change the global default editor variable, execute the following and select the editor of your choice:

1	`$ sudo update-alternatives --config editor`

This is also a perfect time to install GNU Screen.

1	`$ sudo aptitude install screen`

If you’re not familiar with Screen, Red Hat Magazine has a nice little introduction

My .screenrc looks like this:

# Print a pretty line at the bottom of the screen
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{=kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{Y}%Y-%m-%d %{W}%c %{g}]'

# Nobody likes startup messages
startup_message off

# Turn visual bell on and set the message to display for only a fraction of a second
vbell on
vbellwait .3

# Set default shell title to blank
shelltitle ''

# Gimme my scrollback!
defscrollback 5000

# Change command character to backtick
escape ``

# Stop programs (like vim) from leaving their contents
# in the window after they exit
altscreen on

# Default screens
screen -t shell 0

I prefer to have my bash profile setup to connect me to Screen as soon as I login. If there are no running sessions, it will create one. If there is a current session, it will disconnect the session from wherever it is connected and connect it to my login. When I disconnect from screen, it automatically logs me out. To achieve this, I add the following to ~/.bashrc:

# If possible, reattach to an existing session and detach that session
# elsewhere. If not possible, create a new session.
if [ -z "$STY" ]; then
    exec screen -dR
fi

I would also recommend following Slicehost’s guide to installing chkrootkit and rkhunter.

One more thing: let’s set the timezone of the server to whatever is local to you (Slicehost’s Ubuntu image defaults to UTC). To do that, run:

1	`$ sudo dpkg-reconfigure tzdata`

Next up: install a web server.

An Ubuntu VPS on Slicehost: Mail

2008-06-10T00:00:00-07:00

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Three of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Two, and Part Four.

Last week I moved this domain’s email to Google Apps. Slicehost has a guide to creating MX records for Google Apps. I have a couple other domains with Google Apps, along with a couple domains hosted locally with addresses that simply forward to my primary, Google hosted, email. I also need to send mail from the server. To accomplish all of this, I use Postfix.

Installing Postfix is a simple matter. Telnet is used quite a bit for testing, so I install that too:

1	`$ sudo aptitude install postfix telnet mailutils`

The Postfix setup will ask how it should be installed – we want the “Internet Site” option – and then ask you for your fully qualified domain name.

Done? Let’s make sure Postfix is running:

1	`$ telnet localhost 25`

If it’s working Postfix should return:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 localhost ESMTP Postfix (Ubuntu)

Let’s send a test message from root to the user account user (replace that with whatever your standard user is):

ehlo localhost
mail from: root@localhost
rcpt to: user@localhost
data
Subject: Test
Hi, is this thing on?
.
quit

Now, check your email as user by running mail. See the message? Good.

Open /etc/postfix/main.cf to make sure that Postfix knows what domains it’s receiving mail for. To do this, edit the mydestination variable to include all the proper domains. For me, the name of my server looks like server.mydomain.com. I want Postfix to accept mail for that domain, but not for mydomain.com (since that’s being handled by Google Apps), so mine looks like:

mydestination = server.mydomain.com, localhost.mydomain.com , localhost

Restart Postfix if you made any changes:

1	`$ sudo /etc/init.d/postfix restart`

Right. Now let’s send another test. Notice this time we’re using full domain names, instead of localhost:

$ telnet server.mydomain.com 25

ehlo server.mydomain.com
mail from: root@server.mydomain.com
rcpt to: user@server.mydomain.com
data
Subject: domains!
woot... I think this works.
.
quit

Working? Good.

Let’s test from the outside. The first step is to open up the correct ports in the firewall. Assuming you have iptables configured in the way the Slicehost article suggests, open up your /etc/iptables.test.rules and add the following:

# Allow mail server connections
-A INPUT -p tcp -m state --state NEW --dport 25 -j ACCEPT

Now let’s apply the rules:

1	`$ sudo iptables-restore < /etc/iptables.test.rules`

Make sure everything looks dandy:

1	`$ sudo iptables -L`

If it meets your fancy, save the rules:

$ sudo -i
$ iptables-save > /etc/iptables.up.rules

And now, from your local computer, let’s test it out.

$ telnet server.mydomain.com 25

ehlo server.mydomain.com
mail from: root@server.mydomain.com
rcpt to: user@server.mydomain.com
data
Subject: remote connection test
Hello, you.
.
quit

Now check your mail on the mail server as before. Once again, everything should be working.

Now we need to setup a virtual domain. Remember, I don’t want any virtual users. I only want aliases at a virtual domain to forward to my primary email address. That makes this relatively simple. (Be very, very happy. You should have seen this guide before, when I was still hosting virtual domains with virtual users!) Open up /etc/postfix/main.cf and add the following:

virtual_alias_domains = myvirtualdomain.com
virtual_alias_maps = hash:/etc/postfix/virtual

Create the /etc/postfix/virtual file referenced above and add the aliases:

alias@myvirtualdomain.com       user@mydomain.com

Turn it into a database:

$ cd /etc/postfix
$ sudo postmap virtual

Restart Postfix:

1	`$ sudo /etc/init.d/postfix restart`

Attempt to send an email to the new alias at the virtual domain:

$ telnet server.mydomain.com 25
ehlo server.mydomain.com
mail from: root@server.mydomain.com
rcpt to: alias@myvirtualdomain.com
data
Subject: virtual domain test
I hope this works!
.
quit

The message should now be in your primary email inbox!

As long as we’re setting up forwards, let’s forward system account mail to somewhere where it’ll actually get read. To do so, create a ~/.forward file with the following contents:

user@mydomain.com

Let’s also create a /root/.forward, so that roots mail gets forwarded to my local account (where it is then forwarded to my primary email). Root’s forward would simply read:

user

Next up: install Wordpress with rewrites. (Previously, we did a basic setup and installed a web server.)

An Ubuntu VPS on Slicehost: Web Server

2008-06-10T00:00:00-07:00

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Two of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Three, Part Four.

Now we’ve got a properly configured, but idle, box. Let’s do something with it.

Nginx is a small, lightweight web server that’s all the rage on some small corners of the Net. Apache is extremely overkill for a small personal web server like this and, since we’re limited to 256MB of RAM on this VPS, it quickly becomes a resource hog. Lighttpd is another small, lightweight web server, but I’m a fan of Nginx. Try it out.

First, we need to install the web server. Nginx is now in Ubuntu’s repositories:

1	`$ sudo aptitude install nginx`

That’s all it takes in Hardy, but if you really want a guide for it, Slicehost has you covered.

Slicehost has a few more useful guides to Nginx, including introductions to the config layout and how to get started with vhosts:

Next up, we’ll need to install MySQL and PHP, and get them working with Nginx.

Slicehost has a guide for installing MySQL and Ruby on Rails, which also includes suggestions on optimizing MySQL. I follow the MySQL part of the guide, stopping at “Ruby on Rails install”.

Now MySQL is working, lets install PHP:

1	`$ sudo aptitude install php5-common php5-cgi php5-mysql php5-cli`

To get PHP as FastCGI working with Nginx, we first have to spawn the fcgi process. There are a few different ways to do that. Personally, I use the spawn-fcgi app from lighttpd. To use it, we’ll compile and make lighttpd, but not install it. We’re only after one binary.

Lighttpd has a few extra requirements, so let’s install those:

1	`$ sudo aptitude install libpcre3-dev libbz2-dev`

Now, download the source and compile lighttpd. Then copy the spawn-fcgi binary to /usr/bin/:

$ wget http://www.lighttpd.net/download/lighttpd-1.4.19.tar.gz
$ tar xvzf lighttpd-1.4.19.tar.gz
$ cd lighttpd-1.4.19
$ ./configure
$ make
$ sudo cp src/spawn-fcgi /usr/bin/spawn-fcgi

Then, create a script to launch spawn-fci (I call it /usr/bin/php5-fastcgi):

#!/bin/sh
/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -C 2 -f /usr/bin/php5-cgi

The script tells spawn-fcgi to launch a fastcgi process, listening on 127.0.01:9000, owned by the web user, with only 2 child processes. You may want more child processes, but I’ve found 2 to be optimal.

Give the script permissions:

1	`$ sudo chmod +x /usr/bin/php5-fastcgi`

I then link the script filename to a version-neutral, err, version:

1	`$ sudo ln -s /usr/bin/php5-fastcgi /usr/bin/php-fastcgi`

Now we need an init script to start the process at boot. I use this one from HowToForge, named /etc/init.d/fastcgi:

#!/bin/bash
PHP_SCRIPT=/usr/bin/php-fastcgi
RETVAL=0
case "$1" in
    start)
        echo "Starting fastcgi"
        $PHP_SCRIPT
        RETVAL=$?
    ;;
stop)
        echo "Stopping fastcgi"
        killall -9 php5-cgi
        RETVAL=$?
    ;;
restart)
        echo "Restarting fastcgi"
        killall -9 php5-cgi
        $PHP_SCRIPT
        RETVAL=$?
    ;;
    *)
        echo "Usage: php-fastcgi {start|stop|restart}"
        exit 1
    ;;
esac      
exit $RETVAL

Give it permissions:

1	`$ sudo chmod 755 /etc/init.d/fastcgi`

Start it:

1	`$ sudo /etc/init.d/fastcgi start`

Have it start at boot:

1	`$ sudo update-rc.d fastcgi defaults`

Alright, now that PHP is running how we want it to, let’s tell Nginx to talk to it. To do that, add the following to your vhost server block in /etc/nginx/sites-available/mydomain.com, making sure to change the SCRIPT_FILENAME variable to match your directory structure:

location ~ \.php$ {
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /home/user/public_html/mydomain.com/public$fastcgi_script_name;
    include        /etc/nginx/fastcgi.conf;
}

Now let’s create that /etc/nginx/fastcgi.conf file that’s being included above. As per the Nginx wiki article, mine looks like this:

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;
fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

Then restart Nginx:

1	`$ sudo /etc/init.d/nginx restart`

Let’s create a file named test.php in your domain’s public root to see if everything is working. Inside, do something like printing phpinfo.

Go to http://mydomain.com/test.php. See it? Good. If you get “no input file specified” or somesuch, you broke something.

If you create an index.php, and delete any index.html or index.htm you might have, you’ll notice Nginx throws a 403 Forbidden error. To fix that, find the line in your vhost config (/etc/nginx/sites-available/mydomain.com) under the location / block that reads index index.html; and change it to index index.php index.html;. Then restart Nginx.

If you want SSL with your Nginx, Slicehost has a guide for generating the certificate and another guide for installing it.

You’ll want to install OpenSSL first:

1	`$ sudo aptitude install openssl`

There is one bug in the second guide. In the first server module listening on port 443, which forwards www.domain1.com to domain1.com, the rewrite rule specifies the http protocol. So, in effect, what that rule does is forward you from a secure domain to unsecure: https://www.domain1.com to http://domain1.com. We want it to forward to a secure domain. Simply change the rewrite rule like thus:

rewrite ^/(.*) https://domain1.com permanent;

Next up: install a mail server. (Previously, we did a basic setup.)

An Ubuntu VPS on Slicehost: Wordpress

2008-06-10T00:00:00-07:00

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Four of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Two, and Part Three.

I prefer to install Wordpress via Subversion, which makes updating easier. We’ll have to install Subversion on the server first:

1	`$ sudo aptitude install subversion`

After that, the Wordpress Codex has a guide to the rest of the install.

Nothing further is needed, unless you want fancy rewrites. In that case, we’ll have to make a change to your Nginx vhost config at /etc/nginx/sites-available/mydomain.com. Add the following to your server block under location / {:

# wordpress fancy rewrites
if (-f $request_filename) {
    break;
 }
 if (-d $request_filename) {
     break;
  }
  rewrite ^(.+)$ /index.php?q=$1 last;

While we’re here, I usually tell Nginx to cache static files by adding the following right above thelocation / { block:

# serve static files directly
location ~* ^.+\.(jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|css)$ {
    root  /home/user/public_html/mydomain.com/public;
    expires 7d;
    break;
}

That’ll go in the https server section, too. Now, enable rewrites in your Wordpress config. I use the following “custom” structure:

/%year%/%monthnum%/%day%/%postname%/

Then, restart Nginx:

1	`$ sudo /etc/init.d/nginx restart`

And there you have it! You know have a working, new web server and mail server.

(Previously, we did a basic setup, installed a web server, and installed a mail server.)

A Move to Slicehost

2008-06-09T00:00:00-07:00

Yesterday I moved this domain over to Slicehost.

Ian first told me about Slicehost when we were both looking to move away from Dreamhost last November. Initially, we both intended to find another shared host, but that proved far too difficult – it seems most hosting companies have something against shared hosting with decent limits and ssh access (that last part is the kicker).

I signed up with Slicehost at the end of last year and tinkered around with it for a month or so, experimenting with setting up the server in different ways. Eventually, I found an Ubuntu-Nginx-PHP-MySQL-Postfix-Dovecot setup that I enjoyed, and one which I was comfortable administering. In the beginning of the year, I moved a couple of my domains over to the Slice. It’s been a great experience. I’m not sure why it took me 6 months to finally move this domain – my primary one – over. Running a VPS is deceivingly simple* and well worth the effort. If you’re currently running on a shared host and have some basic competency in a UNIX environment, I’d recommend giving it a shot.

In a bit I’ll post a series of guides, compiled from my notes, on how I setup the server.

It’s deceivingly simple if you’re not running a full mail server with virtual users running around everywhere. That part was a pain. Hence, the move to Google.