Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.
CISA added CVE-2026-60004 , described as a Gitea code injection vulnerability, to its Known Exploited Vulnerabilities catalog on 25 August 2026. The KEV listing is the important part: CISA doesn't add things to that catalog on theory. It adds them when there's evidence of active exploitation in the wild. So this isn't "a bug was disclosed" — it's "somebody is using this against real servers right now."
This guide configures a Cisco ASA to send its event logs to a central syslog server (or SIEM) so you have off-box, timestamped audit evidence. It changes the firewall's logging configuration only — it does not touch access rules, NAT, or routing — but you are still editing a production security appliance, so treat it accordingly.
This guide builds a scheduled PowerShell script that reads the Group Policy operational event log, collects the error events from the last 24 hours, and writes them to an HTML file (optionally emailed). It is a reporting tool: it never edits, links, or unlinks a GPO, and it makes no change to any policy or to the events themselves. The only thing it creates on the system is a report file and — if you follow the last section — a scheduled task.
This script reads your Postfix relay-control settings with postconf and flags configurations that could let outsiders relay mail through your server — the classic "open relay" that gets you onto blocklists and turns your box into a spam cannon. It is read-only. It changes nothing, writes nothing, and reloads nothing , so there is no config to back up and nothing to roll back. It simply reports.
This guide configures two related Palo Alto features: a Zone Protection profile (broad, per-zone flood defence applied at the edge, before a session is even created) and a DoS Protection profile + policy rule (granular defence for specific servers). Their whole job is to drop traffic once a rate threshold is crossed. That is the point — and also the danger. Set a Max Rate too low and you will drop legitimate production traffic; enable a block action and you will hold that drop for the block duration.
This guide builds a read-only report. The script reaches each IIS server in your farm over PowerShell remoting, reads the HTTPS (SSL) bindings, looks up the bound certificate in the local machine store, and emails you a list of anything expiring within a threshold you set. It does not install, bind, delete, or renew any certificate, and it makes no change to IIS or the certificate store. The only thing that persists is a scheduled task, if you choose to create one — and I show you how to remove that at the end.
This guide sets up a small bash script, run on a schedule, that reads the resident memory (RSS) of every process inside the dovecot.service cgroup and warns you when one crosses a threshold you set. It only reads and reports — it writes a line to syslog and optionally sends an email. It does not kill processes, change Dovecot config, or touch any mailbox.
Most of the people who read this blog run mail, not print servers, so let me be honest up front: if you don't have PaperCut NG or MF anywhere in your estate, you can close this tab. But a lot of us run it next to the mail infrastructure — it's the thing that meters departmental printing and holds scanned documents — and the way this one broke is worth understanding even if you're patched, because it rhymes with problems we already know from Zimbra.
This guide creates and manages network objects — hosts, networks, address ranges — and gathers them into network groups in the Check Point management database. Those objects are the reusable building blocks you later reference in access rules and NAT. Creating an object by itself changes nothing on the gateway: the object does nothing until it is used in a rule and you Install Policy . The real risk is downstream — a wrong object dropped into an existing rule, or a policy install, can cut production traffic.
A disabled account is not a harmless account. If it still holds membership in security groups, it still carries the access rights those groups grant — file shares, application roles, delegated permissions. If that account is ever re-enabled (by mistake, or by an attacker who compromised a helpdesk process), it lights up with all its old access instantly. Periodically finding disabled users that still sit in security groups is a basic hygiene task, and it is easy to script.
This guide turns on SSL/TLS deep inspection on a FortiGate and then adds exemptions so that applications using certificate pinning (banking apps, Dropbox, Windows/Apple update services, and similar) keep working instead of failing silently. Deep inspection is a man-in-the-middle: the FortiGate decrypts HTTPS, scans it, and re-signs it with its own CA. That is powerful and also the single most disruptive thing you can enable on a firewall.
This guide sets mailbox-level forwarding (the ForwardingSmtpAddress / ForwardingAddress and DeliverToMailboxAndForward properties) on many mailboxes at once, reading the target address for each mailbox from a CSV file. It uses Set-Mailbox in Exchange Online PowerShell. This is not the same as an Outlook inbox rule — it is the server-side forwarding an admin sets, and it applies regardless of whether the user's Outlook is open.
This guide builds a Python tool that looks up the _dmarc.<domain> TXT record for one or more domains, parses it, and reports where the DMARC policy is missing, malformed, or weaker than the baseline you set. In its default form it only reads DNS — it changes nothing. The optional second half pushes a corrected record through a DNS provider API (I use Cloudflare as the concrete example).
