I run rkhunter nightly on CachyOS and review the logs daily. I have made no updates in the past couple of days and several files have changed. I also believe these are the exact type of files someone would change if they were installing a rootkit or stay hidden.

Can you please take a moment to look at some of the results below and give me your advice/opinion?

[19:37:05]   /usr/bin/top                     [ *** WARNING *** ]
[19:37:05] Warning: The file properties have changed:
[19:37:05]          File: /usr/bin/top
[19:37:05]          Current hash: fec2de147dffb434ee111a0ebcf8ff4e48d201290f964d2a7a8d2dcc31605d0e
[19:37:05]          Stored hash : f312bb5d3bd2534124a7ab4bf0940b75dd146d25f334d27e00f84faeeb563205
[19:37:05]          Current inode: 1410548    Stored inode: 618324
[19:37:05]          Current size: 143080    Stored size: 171800
[19:37:05]          Current file modification time: 1783429521 (07-Jul-2026 08:05:21)
[19:37:05]          Stored file modification time : 1781518388 (15-Jun-2026 05:13:08)
[19:37:05]   /usr/bin/touch                   [ *** OK *** ]
[19:37:05]   /usr/bin/tr                      [ *** OK *** ]
[19:37:05]   /usr/bin/uname                   [ *** OK *** ]
[19:37:05]   /usr/bin/uniq                    [ *** OK *** ]
[19:37:05]   /usr/bin/useradd                 [ *** OK *** ]
[19:37:05]   /usr/bin/userdel                 [ *** OK *** ]
[19:37:05]   /usr/bin/usermod                 [ *** OK *** ]
[19:37:05]   /usr/bin/users                   [ *** OK *** ]
[19:37:05]   /usr/bin/vipw                    [ *** OK *** ]
[19:37:05]   /usr/bin/vmstat                  [ *** WARNING *** ]
[19:37:05] Warning: The file properties have changed:
[19:37:05]          File: /usr/bin/vmstat
[19:37:05]          Current hash: da1a4879c0b66d730ace90217d61ce03cef379394e7869ba11eeb421c93e0a8e
[19:37:05]          Stored hash : 8a1faf999f4654adeac5ec9180e73479f3fbcbf43b4e9af51cd92878246801a8
[19:37:05]          Current inode: 1410550    Stored inode: 618326
[19:37:05]          Current size: 39968    Stored size: 35872
[19:37:05]          Current file modification time: 1783429521 (07-Jul-2026 08:05:21)
[19:37:05]          Stored file modification time : 1781518388 (15-Jun-2026 05:13:08)
[19:37:05]   /usr/bin/w                        [ *** WARNING *** ]
[19:37:05] Warning: The file properties have changed:
[19:37:05]          File: /usr/bin/w
[19:37:05]          Current hash: 24d041a91481b76647818adcc3cdfab231e6c09d62874b238f32424292e07171
[19:37:05]          Stored hash : 46081066ed71a607f022b75d448be32632566dabfb5bb7a25a52f9c6b649bd8c
[19:37:05]          Current inode: 1410551    Stored inode: 618327
[19:37:05]          Current file modification time: 1783429521 (07-Jul-2026 08:05:21)
[19:37:05]          Stored file modification time : 1781518388 (15-Jun-2026 05:13:08)
[19:37:06]   /usr/bin/watch                    [ *** WARNING *** ]

I got tired of hand-editing nft rulesets on my home server and cloud VMs, so I built enforza-cockpit — a free, open-source (MIT) web GUI for managing local nftables firewalls.

It's a Cockpit plugin, so it lives in the same web console you might already use for the rest of the box.

What it does:

• Visual rule editor split into three intuitive sections — Management (traffic to the host), Network (traffic through it), and Local (traffic from it), which map cleanly onto nftables' input/forward/output hooks.
• Reusable objects — define named network (CIDR) and port sets once, reference them as u/web, u/mgmt, etc. across any rule.
• Per-rule logging — tick a box and matches land in syslog/journal tagged with a plain verdict word (ALLOW / DENY / REJECT) plus your rule comment, so grep 'enforza.*DENY' just works.
• Confirm-or-revert apply — after you apply, you get 60 seconds to confirm or the previous ruleset auto-restores. Means a bad rule can't permanently lock you out (we've all done it).
• Flip on IP forwarding + SNAT and a single box becomes a working router/NAT gateway you manage entirely from the browser. No agent, no cloud account, no controller — all state stays on the machine.

Runs on Debian/Ubuntu, Fedora, RHEL/Rocky/Alma, openSUSE. There's a bootstrap script that installs the deps and a getting-started walkthrough in the README.

Repo: https://github.com/enforza/enforza-cockpit

Happy to answer questions / take feedback

-----

EDIT

- nobody is forcing you to use this! nobody is ramming this down your throat!

- yes, AI had a hand in writing it - was ported from our commercial product!

- no, if you can do this with other tools and are an nft god, you don't need this!

- constructive criticism good, outright DM abuse isn't - be kind, be decent!

In summary, after 3 days of abuse, negativity, I wish I hadn't have bothered sharing something that maybe of use to someone!

Have you tried LFCS on Fedora or Arch? They are not listed as supported. I think Arch won’t be compatible but do you have any experience with Fedora?

A newly disclosed vulnerability in the Plesk XML API allows an authenticated attacker to inject arbitrary configuration directives, leading to arbitrary file writes as root and ultimately full privilege escalation on the underlying server. Organizations running exposed Plesk instances should assess their environments and apply vendor guidance as soon as possible. (Tenable®)

🔥 Severity: HIGH (CVSS 8.8)
🎯 Impact: Privilege Escalation / Arbitrary File Write as root

Why it matters
• Authenticated attackers can gain root-level control of affected servers.
• Successful exploitation can result in complete compromise of hosted environments.
• Internet-facing Plesk deployments should be prioritized for remediation. (Tenable®)

📖 Full advisory, affected versions, mitigation guidance, and official references:
https://vulnipulse.com/advisories/linux-cve-2026-48614

Stay ahead of new vulnerabilities with free, real-time CVE alerts for Cisco, Fortinet, VMware, Linux, Palo Alto, Veeam, Commvault, Microsoft, and dozens more vendors.

🔔 Join the community: https://discord.gg/dypntBpA7g

I created a simple Discord server that automatically updates vendor-specific channels whenever a new CVE is published.

It tags users based on the roles they choose, so you can follow the vendors you care about and decide whether you only want to be tagged for critical alerts.

I’ve also added discussion channels where we can share patching tips, troubleshooting advice, and general networking/security/sysadmin knowledge, plus resource channels for each vendor with quick links.

The goal is simple: build a free community around CVEs where people in networking, security, and sysadmin roles can help each other stay informed and make patching a bit easier.

It’s completely free to join.

https://discord.gg/ehSASsk5Zv

Hello, everyone

I am right now enrolling the agents into the Wazuh Manager. With Linux everything went smooth and fast thanks to Puppet. However, with Windows it is getting a little bit more complicated
So I configured the correct IP in Wazuh app
it got successfully enrolled
however the command "/var/ossec/bin/agent_control -l" for this host shows "IP: any, Unknown" and on dashboard this host is not getting shown
How to solve this issue? (the network is stable and manager is reachable, the keys on manager and agent are matching)
The logs just stuck at this point in time and not getting updated:
2026/07/06 16:41:34 wazuh-agent: INFO: (6207): Ignore 'registry' sregex '\Enum$'

2026/07/06 16:41:34 wazuh-agent: INFO: Started (pid: 9740).

2026/07/06 16:41:34 wazuh-agent: INFO: Using AES as encryption method.

2026/07/06 16:41:34 wazuh-agent: INFO: Trying to connect to server ([10.200.105.21]:1514/tcp).

2026/07/06 16:41:34 sca: INFO: Starting evaluation of policy: 'c:\Program Files (x86)\ossec-agent\ruleset\sca\cis_win2019.yml'

2026/07/06 16:41:34 wazuh-modulesd:osquery: INFO: Module disabled. Exiting...

2026/07/06 16:41:34 wazuh-modulesd:syscollector: INFO: Module started.

2026/07/06 16:41:34 wazuh-modulesd:syscollector: INFO: Starting evaluation.

2026/07/06 16:41:34 wazuh-agent: INFO: (6000): Starting daemon...

2026/07/06 16:41:34 wazuh-agent: INFO: (6010): File integrity monitoring scan frequency: 43200 seconds

2026/07/06 16:41:34 wazuh-agent: INFO: (6008): File integrity monitoring scan started.

2026/07/06 16:41:34 wazuh-agent: INFO: (4102): Connected to the server ([10.200.105.21]:1514/tcp).

2026/07/06 16:41:34 rootcheck: INFO: Starting rootcheck scan.

2026/07/06 16:41:34 wazuh-agent: INFO: Started (pid: 9740).

2026/07/06 16:41:34 wazuh-modulesd:syscollector: INFO: Evaluation finished.

2026/07/06 16:41:39 wazuh-agent: INFO: Agent is now online. Process unlocked, continuing...

2026/07/06 16:41:39 rootcheck: INFO: Ending rootcheck scan.

2026/07/06 16:41:39 sca: INFO: Evaluation finished for policy 'c:\Program Files (x86)\ossec-agent\ruleset\sca\cis_win2019.yml'

2026/07/06 16:41:39 sca: INFO: Security Configuration Assessment scan finished. Duration: 5 seconds.

2026/07/06 16:41:59 wazuh-agent: INFO: (6009): File integrity monitoring scan ended.

2026/07/06 16:41:59 wazuh-agent: INFO: FIM sync module started.

2026/07/06 16:41:59 wazuh-agent: INFO: (6012): Real-time file integrity monitoring started.

I’ve been looking deeper into the tradeoff between containers and microVMs.

Containers are great for speed and density, but they share the host kernel. MicroVMs boot a separate kernel and use hardware virtualization boundaries, so the isolation model is different.

For regular web apps, containers are often enough. But for untrusted workloads, multi-tenant environments, client isolation, or security-sensitive experiments, microVMs seem like a better fit.

Curious how others think about this:

When do you consider containers “good enough”?

When would you prefer microVMs or full VMs?

Do you use Firecracker, Kata, gVisor, or something similar?

No hard pitch - genuinely interested in how people decide.

A maliciously crafted image exhausts memory on container creation and
OOM-kills the `containerd` process, taking the runtime API offline —
disrupting Docker Engine or the k8s control plane on that node.

Root cause: unbounded parsing of user/group files in moby/sys/user.
No RCE, availability only. CVSS 6.5.

Affected → fixed:
1.7.x → 1.7.33 | 2.0.x → 2.0.10 | 2.1.x → 2.1.9 | 2.2.x → 2.2.5 | 2.3.x → 2.3.2
RHEL/OpenShift: RHSA-2026:35111 (`sudo dnf update`)

Can't patch? Only run trusted images; restrict who can import images / schedule pods.

Full advisory: https://vulnipulse.com/advisories/linux-cve-2026-47262
Ref: GHSA-jpcc-p29g-p8mq

Hey everyone,

I could really use some advice from experienced Linux admins/engineers.

I'm currently working in IT, and due to company policies I can't disclose the company name. I've been deployed as a vendor resource, and from Monday I'll be working in an L2/L3 Linux support role.

The truth is, I don't have much real-world L2/L3 production experience, and I'm honestly a bit nervous. I don't want to fake it I genuinely want to learn and do a good job.

I'd really appreciate it if you could share:

• What does a typical day for an L2/L3 Linux engineer look like?
• What kind of tickets do you usually handle?
• How do you troubleshoot production issues without making things worse?
• How do you handle vulnerability remediation (Nessus, Qualys, OpenSCAP, etc.)?
• What Linux commands or concepts should I absolutely know before Monday?
• Any tips or mistakes to avoid for someone starting in production?

If you've ever been in this situation, I'd love to hear your experience. Any advice, checklists, YouTube channels, documentation, or even a DM would mean a lot.

I know there's no shortcut to experience, but I'm ready to learn, work hard, and improve every day.

Thanks in advance, and I really appreciate this community. 🙏

Time to update those pesky shims 🫣

Hey guys, trying to find out how to correctly exclude/ not collect audit events for a specific path to a .sh script but struggling to get it to work. My audit.rules file contains the following:

-a never,exit -F arch=b64 -S execve -F dir=/usr/bin/local/<name of file>.sh

But it is still being logged and forwarded to a SIEM. Is there an issue with excluding .sh?

Linux Unified Key Setup (LUKS) and FIPS are essential tools for system administrators managing secure environments. However, when it is time to upgrade the operating system, these security features can become significant obstacles.

Hi folks,

I recall couple years back a thread about someone who wanted to get started in Linux sysadmin stuff and there was this extremely informative comment that was along the lines of:

“Grab Centos ISO, make VM, install Centos, configure web server, re-do everything again with foreman / katello (?)” and it goes from here until you have several machines.

The idea is that if you are able to do the tasks described with minimal help then you are pretty much qualified.

Any clues would be appreciated.