当前位置: 王朝网络 >> other >> 使用snort-1.8.0的体验

使用snort-1.8.0的体验

王朝other·作者佚名 2006-01-09

使用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

</tcphdr>

</iphdr>

</packet>

</event>

<hostname>loca***/hostname>

</sensor>

<signature>FTP MDTM overflow attempt</signature>

<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，

<!ELEMENT data (#PCDATA)>可以选择看到的data内容格式，比如现在看到的hex，base64,最节省时间空间的ascii，只是不会有我们能够轻易读懂的，因为数据采集的层次问题，这个和网络的ISO模型有关/

点击展开全文

上一篇：完整的TCP通信包实现