Ubuntu – What Can Be Done To Secure Ubuntu Server

The easiest one I've ever installed is postfix with dovecot. There is a dovecot-postfix package, but it also looks like the Ubuntu server team has packaged this as mail-stack-delivery :

Description: mail server delivery agent stack provided by Ubuntu server team
 Ubuntu's mail stack provides fully operational delivery with
 safe defaults and additional options. Out of the box it supports IMAP,
 POP3 and SMTP services with SASL authentication and Maildir as default
 storage engine.

Looking in the Software Center, I see that dovecot-postfix is present as a meta-pacakge (but I don't know if it will be called that a release or two from now). But that is what I'd recommend -- it's straightforward and secure.

From the command line on my 10.10 desktop, I installed this via apt-get :

sudo apt-get install dovecot-postfix

Give it a shot if you like, and if you have questions, just start a new post.

Here's a oldish (2009) Ubuntu Server Blog post that gives some of the details on the dovecot-postfix configuration.

I'm trying to find out more information on the current status of Ubuntu-centric mailserver projects. Right now I'm not finding much more than a May 2010 wiki post about making anti-spam/virus integration easier.

It will be as secure as your Web server configuration and your Web application, just like it would be were it deployed on a "real" Web server. If the Web server is running as the www-data user, you could change your home directory permissions to something that the www-data user cannot read:

cd ~
chmod 750 .

Run that while logged in as your own username. The rest cannot be guessed without lots information from you including the Web application itself. But, at least this much may offer a little more peace of mind knowing your files in your home directory will not be read.

Add another layer by creating a .htaccess file in the DOCUMENT_ROOT (/var/www/ ?) so that anyone who access the Web server will need to supply a username and password first. This could always be removed at deployment time.

Assuming you are using Apache... edit your Apache config file to make sure that any AuthConfig directives you add will work. Within the 'Directory' directive that specifies your document root, make sure you have AuthConfig in your AllowOverride statement:

AllowOverride AuthConfig

Or, you could use "All":

AllowOverride All

This lets us put Apache directives in .htaccess files. Now create a password file somewhere outside the public portion of the Web site. Here I create (-c) a password file named passwords in /usr/local/etc/apache/ with the initial user, my_username. It will prompt for password.

sudo mkdir -p /usr/local/etc/apache/
sudo htpasswd -c /usr/local/etc/apache/passwords my_username

Then put some Apache AuthConfig directives in the document root. If the document root is /var/www/, then use your favorite editor to create a new file name .htaccess...

sudo vim /var/www/.htaccess

The contents of that file ...

AuthType Basic
AuthName "My Web App"
AuthUserFile /usr/local/etc/apache/passwords
Require user my_username

Save. Change owner and permissions, if running as www-data:

sudo chown www-data /var/www/.htaccess
sudo chmod 400 /var/www/.htaccess

Now no one can use the Web server without username and password, plus the Web server cannot read your personal files. I do not know how or if this password method could work, though, when PayPal is redirecting back to you.

I suppose you could move the .htaccess in and out of the /var/www directory as needed while you are developing the PayPal return portion of your Web app.