If you run a rsyslog server using the rsyslog imtcp module with OpenSSL or GnuTLS enabled for encrypted communication support, chances are, as your infrastructure and/or log traffic grow, you will find out, that for TLS offloading, rsyslog is only able to use one thread of your multithreaded system. This is by design and until today, the imtcp module, which is also the only module supporting TLS, is not able to utilize multiple CPUs.
The imptcp, also known as plaintext-tcp module however, does support multiple threads, but cannot do any encryption.
In my case, I found that the only viable solution to multithreaded TLS offloading with rsyslog is to wrap stunnel in front of it, like this in /etc/stunnel/rsyslog-server.conf:
Continue reading Set up an rsyslog server with multithreaded TLS encryption using stunnel
Recently, I found myself in the situation of having to undergo a large-scale recovery operation on a 15-year-old hard drive with a total runtime of nearly 70,000 hours. The drive had long suffered from numerous defective sectors and reading errors.
The specific hard drive model in question was the SAMSUNG HD501LJ, a contemporary model widely used in systems of that time. It was later replaced by 750GB and 1TB models in the following years before the hard drive division of SAMSUNG was partially acquired by Seagate in 2011.
The task at hand was not an easy one, as it involved:
Continue reading Data recovery from defective storage media using ddrescue and photorec
- Safeguarding and reading as many data as possible.
- Making existing data available on the file systems.
- Locating and making available previously deleted data from the distant past.
- If feasible, writing the data onto a new storage medium of equal or greater size to restore the original system.
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.
Continue reading Compile HAProxy 2.8 with OpenSSL 3.0 and enable weak ciphers and protocols
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.
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:
Continue reading How I run small websites in Docker-containers separated from each other on a small VPS
- easy to handle (upgrades, PHP-version switching etc.)
- efficient (especially towards RAM usage)
- easily migrateable to a different machine
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.)