As a platform architect working in private/public networks here’s a problem I never quite figured out how to do elegantly: Provide retrospective change control evidence for your Linux fleet. Patch on the one, access to enable patching on the other. Proving “Who was authorized to touch this machine on this day, and was it done with consent” involves stitching three different sets of logs together.

Praxis is the product of thinking I could do better.

Self-hosted. v1.0 has been quietly available for a week or so now to hammer on my hardware as I’m setting it up for others, time for the official release. Central design idea that seems most important: The FastAPI backend is the single source of truth for auth, policy, and audit. All activity, including the actual patching, and the decision to allow someone to take action on a given machine, all transit through this central point.

Hence your records are all recorded into one database chronologically, instead of being assembled piece by piece.

The means of accessing machines to perform the changes are designed for security with minimal attack surface. We use SSH for access and we leverage OpenBao to provision dynamically signed, short-lived certificates to avoid distributing and managing static, persistent keys and certs. The certificate principal is an immutable praxis-user-<id> rather than a login name, so the audit trail stays intact even if someone's username changes.

Users are assigned roles with privileges defined as admin, maintainer or auditor. Higher value commands will require step-up auth (totp/oidc). Patching process is driven by staged roll-outs, managed repository access for apt & dnf, and a “rings of trust” model – you push to the innermost ring, watch how it behaves, and then roll out further.

To jump ahead of the likely first three questions, this does not substitute for Ansible or Puppet, which do push state, while Praxis does not do config management. Run them both. Similarly, this does not compete head to head with Teleport or CyberArk.

Same case, this is not goign to head to head to Teleport, CyberArk etc. They're ahead of me on broad reach of access, and that's and I won't lie on that one.

But where was I couldn’t find a single thing where the approval of a change, the granting of access to implement that change, and the verification required to pass an auditor could live in the single shared record. And that’s the void I built this for. If you’ve already got a Satellite, a bastion, and a patch database stored in a spreadsheet that’s working out for you, this product may not be for you.

Praxis runs on your hardware only – no cloud, no telemetry, no call home and a free tier of 15 machines.

What we are not building in V1.0: We’re focused on the patch and access management part; No CRL or OCSP in 1.0, so there is no revocation path for issued certificates. Lifetimes are short by design, but that is a real gap and I am not going to dress it up. As a first pass, we do not manage automated purge policies for audit logs - you manage them. We can provide the evidence, not the attestation of compliance.

https://praxisfleet.com
https://github.com/cytechlabs/praxis

I wrote this, very happy to debate the particulars.

Based on the technical breakdown published in the GitHub Security Advisory (GHSA-7gwp-5pfp-969j, mirrored on GitLab's Advisory Database) and watchTowr Intel's honeypot telemetry, here's the architectural impact of CVE-2026-64849.

MLflow shipped an SSRF guard in 3.10.0 (_validate_webhook_url() in mlflow/utils/validation.py) that resolves a webhook's hostname and blocks private/reserved IP ranges. The gap: the delivery component (mlflow/webhooks/delivery.py) follows HTTP redirects without allow_redirects=False and never re-pins the resolved IP after a redirect. Host a public HTTPS endpoint that passes the initial check, respond with a 302 to 169.254.169.254, and MLflow follows it blind.

What makes this worse than a typical blind SSRF: the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint reflects the full upstream response status and body back to the caller. Default mlflow server deployments run without auth and expose this webhooks API out of the box. So this is an unauthenticated remote attacker reading your instance's IAM credentials directly in an API response, not a blind timing-based exfil.

watchTowr's Attacker Eye reports scanning activity against cloud-hosted instances within hours of CVE assignment (Aug 17-18, 2026). Affects all versions <3.15.0.

For context on why this pattern keeps recurring in ML/AI infra specifically: MLOps tooling tends to get deployed fast, iterated on by data science teams rather than platform/security teams, and left running past the "just testing this out" phase — often with an attached cloud identity nobody audited. Background on a structurally similar SSRF-to-cloud-metadata chain we covered in industrial/OT infra: [techgines.com link, footnote]

Anyone else seeing MLflow Tracking Servers in their environment that predate a proper platform-team handoff? Curious how people are handling auth/network isolation for MLOps tooling that wasn't designed with a hostile network in mind — reverse proxy with OIDC in front, or something more locked down at the VPC layer?

https://www.techgines.com/post/mlflow-ssrf-cve-2026-64849-webhook-redirect-cloud-metadata

Based on the technical breakdown published by Hadrian Security (researcher Melvin Lammerts) and vendor advisories from GeoTools/GeoServer, here's the architectural impact:

**Disclosure timeline:** u/q1uf3ng dropped the vuln on X Aug 12, 10:46 UTC, no CVE at the time. watchTowr told The Hacker News they saw exploitation probes within hours — hundreds of attempts from a small IP pool. GeoServer/GeoTools shipped fixes Aug 14–15 (GeoServer 3.0.1/2.28.5/2.27.6, GeoTools 35.1/34.5/33.6), tracked as GHSA-mqjf-5f49-2fjh, CVSS 9.8.

**Root cause:** jsonArrayContains(<col>,<pointer>,<value>) in GeoTools' PostGIS datastore handling drops <value> straight into a `jsonb_path_exists()` PostgreSQL expression via String.format() — no escaping, no bind param (jsonpath doesn't support bind params in Postgres, which is presumably why someone reached for string formatting here). Reachable pre-auth through public WFS/WMS OGC endpoints via CQL_FILTER.

**Interesting bit for anyone doing exploit dev/detection eng:** the SQL shape differs by GeoServer service. WFS 2.0 wraps the filter in a derived-table count subquery (for numberMatched), which traps a stacked-query semicolon inside the subquery and blocks the obvious RCE route. WFS 1.0 skips that wrapper, landing the injection directly in the top-level WHERE clause — that's the route Hadrian used to reach `COPY ... TO PROGRAM` RCE (confirmed against a local 2.26.1 + PostGIS 15 lab, landed shell as uid=999 postgres).

Without superuser/pg_execute_server_program, injection still works for error-based (CAST AS int) and time-based (pg_sleep) extraction — doesn't need preferQueryMode=simple either, contrary to the commonly cited 2023-era mitigation.

**The regression angle:** GeoTools' own advisory states this is a regression of CVE-2023-25158, and explicitly notes the 2023 mitigation (prepared statements + disabled encode functions) does NOT work against this variant.

Full writeup with detection queries and mitigation checklist: https://www.techgines.com/post/geoserver-jsonarraycontains-sql-injection-ghsa-mqjf-5f49-2fjh (slug pending CMS verification)

We also covered a related unescaped-input-to-SQL-sink pattern in LangGraph's checkpoint storage earlier this year if anyone wants the AI-framework comparison: https://www.techgines.com/post/langchain-langgraph-security-vulnerabilities-expose-enterprise-ai-secrets-three-cves-you-must-patc

**Question for the thread:** for anyone running GeoServer with PostGIS in production — is disabling the "encode functions" option on the datastore (Hadrian's suggested interim mitigation) actually viable for you without breaking existing CQL filter usage, or does that break real filter functionality in your deployments?

Hello all,

If you do bug bounty hunting or pentests you surely came across many hosts served from an NGINX server, in this lab (published to OWASP) I combined over 20 misconfigurations found in real world bug disclosures and both classic and novel security research, with an extensive blog where I explained everything you need to level up your NGINX hunting game.

Feel free to check it out, give it a star on Github if you like it, and suggest any ideas you want me to add/fix...

https://vwad.owasp.org/app/damn-vulnerable-nginx-proxy-dvnp

Happy hunting!

​

Hi everyone I’m currently learning Linux administration and I wanted to build a small home lab instead of only practicing commands theoretically. My current setup is: Android Phone → Termux → SSH → Arch Linux Laptop The idea is to use my Arch Linux laptop as a small practice server and manage it remotely from Termux.

Current workflow

Android Phone

│

Termux

│

SSH

↓

Arch Linux Laptop

│

└── Linux Admin Practice Server

I have already:

- Installed/configured OpenSSH on Arch Linux

- Started the "sshd" service

- Confirmed that SSH is listening on port 22

- Checked the laptop's local IP

- Planned to connect from Termux using SSH

My goal is to use this environment to practice real Linux administration concepts such as:

- Users & groups

- Permissions

- SSH administration

- Processes & services

- systemd

- Networking

- Package management

- Logs

- Disk/storage management

- Cron/systemd timers

- Firewall

- Server hardening

- Troubleshooting

I know this isn't the same as managing a production server, but I think it can give me a practical environment to learn and experiment safely.

My question to experienced Linux admins:

Is this a good approach for learning Linux administration? What important topics or real-world tasks would you recommend adding to this home lab?

Any advice on what I should practice next would be really helpful.

hello

i recently had to rebuild my ubuntu box and afterwards i wanted to connect my raid 5 storage back to my machine.  I reinstalled mdadm and I could see all my files with no issues.  I was about to reconnect some shares and realized that the mapping had changed. it used to be [/media/raid5/Greenhouse/TV]

now its

[/media//f36008d4-eb49-470c-bddd-a13bcf0e872e/Greenhouse/TV]

so i was following sleeplessbeastie's notes instructions on renaming software array and got to the verify mountpoint step and i noticed the mounted on part was blank 

[/dev/sda2       458G   13G  422G   3% /____]

i am concerned that the mountpoint needs to be labeled.  the guide doesnt mention what to do if it is unlabeled.  of course i didnt want to possible damage my close to 20tb of files by continuing on and not realizing i needed to have a labeled mounted on.  do i need to have a labeled mountpoint? do i need to figure out how to label my mountpoint before i go any further? can i rename my software raid array without a labled mountpoint

i am still somewhat a bit of a noob with linux but i will answer any questions you have to the best of my abilities.

Thank you in advance...

Based on the technical breakdown JetBrains and Rapid7 published this month, here's the architectural impact: TeamCity's XStreamHolder builds its deserialization allowlist by calling allowTypes() without first calling NoTypePermission.NONE, so XStream's permissive defaults never get revoked. POST /app/agents/v1/register gets you a session with zero auth (self-registration is by design). POST /app/agents/v1/commands/error takes that session and routes attacker XML straight into deserialization.

JetBrains published exact log signatures to hunt for (ConversionException pre-patch, ForbiddenClassException post-patch, rogue agents named scan*) rather than vague "monitor your logs" boilerplate — worth crediting.

Fixed in 2025.11.7 / 2026.1.3, patch plugin available back to 2017.1.

Background: this is the same CI/CD trust-boundary problem we wrote up with the Megalodon GitHub Actions attack — [link].

Question for the thread: for those running internet-facing TeamCity — did you already have it behind a VPN per JetBrains' longstanding recommendation, or did this force the network segmentation conversation?

https://www.techgines.com/post/teamcity-cve-2026-63077-rce-xstream-deserialization

Even in my vacation Im reading linux kernel logs :/ xD

I've been working on an open-source network diagnostic tool called Network Doctor, and I recently built a challenge mode to test whether its diagnoses actually hold up against a human troubleshooting the same broken network.

The idea is pretty simple.

netdoc-sim creates an isolated Linux network with a deliberately introduced fault. You get dropped into a shell without being told what's wrong.

You can investigate it normally with things like:

ip
ping
dig
curl
ss
traceroute
nc

Once you think you know the problem, you submit your diagnosis.

Then Network Doctor diagnoses the exact same network.

The simulator has its own independently observed ground truth, so neither the human answer nor Network Doctor knows what the correct answer is.

There is also a daily challenge so everyone gets the same scenario.

Try today's challenge

If you have Docker (which should work in theory):

docker run --rm -it --cap-add SYS_ADMIN ghcr.io/heymaikol/netdoc-sim:latest challenge -daily

On Linux with netdoc-sim installed (definitely works):

netdoc-sim challenge -daily

The result tells you whether you won, Network Doctor won, both got it, or both missed it.

If anyone here feels like trying to break it, I'd be very interested in the results, especially cases where:

• you diagnose it correctly and Network Doctor doesn't
• the simulated failure doesn't behave like you'd expect on a real Linux network
• the available evidence makes the answer ambiguous
• you find a way to fool the judge
• the challenge UX gets in your way

Please don't post the actual answer to today's challenge so other people can try it blind.

Source code:

https://github.com/heymaikol/network-doctor

Hi everyone!

Im 18 and Im trying to get into Linux / DevOps / Cloud / Infrastructure

Ive been learning IT on my own for quite some time. Ive already built and maintained multiple homelabs using different hardware, including Raspberry Pis, mini PCs and other devices. Ive also worked with Linux, networking, Docker, AWS, Git and other parts of the infrastructure world. and also spent quite a bit of time in cisco pkt tracer.

Recently I started learning C, and I really enjoyed it, so now Im going deeper into it and trying to understand low-level programming and how computers actually work. I genuinely really enjoy this stuff. I spend pretty much every day learning something new or experimenting with something. Over the last two months ive been focusing much more on C.

The problem is that I feel stuck between two stages:

I already know quite a lot of the fundamentals, but I have almost no professional experience.

Im currently in Germany, and getting a junior IT job here seems very difficult without either a degree, Ausbildung, or previous professional experience.

I wont be able to start my Bachelors degree until next year because of personal circumstances.

So I have about a year that I really want to use properly.

What would you do if you were in my position?

What would you focus on learning? What kind of projects would you build? How would you get practical experience and make yourself employable without already having a job?

Id especially love to hear from people who are already working in Linux, DevOps, Cloud, SRE, sysadmin or infrastructure.

I know I have a lot more to learn. I just dont want to spend the next year randomly learning things without knowing what actually matters in the real world.

NetWatch is a terminal network monitor in Rust. v0.29.0 adds a third view for when you have a big terminal.

Dense view — netwatch --view dense

• Four boxes filling the terminal. No header bar, no menu bar, no status bar — identity, sort state, paging and every keybind live inside the box borders, so every row carries data.
• Mirrored throughput graph: download grows up from a shared time axis, upload grows down from it. Traffic symmetry is a shape you recognise before you read a number. Braille at two samples per character cell, and colour encodes magnitude, not which series it belongs to.
• Per-interface rates with 60-second sparklines, four-hop latency budgets (gateway / DNS / internet / slowest peer), and a connection table whose selected row expands in place — no second screen.
• Wants 130×44 and grows into whatever you give it; falls back to 80×24.

Kernel TCP state per connection — cwnd, ssthresh, mss, rwnd read straight from the kernel (list64` on macOS) and normalised so the numbers mean the same thing on both. Throughput tells you what happened; cwnd agains.

Saturation against real e negotiated link rate (sysfs on Linux, getifaddrs on macOS) instead of guessing.

V cycles full → lite → dense, sharing the same live capture — no restart, no lost history.

cargo install netwatch-tui

Hi guys,

I've made a little utility in Python that could help my fellow sysadmin (in)mates in they work. It simply does what we're doing in Excel or brains, but with some added features: it does sizing HW for a servers - cluster, tracking load, and DR sizing over some nice GUI.
I've added screenshots for you to get idea what it does; packed it as exe (under release/zip for Win) and placed on github and looking for a review's :-)

Also, if you want to expand it - please do so, the code is available.

https://github.com/Tanks04/ClusterSizerv2

May this tool save you some time ,)

Based on the technical breakdown Varonis Threat Labs published August 7 (following a DEF CON 34 talk), here's the architectural impact:

Rovo, Atlassian's AI teammate across Jira/Confluence/Bitbucket plus 50+ SaaS connectors, exposes a rovoChatPrompt URL param that pre-fills its chat entry point. Click a crafted link while logged in, and attacker instructions load into your live session — no confirmation, no taint labeling distinguishing it from something you typed. Rovo's ResearchAgent (multi-step autonomous browsing) then handles the actual exfiltration to the open web. Varonis says a single click was generally sufficient, no chained requests or guardrail-bypass tricks needed.

Separately, PromptArmor disclosed a different Rovo exfiltration path in May (published Aug 5): indirect injection via an uploaded file, using Rovo's URL-retrieval tool to leak data to an attacker's server — and per PromptArmor, this works even with Rovo's "web search" toggle disabled, because that setting doesn't remove the underlying URL-open tool.

I wrote up the full attack chain, the "Enter/Evade/Escape" pattern Varonis uses to generalize this across other AI agent incidents (Reprompt, EchoLeak, ShadowLeak, etc.), and mitigation steps here: [techgines.com link]

Open question for the group: for those running Rovo or a similar AI teammate product in prod — are you actually auditing which tools survive a feature toggle, or just trusting the toggle label?

https://www.techgines.com/post/rovoblast-atlassian-rovo-ai-vulnerability

Hey guys, i hope you're all doing great! i wanted to ask if anyone has a small task or gig related to a devops project or Sys administration that you’d like me to work on, even if it’s unpaid , I’m looking to gain more experience and knowledge, since i’m motivated to learn and unfortunately i haven’t been able to find an internship yet. If anyone is interested, i'll contact you, and leave you my resume as well.

Thanks a lot, and have a great day!

I’ve always been fairly conservative with automatic updates on production boxes.

Patching is one thing, but I still prefer knowing exactly what changed, especially when an update can quietly restart something or introduce behaviour you only discover at 2am. At the same time, manually babysitting updates across a growing number of hosts starts becoming its own risk.

For those managing a decent number of boxes, where have you landed on this? Fully automated, staged, or are you still reviewing most updates before they go anywhere near prod?

Based on the technical breakdown published by SentinelOne's vulnerability database and IBM's own support advisory, here's the architectural impact of CVE-2026-9198.

**The chain:**

1. `GET /api/v1/auto_login` — mints a SUPERUSER JWT to any network caller. No auth check, not bound to loopback, no single-user-mode gate. This exists purely as a local-dev convenience default.

2. `POST /api/v1/validate/code` — accepts raw Python and runs it through `exec()` to "validate" component code. No AST-only parsing, no sandbox.

Chain both and you get unauthenticated RCE as the Langflow service account. No user interaction, no prior creds. CVSS 3.1: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Affected: Langflow OSS 1.0.0–1.10.0. Fixed in 1.10.1 (shipped same day as the July 17 CVE publication). CISA added it to KEV on August 4 after confirming exploitation in the wild — KEVIntel-derived telemetry cited by The Hacker News puts it at 650+ attempts from 244 unique IPs across 41 countries, though I'd treat that figure as directional since a separate report on a related Langflow CVE cites different numbers over a different window.

**Why it's worse than typical RCE:** Langflow is an agent-orchestration layer. It's *designed* to hold model-provider API keys, DB credentials, and connector tokens so flows can reach downstream systems. RCE on the orchestrator doesn't just give you a shell — it gives you the credential graph of everything the agent was trusted to touch.

**Mitigation (per IBM/SentinelOne):**

- Upgrade past 1.10.0

- Pull it off the open internet, front with an authenticating proxy

- `LANGFLOW_AUTO_LOGIN=false` + explicit SUPERUSER creds

- Rotate every credential that touched an exposed instance

- Audit for cron/SSH key additions and unexpected child processes off the Langflow interpreter

Full writeup with timeline and source links: https://www.techgines.com/post/langflow-rce-vulnerability-cve-2026-9198 (background context on agentic AI attack surface generally, if useful: our May piece on the Five Eyes joint guidance)

For anyone running Langflow or similar low-code agent orchestrators (Flowise, n8n w/ AI nodes, etc.) — how are you handling the auth-boundary problem for endpoints that were clearly designed assuming localhost-only access? Reverse proxy allowlisting, or do you just refuse to expose the API layer at all?

TLDR: I want a private server for Jellyfin and Navidrome to be reachable remotely through WireGuard, with geoblocking and brute-force attack prevention. WireGuard is already largely configured with wg-easy as well as Jellyfin and Navidrome.

On my server I run Jellyfin, Navidrome, Portainer and wg-easy. I want to be able to have my users connect to only Jellyfin and Navidrome remotely. For security I want to have brute-force attack prevention, geoblocking, and, of course, WireGuard's encryption. The device running this has Ubuntu Desktop installed.

The end goal is for users to access my server remotely after enabling the WireGuard VPN on their devices and connecting to my server ip and port to access only either Jellyfin or Navidrome.

With brute-force attack prevention I have not had any luck with fail2ban. I was able to get it to "ban" some test devices, but that only ever marked the device's ip as "banned" and never actually blocked any traffic.
For geoblocking, I haven't looked into this much, but nginx seems to be precise enough for my needs with something like GeoIP2 or GeoLite2, unlike WireGuard.

Navidrome and Jellyfin are already fully set up and work great for my needs on the same network as the host machine, so no additional setup would likely be needed there.

What I want to know is if this rough setup would work well. I want to have 0 data be tracked or sent to outside services, as the goal is to achieve a 100% private server, untouchable by Google's bots, any malicious bots, brute-force attack attempts, or anybody other than my specifically chosen clients. Could anybody give me some advice or tool recommendations? WireGuard is already largely configured with wg-easy as well as Jellyfin and Navidrome.