网管员世界—MySQL数据库安全配置与加固

MySQL 数据库安全配置

MySQL 数据库基本安全配置

1. 操作系统的安全

要想保护正在运行MySQL 的主机的安全，不妨参考以下几个指导原则：

（1）部署IPTables（Linux）、IPFfilter（Solaris）或者MySQL 服务器上其他一些基于主机的防火墙软件。

大多数Linux 的发布版本都内置了IPTables，Linux 内核中的报文筛选和操纵都是高度可配置的架构，配置起来并非想象中那么难，但是需要花一番工夫。

（2）使用低特权的MySQL 账户运行MySQL 进程。在某些操作系统上这是默认的，但也有些不是。尤其在Linux 和UNIX 主机上，不要以nobody（举例）身份运行MySQL 是很重要的，因为其他进程可能也用这个账户运行，例如，Apache。这是因为如果多个进程共

享同一个账户，一个进程被攻击意味着它们全都会被攻击。例如，Apache和MySQL 都以nobody 的身份运行，控制Apache 的任何人都可以控制MySQL 数据库。

（3）使用chroot 选项运行mysqld。这在Windows 下无法工作，但在Linux 上，chroot 提供了优秀的文件特权缓冲区，它通过给定目录下的进程来限制文件访问，这意味着在MySQL 下，可以确保攻击者没有能力去读或去写操作系统的配置文件或主机上其他守护进程的配置文件。

要记住，即使有了chroot 选项，拥有文件特权的攻击者还是能够读所有MySQL 数据，而且（很可能）仍然能够创建和执行UDF。

（4）确保MySQL 用户无法访问有限目录集以外的文件，特别是禁止MySQL 用户阅读操作系统的配置文件。这在某些情况下，可以防止MySQL 用户自行修改MySQL配置文件。

可以通过创建适当的组、分配对MySQL 目录适当的权限等方式，阻止MySQL 影响操作系统的其他部分。

（5）保证MySQL 数据文件（一般在MySQL data 目录下面）不能被root，以及MySQL 正在运行的账户之外的用户阅读。为安全起见，要保护MySQL 不被本地主机上的其他用户攻击，并要保护操作系统免受MySQL 的影响。

（6）明文证书。确保除了MySQL 用户以外，没有哪个用户能够阅读MySQL 的任何配置文件和日志文件。文件https://www.360docs.net/doc/643081775.html,f、my.ini、https://www.360docs.net/doc/643081775.html, 通常有明文用户名和口令，查询日志文

件（如果存在）很可能包含口令。基于您所配置的日志等级及主机是否参与复制，在某些MySQL 配置文件中，可以有明文的用户名和口令。为了保护这些证书，应该确保这些文件对于主机上的其他用户来说是受保护的。

（7）关闭不必要的服务或守护进程。主机上攻击者能够访问的组件越多，攻击者从这些组

件发现机会进而入侵主机的可能性就越大。相反，如果需要管理的组件越多，花了越多的精力，那么出错的可能性也越大。

使主机的配置相对简单一点，会降低出现问题的概率。

（8）确保.MySQL_history 文件中没有您自己的任何内容。在Linux 系统的默认情况下，会在home 目录下发现一个.MySQL_history 文件，它包含了您在MySQL 命令行客户端中键入的所有查询日志。

定期将其进行清空，或者永久性地链接到/dev/null 目录。

2. MySQL 用户安全配置

一旦操作系统受到保护，就需要锁定MySQL 本身。这样做的第一步就是准备用户账户和特权模型。

（1）为root@localhost 账户设置一个―强健‖的口令。这样做的原因很明显：在MySQL 中并不存在多次输错口令后将用户锁住的机制，因此，对于MySQL 用户名和口令的brute-force

攻击是很有效的，而设置一个―强健‖的口令能够预防攻击者的猜测口令行为。

（2）删除所有非root 的MySQL 用户。在初始安装阶段，了解哪些用户能够访问数据库是非常重要的，尽量将这些用户从最核心（root 账户）处剥离，然后建立您所需要的用户。

（3）将MySQL 的root 用户重命名为较复杂的名字。root 账户在MySQL 中是一个非常著名的用户名，很多公开可用的工具、脚本、开发都是基于拥有root 账户这个事实的。

MySQL 使用root 这样的名字并无特别含义，所以不妨将MySQL 的root 用户重命名为一些复杂的名字：

1 update https://www.360docs.net/doc/643081775.html,er set user='MySQL_

2 admin' where user='root';

（4）如果启用了远程连接，那么在建立用户时要指定GRANT 语句中的REQUIRE SSL。这是一个较复杂的配置过程，会为特殊用户在连接时执行SSL 加密。

这样做有以下好处：首先保证用户所写的开发脚本不会起作用；第二，保证了口令盘问/ 回答的顺序。根据具体情况，可以通过使用客户机证书施加限制，来进行SSL验证。这是高

度安全的，因为关于口令的简单知识是完全不够的，必须有特定的证书才行。

（5）为每个Web 应用创建一个MySQL 用户, 如果可能的话，为Web 应用中的每个角色

创建一个用户。例如，可以有一个MySQL 用户用来更新表格，另一个低特权的用户用来从表格中进行―选择‖。

根据具体应用将各种角色分解为各用户账户，这个过程可能比较乏味，但它具有很好的安全意义。它意味着如果攻击者能够攻击某个应用程序，那么将会调整组件的特权以使攻击者受到限制。例如，攻击者也许能读某些数据，但无法进行更新。

（6）确保MySQL 用户都能受IP 地址限制，也能受口令限制。一旦嵌入MySQL 配置，那么考虑一下限制用户的IP 地址，使用户无法自行验证。

这是MySQL 一个非常有用的特点，其他数据库则没有。这样，攻击者在试图攻击MySQL 服务器时，您就在他们面前设置了又一个障碍，使他们无法直接攻击服务器，只能去攻击其他一些特定的主机，以便连接到您的数据库服务器。

在攻击者面前设置的障碍越多越好。利用IP 地址而不是主机名会更难控制，但这样做要安全得多。

当指定一个用户仅能从某些主机名或域登录时，MySQL 就必须检查IP 地址来判断其是否在相应的域中。通常这种查找是通过DNS 来实现的，攻击者可能攻击您的DNS 服务器，或是模拟它的响应，以便让MySQL 服务器相信它正在允许的域中与一个机器进行对话（实际上却不是）。

然而，如果使用IP 地址，攻击者就必须伪造3 次TCP握手过程中的客户机一方，以此来伪造一次连接及数据传输，这会更困难。如果可以的话，不妨对IP 地址进行一些限制。

（7）如果账户不一定需要，不要随便给予账户特权，特别是File priv、Grant priv 和Super priv。如果必须与MySQL 下的文件系统相互作用，那么考虑创建一个单独的MySQL 账户，这样就可以进行应用了。记住，这个账户可以阅读MySQL 的所有数据，包括口令散列。对于攻击者来说，如果他知道口令散列值的话，那么以root 的身份登录将会非常简单。

在MySQL 4.1 版本以前的版本中，将File_priv 交给用户与将root 口令交给他们是

同样的效果，这样即可通过如下代码从https://www.360docs.net/doc/643081775.html,er 表格读取口令散列：

select load_file('./MySQL/user.MYD');

一旦他们知道了口令散列，只要稍微修改一下MySQL客户端，就能以自己选择的身份轻易

登录。其他特权同等危险。

（8）不要让任何人进入https://www.360docs.net/doc/643081775.html,er 表格（除了root和用来调用root 的账户）。

在4.1 版本以前的版本中，直接登录MySQL 就可以使用存储在表格中的口令散列——并没

有使用蛮力的必要。这些MySQL 表格（user、db、host、tables_priv 及columns_priv）在MySQL 中能控制特权模型。

GRANT 和REVOKE 语句会修改这些表格。如果用户有权写这些表格，他们就能让任何人有

任何想要的特权。

在4.1 版本以前的MySQL 版本中，如果能从用户表格中读取口令散列，就能以其他任意用

户的身份登录。

MySQL 数据库安全加固

1. 安全加固配置

一旦用户和特权问题得以解决，我们还有其他配置方面的修改需要去做。

（1）通过设置log 选项来允许记录日志。

在MySQL 文档中―general query log‖被认为是调试时的一个特色，但您可能更愿意将它用作安全布防的一部分。它能记录成功连接和每次执行的查询，虽然并不记录这些查询的结果或

返回的数据，但可以提供给您线索。例如，谁在您的数据库上做了什么，所以值得对该配

置进行修改。

查询日志在默认情况下是禁用的，必须使用log 选项将它激活。

记住，对于一个管理员来说，即使完整的查询日志是一个没有价值的资源，但它对于攻击者

来说却是一个非常丰富的信息来源。如果日志存在，就会包含一些口令或者其他敏感信息。

应该保证日志文件仅仅对MySQL，以及系统上正在查询的管理员账户（或者root）可见。

另一个关于查询日志的有趣问题就是，任何拥有FILE特权（file poriv）的账户一定可以通

过执行下列语句读取日志文件。

1 select load_file('query.log');

（假设日志文件名为query.Log）。这是避免给人们FILE 特权的另一个绝佳理由。

（2）通过在https://www.360docs.net/doc/643081775.html,f 文件中加入set.variable=local.infile=0 来禁用LOAD DA TA LOCAL INFILE 命令。

LOAD DATA LOCAL INFILE 是LOAD DATA 语句的一个变体，它允许客户机直接从本地文件系统中的文件上传数据至MySQL 表中。这可能会被攻击者在某些情况下用以在客户机主机上阅读文件。

假设一个Web 服务器正在运行一个易于被进行SQL注入的PHP 应用程序，如果这个Web 应用所连接的MySQL 服务器允许―载入数据本地写入文件‖，那么攻击者就能从Web 服务器上传数据至MySQL 服务器中，这样攻击者就能任意地分析它了。

（3）删除任何不用的UDF。

UDF 可能产生出乎意料的危险，MyPHP、MyPERL、MyLUA 等都允许攻击者通过一些简单的脚本命令在服务器上大肆扩展自己的控制权。如果您没有使用UDF，却在MySQL.func 表格中看见了它们，应当立即删除。

（4）如果仅仅使用本地连接，可通过设置--skipnetworking选项来禁用TCP/IP 连接。因为有时远程主机没有必要去连接MySQL，这时最好通过指定--skipnetworkingoption 选项来禁用网络支持。

（5）根据具体的操作系统及数据目录的配置情况，可以通过设置--skip-symbolic-links 选项来禁用符合链接。

MySQL 的symbolic 链接在Windows 平台上以受限制的方式得到支持，限制包括创建一个名为.sym 的文件，以及创建通往数据库所有表格文件所在目录的路径。

在Linux 系统上，symbolic 链接会导致一些问题。如果用户能够修改一个symbolic 链接，就能与文件系统互相作用，使真正的MySQL 用户也受到限制。

（6）删除默认的测试数据库。

在默认情况下，测试数据库是存在的，应将该数据库删除。它能访问的有效数据库名字可能对攻击者有用，所以默认的测试数据库应该删除。

（7）确保MysQL 通信量是加密的。

在默认情况下，MySQL 流量是不加密的，这意味着如果攻击者能在客户机和服务器之间建立的连接上进行窃听，就能获取用户名和口令盘问／回答序列。如果正在运行一个4.1 版本以前的MySQL，很可能由盘问／回答序列来决定口令散列。这个过程在4.1 版本的MySQL

中比较困难，但仍然是可行的。4.0 以上版本的MySQL 支持客户机和服务器之间连接上的SSL 加密，这就使口令蛮力攻击几乎不可行了。对此进行配置，就是使用--SSL 选项以及其他相关的SSL 选项。

实际正在使用的保证SSL 连接的最好方法就是指定GRANT 语句中的REQUIRE SSL 语句，或者手工设置https://www.360docs.net/doc/643081775.html,er 表格中的ssl_type 域。

2. MySQL 的安全例行审计

一旦所有内容都启动且正在运行，就不应该在不管理的情况下让MySQL 独自运行。

如果一级防范进行得充分，就会很好地防御攻击者，但是知道有人正试图攻击您将会很有帮助，即使他们没有成功。也许他们会以某个0 day 溢出攻击的方式返回，下一次尝试攻击时就能成功了。因此，保持警惕是关键。

0 day 是指一些没有公布补丁的漏洞或没有被漏洞发现者公布出来的漏洞利用工具。这种漏洞的利用程序对网络安全具有巨大威胁，是入侵者的最爱。

（1）检查日志。

如果已经用log 选项配置了查询日志，您应该定期查看正在发生些什么事情。特别查看是否有一些常用的SQL注入攻击，并且使用load file、infile 及outfile 的文件系统语法。

定期检查错误日志文件也很重要，尽管它们提供的信息没有查询日志多。

记住，与日志进行交互时，日志数据是调试敏感的。如果正把它引入到其他存储库（例如数据库）进行分析，查询日志可能包含用户名和口令。

（2）定期计算用户数，并且使用show grants 语句查看哪些特权授予了哪些用户。

例如：

1 MySQL> select user, host from

2 https://www.360docs.net/doc/643081775.html,er;

3 +-------+-------+

4 | user | host |

5 +-------+-------+

6 | goocjh | % |

7 | root | localhost |

8 +-------+-------+

您可能发现在上面的数据库中有两个用户：root@localhost 和goocjh，其中goocjh 能从任意主机登录，但仅在测试数据库上有选择的特权。

另外，您也可能发现在用户表格的password 字段中goocjh 和root 有相同的口令。

（3）周期性地对口令散列进行一些快速检查。

MySQL 中的散列值是没有加密的，这意味着同样的口令总是散列到同一个值。如果使用：

1 MySQL> select user, password from

2 https://www.360docs.net/doc/643081775.html,er;

3 +-------+-------+

4 | user | password |

5 +-------+-------+

6 | root | 5d2e19cc5ef6

7 |

7 | goocjh | 5d2e19c5ef67 |

8 +-------+-------+

9 2 rows in set (0.00 sec)

就会看到哪些账户拥有相同的口令。在这种情况下，goocjh 和root 具有相同的口令（偶尔

会是―password‖）。显然，这并不是人们所希望的安全设置。

3. 了解MySQL 安全信息

如果想了解攻击者，那么拥有最新的信息来源是非常重要的。下面是一些关于MySQL 安全方面非常好的阅读材料指南：

（1）MySQL AB 有一支非常敏感的安全团队，他们会将第三方查明的信息及bug 报告反馈在文档中。这些关于MySQL 的安全文档都很不错，综合性强，容易理解，不妨当作搜集MySQL 安全材料的第一选择。

（2）经常访问，并且检查更新。MySQL 会频繁发布新版本。当发布新版本时，会有一个

非常综合的变更日志，其中详细记录了新版本中新增的或是修改过的内容。如果对日志感兴趣，可以进行仔细的阅读。

当然，是否需要更新版本是由用户自己来决定的。

如果您正在一个项目的某个阶段，它使您有时间决定DBMS，并且您正在关注MySQL 的话，那么这将帮助您进一步理解哪一个版本有哪些特色及旧版本中有哪些bug。

（3）了解您的bug。有规律地检查脆弱数据库，如SecurityFocus https://www.360docs.net/doc/643081775.html,）及NVD（https://www.360docs.net/doc/643081775.html,），看是否有MySQL bug，并且订阅安全邮件列表，如VulnWatch、BugTraq 及MySQL 邮件列表等。

SecurityFocus 及CVE 都是安全漏洞方面非常优秀的信息来源。订阅安全邮件列表也是一个好主意，因为每个人（通常是某些人）会在MySQL 中发现安全bug，这些bug会被随机地

直接发送到邮件列表。

https://www.360docs.net/doc/643081775.html, 是一个与安全相关的新闻和信息的专门站点，其中包括有关一般问题和

特殊问题的最新文章，还有一个由有益的论文构成的内容广泛的技术库。而NVD 标准数据库中所有CVE 命名的漏洞条目均支持通命名的漏洞条目缺陷评估系统CVSS，并提供CVSS

漏洞分级之一的漏洞基准值。

基于您自己的特定环境，应当认识到，最好的方法就是一旦有信息公布就立即关注这些问题，而不是等待发布补丁。