Practical experiences from every day IT

Author: Malte

  • Compile HAProxy 2.8 with OpenSSL 3.0 and enable weak ciphers and protocols

    Compile HAProxy 2.8 with OpenSSL 3.0 and enable weak ciphers and protocols

    I was recently tasked with setting up a test environment to verify if it is possible to run the latest HAProxy with an up-to-date OpenSSL version and still support DES ciphers such as DES-CBC3-SHA.

    (more…)

  • Nextcloud: The “X-Frame-Options” HTTP header is not configured as “SAMEORIGIN” (even if it is)

    An interesting anecdote from my work with Nextcloud. In the backend, they offer a “Security- and configuration check” which proposes some tips and recommendations to take with your Nextcloud server instance.

    After completing all tasks listed, one persisted:

    The “X-Frame-Options” HTTP header is not configured as “SAMEORIGIN”. This is a potential security or privacy risk, and we recommend changing this setting.

    Nextcloud Admin Backend -> Overview

    As this is an easy check, I opened the developer console of my browser and checked if the header was set. And it was. Weird? At that point, I was pretty certain that something with the detection of that header was wrong, but I could not point it out immediately.

    After researching online and fiddling with this for at least an hour, likely more, I decided to utilize the scan.nextcloud.com security scanner to ensure the warning is also shown there. Now the fun part: The scanner showed the warning too, but with cached data from last year. After re-scanning and getting an A+ on the scanner, the warning also disappeared in the Nextcloud backend.

    Likely the Nextcloud backend check relies on the same dataset that scan.nextcloud.com uses and by re-doing the security check manually on scan.nextcloud.com, the warning disappeared. No need to fiddle with any webserver-configs, since Nextcloud in all newer versions sets the X-Frame-Options header correctly by itself.

  • How I run small websites in Docker-containers separated from each other on a small VPS

    Since I rarely give insights on how websites such as this one are run, I decided it would be a great time to share one very simplistic and efficient approach to host several small websites, separated from each other, on a cheap VPS.

    When we talk websites, I mean WordPress instances. WordPress has a few basic requirements:

    • the PHP scripting-language
    • a MySQL database
    • possiblity to use sendmail or a similar software to send mails

    To achieve these basic requirements, I employ:

    • one docker-compose stack bundling the MySQL-database as well as the phpMyAdmin-webinterface
    • multiple docker-compose stacks bundling PHP-FPM, nginx as well as exim4 to act as a mailrelay
    • one nginx instance on the VPS (uncontainered as of now) that does the SSL-offloading and acts as a reverse proxy in front of the different docker-compose stacks for WordPress

    The setup is:

    • simple
    • easy to handle (upgrades, PHP-version switching etc.)
    • efficient (especially towards RAM usage)
    • easily migrateable to a different machine
    (more…)

  • cryptsetup “No key available with this passphrase.” even though you are 100% certain its the right key (Debian Buster)

    Something I stumbled upon today. I tried to unlock a LUKS container and was 100% certain that the passphrase is correct. Still, cryptsetup would not unlock the container:

    # cryptsetup luksOpen /container_file container
Enter passphrase for /container_file: 
No key available with this passphrase.

    Digging around, references can be found to either a problem with the character encoding of the shell or to a bug with cryptsetup and Samsung EVO SSDs with certain older 5.1 kernels. None of these were the case.

    After some trial and error, I upgraded the cryptsetup packages from 2:2.1.0-5+deb10u2 (from buster/main repo) to 2:2.3.5-1~bpo10+1 (buster-backports/main repo). Suddenly the container would unlock.

    I think most of the time people either get their passphrase wrong or their header was corrupted somehow, but in this case: Some bug in cryptsetup. (Not reported yet, no existing report found yet.)

  • Sync time on Linux via GSM

    The RaspberryPi and many similar single-board computers do not have an RTC or “Real Time Clock” and without internet connectivity cannot retain their time setting. Therefore most RaspberryPi Linux-distributions employ NTP to sync the time right after boot. If you are not able to use an internet connection and therefore no NTP, but have a GSM modem or phone and a valid sim card at hand, this guide may be suitable for your needs.

    (more…)

  • Change Plesk spam-settings in bulk

    Since Plesk per default uses the static userdb-driver of Dovecot, it may seem difficult to easily iterate through all mailboxes on the server, for example in order to change the spam-settings of all mailboxes on the systems at once while keeping the “individual settings per-mailbox” functionality enabled.

    The following one-liner may be helpful in such case:

    while read domain; do (while read user; do plesk bin spamassassin --update $user@$domain -status true -personal-conf true -action move -hits 6; done < <(ls -1 /var/qmail/mailnames/$domain)); done < <(ls -1 /var/qmail/mailnames/)

    In this case, the domains and mailboxes are placed in/var/qmail due to a previous upgrade from qmail to Dovecot. If the directory in your case differs, make sure to change it in the one-liner, too.