Oracle DBLINK传输加密

前些天,同事问我DBLINK传输能不能加密,我当时可能是在喝酒,张嘴就回了说不行。后来想想,其实可以通过SQLnet的传输加密来做。比较简单。

本次测试为对比测试,加密前后各抓一个包,用wireshark打开看数据是否被加密。

源库和目标库信息如下:

DBNAMEIP ADDRVERSION
remotepdb110.10.133.6419.3
ora19pdb110.10.133.6319.3

ora19pdb1通过DBLINK连到remotepdb1的HR用户:

在remotepdb1所在主机10.10.133.64上用root打开tcpdump抓取10.10.133.63和10.10.133.64交互的包。

在ora19pdb1上执行一个简单的查询,这个查询使用dblink连接到remotepdb1:

然后把生成的no_encryption.pcap文件用wireshark打开,本次查询一共抓到12帧。

10.10.133.63发给10.10.133.64的帧中能看到转义之后SQL明文

10.10.133.63发给10.10.133.64的帧中能看到转义之后SQL明文。同样64给63的回包的TCP segment data也是明文,但是不是直接回表的数据,而是先告知客户端要查的表有哪些列,然后客户端根据这些列重新生成了一个SQL发给64来执行。这个过程以前未曾观测到过。

server给client端回复了要查的表的列名
client拿到列之后。重新生成了一个SQL发给了server端执行
server端向client端回传查询到的数据的明文

server端向client端回传查询到的数据的明文,一直没想到SQLNET默认是明文的方式传输的。比较不安全。此外。在所有数据都返回了之后,还隐藏了一个ORA-01403:no data found给客户端,但是实际上客户端是看不到这个错误的,猜测这是告知客户端数据已回传完毕,客户端可以以“xx rows selected”了。

现在开始在server对sqlnet.ora进行配置,来加密sqlnet的传输帧。

sqlnet的加密在Oracle的Database Advanced Security文档中,在此不详细叙述各个参数的意义了。除了传输加密,我还打开了一致性校验。为了更好的看到加密过程,除了抓包之外,我还打开了sqlnet的trace。最终在sqlnet.ora中的参数如下:

然后在server端开启tcpdump,重新开启一个客户端到服务器端的会话,执行类似的查询,获得抓包的文件和sqlnet的trace。

在trace中:

随后,打开tcpdump的包:

可以看到回传的数据已经被加密

证明加密成功。

加密的配置不复杂,下面为客户端和服务器端的参数匹配情况,默认是Accepted,OFF代表未开启加密,ORA-12660代表Encryption or crypto-checksumming parameters incompatible,无法建立链接。

RejectedAcceptedRequestedRequired
RejectedOFFOFFOFFORA-12660
AcceptedOFFOFFONON
RequestedOFFONONON
RequiredORA-12660ONONON

此外,加密最关心对性能的损耗,对资源的消耗,对查询效率的影响等等。国外同行在10.2下,开启每种加密算法,对DBA_OBJECTS进行100次查询,统计出来的结果如下:

不同加密算法对性能的影响

可以看到3DES168对性能影响巨大。而其他加密算法的效率还在可以接受的范围内,最低的有4%。仅供参考。

发表评论