【51CTO.com原创稿件】最近，AC公司组织安全部门对即将上线的一款云交流与协作平台，在模拟的环境中进行了全方位的渗透测试。大部分测试结果指向的是与Web应用程序有关的安全漏洞，需要项目组的程序员和DBA们进行整改。但是与此同时，也暴露出了一些与平台部署与环境有关的自身脆弱性问题(如下图所示)。
套用OWASP Top 10理论的分析，这些可以归咎为“A5 – 安全配置的缺失”。虽然从报告结果的严重程度来看，不是那么的outstanding，但是这让一直着眼于软件程序方面的项目组领导终于顿悟到了那些有别于security coding之类的木桶短板。
的确，安全配置是来不得任何freestyle的，我们要有严谨的操作流程和打持久战的心理准备。那么，怎样才能做好全面的安全加固准备呢?其实还是有一定套路可循的。基本的思路包括：
- 识别本系统所涉及到的安全配置项。
- 着手按照一定顺序，如网络系统的层次结构，予以实施。
- 初始化建立安全配置的管理。
- 保持并动态维护各种安全配置。
安全配置项：全面私人定制
一般而言，我们可以从“操作系统->Web服务器->应用服务器->数据库服务器->管理后台->软件运行环境”，来逐步深入展开。下面是一些最基本、最普遍的配置项示例，我希望能给小伙伴们带来火箭一级助推的效果。同时希望大家能自行补齐属于本企业的“多级助推”，成功high上天。
操作系统-Windows Server：
- 帐号伪装之真假三人组：先重命名管理员帐户的名称，并设置为强密码，然后禁用该账号。对!你没看错，费这么大劲儿还是要禁用它，原因是此货的风险太高了。是不是想起了小时候看的电影《铁面人》路易十四啊?就是这个套路。
- 然后，创建自己的“太阳王”：新的管理员帐户名称，是那种自己能识别，别人不太能猜透的名称，并创建强密码。随后，将其加入到Administrators组中。
- 这还不够，我们还要创建一个“马甲”管理员，名字还叫做administrator。但是呢，将其放置到guest组里去。
- 按照“先禁用三个月、再删除”的策略将系统自带的以Guest为首的一干无用帐号打入冷宫。
- 接着是“约法三章”：通过本地安全策略来加固密码强度、留存期、帐号锁定策略，不显示最后登录的用户名、限制软件的安装，并添加审核策略。
- 仅限Administrators组具有“本地”、“远程关机”权限以及“文件或其他对象的所有权权限”，禁用“允许系统在未登录前关机”，将“本地登录”和“从网络访问”分配给指定的帐号。
- 关闭系统的默认共享，尽量不要使用共享文件夹，非要启用的，要制定访问帐号。
- 做好文件权限的保护，在重要文件夹属性的安全标签里删除父项继承(如下图)，以及一般用户组的可修改权限。
- 通过配置日志，使系统能够“审核登录事件”、“策略更改”、“对象访问”、“特权使用”、“系统事件”、“帐户管理” 以及“ 进程追踪”。当然也要注意配置日志文件的大小和归档。
- 通过对注册表的键值设置，将TCP连接请求数阈值(TcpMaxPortsExhausted)设为5、TCP 半连接数阈值(TcpMaxHalfOpen)设为500、以及重传的TCP 半连接数阈值TcpMaxHalfOpenRetried设为400，从而实现对SYN攻击保护。
- 禁用网卡属性里的TCP/IP上的NetBIOS，以及系统上的服务。
- 关闭默认无用的服务，包括Computer Browser、IP Helper、Print Spooler、Remote Debugging、Remote Registry、TCP/IP NetBIOS Helper 、Windows Remote Management、WinHTTP Web Proxy Auto-Discovery Service、Windows Error Reporting Service等。
- 不允许远程访问注册表、对SAM帐号的匿名枚举，而启用对通信进行数字签名、基于128位加密的NTLM SSP的最小会话安全。
- 通过自动订阅或定期手动的方式，及时给系统打上补丁。
- 当然也要安装好主机级的防病毒软件，并运用工具定期扫描。这一步就像我们小时候经常假想自己拥有的一种特异功能：把耳朵天线打开一样。
操作系统-Linux：
- 运用passwd -l锁定不必要的帐号，运用userdel命令删除不必要的帐号;查看口令为空的帐号并设置复杂密码;查看UID为0的帐号，并确保只有root。
- 通过在/etc/profile中添加传说中的“umask 027”，实现新建文件仅“属主可读写，同组用户只读和执行，其他用户根本无权”的默认文件管控。
- 编辑/etc/pam.d/common-auth文件，添加“如果连续输错三次密码，则帐号锁定半小时”的策略;并编辑/etc/pam.d/su文件，限制能够su到root的用户组。
- 通过script实现对全部用户的登录进行日志记录。
- 关闭不必要的服务，并通过编辑/etc/ssh/sshd_config文件，对SSH使用的版本、允许的密码错误次数等进行加固。
Web服务器-Apache/IIS：
- 修改默认帐号及其密码，创建专门用于运行的用户帐号和组。
- 严格控制主目录的访问权限，非特权管理用户不能修改或写入该目录中的内容。
- 通过配置，跟踪包括时间和用户使用的 IP 地址等信息，来实现对运行错误和用户访问等方面的日志记录。
- 禁止该服务访问本Web目录之外的任何文件。
- 禁用或拒绝目录罗列的功能与浏览请求。
- 修改设置错误页面重定向功能，并隐藏版本号及其软件相关的敏感信息。
- 设置 session的保持时间，以应对DoS攻击。
- 删除默认安装的无用文件、文件夹和脚本。
- 对于Apache，要禁用TRACE、CGI功能;禁用PUT和DELETE等危险的HTTP 方法，仅允许GET和POST方法。
- 对于IIS，禁用掉不必要的Web服务扩展(WebDAV)和应用程序扩展，限定支持的页面类型。
如前所述，另外还有其他方面需要进行安全加固与配置，这里就不赘述了。我们的基本思路就是：做好账户(组)和例程脚本的剪裁，文件(夹)访问、端口和服务的最小化，会话连接、错误信息与日志的设置，管理后台的更改以及安全补丁与杀毒的更新。
在根据上述流程逐步完成了系统与服务的安全配置，并且导入了相关的业务数据之后，我们就可以进行多种、多次的漏洞扫描和渗透测试了。我们的宗旨就是要在系统的起步阶段，尽量扫清如OWASP提及的十大安全隐患。
配置管理库：自制月光宝盒
如果您是在边读边做的话，那么到这里，恭喜您基本上闯过了“OWASP Top 10的A5—安全配置缺失”这一关。那么该怎么“纪念”一下呢?我们就来个“立此存照”—将这些配置的经验和方法都录入到配置管理库吧。有关配置管理库的基础知识，大家可以去问“度娘”，当然也可以通过猛戳这里来进行快速和直接地获取—http://zhuanlan.51cto.com/art/201612/525020.htm。而这次，我主要跟大家分享的则是有关安全配置项在入库时和使用中的事项。
- 配置项入库要做好命名规则的一致性。如：<站点/部门/项目名称>-<系统/服务名称>-<主机名或软件名称>-<型号/版本信息>-<创建YYYMMDD>。
- 事先为每个配置项定义好丰富的标识类元数据。通过在入库时填写相应的完备信息，方便事后对该项的快速查找与定位，从而大幅提高配置项的复用价值。
- 管理库的目录结构应当按照服务系统架构里的功能、地域、类型等多个维度进行清晰、全面的设定，以保证配置项能够直接“拎包入住”，且被正确放置。
- 细粒度地定义各个配置项所在文件夹的所有者，和其对应的访问权限;禁用直接删除任何配置项的功能，改用“先标记，7天后系统自动删除”的策略。我们在实际使用中发现这样能最大限度地防止误删等操作的发生。
- 实现对配置项的版本控制和任何操作的日志记录与审计功能，就像配备了一台小型time machine一样。
- 最后，记得在每一次完成系统或服务的相关配置之后，都要习惯性的将其“快照”下来，做成“配置基线”，添加注解，再备份到配置管理库中。与此同时还要检查从库里签出的，本次参考过的配置模板和操作指南，确保其可用性，以方便下一次还能够“开箱即用(OOTB)”。
大家可以试想一下：如果没有对各种应用安全配置信息的可用性、完整性和有效性的持续管理，我们的系统将如同那艘驶向“三体舰队”的探测器一样终将在各种风险因素的作用下完全失控。可见，我们只有通过对配置知识库的建立和维护，加上一整套行之有效的入库和签出管理，才能从源头上解决以往诸多企业在安全配置上仅能单方面依靠运维大牛的个人经验与能力的现象。而且，这能够杜绝各种人工批量操作时的失误可能性。
变更管理：以万变应万变
说了那么多的配置，思路清奇的您是不是已经想到了它那相爱相杀的好基友--变更管理呢?还记得我们在廉环话的变更与发布章节就讨论过变更管理的基本概念和流程。这里我给大家补充一些有关配置项变更的内容吧。首先，就算仅仅是对配置管理库里的配置项基线的细微变更，都要准备一份与之对应的变更请求(Request for Change，RFC)，其中包括：
- 变更发起人与实施人：发起变更请求的不一定是真正实施的人。
- 所涉及到的配置项及类型：服务器、路由交换、存储设备或软件相关等。
- 简单描述：主要是变更意图、必要性和预期的效果。
- 波及范围：包括在逻辑上波及的现有IT系统与服务，和在地域上牵扯到的部门、站点或外部客户。
- 紧急程度：视需要和严重程度进行综合且如实的判断。
- 请求开始和结束的日期/时间。
- 最重要、最详细的三大元：实施步骤、后退回滚步骤和完成后的效果测试步骤。
- 附件：可以附上必要的截图、邮件或文档，让变更管理者更为深入和全面的了解该变更的来龙去脉。比如说下图就是一份标准的虚拟机添加模板。
下面是我们正在使用的一个风险矩阵的示例：
而作为变更管理者最好能够做到：
- 多找几个“臭皮匠”组成委员会(Change Control Board，CCB)，既能互为备份，又能集思广益、风险共担。
- 手头应该有一张“事件汇总日历”，能够全局性地根据请求时间来判定当日的忙闲程度，从而在批复通知里的批准实施的时间项上做适当的微调。
- 及时地将新批准的变更加入到总日历对应的时间段中。
- 伺机用现成的模板向变更将要波及到的人群发送服务中断和变更实施通知。当然，重要的变更可以“说三遍”。
- 针对实施过程中报告上来的变更失败，既要确保能够“回滚”到原配置项状态，又要引入事故或问题管理流程。
小结
通过重视对安全配置的设置和配置管理库的运维，AC公司的云平台顺利通过了各种后继的测试与检验，并已正常上线。运行至今，按照其项目负责人的说法是：“So far so good，我们的团队仍和它愉快地玩耍着。”
在这个暑假里，我陪着小孩子经常对弈国际象棋。有一天我突然顿悟到：其实我们平时做的系统安全设置就像下棋一样，我们并不是比的是谁下得水平高，而比的是谁犯错少。最后做一个小调查：行文风趣的廉哥和专业高冷的大拿，你更爱看谁的文章呢?留言告诉我吧。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
