前两天有个自己买服务器建站的朋友遇到了麻烦，找我帮忙处理些问题。在整个过程中我感觉有些实用的价值，于是发出来和广大服务器管理员朋友们一起讨论讨论,也希望各位朋友将自己遇到的问题发表出来，一起讨论。

该朋友的服务器脚本系统是自己写的，又有电子商务的支付平台，所以在针对安全方面，他花了些力气，做了一些防护，大体是这样的：
脚本攻击寻常的手段有三个：
第一是利用注入，找到管理员密码，然后登陆后台，再通过修改上传格式的方式，获得webshell，进而考虑提权，获得服务器控制权限。
第二是通过下载数据之类的办法，找管理员帐户，再登陆、修改、上传、提权。
第三是直接找上传漏洞，跳过注入、后台获取这一步，直接拿到webshell。

针对这三个方面，朋友的应对策略是这样的：
针对第一种攻击：卡死注入！方法当然大同小异：代码审核、防注入系统。这是常见手法。
针对第二种攻击：使用SQL数据库，不在web目录，当然下载数据库是没有办法的。也是常见手法。
针对第三种攻击：严格审计上传。网站设置成可以上传，但是上传文件类型有限制，IIS解析也只解析正常文件类型，最后再给上传目录做一个不能让脚本运行的权限，简单搞定。也不希奇。

或许很多服务器管理员会说：这些我们都做了，但是不排除出现特殊情况，比如脚本系统的注入0day，当遇到这样的情况的时候，以上三点防护可能就没有用了，这时候我们该如何应对？——正好，这个朋友就遇到了这样的问题。不知道为什么，他的系统在防护后，还是被注入了。搞他站的人，也不做破坏，更不动他的支付平台，就时不时的登陆一下他的管理后台，写上一句“某某到此一游……”，人都能气死。
遇到这个情况以后，朋友修改了自己的系统，除了做更加严格的防御外没有别的办法，所以才找上我。

知道这个事后，我也没认真问情况，随手丢了一套IP判断的脚本给他。这套脚本的功能主要是用来判断来访IP，同时对提前定义的信任IP进行比对审核，如果来访IP是信任IP，则正常打开，如果不是则跳转到其他页面。
程序大体是这样的：
number.inc文件内容：
<!--#include file="ip.inc"-->
<%
        sip1=split(ip1,".")
        num1=cint(sip1(0))*256*256*256+cint(sip1(1))*256*256+cint(sip1(2))*256+cint(sip1(3))-1
        sip2=split(ip2,".")
        num2=cint(sip2(0))*256*256*256+cint(sip2(1))*256*256+cint(sip2(2))*256+cint(sip2(3))-1
        sip3=split(ip3,".")
        num3=cint(sip3(0))*256*256*256+cint(sip3(1))*256*256+cint(sip3(2))*256+cint(sip3(3))-1
        sip4=split(ip4,".")
        num4=cint(sip4(0))*256*256*256+cint(sip4(1))*256*256+cint(sip4(2))*256+cint(sip4(3))-1
        sip5=split(ip5,".")
        num5=cint(sip5(0))*256*256*256+cint(sip5(1))*256*256+cint(sip5(2))*256+cint(sip5(3))-1
        sip6=split(ip6,".")
        num6=cint(sip6(0))*256*256*256+cint(sip6(1))*256*256+cint(sip6(2))*256+cint(sip6(3))-1
        sip7=split(ip7,".")
        num7=cint(sip7(0))*256*256*256+cint(sip7(1))*256*256+cint(sip7(2))*256+cint(sip7(3))-1
        sip8=split(ip8,".")
        num8=cint(sip8(0))*256*256*256+cint(sip8(1))*256*256+cint(sip8(2))*256+cint(sip8(3))-1
%>
banip.inc文件内容：
<!--#include file="number.inc"-->
<%
        ip=request.servervariables("remote_addr")
        sip=split(ip,".")
        num=cint(sip(0))*256*256*256+cint(sip(1))*256*256+cint(sip(2))*256+cint(sip(3))-1
        if  ((num=num1) or (num=num2) or (num=num3) or (num=num4) or (num=num5) or (num=num6) or (num=num7) or (num=num8) or (num=num9)) then
        else
        response.redirect "http://www.rongsen.com.cn/"
        end if
%>
ip.inc文件内容：
<%
ip1="*.*.*.*"
ip2="*.*.*.*"
ip3="*.*.*.*"
ip4="*.*.*.*"
ip5="*.*.*.*"
ip6="*.*.*.*"
ip7="*.*.*.*"
ip8="*.*.*.*"
ip9="*.*.*.*"
ip10="*.*.*.*"
%>
其中IP.inc文件中可定义信任IP，定义好了，再在需要IP审核的页面，调用此系统就可以。效果是如果不是信任IP，则跳转到我们提前定义的页面。

安稳了几天，这个朋友又来找我，说再次被搞了，而且通过日志和相关痕迹，很确定依然是通过后台进来，又写上了“某某到此一游……”。听到这个我倒是很开心，毕竟这套系统不是那么好突破的，突破了就说明挺强——根据以前测试的结果，这套系统除了通过修改数据包，进行IP欺骗以外，没有别的办法可以突破。
模拟一下入侵的过程：
入侵者利用原来的系统里的记录，找到至少一个信任IP（数据库、日志等地方都可能泄露admin的ip），然后打开后台管理页面，用数据包修改工具，直接修改数据包头，让服务器的脚本判断失误，认为入侵者来自信任IP，从而正常登陆后台，潇洒的留言后走人……
挺好，这个入侵者很有意思，技术也不错，至少资料收集、注入、抓包、上传是没得说。
我来了兴趣，连上了朋友服务器，用bak的脚本文件恢复成干净状态，然后取消了IP判断系统，用了一下IIS设置——其实有一个方式是大家忽略的，很简单，却很实用，那就是IIS的访问控制策略。
我们可以设置后台只允许某一个、几个IP访问，非授权IP是没有使用后台的权限的，这样不管怎么注入，不管拿到了多么高级的后台帐户和密码，注入都将一无用处！而这个方法，是IIS层面上的，不是脚本上的，安全性要高得多。
抓几个简单的图，IIS的访问控制列表设置在这里：
 
 
 
相信这几步大家肯定都能看明白，只是平时有可能忽略了而已。设置上这个以后，该服务器直到现在都是安稳的，看来起了一点点效果。

好了，整体过程就是这样，抛出的砖头是：第一次我用的IP判断脚本系统，有没有其他办法可以突破？第二次我用的IIS的IP判断系统，能不能突破？怎么突破？