Linux threat detection built around host behaviour

Authentication

SSH is where most attacks start and where the first signal usually appears. The agent reads the authentication log line by line as sshd writes it, on both the auth.log and the journal-backed layouts, and reports failed and successful logins with the attempted username and the source address. Repeated failures from one source are counted, and on a server set to Automatic the third sighting within thirty minutes blocks the address through the firewall the server already runs.

Success matters more than failure. A privilege-granting change, a new account, a new sudo grant, a new authorised key, is attributed to the interactive session it happened inside, when that session was authenticated with an SSH key you have registered as an administrator's, so an account the owner created during their own login is not reported with the same weight as one that appeared with no session behind it. The attribution is deliberately narrow: a root session being open is not, on its own, a reason to trust a change, because an intruder who has brute-forced root is by definition acting inside a root session.

SSH brute force protection

Processes

Malware that lands on a server has to run from somewhere it is allowed to write, which is why it runs from /tmp, /var/tmp or /dev/shm and often deletes itself from disk once it is in memory. The agent walks /proc on an interval and reports any process whose executable resolves into a world-writable temp directory, deleted or not, with the PID, the path and the command line, so the finding is something an administrator can check in one command. It deliberately does not flag every deleted binary: a routine package upgrade leaves long-running processes pointing at a deleted file all the time, and a detector that cannot tell the two apart is switched off within a week. A miner also shows in the numbers: CPU above the server's own baseline for five consecutive reports is a finding, and it closes itself once the server is calm again.

Hidden processes are reported when the process table and the kernel disagree about what exists, which is exactly what a rootkit produces, alongside the other rootkit-style signs: an ld.so.preload entry, a kernel module that appeared, a file made immutable, a connection the process table cannot account for.

Malware and webshell detection

Files

Persistence is a file change. The agent hashes the files that decide who can do what, the authentication database and its shadow, sudoers and its drop-ins, sshd's configuration, cron and systemd units, PAM and the authorised keys, and reports a change with the hash before and after. For the persistence files, the text before and after travels with the finding, within a small size limit and never for binary files, so a new cron line or a new key is read in the alert.

Web roots are watched for the change that becomes a server problem: a new executable file where a site keeps uploads, a modified core file, a file whose content matches a web-shell rule. A flagged file is made readable to a person as a 200-byte excerpt and screened automatically; quarantine, which makes the file unreadable in place, always waits for a person, because when SecAI reviewed the web-shell findings on its own fleet, every one had been a false positive, and the fix for that is a person, not a threshold.

File integrity monitoring

Network

Outbound is where an intrusion becomes useful to its owner: a download of the second stage, a connection to a command server, a miner talking to its pool. The agent reads the kernel's connection tables, never the packets, and reports an outbound connection to a destination the server has not spoken to before, with the remote address, port and the process that owns the socket. Inbound, it measures flood and connection-exhaustion patterns from the same tables and conntrack, and tells a SYN flood from a backlog full of legitimate clients.

What the host cannot see, it does not claim. A volumetric attack that saturates the link is reported as the link being saturated, and the fix is upstream; behind a CDN, the observed source is the edge, and SecAI protects those addresses from being blocked so a site cannot be taken down by its own traffic.

Flood and DDoS detection

Rated by what it is

A detection system that rates a routine package update as critical trains its owner to ignore it. Every finding in SecAI is rated by one policy, with the context it was found in: an account created by a package install that the package manager can verify is rated low; the same account with a login shell, a home directory or a key is rated medium; a change inside a trusted administrator's own session is attributed to it; a change with no session behind it is not. A finding about a state that is no longer true closes itself; a finding about a change is yours to acknowledge, and once acknowledged it stops counting as something that needs you.

From detection to response

A useful finding answers six questions before anyone opens a terminal:

• What happened, in one sentence, in the owner's words.
• Why it is suspicious, rather than routine.
• Which server, and which resource on it.
• What evidence supports it: the line, the path, the hash, the address.
• What action is safe, if any, and how it is undone.
• Whether a person has to approve it, which for everything except blocking an address is yes.

Automated incident response