Welcome to ShieldedBytes, where cybersecurity meets clarity. This blog offers practical insights, best practices, and in-depth discussions to help you navigate the ever-evolving digital landscape securely.
Explore topics like data protection, network defense, secure coding, and more—all tailored for professionals seeking reliable, actionable advice.
Start exploring, stay informed, and take control of your digital security.
When Docker runs on a modern Linux distro, every container start, stop, or health‑check event is logged by the Docker daemon (dockerd). Those logs are forwarded to systemd‑journal, which is great for auditability but can quickly flood the journal with repetitive, low‑value messages. On a busy host a single day of activity can generate several megabytes of journal data, making it hard to spot real issues and bumping disk usage.
A 2 GB VPS is a tight budget. Every megabyte counts, and swap files that never get freed can silently eat the space you need for logs, containers, or backups. This post walks through how to find those orphaned swap files, safely remove them, and set up a swap strategy that keeps the system lean and secure.
[Read More]Running a lightweight NFS server on a Raspberry Pi or a small Ubuntu Server is a common way to share media or backups.
The problem? A mis‑configured export table can let a client mount a directory that was never meant to be exposed. The server happily replies “yes”, so the admin might not notice until a log entry pops up or a backup job starts to fail.
Running containers as a non‑root user is a solid first line of defense, but it’s not a silver bullet. A mis‑configured image, a vulnerable app, or a simple oversight can still let a container touch /etc, /var, or even your own home directory. This post walks through the hardening steps that keep file writes strictly inside a rootless runtime’s writable layer.
Rootless mode is all about user namespaces. The container’s root (uid 0) gets mapped to a non‑root UID on the host, and the kernel enforces that the process can only see files that belong to that UID. The catch is that the mapping is per‑process, not per‑filesystem. If a container mounts a host directory or a volume, the process inside can write to it unless the mount options explicitly deny it.
When a machine plugs into a VPN it usually needs to look up hostnames that live only inside that tunnel.
If you let the whole system talk to the same nameserver, two things can go wrong:
Binding a dedicated DNS server to the VPN link keeps the resolver stack tidy, cuts the attack surface, and stops accidental leaks.
[Read More]When a typo in /etc/fstab stops the root filesystem from mounting, Ubuntu 24.04 drops straight into emergency mode. You get a read‑only root shell, but that’s not useful because you can’t edit the offending line—root is already mounted read‑only. The usual fix is to reboot, pull out a live USB, and patch the file from there.
There’s a much quicker way that keeps you on the same machine, preserves the state, and lets you fix the problem in place.
When you need a user to read system logs but you don’t want to give them sudo or pull them into a privileged group, POSIX ACLs are the cleanest way to do it.
They let you hand out read rights on a per‑file or per‑directory basis, and you can set defaults so that every new file inherits the same restrictions.
A backup account that pulls logs to an off‑site archive but never touches the live system is the classic case. ACLs keep the principle of least privilege intact while still letting the job run unattended.
[Read More]Rootless Podman on a Raspberry Pi – Solving the “Cannot Bind Mount /home/user/data” Permission Issue
The Raspberry Pi has become a favorite platform for home‑lab enthusiasts, and Podman’s rootless mode lets you run containers without granting the container process full system privileges.
On a Pi running Raspberry OS Bookworm (Debian 12), a common stumbling block is the error
Error: cannot bind mount /home/user/data: permission denied
when you try to persist data with -v /home/user/data:/data.
Below is a step‑by‑step guide that explains why the error happens, how to fix it, and what security trade‑offs you should be aware of.
Syslog is the first place you look when something goes wrong. In a busy server or a home lab, the same message can appear thousands of times a day. Knowing which lines dominate the log helps spot misconfigurations, repeated failures, or malicious activity that repeats silently. A quick frequency count is a low‑overhead sanity check that can turn a noisy log into a focused list of suspects.
[Read More]A home NAS is usually a single‑disk or a small RAID array.
When you run several containers—media servers, databases, CI runners—each one writes a JSON log file under
/var/lib/docker/containers/<id>/<id>-json.log.
If you leave the default json-file driver untouched, those files grow indefinitely.
On a 1 TB NAS, a handful of containers can fill the drive in weeks, forcing you to delete data or upgrade hardware.