Little Fuzzy, door H. Beam Piper

De schrijver van ‘Little Fuzzy’ is in 1964 overleden, meer dan 50 jaar geleden dus, waardoor het auteursrecht op het boek verlopen is. Ik kon en mocht het daarom gratis downloaden. Little Fuzzy bespreekt een aantal interessante kwesties, zoals hoe je intelligentie kan definiëren. Verder is het redelijk zoetsappig, maar persoonlijk heb ik daar weinig bezwaar tegen.
LittleFuzzy
Als je dieper gaat graven, kan je vast nog heel veel vinden over Zarathustra (de naam van de planeet waar het verhaal zich afspeelt) en de manier van handelen van de karakters in het verhaal.

Alles bij elkaar vond ik het gewoon een leuk verhaal om te lezen. Weet je een keer niks te lezen dan kan je Little Fuzzy voor nop downloaden. Niks te verliezen dus.

How to install phpVirtualBox on Debian Jessie

Here are my notes on installing phpVirtualBox, a webbased graphical interface for VirtualBox, now recommended from VirtualBox’s site! These notes are for Debian 8.2 using Apache.

The web interface looks very similar to the original VirtualBox GUI and works very well.

phpVirtualBox01

If you haven’t done so already install Apache and php5:

# aptitude install apache2 php5

Installing VirtualBox
Source: https://www.virtualbox.org/wiki/Linux_Downloads

Add the following line to your /etc/apt/sources.list:

deb http://download.virtualbox.org/virtualbox/debian jessie contrib

(If you’re using an other version of Debian change jessie to your version.)

Add Oracle VirtualBox’s keyfile to your system so the source is trusted. (Don’t do it if you don’t want automatic updates for VirtualBox.)

# wget https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | apt-key add -
# aptitude update
# aptitude install virtualbox-5.1 

Install the Extension Pack (check here which version is the current one first):

# wget http://download.virtualbox.org/virtualbox/5.0.10/Oracle_VM_VirtualBox_Extension_Pack-5.0.10-104061.vbox-extpack
# VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-5.0.10-104061.vbox-extpack

Set up your system
Create a dedicated VirtualBox user and create a password:

# useradd -d /home/vbox -m -g vboxusers -s /bin/bash vbox
# passwd vbox

You’ll need the password later on.

Tell your system which user is going to run VirtualBox. In /etc/default/virtualbox (create it if it doesn’t exist):

VBOXWEB_USER=vbox
VBOXWEB_HOST=127.0.0.1

VirtualBox has a web interface for just this kind of software. We’ll be running it as our vbox user because it doesn’t need access to the rest of your system.

# sudo -u vbox vboxwebsrv &

The ampersand at the end detaches the program from the console so if it’s running and you press Ctrl+C it won’t stop but you will be able to do other stuff in that console including closing it.

If VirtualBox is running on another server you must pass along its IP address here:

# sudo -u vbox vboxwebsrv -H 192.168.1.4 &

Have vboxweb-service start on boot so we don’t need to enter the command manually every time:
in /etc/init.d/vboxweb (create it):

#!/bin/bash
sudo -u vbox vboxwebsrv &

Make the script executable:

# chmod +x vboxweb

Tell Debian to run it at normal bootups:

update-rc.d vboxweb defaults

The remarks about the script being incomplete is expected. Feel free to improve it.

Reboot to see if it works.

Installing phpVirtualBox
Download phpVirtualBox and extract it as a subfolder of /var/www/html. For production machines place phpVirtualBox in its own directory and restrict access.

# aptitude install unzip
# cd /var/www/html
# wget http://sourceforge.net/projects/phpvirtualbox/files/latest/download -O phpvirtualbox.zip

Unzip the downloaded file:

# unzip phpvirtualbox.zip

Rename for easier access:

# mv phpvirtualbox-5.0-3/ phpvirtualbox

Copy the config file and edit it:

# cd /var/www/html/phpvirtualbox/
# cp config.php-example config.php

In /var/www/html/phpvirtualbox/config.php change:

var $username = 'vbox';
var $password = 'P@55w0rd';

Use the password you gave the vbox user earlier on.

Open your browser and point it to your server’s address followed by /phpvirtualbox, for example http://myserver/phpvirtualbox. Default username and password are both admin.

To view the VM, select it and on the right side click the Console button. If all is well you will be able to select your desired screen resolution and connect to the VM.

phpVirtualBox08

Pretty cool!

The part that provides this is actually an RDP client embedded in the VirtualBox Extention Pack. If it doesn’t work make sure you have the latest Extension Pack installed.

It is also possible (and faster) to view the VM from a locally installed RDP client.

If you’re on a Windows system just run

C:\>mstsc

or type remote desktop in the Start Menu box.

phpVirtualBox05

In the Remote Desktop Connection window type the IP address of the server hosting VirtualBox (not the address of your virtual machine) followed by the port number.

phpVirtualBox04

The port number defaults to 9000 but you can set it from the virtual machine’s properties in VirtualBox: Display > Remote Display.

phpVirtualBox06

A port or port range is accepted.

If unsure just check what the built-in console wants to connect to:

phpVirtualBox07

Remote Desktop will then show your virtual machine.

phpVirtualBox03

Alternatively select the VM in phpVirtualBox and from the Details window, under Display, click on the port number. This will fire up your RDP client.

There are terminal services clients for just about any operating system.

Notes:
– phpVirtualBox’s default username and password are both admin.

– VirtualBox’s default interface and phpVirtualBox even more so do not show all options. If you need to perform an operation on a VM that requires options not shown in the GUIs use the command line interface: VBoxManage. Its documentation is excellent and it allows you to access all available options.

– If you use VBoxManage remember to do it under the account of your dedicated VM user (c.q. vbox). If you use root or any other account not in /var/www/phpvirtualbox/config.php the operations will not be reflected in the web interface.

– phpVirtualBox major and minor versions always reflect VirtualBox versions.

– A very cool feature is remote usb. You can pass your usb device through to the VM via the remote display. Haven’t tested it yet but I will. Read all about it here!

– If you’re planning on running PfSense like I did or just *BSD check out this post on fixing a high CPU load.

If you’re looking for a VirtualBox backup script, you’re in luck!

Enjoy!

Install phpSysInfo on Debian Jessie

My notes on installing phpSysInfo on Debian Jessie, just so I won’t forget.

Install the necessary software:

# aptitude install apache2 php5 phpsysinfo

Create a configuration amendment for Apache. Create the following file in /etc/apache2/conf-available/phpsysinfo.conf:

Alias /phpsysinfo /usr/share/phpsysinfo
<Location /phpsysinfo>
        Options None
        Order deny,allow
        Deny from all
        Allow from localhost
        # Change next line to your own subnet or IP
        Allow from 192.168.1.
        Allow from all
</Location>

Enable the config file and reload Apache:

# a2enconf phpsysinfo
# service apache2 reload

phpsysinfo

Halo: Cryptum, door Greg Bear

De term ‘Halo:’ had ik af en toe voorbij zien komen op Tweakers.net en daarom heb ik er weinig aandacht aan besteed: voor spelletjes moet je de tijd nemen. Ik was daarom redelijk skeptisch toen ik begon aan Greg Bears Halo: Cryptum. Ik wist niet zeker of dit boek met het spel te maken had. Achteraf bleek van wel en had ik dat geweten dan had ik er nog eens over nagedacht.

Greg Bear is echter een steengoeie schrijver en zelfs zijn technothrillers vind ik geweldig. Daar kan je je niet echt een buil aan vallen, dacht ik. Halo komt echter uit de pr-koker van Microsoft en we weten allemaal wat daaruit komt…

halocryptum

Het Halo-universum zit interessant en goed doordacht in elkaar. Het verhaal is aardig. De karakters zijn naar Bear-maatstaven matig maar relatief aan gemiddelde schrijvers redelijk. De ingrediënten zijn er allemaal maar op de een of andere manier wordt het niet één geheel. Het leek of het voor iemand anders was geschreven en achteraf werd ook duidelijk waarom: het is gewoon een verhaal dat bedoeld is als achtergrond bij een schietspelletje. Als je graag Halo speelt dan zal het vast een geweldig boek zijn.

De scifi die we van Bear gewend zijn biedt vaak een nieuwe kijk op de werkelijkheid en inzichten in de mens. Halo biedt voornamelijk inzichten in het fictieve Halo-universum. Technisch niks op aan te merken.

Adding ownCloud 8 to Active Directory 2012 R2 – Part 7: Server maintenance

Part 1: Introduction
Part 2: Installing Debian 8
Part 3: Installing ownCloud 8
Part 4: Connecting to Active Directory
Part 5: Security
Part 6: Miscellany
Part 7: Server maintenance

OwnCloud does a fine job listing the steps for creating backups and updating an ownCloud server. Read all about it here. I’m not going to copy ownCloud’s information here. I’ll give some sample scripts you can use targeted at the specific lab setup we created in the previous parts of this series.



Backup up ownCloud
As per ownCloud’s suggestions below script backs up the config folder, the data folder and the database. In addition it lists all installed packages; this list can serve as a base to quickly reinstall them should you need to reinstall your server.

This script backs up to a Windows server. It assumes you have installed smbclient and /root/.smbcreds contains the Windows server share’s credentials in this format:

username=vorkbaard
password=P@55w0rd

The file should only be readable by root:

# chmod 600 /root/.smbcreds

The script creates daily folders containing full backups. I suggest you keep a bunch of recent ones and some older ones, or back up the config and data separately in order to not completely fill up your drives in a week.

The backups are stored in the share \\server01\backups in a folder called “ownCloud daily backups” to demonstrate how to handle paths with spaces.

Create a file called /root/backup.sh:

#! /bin/bash

NOW=$(date +"%Y-%m-%d")

# Create backupdir
mkdir ./$NOW

# Write list of installed packages to backupdir
dpkg --get-selections | grep -v deinstall > ./$NOW/InstalledPackages.txt

# Copy software config to backup dir
cp -R /etc/ ./$NOW

# Copy ownCloud install and config to backup dir
cp -R /var/www/owncloud ./$NOW

# Copy ownCloud data to backup dir
cp -R /var/ownclouddata ./$NOW

# Export Mysql database and copy to backup dir
mysqldump -uroot --password=Y0urSqLp4ssw0rd --events --all-databases > ./$NOW/mysqlbackup.sql

# Copy backupdir to tarball
tar -cvpzf backup-$NOW.tar.gz ./$NOW

# Copy tarball to backup server
smbclient //server01/backups -l 192.168.1.2 -A /root/.smbcreds -c "cd \"ownCloud daily backups\"; put backup-$NOW.tar.gz backup-$NOW.tar.gz"

# Remove backupdir and tarball
rm -R /root/$NOW
rm /root/backup-$NOW.tar.gz

Make the script executable:

# chmod +x /root/backup.sh

Configure the script to run every night using cron:

# crontab -e

Add this line:

59 0 * * * bash /root/backup.sh

Check your backups regularly.

Of course if you’re running ownCloud on a VM you could just create exports and save those on your server.

Restoring ownCloud
To restore your backup to a fresh installation first completely setup the server:

  1. Install Debian
  2. Setup the correct repositories
  3. Reinstall all software with the selections list from your backup:
    # dpkg --set-selections < selections
    # apt-get update && apt-get -u dselect-upgrade
    
  4. Install ownCloud including a database with the same name as before
  5. Import the database backup to the fresh one:
    # mysql -u root -p --one-database owncloud < mysqlbackup.sql
  6. Restore the data from your backup.



Updating ownCloud
OwnCloud extensively covers upgrading on their site.

The only thing I want to add is you may want to create a snapshot of your server before upgrading.

I compliment ownCloud on their ongoing professional and technical growth. And I know it’s not a favourite activity of a lot of people but ownCloud really improved their documentation in the last couple of years. I hope they will continue on this path.

Adding ownCloud 8 to Active Directory 2012 R2 – Part 6: Miscellany

Part 1: Introduction
Part 2: Installing Debian 8
Part 3: Installing ownCloud 8
Part 4: Connecting to Active Directory
Part 5: Security
Part 6: Miscellany
Part 7: Server maintenance

In this part we’ll cover some miscellaneous topics:



Setup mail
OwnCloud sometimes needs to send out mail, for example when a user wants to share a link via e-mail or needs to use the password recovery function. OwnCloud offers three methods for mail: SMTP, sendmail and PHP. I’ll describe two of them.

Gmail via SMTP
In case your ISP doesn’t allow outgoing traffic on port 25 you can use your Gmail account to send out mail. It’s an easy workaround and the drawback is the mail have your Gmail address as sender. For private use that’s ok, or even for a small company.

oc8ad_114

The setup is pretty straightforward.
Send mode: smtp
Encryption: TLS
From address: can be anything
Authentication method: Plain [x] Authentication required
Server address: smtp.gmail.com:587
Credentials: your@gmail.address P@55w0rd -> Store credentials

Click Send email to test your settings and if the ‘Email sent’ box turns green you’re set.

Email via PHP
If you’re in a larger company or you don’t want to use a Gmail account set Send mode to php. Fill out a dedicated sender address and click the Send email button. The address doesn’t have to exist but it’s best if it does.

oc8ad_115

Document Previews
Document support is a fun feature in ownCloud but not much more than that. It’s not an Office 365 or Google Docs replacement. I use it for private purposes or to open the occasional Word document but that’s about it. Try it out if your server can handle a LibreOffice installation.

OwnCloud supports ODF documents natively. For MS Word support you need to install LibreOffice or one of the OpenOffices:

# aptitude install libreoffice

In the ownCloud web interface go to Admin > Apps…
oc8ad_116

At Productivity > Documents click Enable

oc8ad_117

On the Admin page at Documents select Local and click ‘Apply and test’. If a green button says Saved everything is in order.

oc8ad118

If not check your logfile and what ownCloud has to say about it.

To actually use the Documents feature you need to click Files (top left) > Documents. You can edit your documents from there; you can not edit them from the default file view.

oc8ad119

oc8ad120

oc8ad121

If you’ve enabled open_basedir in PHP make sure it has read access to the LibreOffice executable: /usr/bin/libreoffice.

Enable uploading of big files
By default PHP allows you to upload 2MB files max. From https://doc.owncloud.org/server/8.1/admin_manual/configuration_files/big_file_upload_configuration.html?highlight=maximum:

In /etc/php5/apache2/php.ini change:

upload_max_filesize = 16G
post_max_size = 16G
max_input_time = 3600
max_execution_time = 3600

You’ll find explanations of the values above in php.ini. I’m mostly posting it here for myself. Change the values to something sane for your environment.

Cron
For a dedicated ownCloud server I suggest you set cron to cron or. If you don’t care about the speed and you’re the only user set it to Ajax.

Part 7 will be the last part in this series. It will cover backups and restores, and updates. It is not very exciting but exciting is the last thing you need in a production server.

Adding ownCloud 8 to Active Directory 2012 R2 – Part 5: Security

Part 1: Introduction
Part 2: Installing Debian 8
Part 3: Installing ownCloud 8
Part 4: Connecting to Active Directory
Part 5: Security
Part 6: Miscellany
Part 7: Server maintenance

This part is about basic security. OwnCloud lists a number of security options on their site. We’ll be going over their suggestions and add one extra while we’re at it. Everything combined should result in a server with a good baseline security.

Here are today’s activities.

Set the proper file permissions
OwnCloud provides a script to easily set the proper file permissions on ownCloud installations. Their page also lists all suggested permissions per directory or file so you can set the permissions for modified installations.

Here’s a small adaptation of the script:

Paste this in a file called permissions.sh:

#!/bin/bash
ocpath='/var/www/owncloud'
datapath='/var/ownclouddata'
htuser='www-data'
htgroup='www-data'
rootuser='root'
find ${ocpath}/ -type f -print0 | xargs -0 chmod 0640
find ${ocpath}/ -type d -print0 | xargs -0 chmod 0750
chown -R ${rootuser}:${htgroup} ${ocpath}/
chown -R ${htuser}:${htgroup} ${ocpath}/apps/
chown -R ${htuser}:${htgroup} ${ocpath}/config/
chown -R ${htuser}:${htgroup} ${datapath}/
chown -R ${htuser}:${htgroup} ${ocpath}/themes/
chown ${rootuser}:${htgroup} ${ocpath}/.htaccess
chown ${rootuser}:${htgroup} ${datapath}/.htaccess
chmod 0644 ${ocpath}/.htaccess
chmod 0644 ${datapath}/.htaccess

Edit ocpath and datapath to your own variables. htuser, htgroup and rootuser are correct if you’re installing on Debian with Apache, which we are. ocpath and datapath contain the correct values for our lab setup.

Make the script executable:

# chmod +x permissions.sh

Run the script:

# ./permissions.sh

If no errors occured you’re done!

Enter trusted domains
From the ownCloud site: in /var/www/owncloud/config/config.php change the array of trusted domains. Enter all names and addresses by which you want to be able to access ownCloud. I’ll be using the domainname owncloud.vorkbaard.nl. 192.168.1.3 is ownCloud’s local ip address.

'trusted_domains' =>
  array (
   0 => 'owncloud.vorkbaard.nl',
   1 => '192.168.1.3',
),

OwnCloud suggest whitelisting ‘localhost’ as well, but 127.0.0.1 is automatically whitelisted and our server has no gui so I think you will survive the one time you need to type localhost’s IP address.

Give PHP read access to /dev/urandom (also: configure open_basedir)
open_basedir is a php.ini directive which specifies which paths PHP is allowed to access through script. If it’s not configured PHP can access any directory allowed by the filesystem. By default PHP in Debian 8 has no configuration for open_basedir so /dev/urandom may be accessed by PHP to acquire entropy.

Since ownCloud has no business being anywhere else on our system but in its own directories, /tmp/ and /dev/urandom let’s tell PHP about this. Open /etc/php5/apache2/php.ini and find the line that reads

; open_basedir

and change it to

open_basedir /var/www/owncloud/:/var/ownclouddata/:/var/log/owncloud.log:/tmp/:/dev/urandom

Reload Apache to have open_basedir take effect:

# service apache2 reload

SELinux
Setting up SELinux in Debian is still a bit wonky. We’ll skip it for now. If you have genius suggestions feel free to mention them in the comments 🙂

Place data directory outside of the web root
We did that in the setup so we’re covered!

Disable preview image generation
This is really a choice between functionality and marginally more security. If you’re paranoid about it – or just don’t care about image previews – then disable it. Alternatively sign up for ownCloud’s newsletters and I think you’ll be notified soon enough if a security issue with image generation occurs.

Enable SSL
In Apache your have two choices for SSL: either you use a self-signed certificate (appropriately named a snakeoil certificate in Apache) or you pay a certificate vendor a fee for a commercial certificate.

We’ll first do the snakeoil, later on the commercial. The domain I’ll be using is owncloud.vorkbaard.nl. You will need to use your own domain name and pay a DNS provider to tell the rest of the world about it. My DNS provider of choice is Webbed.nl because they provide excellent service for a fair price.

I assume you already have you own domain name and have it pointed at your webserver. If not, just edit your hosts file for now. I’m testing on my Windows AD server so that’s where I’ll edit my hosts file: click Start, type Notepad, rightclick it and choose Run as administrator.

oc8ad_087

In Notepad open %windir%\system32\drivers\etc\hosts. and add this line:

192.168.1.3	owncloud.vorkbaard.nl

oc8ad_088

Save the file and close Notepad. If you can’t save it, open Notepad as administrator.

Ping owncloud.vorkbaard.nl; it should resolve to 192.168.1.3.

Ping owncloud.vorkbaard.nl
Ping owncloud.vorkbaard.nl

If you remembered to add owncloud.vorkbaard.nl to your trusted domains in ownCloud’s config.php you can now connect to ownCloud via http://owncloud.vorkbaard.nl.

Connect to http://owncloud.vorkbaard.nl
Connect to http://owncloud.vorkbaard.nl

On your ownCloud server in /etc/apache2/sites-available open the file default-ssl.conf. Change

DocumentRoot /var/www/

to

DocumentRoot /var/www/owncloud

Enable the site:

# a2ensite default-ssl

Enable Apache’s SSL module:

# a2enmod ssl

Disable the non-ssl version of the site. Strictly this is optional but there’s no use for it anymore so why keep it?

# a2dissite 000-default.conf

Restart Apache so the SSL module and the changes in enabled/disabled sites take effect:

# service apache2 restart

Now go to https://owncloud.vorkbaard.nl and depending on which browser you are using you’ll get some sort or warning about the missing SSL certificate.

oc8ad_091

If you’re using Google Chrome like I am click the Advanced link.

oc8ad_092

Internet Explorer does a similar thing.

oc8ad_093

Click Proceed to owncloud.vorkbaard.nl (unsafe).

oc8ad_094

And Bob’s your uncle.

Now, if you are the only user and you’ll only be using ownCloud to sync to your desktop of mobile device you could stop here. Even though there’s no signed and trusted certificate the data that’s sent back and forth would be encrypted just the same.

oc8ad_095

Just tell your client to trust the certificate anyway.

This is the snakeoil method. It works but it doesn’t look nice and you know the site can be trusted but others don’t.

Error: Your data directory and your files are probably accessible from the internet.
OwnCloud does a strange thing after you enable SSL. On entering the Admin page it verifies whether the data directory (/var/www/owncloud/data by default but we changed it to /var/ownclouddata) is accessible through the internet. It should not be otherwise non-authorized users might type in direct URLs to files and download them. It does this by placing a .htaccess file in the data directory containing supplemental instructions for the webserver. If it can’t find the .htaccess file it will tell you.

It also verifies if it can read from and write to the data directory. It does this by placing a file called htaccesstest.txt in the data directory the moment you open the Admin page. It then tries to remove that file.

The problem is that in between it will do some other stuff for just over two minutes during which the animated ‘loading’ indicator will be shown. The test appears to hang so you might be tempted to reload the page. If you do that when the test has not fully completed the htaccesstest.txt is still there and ownCloud assumes it cannot read-and-write in the data directory and I guess just gives up on the .htaccess file altogether. It will tell you so in the Security & setup warnings section on the Admin page.

Data directory and .htaccess file security warning
Data directory and .htaccess file security warning

After a while though the htaccesstest.txt file disappears. If you:
– then reload the Admin page,
– would have waited for the tests to fully complete, or
– would have manually removed the htaccesstest.txt file
ownCloud will tell you that everything is fine.

I guess this is a bug in ownCloud which will be fixed in time. If you let ownCloud run its tests for two minutes and it tells you everything is in order then next time you can safely ignore the message about the .htaccess file not working and the data directory being in the web server document root. (If however it keeps complaining even after waiting out the full test round you should investigate further.)

Security & setup warnings: all checks passed
Security & setup warnings: all checks passed

Get a commercial certificate
When it comes to commercial certificates there are a lot of options and their prices vary from a small fee to thousands of euros. For private use or a small company what’s important is that things run smoothly and your users don’t get confusing warnings. The cheapest certificates suffice for that. The ones I buy are €8 per year, less if you get certs for more than one year at a time.

I get my certificates at Xolphin.nl because they provide very fast service and are very helpful. I’ll describe the process here but your experience will likely differ if you’re using a different certificate vendor.

Whichever provider you choose the process is always the same:

  1. You generate a Certificate Signing Request (CSR) on your server.
  2. You send the CSR to the certificate vendor.
  3. The vendor verifies your identity. Based on the kind of certificate you are buying this process is less or more elaborate. Basically the more you pay the stricter they are.
  4. The vendor sends you one or more signed certificate files.
  5. You install the files in your webserver.


Let’s start with step 1: generate a CSR.
Adapted from SSLcertificaten.nl.

** Remember to replace owncloud.vorkbaard.nl with your own domain! **

# cd /etc/ssl/certs
# openssl req -nodes -newkey rsa:2048 -keyout owncloud.vorkbaard.nl.key -out owncloud.vorkbaard.nl.csr

You’ll need to enter information that corresponds with that of the domain name owner (DNS registry) or the Chamber of Commerce if applicable. [xx] denotes the standard value.

Country Name (2 letter code) [AU]: your country code. For the Netherlands this would be NL. If in doubt ask Google: https://www.google.nl/search?q=csr+2+letter+country+code+list
State or Province Name (full name) [Some-State]: your province
Locality Name (eg, city) []: your city
Organization Name (eg, company) [Internet Widgits Pty Ltd]: your exact company name if applicable, otherwise try your domain name. I tend to use Vorkbaard.nl
Organizational Unit Name (eg, section) []: ICT dept or whatever you like or is appropriate.
Common Name (eg, YOUR name) []: your (sub)domainname, e.g. owncloud.vorkbaard.nl. Not your own name.
Email Address []: your@email.address
A challenge password []: do not enter anything here
An optional company name []: do not enter anything here

Print the CSR

# cat owncloud.vorkbaard.nl.csr

oc8ad_098

Select every line in the CSR including the BEGIN CERTIFICATE HERE and END CERTIFICATE HERE lines.

Change the permissions of the .key file OpenSSL generated so only root can read it:

# chmod 600 owncloud.vorkbaard.nl.key

Move it to the private folder:

# mv owncloud.vorkbaard.nl.key /etc/ssl/private

Head over to your SSL provider’s website and start the certificate request process. They’ll provide you with a textbox to paste your CSR in.

oc8ad_099

Paste the CSR including the first and last lines.

The certificate vendor will need some information: your name, telephone number, payment method and a method to verify that you are indeed the owner of the (sub)domain you’re requesting the certificate for. These methods may include:
– you need to enter some file on your webserver
– you need to register a special subdomainname in your DNS
– you need to receive a mail at admin@ or some other static e-mail address.

After placing the order you may receive a verification mail with a code you need to fill out on the Comodo Security site, or some other SSL vendor.

If like me you placed your order with Xolphin.nl you’ll receive among other files a zip file containing four certificates:

  1. owncloud_vorkbaard_nl.crt
  2. COMODORSADomainValidationSecureServerCA.crt
  3. COMODORSAAddTrustCA.crt
  4. AddTrustExternalCARoot.crt

Depending on the kind of certificate you purchased you may or may not receive intermediate certificates.

To install the certificate in Apache on Debian 8 you need to concatenate the four certificates in the exact order I mentioned: first your own cert, then the Domain Validation Secure Server CA, then the Add Trust CA and finally the Add Trust External CA Root.

I think this is silly but there you go. In Linux you can do this with the following command:

# cat owncloud_vorkbaard_nl.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > bundle.owncloud.vorkbaard.nl.crt

In Windows just fire up Notepad and copy and paste the files. If you’re feeling geeky do

copy /a owncloud_vorkbaard_nl.crt + COMODORSADomainValidationSecureServerCA.crt +  COMODORSAAddTrustCA.crt + AddTrustExternalCARoot.crt bundle.owncloud.vorkbaard.nl.crt

Make sure that in any case bundle.owncloud.vorkbaard.nl.crt contains ALL lines from all four certificate files including the BEGIN and END CERTIFICATE lines with no empty lines in between.

In /etc/apache2/sites-available/default-ssl.conf replace the snakeoil by the real pixie dust: find the lines that read

# SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
# SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

and replace them by

SSLCertificateFile      /etc/ssl/certs/bundle.owncloud.vorkbaard.nl.crt
SSLCertificateKeyFile   /etc/ssl/private/owncloud.vorkbaard.nl.key

Also while you’re in there just after

ServerAdmin webmaster@localhost

(which you should change to your own e-mail address) add:

ServerName owncloud.vorkbaard.nl

Save the file and reload Apache:

# service apache2 reload

Reload the webpage in your browser: https://owncloud.vorkbaard.nl

oc8ad_100

To be honest it will probably fail because:

  • you made a typo somewhere
  • a file is not in the right place
  • you forgot to write https instead of http and also
  • forgot to do a2dissite 000-default
  • forgot to do service apache2 reload
  • you botched the concatenation of the bundle certificate
  • you overwrote your local hosts file
  • something else
  • a combination of the above

There are a million ways to get SSL to work (and a million more to screw it up, do it wrong or both). The way I’ve described here is a simple one because there’s only one site in your Apache configuration and this entire server is dedicated to ownCloud. Feel free to experiment with other methods. They can be just as good and a lot of them will be better.

Make the Strict Transport Security warning go away
From the ownCloud site:
In /etc/apache2/sites-available/default-ssl.conf just after ServerName owncloud.vorkbaard.nl add:

 <IfModule mod_headers.c>
      Header always set Strict-Transport-Security "max-age=15768000;includeSubDomains; preload"
</IfModule>

Enable the Headers module and restart Apache:

# a2enmod headers
# service apache2 restart

Deny access after three wrong passwords
We’re going to use Fail2ban to deny access to ownCloud after entering a wrong username. After ten minutes the user may try again. The purpose of this is to prevent password hammering: infinitely guessing a user’s password to break in to their account.

Fail2ban is software that can take action based on the contents of logfiles. You define combinations of software (based on that software’s logfile) and actions. These combinations are called jails in Fail2ban. The actions can include blocking access (using the firewall) and sending a notification e-mail to the administrator.

First we’ll set up the mail part, then Fail2ban. If you don’t care about mails from Fail2ban you can skip this part.

The mail part
My provider blocks outgoing traffic on port 25. They do that in order to prevent clients from sending spam. As a result my server can no longer send mail to me. My workaround is to have my server use my Gmail account to send out mail as Gmail’s SMTP server accepts traffic on port 587 instead of 25.

Debian 8’s default MTA is Exim4. Exim is capable of sending mail through Gmail but I find SSMTP easier to use with Gmail so I’m going to set up SSMTP. As a reference I will also configure Exim4 to send out mail directly. You should use one or the other: SSMTP or Exim4, not both. Luckily Debian will disable Exim4 for you if you install SSMTP.

Using Exim – only if your ISP allows outgoing traffic on port 25
Set up Exim (source: https://wiki.debian.org/Exim)

# dpkg-reconfigure exim4-config

The Package configurator will open. Select the following settings:
General type of mail configuration: internet site; mail is sent and received directly using SMTP.

oc8ad_101

System mail name: vorkbaard.nl (replace with your own domain or just your system’s hostname (i.e. owncloud.vorkbaard.nl). The worst that can happen is your mail will be blocked by your spamfilter. Just whitelist your server’s IP address or the sender’s address then.

oc8ad_102

IP-addresses to listen on for incomming SMTP connections: // leave blank

oc8ad_103

Other destinations for which mail is accepted: vorkbaard.nl (same as with System mail name).

oc8ad_104

Domains to relay mail for: // leave blank

oc8ad_105

Machines to relay mail for: // leave blank

oc8ad_106

Keep number of DNS-queries minimal (Dial-on-Demand) ?: No

oc8ad_107

Delivery method for local mail: Maildir format in home directory. Mbox format in /var/mail/ will also work but Maildir is what Debian advises so there you go. We’re not listening for incoming mail anyway, only outgoing.

oc8ad_108

Split configuration into small files ? : No

oc8ad_109

Update and restart Exim:

# update-exim4.conf
# service exim4 restart

Continue to the section about testing the e-mail capability.

Using SSMTP – if you want to send out mail using your Gmail account
Install SSMTP:

# aptitude install ssmtp

When the installer asks if you want to replace exim4 answer yes.

Open /etc/ssmtp/ssmtp.conf and edit (or add) the following values:

root=username@gmail.com
mailhub=smtp.gmail.com:587
hostname=username@gmail.com
UseSTARTTLS=YES
AuthUser=username@gmail.com
AuthPass=p@55word
FromLineOverride=yes 

In /etc/ssmtp/revaliases create an alias for root by adding this line:

root:username@gmail.com:smtp.gmail.com

Replace all instances of username@gmail.com with your own complete Gmail e-mail address. You may use your custom domain address here if you configured one with Google Apps. Replace P@55word with your own Gmail password or your app specific password if you enabled that.

Testing the e-mail functionality
Test your server’s mailing capability by sending a test mail:

# echo “test 01” | mailx -vvv -s “test 01” your@email.address

Replace your@email.address with your own e-mail address. I tend to use a sequence number in my test mails so you can see exactly which test mails have arrived. -vvv means: be very verbose about what you’re doing. If something goes wrong you will probably be able to see what it causes it.

Setting up Fail2ban
Install:

# aptitude install fail2ban

Fail2ban uses template and differential files. This means you get a .conf file and create .local files which contain only the parts that differ from the .conf. Essentially just copy the .conf and make changes there rather than in the .conf. It makes upgrading easier. We’re not upgrading right now but it’s always nice to know why you do what you’re doing. Directly changing the .conf would work as well.

# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Remember the jail files? A jail in Fail2ban is a combination of logfiles and actions. Fail2ban can handle multiple jails. A filter is the part of the logfile Fail2ban should look for. Helpful users on the ownCloud forum have provided the regular expressions.

Create the file /etc/fail2ban/filter.d/owncloud.conf and add:

[Definition]
	failregex={“reqId”:”.*”,”remoteAddr”:”.*”,”app”:”core”,”message”:”Login failed: ‘.*’ \(Remote IP: ”\)”,”level”:2,”time”:”.*”}
	ignoreregex =

Make sure your /var/www/owncloud/config/config.php contains

	'logtimezone' => 'Europe/Amsterdam',

Or your own timezone. Find your timezone here: http://php.net/manual/en/timezones.php.

In /etc/fail2ban/jail.local add this jail:

[owncloud]
enabled = true
filter = owncloud
logpath = /var/log/owncloud.log
maxretry = 3
port = 443

You may edit maxretry to your own tastes of course. This is the amount of seconds an IP address is banned. Afterwards the ban is lifted.

If you want Fail2ban to send you an e-mail when someone is banned change destemail:

mta = mail
destemail = your@email.address

Set action:

  • action_ = just ban
  • action_mw = ban and mail
  • action_mwl = ban and mail with whois report and relevant log lines

I suggest _mwl but change it to your needs.

action = %(action_mwl)s

Start Fail2ban:

# fail2ban-client start

If it was already running:

# service fail2ban restart

Upon starting Fail2ban you should see any errors that were encountered. Pay close attention and troubleshoot when necessary. If you see no errors when starting Fail2ban then all should be fine. Fail2ban should also send you a mail to notify you that it has started. If you don’t receive this (and it’s not in your spambox as well) then you need to verify your server’s mail settings.

Now for the test. Open the ownCloud web interface and try to log in three (or whatever you set as the maximum) times with a wrong username-password combination.

oc8ad_110

If all is well you will now no longer be able to access your ownCloud site.

oc8ad_111

You should also receive an e-mail.

oc8ad_112

To manually unban a client do

# fail2ban-client set owncloud unbanip 192.168.1.2

To manually check the Fail2ban’s ownCloud jail do

# fail2ban-client status owncloud

oc8ad_113

Next up: miscellaneous ownCloud tweaks.