云舒 http://icylife.net/yunshu
互联网企业网络安全架构系列之一 —— 前言
早就想写一点关于互联网企业网络安全方面的文档。但是在开始之前，我先说说写这个的原因。
在北京雅虎两年，杭州阿里集团三年，进行了很多次面试、招聘。发现博士大多数是在做神经网络、人工智能，硕士一般在搞可信计算、linux下的溢出分析保护，当然，这几年多了些在实验室搭建几台ubuntu、XEN搞云计算的。本科生则以windows下面的二进制行文分析、基于snort改装的IDS之类项目为主。接触过实战的，主要分为两类，web系列的，和溢出破解系列的。而我做的网络方面的工作，基本找不到人，这是让我无比纠结的一件事情。细想起来，也许有两个方面的原因，第一是缺乏环境，他们找不到上千台服务器的IDC网络，也找不到上千台PC终端的办公网络。第二个原因，则是书籍资料。网络上免费的书虽多，但是也是web安全的和二进制安全的好找，网络架构方面的则偏少。而第一个原因的存在，又导致在没有书的情况下无法在真实的环境中摸索碰撞，就像我当初在摔的各种跟头中进步。
那么，我就写一点提纲性的东西吧，希望能带一些人入门，然后可以让我更容易招人，让大家都更容易的招人。
互联网企业网络安全架构系列之二 —— 我的甲方安全观
谈技术之前，先说一下我对甲方网络安全的大观点，这是后面的基调。不喜欢看的，请果断跳过。
在甲方做事情，要习惯能用技术搞定的都不是问题，人才是问题。很多好的方案没有得到彻底的执行，很多完善的流程以及标准操作手册，都有人有意无意的跳过，打包好的经过安全加固的软件包，产品运维部门的人视而不见却喜欢耗时的自己编译，然后看着屏幕上一屏一屏的刷过的字幕发呆。当你对这些事情感到痛苦的时候，那就说明有一些甲方的经验了。解决这种问题，有五大法宝，策略、标准、流程、复核，以及行政处罚，五大法宝是互相协调不可分割的，贯穿其中的是良好的沟通。
策略，就是“法律”，明确的描述出什么事情是不可以做的，做了之后会有什么样的后果，导致什么样的处罚。这是后面的标准、流程、复核以及处罚的基础，立法在先，勿怪言之不预。策略的编写，是一定不可以一个人坐在座位上写的，这样的脱离实际无法执行的策略发出来注定骂声一片。好的策略，一定要多方面的沟通，IT、SA、NET OPS（Network Operation）、APP OPS（Application Operation）、DEV、QA各个部门都要照顾到沟通到，了解他们日常工作中的做法，在此基础上以提升安全性为目标做一些修订。策略描述可否，不涉及到具体事情的操作细节，常见策略如：IDC对外开放端口策略、公司内部网络访问策略、服务器上线策略、软件包部署策略、外包人员管理策略等等，由于公司安全制度我就不说太多。
相比策略而言，标准就是操作细节，类似于卫生部公布的《老年人跌倒干预技术指南》。对照来看，策略里面包含服务器上线策略，里面可能规定操作系统要进行安全加固配置，那么，标准里面就应该包括企业常用的各种OS加固标准，明确加固一步一步应该怎么做，让新手可以按照标准中的描述顺利完成整个加固过程。当然，好的标准还可以提供实施的自动化工具，帮助操作者自动化完成某些工作。标准需要尽可能做到完善，从底层的OS加固，到上层的WEB代码的编写，到员工离职后的IT部门的操作，都需要涵盖到。
策略和标准，都是纸面上的东西，而且也非常容易只是存在于纸面，除了让外审看起来很漂亮之外在没有别的用处。解决这个问题，就需要流程出手了，流程的主要作用是用来保证安全部门的各项策略在部门间顺利执行，流程的每一步，都涉及到一个或多个标准。同时，流程需要注意单点问题，每一个关键的步骤，都需要有多个人员备份。还是以上面的服务器上线策略为例，在流程的SA缓环节，他们可能需要遵循服务器安装标准，在APP OPS环节，他们可能需要遵循应用软件如apache加固标准。其次，流程能够带来信息透明度，这一点对安全部门来说尤为重要。因为网络是一个整体，安全更是一个动态平衡的过程，某一个方面的一点小改动，如新增一个IP段，新加一个静态路由，都有可能导致另一个地方的ACL出现缺陷。安全部门需要及时的了解这种大大小小的变化，根据策略推动对应部门实施针对这种变化的措施。关于流程，还有一点非常的重要，那就是不同的时期对流程有不同的期待。企业的初期流程很少，变更非常的轻巧快捷，这是初恋。但是随着公司逐渐壮大，会形成一个混乱期，发现事情缺乏一种条理性，有些事情找不到对应的负责人，这是感情在长跑。这个时候，公司会着手大力建立流程，开始逐渐感受到美好，一切井井有条，这个是蜜月期。随着时间的退推移，流程会越来越多，当发现做事情非常的僵化，缺少灵活性企业变得像国企一样的按部就班的时候，那就是婚后的麻木期了。这个时候，公司又会开始精简流程，做一些适当的删减。总之，流程就是一个轮回的过程，动态的平衡，需要小心的把握。
流程很好，但是并非绝对能保证策略和标准完美精准的执行下去，因为执行者是有感情的人，甚至可能因为前一天晚上没爽到导致第二天执行流程审批的时候一疏忽就放过去一个不应该批准的申请。因此，我们需要最后一步，复核。复核是最后一道关卡，可以是每个流程执行完毕都触发一次，也可以是周期性的自动触发审核所有的网络和系统。需要注意的是，复核的内容需要和策略以及标准是对应的，否则最终会形成无法可依的局面，在打人板子的时候找不到着力点，因为他们会有一个很好的理由，那就是安全部门没告诉我不能这么做。
最后终于到了行政处罚了，关于这一点，我不想多说。多少年来，就一直有人争论是要技术还是要管理，是三分技术七分管理还是七分技术和三分管理等等诸如此类，所以我就不参与了。我的观点是吃米饭不影响吃面条，这顿吃米饭下顿吃面条，这顿吃米饭下顿继续吃米饭，都是可以的，能吃饱就行。只是行政处罚一定要非常慎重使用，这个属于大杀器。BTW，我今年在阿里就被行政处罚过，当然是我做事考虑不周导致出现网络故障。
总的来说，我的观点是安全部门的责任是明确的告诉大家如何不犯法，并且提供各种手段保证大家尽可能不犯法。最后对于出现的不好行为，做到有法可依，有法必依，执法必严，违法必究。就我个人而言，我做得并不好，知易行难。
互联网企业网络安全架构系列之三 —— 办公网网络划分
现在可以从办公网络开始谈一点“狭义”的技术方面的问题了。我不想去谈办公网面临的风险，因为这些东西大家应该都比较清楚了，不外乎ARP欺骗、外部设备随意接入、PC补丁不全被网页挂马、测试服务器被映射到外网导致办公网被渗透诸如此类。直接从办公网的网络如何划分开始吧，介绍一个比较好的办公网络应该从何处入手开始构建。
在完全展开之前，需要先了解一点背景技术，主要是想描述一下802.1X协议，因为它在办公网络中的地位实在太重要了，从无线到有线、从VLAN划分到准入控制、从登陆认证到网络授权都难以避开它。802.1x是一个基于端口的认证和访问控制协议，通过EAP（Extensible Authentication Protocol）进行认证，控制一个端口是否可以接入网络。这里的端口可以是物理端口，也可以是逻辑端口，对于无线网络来说一个信道就是一个端口。802.1X工作在二层，加上EAP只是一个框架，可以由厂商实现具体的认证方法，因此具有非常好的扩展性，在办公网络的很多方案中得到应用。
对安全比较敏感的黑阔们可能已经想到，应用如此广泛的认证体系居然是基于端口的，这个认证这个粒度是不是太粗了？在一个HUB下接入N台PC，只要一个PC通过认证后该物理端口就针对所有PC打开了。针对这一点，又有公司提出了认证实体（Access Entity）的概念，除了常见的端口认证实体之外，增加了一个MAC认证实体，能够将认证粒度从端口下移到设备本身。关于这个问题，我曾经在一篇博文中描述过，和朋友们有一些讨论，参见http://www.icylife.net/yunshu/show.php?id=670，这里不细说了。除认证力度之外，EAP认证框架方面，不同的厂商也衍生出一大堆LEAP、PEAP、EAP-TLS、EAP-MD5等等具体的认证协议。提供了安全的认证方法，有了合适的可控对象，802.1X已经可以比较安全的在网络中使用了。
对802.1X有了初步的了解之后，我们可以开始看如何划分互联网企业的办公网络了。首先要理解的是为什么要将网络划分为多个部分。我不想从各种标准中去找理由，也不想去说那么多生硬的安全术语。就看看生活中吧，为什么一个国家分为很多个不同的行政区块？我想除了历史原因之外还有便于管理的因素在里面。每一个相对独立的区域，都有不同的最适合自身的个性化法律法规。并且，很多事情容易在一个较小的区域内处理而不涉及到全局的整体变化。即使在商场中，我们也能注意到有很多的防火门。这些防火门在出现火灾的时候，可以把商场切分成一个一个的区域，然后分别处理局部事件防止蔓延。在这些地方再延伸到网络中，划分区域的意义是大致相通的。
基于业务的不同，我们可以将办公网络分为两大块，服务器区和办公区。一般情况下，服务器区域又大致可以分为四个部分，内部业务区、公共资源区、开发测试区以及DMZ区，根据业务情况，这些大的区之间可以再进行细分。区域之间其实并不存在严格的安全级别的高低顺序，具体的访问控制依据公司的情况来实现。一般来说，内部业务区部署的是HR、财务、行政、高管支持等较为敏感部门的一些重要业务服务器以及常用的CRM、流程系统之类。公共资源区部署DNS Server、DHCP Server、Update Server等提供给公司全体员工使用的资源。开发测试区域则顾名思义给开发使用的，DMZ则是属于办公网所有但是又需要映射到外网的服务器，如Mail Server等，也可能包含一些测试性质需要临时对外的服务。
相比服务器区，办公区则庞大的多，因为太多涉及到人的因素处理起来也复杂的多。在早期，公司规模不大，安全还不是一个非常重要的因素，大家更宁愿采用静态VLAN的方式，简单方便，而且VLAN之间也不去实施访问控制。之所以部署VLAN是为了解决广播风暴之类的非安全问题，当然也可以说是广义的安全。等到公司规模扩张，而且笔记本移动办公比较普及，也更加推崇“沟通”、团队协作，静态VLAN就不再满足需求了，动态VLAN走上舞台。
最简单最基本的动态VLAN是使用基于MAC地址的划分方式，即VMPS（VLAN Management Policy Serve）方案。在这个方案中，简单的认为MAC地址在公司范围不重复不可伪造，MAC地址可以代表人的身份。VMPS需要一个映射MAC地址到VLAN ID的文本数据库，一般存储在TFTP服务器上。交换机启用VMPS以后从指定的TFTP服务器上下载这个VLAN映射数据库，然后打开一个UDP进程来监听从客户端发来的请求。当一个帧到达动态端口时，交换机根据帧的源地址查询VMPS，获取相应的VLAN ID，将该端口划入对应VLAN。当VMPS配置为非安全模式时，接到数据库中不包含的MAC地址的请求，交换机简单的丢弃来自该MAC的数据包，当配置为安全模式时，交换机将这个端口关闭。无论哪一种模式，对经常有客户拜访的公司都是会造成一些不变的，这就需要预置一个Guest VLAN，在其中设置独立的DNS Server以及其它必须服务，并设置为只能访问internet。然后在VMPS中设置默认VLAN，有不属于数据库中的MAC数据包到达时，交换机将该MAC对应的端口划入默认VLAN，与公司内部进行安全隔离。
VMPS的优点在于对交换机和网络环境没有特殊的需求，结构也简单，能够比较轻松的实现。另外一个优点是可以和IT的资产管理系统集成，直接导入MAC地址表降低收集MAC地址的难度。但是缺点也很明显，首先MAC地址是可以修改的，攻击者可以很容易得骗过VMPS划入到敏感的VLAN中；其次统计MAC地址难免出现遗漏，或者由于资产变更同步不及时，导致一些安全故障；最后，方案简单也意味着功能不够强大，如果基于行政上的组织架构划分VLAN，只能自己开发和域控对接。
稍微复杂一点的DVLAN方案，就是前面提到的802.1X了。这个方案需要有radius服务器，常用的有思科的ACS，微软的IAS，以及开源的Free Radius。假设公司部署了域控制器，那么在radius服务器上添加一个外部数据库，使用AD中的信息作为认证数据库。同时，将域上面的行政组织架构映射为radius上面的组，组关联到VLAN。在交换机上启用全局802.1X，设置认证服务器为配置好的radius服务器即可。域控制器并不是必须的，本质上，任何的LDAP数据库均可，只是企业里比较习惯性的使用AD而已。当用户登录系统的时候，认证信息依次转发，最后返回VLAN信息到接入层交换机。由于VLAN划分是基于登陆用户的，因此基于802.1X协议实现的动态VLAN功能非常强大，可以从AD取到用户的各种属性。但是缺点也比较明显，与交换机、终端对802.1X的支持程度紧密相关，部署复杂，出现问题的可能性也比较大。
上文描述了两种常见的动态VLAN划分方式，但是它们并不是解决网络划分问题的万能药。当网络规模达到阿里巴巴这种万级别终端的时候，动态VLAN就会暴露出许多问题。一个BU的员工，分散在全国甚至世界不同的城市，然后通过site to site vpn连接在一起。即使在最大的滨江园区员工办公也不再局限于一栋楼，而是在楼与楼之间移动，VLAN能够跨越多大的范围（这里先忘记云计算的大二层网络，后文我会去重点介绍）？二层互通会不会带来楼层之间的广播风暴？如果一个楼的故障如果需要去另外一个楼甚至另外一个地点解决，也是一件很痛苦的事情。也许有人会说，我们无需做到二层互通，只要保证每个办公地点有相同的VLAN ID，然后ACL策略统一分发过来即可。当员工在楼之间迁移时，得到的VLAN ID是一样的，访问控制策略也是一样的，虽然VLAN其实是多个分离的。这样做不是不可以，但是又引入了一个新的比较麻烦的东西——策略同步问题。是否有更好的方案来解决问题？让我们先回到划分VLAN的本质上来。显然，我们设置VLAN是为了控制员工之间的相互访问，以及部门与服务器区域指定服务器群的访问关系，比如只有财务VLAN可以访问财务的管理服务器。在这里，策略其实是基于VLAN或者IP段实施的，也就意味着我们是在用IP代替人来进行控制。那么，我们是否可以把眼光从IP段、VLAN ID上移开，不再关心它们，直接把策略落到人的身上，至少从二层三层往上移？关于这一点，我不再继续下去，不用我的想法去毒害束缚大家。而且对一般的环境来说802.1X足矣。但是这个思路，我想是正确的。
评论关闭。