从我记事那时开始起，杭州每年冬天都很少下雪。即便是下雪，也是下那么小一会会，意思一下罢了。记得香港回归到澳门回归之间那几年当中，有一年冬天的雪比较大，积雪比较厚，其他时候都见不到积雪。我一直以为这与全球气候变暖有关，而且我一直坚信杭州未来冬天都很少能见到雪景，并且做好了这辈子都不看雪景的准备。没想到今年冬天的第一场雪来的特别早、特别大方。看到几个朋友都对杭州 2008 年的第一场雪进行了相关报道，若您有兴趣的话可以查看这里、这里、这里、这里与这里。

今天下午醒来的时候，被电话告知 2008 年度杭州的第二场雪已经下了一天了。这场雪与第一场雪相比，少了往日的那份温柔和含蓄，多了一份激情与暴力。大片大片的雪花已经将路面完全覆盖，交通情况变得非常糟糕，连外卖都暂停了。

晚上到公司的时候看到公司门口有一位先生与两位小姐正在用地上的雪堆着一个雪人。走近一看堆的雪人是一个流氓兔的造型，不免感叹一番。而这个流氓兔造型的作者正是我们公司两位美术设计师 MM 和我们的商务总监。经过他们三位历时 3.5 小时的努力，作品完成。请看最终效果：

来个特写：

马路上经过一天的积雪，已经变成这样了：

公司门口的人行道：

某人的坐骑 Buick Lacrosse 也变成这样了：

总的来说，这场雪很暴力，给本来就繁忙的春运带去了深深的影响。内陆一些地区甚至出现了罕见的暴雪，交通中断的地方也很多。晚上打一个长途电话的时候发现移动电话的通话质量也受到了影响，看来中移动这次叫苦也是情有可原。如果这雪继续这样下下去的话，很有可能变成一场准自然灾害。淘宝上甚至出现了“停雪”的呼喊。我个人对下雪也不是非常有好感，还是早点停了吧。

愿上帝知悉，阿门。

今天看到 US-Cert 上面的一篇近期更新的文章，说的是跨站攻击。

如果一台 Web Server 支持 Trace 和 / 或 Track 方式，那么它一定存在跨站脚本漏洞，将有可能受到跨站攻击。 Trace 和 Track 是用来调试 Web 服务器连接的 HTTP 方式。

我们通常在描述各种浏览器缺陷的时候，把“Cross-Site-Tracing”（跨站攻击）简称为 XST。

攻击者可以利用此漏洞欺骗合法用户并得到他们的私人信息。

解决方案：禁用 Trace 和 / 或 Track 方式。

针对 Apache，可以借助 mod_rewrite 模块来禁止 HTTP Trace 请求。只要在各虚拟主机的配置文件里添加如下语句：

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F] 补充其他 Web Server 的解决方案：

1、Microsoft IIS

使用 URLScan 工具禁用 HTTP Trace 请求，或者只开放满足站点需求和策略的方式。

2、Sun ONE Web Server releases 6.0 SP2 或者更高的版本：

在 obj.conf 文件的默认 object section 里添加下面的语句：

<Client method="TRACE">
AuthTrans fn="set-variable"
remove-headers="transfer-encoding"
set-headers="content-length: -1"
error="501"
</Client> 3、Sun ONE Web Server releases 6.0 SP2 或者更低的版本：

编译如下地址的 NSAPI 插件：
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F50603

更多信息可以查看以下资料：
http://www.whitehatsec.com/press_releases/WH-PR-20030120.pdf
http://archives.neohapsis.com/archives/vulnwatch/2003-q1/0035.html
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F50603
http://www.kb.cert.org/vuls/id/867593

最近一阵子，我又进入了去年五六月份看 Windows 内核时候的状态。CPU 资源都被后台运算占据了，所以总是半梦半醒，晕晕乎乎。吃饭也变得没有出息，连续两周以丸子汤度日——这个做起来快，吃起来快，消化起来也快，可以省不少时间。好在味道还行，否则也坚持不了两周。这里介绍给大家，仅供参考。

买一棵大白菜，放在家里，每顿吃三片叶子。记住，大白菜遇水就烂，所以一定不能沾水。

买一斤鱼丸，好赖无所谓。都到吃这东西的份上了，也没什么讲究了。

买些质量好点的粉条，一定要久煮不烂的。因为我处于晕乎状态，经常不记得已经煮了多长时间。

掰三片白菜叶，把菜帮子切成丝，菜叶用手撕撕就成了。然后放几个鱼丸，一把粉条，再随便加点别的东西，譬如说辣白菜，香菇什么的。然后一起放到锅里煮。大概十分钟就可以吃了。

下面这个不是丸子汤。有一天淋了雨，为了驱寒，用白萝卜、猪肉、生姜、辣椒粉、胡椒，炖的超级宽粉——差不多有裤腰带那么宽。

- 阅读剩余部分 -

前几天给因为 N 年没有重装系统，也没有对她进行优化，更没有对她关心有加、呵护备至，从而导致系统缓慢不堪、慢如蜗牛的笔记本重装了系统。操作系统是 Windows 2003 Stardard Edition SP2。又因为时近年底，工作繁忙、杂务众多，一直没来得及给她安装常用软件。

昨晚回家后临时需要用到网付，于是安装了工商银行的 U 盾驱动程序。我的 U 盾对应的程序是“华虹客户端管理工具”。安装完毕，在网上支付过程中发现 Windows 的窗口焦点经常自动变化，并具有一定规律。截图如下：

当前窗口失去焦点的时候：

当前窗口获得焦点的时候：

虽说有一种不详的预感，但 NOD32 毕竟没有什么反应。我回顾了一下从系统安装后到现在所执行的操作，然后将工商银行的 U 盾驱动列为重点排查对象。

安装完工商银行的 U 盾驱动后，系统进程会增加两个：BHDCRegC.exe 和 hhukcert.exe。我对前者有点印象，记得未重装系统前进程里也常驻着它。于是我到资源管理器里找到了后者：

- 阅读剩余部分 -

一直以来，我以为 ARP 欺骗仅仅只会发生在公司单位、网吧等局域网环境比较复杂的地方。也曾耳闻到某些 IDC 机房也出过这样的事情，但总觉得这事情应该离我很遥远。没想到昨天晚上，一个地级市的电信机房也发生了这样的事情。我有幸亲临了整个事件的始终，中途除了机房的技术人员，还有二位仁兄被迫中止睡眠，起身与我一共奋战。一位是 feelinglucky 同学，另一位是我公司的小刘同学，在此向你们二位表示深切的慰问与诚挚的感谢。

昨天晚上 12 点 30 分（也就是今天零点三十分）左右，我打算进入博客后台取点资料，在登录页面上发现了惊奇的一幕：

刷新了一次之后还是这样，突然有一种不详的预感。然后，事实证明这种预感是准确的。我查看页面源代码，发现了更惊奇的一幕：

很明显，页面被挂马了。但又觉得这代码有点不对劲，于是冒着风险用 IE 访问了一下：

现在，发生了什么事情已经非常确定了。从最后一张图上看，应该是 ARP 欺骗挂马的结果；但也有可能是我的博客程序或者是服务器被挂马了。我一边打机房电话，告诉值班人员发生的事情；一边用 FTP 把博客所在目录的文件拖了下来。经过对博客程序的模板、程序代码的检查，发现并没有隐藏框架的代码存在。

下一步，检查服务器日志。把服务器上的 Apache 日志看了又看，没发现异常。根据 lucky 的建议，kill 掉了一些进程，问题依旧。lucky 又建议我测试一下本机访问本机会怎么样，于是：

#vi /etc/apache/httpd.conf 增加：

Listen 127.0.0.1:80 然后：

#/etc/rc.httpd restart
#vi /etc/hosts 增加：

127.0.0.1    www.xuchao.org 然后：

#cd /root
#wget https://www.xuchao.org/xxx/
#cat index.htm 在这里，我并没有发现有隐藏框架的代码存在。于是我更加坚定了刚才的判断，马上再次致电机房，告诉对方我刚才的测试过程，并指出问题极有可能出在机房里。值班的技术人员迷迷糊糊的从美梦中醒来，然后答应帮我检查。由于已经是后半夜了，他说最迟到上午 8 点就可以搞定。

等待、等待……在漫长的等待过程中，我重新查阅了一些几年没看的有关 ARP 欺骗的资料。唉，早知道就做双向绑定了。失误啊、失误。又看了一下 dmesg 日志：

#cat /var/log/dmesg.today 呵呵，全都是这样的内容：

arp: 122.225.96.1 moved from 00:19:b9:f1:14:1c to 00:11:bb:3e:62:3f on em0
arp: 122.225.96.1 moved from 00:11:bb:3e:62:3f to 00:19:b9:f1:14:1c on em0
arp: 122.225.96.1 moved from 00:19:b9:f1:14:1c to 00:11:bb:3e:62:3f on em0
arp: 122.225.96.1 moved from 00:11:bb:3e:62:3f to 00:19:b9:f1:14:1c on em0 从我一直 ping 服务器的情况看，机房的人重启了 3 次交换机，然后那段该死的隐藏框架代码已经不存在了。几分钟后机房给我打来电话，说问题已经解决。我问他原因，他说我的服务器所在机柜有一台服务器中毒，广播 ARP 欺骗包数据，没有防御能力的机器都倒下了。

由于连续 3 次断网，我们的服务器上服务端已经与数据库失去连接了（又是没有走内网通讯的恶果）。重启服务器，开启游戏服务端。早上 6 点，一切恢复正常。

明天整理一下思路，给出一份防御 ARP 欺骗的方案（针对 FreeBSD 服务器与 Windows 服务器）。