IIS&Apache 攻击记录分析篇

在这里,我为大家介绍一下两种常见的网页服务器中最重要的记录文件,分析服务器遭到攻击后,黑客在记录文件中会留下什么记录。目前最常见的网页服务器有两种:Apache和微软的Internet Information Server(简称IIS),这两种服务器都有一般版本和SSL认证版本。本文将使用和现实黑客的攻击手段类似的攻击方法去测试服务器并分析相关文件,有条件的朋友可在自己的机器上测试。
IIS的预设记录文件地址在C:\winnt\system32\logfiles\w3svc1目录下,文件名是当天的日期,如yymmdd.log,系统会每天产生新的记录文件。预设的格式是W3C延伸记录文件格式(W3C Extended Log File Format),很多相关软件都可以分析这种格式的档案。记录文件在预设的状况下会记录时间、客户端IP地址、Method(GET、POST等)、URI stem(要求的资源)和HTTP状态(数字状态代码)。这些字段大部分都一看就懂,只是HTTP状态需要有大概的了解。

小知识:一般而言,如果代码是在200到299代表成功。常见的200状态码代表符合客户端的要求;300到399代表必须由客户端采取动作才能满足所提出的要求;400到499和500到599代表客户端和服务器有问题。最常见的状态代码有两个,一个是404,代表客户端要求的资源不在服务器上,403代表的是所要求的资源拒绝服务。

Apache记录文件的预设储存位置在/usr/local/apache/logs,最有价值的记录文件是Access_log,不过 SSL_request_log和SSL_engine_log也能提供有用的资料。 Access_log记录文件有七个字段,包括客户端IP地址、特殊人物识别符、用户名称、日期、Method Resource Protocol(GET、POST等;要求哪些资源;协议版本)、HTTP状态、还有传输的字节。

常规探测手段的记录分析
网页服务器版本是很重要的信息,黑客一般先向网页服务器提出要求,让服务器送回本身的版本信息:只要把「HEAD / HTTP/1.0」这个字符串用常见的Netcat utility(相关资料网址http://www.l0pht.com/~weld/netcat/)和OpenSSL binary(相关资料网址http://www.openssl.org/)送到开放服务器的通讯端口就成了。注意看下面的示范:

C:>nc -n 10.0.2.55 80
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Sun, 08 Mar 2004 14:31:00 GMT
Content-Type: text/html
Set-Cookie: ASPSESSIONIDGQQQQQPA=IHOJAGJDECOLLGIBNKMCEEED; path=/
Cache-control: private

  这种形式的要求在IIS和Apache的记录文件中会生成以下记录:

IIS: 15:08:44 11.1.2.80 HEAD /Default.asp 200
Linux: 11.1.2.80 - - [08/Mar/2004:15:56:39 -0700] "HEAD / HTTP/1.0" 200 0

  虽然这类要求合法,看似很平常,不过却常常是网络攻击的前奏曲。Access_log和IIS的记录文件没有表明这个要求是连到SSL服务器还是一般的网页服务器,可是Apache的 SSL_request_log和SSL_engine_log(在/usr/local/apache/logs目录下)记录文件就会记录是否有联机到SSL服务器。请看以下的SSL_request_log记录文件:

[07/Mar/2004:15:32:52 -0700] 11.1.1.50 SSLv3 EDH-RSA-DES-CBC3-SHA "HEAD / HTTP/1.0" 0

  第三和第四个字段表示客户端使用的是哪种加密方式,以下的SSL_request_log分别记录从OpenSSL、Internet Explorer和Netscape客户端程序发出的要求:
[07/Mar/2004:15:48:26 -0700] 11.1.1.50 SSLv3 EDH-RSA-DES-CBC3-SHA "GET / HTTP/1.0" 2692
[07/Mar/2004:15:52:51 -0700] 10.0.2.55 TLSv1 RC4-MD5 "GET / HTTP/1.1" 2692
[07/Mar/2004:15:54:46 -0700] 11.1.1.50 SSLv3 EXP-RC4-MD5 "GET / HTTP/1.0" 2692
[07/Mar/2004:15:55:34 –0700] 11.1.2.80 SSLv3 RC4-MD5 “GET / HTTP/1.0” 2692
     另外黑客通常会复制目标网站,也就是所谓的镜射网站,用它来取得发动攻击所需要的信息。网页原始码中的批注字段常有目录、文件名甚至密码的有用资料。复制网站常用的工具包括窗口系统的Teleport Pro(网址http://www.tenmax.com/teleport/pro/home.htm)和Unix系统的Wget(网址http://www.gnu.org/manual/wget/)。在这里我为大家分析Wget和TeleportPro这两个软件攻击网页服务器后记录文件中的内容:这两个软件能全面快速搜寻整个网站,对所有公开的网页提出要求。只要检查一下记录文件就知道,要知道这是镜射这个动作是很简单的事。以下是IIS的记录文件:

16:28:52 11.1.2.80 GET /Default.asp 200
16:28:52 11.1.2.80 GET /robots.txt 404
16:28:52 11.1.2.80 GET /header_protecting_your_privacy.gif 200
16:28:52 11.1.2.80 GET /header_fec_reqs.gif 200
16:28:55 11.1.2.80 GET /photo_contribs_sidebar.jpg 200
16:28:55 11.1.2.80 GET /g2klogo_white_bgd.gif 200
16:28:55 11.1.2.80 GET /header_contribute_on_line.gif 200

这里的11.1.2.80这个主机是Unix系统的客户端,是用Wget软件发出请求。
16:49:01 11.1.1.50 GET /Default.asp 200
16:49:01 11.1.1.50 GET /robots.txt 404
16:49:01 11.1.1.50 GET /header_contribute_on_line.gif 200
16:49:01 11.1.1.50 GET /g2klogo_white_bgd.gif 200
16:49:01 11.1.1.50 GET /photo_contribs_sidebar.jpg 200
16:49:01 11.1.1.50 GET /header_fec_reqs.gif 200
16:49:01 11.1.1.50 GET /header_protecting_your_privacy.gif 200
这里的11.1.1.50系统是窗口环境的客户端,用的是TeleportPro发出的请求。

  小提示:以上两个主机都要求Robots.txt这个文档,其实这个档案是网页管理员的工具,作用是防止Wget和TeleportPro这类自动抓文件软件对某些网页从事抓取或搜寻的动作。如果有人提出Robots.txt档的要求,常常代表是要镜射整个网站。但TeleportPro和Wget这两个软件都可以把要求Robots.txt这个文件的功能取消。

黑客还可以用网页漏洞稽核软件Whisker(网址http://www.wiretrip.net/)来侦查网页服务器有没有安全后门。以下是IIS和Apache网页服务器在执行Whisker后产生的部分记录文件:

IIS:
13:17:56 11.1.1.50 GET /SiteServer/Publishing/viewcode.asp 404
13:17:56 11.1.1.50 GET /msadc/samples/adctest.asp 200
13:17:56 11.1.1.50 GET /advworks/equipment/catalog_type.asp 404
13:17:56 11.1.1.50 GET /iisadmpwd/aexp4b.htr 200
13:17:56 11.1.1.50 HEAD /scripts/samples/details.idc 200
13:17:56 11.1.1.50 GET /scripts/samples/details.idc 200
13:17:56 11.1.1.50 HEAD /scripts/samples/ctguestb.idc 200
13:17:56 11.1.1.50 GET /scripts/samples/ctguestb.idc 200
13:17:56 11.1.1.50 HEAD /scripts/tools/newdsn.exe 404
13:17:56 11.1.1.50 HEAD /msadc/msadcs.dll 200
13:17:56 11.1.1.50 GET /scripts/iisadmin/bdir.htr 200
13:17:56 11.1.1.50 HEAD /carbo.dll 404
13:17:56 11.1.1.50 HEAD /scripts/proxy/ 403
13:17:56 11.1.1.50 HEAD /scripts/proxy/w3proxy.dll 500
13:17:56 11.1.1.50 GET /scripts/proxy/w3proxy.dll 500

Apache:
11.1.1.50 - - [08/Mar/2004:12:57:28 -0700] "GET /cfcache.map HTTP/1.0" 404 266
11.1.1.50 - - [08/Mar/2004:12:57:28 -0700] "GET /cfide/Administrator/startstop.html HTTP/1.0" 404 289
11.1.1.50 - - [08/Mar/2004:12:57:28 -0700] "GET /cfappman/index.cfm HTTP/1.0" 404 273
11.1.1.50 - - [08/Mar/2004:12:57:28 -0700] "GET /cgi-bin/ HTTP/1.0" 403 267
11.1.1.50 - - [08/Mar/2004:12:57:29 -0700] "GET /cgi-bin/dbmlparser.exe HTTP/1.0" 404 277
11.1.1.50 - - [08/Mar/2004:12:57:29 -0700] "HEAD /_vti_inf.html HTTP/1.0" 404 0
11.1.1.50 - - [08/Mar/2004:12:57:29 -0700] "HEAD /_vti_pvt/ HTTP/1.0" 404 0
11.1.1.50 - - [08/Mar/2004:12:57:29 -0700] "HEAD /cgi-bin/webdist.cgi HTTP/1.0" 404 0
11.1.1.50 - - [08/Mar/2004:12:57:29 -0700] "HEAD /cgi-bin/handler HTTP/1.0" 404 0
11.1.1.50 - - [08/Mar/2004:12:57:29 -0700] "HEAD /cgi-bin/wrap HTTP/1.0" 404 0
11.1.1.50 - - [08/Mar/2004:12:57:29 -0700] "HEAD /cgi-bin/pfdisplay.cgi HTTP/1.0" 404 0

  大家要侦测这类攻击的关键就在于从单一IP地址发出大量的404 HTTP状态代码。只要注意到这类信息,就可以分析对方要求的资源,于是它们就会拼命要求提供Cgi-bin scripts(Apache服务器的cgi-bin目录;IIS服务器的Scripts目录)。

  网页如果被人探访过,总会在记录文件留下什么线索。如果网页管理员警觉性够高,应该会把分析记录文件作为追查线索,并且在检查后发现网站真的有漏洞时,就能预测会有黑客攻击网站。

直接攻击及记录分析
  接下来我要向大家示范两种常见的网页服务器攻击方式,分析服务器在受到攻击后黑客在记录文件中痕迹。

1.MDAC攻击

  MDAC攻击法可以让网页的客户端在IIS网页服务器上执行命令。如果有人开始攻击IIS服务器,记录文件就会记下客户端曾经呼叫Msadcs.dll文档:

17:48:49 12.1.2.8 GET /msadc/msadcs.dll 200
17:48:51 12.1.2.8 POST /msadc/msadcs.dll 200

2.利用原始码漏洞

  第二种攻击方式也很普遍,就是会影响ASP和Java网页的暴露原始码漏洞。古老的安全漏洞是+.htr臭虫,这个BUG会显示ASP原始码。如果有人利用这个漏洞攻击,就会在IIS的记录文件里面留下这些线索:

17:50:13 11.1.2.80 GET /default.asp+.htr 200

3.权限问题
  网页常会只让有权限的使用者进入,接下来我们要让各位看 Apache的Access_log记录文件会在登录失败时留下什么线索:

12.1.2.8 - user [08/Mar/2004:18:58:29 -0700] "GET /private/ HTTP/1.0" 401 462

第三栏里面的使用者名称是「user」。还有要注意HTTP的状态代号是401,代表非法存取。

Apache和IIS的类比和相关的攻击与记录就分析到这里,这里只是引用了几个比较常见的,同时又能体现出两者差异和共同点的例子,大家完全可以根据自己喜欢的方式去测试服务器,比如现在流行的SQL注入和上传漏洞等,相信这样才能真正做到攻防对抗!

(0)

相关推荐

  • IIS&Apache 攻击记录分析篇

    在这里,我为大家介绍一下两种常见的网页服务器中最重要的记录文件,分析服务器遭到攻击后,黑客在记录文件中会留下什么记录.目前最常见的网页服务器有两种:Apache和微软的Internet Information Server(简称IIS),这两种服务器都有一般版本和SSL认证版本.本文将使用和现实黑客的攻击手段类似的攻击方法去测试服务器并分析相关文件,有条件的朋友可在自己的机器上测试. IIS的预设记录文件地址在C:\winnt\system32\logfiles\w3svc1目录下,文件名是当天

  • j2Cache线上异常排查问题解决记录分析

    目录 问题背景 问题分析 假设问题 小心求证 问题重现 问题解决 问题后记-下面才是真正的原因 重新假设 最终解决 问题背景 开发反馈,线上有个服务在运行一段时间后,就会抛异常导致redis缓存不可用.项目使用了j2Caceh,异常是j2Cache的RedisCacheProvider抛出来的,如: Exception in thread "main" redis.clients.jedis.exceptions.JedisException: Could not get a reso

  • web.xml中Maven占位符不生效问题记录分析

    目录 问题背景 问题分析 Resources插件有三个目标: 问题定位 问题解决 问题背景 开发反馈,一个spring mvc的web项目,在web.xml配置的占位符不生效,编译后还是没有替换成配置的属性,如下: <context-param> <param-name>logbackConfigLocation</param-name> <param-value>classpath:${loagback.xml.path:logback.xml}</

  • Nginx记录分析响应慢的请求及替换网站响应内容的配置

    nginx记录分析网站响应慢的请求(ngx_http_log_request_speed) nginx模块ngx_http_log_request_speed可以用来找出网站哪些请求很慢,针对站点很多,文件以及请求很多想找出哪些请求比较慢的话,这个插件非常有效.作者的初衷是写给自己用的,用来找出站点中处理时间较长的请求, 这些请求是造成服务器高负载的很大根源. 日志记录之后,在使用perl脚本分析日志,即可知道哪些请求需要修正. 1. 模块安装 nginx第三方模块安装方法这里就一笔略过了. 配

  • JVM完全解读之GC日志记录分析

    相信大家在系统学习jvm的时候都会有遇到过这样的问题,散落的jvm知识点知道很多,但是真正在线上环境遇到一些莫名其妙的gc异常时候却无从下手去分析. 关于这块的苦我也表示能够理解,之前光是JVM相关的八股文就整理了许多,但是经常是不知道如何在实战中使用.最近也尝试在模拟一些案例来训练自己的JVM相关知识,本文特意记录下这段调优经历. Java应用的GC评估 可能大多数程序员在开发完某个需求之后,往线上环境一丢,然后就基本不怎么关注后续的变化了.但是是否有考虑过,这些新引入的代码会对原有系统造成的

  • os_object_release Crash 排查记录分析

    目录 Crash 信息 确认目标对象类型 定位 Crash 场景 Crash 信息 线上存在一个持续很久的 Crash,由于没有明确业务栈且量级不算大,让它成为了老赖之一,Crash 栈是这样的: Thread 55 0 libdispatch.dylib 0x0000000188a8cf8c __os_object_release_internal_n + 80 1 libdispatch.dylib 0x0000000188a96eec __dispatch_lane_invoke + 11

  • libAccessibility通知Crash排查记录分析

    目录 Crash 信息 复现场景 简单引用分析 寻找 Crash 对象 通知中心是否一定弱引用 observer Crash 信息 Last Exception : 0 libobjc.A.dylib 0x00000001bee86f40 _objc_msgSend + 32 1 CoreFoundation 0x00000001a6132834 ___CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 28 2 CoreFoundati

  • IIS故障(Connections_Refused)问题分析及处理

    这篇文章其实已经写好很久,只是后来一直没有重现当时的问题,或者因为业务的重要性.投诉的压力也就临时处理了.这几天某地市Web服务器连续多次出现这个问题,正好借这个案例来做个收尾. 前几个月有台重要的Web服务器(Windows Server2003 + IIS6.0)出现客户端无法访问Web服务器上的站点,错误信息提示为"页面无法显示"的情况.登录服务器检查后发现IIS并未停止运行,各服务也正常处理,但就是无法访问站点上的页面(包括静态页面).这种问题其实以前也经常发生,基本上处理方法

  • IIS W3C日志记录字段和HTTP状态代码的说明

    像新网的部分服务器ftp目录有这个文件,但是就是提示没权限查看也没有权限下载,还得必须给他们打电话才能要到. 做为网站拥有者,我们应该关注IIS日志,从里面我们不仅仅可以看到网站的访问记录和搜索引擎的抓取记录,还可以看到哪些网站盗链本站的哪些资源.部分死链接以及其他出错信息.其实对于我们来说,蜘蛛抓取记录和相关出错信息是我们最想关注的.哪些蜘蛛什么时间抓取了什么页面,返回的什么结果,是否正常,都可以从日志里清楚的看到. 下面说说IIS W3C格式日志中记录的字段及说明(一般都是选择的W3C格式日

  • 使用CDN之后APACHE日志记录中IP地址不正确的解决方案

    最近在搞APACHE日志分析,装好了awstats之后,这两天进行了观察, 报表日期 月 1 月 2010 首次参观日期 2010年01月12日 11:04 最近参观日期 2010年01月13日 23:59     参观者 参观人次 网页数 文件数 字节 浏览器流量 * 77  226  (2.93 参观人次/参观者) 508979 (2252.11 网页数/参观) 509492 (2254.38 文件数/参观) 13.67 G字节 (63430.28 K字节/参观) 非浏览器流量 *  117

随机推荐