等保学习干货|等保测评2.0技术中间件自查阶段(下)
以下是根据我国网络安全体系制订的一系列保护流程进行的等级保护测评。该测评针对已有和将上线的业务服务的基础设施(系统、数据库、中间件等),执行一系列检查以确保安全合规。
本次先行分享学习等保中的技术自查阶段知识,关于如:理论知识、机房环境、备案、拓扑等可以根据自身和现实情况进行学习、文章由上中下三篇组成,建议收藏,以备不时之需、使用PC查看效果最佳、全文较长,请静心观看。
一般来说:业务系统的组成是由系统和数据库及中间件组成,被攻击的情况下,攻击者也是向此作为目的进行攻击
系统方面: Windows、Linux(Centos、Ubuntu、红帽及一些国产系统)
数据库方面: Mysql、Oracle、redis、mongodb、SQL server等
中间件方面: Tomcat、nginx等
逻辑方面: 双因子认证、应用审计与防范、数据完整性与保密性
* 资料仅作为分享、思路来源于互联网和现实学习复现、仅作为参考、实际根据现实情况操作
0x02 测评过程
一、中间件-Nginx
以Linux环境为例
注: Nignx是高性能的HTTP服务器和反向代理服务器
一般用于HTTP发布网站处理,或者是作为反向代理进行负载均衡使用
在进行资产统计、功能统计时要标注明确
Nignx版本为1.25.4
1. 身份的鉴别
a). 对登录的用户进行身份鉴别,并确保密码复杂度并定期更换密码
无登录入口、无账号概念、无控制端,可直接从操作系统控制,默认符合
b). 限制非法登录、登录超时、防止暴力破解等
无登录入口、无账号概念、无控制端,可直接从操作系统控制,默认符合
c). 应当防止在远程控制时、传输信息被监听
无登录入口、无账号概念、无控制端,可直接从操作系统控制,默认符合
2. 访问权限的控制
a). 对登录的账户分配对应的权限
无登录入口、无账号概念、无控制端,可直接从操作系统控制,默认符合
b). 默认多余、可疑用户删除操作,及空口令进行设密
无登录入口、无账号概念、无控制端,可直接从操作系统控制,默认符合
c). 删除或禁用多余、共享、过期、锁定账户
无登录入口、无账号概念、无控制端,可直接从操作系统控制,默认符合
d). 授予用户最小权限,实现权限分离
无登录入口、无账号概念、无控制端,可直接从操作系统控制,默认符合
e). 设定的访问策略、主体和客体之间的访问规则
无登录入口、无账号概念、无控制端,可直接从操作系统控制,默认符合
3. 安全审计
a). 启用安全审计功能、记录每个用户行为和事件作为审计
在nginx中,有error_log、access_log
error_log:这个配置项用来指定Nginx服务器错误日志的存储位置和级别。
其中,存储位置可以是一个文件路径,级别则可以是debug、info、notice、warn、error、crit、alert和emerg等级别。
这些级别从debug到emerg依次增加,代表了日志信息的严重程度。例如,使用error_log /var/log/nginx/error.log error;
可以将错误日志记录在指定的文件中,并且只记录error级别及以上的错误信息。
access_log:这个配置项用来指定Nginx服务器访问日志的存储位置和格式。
通常,可以设置为access_log /var/log/nginx/access.log combined;,
其中combined是一种常见的日志格式,包含了访问客户端IP、访问时间、请求方法、请求URL、HTTP状态码等信息。
在Linux中,nginx的配置文件/etc/nginx/nginx.conf
在Windows中,nginx配置文件就在conf\nginx.conf
b). 审计记录(包含日期、用户、时间、事件类型等信息)
在Windows中、日志存放在nginx中的log\access.log和error.log
Linux中、日志一般存放在/var/log/nginx/access.log和error.log
注: 在docker中运行的nginx容器,会创建软连接,实际上输出到了前台日志
docker logs container_id
其次需要核对日志与配置文件中的是否一致
c). 应用审计定期备份、防止被删除、覆盖
Windows中,除管理用户外,其他用户无增删改权限
Linux下,日志权限不得高于644
关于备份以自身环境需求为主
备份日志需要留存至少6个月以上
4. 入侵防范
a). 最小化安装原则、仅安装需要组件和系统组件
无登录入口、无账号概念、无控制端,可直接从操作系统控制,默认符合
b). 关闭不需要的高危进程、端口、共享服务
无登录入口、无账号概念、无控制端,可直接从操作系统控制,默认符合
c). 对于远程管理进行限制指定用户访问进行配置
无登录入口、无账号概念、无控制端,可直接从操作系统控制,默认符合
d). 及时发现漏洞并确认,及时打补丁修复
根据自身环境进行确认
是否定期进行漏扫计划
存在漏洞及时打补丁等修复
二、中间件-Tomcat
以Linux环境为例
安装不同版本类型的tomcat查看版本方法不一致,我安装的这个在bin/version.sh查看
其他有些catalina.sh查看,以自身环境为准
1. 身份的鉴别
a). 对登录的用户进行身份鉴别,并确保密码复杂度并定期更换密码
查看配置文件是否开启了控制台,在conf/server.xlm下,如未开启则忽略
apache在初次安装后,manager可能会出现403情况,按照以下进行修复
1. conf/tomcat-users.xlm中,找到相关行,配置好账号的密码
2. 在 webapps/manager/META-INF/context.xml中注释如下行
此时重启服务后再次访问manager即可
等保的审查:
设用户开启了控制台管理,在conf/tomcat-users.xml文件中
查看设置的密码复杂度是否符合及唯一的用户标识
b). 限制非法登录、登录超时、防止暴力破解等
在conf/server.xml文件中配置登录失败尝试次数及登录超时配置
找到下图如下配置项,如其中没有参数则手动添加即可
failureCount次数为5,表示最多尝试5次登录失败
lockTime表示5次登录失败后锁定500秒
c). 应当防止在远程控制时、传输信息被监听
根据自身情况查看在访问tomcat管理后台时,是http还是https即可
2. 访问权限的控制
a). 对登录的账户分配对应的权限
在conf/tomcat-users.xml中,角色roles不同分工具有不同权限
在manager中有4种接口不同的rolename
具体如何分配角色权限,以自身环境为准
b). 默认多余、可疑用户删除操作,及空口令进行设密
查看conf/tomcat-users.xml文件
有无可疑用户、默认用户,无密码,弱密码,不符合复杂密码规则用户
c). 删除或禁用多余、共享、过期、锁定账户
查看conf/tomcat-users.xml文件,并根据自身情况
询问其他运维人员,是否存在多余用户
d). 授予用户最小权限,实现权限分离
在conf/tomcat-users.xml文件,确认访问策略规则
按照下图进行设置用户相关权限
e). 设定的访问策略、主体和客体之间的访问规则
根据自身情况判定,有些逻辑问题,对于主体和客体的划分不好区别
3. 安全审计
a). 启用安全审计功能、记录每个用户行为和事件作为审计
tomcat的日志在tomcat的目录下,如tomcat/logs/*
Catalina.out:这是 Tomcat 的主要日志文件,其中包含了 Tomcat 的启动信息、错误信息以及应用程序的日志输出。通常位于 Tomcat 安装目录的 logs 文件夹下。
localhost.yyyy-mm-dd.log:这是 Tomcat 记录本地主机访问信息的日志文件,其中的 yyyy-mm-dd 是日期。它记录了每个访问请求的详细信息,包括请求的 URL、响应状态码、请求时间等。
host-manager.yyyy-mm-dd.log:这是 Tomcat Host Manager 应用程序的日志文件,用于记录 Host Manager 的访问和操作信息。
manager.yyyy-mm-dd.log:这是 Tomcat Manager 应用程序的日志文件,记录了 Manager 应用程序的访问和操作信息。
catalina.yyyy-mm-dd.log:这是 Tomcat 的核心组件 Catalina 的日志文件,它记录了 Tomcat 的启动过程、Servlet 容器的初始化和销毁过程等详细信息。
b). 审计记录(包含日期、用户、时间、事件类型等信息)
查看 conf/logging.properties 下开启相关日志等级不低于FINE
且日志需要全部开启状态(OFF)
且关于access的日志,在conf/server.xml中不能注释
b). 审计记录(包含日期、用户、时间、事件类型等信息)
查看日志,只要时间与本地系统时间(北京时间)相同即可
c). 应用审计定期备份、防止被删除、覆盖
此处日志文件权限不得高于640
查看分配得用户组是否合理
关于备份必须超过6个月以上
根据自身情况进行决定备份方式
4. 入侵防范
a). 最小化安装原则、仅安装需要组件和系统组件
安装默认得tomcat即可,自带得组件,其他无需安装
b). 关闭不需要的高危进程、端口、共享服务
自查开放得有关进程,除了管理后台无其他端口,无共享服务
c). 对于远程管理进行限制指定用户访问进行配置
在 webapps/manager/META-INF/context.xml 配置文件中
如以注释掉相关得IP限制,则检查是否对外映射,否则需要配置相关管理IP
d). 及时发现漏洞并确认,及时打补丁修复
根据自身环境进行确认
是否定期进行漏扫计划
存在漏洞及时打补丁等修复
三、 应用安全的审计与入侵防范
此处对于系统的防范及架设服务的防范进行学习
1. 安全审计
a). 启用安全审计功能、记录每个用户行为和事件作为审计
在开发应用系统时,需要在后台增加用户的操作日志功能
如登录日志、操作日志、功能日志等
如几点几分做了什么,以下图为例
如此日志没有,甚至中间件的日志都没有,直接pass掉
b). 审计记录(包含日期、用户、时间、事件类型等信息)
最低需要包含用户名、操作时间、事件类型、事件,否则不行
c). 应用审计定期备份、防止被删除、覆盖
一般在网站应用中是没有删除功能的,默认符合
假设存在删除功能,应该查看权限的分配,并防止越权事件出现
对于备份:需要了解备份的方式,备份的路径
备份记录一般必须超过6个月以上
d). 审计过程需防止未经授权的中断
在网站应用中,一般用户为一个个体
是否出现中断,还是需要查看权限的分配及存在越权的情况
2. 入侵防范
a). 最小化安装原则、仅安装需要组件和系统组件
这个在等保测评三级的时候会有渗透测试相关操作
如SQL注入,任意文件上传,任意文件包含功能漏洞
账户越权,任意用户密码找回等逻辑漏洞
有兴趣可参考以前发的一些漏洞挖掘的文章
其次就是本地环境与防火墙,waf等一些安全设备的结合去判定
b). 及时发现漏洞并确认,及时打补丁修复
结合当下自身环境,询问管理人员
是否已进行了渗透/准备渗透测试行为
对于渗透测试出具的测试报告,及时对于漏洞进行修改,一般符合
四、 双因子认证
判定标准及具体法则:
(1)GB/T 22239—2019
《信息安全技术 网络安全等级保护基本要求》(GB∕T 22239—2019)的第三级安全要求中
安全计算环境的身份鉴别控制点要求:“应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别,
且其中一种鉴别技术至少应使用密码技术来实现。”
(2)GB/T 28448—2019
《信息安全技术 网络安全等级保护测评要求》(GB∕T 28448—2019)中对身份鉴别控制点的测评实施提出如下要求:
1)应核查是否采用动态口令、数字证书、生物技术和设备指纹等两种或两种以上组合的鉴别技术对用户身份进行鉴别;
2)应核查其中一种鉴别技术是否使用密码技术来实现。
单元判定:如果1)-2)均为肯定,则符合本测评单元指标要求,否则不符合或部分符合本测评单元指标要求。
“双因素”顾名思义,通常就是在“静态口令”的基础上增加另外一种鉴别因素以实现强身份鉴别,确保是用户账号拥有者本人登录。第二因素实现形式包括但不限于:短消息认证、邮件认证、动态口令令牌、USB-KEY、指纹、面部、虹膜、声音等,其中动态口令令牌由于其实现成本较低且操作方便,是目前最常使用的一种。
威胁分析:
设企业内有堡垒机,是否有以下风险
1. 堡垒机存在 重大漏洞,攻击者通过未授权堡垒机进入系统内网
2. 堡垒机无漏洞,但内网服务器、机器对外映射,攻击者通过内网机器进入内网
3. 网络拓扑配置错误,攻击者可绕过堡垒机进入内网
4. 其他正常应用服务器存在漏洞,攻击者通过漏洞进入内网
符合分析:
实体证明:通过实体、声音、刷脸等证明是本人实体
鉴别证明:通过签名、护照、私钥等证明或通过验证码、u-key、VPN进行证明
密码证明:通过密码进行证明,在传输过程中进行加密,防止被破译,使用商用密码等手段
原文地址:https://blog.csdn.net/2401_84434570/article/details/140624666
免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!