Linux系统上记录MYSQL *** 作的审计日志

Linux系统上记录MYSQL *** 作的审计日志,第1张

    根据笔者上一篇文章—Linux系统上记录用户 *** 作的审计日志 。本文来利用相同的方法记录MYSQL *** 作的审计日志。

    使用用mysql工具连接MySQL server的所有 *** 作会默认记录到~/.mysql_history文件中,这个文件会把所有 *** 作记录下来,包括创建用户和修改用户的明文密码,这在生产系统上是不安全的。如果不想保存,仅仅删除是不行的(文件不存在会再建立),要直接将其软连接到垃圾箱。

     ln  -s  /dev/null  ~/.mysql_history

    利用上一篇文章相同的方法记录MYSQL *** 作的审计日志,是因为mysql工具本身就是有一个shell, 每次mysql连接退出后,都会把此次 *** 作的信息记录到~/.mysql_history文件中。那么可以重新定义MYSQL_HISTFILE环境变量来保存mysql日志。

    先看置于/etc/profile.d目录下的环境变量的脚本mysql_history.sh,和loginlog类似。

      在测试时,发现平时使用的普通用户在 *** 作mysql后无法记录,而root用户(平时没有 *** 作过mysql)可以记录成功。后来在在~/.mysql_history文件找到了 *** 作记录,估计是这个文件还存在的原因,删除后才记录到新的MYSQL_HISTFILE定义的路径。

      和loginlog一样,需要定期删除过期日志,以下脚本置于/etc/cron.weekly 目录下。

        delete_time=15

        find /opt/mysqllog/  -mtime +$delete_time -name '*.log' -exec rm -r {} \

      但是相比于loginlog,mysqllog有两点暂时没有解决。

    1、定义最大的记录条数history.maxSize不知在哪定义,my.cnf?

    2、每一条命令的时间记录添加。

mysql服务器自身没有提供审计功能,但是我们可以使用init-connect + binlog的方法进行mysql的 *** 作审计。由于mysql binlog记录了所有对数据库长生实际修改的sql语句,及其执行时间,和connection_id但是却没有记录connection_id对应的详细用户信息。在后期审计进行行为追踪时,根据binlog记录的行为及对应的connection-id 结合 之前连接日志记录 进行分析,得出最后的结论。

1. 设置init-connect

1.1 创建用于存放连接日志的数据库和表

create database accesslog

CREATE TABLE accesslog.accesslog (`id` int(11) primary key auto_increment, `time` timestamp, `localname` varchar(30), `matchname` varchar(30))

1.2 创建用户权限

可用现成的root用户用于信息的读取

grant select on accesslog.* to root

如果存在具有to *.* 权限的用户需要进行限制。

这里还需要注意用户必须对accesslog表具有insert权限

grant select on accesslog.* to user@’%’

1.3 设置init-connect

在[mysqld]下添加以下设置:

init-connect=’insertinto accesslog.accesslog(id, time, localname, matchname)

values(connection_id(),now(),user(),current_user())’

------注意user()和current_user()的区别

log-bin=xxx

这里必须开启binlog

1.4 重启数据库生效

shell>/etc/init.d/mysql restart

2. 记录追踪

2.1 thread_id确认

可以用以下语句定位语句执行人

Tencent:~ # mysqlbinlog --start-datetime='2011-01-26 16:00:00'

--stop-datetime='2011-01-26 17:00:00' /var/lib/mysql/mysql-bin.000010

| grep -B 5 'wsj'

COMMIT/*!*/

# at 767

#110126 16:16:43 server id 1 end_log_pos 872 Query thread_id=19exec_time=0 error_code=0

use test/*!*/

SET TIMESTAMP=1296029803/*!*/

create table wsj(id int unsigned not null)

--

BEGIN

/*!*/

# at 940

#110126 16:16:57 server id 1 end_log_pos 1033 Query thread_id=19exec_time=0 error_code=0

SET TIMESTAMP=1296029817/*!*/

insert into wsj(id) values (1)

--

BEGIN

/*!*/

# at 1128

#110126 16:16:58 server id 1 end_log_pos 1221 Query thread_id=19exec_time=0 error_code=0

SET TIMESTAMP=1296029818/*!*/

insert into wsj(id) values (2)

2.2 用户确认

thread_id 确认以后,找到元凶就只是一条sql语句的问题了。

mysql>select * from accesslog where id=19

+----+---------------------+---------------------+-----------+

| id | time| localname | matchname |

+----+---------------------+---------------------+-----------+

| 19 | 2011-01-26 16:15:54 | test@10.163.164.216 | test@%|

+----+---------------------+---------------------+-----------+

1 row in set (0.00 sec)


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/7451256.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-05
下一篇 2023-04-05

发表评论

登录后才能评论

评论列表(0条)

保存