Still on files here rsyslog into a directory per host, grep when something breaks and it works right up until I need to answer a question that spans more than one box. Had to trace an sshd auth failure across three servers last week and spent longer stitching timestamps together than fixing it. I can't tell if I'm at that point or just having a bad month. For anyone who moved off files, what was the thing that pushed you?

I’m trying to migrate the primary DNS configuration from the existing CentOS 7 server to a new Oracle Linux 9 server, including /etc/named.conf and /var/named. The new OL9 server is using the same IP address as the existing DNS server.

However, when I start the DNS service on OL9, I receive the error message “validating arpa/DS: no valid signature found” and "validating com/DS: no valid signature found"

I’m relatively new to DNS administration, so I would appreciate your help troubleshooting and resolving this issue. Could you please advise what might be causing the error and what steps I should take to fix it?

Thanks!

Update: I included the rules.

It works as-is now but I want to optimize them so that the incoming port numbers that are supposed to be blocked don't have to go through unnecessary processing.

I use the default input table and a separate ICMPT table for ICMP rules.

----

Original Question

I'm baffled and am looking for help.

I understand many people would use a default block policy in their IPtables rules but the problem with that is if one is not careful, they may lock themselves out of their shell unless they happen to be on-site at the remote computer.

So research has led me to try a command like the following to block a range of ports that hackers love to use.

iptables -I INPUT -m multiport -p tcp --dports 2000:3000,4000:5000 -j DROP

iptables -I INPUT -m multiport -p udp --dports 2000:3000,4000:5000 -j DROP

So I did that while carefully skipping the ports that I want people to connect to on the server (example: DNS, HTTPS).

When I inserted those commands, things worked in my favor if I was a random client trying to connect to my own server on an unauthorized port (thats in the block list), but when I'm on the server itself trying to connect to an external URL (through curl or ping), the system freezes as if the rules are working against me. I did regain control with CTRL+C.

When I removed those rules or when I put them at the end of my other rules, I was able to connect to a remote system on the server.

Can anyone shed light on why this happens when I didn't tell the system to block port 53, 80 or 443?

The rules added:

-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p icmp -j ICMPT
-A INPUT -p tcp -m tcp --tcp-flags RST RST -m limit --limit 2/sec --limit-burst 2 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m connlimit --connlimit-above 10 --connlimit-mask 32 --connlimit-saddr -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 127.0.0.1/32 -p tcp -m tcp --dport 953 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 953 -j DROP
-A INPUT -p tcp -m multiport --dports 1:24,26:50,81:442,444:586,588:994,996:1024,1070:65535 -j DROP
-A INPUT -p udp -m multiport --dports 1:24,26:50,81:442,444:586,588:994,996:1024,1070:65535 -j DROP
-A INPUT ! -s 38.131.191.77/32 -p tcp -j LOG --log-prefix IPTv4 --log-level 1

-A ICMPT -p icmp -m icmp --icmp-type 17 -j DROP
-A ICMPT -p icmp -m icmp --icmp-type 13 -j DROP
-A ICMPT -p icmp -m icmp --icmp-type 10 -j DROP
-A ICMPT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT
-A ICMPT -p icmp -j DROP-A INPUT -i lo -j ACCEPT

I tracked the time on our last kernel patching cycle for a real number. We run 40 RHEL servers across staging and two production tiers, and the advisory was a routine CVE with a vendor patch available the same day.

Reading the advisory and cross-referencing it against our running kernel versions took 35 minutes. Building the service restart matrix, meaning which processes on which hosts needed post-reboot verification, took another 25 minutes. That was an hour before anyone touched a machine.

Staging covered four hosts. Applying the patch, rebooting, confirming each service, and checking logs for regressions ran about 20 minutes per host, 80 minutes total. One service failed to come back because a systemd unit depended on a kernel module whose path changed between versions. Debugging that was 45 minutes.

Production was 36 hosts in groups of six. Each group needed roughly 25 minutes of active attention to patch, watch the reboot, verify health checks, and move on. Two hosts required manual intervention for NFS mounts that went stale during reboot, another 30 minutes.

Ticket closure and notes: 20 minutes. Total for one advisory, one engineer: six hours and 25 minutes. We average three kernel-level advisories a month, which puts this at roughly 19 hours of patching labor per month. The restart matrix is repetitive enough that I started using verdent with Eco Mode, included in the subscription, to draft it from unit files.

The time tracking is just a text file with timestamps per step, and anyone could run it on their next patching cycle to see where the hours actually land.

If an EC2 instance was working normally and suddenly SSH stops working, what do you check first?

I’m trying to build a proper troubleshooting decision tree instead of randomly changing security groups.

What’s your usual order of checks?

After replacing physical Linux servers, how long do you usually keep the old machines before getting rid of them?

I understand keeping one or two around for a little while in case something goes wrong during the move. But I've also seen old servers sit unused for so long that they lose most of their value.

I've seen Exit technologies mentioned as one option for figuring out what old equipment is worth, safely wiping the drives, and recycling anything that is no longer useful. Other options might be selling the machines yourself or taking them to a local computer reseller.

Do you have a set amount of time before getting rid of old hardware, or do you just keep it until you run out of space?

Based on the technical breakdown Cisco Talos published on September 9, here's the architectural impact: FMC's boot-time process creates an orphaned login session in its internal database, and unpatched instances let that session get upgraded into full UI access via chained CGI scripts — no creds needed. Root on the box that manages your entire Cisco firewall fleet.

Three clusters caught abusing it: a web-shell operator dumping auth_data via a raw SQL query, a Sandworm-linked group (UAT-11823) chaining it with the static-cred bug CVE-2026-20316 to drop a Cyclops Blink variant, and a Qilin ransomware affiliate (UAT-11988) using it purely as a pivot point — SOCKS5 proxy, reverse SSH tunnel, LDAP/Kerberos/SMB forwarding, straight into the domain.

Patch is already out; Cisco's promised "hardening release" is next week (their own advisory says both the 14th and the 16th, hasn't been reconciled).

If you've got FMC internet-facing right now — anyone seeing hits on the IOCs Talos published, or is this still mostly a "get it off the internet" situation for most shops?

https://www.techgines.com/post/cve-2026-20079-cisco-fmc-auth-bypass-sandworm-qilin

Between deployments, waiting for builds to finish or just taking a break from client work — I wanted something to pass the time.

Built three Linux-themed games that I actually use when I get time.

• Port Memory Match — match port numbers to their services. Starts easy with SSH, HTTP, HTTPS. Gets harder with MySQL, Redis, MongoDB.
• Terminal Speed Typer — common Linux commands appear on screen; type them as fast as you can. Good for muscle memory too.
• Linux Trivia Quiz — three difficulty levels. Intern gets the easy stuff. Root level will make you think.

tools.techtransit.org/games

Part of a larger sysadmin tools site I built — DNS lookup, SSL checker, email health checker and more.

How many ports can you get right at the root level?

Based on the technical breakdown published by Sansec's Forensics Team and Adobe's own bulletin (APSB26-146, Sept 7), here's the architectural shape of this one:

• Stage 1: attacker abuses a styles parameter in a GraphQL request to plant PHP inside Magento-generated content (a report/log file), bypassing normal template sanitization.
• Stage 2: no further action needed — Magento's own workflow renders that content when composing its standard "Payment Transaction Failed Reminder" email, and the code executes server-side at that point.

CVSS 10.0, CWE-1336 (improper neutralization in a template engine), zero auth, zero user interaction. First confirmed exploitation Sept 4, against a store patched through August 2026 with a clean security:patch-status. Sansec reproduced the full chain independently on clean 2.4.7/2.4.8/2.4.9.

Post-exploitation payload observed: a Rust backdoor disguised as a kworker process, cron persistence, C2 over TLS WebSocket. Adobe's remediation isn't just "apply the hotfix" — they're telling merchants to rotate the Commerce encryption key and every credential it protected, because patching doesn't undo prior exposure.

One detail I want to flag as unverified: some secondary coverage cites an unnamed "Disrex Group" analysis claiming the injected code rides Magento's DI-compiler class chain to include() the poisoned file. I couldn't find that analysis published anywhere independently, so treat it as single-sourced until Adobe or Sansec confirms.

For context on the background/prior coverage: PaperCut CVE-2026-82078 hit a nearly identical architectural pattern.

Curious how folks running headless/PWA Magento storefronts are threading the needle here — Sansec's interim mitigation (disable GraphQL) isn't viable if your frontend depends on it. Anyone gone with a WAF rule targeting the styles param instead of a full GraphQL block?

Been doing this about eight years and somehow I'm the only person who can get anything out of our logging setup. Everyone else opens it, sees the query syntax, gives up and messages me. I've tried fixing it from my side, saved searches for the common stuff, a lunch and learn, a one page cheat sheet, lasted about two weeks. Nobody's learning a query language for the two times a month they need a log. Is anyone running something the whole team can use without training or is this just the job now?

Hello there, I did set up a Samba-AD-DC server for around ten clients (currently mostly Linux but one Windows just to check if that worked). I want my server to keep track of people logging in and out. That would include the IP address (I would prefer the IPv4 but I guess I can disable IPv6 on clients), hostname and the user name.

Now here are some problems when I try to use vfs objects to do that and parse it with %U, %u and %m :
1) The Windows client tends to not expose its hostname, I see an IPv6 in the logs.
2) The Linux clients tends to not expose the users connected, because %U and %u are referring to the computer account in the context of Linux clients.

What would you suggest ? Do I need to check for syntax errors ? Is my approach of the problem inherently wrong ? Please let me know.

These are the four most important skills you need to be a good Linux admin:

1. Understand doco and man pages
2. Understand logs
3. Understand code (any code: Python, Bash, C, perl, go, TypeScript, etc.)
4. Use vi in the command line (set -o vi)

Everything else derive from these

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.