强叔被金庸大侠影响甚深，年少时曾手捧老先生各大部头废寝忘食，至今仍对多个经典情节念念不忘。早在十多年前，便与同道兄弟充分讨论过：金庸作品中，最厉害的招式应是独孤九剑，因令狐冲在内力全失情况下，一剑挑瞎十五人眼睛；而最厉害的内功当属扫地僧的内功，秒掉了萧峰父子和慕容父子，算得上前无古人、后无来者。最要命的是，我们无从得知扫地神僧是怎样练成的，这让强叔一直心痒不已。
而回到强叔开讲的防火墙，强叔绝不能让各位小伙伴一直抓耳挠腮--掌握了防火墙报文处理流程，就是掌握了防火墙实现的精髓，就如练成了扫地神僧的内功。表面上看来还是原来的小伙伴，也许貌不惊人，但其实内心那是相当地强大。当你能够娴熟地定位防火墙配置类故障，无论走到哪里，都会如那漆黑中的萤火虫一样，那样的鲜明，那样的出众，那样的拉风~~

在《华为防火墙产品一览》中，强叔曾介绍：华为出品低、中、高端共三个系列防火墙，对应当前的主力产品型号分别为USG2000、USG5000和USG9000。<注>2013年8月发布了下一代防火墙USG6000系列，强叔后续针对性详述。这三个系列产品毫无疑问都基于状态检测与会话机制实现，但是中低端防火墙与高端防火墙在架构实现上有些区别：中低端防火墙采用集中式架构，高端防火墙采用分布式架构，这使得它们在对报文处理的实现上，稍有不同。不过这个稍有不同并不影响主线，强叔的思路是单刀直入，先讲大同的报文处理流程（同样会话机制），再强调求同存异（架构差异影响）。

华为大同：全系列状态检测防火墙报文处理流程

下面先以USG5500系列产品为例，梳理防火墙报文处理流程。
状态检测与会话机制是华为防火墙对报文处理的关键点：即防火墙收到报文后，何时、如何创建会话、命中会话表的报文被如何转发。那么可以此关键点为界线延伸，我们将报文经防火墙处理分为查询会话表前、中、后三个阶段，参见如下USG5500报文处理全景图。友情提醒：图很复杂，对三个阶段有印象即可，重点看图下的文字拆解吧。

我们来进一步介绍下每个阶段的目的和处理过程。
1、查询会话之前的处理过程：基础处理。
这个阶段的主要目的是解析出报文的帧头部和IP报文头部，并根据头部当中的信息进行一些基础的安全检测（单包攻击防范）。
2、查询会话的处理过程：转发处理，关键是会话建立。
这个阶段到了防火墙对报文转发处理的核心。建立会话表，根据会话表转发报文，是状态检测防火墙的精髓。此部分要梳理清楚思路，耗费很多笔墨，还请小伙伴们耐心观看。
报文到此阶段，防火墙最先判断该报文是否要创建会话。
1）OSPF、IGMP组播报文等一些协议报文是不创建会话的，那么这些报文就会去直接查路由和安全策略。
2）而TCP首包、UDP等报文都需要创建会话，那么判断该报文要创建会话后，接下来马上查询会话表中是否已经创建了该报文的会话。

A. 对于会话表中不存在匹配任一表项的报文，防火墙判断该报文为某一流量的首包，进行首包处理流程。
B. 对于会话表中存在匹配表项的报文，防火墙判断该报文为某一流量的后续包，进行后续包处理流程。

这也是强叔在《状态检测和会话机制》一节中提到的“为数据流的第一个报文建立会话，数据流内的后续报文直接根据会话进行转发，提高了转发效率。”
首包处理流程要点：
（1）先使该报文与黑名单匹配，若报文源地址命中黑名单，则此报文被丢弃，不再继续后续流程。
（2）查询该报文是否命中正反向Server-map表，若报文命中Server-map表，记录Server-map表中的信息。

（3）继续根据（2）的记录结果，查询命中哪条路由，优先查询策略路由。若未命中策略路由，则查询正向路由表，决定报文的下一跳和出接口。

这里说明下：为什么要强调根据（2）的记录结果呢？因为此时报文未进行实质转换，但查询路由是使用虚拟出来的、命中Server-map表经转换后的报文查询，这是为了最终经过防火墙各种处理完毕的报文能够正确转发。

（4）查询是否命中安全策略，已知报文入接口源地址、判断出报文出接口后，可以查询到该出入接口所在安全区域的安全策略配置，若报文没有匹配到安全策略或匹配到安全策略中定义为“阻断”的规则，则报文被丢弃，不再继续后续流程；若报文匹配安全策略中定义为“允许”的规则，则继续后续流程。
（5）查询是否命中源NAT策略，若报文匹配到一条源NAT策略，则记录NAT转换后的源IP地址和端口信息。
（6）顺利通过安全策略匹配检查后，终于走到这一步：根据上述记录结果，创建会话。

后续包处理流程：

很简单，判断会话是否需要刷新。当为首包创建会话的各表项和策略（如路由表、安全策略）变化时，会话需要刷新。若需要则继续查询路由、查询安全策略，若不需要直接进行后续阶段处理。

总结：

强叔在开篇中提到防火墙与路由器的区别，对于路由器来说可说是使出浑身解数（通过路由表）将报文转发出去，而对于防火墙来说要作为守护神坚决阻挡非法报文（只有通过各种安全检查建立会话表才可能被转发）。所以防火墙丢弃一些报文是正常的处理流程，包括第一阶段的解决IP报文头、单包攻击，第二阶段的黑名单、安全策略，第三阶段的UTM处理、限流等等，是报文的主要丢弃点。
进行故障定位时，防火墙上是否创建了指定某条流量的会话，是定位要考虑的关键界线。若未创建会话，则考虑是报文是否到达设备、接口丢包、命中黑名单或安全策略、无路由、或NAT等配置出现问题；而存在会话，则向后续的安全业务处理阶段考虑。

3、查询（或创建或刷新）会话的处理过程：进行实质各安全业务处理、及之后的报文去向。

报文在首包处理流程中经一通查询、创建会话后，就与后续包处理流程殊途同归了，即都进入第3阶段。
此阶段首先进行基于IP的限流、IPS等UTM业务处理，报文顺利通过检查之后，到了实质性的地址转换：根据已创建的会话表，进行目的地址转换、源地址转换。
这个目的地址转换、源地址转换对应配置就是NAT Server、源NAT策略等NAT功能，对应报文则是在第2阶段首包流程中已经经过一通查询并创建了会话表。
那么，如果想要在此阶段能够准确地对报文进行源地址转换，有两个常见的points需要关注：

一是报文在前面流程中是否命中了Server-map表，尤其是反向Server-map表，若已经命中，那么报文会根据反向Servermap表进行源地址转换，不会再往后匹配源NAT策略了。
一是报文在后续流程中是否计划要进行VPN加封装，如果在此时定义该条数据流进行了NAT转换，那么后续就无法进入VPN协商流程了。

而按计划进行目的地址转换问题不大，一般是配置NAT Server，其报文处理优先级很高，报文走入歧途可能性就小。

最后，该转换转换，该过滤过滤，一切安全业务流程顺利通过后，报文终于到了分发十字路口：
A. 如ping、OSPF等路由协议报文是要到防火墙本身，会被上送至管理层面处理；
B. 如VPN报文（防火墙为隧道终点，收到VPN报文）就会被解封装、并在解封装后重走一次上述1、2、3流程；
C. 如准备进入VPN隧道的报文（防火墙为VPN隧道起点）就会被进行VPN封装等等。

求同存异：集中式与分布式防火墙差异对报文处理流程影响

防火墙大同的报文处理流程介绍完毕，我们来看一下集中式与分布式架构的区别会导致哪些差异。

对于集中式低端防火墙，来往报文会被上送至一个集中的CPU模块（可能由多个CPU组成）进行处理。
集中式防火墙一般为盒式设备，可以插接多种扩展接口卡，但设备的总机性能恒定，即取决于该设备配置的CPU模块处理能力。上述介绍的USG5500产品报文处理流程即为其全部流程。
对于分布式高端防火墙，对报文的处理就会比较复杂，有多种情况，上述介绍的报文处理流程是其中一个最核心的子集—SPU板业务处理流程。

分布式防火墙一般为框式设备，以USG9000来说，由两块标配主控板MPU、交换网板SFU、接口板LPU、业务板SPU组成，其中LPU与SPU的槽位可混插，客户按需购买。相比集中式防火墙，分布式防火墙由各种单板组成，每种单板各司其责。

主控板MPU：主要负责系统的控制和管理工作，包括路由计算、设备管理和维护、设备监控等。

交换网板SFU：主要负责各板之间数据交换。

接口板LPU：主要负责接收和发送报文，以及QoS处理等。

业务板SPU：主要负责防火墙的安全业务处理，包括安全策略、NAT、攻击防范、VPN等。设备总机性能随插接SPU板的数量增加而线性增加，这是分布式防火墙的特性和价值所在。

那么我们来看一下，各类报文在分布式高端防火墙上是如何被处理的：

已经提到①②是防火墙业务处理的核心，也正是防火墙的安全防护价值所在。③④多用于设备管理、定位故障；⑤⑥多用于网络互联如路由学习。

还有一个更复杂的问题：当一台分布式防火墙配置多个业务板时，报文经过接口板处理后，会被送至哪个业务板呢？如上图中的①②③④报文都会经业务板处理，那么会被送至SPU1还是SPU2呢？
这时会有选择“由哪块SPU板进行业务处理”的动作，即USG9000产品文档中提到的hash选板。默认配置是根据报文的源+目地址经过运算选择。----由于配置了多个SPU板，业务可能在防火墙多个业务板分别建立会话。
例如，以PC访问Web服务器来说，假设PC发往Web服务器在业务板SPU1上建立了会话，而Web服务器的回应报文可能会由业务板SPU2处理。一句话就是请求报文与回应报文有可能被分配到防火墙的不同业务板处理。那么可能会产生一个问题：由于请求报文基于业务板SPU1建立了会话，而回应报文查不到反向会话被丢弃。实际上，USG9000在建立业务板的会话表时，同时会进行hash预测，准确预测回应报文会被哪块业务板处理，在该业务板上同步建立起一条反向会话，保证回应报文能够被正确转发。当然，正反向会话间会定时同步，保证同步老化、统计报文信息等等。

配置实例：与防火墙报文处理流程相关的配置技巧

下面我们以实例来说明，熟悉防火墙报文处理流程，不需要再死记配置限制，而是根据逻辑直接判断如何正确配置。
例1，当安全策略遇上NAT Server。
在eNSP模拟器上，PC1（1.1.1.2）----防火墙USG5500----FTP服务器（192.168.1.2）简单组网，在防火墙上配置NAT Server，将FTP服务器地址转化为与PC同一网段的地址，配置如下：

[USG5500] nat server 0 global 1.1.1.5 inside 192.168.1.2

若希望PC1及其他多个PC能且只能访问该FTP服务器，应该如何配置严格的安全策略？实际是基于固定的目的地址配置安全策略问题。

分析：根据防火墙报文处理流程，先进行NAT Server转换、查询Server-Map表，再进行安全策略处理。那么，该固定的目的地址，应配置为该FTP服务器的真实地址（即inside地址）。

[USG5500] dis cu | include policy

policy interzone trust untrust inbound

policy 0

policy destination 192.168.1.2 0.0.0.0

验证如下：
1）关闭防火墙所有域间缺省包过滤，只保留上述在trust与untrust域间配置的该条安全策略。
2）在PC上访问FTP服务器，可以成功看到FTP服务器的文件列表。

3）查看防火墙USG5500会话表，可以看到FTP服务器已经做了NAT Server，且FTP控制通道与数据通道均已建立。

结论：根据防火墙报文处理流程，先查询Server-Map表，根据查询的记录结果再进行安全策略处理。当需求为允许多个外网客户端访问经过NAT Server转换的服务器时，安全策略配置允许到达的目的地址为该服务器的内网真实地址，而非NAT Server的global地址。

例2，当源NAT遇上NAT Server。
某公司分部与总部互联组网和关键配置如下，其中HTTP Server无法访问分部资源，而其他通信完全正常。

分析：防火墙上涉及HTTP Server的配置如下：
① NAT Server，将HTTP Server的私网192.168.1.2：80映射成为1.1.1.1：9980
②源NAT，策略定义192.168.1.0网段去往分部不进行源NAT转换
查看防火墙的Server-map表：

NAT Server转换成功，生成正反向Server-map表。且按照反向Server-map表含义，当该HTTP Server主动访问网络时，亦进行NAT Server转换。根据防火墙报文处理流程，优先查询正反向Server-map表，命中反向Server-map表后，源NAT不再生效。这个问题的解决办法是，配置NAT Server时增加no-reverse参数，要求不生成反向Server-map表，这样总可以继续查询NAT策略，使该HTTP Server可以正常访问分部资源。
结论：上述报文处理流程第3阶段时已进行提醒，进行源NAT处理时，注意报文在前面流程中是否命中了Server-map表，尤其不要忽略反向Server-map表，如果已经命中，此时源NAT处理不会再生效。

防火墙配置类问题与报文处理流程相关的，可能还有很多，本文难以穷尽，只捡两个实际常用NAT功能的例子抛砖，供小伙伴参考。本文笔墨颇多，逻辑难免有不严谨之处，请小伙伴琢磨指证。

强叔研习金庸多年，可只见一个扫地神僧往来无古今，亦只闻一曲笑傲江湖流传千百年。世上没有什么捷径，掌握防火墙的转发精髓仍需在处理问题实践锻炼中不断琢磨，在参考材料字里行间中不断思考，本文仅提供神功练成的入门之法，强叔与小伙伴们一同继续修行吧。

阅读全文>>

标签: 防火墙报文处理流程华为防火墙状态监测华为

评论(0) 引用(0) 浏览(14289)

赛飞培训之飞镖游戏个人简单感悟小结

作者：易隐者发布于：2014-10-21 21:37 Tuesday 分类：个人观感

下午培训的飞镖游戏，事后根据个人感悟简单总结，想到哪写到哪，急就而成，不成体系，或有谬误，如有兄弟发现错误或共鸣之处，欢迎讨论，互通有无，共同提高！

1，分工需明确，权责需具体，落实清晰，执行到位

我组分工明确之后，权责清晰，在具体执行过程中也表现不错，CEO能够充分信任并听取大家的建议，并做出及时的决策；我作为CTO及时在技术层面做了前期的观察和记录，为后续策略决策提供了基础；CFO在财务信息和风险控制这块也做出及时的提醒，其他人员也在各种时刻提出自己的分析和见解…….总体表现较优。

2，技术能力很重要，但技术有优势并不一定能赢，因为还有很多其他方面的问题会影响最终的结果。

3，了解自己，了解对手，以此科学制定针对性的策略

内部自我评价，选出可能有相关技术能力的选手，确定大致的上场人员；在大家都互相不了解的情况下，通过各组上场训练人员的表现情况，大致了解对手的技术能力；通过大家的训练情况统计，大致明确不同距离的成功可能性和风险，为下一步策略实施提供决策依据。

4，策略需清晰、有针对性。

大家不能一股脑充满激情撸起袖子上场开干，在充满竞争的市场中走弯路是大概率事件（第二组技术优势最为明显，但是第一局竟然垫底，这不符合正常竞争策略，领先者保守，以确保领先优势是基本常识，但是显然他们没有一个人负责制定合理的应对策略，究其原因可能是一开始未观察训练的情况，对其他家的情况了解较少）。

5，环境总在变化，制定中长期的计划不需要细节，具体的都是根据环境变化再不断的调整。

6，成本控制与变化。

我组自始至终成本控制相对较优。一开始我们先做内部自我评价，选出可能有能力的选手，确定大致的上场人员，不需要投入较多的训练的费用。因此我组第一局训练花费投入最少（集中有限资源，只给内部自评出来的选手训练机会）；
第二局给第一局未上场的一些人训练机会，参照第一局上场人员的表现，决定第二轮的上场人员，达到在节约投入的情况下，选出可能的后备技术力量；第三局主要是在新技术引入方面，我们以6次的训练机会获得对新技术的基础了解和感知，以确定是否使用新技术。

7，财务信息影响策略决策，在盈利或亏损情况下的应对策略肯定是有差别的，财务信息是我们策略决策重要的参考。

8，新技术引入问题

新技术引入肯定存在风险和成本，风险是否可控？成本是否在可承担的范围？是否会产生明显的效果？这些问题都需要综合考虑，我组在此次游戏中的表现更有策略性，主要如下：花费少量的训练费用感知新技术的效果。在我组上场人员的感知下，两位明确不引入新技术，另一位对新技术感知良好，使用新技术，我们最终综合考虑了上场人员的建议，采用区别的策略，两名使用原先技术，对新技术感知良好的采用新技术，结果3位上场人员均正常发挥。

第一组则在使用新技术时，效果未达到预期。另外新技术仓促引入，想在短期内产生良好效果，其中不可控的因素更多，失败概率理应更高。

9，顾问问题

第三局可花费一笔费用向顾问取经，我们内部讨论，最终未实施，大致原因：顾问不可能比我们更了解当前的竞争情况，在短时间内在竞争策略方面，给不了我们有价值的信息；顾问可能会在新技术方面给与一些有价值的信息，但是这个新技术的差别我们自己能够大致分析，且新技术的仓促使用有风险；我们的成败与顾问一点关系都没有，亏损倒闭他照常挣钱。

10，预期很美好，现实很操蛋。

现实大部分清楚下不是按照我们预期来发生的。（第一组他们策略预期发挥效应（这个概率相对小一点，因为距离远了）的情况下可以翻盘，但是正常情况却是大家发挥严重失常。）

11，运气也很重要

在各方面都不错的情况下，也未必能成功，运气也是成败过程中非常关键但随机的部分，这部分因素的掌控不在你我和竞争对手的手里，这就需要我们这些创业者要有一颗坚强的心，能够面对创业过程中的各种操蛋局面和最终可能不理想的结果。换句老生常谈的话来说，就是不必太在意最终的结果，还是享受这个过程吧

阅读全文>>

标签: 赛飞培训感悟创业

评论(0) 引用(0) 浏览(5615)

信息系统运维管理工作之我见

作者：易隐者发布于：2014-8-26 11:45 Tuesday 分类：IT 服务

前段时间，在某个场合遇到某专家的一个问题：你对信息系统运维的理解是什么？这是一个非常开放性的问题，当时现场时间紧、任务重，未来得及回答，这几天将我的理解大致总结如下：

1，信息系统的运维工作应围绕用户核心业务展开

用户的信息系统的构建主要目的不是为了单纯的互联网访问需求，而更多的是为用户的核心业务提供基础支撑服务，如财务系统、OA、CRM、ERP、电子商务、网游、工控系统等，如下图所示：

正是因为信息系统与业务系统逐步趋于融合的特性，决定了信息系统运维管理工作的终极目标是保障用户的核心业务系统能够稳定、高效、安全的运行。
基于这个目标，我们在运维管理信息系统的时候，绝大部分的工作需要围绕核心业务来展开。跟核心业务关联的信息系统组成元素（任何元素出现异常都会导致业务系统出现异常）是我们需要重点关注的对象，跟核心业务无关的信息系统组成元素则因其无关业务大局，在运维资源、运维人员时间精力等限制的条件下，大可等而次之。

2，利用工具的目的是“简化工作，提高效率”而非其反面

使用运维管理工具的出发点是“简化运维管理工作，提高运维管理效率”，基于这个出发点，运维管理工具应站在大部分运维管理者的角度，以简单、直观、明了的方式展现出用户最为关心的部分——与核心业务系统相关联的信息系统“健康”状态，所谓业务系统的健康状态主要包括“可用性、稳定性、安全性”等三大方面，简单阐述如下：

     可用性——业务系统连接正常吗？可正常访问吗？常规应用操作正常吗？
     稳定性——业务系统是否稳定？是否存在缓慢、丢包等现象？是否时通时断？
     安全性——是否存在被入侵的痕迹？系统或业务重要文件是否被篡改？

运维管理工具不应单纯追求功能上的大而全、细而精，若如此则必然导致运维管理工具偏离其“简化工作，提高效率”的出发点，如当今绝大部分的运维、SOC产品最终变成了仅适用于少数具有大量专业技术人员的行业单位（如电信、银行等），而让绝大部分其他行业的信息系统运维管理者望而却步——产品本身的专业性和复杂性就已经成为了运维管理工作的门槛和障碍！
每个人都喜欢简单，简单让我们更有效率，如果能够使用点点鼠标就可以解决的问题，我们就不会通过敲一长串命令去解决，不是吗？

好的运维管理工具应该具备以下几点基本要求：
 1、实时、自动、不间断监测业务关联的信息系统组成元素的运行数据
 2、围绕核心业务的运行健康情况做简单、直观的关联展示，不是多个信息系统组成元素的单个松散的展示
 3、能够及时主动发现异常并做出预警
 4、为常见异常预警问题智能提供解决思路，协助用户解决常见异常问题
 5、与专业服务团队关联，实现产品自动关联主动应急响应服务
 6、大胆摒弃大而无当、给运维效率带来反作用的功能
如何实现它？很简单，把大部分的运维管理者当成不具有专业知识的普通用户即可。可惜目前市面上所有的运维、网管、SOC产品类均因偏离了使用工具的初衷而不具备以上特点。

3，运维工作远非单纯工具可解决，离不开专业支撑团队

工具目的在于简化运维工作，提高运维效率，即使工具平台做的“更智能、更简单”，但由于信息系统本身的复杂性和不同用户环境的差异，总有一些疑难问题需要借助精专的技术服务团队，在用户现场帮助用户解决。
专业技术服务团队的以下基本要求：
 1、全面的信息技术领域覆盖，不可存在技术短板
 2、具有专业的技术水准，这是解决疑难问题的基础
 3、站在用户立场设计解决方案，客观公正，不推销产品
 4、服务本地化，保障及时应急响应
 5、服务与工具自动关联，实现主动应急响应
 6、依赖“技术团队”而非个人，个人不具备全面的专业技术素养

4，运维工作应形成体系而非单纯产品和服务的结合

运维体系涉及到的对象应包括业务、用户、服务团队等，运维体系的构建应包括以下几个基本内容：

    模式：服务经费来源保障，具体合作方式、服务级别要求等
    人员权责：用户方、服务方具体人员的分工和权责
    管理制度：考核、相关管理制度
    接口：用户与服务团队的对接方式等等
    流程：巡检流程、应急处置流程、故障处理流程等主要事件的处理流程

运维体系因需而设，因用户而异，但需“简单、实用、可操作”。

5，运维是长期的、持续的、动态的、不断完善的过程，而非一劳永逸的

用户的业务在不断的变化、用户信息系统的组成元素在不断变化、各种信息系统的突发事件、系统的优化完善升级改进等实际情况，决定了运维管理工作是一个长期、持续、动态、完善的过程，无法做到一劳永逸。

6，因信息技术专业性以及运维资源的限制，信息系统的运维管理工作全面外包是大势所趋

将越来越精专、分工越来越细化的信息系统运维管理工作交给专业的服务团队，对用户而言，花少量的资金就可以很好解决复杂专业的问题。将用户解放出来，用户有更多的时间和精力专注于自己的核心业务及管理工作，这对用户及服务团队来说是双赢的局面。

从这些层面来说，信息系统的运维管理工作全面外包是大势所趋。

以上为我个人关于信息系统运维管理工作的一己之见，欢迎讨论。

阅读全文>>

标签: 运维管理运维服务外包信息系统运维运维服务外包

评论(0) 引用(0) 浏览(9351)