My Server Health Check Scripts, and config repository

The primary purpose of these scripts is to perform server audit checks. There are only two scripts, one to collect data from a server which should be sent to another server for processing, and the actual processing script. The processing script will build html reports for all servers that had collector output sent to the procesing server.

The config part is simply because it has an option to record installed packages as part of the data collection so I have a record of what is needed to rebuild a server. It also collects a full hardware listing (if hardware display packages are installed).

The scripts support rhel family servers (Rocky, Alma etc) and Debian servers. It also now handles SunOS (OpenIndiana) for all checks except two, the firewall port open checks (IPF firewall checks not implemented, only iptables and netfilter) and as SunOS/OpenIndiana does not use SeLinux that of course is not implemeneted for SunOS.
[note: working on Debian does not mean it includes Ubuntu or derivitives as they digress too much from Debian :-)];

Processing script notes

All reporting against the collected information should be done on a dedicated machine with a web server running on it to make it easy to view the reports as the reports produced are html pages starting with an overview page of all servers status and total exception counts and drill down to details of the exceptions found for each server.
The processing script is also very CPU intensive.

As each server is likely to need different defaults individual customisation files can be created per server named custom/hostname.custom (with a default ALL.custom used if no explicit server customisation file exists).
These customisation files support include files, so for hostname.custom files the first include line would be something like "INCLUDE ../custom_includes/sever_Debian13|Debian12|Alma|OpenIndiana" etc. to set a decent base default ruleset for the server.
And then include applications unique to the server that do not belong in a full default ruleset, such as "INCLUDE ../custom_includes/mariadb_server" may only be needed on a few servers so would not be included in a base ruleset or alerts would be raise on servers not running mariadb; some include files are provided.

• it checks for bad file permissions and ownership on all files to the recursion depth permitted by the operating system (although a max directory depth can be passed as a parameter to the collection script if you want to limit the checks)
• it checks all open TCP and UDP ports in use against ports expected to be open (tcp/tcp6/udp/udp6/raw/raw6) including listing the process that actually has the port open. Also reports on any custom file entries expecting a port open that may be obsolete (if the port was not actually in use at the time the data was collected)
• checks server firewall rules to report on any open ports in the firewall rules and alert on those that have no matching listening port on the server (locates obsolete firewall rules to clean up); excluding SunOS where ipf is not yet handled
• checks various security files in /etc for sensible default settings; password defaults, sshd configs (listenaddress, permitrootlogin, banner, any scripts run whenh users connect etc), whats in motd, and lots more config files
• cron job checks, that cron+at allow or deny files exist, that every script run by a crontab is only able to be updated by that user etc. (ie: so nobody can insert commands into scripts run by root). Note: only checks files in crontab directory currently (not yet cron.d/cron.daily etc)
• checks all suid files on the system to ensure no new ones appear unnoticed
• user checks, homedir perms, .ssh perms, who has authourized_keys files, who has scripts that automatically run on a ssh connection, no missing users in ftpusers etc.
• special checks implemented to ensure webserver files are read-only (optional)
• and does a lot more

Important: the most recent stable version of this toolkit is most likely to be the one in my shell scripts repository on github, not on this webserver. Incremental changes/fixes and enhancements are pushed there more frequently than the files here are updated.

The latest dowload tarball (version 0.28) (released 31 May 2026) is available if you are interested. A copy of the documentation for the toolkit is available online here, this documentation is for the old version 0.25.

No matter how tightly you think you have locked down your server(s) I would be supprised if there were not at least hundreds if not thousands of exceptions found when using these scripts for the first time.

After processing there is a menu for all servers with a summary of insecurities found, permitting drill-down to each individual servers summary results be check section.
From version 0.08 onward this page also shows (dates in yellow) servers that have new collected data files available since the last processing was done for the server; which can be also be displayed with the '--checkchanged=list' option and processed with the '--checkchanged=process' option
From version 0.11 onward servers that have not had fresh data collected in the last 14 days are alerted on, as you should have automated collection/processing of these checks. From version 0.12 onward the 14 days limit has been made customisable per server and shown on the main index page in the snapshot date column.
Below is an example of the 0.28 index page.
Of note is where in the alerts column there is a (n) listed that is a configured exact match of alerts to expect (that will not be corrected) and if there is only those matched the alerts field in the main index will be green [OK], only if there are unexpected alerts will the number of alerts in that column be red.

From the main index page you just click on the link of the server name to look at each server. From each individual server summary page you can see a summary of insecurities found for each section of the checks, and drill-down to a detailed report for each section.

Please note this is being actively maintained, the latest will always be on github not here. This copy was last updated on 31May2026.

It should also be noted that as a general rule each new version will take longer to run than the previous version as additional checks are added; although obviously this depends on what your servers are used for (a web server with 200,000+ files to be checked obviously takes longer than a tftpboot server with 25,000 files to be checked so you probably won't notice much difference on servers with a large number of files).

You should always use the latest version for bug-fixes and enhancements. Upgrading to a new processing version will always require a full re-processing of all servers (although existing old collector files can be used for the re-processing although some information for a server will be unavailable in that case so there is the probability of false alerts due to data expected in later versions not present in files collected by older collector versions).