DM数据库用户限制白名单导致自身无法登录的一次紧急恢复-工具盒子

一、事件背景 {#一、事件背景}

在一次配合应用开发商进行安全加固时，用户提出了需要对连接数据库的IP进行白名单配置，对于业务用户仅支持应用节点IP登录，对此我们提供了alter user的模板SQL对用户的网络白名单进行限制：

alter user "SYSDBA" allow_ip "192.168.100.11";

但是当配置多个IP时需要将IP以逗号隔开，否则会不断刷新可连接的网络，且只保留最后一个。

二、事件经过 {#二、事件经过}

应用开发商在处理该问题时，没有将用户名修改为业务用户，而是直接对SYSDBA用户进行的操作，在执行的时候恰恰选择了上述错误的方式。

alter user "SYSDBA" allow_ip "192.168.100.11";
alter user "SYSDBA" allow_ip "192.168.100.12";
alter user "SYSDBA" allow_ip "192.168.100.13";
alter user "SYSDBA" allow_ip "192.168.100.14";
alter user "SYSDBA" allow_ip "192.168.100.15";
alter user "SYSDBA" allow_ip "192.168.100.16";
alter user "SYSDBA" allow_ip "192.168.100.17";
...
exit;

且用SYSDBA用户在disql执行完成后退出了以上会话。
直接导致了SYSDBA在本地也无法登录。

此时在数据库服务器本地使用disql登录127.0.0.1也无法登录。

[dmdba@dsc_131 bin]$ ./disql SYSDBA/SYSDBA@127.0.0.1
[-2158]:无效的IP.
disql V8
用户名:^C

而要将网络白名单限制取消又需要DBA权限对SYSDBA用户进行操作，恰巧又没有创建其他具有DBA权限的用户。

三、事件解决 {#三、事件解决}

以上操作做完之后出现死循环了，有DBA权限的SYSDBA用户无法登录，而能登录的用户又无法操作修改DBA的网络白名单。
针对这种误操作的问题，现场采用的是Linux虚拟网卡绑定IP来处理，唯一的问题在于，在执行了多次alter user后无法确认最终允许的IP。
普通用户查询的SYSUSERS视图无法显示SYSDBA用户的网络白名单。最终在系统默认的用户里面，还可以用审计用户SYSAUDITOR去查询。

SQL> SELECT ALLOW_ADDR,NOT_ALLOW_ADDR FROM SYSUSERS;

行号     ALLOW_ADDR     NOT_ALLOW_ADDR


*** ** * ** ***



1          NULL           NULL
2          NULL           NULL
3          192.168.100.88 NULL
4          NULL           NULL
5

`已用时间: 50.978(毫秒). 执行号:4100.
SQL> exit`

至此我们找到了这个白名单列表的IP地址。
接下来我们使用Linux的添加虚拟IP的方式，在本地虚拟一个IP为白名单列表的IP地址。

例如我在本地的ens33这个网卡上虚拟一个IP地址出来：

[root@dameng bin]$ ifconfig ens33:1 192.168.100.88 up

再尝试用SYSDBA用户登录，此时登录成功后，再将SYSDBA用户的网络白名单取消即可。

SQL> alter user "SYSDBA" allow_ip null;
操作已执行
已用时间: 21.248(毫秒). 执行号:4200.
SQL>exit;
最后将本地虚拟的这个IP删除
[root@dameng bin]$ ifconfig ens33:1 192.168.100.88 down