MySql日志审计配置与分析实战 – 作者:ofei

前言

mysql安全基线配置有很多文章讲过，mysql日志分析的文章却比较少。前段时间刚好遇到mysql数据库的勒索病毒，日志分析的时候发现了之前没有注意到的地方，本文就通过搭建模拟环境，配置mysql数据库安全审计插件，基于审计插件的数据结合其他日志，对常见的数据库攻击如暴力破解、SQL注入、命令执行进行审计日志分析，尝试还原攻击场景及追溯攻击源。

一、Mysql审计配置

1、审计方法选择

使用数据库审计插件开启数据库审计会牺牲部分数据库性能，建议根据实际业务情况选择审计插件或旁路部署审计设备。

常见的mysql免费审计插件：mariadb  audit plugin, macfee  mysql-audit

我们以mariadb audit plugin为例来完成配置安装与分析。

2、审计插件安装与配置

环境：windows server 2008 R2，phpstudy8.1，mysql 5.5.29，sqli-labs

官网下载mariadb-5.5.68 版本，使用命令行执行以下命令，解压到目标目录

msiexec /a “d:\mariadb-5.5.68-winx64.msi” /qb TARGETDIR=”D:\abc”

在MariaDB 5.5\lib\plugin目录中提取需要的插件server_audit.dll，打开mysql命令行，查询plugin目录

复制server_audit.dll到插件目录，mysql命令行安装插件，查询插件状态

查询server_audit插件状态配置，默认为关闭状态，开启日志审计

这些参数的具体定义：

server_audit_events    
指定记录到日志的event类型，可以用逗号分隔的多个值(connect,query,table,query_ddl等)，如果开启了查询缓存(query cache)，查询直接从查询缓存返回数据，将没有table记录
server_audit_excl_users
该列表的用户行为将不记录，connect将不受该设置影响
server_audit_file_path    
审计日志路径，如果server_audit_output_type为FILE，审计日志默认存于数据目录下。即参数datadir对应的数据目录下面。如果修改server_audit_file_path，之前旧的审计日志文件不会被删除。需要手工去清理、删除。另外MySQL会开始新的审计日志轮转。
server_audit_file_rotate_now
强制轮转一次，执行脚本SET GLOBAL server_audit_file_rotate_now = ON;后，审计日志就会强制轮转一次。
server_audit_file_rotate_size
限制单个轮转审计日志大小，超出该限值后自动轮转。默认值为1000000，单位为byte,建议设置稍微大一点，例如,64M大小，67108864。具体根据实际需求和参数server_audit_file_rotations一起设定。
server_audit_file_rotations 
轮转日志总数，当设为0表示审计日志不轮转。默认值为9。 一般需要根据实际需求进行修改。
server_audit_incl_users    
指定哪些用户的活动将记录到审计日志，connect将不受此变量影响，该变量比server_audit_excl_users 优先级高
server_audit_loc_info   
这个是插件内部使用的参数，对用户没有什么意义。在早期版本中，用户将其视为只读变量，在更高版本中，它对用户不可见。   
server_audit_logging      
审计功能的开关， ON表示开启审计功能，OFF表示关闭审计功能。
server_audit_mode    
标识版本，用于开发测试。对于用户而言，此变量没有任何特殊含义。 它的值主要反映了启动插件所使用的服务器版本，供开发人员用于测试      
server_audit_output_type    
指定审计日志的类型，有SYSLOG 或FILE两种选择，默认为FILE
server_audit_query_log_limit
记录中查询字符串的长度限制。默认为1024
server_audit_syslog_facility
当审计日志类型为syslog模式时，它定义了将发送到系统日志的记录的“功能”。 以后可以使用此参数过滤日志。
server_audit_syslog_ident  
设置ident，作为每个syslog记录的一部分 
server_audit_syslog_info    
指定的info字符串将添加到syslog记录
server_audit_syslog_priority
定义记录日志的syslogd priority

3、error日志

查询err日志的路径。至此日志配置与所需的文件已备齐，以审计日志server_audit.log和data.err为基础进行入侵分析。

二、实战思路

通过搭建sqli-labs测试环境，根据mysql日志，分析mysql暴力破解，手工注入，sqlmap os-shell三种攻击模式的日志记录，尽可能的还原攻击场景，追溯攻击源信息。

1、mysql暴力破解

mysql对外开放端口，使用mysql暴力破解时的日志信息

data.err  中记录了攻击的ip地址和第一次连接的时间

200909 10:15:41 [Warning] IP address ‘192.168.106.180’ could not be resolved: 不知道这样的主机。

server_audit.log  从下图可以看出，攻击者多线程破解，破解的账号root，攻击者ip 192.168.106.180，返回代码1045，登陆成功后的执行了4个查询操作。

日志格式为：

[timestamp],[serverhost],[username],[host],[connectionid],[queryid],QUERY,[database],[object], [retcode]

可以根据 账号，ip地址，返回代码进行日志筛选分析，登陆后查询操作特征，可以推测使用的破解工具。

2、sql注入攻击

使用sqli-labs模拟存在漏洞的应用，github下载sqli-labs代码复制到phpstudy  www目录，运行项目，通过手动输入获取webshell。

模拟场景：已知服务器被执行phpinfo，疑似被入侵，需要通过日志分析入侵点与获得权限的方法。

此次data.err无变化，我们分析nginx的access.log 和审计插件的server_audit.log

发现access.log和server_audit.log均记录了攻击是sql注入，并通过mysql outfile写入后门到web目录，执行了phpinfo，触发报警。由于access.log不记录post请求的请求体，故server_audit.log可以看到更详细的攻击细节。

3、sqlmap os-shell攻击

通过sqlmap获取mysql os-shell，分析os-shell过程，日志有哪些特征

模拟场景：假设在场景2中，sql注入攻击时，应用方修复了sql漏洞，并对web目录进行了权限限制，监控又发现了命令执行的报警，尝试分析入侵点。

sqlmap -d “mysql://root:[email protected]:3306/mysql” –os-shell，成功后执行whoami

查看server_audit.log日志，可以看到sqlmap os-shell执行的完整过程,包括探测mysql版本，字符集，操作系统类型，如何用实现udf实现命令执行等。

日志里包含了很多sqlmap的特征，udf达到命令执行的特征，可结合其他日志初步判断为mysql密码泄露导致的udf命令执行。

命令执行时的错误会被错误日志data.err记录，引用一个mysql勒索病毒的日志截图，暴漏了攻击者控制的服务器地址信息。

三、总结

通过搭建环境结合日志分析，了解了针对mysql数据库的几种常见攻击方式，以及各个攻击方式对应的特征，可以从错误日志、审计日志、web访问日志结合来还原攻击路径，溯源攻击者，结合syslog可为威胁攻击检测平台提供有用信息。

参考链接：

https://www.cnblogs.com/mike-tao/

https://zhuanlan.zhihu.com/p/83284578

https://mariadb.com/kb/en/mariadb-audit-plugin/

来源：freebuf.com 2020-09-09 15:45:58 by: ofei