一、说明1
本篇文章主要说一下Oracle数据库中身份鉴别控制点中a、b、c测评项的相关知识点和理解，以及一些其他的东西。
二、测评项
a)应对登录的用户分配账户和权限； b)应重命名或删除默认账户，修改默认账户的默认口令； c)应及时删除或停用多余的、过期的账户，避免共享账户的存在；
三、测评项a
a)应对登录的用户分配账户和权限；
3.1. 要求1
如果从字面意思来看，就是一个废话，用户都登录账户了，自然就存在着账户。
这里的意思是应该是你本来就存在“多个账户”，然后当用户使用时要适当的“分配账户”给用户，而账户再拥有不一样的权限，这样就实现了将权限通过账户分配给用户（自然人）。
所以，该测评项就需要Oracle中存在至少两个账户，且这两个账户的权限不一样。
3.2. 要求2
在测评要求中测评实施如下：
在Oracle中默认用户挺多的，最常用的就是SYS和SYSTEM这两个账户，对于它们以及其他的一些默认账户，实际上没有什么好限制的，如果需要使用，按照实际情况使用就行了。
需要值得关注的是PUBLIC，不过实际上PUBLIC既不是角色也不是用户，但是如果你把某权限赋予给PUBLIC，那么所有的数据库用户都会具有这个权限。
PUBLIC肯定不是用户：
SQL> select *from dba_users where username='PUBLIC'; no rows selected
PUBLIC也不会出现在dab_roles表中：
SQL> select *from dba_roles where role='PUBLIC'; no rows selected
不过它确实存在于USER$表中：
Oracle官方文档解释如下：
大概就是说Public角色无法删除，手动将其授予给某用户或者从某用户上将其撤销都没有任何意义，由于所有数据库用户都承担PUBLIC角色，因此它不会出现在DBA_ROLES 和 SESSION_ROLES表中。
不管PUBLIC到底是什么，我们知道它属于每一个数据库用户就行了。
默认状态下，PUBLIC会拥有很多的权限，其中和UTL有关的就有不少：
如果你使用某扫描工具扫描，扫描报告里会指出这属于高危漏洞：
所以理论上是最好将这些（UTL_SMTP、UTL_TCP、UTL_HTTP以及UTL_FILE）的相关权限从PUBLIC上撤销掉。
不过最好还是给整改人员提醒下（测评人员基本上不插手整改，顶多做出一些说明），根据实际情况做出整改：
大概就是说由于PUBLIC的权限由所有用户所共有，撤销掉PUBLIC的权限可能会引起严重的级联效应，所以要小心。
四、测评项b
b)应重命名或删除默认账户，修改默认账户的默认口令；
对于默认账户如SYS等，可能重命名比较麻烦，所以修改其默认口令应该就可以了。
默认口令如下（没实际验证过，大概率对的，因为网上说的都一样）：
系统默认ORACLE用户及口令
在Oracle 11G中，增加了个新特性，可以直接查询出使用默认口令的用户：
核心就是这个DBA_USERS_WITH_DEFPWD视图，只有一列，存放的是使用默认口令用户的用户名：
原理我猜就是oracle自己拿着默认口令去对比，发现使用默认口令的用户名就记在这个视图中，反之，不使用默认口令了，就不记入视图中。
所以如果你修改了口令，但是还是用的默认口令（也就是只是更新了口令修改的时间，内容没变），或者你用了新口令，后来又改回默认口令了，不会影响这个视图的效果：
比如我用下面的SQL语句刷新了下DBSNMP的口令修改时间：
alter user DBSNMP identified by DBSNMP;
查询DBA_USERS_WITH_DEFPWD，DBSNMP还是在里面的：
网上有关这个视图的解释有点会造成歧义，或者没说清楚，可能会造成DBA_USERS_WITH_DEFPWD是以口令修改时间是否刷新来判断：
五、测评项C
c)应及时删除或停用多余的、过期的账户，避免共享账户的存在；
这大概没有什么需要特别说明的，每个账户是否有自己的用途，这个要通过实际查询账户具备的权限以及访谈来确定。
具体用哪些SQL语句查询出账户拥有哪些权限，放在之后的几个测评项中说。
六、说明2
这里说明一下，我写文章是按照控制点-测评项的结构写的，但是每次写完后，或多或少会发现以前的文章有没写全的、写错的，或者发现一些与控制点-测评项的结构不太相关的东西。
这些东西我也想写出来，但是关联性不强，也不大可能单独写成一篇文章，所以就只有附加在文章的后面了。
七、提出的整改建议要符合实际
虽然按照等级保护的工作流程，整改在测评之前，测评机构主要只负责测评，但实际工作中还是会涉及到整改方面的内容，特别是在测评报告中也需要写出整改建议。
那么在提出整改建议的时候，如果写得详细的话（比如直接涉及到参数），那么最好还是要好好考虑，不要犯一些低级错误。
口说无凭，我举几个简单的例子。
7.1. SqlServer的C2跟踪审核
在测评能手中在SqlServer的安全审计控制点中提到了C2跟踪审核，开启之后，几乎会记录数据库的每一个操作。
开启的位置：
会记录数据库的每一个操作，但是不知道为什么，具体到updat语句的时候就比较奇怪了，涉及的sql语句中，具体的值不知道，以变量名代替，比如不知道下面@1和@2到底是什么值：
但是由于每个操作都记录，所以会大量的占用资源，下面的trc就是记录文件，记录文件一天生成一个，以当天的日期为文件名，如果一天之内的记录大小超过200M，就添加序号，生成新的。
我个人电脑上，根本就没有业务，顶多我自己试验一些sql语句，结果记录文件就有这么多，如果真的存在业务的话，我看记录文件直接能占满磁盘空间，性能方面的损耗也不会小。
也就是说，这个选项开启的目的，只能是短期内对sql语句进行核查、检查、审计等，而不能够作为长期对数据库进行审计的手段！
如果照搬测评能手给出这种整改建议的话，画面太美我不敢想象……
这并不是我自己杞人忧天，我在搜索C2跟踪审核的时候居然发现了这样的内容：
大家是不是觉得有点黑色幽默……
7.2. Mysql自带的审计功能
也就是Mysql的general_log选项，开启后好像会记录所有关于mysql的sql语句，具体可以看等保测评2.0：MySQL安全审计的相关内容。
你有没有发现Mysql自带的这个审计功能的相关参数太少？只有那么三四个（具体几个我没数，但是很少就是了），和其它的审计插件或者服务器审计功能的相关参数相比是不是少了一些关键的参数。
Mysql自带这个审计功能没有关于记录文件轮询以及文件最大值的限制！
也就是说，你开启general_log选项后，文件只会越来越大，没办法直接进行日志轮询以及文件最大值的设置。
所以同样的，你直接在整改建议中叫被测评机构开启这个选项，虽然可能没C2跟踪审核那么夸张，但是也强不到哪去。
不过好像可以配合其他的一些工具实现general_log记录文件的分割：
mysql的general log太大怎么处理
日志切割之Logrotate
八、SQLServer的空口令查询
注意，不同版本可能效果不一样，请先自行实验。
如果SQLserver没有设置什么口令策略，那么对于数据库用户，是可以设置空口令的。
当然，想要判断某用户是不是空口令，一个最简单的方法就是直接挨个使用空口令去登录。
但是能不能直接从数据库表中查询出空口令呢？
按照一般的思路，我们先设置一个空口令用户，然后去查看其口令字段，然后看看是不是有什么特殊值，比如空字符串、null之类的，这样下次就能直接对比了。
但结果有点奇怪，设置了两个空口令用户，两个的口令字段都有值，而且还不一样：
嗯，其实也没啥奇怪的，有些加密算法可以实现相同的明文生成不一样的密文，一个最简单的例子，你在生成密文的时候挑选一些位数，设定其是无效字符串，然后放一些随机字符进去，不就是一个最简单的方案吗？
当然，实际的算法比我想的肯定复杂多了，而且SQLServer用的应该是哈希算法，不可逆，我也懒得去管它怎么实现的了，解决问题更重要。
在不了解其内部算法的情况下，想要判断出给出的口令的哈希值的原文是不是空字符串，就只能依靠SQLServer自带的函数了，还真被我找到了。
识别SQLServer中空密码或者弱密码的登录名
注意看这一段：
也就是PWDCOMPARE这个函数可以将哈希值同某字符串进行对比，判断出哈希值的明文是否等于某字符串。
实际测试是可以的，结果如下：
从这一点扩展的话，如果你想自己判断SQLServer里是否存在弱口令的话，如果使用用扫描工具，你可以自己写一些存储过程什么的来进行判断。
来源：freebuf.com 2020-07-14 00:30:16 by: 起于凡而非于凡
请登录后发表评论
注册