windows2003服务器被ARP挂马事件的安全分析（3）

五、恢复网站
既然没有更多线索，就先恢复网站的正常服务吧。“站长X”说他已经用利用自己上传的webshell批量清除过挂马语句。那么，我只需要找到网站无法正常访问的原因并排除就可以了。在查看了IIS的设置与硬盘的NTFS权限设置后，找到了网站无法服务的原因。因为两个虚拟主机文件夹（web1/web2）是同处一个父文件夹(www)下，虽然两个网站文件夹的NTFS设置了相应的匿名访问帐号(web1:webguest1/web2:webguest2)的读取权限。但是父文件夹www却只有administrator和system两个帐户可以访问。将www的读取及运行权限开放给webguest1和webguest2两个匿名访问帐号。然后分别将web1和web2的权限重新分配一下。让webguest1和webguest2不能相互访问对方的虚拟主机目录。以限制webshell的访问能力。
经过处理，网站服务成功恢复。
防：对每个虚拟主机设定不同的匿名访问帐户，是隔离webshell的重要方法。但是要注意父路径的权限设置。保持可用性前提下的权限最小化，是权限设置的精髓。
攻：没什么好说的，利用漏洞提权呗，如果运气好，webshell的权限就会让你在几个站点间穿梭观赏，如果运气非常好，你不但可以浏览你想看的一切，可能还可以直接改写很多配置文件，比如serv_u的ini。如果你走了超级狗屎运，扔批处理或脚本丢管理员的启动组里也不是没可能。好了，醒醒！醒醒！该起床咯。
六、安全设置
由于短时间内无法知道具体是因为什么漏洞而被入侵，先做一些安全设置加强安全性。
1、将所有数据库文件移到www外，另外新建一个db文件夹。db允许webguest1和webguest2读取。查看网站内的conn.asp文件。将数据库文件移动到db文件夹下。针对每个数据库文件设置相应的NTFS权限。修改相应的conn.asp文件，使用绝对路径连接数据库。将后台管理文件夹改名。
2、由于数据库文件已经不在web1或者web2中。所以直接将这两个网站文件夹的NTFS写入权限完全剥去。杜绝了因为脚本漏洞而生成webshell的可能性。
3、将serv-u FTP的启动帐号降权，从system降到一个身处guests组的帐号。只需要将这个帐号拥有serv-u配置文件的写权限就可以了，如果你无需图形界面管理，那么只给它一个读权限也是一个好选择。
4、删除所有没用的ISAPI映射。只留下.asp。
防：数据库移到网站文件夹外，只能阻挡暴库者的直接下载。修改后台管理的路径，减少被攻击的几率。尽可能的降低网站访问匿名帐号的权限，能不给写就不给写。如果实在有需要上传的路径，比如上传图片的目录，则一定要拿掉该目录的执行许可。任何服务的启动帐号，也是权限越小越好。只要设置得当，guests 组是它们的最好归宿。应用程序映射也别舍不得删，用不到的坚决删掉，不留给漏洞利用者任何机会。
攻：下载数据库分析表结构，数据内容，运气好还可能得到帐号口令。serv-u提权、利用ISAPI扩展的远程溢出获取shell都是老生常谈了。
七、峰回路转
正当我做完这一切，准备休息时，随手浏览了一下“站长X”的网站，居然发现又被挂马了！从服务器端查看页面源码却没有木马语句的踪迹。第一个反应是被挂了IIS马。但是立即否定了这个推断。因为IIS挂马不会时有时无。那可是连404错误页面都会被挂上木马代码的。所以我判定应该是被arp挂马。
运行 ipconfig -all 找到服务器的网关地址：61.175.179.161。运行arp -a 发现果然有另一台机器 61.175.179.168 的MAC地址与之相同。很明显，是61.175.179.168在对服务器进行ARP欺骗，服务器的所有跨网段通讯都流经了61.175.179.168进行中转。而61.175.179.168可以在http协议的通讯过程中进行挂马操作。这就是挂马语句时有时无的原因。
首先通知了“站长X”，让他与ISP交涉，至于61.175.179.168是被恶意攻击植毒，还是所有者本身即为幕后黑手，都很难说。但是我们不能一直这样等着，趁着一次arp攻击波的过去，立即刷新得到真实的网关MAC：00-0f-e2-8d-11-85。使用arp -s 61.175.179.161 00-0f-e2-8d-11-85 命令进行静态绑定，阻挡住了来自外界的ARP欺骗。但是当系统重启后这个绑定命令就会失效。为了永久性的解决问题。我在服务器上运行了我写的小工具：BLX ARP防火墙。它的优点是每次重启后自动进行静态绑定网关MAC的操作后退出程序释放内存。
既然确定了是ARP攻击，那么就要提防很多敏感信息已经被嗅探的危险。通知“站长X”修改掉后台口令等信息。考虑到一些嗅探软件专门瞄准password等敏感数据。我修改了登陆页面中提交的postid。这样可以让一些嗅探软件瞎掉。
防：如果在被挂马以后，发现在源代码中找不到挂马痕迹，就需要考虑IIS挂马和ARP挂马两种可能了。两者的区别就是ARP挂马是页面一会儿正常一会儿又被挂上木马代码。IIS挂马则是无论什么时候访问什么页面都会看到挂马语句在返回的页面中（包括IIS返回的错误提示页面）。IIS挂马可以在IIS的设置中找到痕迹，在“文档”设置页中，有个“启用文档页脚”的设定。若被莫名其妙的启用，你会发现挂马代码就在这个自定义的页脚文件中。你也可以在C:\windows\system32\inetsrv\MetaBase.xml中找到DefaultDocFooter项，（IIS的很多设置就保存在这个xml文件中），删除掉这个选项即可。ARP挂马则无需多做其他设置，消除掉被ARP欺骗的影响即可。修改登陆提交的postid，可以躲过一些针对关键词的嗅探工具。
攻：IIS挂马需要对C:\windows\system32\inetsrv\MetaBase.xml有写权限，加入DefaultDocFooter="FILE:C:\www\mm.htm"就可以启到挂马效果。而ARP欺骗攻击则用途多多，不但可以挂马，还可以sniff到很多有用的信息。但注意一些傻瓜型嗅探软件虽然功能很强大，但由于是基于关键词，所以也容易被蒙蔽。如果攻击的是重要目标，对截获的通信数据进行人工分析还是有必要的。
八：结论
运行过BLXARPFW后，网站已经变得正常，没有再被挂马所困扰。可见，其实这次挂马攻击就源自于被ARP欺骗。并非由于被入侵的结果。“站长X”以为是被入侵，在做权限设置时又宁可错杀一千，结果出了差错。才导致了网站的瘫痪。
最后回到那个被牵连查出来的asp木马 aaa.asp。将其删除后，丢一个假的aaa.asp用来记录来访者的信息。因为没有完整的IIS日志，无法得知这个aaa.asp的主人当初是用什么手段达到侵入的目的。是因为另一次的arp欺骗后的嗅探得到了后台管理员口令和管理路径？还是利用了其他的脚本漏洞？因为实在是懒得去分析那些乱七八糟的源码（本F的眼睛还没痊愈呢），看来目前只能是个未知的迷了。