A Security Audit on My Own Machine — And What It Revealed

Author: Hani Esmael
Date: May 24, 2026
There is a habit I have developed working in information security: I do not assume something is fine just because nothing has gone wrong yet. That is not caution — it is discipline. And it applies to my own devices just as much as it applies to the systems I professionally oversee.

So this weekend, I ran a formal security scan on my personal laptop. Not because I suspected a problem. Because I wanted to know the truth about what was actually running on my own machine.

What I found was instructive — not catastrophic, but meaningful. A risk score of 16, rated Elevated. Findings across two High and three Medium categories. Things that had accumulated quietly over time, not through negligence, but through the simple reality that modern systems carry more complexity than most people realize.

This post documents what I found, what I did about it, and what it means — for anyone running Linux personally, and for anyone in a leadership or governance role who wants to understand what this kind of audit actually looks like in practice.

The scanner I used is LinuxShield — a tool I built for exactly this purpose. It runs entirely on your machine, sends nothing anywhere, and produces a prioritized risk score with actionable findings. Everything in this post came from a single scan.

Before we get into findings

For those in governance or leadership roles reading this: what I am doing here is a configuration audit. It maps directly to what frameworks like NIST CSF 2.0, CIS Controls, and ISO 27001 require organizations to perform formally. The difference between what I did on a Saturday afternoon and what a security team documents in an enterprise audit is scale — not methodology.

The starting point

Risk Score: 16 — Elevated
Critical:  0
High:      2
Medium:    3
Low:       0
Pass:      9

Elevated does not mean actively compromised. It means the attack surface — the number of ways something could go wrong — is larger than it needs to be. In security, unnecessary surface area is unnecessary risk. The goal is to reduce it deliberately, not reactively.

Finding 1 — Legacy Remote Services (High)

The first High finding flagged something called legacy r-services. To understand why this matters, a brief history is useful.

In the early days of networked computing, Unix systems communicated using a set of remote access tools — rsh, rlogin, rexec — built for convenience in a time when security was not the primary concern. These tools transmit credentials in plain text and authenticate based on network address trust rather than cryptographic keys. They were formally superseded by SSH.

Finding them flagged on a modern machine is like discovering an unlocked side door that was supposed to have been removed during a renovation.

The first step was to verify whether these services were actually listening on the network:

bash

# Check for activity on r-service ports — exact match only
ss -tlnp | awk 'NR==1 || $5 ~ /:(512|513|514)$/'

Nothing was listening. But a package called inetutils — which bundles these legacy tools among others — was installed on the system. Before removing any package, the right practice is to check whether anything else depends on it:

bash

pacman -Qi inetutils | grep -E 'Required By|Optional For'

The result: Required By: None. Safe to remove.

bash

sudo pacman -Rs inetutils

One practical note worth documenting: inetutils also provides a utility called hostname, which the LinuxShield scanner itself calls internally. Removing the package caused the scanner to produce errors on the next run. This is a good reminder that remediation decisions have dependencies — in this case, a minor one, but worth knowing.

Finding 2 — Privileged Binaries (High)

This finding requires the most explanation, because it is the one most likely to cause alarm without context.

Linux uses a permission system to control what programs can do and who can run them. A special permission called SUID allows a program to run with the privileges of its owner — typically the system administrator — regardless of who actually executes it. This is how essential tools like sudo, passwd, and su function. They need elevated access to do their jobs. SUID, in those cases, is by design.

The security concern is this: any program with SUID privileges that contains a vulnerability becomes a potential path to full system access. So security scanners flag every SUID binary and ask the administrator to review the list. The scanner does not know which ones are legitimate. That judgment requires a human.

bash

# List all SUID and SGID binaries on the system
find / -perm /6000 -type f 2>/dev/null

The scan returned 30 flagged binaries. After reviewing each one:

BinaryPurposeDecision
sudo, su, passwd, chfn, chsh, newgrpCore authenticationRetain
mount, umount, fusermount3Filesystem operationsRetain
nvidia-modprobeGPU driverRetain
VBoxHeadless, VBoxNetAdpCtl and relatedVirtualization networkingRetain
chrome-sandbox variants (Brave, Vivaldi, Signal, Electron)Browser process isolationRetain
pkexecDesktop environment privilege managementRetain
cdda2wav, cdrecord, readcd, rscsiOptical disc tools — not in useRemove privilege
ksuKerberos authentication — not in useRemove privilege
mail-dotlockLocal mail delivery — not in useRemove privilege
wall, writeTerminal messaging — relevant only on shared serversRemove privilege
Removing the elevated permission from unused binaries:

bash

sudo chmod u-s /usr/bin/cdda2wav
sudo chmod u-s /usr/bin/cdrecord
sudo chmod u-s /usr/bin/readcd
sudo chmod u-s /usr/bin/rscsi
sudo chmod u-s /usr/bin/ksu
sudo chmod u-s /usr/lib/mail-dotlock

# wall and write use a group-level privilege bit, not a user-level one
sudo chmod g-s /usr/bin/wall
sudo chmod g-s /usr/bin/write

After cleanup, save a documented baseline:

bash

find / -perm /6000 -type f 2>/dev/null | sort > ~/suid_baseline.txt

This file becomes your reference point. Any new entry that appears in a future scan and is not on this list warrants immediate investigation.

The binaries that remain — sudo, browser sandboxes, virtualization tools — represent what governance practitioners call accepted residual risk. The risk is known, the justification is documented, and the decision is deliberate. That is categorically different from an ignored finding.

Finding 3 — SSH Configuration (Medium)

SSH is the protocol used to access Linux systems remotely. Two configuration settings were absent that meaningfully reduce exposure to automated login attacks.

Open the SSH configuration file:

bash

sudo nano /etc/ssh/sshd_config

Add the following:

MaxAuthTries 3        # terminate the session after three failed login attempts
LoginGraceTime 30     # disconnect any session that does not authenticate within 30 seconds

Apply the change:

bash

sudo systemctl restart sshd

These two settings disrupt the most common automated brute-force approach: rapid, repeated login attempts over a persistent connection. Neither setting affects normal use. Both close a gap that has no reason to exist.

Finding 4 — World-Writable Files (Medium)

Eight files on the system carried world-write permissions — meaning any user account on the machine could modify them. Most were debug symbol files associated with a ThinLinc remote desktop installation, likely set incorrectly during software packaging.

bash

# Correct the HP printer state file
sudo chmod o-w /var/lib/hp/hplip.state

# Correct the ThinLinc debug files
sudo chmod -R o-w /opt/thinlinc/lib/tlclient/lib/.build-id/

# Confirm nothing remains
find /var/lib/hp /opt/thinlinc/lib/tlclient/lib/.build-id/ -perm -o+w 2>/dev/null

o-w removes write access from all other users. -R applies that change to every file within the specified directory. The verification command should return nothing if the corrections took effect.

Finding 5 — Open Network Ports (Medium)

The scanner flagged ten listening ports. A full audit of each one:

PortServiceAssessment
127.0.0.1:631CUPS print service — local onlyNo action needed
127.0.0.53:53systemd DNS resolver — local onlyNo action needed
100.120.x.x:42888Tailscale VPNNo action needed
*:1716KDE ConnectNo action needed
0.0.0.0:5355LLMNR — legacy name resolutionDisable
Nine of the ten ports are legitimate and expected for this system's configuration. The one that warrants action is port 5355, used by a protocol called LLMNR.

LLMNR — Link-Local Multicast Name Resolution — is a legacy protocol designed to resolve hostnames on local networks without a central DNS server. It has a well-documented vulnerability: an attacker on the same network can respond to LLMNR broadcast queries and intercept authentication credentials. This attack class, known as LLMNR poisoning, is a standard technique in network penetration testing precisely because it works reliably against systems that have not disabled it.

On a personal laptop, there is no operational need for LLMNR. Disabling it removes the exposure entirely.

bash

# Edit /etc/systemd/resolved.conf — under the [Resolve] section
LLMNR=no
MulticastDNS=no

On systems where NetworkManager controls per-interface network settings, an additional override is required:

bash

# Create /etc/NetworkManager/conf.d/llmnr.conf and add:
[connection]
connection.llmnr=no

bash

sudo systemctl restart systemd-resolved
sudo systemctl restart NetworkManager

The result

Risk Score: 12 — Moderate
Critical:  0
High:      1
Medium:    1
Low:       0
Pass:      11

The score moved from 16 to 12. More importantly, every remaining finding is now understood, justified, and documented. The residual High is the privileged binary list — which has been fully audited. The residual Medium is the open ports list — which has been fully explained.

A score of 12 with documented justifications is a stronger posture than a score of 8 with unknown residuals. The number matters less than the clarity behind it.

Building ongoing monitoring

LinuxShield tells you the state of your system at the moment you run it. That is the audit. What you need beyond that is continuous watch — something running between scans that catches what changes after you have already cleaned things up.

Three tools cover that gap. They do not replace LinuxShield — they extend it into the space between runs:

ClamAV handles malware detection. It is the standard open-source antivirus for Linux systems.

bash

sudo pacman -S clamav
sudo freshclam                       # update signature database
sudo clamscan -r /home -i --quiet    # scan home directory, report infections only

rkhunter scans for rootkits and known local exploits — attack tools that attempt to hide their presence on a compromised system.

bash

sudo pacman -S rkhunter
sudo rkhunter --update
sudo rkhunter --check

AIDE provides file integrity monitoring. It takes a snapshot of your filesystem at a known-good state and alerts you when anything changes unexpectedly. If a system binary is modified — by an attacker, by a misconfigured update, by anything — AIDE will surface it.

bash

sudo pacman -S aide
sudo aide --init
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
sudo aide --check    # run periodically or schedule via cron

Together, these three tools provide detection capability between formal scans. That is the difference between a snapshot and a posture.

What this maps to in governance terms

For those reading this from a governance, risk, or leadership perspective, the activities in this post correspond directly to formal control requirements:

ActivityNIST CSF 2.0 FunctionControl Reference
Running a vulnerability scan and reviewing findingsIdentifyID.RA — Risk Assessment
Removing unnecessary services and packagesProtectPR.PS-01 — Secure Configuration
Stripping unnecessary elevated permissionsProtectPR.AA-05 — Least Privilege
Establishing a baseline and enabling monitoringDetectDE.CM — Continuous Monitoring
Documenting risk acceptance decisionsGovernGV.RM — Risk Management
This is not a coincidence. The principles that underpin enterprise security programs are not invented for organizations — they reflect sound practice at any scale. What changes with scale is formality, tooling, and the number of systems in scope. The reasoning does not change.

Security is not a product you purchase or a certification you achieve. It is a practice you maintain — one deliberate decision at a time, documented, reviewed, and revisited. What I did here on a Saturday afternoon is, at its core, the same thing I would expect any well-run organization to do continuously.

The only difference is I did mine before something went wrong.

References

© 2026 Hani Esmael / EFHorizons / EsmaelNexusX. All rights reserved.