Monthly Archives: August 2011

Debian 6.0.2 Squeeze, ProFTP, chroot and all that jazz

A base install of Debian squeeze does not include some of the tools required to establish a secure FTP server.

I started at

http://www.debian-administration.org/article/228/Setting_up_an_FTP_server_on_Debian

The ProFTP reference for TLS is somewhat sparse for step-by-step requiring some degree of thinking. Which is fine except if I am in a hurry.

How-to-Forge regarding Debian Etch gave some information that was relevant but missing a couple of steps that apply in the later Squeeze version of Debian (6.0.2).

So my steps for future reference are as follows:

Start by installing and establishing a basic FTP server. Not secured but functioning is the goal.

[bash]
#apt-get install proftpd-basic proftpd-doc
[/bash]

During the ProFTP install it will prompt for inetd or stand-alone, select stand-alone.

Create a test user account and password with adduser on the Debian system.

Test with a FileZilla install for a basic FTP connection on port 21. If this is working a basic connection will allow the user to see the entire server.

Based on the config /etc/proftpd/proftpd.conf setting to chroot the user to their /home/ directory will restrict the user login to only their home directory. Enable the line by removing the # sign at the start of the line in /etc/proftpd/proftpd.conf

[text]
DefaultRoot
[/text]

Stop and restart the proftpd service

[bash]
#service proftpd restart
[/bash]

Test again with a FileZilla install for a chroot FTP connection on port 21. It will probably fail unless the next step was done previously.

Check tail /var/log/proftpd/proftpd.log for errors like this:

[text]
Aug 09 16:30:44 server_name proftpd[9625] fq_server_name (::ffff:ip_address[::ffff:ip_address]): Preparing to chroot to directory ‘/home/username/’
Aug 09 16:30:44 server_name proftpd[9625] fq_server_name (::ffff:ip_address[::ffff:ip_address]): chroot to ‘/home/username/’ failed for user ‘username’: Operation not permitted
Aug 09 16:30:44 server_name proftpd[9625] fq_server_name (::ffff:ip_address[::ffff:ip_address]): error: unable to set default root directory
[/text]

The issue is that chroot is not installed by default and therefore a Filezilla connection should fail.

[bash]
apt-get install chrootuid
[/bash]

Stop and restart the proftpd service

[bash]
#service proftpd restart
[/bash]

Test again with a FileZilla install for a basic FTP connection on port 21 to the users home directory.

Once that is working adding TLS takes a few more steps.

Find and enable the following line by removing the # sign at the start of the line in

/etc/proftpd/proftpd.conf

[text]
include /etc/proftpd/tls.conf
[/text]

Install openssl

[bash]
# apt-get install openssl
[/bash]

Follow the details on How-to-Forge for creating a self-signed certificate for the FTP server in Step 3 Creating The SSL Certificate For TLS.

Step 4 Enabling TLS In ProFTPd is no longer correct for this version of Debian. The tls section is no longer in the /etc/proftpd/proftpd.conf but as a separate file in the same directory

Edit /etc/proftpd/tls.conf instead of /etc/proftpd/proftpd.conf

Turn on the appropriate sections and edit the relevant paths to suit your certificate locations.

Stop and restart the proftpd service

[bash]

#service proftpd restart

[/bash]

Modify the Filezilla settings to use Require explicit FTP over TLS and test again. The prompt for the certificate acceptance is because it is self-signed and tick the box to retain the certificate so that the prompt disappears.

Note that the self-signed certificate is valid only for 365 days and in a year it will need to be renewed.

I also referenced http://www.delphi3000.com/articles/article_4881.asp regarding the differences between SFTP and FTPS.

And this section of the ProFTP documentation for chroot information.

Plesk 10.2.0 and SSL Certificates part II

Tracking down the actual location of the SSL certificate in a Plesk subscription is a process I hope never to use again. But… I am getting an error while trying to install a certificate manually on the site.

Error: Some fields are empty or contain an improper value.

Certificate Name*

I wasted an hour before I realised that I still had a partial certificate setup in the old sub-domain that I could not use. I deleted that certificate restarted Apache. Generated a new certificate request and revised the certificate via RapidSSL. The install of the certificate in Plesk still reported an error with the signing Authority. I ended up at https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&id=SO16226 to find the correct Intermediate certificates for Plesk Apache.

And while Plesk seemed to settle down after adding them, using IE or Chrome to visit the site gave me errors that the Certificate was invalid.

I used http://www.sslshopper.com/ssl-checker.html to confirm the certificate and it came back as self-signed.

The penny dropped that I had not re-started the web service and the Apache config would still be using the default Plesk certificate.

A quick restart and it’s all good.

Plesk 10.2.0 and SSL Certificates

One of the servers I manage has a Plesk control panel. I am not familiar with it having used cpanel/whm for the last 11 years since I first got a hosted server.

I was setting up what I thought would be an easy SSL certificate install. I’ve started this post because I am now delving into the core of the server <supposition>as the damn GUI hates me.</supposition>

Before you even start, if you want to have an SSL certificate on a sub-domain site, forget it unless you a) make it a wildcard certificate or b) are prepared to have the only ip address attached to that certificate.

Plesk 10.x only allows one IP address per subscription and that is set for all the sub-domains as well as the domain attached to the subscription.

So to apply a certificate that works for the subscription it must be a wildcard certificate. i.e.

[code]
subscription_domain.tld
[/code]
sub-domains exist for
[code]
site1.subscription_domain.tld
site2.subscription_domain.tld
[/code]
certificate is for
[code]
subscription_domain.tld
[/code]
it will be applied to all the domains
[code]
https://subscription_domain.tld
https://site1.subscription_domain.tld
https://site2.subscription_domain.tld
[/code]

While the option to have a specific SSL for
[code]
site1.subscription_domain.tld
and
site2.subscription_domain.tld
[/code]
as it is not possible to split the IP addresses to isolate the SSL per IP address.