这是一个充满危险的世界。 在这个世界上， 时时刻刻都有人走向死亡。 而你永远也不会知道， 下一刻死亡的人， 会不会就是你。
如果要你选出一个世界上最危险的地方， 你认为会是哪里？时时有飞机来撞大楼的美国？还是爆炸声声的印度孟买？或是恐怖行动天天上演的中东？亦或是无可逃避的百慕大死亡三角洲？
我得告诉你， 你错了， 完全错了。 世界上最危险的地方， 绝不是以上地方， 而是互联网！对就是互联网， 绝不会再有任何一个地方， 比互联网更不安全。
先不要说网页上漫天的病毒， 也不要说处处横行的木马， 对于普通网站访问用户的危害， 大家有目共睹。 今天我要说的， 不是普通用户所面临的危险， 而是网站提供商所面临的危险！
网站提供商， 在这里， 我们指的不是人， 而是指提供网络服务器的设备与机器， 简单的一点说， 我们就说它是服务器吧。 因此本文我要说的， 就是网站服务器所面临的不安全！
网站服务器所面临的不安全， 无外乎硬件的、软件的、人为的几种。 当然我在这里要说的， 自然是人为的那一种。
攻击、入侵、劫持等等， 这是最常见的手段， 也是目前互联网上最泛滥的恶行。 那么我们来看一下， 一台服务器， 会有多么的脆弱呢？
那一天晚上， 我的心情很郁闷。 为什么郁闷呢？有一个论坛很没有理由的封了我的ID。 那是一个人气很旺的财经论坛， 日发贴量一般都在3~4万以上。 据他们自己说alexa排名在1000多的样子， 我那天查了一下， 三个月的排名也就是在4000~6000的样子。 不过在财经论坛中， 也算是一个很理想的了。 那个网站的打开速度一直都很快。
那天我的心情确实不怎样， 忽然想测试一下这个论坛的负载能力如何。 我声明， 我从来都不是黑客， 也从没有学过任何黑客技术， 也从不去想黑哪一个网站。 我之所以有这个想法， 是因为与我的职业与爱好有关， 我只是想做一下压力测试而已。
我留意了一下那个网站用的WEB服务器， 用的是nginx+PHP+MYSQL， 有一个子域名用的是nginx 0.7.X（nginx 0.7.X还是测试版本， 看来对方的管理员是一个很激进的人）， 主论坛用的是nginx 0.6.X， 这更引起了我的兴趣。 在我的印象中， nginx代表的就是高速高并发处理能力。 据称nginx可以负载上万个并发连接。 我现在对使用nginx的服务器， 远比使用Apache和IIS的更有兴趣。
我接下来查看了一下该论坛的服务器布局， nslookup一看， 发现他用了三台服务器， 处于125.90.88网段中， 显然三台服务器处于同一机房的局域网内。 在这时， 我又有了一种猜想：这三台服务器中， 必定有一台是主服务器， 而两台是辅服务器。 论坛的程序， 必定是只在一台上面运行， 而其余两台， 只是proxy。
接下来我就开始行动了。 很多人都知道， Apache自带了一个工具， 名叫AB， AB是一种压力测试工具， 主要用于测试服务器的并发处理能力。 于是我在论坛上面找到了一个页面， 该论坛的搜索用的是奇虎的搜索， 无法利用， 而其它的搜索功能需要登录才能处理， 不方便利用。 所以我就找了一个主题列表页， 需要排序的， 而且页数是要偏后的（这所以这样选择：是因为这种页面需要的数据库资源会稍多一点）。 然后我就开始使用下面的命令了：ab -c 5000 -n 500000 http://www.XXX.com/XXXX。
同时开了两个上面的命令， 两次以后， 那台服务器没有当掉， 这在我的意料之中（nginx的并发处理能力， 我深有信心）。 但是那个论坛挂掉了， 这也在我的意料之中（因为ab测试造成并发请求的数量， 必定超过了mysql的最大连接数）。 接下来， 我试着用他的三个IP直接访问论坛， 发现访问三个IP的结果都是一样的：MYSQL超出最大连接， 也就是三台全处于基本挂的状态。 这也证实了我关于三台服务器中一台为主两台为辅的判断是正确的。
于是我当时停止了AB命令， 但是一个小时后， 那个论坛还没恢复过来， 一个小时后， 论坛重新可以访问， 但是速度极慢。
我说上面这次经历， 不是在说自己如何， 而是在说：在这个互联网上的服务器， 竟然是如此的脆弱， 这真是我以前没有想像到的。 一个普通的人， 根本没有经过黑客的培训， 也没有用任何黑客工具， 只是利用了一个小工具的功能， 竟然就可以攻击到一个不算小的论坛。 这应该怎么说呢？是管理员的失职吗？如果他只要加上connlimit防火墙模块， 我的这次攻击， 即使规模再大上几十倍， 只怕也是无法憾动吧？
而事实证明， 互联网的脆弱， 远不如此。 大约是因果报应， 环环不息。 前天晚上我的午夜惊魂， 更是证实了互联网的脆弱。
前天晚上突然被电话惊起， 马上意识到服务器出问题了。 于是访问一看， 发现所有的页面全打不开， 变成了文件下载的方式。
心头稍稍安定， 服务器没有挂。 将下载下来的网页文件一看， 全是乱码， 而非是普通的HTML源代码。 心中马上意识到是gzip的问题。 因为这个乱码的问题， 之前有朋友反应过， 但由于只是极偶然的情况， 所以不太放心上。
马上登录服务器， 用curl一看， 发现果然是gzip压缩的问题。 于是马上关了gzip， 重启nginx， 发现部分可以正常访问。 但是部分在后台使用了gzip功能的页面， 仍是下载的方式。 于是手工修改了后台配置文件， 终于恢复正常。
服务器恢复正常后， 开始寻找根源。 难道是gzip的配置不对？仔细上nginx的官方查看了gzip的配置说明， 没发现异常的地方。 发现的规律是：凡是使用gzip压缩的页面， 就必定会变成直接下载的方式， 而没有使用gzip压缩的页面， 就很正常。 我对gzip的配置尝试改动了很多次， 始终皆是如此。 难道并非是gzip的问题？
这时， 有朋友反映某个网页的功能不正常。 我检查了一下那个网页， 大惊失色， 那个不正常的网页中， 竟然在最开始处， 夹着类似如下一段代码:<iframe src="XXX" width="0" height="0">！
网页木马病毒？心中马上闪过如此一个念头。 于是上服务器检查该文件， 发现源文件是正常的， 根本没有包含这个iframe的代码。 再多试几次， 发现其它的页面， 凡是以php结尾的页面， 都是正常的！而只要是以htm,html,shtml一类结尾的页面， 在文件前全部加上了iframe代码！
心中一惊， 登录论坛后台， 寻找相关gzip的配置选项， 查看源代码， 竟然发现有些gzip的字符， 变成了gxip！
至此， 我终于明白了经过压缩的网页无法访问而是提示下载的原因了。 因为压缩后的网页用的是gzip格式， 在文件头中有包含gzip的代码， 而所有gzip字符全部变成了gxip。 gxip自然不是服务器能识别的文件格式， 自然会提示下载。
看来是遇上了HTTP劫持！(未完待续)
