设备和主机层安全架构设计

本文详细介绍了设备和主机层安全架构设计原理。涵盖了架构示意图、简介、身份认证与账号安全、授权与访问控制、运维审计与主机资产保护、基于主机的入侵检测系统。

设备和主机层安全架构

• 架构示意图
  • • ■ 身份认证与账号安全：最典型的场景是SSH登录安全。
    • ■ 授权与访问控制：谁有权可以登录、登录来源限制、端口开放限制。
    • ■ 主机资产保护：防止恶意软件破坏主机计算环境，如防病毒、主机入侵检测等。
    • ■ 主机运维审计与入侵检测。
• 简介
  • 主机层的基础设施主要包括：
    • ■ 主机统一认证管理。
    • ■ 跳板机、运维平台、数据传输平台。
    • ■ 操作系统母盘镜像。
    • ■ Docker容器基础镜像。
    • ■ 补丁管理，保障主机操作系统及组件完整性。
    • ■ 防病毒管理，防止病毒、木马、Web-Shell等有害程序危害安全。
    • ■ HIDS（基于主机的入侵检测系统），监测主机入侵行为并触发告警及应急响应。
• 身份认证与账号安全
  • 操作系统默认使用非实名账号和静态口令，风险包括：
    • ■ 使用的非实名账号（如root、administrator）在运维审计时难以定位到具体的人员，且黑客也可以使用这些账号登录。
    • ■ 冗余的账号，这些多出来的账号有可能是黑客留下的，或者虽然是员工创建的，但有可能被黑客利用。
    • ■ 通用口令，即多台服务器使用同一个口令。
    • ■ 弱口令，口令强度太低很容易被猜出的口令。
    • ■ 历史上已经泄露的口令，如员工通过博客、开源等泄露出去的口令，也可划入弱口令之列。
  • 由于非实名账号黑客也可以登录，无法关联到具体的使用人员，给事件定位、追溯带来麻烦；通用口令和弱口令很容易导致服务器口令被黑客获取，从而给业务带来风险。
  • 动态口令
    • 静态口令容易被黑客利用，不安全，所以安全的做法就是对SSH启用实名关联和动态口令。
    • Linux下面有一个PAM模块（Pluggable Authentication Modules，身份认证插件），可用于替换系统默认的静态口令认证机制，如果考虑自行开发的话，可从这里入手，跟企业的SSO关联，让员工可以使用统一的身份认证机制进行运维。业界也有公开的解决方案，如Google Authenticator、TOTP（Time-based One-Time Password）等。
  • 一次一密认证方案
    • 如果没有动态口令机制，在安全性要求不是很高的场景，也可以考虑一次一密机制，配合口令管理系统使用。一次一密，指的是每一次登录服务器的时候，都使用不同的服务器口令。
    • 不过，这种方案必须具备口令的修改机制，如变更时间窗（即申请执行运维操作的时间段）关闭的时候修改口令或定期修改口令（口令短期有效，超时自动改密）。
    • 在运维工具方面，还需要执行相应的权限校验和运维审计。
  • 私有协议后台认证方案
    • 一次一密机制仍存在泄露口令的风险。如果能够在业务服务器上部署一个Agent（代理程序），采用私有协议向其下发指令，由Agent代理执行运维指令，则可以规避口令泄露的风险，如图所示。
    • 所谓私有协议，是相对于通用协议而言的。通用协议，就是广泛使用的格式公开的协议，如HTTP、SMTP、SFTP。私有协议是指采用自定义协议格式且不公开该格式，仅在自身业务专门使用的协议，通过后台认证机制，以及对协议格式的保密，提高攻击者的研究门槛，可采用RPC（远程过程调用）机制以二进制的方式加密通信。
• 授权与访问控制
  • 通常在企业的CMDB（Conf iguration Management Database，配置管理数据库）中，每一台服务器主机都有一个运维责任人字段，也许还有一个备份责任人字段。
  • 我们就可以基于ABAC（基于属性的访问控制）原则，只允许主机的两个责任人登录，而拒绝其他账号的登录尝试。但问题就来了，为了资源的合理配置，可能有另一个业务需要复用当前主机，另一个业务团队的员工都不是该主机的责任人，这就需要用到授权表了。假设有一台服务器ServerA，有两位责任人分别是Alice和Bob，另一团队的Carol也需要登录该服务器。Carol就需要事先申请访问该服务器的权限，这样，授权表里就包含了一条记录：允许Carol在一年内访问主机ServerA。
  • 如图所示，当Carol通过运维平台尝试登录服务器ServerA，访问控制模块会先基于ABAC原则，检查Carol是否为该服务器的责任人，结果不是；访问控制模块继续访问授权模块，检查Carol是否具备访问该服务器的权限，结果是有权限且权限在有效期内，于是放行。
  • 主机服务监听地址
    • 运维端口属于内部运维专用，如果对外网开放，且使用了静态口令机制，则很有可能被黑客从外网直接登录，给业务带来损失。 如果服务器只有内网IP地址还好，但同时还有外网IP的话，默认配置也会开启监听，将端口暴露出去。 在sshd的配置文件/etc/ssh/sshd_conf ig中，可以找到监听地址设置： #ListenAddress 0.0.0.0 可将0.0.0.0修改为实际的内网IP地址并取消前面的注释符： ListenAddress 10.10.10.10 安全建议：业务服务器默认只配置内网IP, Web业务可通过统一接入网关接入，反向代理到内网业务，降低犯错的可能性。
  • 自动化运维
    • 登录服务器本身属于高风险行为，很可能由于员工误操作等原因造成配置错误、数据丢失等巨大损失。为了解决频繁登录可能导致的各种潜在风险，以及解决批量运维问题，就需要考虑建设自动化运维平台，在能力许可的情况下，应尽可能地实施自动化运维，将日常例行的运维操作放到自动化运维平台，减少日常登录服务器的操作。
    • 自动化运维平台，就是根据业务特点，将常规的例行的操作封装为应用，或者封装为自动化运维平台上的例行任务，不再经常登录到服务器，这比之前经常登录到目标服务器操作要更安全。
    • 使用自动化运维平台的好处有很多：
      • ■ 使用Web化界面，方便、效率高、体验好。
      • ■ 可屏蔽高危操作（如：rm -rf /），避免误操作。
      • ■ 方便跟SSO集成，用于员工实名认证。
      • ■ 方便执行权限管控、运维审计。
  • 数据传输
    • 在使用跳板机执行Linux运维时，用得最多的文件传输指令就是rz和sz了，但这只适用于小文件，不适用于大文件，速度慢不说，还经常出错，这就需要考虑专门的解决方案了。
    • 文件跨区传输，也可借鉴应用网关统一接入的方案，扩展应用网关的功能，将其升级为统一的访问代理，执行受控的TCP端口转发，如图所示。
    • 也就是说，访问代理不仅可以支持Web类业务，也可以支持非Web类业务的接入。当使用非Web业务时，可以在转发前要求员工通过SSO认证。
    • 位于访问代理后端的数据存储服务器可使用SFTP服务器，且SFTP不使用SSH通道，而是使用虚拟账号和自定义端口。
  • 设备的访问控制
    • 网络设备如路由器、交换机、防火墙等等，也会面临各种风险：
      • ■ 不正确的开放范围，运维端口或后台管理端口可以从业务网访问，甚至外网也能访问到，如果再存在弱口令，很容易被黑客所利用。
      • ■ 不安全的协议，如只能使用Telnet的老旧设备（Telnet协议明文传输口令等信息，如图所示）。
      • ■ 固件漏洞（固件即写入设备内部的可擦写可编程只读存储器的程序）。
  • 安全建议：
    • ■ 淘汰那些只能使用Telnet的老旧设备，消除Telnet协议的使用。
    • ■ 管理网跟业务网分离，让两张网路由不通，这样网络设备的管理端口就无法从正常的业务网络访问到。
    • ■ 及时升级存在漏洞的固件，避免存在漏洞的老旧版本固件引入风险。
• 运维审计与主机资产保护
  • 打补丁与防病毒软件
    • 在生产网络，针对Windows服务器的防病毒软件也是必选的。但对于Linux来说，选择非常有限，这时就需要采取一些折中的措施，比如可以在HIDS中建立典型恶意软件的HASH值数据库，用于比对检测，第一时间发现恶意程序，然后通过人工或自动的方式进行清理。
  • 母盘镜像与容器镜像
    • 主机的预置安全能力能否在业务交付使用前得到较好的保障，就需要依赖母盘镜像、Docker容器基础镜像维护团队了。这也体现了我们所提倡的“默认就需要安全”的理念。
    • 镜像中可以预置的安全能力有：
      • ■ 高危功能裁剪，将一些不常用的高危服务或功能裁剪掉，避免业务误开或者被黑客利用，比如禁用移动介质的使用，防止通过移动介质（如U盘、光盘等）引入病毒木马等恶意程序；以及禁用LKM（Loadable Kernel Modules，可加载内核模块），可以防止黑客植入rootkit等内核级后门。
      • ■ 安全配置，如内核安全配置、口令强度要求与锁定设置、日志开启等。
      • ■ 预置安全防御能力，如HIDS、性能监控组件等。
  • 开源镜像与软件供应链攻击防范
    • 面对开源组件，业界呈现出两种主要的流派：
      • ■ 第一种是不鼓励使用开源组件，只用少量几种开源组件，采用白名单式管理，并且需要有团队对其管理和维护。
      • ■ 第二种是大量使用开源组件，并对使用开源组件的行为加以规范和引导。
    • 对于第一种，通常来说，一切尽在掌握中，黑客很难通过发布开源软件的方式进入企业的生产环境。
    • 而对于第二种，黑客就有了可乘之机，可通过一种称为“软件供应链攻击”的方式，进入企业的生产网络。
    • 所谓“软件供应链攻击”，就是在软件开发的各个环节，包括开发、编译、测试、发布部署等过程中污染软件的行为，典型的行为包括：
      • ■ 污染软件开发工具及编译过程，添加后门、捆绑恶意软件等；在2015年9月的XcodeGhost事件中，超过4000个iOS APP是用被污染的XCode所开发，并在编译过程中被植入恶意代码；官方正版的XCode需要从苹果公司美国的服务器上下载，受制于国际带宽的影响，此下载速度非常缓慢，黑客正是利用这一点，将被污染的XCode上传到国内各种服务器并推广下载链接，让很多开发者猝不及防。
      • ■ 直接污染代码，添加后门；2017年8月，XShell（一款非常流行的远程终端管理软件）被发现植入了后门代码，并经过官方的代码签名，可导致使用该工具的用户泄露所管理的主机敏感信息；据分析，黑客极有可能入侵了相关开发人员的电脑。
      • ■ 污染社区软件源，误导用户下载恶意的开源组件，并使用在生产环境；很多软件源实际上并没有一个官方组织对其负责，常见的如Python的pip源、npm源等，都是人人可以上传的社区源；比如黑客曾经上传过一个伪造加密库crypt（这个是恶意的），就是傍上了常用的加密库crypto（这个是正常的），利用大家可能出现的拼写错误或模糊的记忆，如果不小心使用了pip install crypt就会将恶意代码植入受害者的电脑。
      • ■ 入侵官方网站，替换官方软件或升级包。
      • ■ 黑客向正常的开源组件贡献恶意代码，寻求合入主分支，或者尝试向那些没有精力维护开源组件的原作者索取控制权。
• 基于主机的入侵检测系统
  • 主机入侵检测就是在主机上检测入侵行为并告警，以便触发应急响应，对应的系统称为HIDS（Host-based Intrusion Detection System，基于主机的入侵检测系统），属于主机层可选的安全基础设施，构成安全防御体系的一部分。
  • 运维审计日志作为入侵检测的输入之一，协同工作，可做到：
    • ■ 事前预防（提前发现主机层面的风险，比如在网页脚本中调用系统命令等高风险动作，在危害尚未发生时就发出告警，提醒业务团队修复）。
    • ■ 事中控制（检测到高危行为时，可阻断该行为的执行）。
    • ■ 事后溯源（在发现安全事件后，对入侵路径、手法、利用的弱点等进行溯源，找出问题点供改进使用）。
  • 1．账号风险检测
    • 如图所示，主机账号（即操作系统账号）面临的风险，首先就是异常的账号名。如果对操作系统的用户名加以规范，例如按照指定的规则命名或者或跟员工ID绑定，那么不符合规范的用户名就属于异常，黑客创建的账号就能很快地被发现。对于异常，要么告警并通知整改，要么登记后让其合法化。登记报备的数据记录，包括责任人、报备类型、原因、有效期等，作为触发告警环节的排除项。
    • 其次，是弱口令。要防止弱口令，首选是强制使用动态口令。如果尚未推行动态口令，仍旧使用静态口令，就需要弱口令检测机制了。
  • 2．授权风险检测
    • 在已实施实名登录的场景下，如果出现非授权用户的登录动作，则授权机制出了问题，需要检查授权与访问控制的有效性。这需要结合设备责任人清单、授权表和登录动作，关联起来进行判断。
  • 3．访问控制风险检测
    • 如图所示，访问控制风险检测首先是登录行为检测。如果登录来源不是来自跳板机或运维平台，而是来自其他服务器，则可能是黑客已经渗透到内网。
  • 4．主机资源完整性检测
    • 我们提到资产的时候，除了数据，还有资源，包括网络资源、计算资源、存储资源、进程、产品功能、网络服务、系统文件等。
    • 服务器主机操作系统的相关资源，如系统文件、业务文件、进程等，也有可能受到外部恶意程序的侵害，典型的有：
      • ■ WebShell文件，可以让黑客通过浏览器执行操作系统命令。非登录用户（特别是Web服务器运行账户，如nobody、nginx、apache等）的命令执行操作，通常出现在黑客通过WebShell执行了系统命令。WebShell就是可以执行操作系统命令或解析脚本的Web界面，是一种典型的基于Web的恶意程序。
      • ■ 病毒、木马文件。
      • ■ 操作系统漏洞。
      • HIDS需要针对以口风险具备或整合相应的检测能力，