Genuine time check, because I think ours is bad and I can't tell if that's normal, central rsyslog box here, everything on the estate points at it. We picked up another site last month, a firewall I hadn't seen before, a couple of Windows boxes and some appliance nobody had documented. Getting all of that parsed and searchable took the better part of a week, most of it writing and testing rules by hand. Feels like it should be quicker than that by now, what's your realistic number and what are you running that gets you there?

Disclosure up front: this is my own repo, MIT, no install, just markdown.

I wrote it after one of my own boxes got taken through a screen-share service listening on 0.0.0.0 with a password someone brute-forced. What bothered me afterwards was that every hardening guide I had skimmed would have caught it. I never applied any of them, because they read as a wall of sysctl flags with no consequence attached to any line.

So the format is one thing per section: the failure it prevents, the exact command that closes it, and the command that proves it closed. If I can't verify it on a live box, it doesn't go in.

The triage at the top is what I run first on anything I inherit:

ss -tlnp | grep -vE '127.0.0.1|::1'      # listening beyond localhost
sshd -T | grep -i '^passwordauthentication'   # should print: no
iptables -S INPUT | head -1               # should be -P INPUT DROP
redis-cli ping                            # PONG without auth is bad

Twelve sections: SSH, firewall, service binding, remote desktop, secrets, database auth, passwords, attack-surface audit, incident response, change discipline, an integrity sentinel, and supply chain.

The supply-chain one is the odd one out and the reason I'm posting today, because it breaks the frame of the other eleven. Everything else is about who can reach the box. That one is about what you install on it yourself: a source distribution runs its build script at install time as whoever ran pip, and no firewall rule touches that. It also covers package provenance (typosquatting, and the newer variant where a model invents a plausible package name and someone registers it), pinning against a maintainer takeover, why curl | bash is a different trust level than it looks, and why a clean pip-audit means "nothing known against it" rather than "safe".

The line I'd keep if I could keep one: reachability beats secrecy. A strong password on a service exposed to the world is a weak setup; no password on a service bound to localhost behind a default-deny firewall is a strong one.

https://github.com/Sanexxxx777/server-hardening-playbook

There's a one-page CHECKLIST.md for a fresh box. If something in there is wrong on a distro I don't run, I'd rather hear it than not.

For a periodic job, Persistent=true can cause an overdue run immediately after boot while the next scheduled run is already close. The service may also be restarted manually, so the timer schedule alone does not guarantee one active instance. What locking pattern do you trust for long-running maintenance jobs? The options I am comparing are letting systemd serialize one service unit, using flock on a dedicated file descriptor, and creating a lock directory that stores the owner PID plus process start time. A plain PID file seems unsafe because PIDs are reused and stale files survive crashes. Should a second invocation exit successfully, fail loudly, or wait with a timeout? How do you distinguish a stale lock from a slow but healthy process without creating a race during cleanup?

Can someone post instructions and a video on how to setup xeno rat server and client on macbook air or macosx operating system? Xeno rat is a web based rat and requires no port forwarding. I dont know where to put the .json and confif files etc using map. I need it for monitoring purpose and educational purpose not hacking or thefth.

I recently set up a 3-node Kubernetes homelab on bare metal (on Dell OptiPlex) using Talos Linux, mainly to have a proper environment for learning, testing failures, networking, storage, GitOps, observability, and general Kubernetes experiments.

The setup uses three control-plane/etcd nodes with a shared Kubernetes API VIP, and I documented the full process from network planning and DHCP reservations to Talos installation, per-node configs, bootstrap, workload scheduling, and HA testing.

I’ve written the full guide with commands, screenshots, and the reasoning behind the setup:

Blog: https://blog.prateekjain.dev/building-a-3-node-highly-available-kubernetes-homelab-with-talos-linux-0372066fe49c?sk=4c66cf9181999f9db19ac3aacabcd8e8

If anyone is planning a similar homelab or has questions around Talos, the API VIP, etcd quorum, or the setup in general, happy to help.

In a lab setting, I have a Debian Trixie VM that I'm trying to get setup like a router, and a client Trixie VM whose sole purpose is to get a DHCP lease and get out to the Internet.

On the "router" VM, I have disabled nftables and flushed the rules. Even when I assign an IP address to the client and router VMs and attach them to the same virtual network, they cannot ping each other.

<network>
  <name>isolated-network</name>
  <uuid>2d9a40eb-c078-4c7e-998e-4ed1bf46786e</uuid>
  <bridge name="virbr1" stp="on" delay="0"/>
  <mac address="52:54:00:12:8d:b8"/>
  <domain name="isolated-network"/>
</network>

I am hoping this is something simple, but it's been driving me a little crazy trying to figure it out. How can I get these two isolated VMs to talk to each other?

Based on the technical breakdown published by SonicWall's PSIRT (SNWLID-2026-0016) and Rapid7's ETR analysis, here's the architectural impact:

• CVE-2026-83548 (CVSS 10.0): pre-auth SSRF in the WorkPlace interface, described as an "unintended forward proxy" letting an unauthenticated caller reach localhost-only functionality.
• CVE-2026-83549 (CVSS 7.8): OS command injection in the Appliance Management Console, normally requiring an authenticated admin session.
• Chained, per Rapid7: the SSRF hands the AMC service enough internal reach that the command injection no longer needs authentication at all.

Affected: SMA1000 6210/7210/8200v on 12.4.3-03453 or earlier, 12.5.0-02835 or earlier. Fixed builds: 12.4.3-03526 / 12.5.0-02952.

What makes this worth a second look: this is the same appliance line, same WorkPlace-interface SSRF pattern, as July's CVE-2026-15409/15410 — where Rapid7 and Help Net Security documented TOTP MFA seed extraction and VPN-less lateral movement to domain controllers via the appliance's own LDAP service account. No IOCs or PoC are public yet for this September pair, per the sources I reviewed.

Anyone running SMA1000 in production — are you treating this as patch-and-verify, or going straight to re-image/credential-rotation given the July precedent? Curious how people are scoping the IoC review SonicWall recommends before deciding.

https://www.techgines.com/post/sonicwall-sma1000-cve-2026-83548-third-zero-day-ssrf-rce

I finally fixed a weird blank screen issue after logging into my ThinkPad L14 with Intel Iris Xe graphics. GDM was running normally but after logging in I would just get a blank screen, Where i need to force power off and power on again each time i face this issue. I checked journalctl and found some Xorg errors about AIGLX failing to load i965_dri.so. Since this is a Tiger Lake GPU, I initially thought it might be a Mesa/driver issue and tried MESA_LOADER_DRIVER_OVERRIDE=iris, but it still fell back to llvmpipe.

I also checked /dev/dri permissions and found my user wasn't in the video/render groups, fixed that, but the blank screen persisted, so it wasn't the actual cause. Then I noticed glxinfo was saying "screen 0 does not appear to be DRI3 capable." After digging through the Xorg configuration, I found an old /etc/X11/xorg.conf.d/20-intel.conf file that was forcing the legacy Intel Xorg driver.

Turns out the intel Xorg driver (xf86-video-intel) is an old legacy driver for Intel's older i8xx/i9xx graphics, and Debian explicitly discourages using it on newer hardware, recommending the built-in modesetting driver instead (Debian — xserver-xorg-video-intel). My Tiger Lake Iris Xe is Gen 12 so forcing the old intel driver through that config was simply the wrong setup for this hardware. It wasn't really a case of the driver being "too old" it's just the config was forcing the wrong Xorg driver in the first place.

For comparison, Mesa's documentation lists the Iris driver among its Intel graphics drivers, with Iris being the modern Mesa driver for Intel Gen 8 and newer hardware (Mesa — Source Code Tree). This is separate from the old Xorg intel driver mentioned above.

I removed that old config file and rebooted. After that, everything went back to normal. glxinfo now shows Mesa Intel Iris Xe Graphics instead of llvmpipe, and the blank screen is completely gone.

What surprised me even more is that before this, I was also dealing with inconsistent performance and higher CPU usage. It turned out that llvmpipe was being used for software rendering. Mesa's documentation describes LLVMpipe as a software rasterizer that uses LLVM for runtime code generation and performs the rendering work using the CPU (Mesa — LLVMpipe). Once the config was fixed and the system switched back to hardware-accelerated Iris Xe rendering, that extra CPU rendering workload was no longer necessary, and the whole system now feels noticeably smoother and more responsive.

Funny how fixing one blank-screen issue ended up fixing my laptop's overall performance too.

RANT

i just came up with this facebook post from a guy complaining about his linux ui/ux experience when he's clearly ragebaiting idk what's wrong with him and he probably dont know how to use linux and he's just seemingly hating linux with passion for some reason maybe someone rejected his PR smh and about the fonts on my waybar its my personal preference since pixelify sans resembles that minecraft type of vibes i didn't reply in his recent comments (ragebaits) because he's so retarded here's the facebook post if you wanna flame the guy: https://www.facebook.com/share/p/19dBqrAAoM/

Since we buy internet in Egypt like tomatoes by the kilo, I needed a tool on Linux to see where my bandwidth was actually going.

I looked around but couldn’t find a Linux tool that did exactly what I needed, so I built ViNet!

ViNet uses eBPF to monitor TCP/UDP traffic at the kernel level.

With it, you can:

See which process is responsible for the traffic

See which destination each process is communicating with

Store traffic history locally in a SQLite database

Monitor bandwidth usage through a TUI/CLI

The project is built with Go + eBPF + SQLite + Bubble Tea, and can run as a CLI, TUI, or a background daemon responsible for monitoring the traffic.

Install: curl -fsSL https://github.com/alalfymansour/vinet/raw/refs/heads/main/install.sh | bash

GitHub: https://github.com/alalfymansour/vinet

Based on the technical breakdown published by CISA and BerriAI's own security advisory (GHSA-7488-6r32-c95q) on September 2, here's the architectural impact:

LiteLLM's MCP Streamable HTTP endpoint supported OAuth2 passthrough for upstream MCP servers. When a request's LiteLLM key failed validation, the fallback path was supposed to hand off to passthrough logic — instead it substituted an empty UserAPIKeyAuth() object. Downstream code treats that object as a valid session. Net effect: any request with a fabricated Authorization header reaches the MCP endpoint, can list configured tools, and can call them. No valid LiteLLM key ever required.

CVSS v4: 8.8 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N). Fixed in 1.84.0. Workaround if you can't patch immediately: block /mcp/ routes at your reverse proxy.

Worth noting this is LiteLLM's second KEV appearance this year — CVE-2026-42271 (MCP-bridge subprocess command injection, fixed in 1.83.7) went into KEV back in June, and per a third-party writeup it was chainable with the Starlette Host-header bug (CVE-2026-48710) that's also in this week's CISA batch. If you're running LiteLLM in front of MCP tooling, worth checking you're actually past both fixes, not just the newest one.

CISA bundled this with six other actively-exploited CVEs (Starlette, Kestra, Artifactory, Switchvox, SonicWall SMA 1000) — most share the same failure class: auth logic trusting a reconstructed path, a suffix match, or a fallback object instead of doing a hard check.

Full writeup with the batch table and remediation steps here (background piece on a related local-AI-agent auth bypass for context): [techgines.com link]

What's everyone doing for MCP gateway auth in production — anything better than relying on the gateway's own key validation, given how many ways that's apparently failing this year?

https://www.techgines.com/post/litellm-mcp-authentication-bypass-cve-2026-59822

Full disclosure: Det Mimir is something I’m building.

The reason I started working on it was pretty simple: I kept running into the same kind of incident.

Something breaks, you check a few logs, restart the service, everything comes back... and then half of the useful evidence explaining why it broke is gone.

So I started building Det Mimir around that problem.

It’s a local-first, read-only investigation CLI for Linux infrastructure. It collects bounded evidence from Linux, systemd and optionally Docker, correlates it, builds a timeline, runs deterministic detectors and produces a report where findings stay tied to the evidence they came from.

The important part for me is the boundary: it does not restart services, kill processes, stop containers, edit config or try to remediate anything. There’s also no arbitrary shell execution path.

AI analysis exists, but it’s optional and sits after the deterministic investigation rather than being the thing deciding what happened.

One of the cases I’ve been testing recently was a root filesystem sitting at 96%.

A 512 MiB nginx access log had been deleted, but nginx still had the file open. So the pathname was gone, but the blocks were still allocated.

Mimir correlated the filesystem pressure, the mismatch between filesystem usage and visible files, the deleted-open file, the process holding it and the systemd/service context around it.

It didn’t delete anything or restart nginx. It just explained what was going on and showed the evidence behind it.

Right now Det Mimir is still in private validation, so there’s no public download yet. I’m mainly looking for Linux admins / SREs who’d be interested in tearing the investigation model apart a bit ;)

Things like: * reviewing an example report and telling me what’s missing; * suggesting nasty Linux incidents it should be able to investigate; * testing it against lab / synthetic incidents; * or generally telling me where the model falls apart compared to how you investigate systems in real life.

I’ve documented the current boundary here: https://docs.det-mimir.com/current-and-future/

There’s also a worked example of the storage incident: https://docs.det-mimir.com/worked-examples/storage-disk-full/

And the roadmap is public here: https://det-mimir.com/roadmap/

I’m particularly interested in this question:

What Linux incident would you throw at something like this to decide whether it’s actually useful, rather than just another layer of tooling?

i have a swap script to do blue green deployment, boot new process then move all traffic to new one, terminate old process.

to move traffic i am using iptables. if one knows iptables only only move the new connections. old established connections still use the old ports which old process is listening.

to fix this after redirecting the traffic i am issuing conntrack -F

it works good but problem is it kills all the connections.

to fix it i changed to conntrack -D -p tcp --orig-port-dst port

but now problem is, its somehow corrupting the new process's connection to redis and other outward connection.

i am trying to figure out whats happening but no clue at all.

for now i have reverted back to conntrack -F

any advice, help??

Based on the technical breakdown published in ServiceNow's own August 2026 CVE advisory (KB3152242) and corroborated by BleepingComputer/TheHackerNews, here's the architectural impact: three independent unauthenticated paths into any exposed instance — one through the GraphQL Composite Data API, one through the system config image upload processor, one through a dynamic ORDER BY clause. A fourth bug (CVE-2026-6876) is a sandbox escape for low-priv users. ServiceNow's telemetry says no active exploitation — but their track record on that claim isn't great (see CVE-2026-6875, caught exploited by Defused before ServiceNow's own advisory admitted it). Full patch table and attack chain: [link, background context: our earlier piece on AI sandbox escapes]

Question for the thread: for anyone running self-hosted ServiceNow instances — are you treating GraphQL batching endpoints as a distinct attack surface in your WAF rules, or still relying on the same generic injection ruleset you use for REST?

A few honesty notes on my end: the "85% of Fortune 500" figure is ServiceNow's own self-reported stat, not independently audited — I flagged that in the article's accuracy table. Worth verifying against ServiceNow's investor materials if it matters for your reporting.

https://www.techgines.com/post/servicenow-ai-platform-vulnerabilities-cvss-10-graphql-sql-injection

We have a mix of Linux servers (RHEL, SSSD/realmd joined) in our AD forest going back to 2019. Our compliance/health report flags a bunch of them for PasswordNeverExpires = TRUE, but when I cross-check PasswordLastSet against today's date, the passwords are actually rotating (varying DaysSincePwdChange values, roughly in the 4–30 day range across machines) — so SSSD is clearly doing its job on the client side.

A few questions:

1. Why does the ADS_UF_DONT_EXPIRE_PASSWD bit (0x10000) get set on Linux-joined computer objects in the first place?

My understanding is adcli used to set this bit unconditionally from its original 2012 release until v0.9.2 (2021), when it was made optional behind a --dont-expire-password flag. Some of our newer machines (joined in 2026) still show the flag set, which suggests either our join automation is still passing that flag, or something else is setting it.

2. Does the flag actually do anything on a box where SSSD is actively rotating the password?

Per Steve Syfuhs' writeup, DCs don't enforce password expiry for computer accounts — expiry is just a hint for the client's proactive rotation logic, not something the DC checks.

So my read is that clearing the flag on a machine where SSSD is already rotating should be a functional no-op — it just satisfies whatever compliance scanner is checking userAccountControl. Is that correct, or is there a scenario where this bites you?

3. What's the actual best practice in 2026 for fixing this at scale?

• Bulk-clear via Set-ADComputer -PasswordNeverExpires $false against the whole OU?
• Fix it at the source by auditing our join automation (Ansible/Puppet templates) for a stray --dont-expire-password flag?
• Or is there a way to have adcli update clear the bit itself without a separate LDAP write?

Would appreciate input from anyone who's dealt with mixed Windows/Linux AD estates at scale — especially if there's a gotcha I'm not seeing with ad_maximum_machine_account_password_age (SSSD, default 30 days) vs machine password timeout (Winbindd, default 7 days) that makes bulk-clearing the flag risky.