由服务器IP判断说起的攻防——站长安全顾问系列话题一-阿里云开发者社区

开发者社区> 数据库> 正文

由服务器IP判断说起的攻防——站长安全顾问系列话题一

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

来自黑客防线 

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

该朋友的服务器脚本系统是自己写的,又有电子商务的支付平台,所以在针对安全方面,他花了些力气,做了一些防护,大体是这样的:
脚本攻击寻常的手段有三个:
第一是利用注入,找到管理员密码,然后登陆后台,再通过修改上传格式的方式,获得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.hacker.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判断系统,能不能突破?怎么突破?

希望有思路或者经历过的朋友,都来参与讨论一下,引来几个玉,让我们也提升一把!=。=

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章