Archiv der Kategorie: Security

Root login on debian mariadb

Debian switched to mariadb by default. On a new installation you can login to your mysql database as root just by executing the mysql command without a password.

root@host:~# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 56339
Server version: 10.1.26-MariaDB-0+deb9u1 Debian 9.1

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type ‚help;‘ or ‚\h‘ for help. Type ‚\c‘ to clear the current input statement.

MariaDB [(none)]>

This is or can be a nice security feature. Connecting as root is only allowed by the root system user through the mysql unix socket. On the other hand you may have some software which needs the root user to access the database server. In this case you need to tweak some user settings.

First, set a password.

MariaDB [(none)]> update mysql.user set password=password(‚geheim‘) where user=’root‘;
MariaDB [(none)]> flush privileges;

Next, change the connection type.

MariaDB [(none)]> update mysql.user set plugin=“ where user=’root‘;
MariaDB [(none)]> flush privileges;

Downside seems to be the init process and autostart procedure. If you set a password for the root account, you need to add it to your /etc/mysql/debian.cnf in cleartext. Maybe you might want to consider this. Better choice would be to create a second privileged user.

Reverse ssh tunnel

My ISP started to roll out broken IPv6 for home users, so my services aren’t available from outside anymore. I don’t need a full vpn solution, but sometimes I just want to ssh home to check a file etc. The simplest solution was to create a reverse ssh tunnel. The raspberry pi inside my home network connects to my public server via ssh. Logged in on the server I can connect to a local port and get forwarded to the raspberry. That works for me really well.

Since wifi is a little bit flaky, I need to make sure, that the ssh connection is reopened when there is a connection loss. You can write a very simple script like this and use a cronjob to execute it.


COUNT=$(ps ax | grep 'ssh -Nf -R' | wc -l)

if [ $COUNT -eq 1 ]
    echo "No tunnel yet. Creating..."
    ssh -Nf -R LOCALPORT:localhost:PORT user@remote
    echo "Tunnel already exists. Aborting."

But I just found out about autossh. Which does the monitoring for you. I tried to get it working with systemd, but without any success. Ideas are welcome.

$ cat /etc/systemd/system/autossh-tunnel.service
Description=reverse ssh tunnel

ExecStart=/usr/bin/autossh -f -M 0 remote -l remoteuser -N -o "ServerliveInterval 60" -o "ServerAliveCountMax 3" -R LOCALPORT:localhost:PORT
ExecStop=/usr/bin/pkill autossh

$ sudo systemctl enable autossh-tunnel.service
$ systemctl start autossh-tunnel.service

Looking at journalctl, I can see the exit but no reason. Executing the command manually works fine.

systemd[1]: Starting reverse ssh tunnel...
systemd[1]: Started reverse ssh tunnel.
autossh[2468]: port set to 0, monitoring disabled
autossh[2474]: starting ssh (count 1)
ssh child pid is 2476
received signal to exit (15)

In the end I modified the bash script to use autossh.


COUNT=$(ps ax | grep 'autossh' | wc -l)

if [ $COUNT -eq 1 ]
  echo "No tunnel yet. Creating..."
  /usr/bin/autossh -f -M 0 remote -l remoteuser -N -o "ServerliveInterval 60" -o "ServerAliveCountMax 3" -R LOCALPORT:localhost:PORT
  echo "Tunnel already exists. Aborting."

If you have a better solution, let me know.

Owncloud: Es gab Probleme mit dem Code – Integritätsprüfung.

Owncloud hat wohl eine Integrationsprüfung für seine Dateien hinzugefügt (mit Version 9.0?). Da ich die util.php aufgrund von abweichenden Zugriffsrechten per Hand anpassen muss, erhalte ich in der Browseransicht die Fehlermeldung. Es funktioniert alles, aber der gelbe Balken stört.

Die Integritätsprüfung lässt sich durch einen Eintrag in der owncloud/config/config.php einfach abschalten.

'integrity.check.disabled' => true,

Anschließend auf der owncloud/index.php/settings/admin#security-warning die erneute Prüfung aktivieren.

Fieser workaround, aber tut was er soll.

SSH-Tunnel mit Firefox nutzen

Kurz notiert:

Ich hatte etwas Probleme bei der Verwendung eines aktuellen Firefox mit einem dynamischen SSH Tunnel. Konnte ich in der Vergangenheit etwa mit dem Befehl

ssh -fNCD 4444 remotesshserver

einen SOCKS Proxy auf Port 4444 aufmachen und Firefox einfach auf diesen umlenken, funktioniert dies wohl aktuell(?) nicht mehr. Richte ich den Proxy in den Einstellungen des Browsers ein (localhost, Port 4444, alle Protokolle, SOCKSv5 etc), kann anschließend keine Verbindung aufgebaut werden. Die selben Daten, konfiguriert in FoxyProxy funktionieren allerdings problemlos.

Hilfreich bei der Fehlersuche:

ssh -N -vvv -D 4444 remotesshserver
curl –socks5

Raspberry Pi: Owncloud setup revisited

The Raspberry and owncloud ran for a few months now and I really enjoyed my own personal cloud. But I was really annoyed by the poor performance. One possible solution was to switch the sd card, which I did. I replaced the Transcend 16GB SDHC card with a 4GB one. Performance is much better now. Since setting up the system is a pretty simple and fast process, I didn’t bother about cloning the card etc. I reinstalled raspbian and followed my own guide on how to setup nginx and php and oriented on my other tutorial on how to install owncloud 6 beta. Of course I needed to change some links etc.

Some more things (I) changed:

  1. owncloud added security for trusted domains
  2. moved owncloud storage to an external usb drive
  3. changed the nginx webserver configuration: restrict to https only and …
  4. accessing php-fpm through network socket


1. If you access the webinterface of your owncloud instance using different ips, names etc., you need to add them to the „trusted_domains“ parameter.

pi@raspberrypi ~ $ sudo vi /var/www/owncloud/config/config.php

‚trusted_domains‘ =>
array (
0 => ‚′,
1 => ‚‚,

2. Connect the usb drive and use lsblk and blkid to find the needed UUID.

pi@raspberrypi ~ $ lsblk && blkid
sda 8:0 0 2,7T 0 disk
└─sda1 8:1 0 2,7T 0 part /media/usb
mmcblk0 179:0 0 3,7G 0 disk
├─mmcblk0p1 179:1 0 56M 0 part /boot
└─mmcblk0p2 179:2 0 3,7G 0 part /
/dev/mmcblk0p1: SEC_TYPE=“msdos“ LABEL=“boot“ UUID=“7D5C-A285″ TYPE=“vfat“
/dev/mmcblk0p2: UUID=“5d18be51-3217-4679-9c72-a54e0fc53d6b“ TYPE=“ext4″
/dev/sda1: LABEL=“Backup3TB“ UUID=“1D3F163D4EEC069E“ TYPE=“ntfs“

Create the mountpoint /media/usb and edit /etc/fstab to mount the drive on startup.

pi@raspberrypi ~ $ sudo mkdir /media/usb

pi@raspberrypi ~ $ sudo vi /etc/fstab
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
UUID=1D3F163D4EEC069E /media/usb ntfs-3g defaults,auto, uid=pi,gid=wwwdata,umask=007,users 0 0

While setting up your owncloud, you can now define /media/usb as your data storage. Not sure if there is a way to change this on a already running owncloud setup.


3. Change the nginx configuration (/etc/nginx/sites-availabe/default) according to the owncloud 6 documentation

upstream php-handler {

server {
listen 80;
return 301$request_uri; # enforce https

# HTTPS server
server {
listen 443 ssl;
server_name localhost;

root /var/www;

autoindex off;
index index.php index.html index.htm;

ssl on;
ssl_certificate /etc/nginx/conf.d/ssl/server.crt;
ssl_certificate_key /etc/nginx/conf.d/ssl/server.key;

client_max_body_size 10G; # set max upload size
fastcgi_buffers 64 4K;

rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;

index index.php;
error_page 403 /core/templates/403.php;
error_page 404 /core/templates/404.php;

location = /robots.txt {
allow all;
log_not_found off;
access_log off;

location ~ ^/(data|config|\.ht|db_structure\.xml|README) {
deny all;

location / {
# The following 2 rules are only needed with webfinger
rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;

rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;

try_files $uri $uri/ index.php;

location ~ ^(.+?\.php)(/.*)?$ {
try_files $1 =404;

include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$1;
fastcgi_param PATH_INFO $2;
fastcgi_param HTTPS on;
fastcgi_pass php-handler;

# Optional: set long EXPIRES header on static assets
location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
expires 30d;
# Optional: Don’t log access to assets
access_log off;

4. Modify the php5-fpm config to listen on a netsocket.

 pi@raspberrypi ~ $ sudo vi /etc/php5/fpm/pool.d/www.conf

;listen = /var/run/php5-fpm.sock
listen =

Restart the services.

pi@raspberrypi ~ $ sudo service php5-fpm restart
pi@raspberrypi ~ $ sudo service nginx restart





QNAP TS419U+ und die Passwortlänge

Wenn man bei Google z.B. nach den Schlagworten „qnap max password length“ sucht, findet man einige Treffer zu Foreneinträgen, in denen sich Besitzer von QNAP Netzwerkspeichern über eine Grenze bei der Passwortlänge ärgern. Anscheinend war es sogar mal so, dass die Firmware, Passwörter, die länger als 16 Zeichen waren, einfach abschnitt ohne den User zu informieren.

(Dieses Vorgehen ist auch schon bei einigen anderen Anbietern aufgefallen. Ich erinnere mich noch an AOL und das Sparkasse Onlinebanking. Allerdings ist das schon einige Jahre her.)

In den offiziellen Foren wird seit langer Zeit (Aus-)Besserung versprochen, jedoch gibt es auch bei der aktuellsten Firmware-Version immer noch ein Limit von 16 Zeichen (siehe Screenshot).

QNAP Passwortlänge


Wie es sich für ein NAS gehört, kann man auf das System auch auf andere Art als über das Webinterface zugreifen, z.B. per SSH. Wer allerdings versucht sich hier mit seinem Benutzernamen und 16stelligen Passwort anzumelden, wird sich wundern warum der Login verweigert wird. Angeblich ist das Passwort falsch. Auch im Systemlog des NAS werden die „failed login attempts“ aufgelistet. Nach einiger Fehlersuche ist die Ursache gefunden:

Als Passwort für den SSH-Zugang sind nur die ersten 12 Zeichen gültig! 

Und das 2014! Oh Man. Dokumentiert wird dies natürlich nirgendwo. Jedenfalls habe ich nichts gefunden.

Facebook kauft WhatsApp

Gestern Abend wurde bekannt gegeben, dass Facebook den Messenger WhatsApp für 19 Milliarden Dollar (ca. 13,8 Milliarden Euro) übernehmen wird.

Aus diesem Grund nochmal der Verweis auf den „sicheren“ Messenger Threema. Mehr Infos und ein interessantes Interview mit den Entwicklern gibt es in einem Podcast bei monoxyd.

Android Version: Play Store
iOS Version: App Store

Raspberry Pi: Selfhosted cloud with ownCloud 6 beta

Quick writeup on how to install the new owncloud 6 beta on your raspberry Pi.

Disclaimer: If you want something superfast, leave this site now. If you’re looking for a really cheap way to get your own cloud (No NSA. So yay!) and give some use to your raspberry pi which is sitting on the shelf since months, here you go. Just don’t expect a 1 to 1 dropbox/drive/$whatever clone.

Prequirements: Working Raspberry Pi with Raspbian (path etc. may vary on other distributions) and a running webserver with php and ssl.

Installation on the Pi
Download the package from here, extract it, move it to the right location and set the correct user rights:

pi@raspberrypi ~ $ wget
pi@raspberrypi ~ $ unzip
pi@raspberrypi ~ $ sudo mv owncloud /var/www/
pi@raspberrypi ~ $ sudo chown -R www-data:www-data /var/www/owncloud
pi@raspberrypi ~ $ cd /var/www/owncloud/

We need to change a few settings in the php config.

pi@raspberrypi /var/www/owncloud $ sudo vi /etc/php5/fpm/php.ini


upload_max_filesize = 2M
post_max_size = 8M


upload_max_filesize = 1024M
post_max_size = 1024M

and add some lines to the end of the file (we will install apc later):

upload_tmp_dir = /srv/www/owncloud/data/temp
extension =
apc.enabled = 1
apc.include_once_override = 0
apc.shm_size = 256

Create the directory for uploads

pi@raspberrypi /var/www/owncloud $ sudo mkdir -p data/temp
pi@raspberrypi /var/www/owncloud $ sudo chown -R www-data:www-data data

After editing your webserver config according to the documentation, visit http://localhost/owncloud or http://raspberryip/owncloud and check for error messages. In my case, I got two:

1. PHP module GD is not installed. Please ask your server administrator to install the module.

So I needed to install this:

pi@raspberrypi /var/www/owncloud $ sudo aptitude install php5-gd


2. No database drivers (sqlite, mysql, or postgresql) installed.

Of course. After some searching and reading the official documentation about the database configuration, I decided to use MySQL as backend. Mainly because there will be at least two persons using the system. So I installed the mysql-server and php5-mysql package.

pi@raspberrypi /var/www/owncloud $sudo aptitude install mysql-server php5-mysql

After settings the root password, connect to your mysql server. Create a user for owncloud and a database.

pi@raspberrypi /var/www/owncloud $ mysql -u root -h localhost -p
CREATE USER ‚owncloud’@’localhost‘ IDENTIFIED BY ‚password‘;
GRANT ALL PRIVILEGES ON owncloud.* TO ‚owncloud’@’localhost‘ IDENTIFIED BY ‚password‘;

Return to http://localhost/owncloud or http://raspberryip/owncloud and complete the setup process.

Some tips to improve performance:
There are a few guides and tips on the net on how to improve performance of owncloud on your pi. Here are some of them.

1. Install the PHP Accelerator (see modified php.ini at the top)

pi@raspberrypi /var/www/owncloud $ sudo aptitude install php-apc

2. Use a cronjob to update the database and fasten up the webinterface. Open the crontab for the webserver user:

pi@raspberrypi /var/www/owncloud $ sudo crontab -u www-data -e

For updates every 15 minutes add:

*/15 * * * * php -f /var/www/owncloud/cron.php

On the webinterface go to Administration -> Cron and change the setting to Cron.

3. Disable unused apps. Disable all apps you don’t need.


Installation of the owncloud ubuntu client

pat@think:~$ wget
pat@think:~$ sudo apt-key add Release.key
pat@think:~$ echo ‚deb /‘ >> sudo tee /etc/apt/sources.list.d/owncloud-client.list
pat@think:~$ sudo aptitude update
pat@think:~$ sudo aptitude install owncloud-client

Sources: (german) (german)

Raspberry Pi: Mount and unmount truecrypt on startup and shutdown

My Raspberry Pi functions as a lokal NAS and data haven for backing up remote servers and all my clients. The data is stored in a truecrypt container on an external usb harddrive. The drive is mounted on bootup, as well as the decrypted container. If you follow my notes, please be aware that the password to unlock the files is stored in cleartext in the automount script and could show up when running e.g. ps. So maybe this isn’t the right solution when you grant access to your Pi to other people.


Create the two directories to mount the external harddrive and the truecrypt container.

sudo mkdir /mnt/{usb,truecrypt}

If you use NTFS as a filesystem on your external drive, install the ntfs-3g package and try mounting the it manually first:

pi@raspberrypi ~ $ sudo aptitude install ntfs-3g
pi@raspberrypi ~ $ mount -t ntfs-3g /dev/sda1 /mnt/usb

When everything works, add the permanent mount entry to your /etc/fstab:

/dev/sda1 /mnt/usb ntfs-3g defaults 0 0

To automount the truecrypt container on startup, install truecrypt like explained here and create the two init scripts for mounting and unmounting the container.


# Provides:          tc_mount
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2
# Default-Stop:
# Short-Description: tc_mount
# Description:      Mount the truecrypt container
echo „Mounting truecrypt container“
/usr/local/bin/truecrypt -t -k „“ –protect-hidden=no –mount /mnt/usb/crypt /mnt/truecrypt/ -v -m=nokernelcrypto -p ‚YOURPASSWORD‘
exit 0


# Provides:          tc_unmount
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:
# Default-Stop:      0 1 6
# Short-Description: tc_unmount
# Description:       Unmount the truecrypt container
echo „Unmounting truecrypt containers“
/usr/local/bin/truecrypt -d
exit 0

And add them to the correct runlevels:

pi@raspberrypi ~ $ sudo update-rc.d tc_mount start 02 2 .
pi@raspberrypi ~ $ sudo update-rc.d tc_unmount stop 02 0 1 6 .