Archive the non-ported remainder of the legacy KNELServerBuild repo
under archive/KNELServerBuild/ with its original structure intact,
completing the legacy repo merge for everything except the live
LibreNMS patterns (ported in the previous commit).
Exclusions:
- .git history (superseded; legacy repo remains at its original path)
- ported files (Agents/librenms, Modules/OAM/oam-librenms.sh,
ConfigFiles/SNMP/snmp-sudo.conf)
- vendored KNELShellFramework tree (byte-identical duplicate of the
copy already vendored at vendor/ in this repo)
- SSH authorized-keys files (live access-control material; carrying
them in an archive invites drift — key policy lives elsewhere)
The whole tree is skip-listed in tests/shellcheck.sh (archived legacy
code, not maintained — same standing as vendor/); check-rules.sh
already prunes archive/. Rule 9 (conflict markers) now also excludes
archive/ staged files: preserved-verbatim legacy scripts contain
decorative "====" banners that false-positive as conflict markers
(same archive exclusion precedent as rule 11).
AGENTS.md: note archive/KNELServerBuild and oam/librenms-agent in the
Repository Layout, and fix the stale KNELIAC path to
/home/reachableceo/projects/KNEL/KNELIAC.
💘 Generated with Crush
Assisted-by: Crush:glm-5.2
28 lines
2.3 KiB
Markdown
28 lines
2.3 KiB
Markdown
# AI Security Audit of KNELServerBuild
|
|
|
|
This is an AI-generated security audit of the KNELServerBuild project. The analysis is based on a read-only review of the project's files.
|
|
|
|
## Summary of Findings
|
|
|
|
The KNELServerBuild project has a good security posture overall, but there are a few areas that could be improved. The most significant finding is the presence of SSH authorized keys in the repository. This is a security risk, as it allows anyone with access to the repository to know which public keys are authorized to access the servers.
|
|
|
|
### High-Risk Findings
|
|
|
|
* **SSH Authorized Keys in Repository:** The `ProjectCode/ConfigFiles/SSH/AuthorizedKeys` directory contains SSH authorized keys for the `localuser` and `root` users. This is a security risk, as it allows anyone with access to the repository to know which public keys are authorized to access the servers.
|
|
|
|
### Medium-Risk Findings
|
|
|
|
* **Hardcoded Hostnames:** The scripts contain several hardcoded hostnames for services like Postfix, NTP, syslog, and Wazuh. This is not a direct security risk, but it does represent a configuration management issue. If any of these hostnames change, they will need to be updated in multiple places.
|
|
|
|
### Low-Risk Findings
|
|
|
|
* **Potential for Password on Command Line:** The `ProjectCode/Agents/librenms/mysql.sh` script has a `--pass` argument for a MySQL password. This is a potential security risk if the password is provided on the command line, as it could be logged in the shell history.
|
|
|
|
## Recommendations
|
|
|
|
* **Remove SSH Authorized Keys from Repository:** The SSH authorized keys should be removed from the repository and managed using a secrets management tool like HashiCorp Vault or AWS Secrets Manager.
|
|
* **Use Variables for Hostnames:** The hardcoded hostnames should be replaced with variables that are defined in a central configuration file. This will make it easier to update the hostnames if they change.
|
|
* **Avoid Passwords on Command Line:** The `ProjectCode/Agents/librenms/mysql.sh` script should be modified to avoid passing the MySQL password on the command line. For example, the script could prompt the user for the password or read it from a configuration file.
|
|
|
|
Overall, the KNELServerBuild project is a good starting point for an IAC repository. By addressing the security risks identified in this audit, the project can be made more secure and reliable.
|