Rocky Linux

Rocky Linux server security monitoring

Rocky Linux starts from a stronger default than most distributions: a firewall that is on, SELinux enforcing, and security advisories you can filter on. What is left is keeping it that way, and seeing what those defaults cannot.

The short answer

Securing a Rocky Linux server means keeping the defaults it ships with, firewalld and SELinux, switching on security-only automatic updates with dnf-automatic, requiring keys for SSH, and then monitoring for what configuration cannot prevent. SecAI installs on Rocky Linux 9 and 10 with one command, reads authentication events from /var/log/secure, inventories packages through rpm, matches them against Rocky Linux's own RLSA advisories every 12 hours, and blocks attacking addresses through firewalld or whichever tool the server runs.

What Rocky Linux gives you on day one

A standard installation has firewalld running with a default zone that rejects what is not listed, SELinux in enforcing mode, and an OpenSSH server whose ciphers and key exchange follow the system-wide crypto policy instead of a hand-written list. That is a better starting point than a distribution that ships with no rules at all, and it changes what hardening means: mostly, not undoing it.

The defaults to check rather than assume are the ones images change. Rocky Linux builds its official GenericCloud, EC2 and Azure images without firewalld, and its container image has the firewall disabled, so a cloud server often starts with no host firewall at all. Run "sudo firewall-cmd --state" and "getenforce" on a new server before trusting either.

  • Leave SELinux enforcing. When a service is denied something, "sudo ausearch -m AVC -ts recent" shows the denial; allow that one thing rather than switching the system off.
  • Change SSH cryptography through "update-crypto-policies", not by editing cipher lists in sshd_config.
  • The SSH service is named sshd here, not ssh as on Debian and Ubuntu.
  • The systemd journal is kept in memory by default and is lost at every reboot; the text logs written by rsyslog, /var/log/secure among them, survive. The hardening guide has the four commands that make the journal persistent.

The hardening guide, with Rocky Linux commands

Security-only updates, and the reboot nobody does

Rocky Linux publishes advisory metadata with its repositories, as RLSA advisories, so dnf can tell a security update from an ordinary one. "sudo dnf check-update --security" lists only the former, and dnf-automatic with "upgrade_type = security" installs them on a timer. Neither reboots the server: a patched kernel or core library is on disk and not running until somebody restarts.

SecAI reads the same information without changing anything. The agent runs check-update once for everything and once with --security, reports both counts and up to twenty package names, and asks "needs-restarting -r" whether a reboot is pending. That last command belongs to the yum-utils package; on a minimal installation without it, the reboot flag cannot be read and SecAI shows it as not pending, so install the package if you want that signal.

Enable and verify dnf-automatic

How CVEs are matched on Rocky Linux

Red Hat Enterprise Linux backports security fixes into the version it shipped, and Rocky Linux rebuilds them. A package's upstream version therefore says nothing about whether it is vulnerable; only the build does. SecAI matches the rpm inventory against OSV.dev's Rocky Linux data for your major release, where each advisory lists every affected binary package with the build that fixes it, and compares builds with rpm's own version ordering.

One detail matters more than it looks. rpm versions can carry an epoch, a number in front of the version that outranks everything after it, and package inventories usually omit it. Read literally, a build without its epoch looks older than any fix that has one, and every patched server looks vulnerable. SecAI reads a missing epoch as the fix's own when both builds carry the same Enterprise Linux release tag, and otherwise leaves the finding standing rather than clearing it on a guess.

OSV.dev's Red Hat data is organised by Red Hat product stream rather than by release, and SecAI does not map it yet. On a Red Hat Enterprise Linux server SecAI therefore skips vulnerability matching rather than borrow another distribution's data; on Rocky Linux the data is Rocky's own.

Vulnerability and CVE monitoring

firewalld, and where a block lands

The agent asks firewalld for its state and rules and reports whether it is active, what the default policy is, and whether unlisted traffic is really turned away. On Rocky Linux the answer is normally yes, which is the point of reporting it: the day somebody stops firewalld to debug something and forgets, the posture changes and SecAI shows it.

When an address has to be blocked, SecAI uses what the server runs. For an SSH attacker the order is fail2ban, CrowdSec, CSF, firewalld, then iptables, and in firewalld the block is a rich rule with a timeout, so it removes itself.

Blocks are scoped to what was attacked. An address attacking SSH is dropped on the SSH port only. An address attacking a website is dropped on ports 80 and 443 only, and SSH is never touched. For a flood, where everything from the address has to go, the agent first adds a rule that keeps the SSH port open and only then drops the rest, and refuses to place the block if it cannot add that safeguard. The reasoning is simple: if an address was ever attributed wrongly, the person behind it must still be able to reach their own server. Blocks are visible in firewalld itself, listed in the dashboard with their evidence, and expire after 24 hours.

How IP blocking works

What is watched on a Rocky Linux server

  • Authentication from /var/log/secure: SSH failures, successes after failures or from a new source, root logins, and which registered administrator key opened a session.
  • Accounts and privilege: /etc/passwd, shadow, group and gshadow, sudoers and /etc/sudoers.d, authorized_keys, setuid binaries, and the RHEL-family PAM stack in /etc/pam.d/system-auth and password-auth.
  • Persistence: /etc/crontab, /etc/cron.d, user crontabs in /var/spool/cron, and units under /etc/systemd/system, with the text of each change.
  • Package-created accounts, confirmed against rpm's own record, so that installing a package is not reported as an intrusion.
  • Privileged binaries that changed, checked with "rpm -V" so an ordinary update is not reported as tampering.
  • Web and network: web shell candidates in web roots, new outbound destinations, floods, and the certificates your sites actually serve.

Every detection, row by row

Installing on Rocky Linux

One command, as root. The agent is a single static binary for x86_64 with no kernel module and no dependency on the system's libraries, so it is the same binary on Rocky Linux as everywhere else. It needs systemd and the base tools already on the server.

SecAI supports current Rocky Linux releases, which today means 9 and 10. The installer verifies the agent's Ed25519 signature before it installs anything, using an OpenSSL command that exists from OpenSSL 3.0; Rocky Linux 8 ships OpenSSL 1.1.1, so the installer stops there rather than install a binary it could not verify.

Install documentation

Related

Questions people ask

Sources

Statements about Rocky Linux come from the Rocky Linux project and from Red Hat's documentation for the matching Enterprise Linux release, listed here. Statements about SecAI come from the agent and platform source code.

See it on your own server

Install the SecAI agent with one command and watch it protect a Linux server in about 60 seconds. 14-day free trial, no credit card.