From the Rubble | Digital Sovereignty Series | Episode 2

TLDR: A fresh Linux install isn’t a hardened Linux install. Out of the box, your firewall has ports open you don’t know about, KDE Connect is silently holding network connections in your user session, and your DNS queries are being logged by your ISP. This is the first-boot checklist: updates, firewall audit, finding what’s actually listening on your network, disabling what shouldn’t be there, setting DNS privacy at the router level, and verifying LUKS encryption is enabled. Takes under an hour. Covers the gaps the install guide skipped.

series: [“Digital Sovereignty”]

You’ve got a fresh Linux install. Feel good about it for exactly five minutes.

Then open a terminal and find out what’s actually running on your machine.

This is the step most Linux tutorials skip - they get you through the install, point you at the app store, and send you on your way. What they don’t tell you is that a default Linux install, even a privacy-focused one, ships with some doors open that you probably want closed. Not because the distribution is malicious. Because defaults are designed for convenience, and convenience and security are usually pulling in opposite directions.

This episode is the first boot checklist I wish someone had handed me. It’s not exhaustive - hardening is a spectrum and you can go as deep as your threat model requires. This is the baseline: the things everyone should do before they start treating a new Linux machine as a trusted daily driver.

series: [“Digital Sovereignty”]

Step 1: Update Everything Before You Do Anything Else

Fresh installs are never fully current. Packages have been updated since the image was built. Some of those updates are security patches. Do this first, before anything else.

On Bazzite and Aurora (and any Universal Blue derivative), the update command is:

ujust update

This handles both the system image and your Flatpak applications in one pass. On a traditional Fedora system you’d run sudo dnf update. Either way - updates first, everything else second.

Reboot after. Start clean.

series: [“Digital Sovereignty”]

Step 2: Check What’s Listening on Your Network

This is the one that surprises people.

Run this command:

ss -tulnp

What you’re looking at is every process on your machine that’s currently listening for network connections - open ports, what’s using them, whether they’re exposed on all interfaces or just locally.

On a fresh install you’ll likely see a handful of expected entries: the system’s mDNS responder, maybe a CUPS print service, a few localhost-only connections. These are generally fine.

What you’re looking for is anything listening on 0.0.0.0 or ::: - which means “any interface,” including your network-facing interfaces. Those are ports that could potentially be reached from other devices on your network, or from the internet if your firewall has a gap.

Write down or screenshot what’s running before you change anything. You want a baseline so you know what you’ve got.

series: [“Digital Sovereignty”]

Step 3: Check and Configure Your Firewall

Bazzite and Aurora both ship with firewalld - a solid, well-maintained firewall. The question is what it’s configured to allow by default.

Check the active zone and what’s permitted:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

The default zone is typically FedoraWorkstation, which allows a few services by default. Some of those you want. Some you should look at critically.

To see what services are allowed:

sudo firewall-cmd --zone=FedoraWorkstation --list-services

Common entries you’ll see: dhcpv6-client (needed for IPv6 addressing), mdns (local network discovery), ssh (remote access - disable if you’re not using it), and potentially others depending on what you’ve installed.

To remove a service you don’t need:

sudo firewall-cmd --zone=FedoraWorkstation --remove-service=ssh --permanent
sudo firewall-cmd --reload

The --permanent flag makes the change persist across reboots. Always follow with --reload to apply immediately.

If you’re not sure whether you need a service, disable it and see if anything breaks. That’s a safer default than leaving things open because you’re not sure.

series: [“Digital Sovereignty”]

Step 4: The KDE Connect Situation

Here’s the one that got me.

KDE Connect is a genuinely useful tool - it lets your phone and your Linux desktop communicate. Share files, sync notifications, use your phone as a remote control. Legitimately useful software.

It also opens ports on your machine by default. And here’s the part that’s easy to miss: on some configurations, KDE Connect runs as a user process, not a system service. That means it might not show up obviously when you’re looking at system-level processes. It’s running in your user session, quietly holding ports open for device discovery.

Run ss -tulnp again after you’ve been logged in for a few minutes and compare to your first run. If KDE Connect is installed and running, you’ll see it appear.

If you’re not using KDE Connect - and most people aren’t, because most people don’t know it exists - disable or remove it:

# Check if it's running
systemctl --user status kdeconnect

# Disable it from starting automatically
systemctl --user disable kdeconnect
systemctl --user stop kdeconnect

Or uninstall it entirely if you have no use for it:

# On Fedora-based systems
sudo dnf remove kdeconnect

On immutable systems like Bazzite/Aurora, if it’s part of the base image you may need to mask it rather than remove it:

systemctl --user mask kdeconnect

The broader lesson: check your user-level services too, not just system-level ones. Things running in your user session can open network ports just as effectively as system services.

# See all user-level services and their status
systemctl --user list-units --type=service --state=running

series: [“Digital Sovereignty”]

Step 5: Set Your Hostname

Default hostnames are often something generic - fedora, bazzite, or a random string. Your hostname broadcasts on your local network and shows up in router logs, mDNS announcements, and anywhere else your machine identifies itself.

Set something deliberate:

sudo hostnamectl set-hostname yourhostname

Pick something that identifies the machine to you without being personally identifying to anyone else who might see it on a network. kyle-laptop is convenient but broadcasts your name. workstation-01 or something similarly neutral is cleaner.

series: [“Digital Sovereignty”]

Step 6: DNS Privacy at the Router Level

This is where a lot of people stop short. They install a VPN or change their browser’s DNS settings and consider it handled. It isn’t.

Every device on your network - phone, tablet, smart TV, the laptop you didn’t configure - makes DNS queries. DNS queries are how your network translates google.com into an IP address. By default, those queries go to your ISP’s DNS servers. Your ISP logs them. They know every domain you’ve resolved, timestamped, tied to your account.

The fix that actually covers everything is changing the DNS server at your router level, not just on individual devices.

Quad9 (9.9.9.9) is the recommendation I landed on. It’s operated by a Swiss nonprofit. It blocks known malicious domains. It doesn’t log personally identifying information. It doesn’t have a surveillance business model. There are other solid options - Mullvad DNS, NextDNS, Cloudflare 1.1.1.1 - each with their own tradeoffs. Quad9 hits the sovereignty filter well.

How you change this depends on your router. Generally:

  1. Log into your router admin panel (usually 192.168.1.1 or 192.168.0.1)
  2. Find DNS settings - often under WAN settings or DHCP settings
  3. Set primary DNS to 9.9.9.9, secondary to 149.112.112.112 (Quad9’s secondary)
  4. Save and apply

Every device on your network now resolves DNS through Quad9 without any per-device configuration. Clean, network-wide coverage.

For deeper DNS privacy, look into DNS-over-HTTPS or DNS-over-TLS - both encrypt your DNS queries so even your ISP can’t read them in transit. That’s a slightly more involved setup and worth a dedicated episode. Quad9 at the router level is the solid baseline.

series: [“Digital Sovereignty”]

Step 7: Full-Disk Encryption

If you’re setting up a new machine, enable LUKS encryption during the install process. Both Bazzite and Aurora offer this as a checkbox during setup - take it.

LUKS encrypts your entire drive. If your laptop is lost or stolen, the data is inaccessible without the passphrase. It’s not a performance hit on modern hardware. It’s table stakes for any machine that leaves your home.

If you’ve already installed without encryption, the practical path is to reinstall with it enabled. Retrofitting full-disk encryption onto an existing install is possible but complicated. Easier to do it right from the start.

Your encryption passphrase should be strong and stored somewhere you control - a Bitwarden vault, not a sticky note.

series: [“Digital Sovereignty”]

Step 8: Verify After You’re Done

After you’ve worked through the checklist, run through the verification pass:

# Confirm firewall is active and configured correctly
sudo firewall-cmd --list-all

# Confirm what's listening - should be a shorter, understood list now
ss -tulnp

# Confirm user services - nothing unexpected running
systemctl --user list-units --type=service --state=running

# Confirm hostname is set correctly
hostnamectl

Compare against your baseline from Step 2. Every entry in the current output should be something you recognize and understand. If something’s there that you can’t account for, dig into it before you move on.

series: [“Digital Sovereignty”]

The Mindset Behind This

There’s a version of security theater where you go through the motions of hardening a system to feel better about it without actually understanding what you changed or why. That’s not the goal here.

The goal is to understand your attack surface - what’s exposed, what’s running, what’s reachable - and make deliberate decisions about each piece. Some things you’ll leave open because they serve a purpose. Some things you’ll close because they don’t. The point is that you chose, based on understanding, rather than leaving it to whatever the defaults happened to be.

This is the same frame as health sovereignty: you don’t accept a system’s default settings for your body without understanding what those defaults are optimizing for. You don’t accept a system’s default settings for your machine either.

Defaults serve the system’s purposes. Hardening serves yours.

series: [“Digital Sovereignty”]

The Checklist (Quick Reference)

For the people who want the short version to run through:

  • Run system updates (ujust update or sudo dnf update) - reboot after
  • Audit running network services (ss -tulnp) - document baseline
  • Check firewall configuration (sudo firewall-cmd --list-all)
  • Remove unnecessary firewall exceptions
  • Check for KDE Connect and disable/remove if not using it
  • Check user-level running services (systemctl --user list-units --type=service --state=running)
  • Set a deliberate hostname (sudo hostnamectl set-hostname)
  • Change router DNS to Quad9 (9.9.9.9 / 149.112.112.112)
  • Verify LUKS encryption is enabled (reinstall if not)
  • Run verification pass - compare to baseline

series: [“Digital Sovereignty”]

Resources

  • Quad9 DNS: quad9.net - Swiss nonprofit, privacy-respecting, malware-blocking DNS
  • firewalld documentation: firewalld.org - full reference for firewall management
  • ss command reference: man ss in your terminal - everything the tool can show you
  • KDE Connect: kdeconnect.kde.org - if you do want to use it, the docs are solid
  • LUKS encryption overview: gitlab.com/cryptsetup/cryptsetup

series: [“Digital Sovereignty”]

Next episode: Your OS is locked down. Now your files need a sovereign home. Filen - end-to-end encrypted sync, zero-knowledge cloud storage, and getting your Obsidian vault off Google’s servers.

series: [“Digital Sovereignty”]

From the Rubble is written by Kala - veteran, 30-year conspiracy realist. Digital sovereignty, health sovereignty, and the overlap between them. No corporate funding. No ads. No permission required.