安全的三个点，client/gateway/server，是各个安全厂商的战场。client上，防病毒比较多一点；gateway上，防火墙比较多一点；server上，主要是安全加固意义application firewall之类的东西。大家用的技术有相同的地方，也有不同的地方。各个战场上都有重量级的选手。当然也有新兴的公司。

各种技术也有融合的趋势，比如把防病毒放到gateway上，把包过滤（访问控制）放到client上。client相对比较复杂一点，因为windows操作系统比较复杂。Gateway就相对单纯一下。Server的种类也比较多，但是server端的过滤号称是与server无关的，不知道这个有没有意义。

像这个google受攻击的案例，NULL pointer都能被利用，这已经是非常高深和专门的技术了，非一般人能够理解和执行。

“正向就是搞建筑的，逆向就是搞爆破的”（引用）。正向要考虑如何建造一个系统，考虑硬件架构，软件架构，以及系统架构。使用什么操作系统，什么语言。考虑分层，面向对象，SOA，以及模式等等。而逆向就是要找漏洞，分析系统架构里面的错误，以及利用这些错误来做某些事。

正向和逆向是一个事情的两个方面，对两个方面都能了解或者掌握，不管是做正向还是逆向都有很大的帮助。不过目前还是从事正向工作的人多一点，从事逆向的人少一点。貌似从事逆向的人水平高一点，但这个也不一定。逆向的工作局限性很大，不一定懂得如何构建一个稳定，高效，可持续的系统。

有很多书和资料介绍正向如何做，但是很少有介绍逆向的。逆向的工作一般都散落在网上，需要收集，自己总结和摸索。也有一些会议，但是圈子太小，一般人都不知道。

正向是合法合理的工作，也是大部分公司的重点。逆向就差一点，逆向有可能违反法律，市场也小很多。

如果正向做好了，可以做架构师，逆向做好了哪？安全分析员？在这个圈子里面，哪个职位有更好的待遇哪？

有两个正在发展的方向：一个盒子集成越来越多的功能，在广度上扩展；一个盒子只完成单一的功能，在深度上扩展。

在广度上扩展，是大公司的做法。把公司内部的优势技术集成到一起，给用户一个集成的解决方案，解决用户从网络到安全再到访问控制，安全管理等等，一体化的产品。对用户来说，节省投资，节省管理成本，也节省使用成本。

在深度上扩展，是小公司的做法。把某个功能做得很强，很深，只关注某一个细分到市场。比如做web server保护等等。当越来越多的公司都是基于internet时，对内部这些server的保护就非常重要。这相当于在前面多加了一道门，使得入侵不那么容易。这个方向还在发展之中，应该有很多机会。

Application layer firewall与以前的firewall的主要区别是在对

深层内容的检查上。L2/L3/L4的firewall更多关心对网络层的控制，ip/port等。L7的firewall需要检查协议内容。有可能需要关心application layer的transaction。这里面有很多细分的功能，比如对Web server/DB server/Mail server/FTP server的防护。

其实问题都还是一样的：一是网络功能，比如l2/l3的转发，这是基础。虽然application layer firewall不会部署在edge上，不需要太复杂的网络功能，比如动态路由，QoS等，但是基本的connection rate/ throughput等还是需要的。

再一个就是协议解析。application protocol有很多，也很复杂，如果协议解析做不好，在这之上的检测就没办法做。

再者就是detection engine和规则库了，规则库需要积累。而且一个新的攻击出现后，如何快速写出新的规则，这个是很重要的能力。

Web Application Firewall Testing Procedure

“任何一支部队都有着它自己的传统。传统是什么？传统是一种性格、是一种气质！这种传统与性格，是由这种部队组建时首任军事首长的性格与气质决定的。他给这支部队注入了灵魂。从此不管岁月流失，人员更迭，这支部队灵魂永在。”

这是<<亮剑>>里面的一段话，我觉得也比较适合现在的Web2.0 SNS。每个web2.0站点，都有自己的读者群，有自己

的风格和特色。这些风格和特色，是在站长的潜移默化中形成的，比如tektalk的陈首席。

所以要建一个网站，首先要考虑自己的目标读者（如果是自娱自乐就不讨论了）。目标读者的背景和自己的背景应该类似（除非是多才多艺的通才，什么都懂）。然后由读者再连接新的读者。一个社区就形成了。

每个社区的性格刚开始可能不太注意，但是浏览的多了，就慢慢会发现。比如这次的Google事件，不同的社区，讨论和观点可能截然不同。左的，右的都有。tektalk应该属于中间偏左一点，或者偏右一点，这可能只有四位创始人才知道了。

3C指的是计算机（Computer)、通讯（Communication)和消费类电子产品（Consumer Electrics)。这三类电子产品

占据了家庭电子产品的大半，如何将这些产品融合到一起，设计出集成，高效，实用的新产品，是很多It厂商，家电厂商，

通讯厂商非常关注的一个问题。

从普通消费者的角度来看，在一个家庭的客厅里面，有电视机，DVD机，数字机顶盒，高清播放器，家庭影院等等。首先应该

集成的，是电视机，高清播放器和数字机顶盒。高清播放器需要支持wireless，或者是以太网口，支持大硬盘，鼠标键盘之类

的也需要。还要支持HDMI接口，支持多声道输出。如果能够支持遥控器操作更好。数字机顶盒也可以做这些功能，如果有

xDSL的接口最好。电视机最好支持录播功能，支持摄像头，能够使用SIP电话，或者其他可视电话。最好能支持视频点播，

付费可以，但不要广告。

如果有这么一台集成的机器，如何操作是个问题。是用遥控器哪，还是鼠标键盘，人机接口如何设计？如何访问广电网的资源，

internet的资源，还有通信网的资源。要做出这个机器，是It厂商有优势哪，还是家电厂商有优势？目前来看，通讯厂商在

家庭客厅里的位置还是少一点，家电厂商的优势大一点。

如果把PC做为家庭娱乐中心，操作系统是不是需要换一下哪？至少目前windows的操作习惯不适合家庭用户，比如家庭主妇，

小孩，老人。这是不是一个新的机会？

这么多的东西集成起来，至少能减少电源，网络等等线路，节省空间。价格有没有优势，维护成本有没有优势？是不是能够

完全替代传统的家电或者PC，电话等等。

这些问题，我想也是目前在tektalk讨论的融合的安全解决方案所要面临的问题是一样的，但是这个市场明显大很多。

sony的人写的，主要还是关于游戏编程方面的问题。

Pitfalls_of_Object_Oriented_Programming_GCAP_09

在endpoint上做安全和在gateway上做安全是两种截然不同的选择。这里的Endpoint是指通讯的两端，比如client和server都是endpoint，而gateway是指中间的转发设备。

在Endpoint上做安全，首先要面临的问题是操作系统的多样性和应用程序的多样性。比如在Web server上做一个Web application firewall的模块，就面临着许多不同的server: apache, IIS, websphere等等。每个server的编程模型可能都不相同，怎么把这个模块嵌进去，不同server要用不同的方法。当然，核心的过滤模块应该是一样的，不同的部分就是如何适配不同的server，意义如何使用server的协议解析库。

在Gateway上做相同的功能就简单许多。因为不管是什么server，在gateway上，看到的只是网络包。在gateway上，还原tcp链接，做协议解析等等，不会有os和application的烦恼。它的协议解析也可以是部分解析，而不用完整的协议解析模块。

在Endpoint的优点是程序升级方便，一个Endpoint升级不会影响其他Endpoint。如果是Gateway升级，就会影响所有穿过Gateway的流量。这也是为什么HA对Gateway来说很重要的原因。

Endpoint的数量大，大批量生产，可赚取的利润可能会更多。而Gateway虽然贵很多，但是毕竟数量少，利润有限。

这两种方式都有比较高的进入门槛，毕竟安全是一个需要积累的行业，并没有现成的知识库供参考。

http://en.wikipedia.org/wiki/Real-time_computing

Realtime system最关键的一个概念就是当事件发生时，系统必须在规定的时间内响应，并在规定的时间内完成这个任务。能够严格满足这个时间规定的，就是hard realtime（在规定的时间内不能完成，整个系统就失败了），如果能够容忍某些任务失败而系统继续运行的，就是soft realtime.

Realtime system通常与Embedded system联系在一起，通常它们就是一回事。普通的操作系统虽然也有分时调度，但是对时间的限制没有那么严格，如果某个事件没有响应，也不会造成大的损失。

网络设备，比如router/switch，一般都用的是realtime os，比如收一个网络包，如果在规定的时间内没有响应，这个包就会被丢掉，而系统对此可能一无所知。通常情况下，系统可以选择丢弃一下包，但是必须有记录。否则的话，这个系统就是不可信的。

在集成了多种服务的系统里面，如何保证实时性，是个难题。实时任务和非实时任务如何划分？引入的service是否会延长任务的执行时间而导致任务不能在规定的时间内完成。如果有多个这个的service，可能系统都无法收发包了。这样的系统部署到网络上，就很危险。

用Linux做网络设备，就会碰到这样的问题，在系统load重的时候，如何保证设备还是可管理的，如何保证某个traffic消耗了所有的资源，如何保证协议包能够正常的收发（比如网络协议包）。这些东西都是需要考虑的。如果在系统load重的时候，系统就无法正常使用，这样的系统，就无法称之为实时系统。

对于L7的service，是flow-based，还是stream-based，还是protocol-based？比如ALG和IDP，都对某个协议感兴趣，比如sip，那么这两个服务，就应该有共同的部分。如果是flow-based，传递给service的是packet，如果是stream-based，传递给service的就是byte stream，如果是protocol-based，传递给service就是protocol handler。那么，对service来说，是不是一个packet就足够了，显然不是，packet里面没有足够的协议信息，所以，首先要把packet组装起来。把协议的一行传递给service，假设一个line就足够了，但是对于protocol stack来说，一个line是否足够？协议里面的line与line之间有没有联系，如果有联系，是不是整个协议头都全了，再传给service(比如http是以两个回车来结束http header）。

可以想象的层次如下：

flow –> stream –> protocol –> service。当然可以把stream和protocol都合并到flow里面，不同的协议调用不同的协议解析。

从service角度来看，如果底层能够完整的协议语义都传递进来，在这之上的分析，过滤就会简单很多。service可以更关注自己的功能。

所以在ISR里面，首先是stream/protocol等基本功能的集成，如果能够向上提供一致的接口和服务，那么集成service就会方便很多。或者可以在这之上提供基于xmlrpc/soap等等SOA接口，如果throughput和latency能够满足要求的话。

service的性能是个问题，单从转发来看，速度可以做得很快，但是如果service的速度上不去，也是没法满足要求。毕竟http，sip等协议是交互式的，用户可以容忍的latency有限。如果是smtp或者是ftp，倒是可以缓存一下。对不同service，集成的方式还有所区别。