来源: 互联网  发布时间: 2013-11-30

大多数网站托管（Web hosting）公司都支持客户对Web站点统计数据的访问，但是你往往会觉得服务器所产生的状态信息不够全面。例如，配置不正确的Web服务器不能识别某些文件类型，这些类型的文件就不会出现在状态信息之中。幸好，你可以用PHP来定制状态信息收集程序，这样你就可以获取你所需要的信息了。

公共日志文件格式（Common Logfile Format，CLF）的结构

 
CLF最初是NCSA为HTTPd（全球网服务器软件）而设计的。CERN HTTPd是一个由万维网联盟（World Wide Web Consortium，W3C）维护的公共域Web服务器。W3C网站列出了该日志文件规范。基于微软和UNIX的Web服务器都可以生成CLF格式的日志文件。CLF格式如下：
Host IdentAuthuserTime_Stamp "request" Status_codeFile_size

例如：
21.53.48.83 - - [22/Apr/2002:22:19:12 -0500] "GET /cnet.gif HTTP/1.0" 200 8237

下面是日志条目的细目分类：

Host是网站访问者的IP地址或者DNS名；在上面的例子中，它是21.53.48.83。
Ident是该访客的远端身份（RFC 931）。破折号表明“未指定”。
Authuser是用户ID（如果Web服务器已经验证了验证网站访问者的身份的话）。
Time_Stam是服务器以“日/月/年”这种格式返回的时间。
Request是网站访问者的HTTP请求，例如GET或者POST。
Status_Code是服务器所返回的状态代码，例如：200代表“正确——浏览器请求成功”。
File_Size是用户所请求文件的大小。在本例中，它为 8237字节。

服务器状态代码

 
你可以在HTTP标准中找到W3C所开发的服务器状态代码规范。这些由服务器所产生的状态代码表示了浏览器和服务器之间的数据传输成功与否。这些代码一般传递给浏览器（例如非常有名的404错误“页面没有找到“）或者添加到服务器日志中去。

收集数据

创建我们的自定义应用程序的第一步就是获取用户数据。每当用户选择网站的某个资源时，我们就希望创建一个对应的日志条目。幸好，服务器变量的存在使得我们能够查询用户浏览器并获取数据。

报头中的服务器变量携带了从浏览器传递到服务器的信息。REMOTE_ADDR就是一个服务器变量的例子。这个变量返回了用户的IP地址：
例子输出：27.234.125.222

下面的PHP代码将显示出当前用户的IP地址：
<?php echo $_SERVER['REMOTE_ADDR']; ?>

让我们看看我们的PHP应用程序的代码。首先，我们需要定义我们想跟踪的网站资源并指定文件大小：
//获取我们想记录的文件名称
$fileName="cnet-banner.gif";
$fileSize="92292";

你无需把这些值保存到静态变量中去。如果你要跟踪许多条目，那么你可以把它们保存到数组或者数据库中去。在这种情况下，你可能会希望通过一个外部链接来找到每个条目，如下所示：
<a href="/blog_article/weblogger/bannerid/123.html"><imgsrc="/blog_article/cnet-banner.gif" border="0"></a>

其中“123”表示“cnet-banner.gif”所对应的记录。然后，我们通过服务器变量来查询用户浏览器。这样我们就得到在我们的日志文件中添加新条目所需的数据：
//得到网站浏览者的CLF信息
$host=$_SERVER['REMOTE_ADDR'];
$ident=$_SERVER['REMOTE_IDENT'];
$auth=$_SERVER['REMOTE_USER'];
$timeStamp=date("d/M/Y:H:i:s O");
$reqType=$_SERVER['REQUEST_METHOD'];
$servProtocol=$_SERVER['SERVER_PROTOCOL'];
$statusCode="200";

然后，我们检查服务器是否返回了空值（null）。根据CLF规范，空值应该用破折号来代替。这样，下一个代码块的任务就是寻找空值并用破折号来取代它：
//给空值添加破折号（根据规范）
if ($host==""){ $host="-"; }
if ($ident==""){ $ident="-"; }
if ($auth==""){ $auth="-"; }
if ($reqType==""){ $reqType="-"; }
if ($servProtocol==""){ $servProtocol="-"; }

一旦我们获取了必要的信息，这些值将被组织成一种符合CLF规范的格式：
//创建CLF格式的字符串
$clfString=$host." ".$ident." ".$auth." [".$timeStamp."] \"".$reqType." /".$fileName." ".$servProtocol."\" ".$statusCode." ".$fileSize."\r\n";

创建自定义日志文件

现在，格式化之后的数据可以存放到我们的自定义日志文件中去。首先，我们将创建一种文件命名协定，并编写每日产生一个新日志文件的方法（函数）。在本文所举的例子中，每个文件都以“weblog-”开头，然后是按月/日/年表示的日期，文件扩展名为.log。.log扩展名一般表示服务器日志文件。（实际上，绝大多数日志分析器都搜索.log文件。）
// 用当前日期来命名日志文件
$logPath="./log/";
$logFile=$logPath."weblog-".date("mdy").".log";

现在，我们需要判断当前日志文件是否存在。如果存在，我们就向它添加条目；否则，应用程序就创建新的日志文件。（新日志文件的创建一般发生在日期更改时，因为这时文件名发生变化了。）
//检查日志文件是否已经存在
if (file_exists($logFile)){
//如果存在，则打开已存在的日志文件
$fileWrite = fopen($logFile,"a");}
else {
//否则，创建新的日志文件
$fileWrite = fopen($logFile,"w"); }

如果你在写或者追加文件时，收到“权限不足（Permission Denied）”错误信息，请更改目标日志文件夹的权限来允许写操作。绝大多数Web服务器的默认权限为“可读可执行”。你可以用CHMOD命令或者使用FTP客户端来改变文件夹的权限。

然后，我们创建文件锁定机制，这样当两个或者更多用户同时访问日志文件时，只有其中的一个用户可以对该文件进行写操作：
//创建文件写操作的锁定机制
flock($fileWrite, LOCK_SH);

最后，我们写入条目的内容：
//写CLF条目
fwrite($fileWrite,$clfString);
//解除文件锁定状态
flock($fileWrite, LOCK_UN);
//关闭日志文件
fclose($fileWrite);

处理日志数据

 
在该系统产品化之后，客户希望得到对所收集到的访问者数据的详细统计分析。由于所有的定制日志文件都是按照一个标准的格式组织的，因此任何一个日志分析器都可以处理它们。日志分析器是一个工具，它分析大的日志文件并产生饼图、直方图以及其它统计图形。日志分析器也用来收集数据，并综合出提供哪些用户访问你的网站、点击数等方面的信息。

下面列出了几个比较流行的日志分析器：

WebTrends是一个非常不错的日志分析器，它适用于大规模网站以及企业级的网络。
Analog是一个颇受欢迎的免费日志分析器。
Webalizer是一个免费的分析程序。它可以产生HTML报告，这样大多数网络浏览器都可以查看它的报告。

遵守标准

我们可以轻松的扩展该应用程序来让它支持其它类型的日志记录。这样你就可以捕获到更多的数据，如浏览器类型以及referrer（referrer指得是链接到当前网页的前一个网页）。这里的经验就是：在你编程的时候遵循标准或者惯例终究会简化工作。

    

    来源: 互联网  发布时间: 2013-11-30

    在多数WEB开发者眼中，ASP和JSP都被认为是领跑者，而PHP却被认为是个弱小的“挣扎者”，或者说它是一门被贬低为业余者才使用的语言，不值得参与企业Web开发的竞争。在我看来，PHP没有被当作竞争者的理由是评论者缺乏对它的了解，而且也不了解用于Web开发的其他操作系统。和一些观点相反，Windows不再占有Web虚拟主机服务市场的最大份额，我猜想它在Web开发这一领域里也在被摧城拔寨。

在企业开发里为什么没有PHP？

 
很显然，PHP被认为落后ASP和JSP太多，以至于它是没有什么用的，但是这恰恰与事实不符。PHP本身就是一门强大的语言。它事实上在每个发行版的Linux上都有，在Mac OS X上也有。获取开发和使用PHP代码的构件（building-block）工具和软件都是免费的。用于开发PHP应用程序的商业集成开发环境（commercial integrated development environments，IDES）也可以找到——这样的工具有Komodo（它运行在Linux和Windows上）和Zend Studio（这个应用程序能够运行在任何带有Java运行环境的操作系统上）。你几乎可以在每个Web虚拟主机上运行由PHP建立的网站，而不要考虑服务器所运行的是什么操作系统，这一事实让PHP更加具有吸引力。

PHP能够提供什么？

先把PHP周围有什么忘掉一会儿，而考虑一下PHP自身能够提供什么。它是一门强健的服务器端语言，能够提供相当多的功能，而且能够迅速地为页面提供服务。

容易使用

使用C或者Perl或者具有类似风格和句法的另一种语言的任何用户都能够很快上手PHP。尽管它是设计用在Web上的，但是它也能够作为命令行语言使用。你正在编写的Web应用程序需要每个小时或者每天执行一次某些代码吗？使用cron或者类似的计划安排管理器，你可以计划安排PHP代码在你希望的时候执行，使用普通的命令解释脚本或者批处理文件就能够执行这样的代码。不需要自动调用浏览器就能够查看专门的网页，从而执行你的事件，也没有必要依赖来访者的点击来告诉你的系统：特定的代码需要在特定的时候被执行。PHP在这一领域可扩展性的事实是绝对具有吸引力的。

PHP的好处

 
我不是JSP或者ASP的老手，在此我也不想贬低这些语言。相反，我会把注意力放在PHP的好处上。

本地化
PHP让你能够为网站的访问者提供本地化的服务。当用户点击进入网站的时候，网站会根据他们浏览器的设置自动地以其母语向其提供页面。要实现这一点不需要使用用于语言翻译的烦杂文件，而是使用和本地化的C程序所具有的相同能力，通过一个叫做gettext的系统实现的。如果被请求的语言文件存在，那么用户所看到的文本就是其母语；如果语言文件不存在，那么文本就是缺省的英语或者其他任何你所指定的语言。许多本地化的UNIX应用程序都将gettext作为标准，它让第三方的翻译变得轻而易举。

轻易地使用命令行
PHP支持在需要的地方设置和执行命令行程序。使用标准的UNIX diff工具，它能够生成错误最后一次修改同要使用电子邮件发送到错误的所有者的当前注释之间的不同。PHP代码对在系统上所编写的两个文件执行diff，将其输出作为输入，再生成一个要发送的电子邮件。这封电子邮件是通过PHP自己来发送的。

其他好处
上面的只是我在自己程序里所用到的强大功能中的两个，而还其他的功能。例如，你可以：

即时创建简单的Flash动画。
即时创建PDF文档。
使用高级数学功能，以及面向对象的编程技术。
读取和写入到本地和IMAP邮箱。
在PHP里就可以使用任何标准的Internet协议。想要编写基于PHP的FTP、Web或者新闻客户端？没有问题！只使用PHP你就完全能够编写出使用标准TCP/IP套接字的客户端和服务器，并以此创建自己的协议。
实现对加密的支持，以及对各种数据库服务器的支持。
缺乏远见的评论

我觉得，那些寻找顶级Web开发语言而排除掉PHP的人是极其短见的。我使用PHP编写代码已经有很多年了，无论是像错误追踪系统这样的高级功能，还是简单地重复使用页眉和页脚这样的普通功能，我都使用PHP编写过。我用PHP编写过半静态的页面，也编写过全功能的多媒体演示。我不是唯一一个使用PHP的人。如果PHP不值得引起注意，如果它只是小儿科或者爱好者的语言，那它为什么会是在Web开发上成长最快的语言呢？如果它没有ASP或者JSP那么强大，那么它为什么会被用在流量巨大Web网站上？例如Yahoo，据说它就是由PHP建成的。

开发人员习惯用熟悉的产品

我敢肯定，ASP 和JSP有它们各自的强项，但是我相信人们是用它们不是因为它们能够提供比PHP更加强大的功能，而是因为人们已经了解了它们，并希望以自己习惯的方法编写代码。排除PHP只能表示对这一语言的无知。

 

    

    来源: 互联网  发布时间: 2013-11-30

1.  前言  3
2.  报警信息  3
3.  NFR的检测  4
4.  协议分析  8
5.  漏洞说明  15
6.  漏洞分析  18
7.  小结  20


1.  前言
NFR（Network Flight Recorder）是一个老牌的商业网络IDS产品，最初由Firewall的牛人Marcus J. Ranum创建，是作为一个通用的网络流量分析和记录软件来实现的，为了最大限度地发挥分析工具的灵活性，NFR提供了完善强大的N-Code脚本语言，在很多的评测中表现出色。虽然L0pht为NFR提供过数百个签名库，但是缺乏一个可靠的签名集一直是他的软肋。

使用NFR有一段时间后，发现NFR存在着不少问题。且不说AI对中文的兼容性差而经常退出，也不说NFR版本升级而攻击事件说明却一直用旧版本的说明，单是IDS中最关键的攻击签名库，却让我大跌眼镜。除了升级缓慢以外，甚至还存在不少错误的签名。本系列文章针对其中我发现的部分问题进行分析和阐述，以便各位更好地利用NFR产品，同时也想和各位同仁讨论IDS中攻击签名库的编写。由于知识和时间的限制，错误之处在所难免，还希望得到各位的指教，任何意见或建议请发至:benjurry@xfocus.org

SQL Server是微软为对抗Oracle推出的数据库, 占领的市场份额已经仅次于Oracle，居世界第二，但是其安全性也一直受到用户的置疑。从1996年，Microsoft公司推出的SQL Server 6.5版本到1998年推出的SQL Server 7.0，以及到2000年8月推出了SQL Server 2000，在版本和功能不断升级的情况下，安全问题却没有得到很好地改善，不断发布针对SQL Server的安全公告和补丁。在2003年1月24日，针对SQL Server的“Slammer”蠕虫在Internet上肆虐，导致网络流量激增，严重影响了世界范围内的计算机和网络系统。SQL Server的漏洞引起了各大安全公司和厂商的重视，因此NFR也立即发布了多个针对SQL Server的攻击签名，其中包括了2002年8月7日Immunity公司Dave Aitel发现的Hello Buffer Overflow漏洞。但是在使用过程中，我发现NFR针对该漏洞的报警非常多，于是我对此进行了分析，于是写成了这个文章，以做记录。


2.  报警信息
下面是NFR针对MS SQL Hello Buffer Overflow的报警信息：

Severity:      Attack
Time:        13:54:21 15-Jul-2003
Source File:    packages/mssql/sql2k.nfr
Line:        226
Host:        benjurry-xfocus
Alert ID:      mssql_sql2k:buffered_hello
Source ID:     mssql_sql2k:source_me
Source:       mssql_sql2k:source_me
Source Description: Sqlserver 2k overflow detector
Source PID:     36531
Alert Message:   Saw 8 Mssql HELLO overflows from 192.168
          0.110 in 900 seconds
:          3
Source IP:     192.168.0.110
Destination IP:       --

其中包括了事件的严重等级、时间、NFR Sensor名字、攻击源IP、目的IP和一些其他报警信息。
在实际的使用中，一天产生了几百条这种报警，看来这是个误报，我们可以好好的分析一下了。


3.  NFR的检测
我们首先打开NFR发布的签名库 MSSQL.fp(或者也可以在AI的package中查看) 看一下NFR的针对这个漏洞的攻击签名：

<snip>
…..

变量定义等…

…
<snip>
sqlserv_schema = library_schema:new(1, ["time","ip","int","ip","int", "str"],
  scope());
sqlserv_rec = recorder("bin/list %c", "sqlserv_schema");

HELLO_SIG = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
MIN_LEN = strlen(HELLO_SIG);


…….
<snip>
filter hello tcp (client, dport: 1433) {
  declare $Blob inside tcp.connsym;
  if ($Blob == NULL) {
    $Blob = tcp.blob;
  } else {
    $Blob = cat($Blob, tcp.blob);
  }

  if (strlen($Blob) < MIN_LEN)
    return;

  if (prefix($Blob, HELLO_SIG)) {
    if (COUNTHELLO[tcp.connsrc]) {
      COUNTHELLO[tcp.connsrc] = COUNTHELLO[tcp.connsrc] + 1;
    } else {
      COUNTHELLO[tcp.connsrc] = 1;
    }
    if (do_alert(hello_overflow_alert, tcp.connsrc)) {
      alert(source_me, hello_overflow_alert, tcp.connsrc,
        tcp.connsport, tcp.conndst, tcp.conndport,
        "--AlertDetails",
        "ALERT_ID", "40-8",
        "ALERT_CONFIDENCE", 60,
        "ALERT_SEVERITY", "medium",
        "ALERT_IMPACT", "unknown",
        "ALERT_EVENT_TYPE", "attack",
        "ALERT_ASSESSMENT", "unknown",
        "IP_ADDR_SRC", tcp.connsrc,
        "PORT_SRC", tcp.connsport,
        "IP_ADDR_DST", tcp.conndst,
        "PORT_DST", tcp.conndport,
        "IP_PROTO_NUM", 6);
    }
    record packet.sec, tcp.conndst, tcp.conndport, tcp.connsrc,
      tcp.connsport, $Blob to sqlserv_rec;
    misc_attacks:rec(packet.sec, scope(),
            "Mssql HELLO overflow!", tcp.connsrc, tcp.conndst);
  }
}

从上面的N-CODE中我们可以看到,NFR在做这个检测的时候步骤如下:

1、定义了一个攻击特征码:
HELLO_SIG = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
和攻击特征码的长度:
MIN_LEN = strlen(HELLO_SIG);

2、从TCP的载荷数据中取出数据,把这个数据的长度和特征码长度比较，如果这个数据长度小于攻击特征码的长度，那么就不再进行下一步的检测；

3、否则，把这个数据和特征码进行字符串匹配，如果一致则认为是攻击行为，然后进行阻止或者报警。
接下来我们分析一下NFR IDS Record的数据，在AI中选择package->Query->MSSQL->MSSQL Server 200,定好条件，按Table查到数据，随便选取一条，copy出来得到如下内容：

Time:        15-Jul-2003 13:54:21
NFR:        benjurry-xfocus
Destination Address:192.168.0.135
Destination Port:  1433
Source Address:   192.168.0.110
Source Port:    1391
Payload:      
          \x12\x01\x004\x00\x00\x00\x00\x00\x00\x15\x00\x06\x01\x00\x1b\x00
          \x01\x02\x00\x1c\x00\x0c\x03\x00(\x00\x04\xff\x08\x00\x00\xc2\x00
          \x00\x00MSSQLServer\x00x\x03\x00\x00

上面这条记录包含了攻击的时间,报告攻击行为的NIDS sessor名字,目的IP、目的端口、源ip和源端口，而我们关心的是有效载荷Payload，因为它是NIDS用来和攻击签名库比较的数据。但是NFR在这里有几个小问题：

1.  会把payload中的能转换成ASCII字符的16进制数转换成ASCII码；

2.  不能处理Unicode的字符，这个将在以后的分析中可以看到。

在这个例子中为了分析方便，我们把上面的payload中的字符特征码部分转换成16进制数：
\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15\x00\x06\x01\x00\x1b
\x00\x01\x02\x00\x1c\x00\x0c\x03\x00\x28\x00\x04\xff\x08\x00\x00
\xc2\x00\x00\x00MSSQLServer\x00x\x03\x00\x00


NFR抓到数据组包后，发现是SQL Server包，便把里面的内容和SQL Server的攻击库进行比较，很明显，上面所列的数据和攻击库是相符合的，因此一个报警便产生了，但是这真是一个攻击行为吗？我们继续看下面的分析。


4.  协议分析

根据Xfocus的协议分析项目（将会在近期公布项目成果），MS SQL 2000用的是TDS8.0，它的格式如下：
-------------------------------------------------
| TDS包头（8字节） |  TDS负载数据       |
-------------------------------------------------
其中MS SQL SERVER 2000 TDS的包头结构如下：
-------------------------------------------------------------------
| TOKEN | STATUS | LENGTH | SIGNED NUM | PACKET NUM | WINDOW SIZE |
-------------------------------------------------------------------
其中TOKEN字段域1个字节，用来表示TDS操作请求种类。在这个漏洞中是0x12，也就是NFR记录中的有效负载中的第一个字节0x12, 0x12是预登录验证命令请求。其目的是获得当前MS SQL SERVER2000的一些设置值，比如SQL SERVER版本，是否支持加密等信息，作为客户端在构造TDS包的一个依据。SQL Server在接受到该类型的包的时候，将会由SSlibnet.dll中的相应函数做处理，在我的系统SQL Server 2000（没有SP）的情况下，相应函数如下：


.text:42CF6DDD ; Attributes: bp-based frame
.text:42CF6DDD
.text:42CF6DDD         public ConnectionPreLogin
.text:42CF6DDD ConnectionPreLogin proc near
.text:42CF6DDD
.text:42CF6DDD var_4      = dword ptr -4
.text:42CF6DDD arg_0      = dword ptr 8
.text:42CF6DDD arg_4      = dword ptr 0Ch
.text:42CF6DDD arg_8      = dword ptr 10h
.text:42CF6DDD arg_C      = dword ptr 14h
.text:42CF6DDD arg_10     = dword ptr 18h
.text:42CF6DDD
.text:42CF6DDD         push  ebp
.text:42CF6DDE         mov   ebp, esp
.text:42CF6DE0         push  ecx
.text:42CF6DE1         mov   eax, [ebp+arg_0]
.text:42CF6DE4         mov   ecx, [eax+94h]
.text:42CF6DEA         mov   [ebp+var_4], ecx
.text:42CF6DED         cmp   [ebp+var_4], 1
.text:42CF6DF1         jz   short loc_42CF6E01
.text:42CF6DF3         cmp   [ebp+var_4], 1
.text:42CF6DF7         jle   short loc_42CF6E3D
.text:42CF6DF9         cmp   [ebp+var_4], 3
……


STATUS字段域1个字节，当它为0x01的时候表示此包为当前TDS会话中的最后一个TDS包。
LENGTH字段域2个字节，表示TDS包的总长度，包括TDS包头的长度。
SIGNED NUM字段域2个字节，目前保留未用。
PACKET NUM字段域1个字节，表示此TDS包在当前TDS操作请求中的序号
WINDOW SIZE字段域1个字节，目前保留未用。
MS SQL SERVER 0X12 TDS的包主要包格式如下：
------------------------------------------------------
| TDS包头（8字节）| 字段指示头 |    信息      |
------------------------------------------------------
其中字段指示头是一个可以变长的表，表的每一项代表了在一个字段在信息中的偏移地址和长度信息，在SQL2000中主要是4个字段，其对应的字段指示头的结构如下：
{
  BYTE CNETLIBVERNO；
  WORD CNETLIBVEROFFSET；
  WORD CNETLIBVERLEN；
  BYTE CENYFLAGNO；
  WORD CENYFLAGOFFSET；
  WORD CENYFLAGLEN；
  BYTE SINSTNAMENO；
  WORD SINSTNAMEOFFSET；
  WORD SINSTNAMELEN；
  BYTE CTHREADIDNO；
  WORD CTHREADIDOFFSET；
  WORD CTHREADIDLEN；
  BYTE FILEDEND；
}
信息内容的结构如下：
{
  BYTE CNETLIBVER[CNETLIBVERLEN]
  BYTE CENYFLAG[CENYFLAGLEN]；
  BYTE SINSTNAME[SINSTNAMELEN]
  DWORD CTHREADID[CTHREADIDLEN]；
}
其中：
CNETLIBVERNO字段域
偏移：0
长度：1
含义：客户端使用的网络连接库（NETLIB）的版本号信息的字段编号。
说明：
备注：该值固定为0

CNETLIBVEROFFSET字段域
偏移：1
长度：2
含义：客户端使用的网络连接库（NETLIB）的版本号信息的字段偏移。
说明：字段格式是网络字节顺序
备注：

CNETLIBVERLEN字段域
偏移：3
长度：2
含义：客户端使用的网络连接库（NETLIB）的版本号信息的字段长度。
说明：字段格式是网络字节顺序
备注：该值固定为6

CENYFLAGNO字段域
偏移：5
长度：1
含义：客户端使用强制加密标记字段的字段号。
说明：
备注：该值固定为1

CENYFLAGOFFSET字段域
偏移：6
长度：2
含义：客户端使用强制加密标记字段的偏移。
说明：字段格式是网络字节顺序
备注：

CENYFLAGLEN字段域
偏移：8
长度：2
含义：客户端使用强制加密标记字段的长度。
说明：字段格式是网络字节顺序
备注：该值固定为1

SINSTNAMENO字段域
偏移：0XA
长度：1
含义：客户端要求使用服务器的实例名字段的字段号。
说明：
备注：该值固定为2

SINSTNAMEOFFSET字段域
偏移：0XB
长度：2
含义：客户端要求使用服务器的实例名字段的偏移。
说明：字段格式是网络字节顺序
备注：

SINSTNAMELEN字段域
偏移：0XD
长度：2
含义：客户端要求使用服务器的实例名字段的长度。
说明：字段格式是网络字节顺序
备注：

CTHREADIDNO字段域
偏移：0XF
长度：1
含义：客户端进程的线程ID字段的字段号。
说明：
备注：该值固定为3

CTHREADIDOFFSET字段域
偏移：0X10
长度：2
含义：客户端进程的线程ID字段的的偏移。
说明：字段格式是网络字节顺序
备注：

CTHREADIDLEN字段域
偏移：0X12
长度：2
含义：客户端进程的线程ID字段的长度。
说明：字段格式是网络字节顺序
备注：该值固定为4

FILEDEND字段域
偏移：0X14
长度：1
含义：此字段标记字段指示头已经结实，下面的就是字段的信息。
说明：结束标记是0XFF
备注：

CNETLIBVER字段域
偏移：0X15
长度：6
含义：客户端使用的网络连接库（NETLIB）的版本号。
说明：其版本号取的是DBNETLIB.DLL的版本
备注：其格式是网络字节格式，如版本号为80.528.00，则为
  08 00 02 10 00 00

CENYFLAG字段域
偏移：0X1B
长度：1
含义：客户端强制加密标志。
说明：0代表客户端不强制加密，1代表客户端使用强制加密
备注：

SINSTNAME字段域
偏移：0X1C
长度：SINSTNAMELEN
含义：客户端要求使用的实例名。
说明：单字节格式
备注：默认实例使用MSSQLserver这个名字

CTHREADID字段域
偏移：0X1C+SINSTNAMELEN
长度：4
含义：客户端进程的线程ID。
说明：字段格式是主机字节顺序
备注：

由上面的格式可以看出，一个用默认实例名MSSQLserver连接的SQL TDS包格式将是如下的格式：
\x12\x01\x00\x34\x00\x00\x00\x00
\x00\x00\x15\x00\x06\x01\x00\x1b
\x00\x01\x02\x00\x1c\x00\x0c\x03
\x00\x28\x00\x04\xff\x08\x00\x00
\xc2\x00\x00\x00MSSQ
LServer\x00
\x78\x03\x00\x00

而NFR的攻击签名库却是
HELLO_SIG = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
明显是正常TDS 0x12预登陆包的一部分，这就难怪会有这么多报警了，那NFR的这个攻击签名是如何得到的呢？
我们还是从它的漏洞说明入手吧！


5.  漏洞说明
下面是NFR N-CODE中对这个漏洞的说明：
FALSE POSITIVES

False positives are unlikely due to the nature of the attack

REFERENCES
Bugtraq Post
  http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00125.html
Exploit
http://www.scan-associates.net/papers/sql2kx2.txt
我们可以看到这个漏洞来自于http://www.immunitysec.com/ 的Dave Aitel，而从http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00125.html所列的MS SQL Server Hello Overflow NASL script中我们可以看到这个漏洞的关键就在于以下几个语句：

<snip>
pkt_hdr = raw_string(
0x12 ,0x01 ,0x00 ,0x34 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x15 ,0x00 ,0x06 ,0x01 ,0x00 ,0x1b,
0x00 ,0x01 ,0x02 ,0x00 ,0x1c ,0x00 ,0x0c ,0x03 ,0x00 ,0x28 ,0x00 ,0x04 ,0xff ,0x08 ,0x00 ,0x02,
0x10 ,0x00 ,0x00 ,0x00
);

pkt_tail = raw_string (
0x00 ,0x24 ,0x01 ,0x00 ,0x00
);


<snip>
…..
if(get_port_state(port))
{
  soc = open_sock_tcp(port);

  if(soc)
  {

  attack_string=crap(560);
     sql_packet = pkt_hdr+attack_string+pkt_tail;
  send(socket:soc, data:sql_packet);

    r = recv(socket:soc, length:4096);
    close(soc);
  display ("Result:",r,"\n");
    if(!r)
    {
     display("Security Hole in MSSQL\n");
      security_hole(port:port, data:report);
    }
  }

其中pkt_hdr是根据TDS协议构造的包，中间加了560个字符X，pkt_tail是构造的TDS包尾。

从这里我们可以看到，可怜的NFR居然不负责任地把MS SQL Server Hello Overflow NASL script中的pkt_hdr取出11个字符，毅然决然地把它们作为其签名。更为可笑的是居然还写着“False positives are unlikely due to the nature of the attack ”。
这就是在许多评测中遥遥领先的NFR？后来和stardust聊起这个事情的时候，认为这个现象和很多评测机构在评测IDS产品的时候，重视对产品漏报的检测而忽视对误报的评测有关。因为在评测产品时，基本上都是大部分都是黑箱评测，要检测漏报只要收集几个Exploits就可以进行，但要检测漏报却要产生正常的包，有些系统比如这里的Sql Server，如果不了解它的协议包格式，是很难产生的。因此一些IDS产生便钻了这样的空子，只要收集一些Exploits，把其中的攻击代码作为攻击签名直接发布，而不去分析漏洞产生的真正原因。

下面我们来分析一下这个漏洞产生的原因，然后我们就可以根据这个分析，写出比较完善的攻击签名。


6.  漏洞分析
用IDA对SSlibnet.dll反汇编，我们可以看到：


.text:42CF6F49 loc_42CF6F49:     ; CODE XREF: sub_42CF6E4F+EA j
.text:42CF6F49         mov   eax, [ebp+0xc]
.text:42CF6F4C         add   eax, [ebp-0x218]
.text:42CF6F52         push  eax
.text:42CF6F53         lea   ecx, [ebp-0x214]
.text:42CF6F59         push  ecx
.text:42CF6F5A         call  strcpy
.text:42CF6F5F         add   esp, 8
.text:42CF6F62         push  offset unk_42D01104
.text:42CF6F67         lea   edx, [ebp-0x214]
.text:42CF6F6D         push  edx
.text:42CF6F6E         call  strcmp
.text:42CF6F73         add   esp, 8


这个漏洞的原因就在这里，当程序用strcpy拷贝的时候，如果源字符串超出0x214（也就是532）后，目标地址后的环境变量就会被覆盖导致溢出。由于这个漏洞很早，经历了“Slammer”蠕虫后，基本上所有的系统都补掉了这个漏洞，因此这里就不在提供攻击代码了，有兴趣的朋友可以自己分析和编写一下。


另外需要在这里说明的是，如果分析了TDS协议和这个漏洞的成因，完善的攻击程序中的TDS包的长度是根据计算生成的，明显不会是”\x00\x34”,以避过SQL Server中针对TDS包长度的校验（当然在这个版本的SQL Server中还不包含这个校验），或者攻击程序把这攻击代码分成多个包，因此TDS格式中的status就不会是0x01,因此NFR是检测不出完善的攻击程序的的，也就是说针对这个漏洞，NFR 同时存在误报和漏洞的情况。

在分析了这个漏洞的成因后，我们就可以针对这个问题写出自己的NFR检测代码：


sqlserv_schema = library_schema:new(1, ["time","ip","int","ip","int", "str"],
  scope());
sqlserv_rec = recorder("bin/list %c", "sqlserv_schema");

HELLO_SIG = "\x12 ";
#考虑了分包和长度不固定的因素，去除了后面不可靠的特征串
MIN_LEN =29;
#包括TDS包头和字段指示头的总长度

…….
<snip>
filter hello tcp (client, dport: 1433) {
  declare $Blob inside tcp.connsym;
  if ($Blob == NULL) {
    $Blob = tcp.blob;
  } else {
    $Blob = cat($Blob, tcp.blob);
  }

  if (strlen($Blob) < MIN_LEN)
    return;

  if (prefix($Blob, HELLO_SIG) && strlen($Blob) > 295) {
    #考虑到实例名不可能超过255，因此这里长度选择了40（包头）+255=295
#也可以增加一个Value，以便用户自己根据事件情况进行调节
#报警
….

}


7.  小结
通过对NFR这个攻击签名的分析可以看出，发布完善的IDS攻击签名不是一个简单的事情，它需要了解应用的协议格式和漏洞的成因。而不是简单地收集网络上存在地exploits，然后截取其中的特征码。
目前很多人包括IDS开发人月都在讨论IDS有没有前途，需不需要。我想与其在那里讨论，不如静下来好好分析漏洞，完善攻击签名，使IDS做的更准确。
与其坐而论不如起而行！！（出处：www.xfocus.net）