mirror of
https://github.com/Cacti/documentation.git
synced 2026-10-25 04:27:20 +09:00
* docs: comprehensive audit, Spine poller overhaul, and technical refactor - Overhaul Spine documentation (Spine.md) with complete end-to-end guide: architecture, prerequisites for modern distros (EL8/9 CRB, Ubuntu 22/24, Debian 11/12, FreeBSD), SUID root permissions, secure spine.conf setup (0640), Web UI configuration (Paths, Poller type, Data Collectors tuning), MySQL max_connections sizing, and troubleshooting. - Fix broken links and anchors (Hardening, SNMP data queries, Hook API references). - Fix broken image reference in Sites.md (add-site.JPG -> add-site.png). - Fix syntax errors in documentation PHP code blocks, including invalid parenthesization, missing SQL execute quotes, and malformed comments in FAQ. - Fix DevOps installation commands: use config.php.dist, correct systemctl service names for MySQL/MariaDB/PHP-FPM, remove nonexistent php-json, add missing composer install, and correct Debian/Ubuntu systemd environment path. - Correct grammatical errors, repeated words, and typos across all markdown documents. - Remove obsolete unreferenced duplicate installation guides. Signed-off-by: Thomas Vincent <thomasvincent@gmail.com> * docs: correct reviewed examples and guidance Signed-off-by: Thomas Vincent <thomasvincent@gmail.com> * docs: correct guidance that disagrees with the Cacti source Verified each claim against include/global_arrays.php, lib/auth.php, lib/functions.php, host_templates.php and the Spine config parser. The notable ones: api_plugin_safe_exec() does not exist on either branch, Spine reads DB_Pass rather than DB_Password, and the CDEF special data source table was missing five entries and renamed four others. Signed-off-by: Thomas Vincent <thomasvincent@gmail.com> * docs: wrap Spine prose and fence the connection sizing formula The formula's bare asterisks rendered as emphasis, dropping the multiplication signs. Signed-off-by: Thomas Vincent <thomasvincent@gmail.com> * chore: refresh copyright year in scripts and issue templates Signed-off-by: Thomas Vincent <thomasvincent@gmail.com> --------- Signed-off-by: Thomas Vincent <thomasvincent@gmail.com>
114 lines
4.2 KiB
Markdown
114 lines
4.2 KiB
Markdown
# Security
|
|
|
|
## General Validation
|
|
|
|
Never trust input regardless of where it is coming from! The responsibility
|
|
falls on the library functions to ensure that potentially dangerous input does
|
|
not introduce a security hole. Some sort of sanitization, validation, or quoting
|
|
must be provided for **all** arguments in a function. This ensures that bad
|
|
data does not make its way into an SQL string, a filename, an executable, or
|
|
even another function.
|
|
|
|
## Request Validation
|
|
|
|
For Plugin Developers, Cacti includes settings to allow you to know when
|
|
you are using unvalidated data. They include:
|
|
|
|
* get_filter_request_var('somevariable') - This function call, by default,
|
|
will validate that the variable `$_REQUEST['somevariable']` returned
|
|
is actually an integer, if not, Cacti will block the page
|
|
function from continuing.
|
|
|
|
* get_filter_request_var('somevariable', $filter, $options) - The second
|
|
argument is a PHP filter constant such as `FILTER_VALIDATE_INT` or
|
|
`FILTER_VALIDATE_REGEXP`, and the third is the matching options array.
|
|
This form covers the rest of the verification and sanitization cases.
|
|
|
|
* set_request_var('somevariable', 'somevalue') - This function will set
|
|
the Cacti request variable superglobal with a value.
|
|
|
|
Generally speaking, you should never use `$_GET`, `$_POST` or `$_REQUEST`
|
|
directly in your Cacti code. Use the validators. When you do, you can
|
|
turn on the Cacti setting `Log Input Validation Issues` when you are
|
|
developing, and your Cacti log will include warnings when an invalid
|
|
variable has been encountered.
|
|
|
|
## OS Command Injection
|
|
|
|
Never pass unsanitized input to shell execution functions (`exec()`,
|
|
`shell_exec()`, `system()`, `passthru()`, `popen()`, `proc_open()`). Device
|
|
fields, OID strings, community names, and any other user-influenced values
|
|
must be treated as untrusted.
|
|
|
|
Escape every argument with Cacti's `cacti_escapeshellarg()` rather than the
|
|
PHP `escapeshellarg()` directly. The Cacti wrapper strips carriage returns
|
|
and line feeds, and it quotes correctly on both Unix and Windows, where
|
|
`escapeshellarg()` blanks out percent signs that RRDtool format strings need.
|
|
Where a whole command string has to be escaped, use `cacti_escapeshellcmd()`.
|
|
Neither function is a substitute for validating the value first: resolve
|
|
binaries from a fixed path and check arguments against an expected pattern
|
|
before the command is built.
|
|
|
|
## Prepared Statements
|
|
|
|
The second method of hardening your Cacti application is through the use
|
|
of prepared SQL statements. A prepared statement sends the query and the
|
|
values separately, so a value can never be parsed as SQL. This removes the
|
|
injection risk that string interpolation creates.
|
|
|
|
Examples of a non-prepared call and its prepared equivalent:
|
|
|
|
```php
|
|
$somevalue = db_fetch_cell("SELECT COUNT(*)
|
|
FROM host
|
|
WHERE id = $somevariable");
|
|
```
|
|
|
|
In the case above, it would be very easy to exploit Cacti. The example
|
|
below is the correct way to protect against attacks.
|
|
|
|
```php
|
|
$somevalue = db_fetch_cell_prepared('SELECT COUNT(*)
|
|
FROM host
|
|
WHERE id = ?',
|
|
array($somevariable));
|
|
```
|
|
|
|
## Output Escaping
|
|
|
|
Cacti provides an escaping function to reduce the likelihood of XSS
|
|
vulnerabilities in Cacti leading to exploitation of other websites.
|
|
Cacti itself has a restrictive XSS mitigation policy in effect
|
|
by default, but proper output escaping still matters.
|
|
|
|
The following examples show how, and how not, to escape output:
|
|
|
|
```php
|
|
print "<tr><td>" . $some_variable . "</td></tr>";
|
|
```
|
|
|
|
The print statement above can lead to Stored XSS in your code whenever the
|
|
value comes from the database. Use the following instead:
|
|
|
|
```php
|
|
print "<tr><td>" . html_escape($some_variable) . "</td></tr>";
|
|
```
|
|
|
|
## JavaScript Validation
|
|
|
|
Relying on JavaScript-based validation is nice for instant feedback to the
|
|
user, but should not replace validation checking in the PHP code.
|
|
|
|
If you follow the simple rules above, your Plugin will be much safer
|
|
for others to use and will more easily pass internal security and
|
|
pen tests.
|
|
|
|
## See Also
|
|
|
|
For OS-level hardening controls covering file permissions, web server access
|
|
restrictions, PHP-FPM pool settings, SELinux, and AppArmor, see
|
|
[Hardening a Cacti Installation](Hardening-Cacti-Installation.md).
|
|
|
|
---
|
|
Copyright (c) 2004-2026 The Cacti Group
|