HVV行动作为国家级攻防演练具有重大意义，旨在通过检验单位网络和信息基础设施的安全防护、应急处置和指挥调度能力，提高信息系统的综合防御能力。而要打好一场完美的防守战役应该先从组织本身的脆弱性整改开始，其整改工作应该具备全局性视图。
本文将主要从HVV行动第一阶段，即准备阶段时涉及到的检测内容和要点进行梳理和分析，并给出相应的加固建议。
1、整体安全整改
从整体整改视图出发，到梳理相关资产，发现相关风险，以此开展相应工作等整体安全加固能全面有序的帮助大家度过前期的安全整改工作，为HVV攻防演练奠定坚实基础。
2、资产梳理
资产梳理作为整体安全建设基础，应该做到全面梳理，因为资产梳理做得是否全面将直接影响后续风险排查是否彻底。全面的资产排查应从内、外网，软、硬件，人员配备，以及安全管理制度等多方面进行梳理。资产的排查可以从多维度进行交叉排查，应该做到“宁可多查，不可漏查”，大致可以分为以下几个类别：互联网暴露资产、业务资产、硬件资产、软件资产、办公资产等类型。
3、互联网暴露面缩减
互联网暴露面作为流量的入口，是攻击方重点收集的目标，也是攻击方重要的攻击对象，因此降低互联网资产风险是蓝队最主要的工作。互联网资产风险范围包括对外业务（如官网、APP及其它应用系统）的漏洞、对外开放的测试环境、VPN系统、公有云上系统、以及共享在外的代码（githup、百度云盘等公共仓库里共享的代码）等。
互联网暴露面排查方式：
外网资产信息收集；
子域名探测；
敏感信息泄露探测；
源代码泄露探测。
互联网暴露面缩减方式：
从代码层修复漏扫及渗透发现的问题；
关闭测试系统对外服务端口映射；
关闭直接对外服务的高危端口及其映射地址；
所有对外业务都该经过安全防护设备（防火墙、WAF、入侵检测、防毒墙等）；
将VPN设备系统升级到最新版本，设置后台管理页面访问控制权限（仅允许个别IP访问），设置多因素登录VPN；
对于无法从代码层修复的系统应直接关闭系统或关闭映射，若实在无法关闭的话，需要将其与其它系统单独隔离出来；
对于公有云上的资产应该设置安全组，接入云安全防护（如云防火墙）、软件安全防护软件等。
4、补丁修复
根据2020年的HVV风险总结来看，内网的隐患占到47%，排名第一，其大多数表现为内网大批漏洞、补丁、弱口令不修复、内网缺乏隔离产品等。在这里我们列举一些红队利用频率较高的漏洞：
中间件的反序列化漏洞：Jboss、Weblogic、shiro；
远程执行代码漏洞：Struts2系列漏洞、Jekins任意读取、ElasticSearch任意文件读取、Glassfish；
未授权访问：RabbitMQ、Redis；
操作系统：windows 各种远程执行代码漏洞；
后台弱口令和未授权访问；
应用系统的任意文件上传Getshell；
5、中间件及第三方组件安全
常用的中间件及第三方组件是最容易被忽视和被利用的一个环节。常见的中间件及第三方组件有：redis、activemq、memcache、rabbitmq、AppServ、Xampp、宝塔、PhpStudy、Dedecms、thinkphp 5.x、phpcms、ecshop、Metinfo、discuz、帝国cms、wordpress、joomla、drupal等。
这些中间件及第三方组件主要问题：
使用默认密码或直接未授权访问；
使用的老旧版本存在大量已知漏洞，如：ThinkPHP3.x注入漏洞、ThinkPHP6 任意文件操作漏洞、CVE-2020-13920 Apache ActiveMQ 远程代码执行漏洞、wordpress File-manager任意文件上传、CVE-2020-13933-Apache Shiro 权限绕过漏洞、PHPCMS v9全版本前台 RCE、PHPCMS v9全版本前台RCE、PHPCMS V9 存在RCE漏洞、CVE-2020-25540 Thinkadmin v6 任意文件读取漏洞；
后台管理页面直接对外提供服务。
加固建议：
升级到官方最新版本；
修改默认密码或空密码；
限制访问这些资源。
6、应用系统
应用系统最主要的风险来源于应用系统或软件的使用过程，尤其在网络环境下，其主要包括：
应用系统安全性；
未授权访问和改变数据；
未授权远程访问；
不精确的信息；
错误或虚假的信息输入；
授权的终端用户滥用；
不完整的处理；
重复数据处理；
不及时处理；
通信系统失败；
不充分的测试。
加固建议：
根据应用系统业务重要性进行分级处理；
对所有应用系统进行漏洞扫描并整改；
对重要系统进行渗透测试并整改；
重要系统暂时无法修改进行限制访问；
非重要系统暂时无法修复建议暂时下线。
7、弱口令
根据数据分析显示，所有成功突破外网边界的手段中利用弱口令进入的比例高达70%。口令是网络信息安全基础中的基础，直接决定了系统和信息的安全性，当弱口令安全得不到保障时，则黑客可以通过暴力破解等手段，轻易地进入后台或者系统中进行数据窃取。据统计，常见的弱口令top10有：123456、12345、123456789、Password、iloveyou、princess、rockyou、1234567、12345678、abc123。
弱口令的修复主要从两方面：一是技术手段、二是行政手段。
技术性修复弱口令：
1、密码长度应不小于8位长度；
2、密码复杂度要有大写字母、小写字母、数字、特殊字符至少三种组合；
3、定期更换密码，三级系统不超过30天，二级系统不超过90天，到期后下次登录强制修改密码；
4、强制密码历史，最近10次使用的密码不可重复使用，且密码中重复的字符不应超过5位；
5、建立弱口令库（收集互联网上公开的密码库、弱口令TOP1000字典等），新建密码时对弱口令库中的密码进行匹配，若匹配上了则无法使用该口令；
6、登陆界面设置验证码，验证码应进行扭曲、变形、干扰线条、干扰背景色、变换字体等处理，避免被OCR识别。验证码使用一次后失效，且应由后端服务器生成，避免被抓包绕过或重放利用。
行政性修复弱口令：
1、加强人员安全意识培训；
2、通知统一修改一次密码。
8、网络设备
目前各个单位的网络系统都有较大的规模，且结构复杂，组网方式随意性强，这就导致了网络中网络设备、安全设备缺少有效的策略控制。不规范的策略配置可能会导致设备故障配置丢失、非法外联、非法内联、东西向的互联网渗透、南北向的内网横向渗透、设备“0 day”漏洞等风险。
加固建议：
1、应绘制与当前运行情况相符的网络拓扑结构图，并维护网络中的设备资产清单，详细记录设备连接情况、接口信息、管理密码等信息；
2、应定期对所有网络设备、安全设备的配置进行备份，并测试备份文件的有效性，备份周期建议不超过30天；
3、由于telnet协议是通过明文的方式进行数据传输的，黑客可以通过arp攻击、抓包等方式获得设备的密码，如非特殊情况应关闭所有网络设备、安全设备的telnet服务，即禁用23端口，采用更安全的SSH远程管理方式；
4、所有网络设备（含物联网设备）、安全设备应启用管理主机，只允许可信的IP访问设备的运维端口（22、80、443等端口），如视频会议后台、摄像头登陆界面、设备登录界面等；
5、网络设备、安全设备应启用密码复杂度、登录失败次数锁定以及会话超时退出等功能，且应采用双因子认证的方式（采用动态口令、数字证书、生物技术和设备指纹等两种或两种以上组合的鉴别技术对用户身份进行鉴别）进行登录；
6、所有网络设备、安全设备应定期排查策略的有效性，并按照最小化原则进行权限划分；
7、所有接入网络的网络设备、安全设备应进行IP/MAC地址绑定，保证设备的可靠运行；
8、优化边界防火墙的访问规则，限制除业务必须外联的服务器以外的设备访问互联网，禁止服务主动外联，如果发现主动外联的IP地址，应立即报警追溯，特殊服务器（DNS服务器、补丁服务器等）需主动外联的除外；
9、防火墙应删除多余或无效的访问控制规则，优化访问控制列表，并保证访问控制规则数量最小化，在访问控制列表第一条创建拒绝高风险端口（135、137、138、139、445等勒索病毒常用端口）通信规则，默认情况下除允许通信外受控接口拒绝所有通信；
10、边界防火墙应删除多余或无效的NAT规则，只保留业务必须的端口映射至外网，严禁将高风险端口（运维端口、数据库端口等）映射至外网，如果需要远程管理，尽可能使用VPN、专线、4A接入等手段，保证接入管理的安全性；
11、建议在网络边界、重要网络节点，对重要用户的行为和重要安全事件进行日志审计，便于对相关事件或行为进行追溯，且审计记录应保存180天以上；
12、安全设备的规则库版本应升级至最新，才能及时有效地发现新型攻击并阻断，保证业务安全；
13、网络设备、安全设备系统版本应升级至最新，通过攻防演练已经有较多安全设备出现“0 day”漏洞，且漏洞利用难度低，危害大。
9、网络分区分域
由于资金、网络规模、管理方便等历史原因，网络安全分区总是不那么合理。往往一个区域混杂多种流量，各个流量相互影响，容易由于某个业务遭受攻击连带影响到其他业务。当规模不断扩大时，就像一个隐形炸弹，管理人员光是梳理清楚流量都要耗费大量的精力，甚至有时候由于人员变动，没有人分得清楚流量间的关系，给后续的运维带来非常大的成本。一旦发生故障将要耗费大量的时间排错。
根据网络安全分区防护的要求，结合应用系统服务器之间服务层次关系的分析，引出了新的层次型网络安全区域模型。该模型用垂直分层、水平分区的设计思想系统阐述了这一新的网络安全区域的划分方法。
在划分安全区域时，需要明确几个安全区域相关的定义，以免模糊他们之间的概念，造成区域划分完之后，依然逻辑不清晰，安全策略无法明确，立体的纵深防御体系也无法建立。
一般在安全区域划分时，需要明确如下常用的定义：
（1）物理网络区域
物理网络区域是指数据网中，依照在相同的物理位置定义的网络区域，通常如办公区域，远程办公室区域，楼层交换区域等。
（2）网络功能区域
功能区域是指以功能为标准，划分的逻辑网络功能区域，如互联网区域，生产网区域，办公网区域等。
（3）网络安全区域
网络安全区域是指网络系统内具有相同安全要求、达到相同安全防护等级的区域。同一安全区域一般要求有统一的安全管理组织和安全防护体系及策略，不同的安全区域的互访需要有相应得边界安全策略。
（4）网络安全层次
根据层次分析方法，将网络安全区域划分成几个不同安全等级的层次，同一层次包含若干个安全等级相同的区域，同层安全区域之间相互逻辑或物理隔离。
尽管不同企业对安全区域的设计可能理解不尽相同，但还是有一般的安全区域设计原则可供参考。常规的网络划分包括DMZ区、互联网接入区、内网办公区、服务器区、安全管理中心。每个区域之间利用防火墙、网闸、ACL、VLAN实施逻辑、物理的隔离，形成一个垂直分层、水平分区的网络安全区域模式。
当整个网络环境因历史原因一时无法采用物理方法划分到位时，可采用微隔离产品进行软隔离，从而达到相对安全状态。微隔离产品主要是对同一安全域内服务器按一定规律进行最小划分组，实现组内相对自由、组间严格管控，最大层面上缩减内网暴露面提升内网安全。
10、办公网络安全
办公网络存在主要存在以下几个风险：恶意攻击和木马病毒。
加固建议：
1、及时修复漏洞；
2、关闭无用的互联网出入口；
3、及时更新防火墙、杀毒软件病毒库、规则库；
4、搭建统一桌面管理系统、网络防病毒系统并要求所有办公电脑安装两个系统客户端，并由各部门主管落实安装情况或者开启相关系统准入功能。将所有办公电脑安装完成后，可由桌面管理系统和防病毒系统进行配合管理；
5、开启对应办公网段桌面准入功能，凡是所有接入办公网段均需要安装桌面管理系统和防病毒系统；
6、桌管及防病毒系统后台进行IP限制；
7、对办公电脑进行分组下发策略，如无特殊情况限制所有人员使用USB接口；
8、下发定时体检定时扫描策略，每天中午分组对所有办公下发定时体现、扫描策略，并根据体检、扫描结果对问题电脑进行相关整改。
11、WIFI网络安全
WIFI网络主要存在以下几个风险：被盗用的风险、被窃听的风险、被控制的风险、钓鱼攻击风险。
加固建议：
1、隐藏服务标识；
2、用户认证设备；
3、提高保密性能；
4、检查办公环境内存在多少WIFI信号，是否存在未知的信号，加密类型是否为弱加密；
5、检查是否存在空口令的WIFI信号；
6、使用万能钥匙尝试连接，对连接成功的需要查看信号源、口令强度以及是否可以访问内网；
7、连接成功的WIFI尝试访问管理界面，查看是否存在弱口令；
8、严禁私拉WIFI，所有的WIFI信号都需要严格把控，做好设备准入和访问控制（无线准入、无线区域的防火墙），如果没有准入的话，要通过绑定ip/mac来限定，设备也要设置强口令。
12、安全产品自身安全
安全产品自身存在的风险主要是在安全产品部署和运维过程中，尤其在复杂网络环境下，因运维操作而产生的风险，主要包括：
1.可能存在安全产品老化或产品版本未更新等风险。
2.所有类型的安全产品，可能存在运维配置风险，例如：弱口令，无登录次数限制，无多因子认证，未定期更新系统版本和相关规则库。
3.对于相关的网关类安全产品，可能存在全通策略等不严谨策略的风险，不定期分析和加固策略的风险。
4.对于审计监控类型的安全产品，可能存在不定期镜像流量异常情况或上传日志文件有效性完整性等风险。
5.对于安全产品的管控方面，可能存在安全产品没有开启带外管理，或纳入统一的安管平台，无法有效的管控等风险。
加固建议：
1. 用户身份鉴别：在用户请求访问系统资源时至少进行一次身份鉴别。
2. 访问限制：有且只有授权用户才能访问分配给该用户的资源；用户不能访问没有分配给该用户的资源。
3. 用户分级管理功能：安全防护产品应具有多用户分级管理功能，应可建立具有不同权限的用户，并可以针对不同客户设定对资源的不同访问权限。
4. 管理员身份鉴别：应保证只有授权管理员和可信主机才有权使用产品的管理功能，对授权管理员和可信主机应进行身份鉴别。
5. 管理员权限：定期队管理员属性进行修改（更改口令等）；并且制定和修改访问控制安全策略。
6. 身份鉴别时效和失败处理：当用户的失败登录次数超过允许的尝试鉴别次数时，应能加以检测，并应该阻止该用户的进一步登录尝试，直至授权管理员恢复对该用户的鉴别能力。
7. 安全防护产品在部署和安置的位置要尤为注意，需要进行单独分区分域管理，避免安全产品出现0day漏洞导致攻击人员直接进入业务网络进行破坏或者其他进一步操作。
本文来源：安全狗safedog
<!– 多条广告如下脚本只需引入一次 –>
版权归原作者所有，如若转载，请注明出处：https://www.ciocso.com/article/504.html
