MariaDB在Debian下的安全加固参数

MariaDB 在 Debian 系统上安装完毕后，默认配置往往只考虑了基础的连通性，在安全层面留下了大量空白。直接用于生产环境，无异于将数据库暴露在风险之下。我们需要立刻着手调整一系列核心参数，这些参数不是锦上添花，而是安全基线。首先，也是最容易被忽视的一点，是数据文件在磁盘上的读写安全。在 Debian 下，MariaDB 的数据目录通常位于 /var/lib/mysql，默认权限是 755，属主为 mysql:mysql。这意味着同系统的其他用户虽然不能写入，但可能具备读取权限。如果你的系统存在多个用户，或者某个 Web 应用存在目录遍历漏洞，攻击者就有可能直接读取数据库的原始物理文件，从而绕过应用层的所有访问控制。因此，我们应当执行 chmod 750 /var/lib/mysql，严格限制其他用户的进入权限。

接下来，我们直接进入 MariaDB 的主配置文件。在 Debian 中，自定义的安全参数最好集中放置在 /etc/mysql/mariadb.conf.d/ 目录下，例如创建一个名为 99-security.cnf 的文件。这样既能保证配置被最后加载从而覆盖默认值，又便于集中管理和审计。所有后续的参数修改，都应在这个文件中进行，而不是直接修改 /etc/mysql/my.cnf。

数据库服务最大的暴露面就是网络端口。默认的 3306 端口是扫描器的重点目标。如果你的应用和数据库在同一台 Debian 服务器上，最彻底的防护手段就是禁止网络监听。在配置文件的 [mysqld] 节点下，添加 skip-networking=1 参数。这会让 MariaDB 完全忽略 TCP/IP 连接，只接受本地的 Unix Socket 连接。应用通过 localhost 连接时，会自动使用 Socket，速度更快且绝对安全。如果应用和数据库必须分离部署，那么必须开启网络监听，但绝不能绑定 0.0.0.0。请使用 bind-address=你的内网IP 来精确指定监听的网卡接口，避免数据库服务意外暴露在公网网卡上。同时，立即修改默认端口，虽然安全不能仅靠隐蔽，但变更端口可以过滤掉 99% 的自动化扫描噪音。设置 port=3307 或其他高位端口，能显著降低被随机攻击命中的概率。

任何一个客户端都可以尝试无限次连接，这为暴力破解和拒绝服务攻击敞开了大门。我们需要配置一系列参数来收紧连接行为。max_connect_errors 是一个关键的防护阀值。当某个主机的连接错误次数超过此值，MariaDB 会直接屏蔽该主机的后续请求。设置 max_connect_errors=100，可以有效地阻断持续的暴力破解尝试。同时，max_connections 必须根据业务实际并发量进行限制，而不是使用默认的 151。一个过大的连接数会让攻击者轻易耗尽服务器内存。通过计算 (最大物理内存 - 系统与其他服务占用) / 单个连接预估内存，得出一个合理值，例如 max_connections=200。此外，connect_timeout 定义了客户端握手超时时间，默认为 10 秒，在可能遭受 SYN Flood 类攻击时，将其降低到 5 秒可以更快地释放半连接资源。这些参数组合在一起，构成了第一道资源防线。

安装完成后，系统中存在匿名用户、无密码的 root 账户以及 test 数据库，这些都是巨大的安全隐患。虽然 mysql_secure_installation 脚本可以处理一部分，但作为系统管理员，我们必须清楚每一步的 SQL 逻辑，并确保执行到位。首先，以 root 身份通过 Socket 登录后，执行以下 SQL 语句来彻底清除匿名用户和危险数据库。

DELETE FROM mysql.global_priv WHERE User='';
DROP DATABASE IF EXISTS test;
DELETE FROM mysql.db WHERE Db='test' OR Db='test\_%';

接下来，要审视所有用户的认证插件。在 Debian 的 MariaDB 10.3 及以上版本中，root 用户默认可能使用 unix_socket 认证，这虽然安全，但有时会给管理脚本带来困扰。如果需要为 root 设置强密码，务必使用 ALTER USER 命令。更重要的是，要检查所有应用账户，强制它们使用安全的认证插件，如 mysql_native_password 或更安全的 ed25519。对于所有账户，都必须严格执行最小权限原则。严禁给应用程序账户授予全局权限，比如 GRANT ALL ON *.*。必须将权限细化到具体的数据库级别，甚至表级别。例如，一个只需要从 users 表读取数据的应用，其权限应为 GRANT SELECT ON myapp.users TO 'appuser'@'host'。定期检查 mysql.user 和 mysql.db 表，确保没有账户拥有多余的 Grant_priv 或 Super_priv 权限，这些特权一旦被滥用，后果是毁灭性的。

没有日志的安全是空中楼阁。在 MariaDB 中，我们必须开启并妥善配置日志系统。首先，general_log 记录了所有客户端连接和执行的查询，在性能敏感的生产环境，它可以作为短期排查手段按需开启，但不建议长期运行。真正的核心是错误日志和慢查询日志的安全配置。对于审计至关重要的，是 log_warnings 参数，建议设置为 2，它会将连接错误、拒绝访问等详细信息记录到错误日志中。更重要的是，从 MariaDB 10.3 开始，我们可以利用服务器审计插件。在配置文件中添加以下行来加载审计插件并指定日志路径。

plugin_load_add = server_audit
server_audit_events=CONNECT,QUERY,TABLE
server_audit_logging=ON
server_audit_file_path=/var/log/mysql/audit.log
server_audit_file_rotations=10
server_audit_file_rotate_size=1000000

这会将所有连接、查询和表操作记录到专用的审计日志中。务必确保 /var/log/mysql/ 目录的权限是 750，属主为 mysql:adm，这样既能防止非授权访问，又能让系统管理员通过 adm 组读取日志。日志文件的轮转和保留策略也必须提前规划，避免因磁盘写满导致服务中断。

即使在内网，数据传输也不应是明文的。任何跨服务器的数据库流量都必须被加密。在 Debian 上，我们可以使用 OpenSSL 生成自签名证书，或者部署由内部 CA 签发的证书。生成证书后，在配置文件中指定路径。

ssl-ca=/etc/mysql/ssl/ca.pem
ssl-cert=/etc/mysql/ssl/server-cert.pem
ssl-key=/etc/mysql/ssl/server-key.pem

仅仅配置服务端还不够，我们必须强制所有远程连接使用 SSL。对于用户账户，在创建或修改时，应添加 REQUIRE SSL 子句。例如：ALTER USER 'appuser'@'192.168.1.%' REQUIRE SSL;。对于不需要 SSL 的本地 Socket 连接，这个限制不会产生影响。更进一步，如果你的所有客户端都支持，可以要求验证客户端证书，使用 REQUIRE X509 或 REQUIRE ISSUER 和 REQUIRE SUBJECT 来实现双向认证，这能彻底杜绝中间人攻击和未授权的客户端接入。

MariaDB 进程本身的运行权限也需要限制。永远不要以 root 用户运行 mysqld。Debian 包安装的 MariaDB 已经使用 mysql 用户运行，但我们要确保这个用户的 shell 被设置为 /usr/sbin/nologin 或 /bin/false，并且不能用于登录系统。通过 usermod -s /usr/sbin/nologin mysql 来锁定该账户。此外，利用 Debian 的 AppArmor 强制访问控制系统，可以为 MariaDB 提供内核级的防护。确保 apparmor 服务正在运行，并检查 /etc/apparmor.d/usr.sbin.mysqld 配置文件。这个文件定义了 mysqld 进程能访问的文件路径和权限。如果你更改了数据目录、日志路径或临时文件路径，必须同步更新 AppArmor 规则，否则服务将无法启动。这种白名单机制意味着，即使 MariaDB 进程被攻破，攻击者也无法在系统上执行任意命令或访问数据库目录之外的文件。

最后，一个常被忽略的细节是 LOAD DATA LOCAL 语句。这个功能允许客户端读取本地文件并插入到数据库，如果应用存在 SQL 注入漏洞，攻击者可以利用此功能读取服务器上的敏感文件，如 /etc/passwd。在服务端配置文件中，设置 local-infile=0 来彻底禁用此功能。如果应用确实需要从服务器本地加载数据，应改为使用 LOAD DATA INFILE，并严格控制文件权限。完成所有配置修改后，重启 MariaDB 服务，并立即检查错误日志，确认所有参数都已正确加载且没有权限错误。安全加固不是一次性的工作，而是一个持续监控和调整的过程。将这些参数纳入配置管理，并定期根据安全公告进行审查，才能维持数据库的长期安全状态。