Does this work on my system?

Four commands that trigger Timbre — harmless, undone in seconds, each hitting exactly one immediate indicator.

A security tool you cannot try out is a tool you have to believe. This one you do not have to believe.

Each of the following commands triggers exactly one immediate indicator. They are undone in seconds, cause no damage and leave nothing behind. The alert should reach you in under a minute.

Run them one at a time, not all at once. Otherwise the same report contains four indicators and you cannot tell which came from which command.

1 · A shell under the web server #

The most telling test — it looks exactly like a real web shell, and that is the point. An attacker who gets in through a flaw in a web application runs commands under precisely this account.

If no web server runs on the system, the account does not exist — then this test does not apply, and that is not a fault.

What Timbre recognises: an interactive shell under a service account that normally starts none.

2 · Starting from a storage directory #

cp /bin/true /tmp/timbre-test && /tmp/timbre-test; rm /tmp/timbre-test

Copies a harmless system program to /tmp, runs it and deletes it again.

What Timbre recognises: an executable started from a directory that should only hold data — the most common route by which downloaded malicious code gets executed.

3 · The shape of a reverse connection #

timeout 1 bash -c 'exec 3<>/dev/tcp/192.0.2.1/4444' 2>/dev/null

It connects nowhere. 192.0.2.1 lies in the range explicitly reserved for documentation (RFC 5737); nothing answers there. What is recognised is the shape of the call, not its success.

Without bash — on Alpine or OpenWrt — there is no /dev/tcp. There this test does not apply.

4 · Mining pattern in the command line #

bash -c 'echo stratum+tcp://pool.example:4444; sleep 1'

Prints a string that looks like the configuration of a mining program. Nothing is computed and nothing is connected.

In a container #

All four work there too, with one restriction: the agent must be able to see the process. Running in the same namespace (--pid=host, as the installation guide specifies) it does. In its own container without a shared namespace it only sees its own processes — and then it honestly reports nothing.

If nothing arrives #

If no report arrives after a minute, it is usually one of three things:

1. The process watch is not running. It needs a netlink socket; on systems with SELinux or AppArmor that can be denied. The dashboard says so on the device.
2. The immediate channel is capped. It reports at most six events per hour and leaves five minutes between two reports — running all four commands in a row therefore does not produce four reports.
3. The agent is not measuring. With the security check switched off on the device it collects nothing, including immediate indicators.

What these tests are not #

They test one path: the immediate channel of the process watch. Timbre recognises far more — files, network connections, accounts, system state — and most of that is not triggered in seconds but learned over days. Running these four commands and getting a report tells you the channel works. It does not yet tell you how good the baseline is.