使用snort-1.8.0的体验
Author Gnicky URL:http://blog.csdn.net/loconfuse
最近写的东西更像是个记录过程，这是我的思维习惯，也许你不是这样的--）
从某种意义上来说，本来是想通过snort-1.8编译生成一个spo_xml.out的输出插件，然后让其在snort2.0下工作的（编译的部分交给1.8，在2.0当中只是在关键字注册的时候调用一下，这样应该可以在2.0下使用xml output plugin，有些取巧的想法）
结果折腾下，根据提示要求的class .include等等，把1.8版本下的输出插件生成好了，转念想来，那岂不是在这个目录下的snort就可以尝试xml输出了，何必费那番周折。心里总是对这个1.8版本有些担心，版本的升级必然解决了许多的bug，高版本一般来说要比低版本稳定，安全。但就snort而言，高版本比低版本少了好些功能，也许也增加了好些特点，只是我目前还没有了解到，惭愧%
使用xml output plugin：
修改下规则文件，采用redalert，在redalert中采用xml插件：output xml ；log, file=/var/log/snortxml，运行起来，到var/log中去发现一堆的xml文件，怎么居然是不按照集中管理的一个xml文件？观察文件发现其中仅仅包含了xml文件的格式<?xml version****><file></file>，并没有记录数据，文件的创建日期是今天。却意外发现上面也有一些xml的日志文件，时间是昨天的这个时候，昨日以为的失败，居然也产生了alert.xml文件？也很是纳闷。其中的内容更是离奇，连一个标准的xml框架也算不上，<?xml version****><file>倒是少了</file>。
Xml Log文件的命名规则是这样的：conf中定义的文件名称+日期+@编号（自增长型）。由于一个linux系统下安装了3，4个不同版本的snort，自己也有些晕了，昨日的那些xml log是snort2.2.0生成的，也许那个时候的xml plugin植入2.2.0有些成果了，但现在2.2运行不起来，那个2.2.0因为某些修改，居然对detection的一个plugin不认识了，unknown preprocessor “http inspect”, unknown preprocessor “http inspect server”。
解决数据无法录入xml的问题：
假如你的xml log文件中没有数据，可以尝试下，根据xml文件的内容，应该是dtd格式文件的存放路径有关，于是把snml文件从contrib中copy到主目录中，结果在/var/log中发现一个2.5M的文件J
下面简单分析下xml文件DTD以及content,首先通过xml log中截取的部分内容来学习下：（有些东西，我也是胡乱猜测，希望能够得到大家的指正）
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE snort-message-version-0.1>
<file>-------------------基本结构对应了</file>
<event version="1.0">------event generate log action,many event types
<sensor encoding="hex" detail="full">--some of the libpcap’s property—default full/fast etc
<interface>eth0</interface>--eth0 enternet One
<ipaddr version="4">192.168.0.59</ipaddr> ipV4
<hostname>loc***domain</hostname> your listening host
---------------some thing upper is the same as any other, these property in blog <sensor>, some times you may have a lot of sensor, this content will different.
</sensor>
<signature>FTP MDTM overflow attempt</signature> ---the content is the msg in rulesJ
<timestamp>2005-01-31 22:27:06+08</timestamp>
<packet>
<iphdr saddr="192.168.0.2" daddr="192.168.0.59" proto="6" ver="4" hlen="5" len="64" id="3708" ttl="128" csum="27310">
<tcphdr sport="808" dport="33318" flags="18" seq="2239921477" ack="1007640368" off="11" win="16920" csum="20263">
<option code="2" len="4">05820103</option>
<option code="1"/>
<option code="3" len="3">000101</option>
<option code="1"/>
<option code="1"/>
<option code="8" len="10">00000000000000000101</option>
<option code="1"/>
<option code="1"/>
<option code="4"/>
</tcphdr>
</iphdr>
</packet>
</event>
<event version="1.0">
<sensor encoding="hex" detail="full">
<interface>eth0</interface>
<ipaddr version="4">192.168.0.59</ipaddr>
<hostname>loca***/hostname>
</sensor>
<signature>FTP MDTM overflow attempt</signature>
<timestamp>2005-01-31 22:27:06+08</timestamp>
<packet>
<iphdr saddr="192.168.0.59" daddr="192.168.0.2" proto="6" ver="4" hlen="5" len="1450" id="16575" ttl="64" csum="29441">
<tcphdr sport="33318" dport="808" flags="16" seq="1007640368" ack="2239921478" off="8" win="5840" csum="25443">
<option code="1"/>
<option code="1"/>
<option code="8" len="10">00041F97000000004745</option>----所有的option目前还没学习<data>7C6C623A307C2A7C313130373039343738363535362E3132397C7069643A33312D372D31352D332D313333343030377C66696E616E63652E73722F73746F636B2F686B73746F636B6E6577732F32303035303133312F30343337313333343030372E7368746D6C7C73743A39362E3332357C65743A313130373039343836353732377C7C68703A756E6B6F776E7C6C623A307C2A7C313130373039343738363535362E3132397C7069643A33312D372D382D302D313333343533327C66696E616E63652E73722F73746F636B2F792F32303035303133312F30383231313333343533322E7368746D6C7C73743A36322E3434327C65743A313130373039343938303531337C33312D372D31352D332D313333343030377C68703A756E6B6F776E7C6C623A307C2A7C313130373039343738363535362E3132397C7069643A33312D31322D322D302D313333343233307C66696E616E63652E73722F672F32303035303133312F30363434313333343233302E7368746D6C7C73743A32352E3331357C65743A313130373039353139373339317C33312D372D382D302D313333343533327C68703A756E6B6F776E7C6C623A307C2A7C313130373039343738363535362E3132397C7069643A33312D372D382D302D313332383634367C66696E616E63652E73722F73746F636B2F792F32303035303132382F30313430313332383634362E7368746D6C7C73743A33332E3936</data>--这堆东西人能翻译出来吗？
</tcphdr>
</iphdr>
</packet>
</event>
</file>
再看一下dtd中的描述：<!ELEMENT event (sensor, signature, reference*, timestamp, packet)>
就会明白当前的结构，reference*为什么在这里没有，为什么用*，不明白，但是发现一点关于reference的detection文件即sp_reference在后续的版本中已经被删除了。这和之前对该文件消失的分析道理是一样的，可见当初在snort设计的时候，隐含的问题也隐含了处理方法。
我想关心分析器的应该会关心data element，
<!-- This field contains a representation of data. The encoding of this data hex, base64, or ascii is defined as an attribute to the sensor tag. -->
<!ELEMENT data (#PCDATA)>可以选择看到的data内容格式，比如现在看到的hex，base64,最节省时间空间的ascii，只是不会有我们能够轻易读懂的，因为数据采集的层次问题，这个和网络的ISO模型有关/
本文地址：http://com.8s8s.com/it/it32729.htm