快下班的时候看了下mod_proxy_http的代码，这种漏洞完全不给力啊，以后不看了……

WPA2 uses two types of keys: 1) Pairwise Transient Key (PTK), which is unique to each client, for protecting unicast traffic; and 2) Group Temporal Key (GTK) to protect broadcast data sent to multiple clients in a network. PTKs can detect address spoofing and data forgery. "GTKs do not have this property," according to page 196 of the IEEE 802.11 standard.

These six words comprise the loophole, Ahmad says.

Because a client has the GTK protocol for receiving broadcast traffic, the user of that client device could exploit GTK to create its own broadcast packet. From there, clients will respond to the sending MAC address with their own private key information.

Ahmad says it took about 10 lines of code in open source MadWiFi driver software, freely available on the Internet, and an off-the-shelf client card for him to spoof the MAC address of the AP, pretending to be the gateway for sending out traffic. Clients who receive the message see the client as the gateway and "respond with PTKs", which are private and which the insider can decrypt, Ahmad explains.

http://www.networkworld.com/newsletters/wireless/2010/072610wireless1.html

现在我已经不太喜欢写博客了，尤其是和安全相关的东西。但是经常的也会有些东西憋着不舒服，今天稍微来几句，说一下一下甲方的安全产品，主要是定制化。

国内比较大的互联网公司，多多少少都会有一些自己的安全产品。之所以自己开发而不是直接采购，我想有很大的原因在于定制化。基于对公司业务的了解，对公司流程的熟悉，自己开发最终能够做出不是很通用但是却最适合自己公司的产品。同时，可以和运营方频繁的沟通，最终再易用性方面也得到较大的提升，这些都是坐在屋子里很难设计出来的。

不过另外一方面，我觉得定制化也是要有一个粒度的，过尤不及。最近在产品的设计、推广方面，就遇到一点类似的问题。产品设计的当初，是否好运营，易用性如何肯定是要考虑的。但是根据一个具体的“个人”的运营方式去决定产品的走向，我觉得是不可取的。因为产品做出来，不是给一个人去运营使用，而是给一个群体来运营，随时是可能够换人的，不可能根据某一个人的工作习惯来决定。站在运营者这个“群体”的角度，来考虑设计是最恰当的。

电脑可以定制，可以要求什么牌子的主板，多大的内存，什么牌子的网卡，但是你不能要求说要指定地点的硅矿石提炼出来的硅做的CPU。如果要照顾到每一个人的习惯，那么只能在功能、基础的易用性得到满足后，去提供一些API让特定的人可以根据自己的工作习惯来开发定制。

安全产品这一块，我想刺也许也有很多体会吧，我懒得再写下去了，也许可以建议他写一篇长的。我到想看看下次我再想扯点什么的时候，是不是可以说一下流程方面的事情。

我前些时候想写一篇关于安全在甲方乙方的文章，因为我有过这样两种经历，有很多亲身的体会。最近一直在考虑该怎么写才能说清楚我的想法，不过最终思考的结果是不写这个东西。

恰好5.1在家看到wzt写了一篇这样的文章，讨论的人很多。我有点心痒，就稍微说几句。简单的说，我的想法是安全研究不仅仅是研究溢出，研究内核，研究xss，研究各种新的攻击方式。研究如何让一个有1万台服务器部署了各种应用的网络安全，研究如何在拥有3万名员工的办公区域不泄漏敏感信息，这个也是技术研究，并没有完全束缚到业务里面。何况即使在乙方，也不会有天马行空的屠龙之术。

以《神鞭》的一句话结尾，辫子剪了，神留着，一变又是绝活。

这两天在准备一份数据报表，需要写几个脚本协助工作，但是追求完美的性格反而导致了一个错误。本来只是一个一次性的工作，在写脚本的时候却妄图去追求通用性，备以后使用，但是而且这个脚本以后基本上是用不上的，结果本来很简单的事情却做了接近3个小时。还好进行到一大半的时候翻然醒悟，快刀斩问题。

以前对DNS的解析过程还有些误解，最近做事情的时候仔细搞了一搞。简单的说，监控全局DNS劫持，还是直接监控根域服务器和授权域服务器能够最快得到结果。

dig baidu.com +trace

; <<>> DiG 9.5.1-P2.1 <<>> baidu.com +trace
;; global options:  printcmd
.                       349711  IN      NS      G.ROOT-SERVERS.NET.
.                       349711  IN      NS      H.ROOT-SERVERS.NET.
.                       349711  IN      NS      I.ROOT-SERVERS.NET.
.                       349711  IN      NS      J.ROOT-SERVERS.NET.
.                       349711  IN      NS      K.ROOT-SERVERS.NET.
.                       349711  IN      NS      L.ROOT-SERVERS.NET.
.                       349711  IN      NS      M.ROOT-SERVERS.NET.
.                       349711  IN      NS      A.ROOT-SERVERS.NET.
.                       349711  IN      NS      B.ROOT-SERVERS.NET.
.                       349711  IN      NS      C.ROOT-SERVERS.NET.
.                       349711  IN      NS      D.ROOT-SERVERS.NET.
.                       349711  IN      NS      E.ROOT-SERVERS.NET.
.                       349711  IN      NS      F.ROOT-SERVERS.NET.
;; Received 436 bytes from 208.87.241.170#53(208.87.241.170) in 0 ms

com.                    172800  IN      NS      D.GTLD-SERVERS.NET.
com.                    172800  IN      NS      H.GTLD-SERVERS.NET.
com.                    172800  IN      NS      L.GTLD-SERVERS.NET.
com.                    172800  IN      NS      C.GTLD-SERVERS.NET.
com.                    172800  IN      NS      G.GTLD-SERVERS.NET.
com.                    172800  IN      NS      J.GTLD-SERVERS.NET.
com.                    172800  IN      NS      B.GTLD-SERVERS.NET.
com.                    172800  IN      NS      E.GTLD-SERVERS.NET.
com.                    172800  IN      NS      F.GTLD-SERVERS.NET.
com.                    172800  IN      NS      K.GTLD-SERVERS.NET.
com.                    172800  IN      NS      A.GTLD-SERVERS.NET.
com.                    172800  IN      NS      I.GTLD-SERVERS.NET.
com.                    172800  IN      NS      M.GTLD-SERVERS.NET.
;; Received 499 bytes from 192.58.128.30#53(J.ROOT-SERVERS.NET) in 153 ms

baidu.com.              172800  IN      NS      dns.baidu.com.
baidu.com.              172800  IN      NS      ns2.baidu.com.
baidu.com.              172800  IN      NS      ns3.baidu.com.
baidu.com.              172800  IN      NS      ns4.baidu.com.
;; Received 163 bytes from 192.43.172.30#53(I.GTLD-SERVERS.NET) in 166 ms

baidu.com.              600     IN      A       220.181.6.81
baidu.com.              600     IN      A       220.181.6.184
baidu.com.              600     IN      A       61.135.163.94
baidu.com.              86411   IN      NS      ns2.baidu.com.
baidu.com.              86411   IN      NS      ns3.baidu.com.
baidu.com.              86411   IN      NS      ns4.baidu.com.
baidu.com.              86411   IN      NS      dns.baidu.com.
;; Received 211 bytes from 61.135.165.235#53(ns2.baidu.com) in 251 ms

http://intevydis.com/mysql_overflow1.py.txt