What the scanner does
Minaki Scan checks a Linux server and tells you, in plain English, what's wrong and the exact command that fixes it. Here's what it does, what it doesn't, and where its limits are.
At a glance
- Read-only by default. A scan looks and reports. It changes nothing.
- You approve every fix.
--fixoffers fixes one at a time, and each runs only after you typeyes. - Backed up and logged. Before a fix changes or deletes an existing file, the scanner saves a copy. Every fix is written to a log on your server.
- Nothing leaves your server. Minaki Scan makes no network connections.
- Honest about limits. It can't prove a server is clean, and it tells you what it couldn't check.
A scan changes nothing
Run sudo minaki-scan and it reads your server's settings, files, running programs and logs, then prints a report. Each finding names the exact file, line or setting it found, explains why it matters, and gives the command to fix it by hand. A scan doesn't write any files.
Fixes only after you say yes
Add --fix and, after the report, Minaki Scan offers each fix it knows how to apply safely, one at a time. Each asks you to type yes. Anything else skips it. When you're done, it scans again and shows the new result.
It can apply two kinds of fixes:
- SSH settings. Turn off password logins, let root log in only with a key, and refuse empty passwords. It tests the new settings before using them and puts the old ones back if the test fails. It won't turn off passwords if no account has a login key, because that would lock you out.
- Removing malware it has confirmed. It acts only on a confirmed finding, such as a file whose exact fingerprint matches the malware. A file or process that only has a suspicious name is reported and left alone.
Before a fix changes or deletes an existing file, the scanner copies it into /var/lib/minaki-scan/. Copies of removed malware are made unrunnable, and only root can open them. Every fix is written to /var/lib/minaki-scan/changes.log. For SSH fixes, the log includes the exact command that undoes it. See undoing a fix.
Threats it can remove
Minaki Scan can remove seven malware families, with your approval. Each removal was tested before it shipped. How we test explains how, and what each test proves.
| Threat | How we tested the removal |
|---|---|
| Mirai-lineage bot | On a real sample our own decoy servers caught |
| Sysrv | On a planted test copy |
| Prometei | On a planted test copy |
| Muhstik | On a planted test copy |
| DreamBus | On a planted test copy |
| RedTail | On a planted test copy |
| Outlaw | On a planted test copy |
Threats it won't try to clean
Some threats hide inside the system itself. They load into the core of the operating system (the kernel), or replace the programs you'd use to look for them. These are often called rootkits. A server with one of these can't be trusted to report on itself, so a cleanup that looks finished may not be.
Minaki Scan looks for signs of eleven of these: Skidmap, Reptile, perfctl, BPFDoor, Kinsing, XorDDoS, PwnRig, HeadCrab, P2PInfect, PumaBot and Chaos. It reports one only when several signs agree, never on a single name. If it finds one, it tells you to back up your data, reinstall the server from trusted install media, and change every password and SSH key the server held. It never offers to remove these.
What it checks
| Area | What it looks for |
|---|---|
| SSH settings | Password logins allowed, root allowed to log in with a password, empty passwords allowed. All three can be fixed with --fix. |
| Login keys | Key files changed in the last 7 days, and keys in the older authorized_keys2 file that people often forget to check. |
| Accounts and admin rights | Accounts with no password, extra accounts with full root power, admin (sudo) rules changed in the last 7 days, and accounts that can control Docker. |
| Hidden code | A system-wide setting (/etc/ld.so.preload) that loads code into every program. |
| Startup entries | Scheduled tasks (cron), system and user services, and login scripts that download and run scripts, decode hidden commands, or run from temporary folders. |
| Running programs | Known crypto miners, programs running from deleted files, and programs running from temporary folders. |
| Open services | Databases, Docker, Telnet, FTP, Windows file sharing, rsync, remote desktop and similar services listening on an address other machines can reach. |
| Temporary folders | Compiled programs sitting in temporary folders, and programs there set to run with their owner's power (setuid). |
| Login logs | Failed SSH logins in the server's log, and any address that failed to log in and then succeeded. |
| Known malware files | Files whose exact fingerprint matches known malware, plus the seven removable threats above and signs of the eleven threats that need a rebuild. |
| Upkeep | Automatic security updates turned off (on systems that use apt), and updates waiting for a restart. |
What it can't do
- It can't prove a server is clean. No scanner can. A report with no findings says so: "nothing found by these checks", which is not proof.
- It tells you what it couldn't check. If a check can't run, for example because a file needs root to read, it says so instead of skipping it quietly. Run
minaki-scan --advancedto see the list. - Some checks need the live system. When you scan a mounted disk with
--root, only file checks run. The automatic-updates check works only on systems that use apt. - It doesn't watch your server. It checks when you run it.
- It runs on Linux only. Windows Subsystem for Linux isn't supported yet.
Nothing leaves your server
Minaki Scan doesn't open network connections. It doesn't send your results, your server's name or anything else to us or to anyone. It doesn't need an internet connection to scan, and the license check planned for when sales open will run on your server too. Updates don't come through the scanner: your package manager, or our separate updater for other Linux, downloads them and checks their signatures.
To read your server's state, it runs a few standard system programs: sshd to read and test SSH settings, journalctl to read the SSH log, and systemctl to reload SSH after a fix or stop a malware service during a removal.
Why it runs as root
A full scan needs sudo because much of what matters is readable only by root:
- the password file (
/etc/shadow), to find accounts with no password; - other users' SSH key files and startup files;
- the details of every running program, to spot miners and programs running from deleted files;
- the SSH log, to spot password guessing.
Fixes need root too, because they change system settings and remove files that malware put in system folders.
You can run it without sudo. It tells you it isn't running as root, checks what it can, and lists what it couldn't check. Fixes always need sudo.