以前写过一个关于Take-Grant模型的小短文，大概描述的是关于信任关系的传递造成的安全隐患。今天看到了某个安全防护措施相对很完善的网络（堆满了FW，各种各样的ACL，全网流量传输加密）里面由于系统管理员和网络管理员的疏忽造成信任关系非预期的传递了，当然造成的进一步的影响就是越权访问、信息泄露等等。
当然，发现这个问题对于这个网络来说是好事，而且只是一个公司的网络，遇到些漏洞也不会危害到国计民生，所以写出来感慨一下。 这个公司的系统管理员和网络管理员技术非常的好，也很称职，只是对于一个应用了无数策略和设备的小网络来说，管理的难度反而因为这些策略增大了，稍不留神就会出现问题。安全就是这样，不论使用多强的加密策略，使用多好的密钥管理手段，多硬的管理规定，只要有一点出现问题，整个安全系统就全都崩溃失效了。
BTW，所谓的信任关系传递是m$提供的某个标准的常用无害服务造成的。
怀疑是供电不稳定的原因,机器的主板供电部分烧毁了.这台PC我已经使用很多年了，中间做过几次小的升级，作一般的工作都没什么问题。
周五的时候找村里的朋友帮忙检查，当得到主板烧毁的结论之后以为只能更换全新的机器了。今天早上又去了趟村里，没想到村里的朋友找到了一个能做主板修理的摊位，替换了几个器件之后竟然可以用了。万幸。
今天PP离开工作了快1年的106了。回想起1年前我们还都为未来困惑和迷茫，1年后PP通过自己的努力抓住了机会获得了一份足以让我羡慕的很不错的新工作。
PP的新生活开始了，我还在自己的路上慢慢的走着，好在已经不像一年前那样迷茫了。
1年前，3月16日发的图片，今天再次使用，谨以此纪念Penguin Partner在106生活的1年。
衷心祝愿PP能在新的工作岗位上完全发挥出自己的能力，生活幸福快乐。
一年前的P&PP
今天帮同事去村里买无线路由器，顺便给自己也买了一个。我是比较喜欢Linksys品牌的，在linksys刚刚进入国内市场的时候我就买过它的无线产品。
WRH54G是linksys今年新出的一种家用无线路由器，以前我用过WRT54G。在网上搜索了一下WRT54G和WRH54G的区别，似乎大多都在做广告，也没看到什么实质的内容。
买回家把所有的功能试用了一下，感觉除了样子(颜色，大小，少了一个外置天线，把WAN连接的标示修改为Internet)的区别之外，还有下面几个区别：
个人感觉，WRH54G的确更适合家庭用户使用，我在使用和设置的时候没有遇到任何的麻烦，以前在WRT54G上用过的功能在新的路由器上都能做出正常设置，而且新设计的向导式界面要比以前的WRT54G更人性化，对于大多数用户来说肯定要好用很多。高级设置界面基本保持了WRT54G的功能。性能上没有感觉，至少满足我一台电脑+一个手机+偶尔一台笔记本同时使用的需要了。
R1#sh int fa0/0
FastEthernet0/0 is administratively down, line protocol is down
…<omitted>
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
…<omitted>
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int fa0/0
R1(config-if)#load
R1(config-if)#load-interval ?
<30-600> Load interval delay in seconds
R1(config-if)#load-interval 600
R1(config-if)#do sh int fa0/0
FastEthernet0/0 is administratively down, line protocol is down
…<omitted>
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
10 minute input rate 0 bits/sec, 0 packets/sec
10 minute output rate 0 bits/sec, 0 packets/sec
…<omitted>
非常怀疑网络设备同样受到CVE-2007-2242的影响。不知道为什么IPv6也要继续设计一个类似于IPv4的source route选项。Cisco支持IPv6的设备似乎目前也没有类似IPv4上的uRPF的功能，而且文档上也没有看到如何禁止这样的选项，有些不是很好的感觉，要乱套……
终于完成了SMARTnet的注册，这几天连续在Cisco TAC上开了几个case：第一个case是5-1假期期间某天半夜开的——某天睡觉前对设备做例行巡视的时候看到某个服务板卡可能出了问题；第二个case是今天下午接近17点的时候开的——怀疑某个板卡出现了文档上从来没有覆盖的错误。
第一个case由于没有影响到服务，所以我开了个最低的S4级别的case，大约1小时后，RTP TAC的工程师给了回复，希望能提供一些命令的运行结果给他。第二个case由于潜在影响了某些服务，级别被我设置成了S3， 很快EMEA TAC的工程师给了回复，并且马上提供了一些看似有用的指导。
这两个case建立的时间一个是5-1假期并且是半夜，另一个是非常接近下班的时间，但是服务仍然都是在我可以接受的时间内完成的。在半夜作出响应的工程师是在美国的，在他作出响应的时候我似乎已经睡着了，看到他的响应我第二天白天又做了相应的处理并且提供了进一步的信息给他；下午接近下班时作出响应的工程师是在欧洲工作的，看到他的回应，我至少可以踏实的去吃顿晚餐了。
很喜欢这种专业的服务，不论什么时间，不论发生了什么问题，随时都能接收到来自世界各地的支持。有这样的服务给人的感觉非常的踏实，以后不担心再会遇到什么稀奇古怪的问题了，随时开case接受技术支持。
昨天和一个兄弟讨论问题，说到了以太网帧头和IP包头的结构。在以太网帧头目的MAC是在相对靠前的位置的，而在IP包头中源IP是在相对靠前的位置。这兄弟不是很理解为什么会这样。
我给根据自己的理解给了个解释：在2层，交换机可以以cut-through方式工作，一旦检测到了目的MAC就可以把整个帧直接转发了，而不必检测后面的内容（尽管现在的交换机一般都是store-forward方式工作的，后面的内容其实现在也都检查，包括最后的FCS交验）；在3层，尽管转发时仍然关心目的，但是最终接收端关心的是请求服务的来源。
对于后者的解释我觉得可能并不是很好，确实没有仔细考虑过当时那些制定标准的人是基于什么样的思路来考虑的。其实掌握知识本身只是一部分，如果能了解一种思想/思路或许可能更重要。
今天和PP、Brina、8han一起把netlab最终架设好了。Netlab本身的功能还是很丰富的，需要慢慢挖掘才能了解更多。在出生的时刻我在机房里和PP一起为netlab忙碌着，天生干活的命啊，呵呵。
刚才忽然想尝试在某个启用了IPv6的机器上ping一下著名的KAME,结果发现通了，嘿嘿