给MySQL写一个代理网关

2024年 5月 7日 47.9k 0

由于一个突发的需求,年前年后大部分时间都在mysql-proxy这么个项目上折腾;现在一期功能算是上线了,趁这个机会简单总结一下

由于MySQL通信是通过MySQL协议交互的,所以主要其实就是折腾MySQL协议

项目背景

先简单说下为什么需要做mysql-proxy,开发平时查看数据库,是通过 jumpserver 连接到现网的灾备库查看,灾备库和现网业务库的数据内容是一样的,里面有很多敏感数据,比如手机号,身份证等,所以存在着数据安全的问题

常规的处理思路是,对所有敏感数据的查询都进行申请和审批,这样固然能解决数据安全的问题,但是让开发查数据变得麻烦了许多,降低了排查问题的效率,同时要分析出所有包含敏感数据的库表也是一件麻烦事

综合考虑,我们决定增加一个代理,直接对敏感数据进行脱敏,这样开发的使用习惯和之前一样,如果查询到的数据集中包含敏感数据,就会被其他的符号遮掩

当然某些场景下,开发还是需要知道数据的真实值,这时候就必须得进行申请了,为了数据的安全,一些必要的效率折损,还是可以接受的

实现思路

要实现MySQL代理并进行数据脱敏,分为以下两步

1.  模拟mysql client 与mysql server 的双端交互,成为中间人

2.  pick up出查询请求,篡改返回数据包

给MySQL写一个代理网关-1

MySQL建连过程分析

平时连接MySQL,我们会执行类似下面这行命令

mysql -u root -h127.0.0.1 -p123qwe -P3306 --ssl-mode=DISABLED

执行这行命令会发生什么?

1.  客户端向服务端建立TCP连接,也就是三次握手

2.  服务端返回InitialHandshake消息包,其中包括服务端版本号和一些功能性标记(比如是否丢弃EOF包等)

3.  客户端发送HandshakeResponse消息包,其中包括功能性标记、连接使用的用户名密码,字符集和数据库名等

4.  服务端校验通过后,返回ok消息,即完成连接的建立

给MySQL写一个代理网关-2

完成握手之后就进入了下图中的交互模式,红框的版本信息就是此次交换得到的数据

给MySQL写一个代理网关-3

MySQL代理建连过程分析

代理处于client和server中间,最简单的做法就是直接转发

给MySQL写一个代理网关-4

如果只有一个client和一个server,这么做当然是没问题的

但实际场景中,我们有多个数据库实例,proxy应该代理到哪个数据库实例,是由client端决定的

给MySQL写一个代理网关-5

看来proxy不能偷懒了,它必须做到以下几件事

1.  识别到client端想连接哪个server端

2.  连接到对应的server端

要做到这两件事,首先要分析,不同的数据库实例是靠什么区分的?

显然是ip:port,实例的ip是不同的,端口都是3306

但是client端要走proxy,ip自然要填proxy的ip,proxy的ip肯定只有一个,此时就无法通过ip来进行区分,必须另寻他径

回头看看MySQL的连接过程,TCP三次握手肯定不能携带任何信息,只能想办法在HandshakeResponse包里携带标识

经过对TCP协议包的分析,TCP包确实留置了option段来放一些自定义信息,但是这样需要修改client端来做适配,这显然不合适,不同的开发客户端各有千秋,navicat,datagrip等等

所以只能对open的信息做手脚,观察MySQL的连接命令,发现可以在用户名上动手脚,所以将数据库实例id的拼接在用户名上

mysql -u {instance_id}.root -h127.0.0.1 -p123qwe -P3306 --ssl-mode=DISABLED

proxy在拿到{instance_id}.root后,进行拆分,由instance_id得到需要连接的数据库实例,再进行数据库实例的连接,所以代理的建连过程就变成下图所示

注:proxy的配置中,存有instance_id对应的ip:port,这样拿到instance_id就等于拿到的实例的地址

给MySQL写一个代理网关-6

TODO: wireshark抓报示例整个过程

MySQL鉴权过程分析

先看下一个常规的鉴权过程

1.  客户端发送账号密码

2.  服务端校验,并返回结果

这里往往会消耗一次来回的消息交换

为了减少建立连接过程种消息交换的次数,MySQL协议有一个鉴权的快速通道 FastPath

给MySQL写一个代理网关-7

在服务端发送InitialHandshake消息时,会先默认猜一个AuthMethod,并随机生成8字节或者更长的challenge payload,放在InitialHandshake消息中一起发给客户端

为什么说是“猜”呢,因为不同用户可能设置不同的AuthMethod,然而在这一阶段,服务端还不知道要连接的用户是哪一个,自然不知道正确的AuthMethod应该是什么了

AuthMethod 比较常见的有 mysql_native_password,caching_sha2_password,主要区别在于hash算法不同

challenge payload是一串随机码,每一次连接都会不同,客户端会用这一串随机码给密码加密

客户端根据AuthMethod定义的方法对密码+payload加以计算,计算结果连同AuthMethod一起放在HandshakeResponse里一起发给服务端

如果服务端读取对应的用户表之后,发现AuthMethod跟猜测的一致,那么就可以直接验证客户端的计算结果了,成功后直接返回Ok,这样就完成连接建立了,否则,服务端需要发送AuthMethodSwitchRequest来重新进行鉴权

AuthMethod的特殊处理

由于MySQL协议中鉴权FastPath的存在,这个过程是有问题的:客户端收到的加密随机码是一开始由proxy生成的,它跟mysql-server发给proxy的显然不一致,这将导致mysql-server在收到HandshakeResponse后校验失败报错

给MySQL写一个代理网关-8

要通过server的校验,需要随机码2生成的密码

最简单的做法显然是,proxy配置实例的原始密码,然后用随机码2去加密

但是这样做显然很麻烦,更主要的是不安全,所有数据库的密码都放在proxy,要是泄密了不得背大锅,所以必须要做到proxy不存储密码也要能完成鉴权

所以这里需要绕过 FastPath,强制触发AuthMethodSwitchRequest进行重新鉴权,即用一个服务端一个不认识的AuthMethod时,触发服务端重新鉴权

最终整个流程如下

给MySQL写一个代理网关-9

通过wireshark抓包可以看到整个包传输的流程

给MySQL写一个代理网关-10

至此proxy完成了整个连接鉴权过程,现在可以进行查询操作了

MySQL查询过程分析

连接建立成功后,客户端就可以发送查询命令给服务端,再简单分析一下mysql的查询流程,常规的查询过程是串行的,发送一个查询包,返回一个查询结果包,然后重复上述过程

给MySQL写一个代理网关-11

1.  客户端向服务端发送request包,并指定command的为query,statement为具体查询语句,比如selelct @@version_comment limit1

给MySQL写一个代理网关-12

2.  服务端会返回一个叫做TABULAR的response组合包,该包由5个部分组成,column包指明这次查询有多少列,field包每个列的属性,比如类型,长度等,EOF 分隔包,指示, row packet 包含一行数据的值 , EOF 结束包

给MySQL写一个代理网关-13

mysql-proxy的实现

上述分析只是理论上的核心流程,实际开发过程中会有很多问题要处理,其中最多的是对二进制字节流的处理,因为MySQL协议属于TCP协议,GO没有完整的SDK能够处理MySQL协议,所以都是依靠计算位和流来解析协议包

值得一提的是,MySQL经过多年的发展,具有丰富的功能,根据我们的业务场景,目前proxy只实现了简单查询的场景,像事务,prepare等功能,都是没有实现的

相关文章

Oracle如何使用授予和撤销权限的语法和示例
Awesome Project: 探索 MatrixOrigin 云原生分布式数据库
下载丨66页PDF,云和恩墨技术通讯(2024年7月刊)
社区版oceanbase安装
Oracle 导出CSV工具-sqluldr2
ETL数据集成丨快速将MySQL数据迁移至Doris数据库

发布评论