网络管理

新帆： news.newsfan.net 几百个组很好
万千： news.webking.com.cn 几百个组很好
希网： news.cn99.com 2万个组国外交换较好
奔腾： news.bentium.com 近千个组较好
深圳： newsgroup.szptt.net 很差
210.12.63.4
微软： msnews.microsoft.com 都是计算机方面
国内完全免费的电子书籍下载
http://www.vvsoft.net/vvbksd/index.asp

http://download.chinaitlab.com/sort/2_1.htm

http://book.httpcn.com/

http://www.chinesebook.com.cn/bjbookfair/index.asp

http://www.eshunet.com/

http://www.manyi100.com/

http://www.52ebook.com/

http://www.pcbookcn.com/

http://www.itebook.net/download.asp

http://www.ebookcn.net

http://www.chinaz.com/DownLoad/L/8_Lastuptime_Desc_1.asp

http://soft.winzheng.com/SoftList/Catalog_11_SoftTime_Desc_1.htm

http://www.gd00.com/SoftList/Catalog_7_SoftTime_Desc_1.html

语言翻译：http://www.worldlingo.com

协议：

BGP：http://www.smartforce.com/learning_community/applications/course_resources/login_course_resources.asp?link_id=16923&type=2

- 作者： macob 2005年06月3日, 星期五 10:38　回复（0） |　引用（1）加入博采

构建网管基线的最佳实践　（作者置顶）

http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a008014fb3b.shtml#alarms

内容
为什么需要Baseline
网络基线可用于发现和解决网络中主要的资源限制问题。这些问题可用control plane

resources描叙出来。
Control plane resources包括以下参数：
  CPU utilization
  memory utilization
  Buffer utilization
通过在关键区域基线化网络，可以避免严重的性能问题。
随着对延迟敏感的应用增多，例如：语音和视频应用，基线化网络更加重要了。传统的TCP/IP协

议允许大量的延迟。语音和视频应用使用的UDP不支持重传和拥塞避免。网络基线就显得更加重要了。

什么是Baseline
Baseline是定期学习和观察网络以确定网络是否正常运行的过程。
通过基线化网络，可以获得以下信息：
（1）得到关于软硬件产品的有用的信息
（2）测定当前网络资源的利用率
（3）为network alarm thresholds确定正确的值
（4）找出网络中的问题
（5）预警未来的问题

基线化的目标：
1.确定网络设备的当前状态
2.和标准性能guidelines比较当前状态
3.设定边界使状态超过guideline时产生报警信息
网络核心是进行基线化最符合逻辑也是最有用的位置。

进行基线化的步骤（以CPU利用率为例）：
第一步：编写产品列表（设备名称、类型、版本、软件版本）
第二步：确定当前设备支的SNMP MIB

具体设备支持的对象定义：http://www.cisco.com/public/mibs

MIB OID（Object identifier）ftp://ftp.cisco.com/pub/mibs/oid

cisco支持CPU利用率的OID
ftp://ftp.cisco.com/pub/mibs/oid/CISCO-PROCESS-MIB.oid
"cpmCPUTotal5sec"  "1.3.6.1.4.1.9.9.109.1.1.1.1.3"
"cpmCPUTotal1min"  "1.3.6.1.4.1.9.9.109.1.1.1.1.4"
"cpmCPUTotal5min"  "1.3.6.1.4.1.9.9.109.1.1.1.1.5"
具体检查一个MIB OID（Object identifier）是否可用
http://net-snmp.sourceforge.net工具：
snmpwalk -v1 -c private [设备IP] 1.3.6.1.4.1.9.9.109.1.1.1.1.5
snmpwalk -v1 -c private

第三步：从设备读取并记录特定SNMP MIB对象
有许多工具可用来读取SNMP MIB信息，这些工具都使用snmp get程序来获取这些信息。
现在已经知道设备支持哪些OID，接下来要决定多长时间间隔检查并记录一遍。Cisco建议CPU

MIB每5分钟一次。基线的建立通常需要两个星期以上的时间。
挑选出需要的MIB OID，用snmpget每隔相应的时间读取一遍，将其保存在相应文件中留待以后分

析使用。
第四步：分析数据以确定界限threshold
现在已经有数据了，接下来可以开始分析它。有许多方法可以用来处理数据，电子表格（如：

excel）是一种比较方便的方法。
图表（scatter chart）可以更容易的观察到不同的threshold将如何在网络上工作。在excel中

创建图表：选中某一列，点击图表向导（chart wizard）图标。
现在能够使用图表进行分析了，然而，在进行分析之前，应该明白下面的问题：
1、厂家如何建议某个MIB变量的threshold
通常cisco建议核心路由器的CPU利用率不应超过60%，因为路由协议的重新计算和重新汇聚

（recalculate and recoverge）大约需要40%的CPU利用率。这个百分比具体基于网络使用的协议，拓扑

以及网络的稳定性。
2、如果使用60%作为threshold要怎么分析
通过图表观察，找到接近或超过界限的时间断，查明原因，做出预案。
3、对多个不同的设备应选择不同的threshold。

还应确定到达某个界限采取的行动，如：
45%--〉Ready--〉到达这个界限时，应为下一步做好准备。
50%--〉Set --〉开始为维修、重配置或升级做准备。
60%--〉Go --〉设备或网络错误已经发生，采取行动。
第五步：修复当前识别出来的问题
当发现某个设备超过了Go threshold，应该执行一个行动计划使这个设备回到threshold界限下
某些ACLs可能使设备CPU利用率显著上升，有时可以考虑控制某些流量到其它路径上。不论用什

么方法，必须将所有设备的CPU利用率降到threshold以下。
第六步：Test Threshold Monitoring
第一种方法：使用SNMP平台或其它SNMP监控工具
这种方法使用更多的网络带宽支持polling traffic and take up processing cycle on your

SNMP platform。
第二种方法：在路由器上配置Remote Monitoring(RMON)Alarm和Event。
这种方法减少了网络带宽的使用，但是也增加路由器的内存和CPU利用率。

To use the Ready, Set, Go method, use all of the following configuration statements.

rmon event 1 trap private description "cpu hit60%" owner jharp
rmon event 2 trap private description "cpu recovered" owner jharp
rmon alarm 10 cpmCPUTotalTable.1.5.1 300 absolute rising 60 1 falling 40 2 owner jharp

rmon event 3 trap private description "cpu hit50%" owner jharp
rmon event 4 trap private description "cpu recovered" owner jharp
rmon alarm 20 cpmCPUTotalTable.1.5.1 300 absolute rising 50 3 falling 40 4 owner jharp

rmon event 5 trap private description "cpu hit 45%" owner jharp
rmon event 6 trap private description "cpu recovered" owner jharp
rmon alarm 30 cpmCPUTotalTable.1.5.1 300 absolute rising 45 5 falling 40 6 owner jharp

The following example shows the output of the show rmon alarm command that was configured by

the above statements.

zack#sh rmon alarm

第七步：用SNMP或RMON实现Threshold Monitoring
了解了CPU利用率基线的建立过程，接下来可以用同样的方法对网络中其它重要的MIB变量例如：

buffer,free memory,cyclic redundancy check(CRC) errors,AMT cell loss,等建立基线。
如果使用RMON alarm and event配置，就可以停止NMS station的轮巡检测（polling）了。

Additional MIBs
After you have learned this process, you may want to investigate other MIBs to baseline and

monitor. The following subsections present a brief list of some OIDs and descriptions that

you may find useful.

Router MIBs
Memory characteristics are very helpful in determining the health of a router. A healthy

router should almost always have available buffer space with which to work. If the router

begins to run out of buffer space, the CPU will have to work harder to create new buffers

and to try to find buffers for incoming and outgoing packets. An in-depth discussion of

buffers is beyond the scope of this document. However, as a general rule, a healthy router

should have very few, if any, buffer misses and should not have any buffer failures, or a

zero free memory condition.

Object
Description
OID

ciscoMemoryPoolFree
The number of bytes from the memory pool that are currently unused on the managed device
1.3.6.1.4.1.9.9.48.1.1.1.6

ciscoMemoryPoolLargestFree
The largest number of contiguous bytes from the memory pool that are currently unused
1.3.6.1.4.1.9.9.48.1.1.1.7

bufferElMiss
The number of buffer element misses
1.3.6.1.4.1.9.2.1.12

bufferFail
The number of buffer allocation failures
1.3.6.1.4.1.9.2.1.46

bufferNoMem
The number of buffer create failures due to no free memory
1.3.6.1.4.1.9.2.1.47

Catalyst Switch MIBs
Object
Description
OID

cpmCPUTotal5min
Overall CPU busy percentage in the last five-minute period. This object deprecates the

avgBusy5 object from the OLD-CISCO-SYSTEM-MIB
1.3.6.1.4.1.9.9.109.1.1.1.5

cpmCPUTotal5sec
Overall CPU busy percentage in the last five-second period. This object obsolesces the

busyPer object from the OLD-CISCO-SYSTEM-MIB
1.3.6.1.4.1.9.9.109.1.1.1.3

sysTraffic
The percentage of bandwidth utilization for the previous polling interval
1.3.6.1.4.1.9.5.1.1.8

sysTrafficPeak
The peak traffic meter value since the last time the port counters were cleared or the

system sarted
1.3.6.1.4.1.9.5.1.1.19

sysTrafficPeaktime
The time (in hundredths of a second) since the peak traffic meter value occurred
1.3.6.1.4.1.9.5.1.1.20

portTopNUtilization
Utilization of the port in the system
1.3.6.1.4.1.9.5.1.20.2.1.4

portTopNBufferOverFlow
The number of buffer overflows of the port in the system
1.3.6.1.4.1.9.5.1.20.2.1.10

Serial Link MIBs
Object
Description
OID

locIfInputQueueDrops
The number of packets dropped because the input queue was full
1.3.6.1.4.1.9.2.2.1.1.26

locIfOutputQueueDrops
The number of packets dropped because the output queue was full
1.3.6.1.4.1.9.2.2.1.1.27

locIfInCRC
The number of input packets that had cyclic redundancy checksum errors
1.3.6.1.4.1.9.2.2.1.1.12

RMON Alarm and Event 配置命令
Alarms
RMON alarms can be configured with the following syntax:

rmon alarm number variable interval {delta | absolute} rising-threshold value
[event-number] falling-threshold value [event-number]
[owner string]

Element
Description

number
The alarm number, which is identical to the alarmIndex in the alarmTable in the RMON MIB.

variable
The MIB object to monitor, which translates into the alarmVariable used in the alarmTable

of the RMON MIB.

interval
The time, in seconds, the alarm monitors the MIB variable, which is identical to the

alarmInterval used in the alarmTable of the RMON MIB.

delta
Tests the change between MIB variables, which affects the alarmSampleType in the alarmTable

of the RMON MIB.

absolute
Tests each MIB variable directly, which affects the alarmSampleType in the alarmTable of

the RMON MIB.

rising-threshold value
The value at which the alarm is triggered.

event-number
(Optional) The event number to trigger when the rising or falling threshold exceeds its

limit. This value is identical to the alarmRisingEventIndex or the alarmFallingEventIndex in

the alarmTable of the RMON MIB.

falling-threshold value
The value at which the alarm is reset.

owner string
(Optional) Specifies an owner for the alarm, which is identical to the alarmOwner in the

alarmTable of the RMON MIB.

Events
RMON events can be configured with the following syntax:

rmon event number [log] [trap community] [description string]
[owner string]

Element
Description

number
Assigned event number, which is identical to the eventIndex in the eventTable in the RMON

MIB.

log
(Optional) Generates an RMON log entry when the event is triggered and sets the eventType

in the RMON MIB to log or log-and-trap.

trap community
(Optional) SNMP community string used for this trap. Configures the setting of the

eventType in the RMON MIB for this row as either snmp-trap or log-and-trap. This value is

identical to the eventCommunityValue in the eventTable in the RMON MIB.

description string
(Optional) Specifies a description of the event, which is identical to the event

description in the eventTable of the RMON MIB.

owner string
(Optional) Owner of this event, which is identical to the eventOwner in the eventTable of

the RMON MIB.

关于实现RMON Alarm和Event的细节信息参见Network Management Systems Best Practices white paper

：

http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a00800aea9c.shtml#r

eference1

- 作者： macob 2005年05月18日, 星期三 17:55　回复（0） |　引用（1）加入博采

醒酒

轻风揽月就云裳

冷雨披霜弄清晨

菱花回忆已旧年

危栏独椅臆新人

- 作者： macob 2005年11月24日, 星期四 10:08　回复（0） |　引用（1）加入博采

入侵检测系统之日志检测详解- -

1.概述

入侵检测（Intrusion Detection），顾名思义，便是对入侵行为的发觉。它通过对计算机网络或计算机系统中的若干关键点收集信息并对其进行分析，从中发现网络或系统中是否有违反安全策略的行为和被攻击的迹象。进行入侵检测的软件与硬件的组合便是入侵检测系统 /a>（Intrusion Detection System,简称 IDS ）。与其他安全产品不同的是，入侵检测系统需要更多的智能，它必须可以将得到的数据进行分析，并得出有用的结果。一个合格的入侵检测系统能大大的简化管理员的工作，保证网络安全的运行。

　　日志是使系统顺利运行的重要保障。它会告诉我们系统发生了什么和什么没有发生。然而，由于日志记录增加得太快了，铺天盖地的日志使系统管理员茫然无措，最终使日志成为浪费大量磁盘空间的垃圾。日志具有无可替代的价值，但不幸的是它们经常被忽略，因为系统管理员在并不充裕的时间里难以查看大量的信息。标准的日志功能不能自动过滤和检查日志记录，并提供系统管理员所需要的信息。

　　对于入侵者来说，要做的第一件事就是清除入侵的痕迹。这需要入侵者获得root权限，而一旦系统日志被修改，就无法追查到攻击的情况。因此，好的系统管理员应该建立日志文件检测。有很多工具可以实现日志检测的功能，其中就有Logcheck和Swatch。本文将对Logcheck和Swatch逐一进行介绍。

2.日志文件系统

　　审计和日志功能对于系统来说是非常重要的，可以把感兴趣的操作都记录下来，供分析和检查。UNIX采用了syslog工具来实现此功能，如果配置正确的话，所有在主机上发生的事情都会被记录下来，不管是好的还是坏的。

　　Syslog已被许多日志系统采纳，它用在许多保护措施中--任何程序都可以通过syslog记录事件。Syslog可以记录系统事件，可以写到一个文件或设备中，或给用户发送一个信息。它能记录本地事件或通过网络纪录另一个主机上的事件。

　　Syslog依据两个重要的文件：/sbin/syslogd（守护进程）和/etc/syslog.conf配置文件，习惯上，多数syslog信息被写到/var/adm或/var/log目录下的信息文件中（messages.*）。一个典型的syslog纪录包括生成程序的名字和一个文本信息。它还包括一个设备和一个行为级别（但不在日志中出现）。

　 /etc/syslog.conf的一般格式如下

　设备.行为级别 [；设备.行为级别]　记录行为　　　　

　　设备　　　　　　　　　　描述

　　auth　　　　　　　　认证系统：login、su、getty等，即询问用户名和口令

　　authpriv　　　　　　同LOG_AUTH，但只登录到所选择的单个用户可读的文件中

　　cron　　　　　　　　 cron守护进程

　　daemon　　　　　　　其他系统守护进程，如routed

　　kern　　　　　　　　内核产生的消息

　　lpr　　　　　　　　打印机系统：lpr、lpd

　　mail　　　　　　　　电子邮件系统

　　news　　　　　　　　网络新闻系统

　　syslog　　　　　　　由syslogd产生的内部消息

　　user　　　　　　　　随机用户进程产生的消息

　　uucp　　　　　　　　UUCP子系统

　　local0~local7　　为本地使用保留

　行为级别　　　　　　　描述

　　debug　　　　　　　包含调试的信息，通常旨在调试一个程序时使用

　　info　　　　　　　　情报信息

　　notice　　　　　　不是错误情况，但是可能需要处理

　　warn(warning)　　警告信息

　　err(error)　　　　错误信息

　　crit　　　　　　　　重要情况，如硬盘错误

　　alert　　　　　　　应该被立即改正的问题，如系统数据库破坏

　　emerg(panic)　　　紧急情况

　　记录行为（举例）　　　　描述

　　/dev/console　　　　发送消息到控制台

　　/var/adm/messages　　把消息写到文件/var/adm/messages

　　@loghost　　　　　把消息发到其它的日志记录服务器

　　fred,user1　　　　　传送消息给用户

　　*　　　　　　　　　传送消息给所有的在线用户

　　有个小命令logger为syslog系统日志文件提供一个shell命令接口，使用户能创建日志文件中的条目。用法：logger 例如：logger This is a test！　　

　　它将产生一个如下的syslog纪录：Apr 26 11:22:34 only_you: This is a test!

3.Logcheck

　　3.1 logcheck介绍

　　Logcheck是一软件包，用来实现自动检查日志文件，以发现安全入侵和不正常的活动。Logcheck用logtail程序来记录读到的日志文件的位置，下一次运行的时候从记录下的位置开始处理新的信息。所有的源代码都是公开的，实现方法也非常简单。

　　Logcheck SHELL脚本和logtail.c程序用关键字查找的方法进行日志检测。在这儿提到的关键字就是指在日志文件中出现的关键字，会触发向系统管理员发的报警信息。Logcheck的配置文件自带了缺省的关键字，适用于大多数的*inx系统。但是最好还是自己检查一下配置文件，看看自带的关键字是否符合自己的需要。

　　Logcheck脚本是简单的SHELL程序，logtail.c程序只调用了标准的ANSI C函数。Logcheck要在cron守护进程中配置，至少要每小时运行一次。脚本用简单的grep命令来从日志文件检查不正常的活动，如果发现了就发MAIL给管理员。如果没有发现异常活动，就不会收到MAIL。

　　3.2 安装和配置logcheck

　　3.2.1 下载Logcheck

　　下载网址下载后放在/backup目录

　　3.2.2 安装

　　以root用户身份登录，

　　[root@only_you /root]# tar zxvf /backup/logcheck-1.1.1.tar.gz

　　[root@only_you /root]# cd logcheck-1.1.1

　　[root@only_you logcheck-1.1.1] make linux file://在Linux平台下使用

　　make install SYSTYPE=linux file://缺省安装目录是/usr/local/etc

　　make[1]: Entering directory `/root/logcheck-1.1.1'

　　Making linux

　　cc -O -o ./src/logtail ./src/logtail.c

　　Creating temp directory /usr/local/etc/tmp file://在/usr/local/etc下创建目录tmp

　　Setting temp directory permissions

　　chmod 700 /usr/local/etc/tmp

　　Copying files

　　cp ./systems/linux/logcheck.hacking /usr/local/etc file://拷贝文件到/usr/local/etc目录

　　cp ./systems/linux/logcheck.violations /usr/local/etc

　　cp ./systems/linux/logcheck.violations.ignore /usr/local/etc

　　cp ./systems/linux/logcheck.ignore /usr/local/etc

　　cp ./systems/linux/logcheck.sh /usr/local/etc

　　cp ./src/logtail /usr/local/bin file://把logtail程序拷贝到/usr/local/bin目录

　　Setting permissions

　　chmod 700 /usr/local/etc/logcheck.sh file://logcheck的脚本

　　chmod 700 /usr/local/bin/logtail file://修改文件访问权限，确认只有root用户才能操作

　　chmod 600 /usr/local/etc/logcheck.violations.ignore　file://不同的配置文件

　　chmod 600 /usr/local/etc/logcheck.violations

　　chmod 600 /usr/local/etc/logcheck.hacking

　　 3.2.3 程序文件介绍

　　logcheck.sh 主脚本文件。控制所有的处理过程，用grep命令检查日志文件，发现问题报告系统管理员。由cron定时启动

　　logtail 记录日志文件上次处理到的位置。被logcheck程序调用，避免重复处理已处理过的日志文件。所有的日志文件都由此程序处理，在同一目录下会产生文件######.offset，其中######是检查的日志文件名。文件中记录了logtail开始处理的偏移量，如果删除掉，则从文件开始处进行处理。Logcheck跟踪日志文件的inode号和文件大小，如果inode号发生变化，或者是文件大小比上次运行时的小， logtail会重置偏移量，处理整个文件

　　Logcheck.hacking 文件中包含了系统受到攻击时的关键字。这个文件的关键字比较稀少，除非能知道某种特定的攻击方式的特征。缺省的关键字是ＩＳＳ（Internet Security Scanner）攻击产生的，或者是sendmail中的地址栏里的非法语法。在日志文件中找到了关键字就会给管理员发信。

　　logcheck.violations 文件中包含了产生否定或拒绝信息的系统事件。如denied，refused等。
　　 logcheck.violations.ignore　文件中包含了要对logcheck.violations进行反向查找的关键字。

　　3.2.4 配置

　　为了使logcheck运行正常，先要对syslog.conf进行配置，你应该根据自己的需要进行配置，下面给出的只是一个例子

　　把下面的内容加到/etc/syslog.conf中

　　#记录mail，news以外的消息

　　*.*;mail.none;news.none -/var/log/messages

　　#记录认证请求

　　auth.*;authpriv.* /var/log/authlog

　　#记录所有的内核消息

　　kern.* /var/log/kernlog

　　#记录警告和错误消息

　　*.warn;*.err /var/log/syslog

　　这四个文件/var/log/messages，/var/log/authlog，/var/log/kernlog，/var/log/syslog也就是logcheck要检查的日志文件

　　重起syslog，［root@only_you］#/etc/rc.d/init.d/syslog restart　　

　　用编辑器（vi等）打开文件/usr/local/etc/logcheck.sh，在其中会找到下面的内容

　　# Linux Red Hat Version 3.x, 4.x

　　$LOGTAIL /var/log/messages > $TMPDIR/check.$

　　$LOGTAIL /var/log/secure >> $TMPDIR/check.$

　　$LOGTAIL /var/log/maillog >> $TMPDIR/check.$

　　这是logcheck自带的内容，也就是logcheck要检查的日志文件，把它该为下面的内容，使之于syslog.conf的内相一致：（应该根据你配置的syslog.conf进行修改）

　　$LOGTAIL /var/log/messages > $TMPDIR/check.$

　　$LOGTAIL /var/log/authlog >> $TMPDIR/check.$

　　$LOGTAIL /var/log/kernlog >> $TMPDIR/check.$

　　$LOGTAIL /var/log/syslog >> $TMPDIR/check.$

　　还可以找到一行为　SYSADMIN=root，指的是发邮件时的收信人，缺省为root@localhost，本机的root用户，如果机器与Internet相连，也可以指定真实的帐号，我就把它改为了only_you@linuxaid.com.cn，这样就可以随时收到邮件了，不须用root帐号登录到linux机器上去。

　　在/etc/crontab中增加一项，让cron定时启动logcheck。关于cron的用法请参考相应文档。

　　00,10,20,30,40,50 * * * * root /usr/local/etc/logcheck.sh

　　每10分钟运行一次

　　3.2.5 测试

　　都配置好了，试试效果如何吧。登录一下，故意输错口令，看看有什么事情发生。１０分钟以后，我的only_you@linuxaid.com.cn信箱真的收到了一封信，信的内容大致如下

　　Apr 26 13:51:13 only_you -- wap[1068]: LOGIN ON pts/1 BY wap FROM *.*.*.*

　　Apr 26 13:51:24 only_you PAM_unix[1092]: authentication failure; wap(uid=500) -> root for system-auth service

　　刚装好不长时间，logcheck就报告有人试图登录到我的机器上来，不知道这位IP为211.69.197.1的朋友想干什么？

　　Security Violations

　　=-=-=-=-=-=-=-=-=-=

　　Apr 26 15:30:53 only_you xinetd[528]: refused connect from 211.69.197.1

　　Unusual System Events

　　=-=-=-=-=-=-=-=-=-=-=

　　Apr 26 15:30:53 only_you xinetd[528]: refused connect from 211.69.197.1

　　Apr 26 15:30:53 only_you xinetd[528]: FAIL: ftp libwrap from=211.69.197.1

　　Apr 26 15:40:00 only_you CROND[1388]: (root) CMD (/usr/local/etc/logcheck.sh)

　　Apr 26 15:40:00 only_you CROND[1390]: (root) CMD ( /sbin/rmmod -as)

　　Apr 26 15:30:53 only_you xinetd[528]: FAIL: ftp libwrap from=211.69.197.1

4.swatch

　　SWATCH (The Simple WATCHer and filer) 是Todd Atkins开发的用于实时监视日志的PERL程序。Swatch利用指定的触发器监视日志记录，当日志记录符合触发器条件时，swatch会按预先定义好的方式通知系统管理员。

　　Swatch非常容易安装。它是一个PERL程序，无需编译。Swatch有一个很有用的安装脚本，将所有的库文件、手册页和PERL文件复制到相应目录下。安装完成后，只要创建一个配置文件，就可以运行程序了。Swatch的下载网址,最新的版本为3.0.1 。下载后也放到了/backup目录。

　　4.1 安装

　　以root用户身份登录，

　　[root@only_you /root]# tar zxvf /backup/swatch-3.0.1.tar.gz

　　[root@only_you /root]# cd swatch-3.0.1

　　现在的版本需要perl 5和Time::HiRes, Date::Calc,Date::Format, file::Tail.模块，系统自带的perl可能不包括，没关系，它的安装程序会自己到网上去找

　　[root@only_you swatch-3.0.1]# perl Makefile.PL

　　系统提示HiRes 1.12模块没有安装，询问是否安装，回答y，

　　接着系统提示Are you ready for manual configuration? [yes]

　　敲n就会自动配置，然后它自己到网上去装东西，具体在干什么我也不清楚了。装完这个又说缺别的东西，还是让它自己去装。试着执行一下./swatch，如果没有错误信息就说明安装成功了。

　　 4.2 配置swatchrc

　　swathrc文件的格式如下

　　# Bad login attempts

　　watchfor /INVALID　REPEATED　INCOMPLETE/

　　echo

　　bell 3

　　mail=only_you@linuxaid.com.cn

　　# Machine room temperature

　　watchfor /WizMON/

　　echo inverse

　　bell

　　watchfor后跟/pattern/，其中的"pattern"代表一个swatch将要进行搜索匹配的正则表达式，也就是我们的触发器，下面紧跟的以“Tab”开头的是当表达式匹配时所要执行的动作，Swatch允许指定包括显示、email、呼叫或任何指定的执行文件。上面第一个watchfor的含义是找到/INVALID　REPEATED　INCOMPLETE/后把信息显示到屏幕上，响铃，同时向only_you@linuxaid.com.cn发MAIL。详细的正则表达式的格式请参考相应的文档

　　缺省情况下，swatch认为swatchrc文件为~/.swatchrc，可以通过运行时指定参数来改变，如果未找到swatchrc文件，则使用缺省的配置

　　watchfor = /.*/

　　echo = random

　　4.3 测试

　　Swatch启动时可以带很多参数，但使用通常如下格式启动它就可以了：

　　/usr/local/bin/swatch -c /var/log/syslogrc -t /var/log/syslog &

　　-c参数用于指定配置文件，-t参数指定实时监视的日志文件，"&"使swatch在后台运行。启动后，swatch产生子进程，因此swatch是以两个进程运行的，在停止swatch时必须杀掉两个进程。

　　-t参数是用tail Cf filename，从文件的末尾开始查找，如果想查找整个文件，则应该使用-f filename。

　　现在让我们来实验一下，在swatch程序所在的目录下建立swatchrc文件，内容如下：

　　watchfor = /FAILED/

　　echo=random

　　执行./swatch Cc swatchrc Cf /var/log/authlog，所有登录失败的记录就会显示出来，并且还用不同的颜色来显示。

　　Apr 26 17:43:34 only_you login[2344]: FAILED LOGIN 1 FROM cjm FOR dsf, Authentication failure

　　Apr 27 09:55:50 only_you login[932]: FAILED LOGIN 1 FROM (null) FOR root, Authentication failure

5.总结

　　日志是很强大的工具，然而它的大量数据也很容易淹没我们。如果我们没有足够的时间去检查数以兆计的数据时，很可能会忽略那些有用的资料。日志自动检测系统可以帮助我们解决这个问题。这些自动检测系统将我们所需要的信息实时地通知我们。希望本文能对如何定制你自己的日志文件自动检测系统有一定的帮助。

- 作者： shuitongal 访问统计： 7　2005年07月26日, 星期二 12:12

- 作者： macob 2005年11月18日, 星期五 07:41　回复（0） |　引用（1）加入博采

已锁定

此日志的浏览权限已被作者锁定，请同作者联系，发送短消息,如果你的身份符合作者的要求，点击此处可以进行浏览

- 作者： macob 2005年11月13日, 星期日 19:07　回复（0） |　引用1）加入博采

无状态静态过滤器的缺陷

static packet filters, such as IPChains, evaluated each packet independently and did not track state. The presence of the ACK bit made it appear that I had initiated the connection and the ACK was the response. Without a stateful firewall in place, reconnaissance of my machine was relatively easy.

- 作者： macob 2005年11月11日, 星期五 10:22　回复（0） |　引用（1）加入博采

已锁定

此日志的浏览权限已被作者锁定，请同作者联系，发送短消息,如果你的身份符合作者的要求，点击此处可以进行浏览

- 作者： macob 2005年11月5日, 星期六 19:17　回复（0） |　引用（1）加入博采

Bro：一个开放源码的高级NIDS系统

创建时间：2003-10-12
文章属性：原创
文章提交：stardust (stardust_at_xfocus.org)

在介绍Bro之前先总结一下几个常见的开放源码NIDS系统：

Snort ( http://www.snort.org/ )
目前最著名最活跃的开放源码NIDS项目，定位于轻量级的入侵检测系统，已经实现了网络探测器和许多第三方的管理及日志分析工具，广泛使用在对检测准确性要求不高的非高速网络环境下。对其进行介绍及分析资料辅天盖地，国内当前大多数的IDS产品都是在其基础上修改出来的。Snort的成功之处在于其高效的整体设计编码、简洁明了的规则描述设计及已经成一定规模的攻击检测规则集，它的规则集已经被很多其他开放源码IDS项目所兼容。

Prelude IDS ( http://www.prelude-ids.org/ )
目前比较活跃的开放源码混和IDS项目，比较注重IDS各组件的模块化设计，组件之间使用标准IDMEF格式进行通讯，从设计的方式来看定位于适应大型网络的需求，当前已经实现了网络探测器、日志分析器、告警信息集中查看分析工具。其网络探测器部分基本上翻版了Snort的功能，完全兼容Snort的规则集。

Firestorm ( http://www.scaramanga.co.uk/firestorm/index.html )
不太出名的开放源码NIDS项目，目前仅实现了探测器部分，完全兼容Snort的规则集，功能上也基本上差不多，可以把告警信息记录到Prelude IDS的管理器，但自称性能上比Snort强很多。

NetSTAT ( http://www.cs.ucsb.edu/~rsg/STAT/ )
一个学术界的开放源码的IDS项目，基于STAT(State Transition Analysis Technique，状态迁移分析技术)描述攻击的研究成果，使用特有的STATL语言描述攻击，攻击描述文本被STATL解释工具转换为C++代码编译进检测引擎来实现检测功能，目前已经发布了STATL语言解释转换工具及一个基本的示例网络探测器部分(很少的几个检测功能例子)。要熟练使用这个IDS工具需要比较强的编程功底，但用此IDS可以实现很复杂的检测功能。

可以看到当前大多数开放源码的NIDS项目都以Snort为基础，还有一些主要用于学术研究的IDS(比如NetSTAT)，Snort是用于了解NIDS技术的很好入门方式，学术领域的IDS主要用于验证某些思想概念的可行性，这类IDS一般实现使用复杂，注重检测的严谨准确，如果商业化还需要很大的努力。Snort实现简单，使用方便，但本质上只是一个可以匹配分析数据包payload的嗅探器而已，对于有丰富网络知识的网管来说是个称手的网络流量过滤分析工具。由于只能对TCP/UDP/ICMP数据包的payload及某些数据包属性做些简单的匹配操作，而且没有特定的规则关联机制，Snort对于攻击的检测只能是粗线条的。当前的主流商业NIDS产品已经普遍采用细致的应用层协议分析技术，应用层协议分析技术不仅能够极大地提高检测准确性和效率，更能带来基于协议分析的异常检测能力，基于规则类似病毒检测的方式只能检测已知攻击，而基于异常分析的检测却可能检测到某些未知攻击，这点是新NIDS产品的发展热点和方向，基于异常并结合误用的IDS产品将会是未来IDS/IPS产品的主流。Snort虽然对一些应用层协议如HTTP、PORTMAP、TELNET做了些简单的解码和处理，这些处理只是对匹配做的一些优化，远没有到协议分析的程度，Snort与当今主流IDS产品的差距越来越大，相对而言越来越落后，学习参考的价值越来越少。是不是存在技术上更有意思的开放源码的NIDS项目呢，我注意到了一个叫Bro的NIDS软件，它几乎提供了一切所希望见到的特性。

下面介绍一下Bro ( http://www.icir.org/vern/bro-info.html )，本文旨在分析Bro本身提供的一些很有意思且很有用的功能特性，不对其如何安装、配置、使用做介绍，那部分的内容可以参考软件包中的相关说明。

Bro是一个Vern Paxson实现的实时网络入侵检测软件，于98年对外发布，BSD license，它的最初设计目标是实现一个在100M网络下实告警、机制与策略分离、高可扩展性的入侵检测及网络监视审计系统。

Bro的系统结构如下图示：

                      | 下发          ^ 实时
                      V 策略          | 告警
                   +-----------------------------+
                   |        策略脚本解释器       |
                   +-----------------------------+
                    | 事件  | 规则       ^ 事件
                    V 控制  | 控制       | 流
                   +--------+--------------------+
              规则 +--------V-+                  |
             ----->| 规则引擎 |   事件生成引擎   |
                   +----------+                  |
                   +-----------------------------+
                      | Tcpdump       ^ 过滤出
                      V 过滤器        | 的流量
                   +-----------------------------+
                   |          libpcap            |
                   +-----------------------------+
                                 ^
                                 | 网络数据包
                   +-----------------------------+
                   |           网络              |
                   +-----------------------------+


Bro的设计实现遵循分层的原则，利用libpcap从网络上获取的数据包经过事件生成引擎和规则引擎被抽象成一系列的事件，这些事件被策略脚本做进一步的深入分析，基本事件本身就可以触发告警，策略脚本分析基本事件以后既可以生成新的事件也可以触发告警。如下详细描述各个组件的功能，对于Bro提供的高级功能特性分析会穿插其间：

$ libpcap

Bro使用libpcap库来获取网络数据包，这样可以使Bro忽略具体的链路层细节，从而获得最大的可移植性。当前Bro支持FreeBSD、Solaris、Linux、Digital Unix等操作系统。

libpcap从上层的事件生成引擎获得Tcpdump格式的网络流量过滤器，从网卡上过滤出Bro感兴趣的那部分流量做进一步的分析。比如“tcp port 80 or port 23”这个过滤器会从网络上过滤出源目的源口为80或23的TCP数据包做分析，也就是分析目标是HTTP和TELNET协议相关的数据包。

$ 事件生成引擎

从libpcap获取的数据包经过事件生成引擎，引擎首先对数据包头做些合法性检查，生成一系列事件，比如引擎收到一个TCP包会先检查TCP头的checksum是否正确，检查通过以后引擎检查包头的标记位，如果是SYN标记引擎会启动一个定时器并生成一个connection_attempt事件，当引擎再收到一个对方的确认包时，引擎会关掉定时器并生成一个connection_established事件，如果收到一个RST包，引擎则会生成一个connection_rejected事件。这些事件都会被提交给上层的策略脚本解释器，如果用户关心这些事件可以编写策略脚本定义相应的事件处理例程来处理。

在这一层，Bro还会对于一些应用层协议做更深层次的分析，比如对于HTTP协议，引擎会进一步分析数据包是请求还是回应、访问的对象、请求的方法等信息并生成相应的事件，比如http_request事件并包含了相关的数据字段。目前的最新版本软件支持FINGER、FTP、HTTP、IDENT、PORTMAP、SMTP等应用层协议的分析，随着软件的开发会有更多的应用层协议分析加入进来，Bro在这一层上实现了应用层的协议分析并向上层策略脚本解释器提供抽象出来的事件。

$ 策略脚本解释器

Bro的策略脚本用于对事件生成引擎生成的事件进行分析处理，如果发现攻击特征引发相应的操作比如告警、记录或生成新的事件。Bro的策略脚本是用Bro语言编写的类似NFR N-Code的全功能解释执行的分析脚本，Bro语言提供了丰富的数据类型、流程控制手段及许多有用的分析函数，从实现上功能上与N-Code非常相似甚至有过之。如此功能强大的脚本语言可以对抽象出来的事件做充分细致的分析，组合Bro事件生成引擎中应用层协议分析和Bro脚本的分析能力可以提供非常准确强大的入侵检测功能。

下面分析一个检测某些恶意HTTP请求的Bro脚本：

------------------------------------------------------------------------------
# $Id: http-request.bro,v 1.14 2003/08/31 00:40:21 vern Exp $

# Analysis of HTTP requests.

@load http  # 装入此脚本依赖的http.bro脚本。

redef capture_filters +=  {
    ["http-request"] = "tcp dst port 80 or tcp dst port 8080 or tcp dst port 8000"
};  # 定义过滤HTTP协议相关流量的tcpdump过滤器

const sensitive_URIs =
      /etc.*\/.*(passwd|shadow|netconfig)/
    | /IFS[ \t]*=/
    | /nph-test-cgi\?/
    | /(%0a|\.\.)\/(bin|etc|usr|tmp)/
    | /[iI][iI][sS][aA][dD][mM][pP][wW][dD]/
    | /\/(cmd|root|tftp)\.exe/
    | /\/Admin_files\/order\.log/
    | /\/carbo\.dll/
    | /\/cgi-bin\/(phf|php\.cgi|test-cgi)/
    | /\/cgi-dos\/args\.bat/
    | /\/cgi-win\/uploader\.exe/
    | /\/search97\.vts/
    &redef;  # 用正则表达式定义一些常见的恶意HTTP请求

# URIs that match sensitive_URIs but can be generated by worms, and hence
# should not be flagged (because they're so common).
const worm_URIs =
  &bsp;   /.*\/c\+dir/
    | /.*cool.dll.*/
    | /.*Admin.dll.*Admin.dll.*/
    &redef; # 定义ssl-worm相关的几个请求

# URIs that should not be considered sensitive if accessed remotely,
# i.e. by a local client.
const skip_remote_sensitive_URIs: pattern &redef;
# In order to redef skip_remote_sensitive_URIs, you have to also
# redef the following to T, because there's currently no way in Bro
# to specify an empty pattern that can otherwise be used as the default
# for skip_remote_sensitive_URIs.
const have_skip_remote_sensitive_URIs = F &redef;

const sensitive_post_URIs = /wwwroot/ &redef;

event http_request(c: connection, method: string, original_URI: string,  # http_request事件的处理
            unescaped_URI: string, version: string)          # 例程，对同一事件可以定
    {                                                                # 义多个不同的处理例程。
    local log_it = F;                                                # 事件生成引擎随同事件提
    local URI = unescaped_URI;                                       # 供了相关的连接情况、请
                                                                         # 求方法、请求的URI等字
                                                                         # 段信息。

    if ( (sensitive_URIs in URI && URI != worm_URIs) ||              # 如果URI中包含了某些恶意
         (method == "POST" && sensitive_post_URIs in URI) )          # 请求。
        {
        if ( have_skip_remote_sensitive_URIs &&                  # 排除某些不需关心的情况。
             is_local_addr(c$id$orig_h) &&
             skip_remote_sensitive_URIs in URI )
            ; # don't flag it after all
        else
            log_it = T;                                      # 设置记录标记。
        }

    local s = lookup_http_request_stream(c);                         # 查找此连接相关的HTTP
                                                                         # 信息，如果不存在，则
                                                                         # 创建一个此网络连接相
                                                                         # 关的HTTP信息。lookup
                                                                         # _http_request_stream
                                                                         # 函数在http.bro脚本中
                                                                         # 定义。

    if ( process_HTTP_replies )                     &bsp;                # 如果还要处理HTTP请求
                                                                     # 的回应。
        {
        # To process HTTP replies, we need to record the corresponding
        # requests.
        local n = s$first_pending_request + s$num_pending_requests; # 获取此连接相关的HTTP
                                                                    # 信息的索引号。

        s$requests[n] = [$method=method, $URI=URI, $log_it=log_it]; # 存储相关的HTTP信息到
                                                                    # 索引号指向的记录。
        ++s$num_pending_requests;

        # if process_HTTP_messages
        local msg = s$next_request;

        init_http_message(msg);   # 初始化pending HTTP请求队列下一个记录的信息。
                                  # init_http_message函数在http.bro脚本中定义。
        msg$initiated = T;
        }
    else
        {
        if ( log_it )             # 做记录。
            ALERT([$alert=HTTP_SensitiveURI, $conn=c,
                $msg=fmt("%s %s: %s %s",
                    id_string(c$id), c$addl, method, URI)]);
        print http_log,
            fmt("%.6f %s %s %s", network_time(), s$id, method, URI);
        }
    }
------------------------------------------------------------------------------

Bro策略脚本的编写需要不少时间和精力的投入，Bro的作者提供了完整的使用手册，包括各种特定数据类型的说明、引擎本身支持的函数说明、如何使用的示例，用户经过一定时间的学习可以完全掌握。

$ 规则引擎

规则引擎是新近Bro 0.8版本加入的一个组件功能，此功能允许用户把一些数据包特征定义成简单的规则，事件生成引擎根据规则匹配网络数据包生成相应的事件，这些事件可能直接导致告警信息的产生，也有可能被策略脚本作进一步的分析形成高级别的告警。

与Snort的规则相比，Bro的规则不仅格式不同，而且提供了Snort规则所不具备的高级功能：匹配正则表达式、多个规则的关联、规则与策略脚本的交互。下面通过几个例子来展示Bro规则提供的高级特性。

可以用如下的Bro规则来准确地检测前阵子流行的对RPC DCOM的两个溢出漏洞的攻击尝试。

signature rpc-dcom_bind-req {    # 定义一个叫rpc-dcom_bind-req的规则，此规则匹配一个攻击会话
                                 # 中必定先于实际攻击数据包出现的绑定RPC DCOM的数据包，以此规
                                 # 则匹配出来的事件不单独触发告警，用于被以下的两个规则做关联。
  header ip[9:1] == 6            # 匹配IP包头的协议字段为6，也就是TCP包。
  header tcp[2:2] == 135         # 匹配TCP包头的目标端口字段为135，也就是RPC DCOM漏洞常用的攻击端口。
  tcp-state originator,established # 匹配TCP包状态为已建立且从连接的发起者发出。
  payload /\x05\x00\x0b.{100,}\xa0\x01\x00\x00\x00\x00\x00\x00\xc0\x00\x00\x00\x00\x00\x00\x46.*\x04\x5d\x88\x8a\xeb\x1c\xc9\x11\x9f\xe8\x08\x00\x2b\x10\x48\x60/ # 用正则表达式匹配RPC DCOM BIND包的payload特
                                                 # 征(RPC包头及两个特定的UUID)。
  event "RPC DCOM BIND request"                  # 定义可能出现在告警日志的事件信息。
  }

signature rpc-dcom_servername-overflow {  # 定义名为rpc-dcom_servername-overflow的规则，此规则
                                          # 匹配RPC DCOM长主机名的栈溢出攻击。
  header ip[9:1] == 6
  header tcp[2:2] == 135
  requires-signature rpc-dcom_bind-req    # 指定需要rpc-dcom_bind-req规则先要匹配到本规则才能
                                          # 成立，也就是说此规则关联了同一个TCP会话中的另一个
                                          # 规则，这是Bro规则提供的特有功能。具体到本规则，表
                                          # 达的意思就是只有在看到有RPC DCOM BIND操作以后才会
                                          # 再去匹配接下来的数据包中是否有攻击数据包。
  tcp-state originator,etablished
  payload /.*\x05\x00\x00.{100,}\x5c\x00\x5c\x00[^\\]{32,}/  # 匹配攻击数据包的payload特征，用正
                                                             # 表达式检查是否存在超过32字节的主机
                                                             # 名。
  event "RPC DCOM servername stack overflow attempt"
  }

signature rpc-dcom_pathname-overflow {   # 定义名为rpc-dcom_pathname-overflow的规则，此规则
                                         # 匹配RPC DCOM长路径名的堆溢出攻击。
  header ip[9:1] == 6
  header tcp[2:2] == 135
  requires-signature rpc-dcom_bind-req   # 同上条规则一样的前提条件。
  tcp-state originator,established
  payload /.*\x05\x00\x00.{100,}\x5c\x00\x5c\x00[^\\]{5,32}\x5c\x00.{520,}\x00\x00/ # 匹配攻击数据
                                                                                    # 包的payload特
                                                                                    # 征，用正则表达
                                                                                    # 检测是否存在超
                                                                                    # 长的路径名。
  event "RPC DCOM pathname heap overflow attempt"
  }

以上的Bro规则展示了规则支持正则表达式匹配和规则关联的强大功能特性。正则表达式可以非常精确地匹配攻击数据的特征，当然正则表达式也存在效率低下的缺陷，但对于面向百兆网络流量注重检测准确性的引擎来说，这样的代价还是可以接受并允许的。规则关联其实是一个非常强大的功能特性：利用规则之间的关联可以很大程度上提高检测的准确性，比如上面的检测RPC DCOM攻击的例子；通过关联攻击请求及回应数据可以判定攻击的成功与否，比如通过关联一个CGI攻击请求和它的回应数据包中的HTTP状态码可判定攻击是否成功；通过关联某些相关事件序列可以触发更高级别的事件，比如可以关联多个明显的恶意CGI请求可以得出系统正在受到CGI漏洞扫描攻击的结论。

如下的用于检测ssl-worm攻击的Bro规则展示规则与策略脚本的交互特性。

signature sslworm-probe {  # 定义一个名为sslworm-probe的规则，检测ssl-worm的扫描操作
  header ip[9:1] == 6      # TCP包
  header tcp[2:2] == 80    # TCP目标端口80
  payload /.*GET \/ HTTP\/1\.1\x0d\x0a\x0d\x0a/  # 匹配payload中ssl-worm扫描数据特征
  event "Host may have been probed by Apache/SSL worm" # 定义日志记录中的告警信息
  }

signature sslworm-vulnerable-probe { # 定义扫描到有漏洞主机的规则，通过关联上面的扫描检测规则
  requires-signature sslworm-probe   # 引用上面的扫描检测规则
  eval sslworm_is_server_vulnerable  # 执行Bro策略脚本中预先定义的功能函数，此函数用于通过判
                                     # 断被扫描的主机的OPENSSL软件的版本来确定攻击方是否扫描
                                     # 到了有漏洞的主机。
  event "Host may have been probed by Apache/SSL worm and is vulnerable"  # 告警信息
  }

以上的规则展示了规则与策略脚本之间的交互，从规则可以引用策略脚本中的完成特定功能的函数，函数向规则返回函数执行完后的成功或失败的信息，规则根据返回的信息来确定是否触发相关的事件。规则中引用的功能函数可以对可以判定某些匹配条件进行判定返回结果，如上面的ssl-worm例子；也可以对多个事件进行更深入的分析关联；甚至可以利用规则中引用的功能函数执行响应操作，比如切断连接。

总结：与Snort简单粗糙的检测方式相比，Bro提供了一些关键的高级特性：在事件生成引擎中实现的应用层协议功能、强大的用于对事件做深入分析的策略脚本、支持正则表达式的数据匹配、规则关联(同一会话的规则直接关联，跨会话规则的关联可以用策略脚本实现)、规则与策略脚本的交互，这些特性使Bro这个开放源码的NIDS系统所能实现的功能更接近于当前主流商业NIDS产品，对之细调以后完全可以做到很多商业NIDS产品的准确检测，Bro是一个值得NIDS开发者参考和借鉴的好东西，也是具有一定网管经验的用户定制某些攻击检测功能的好工具。

- 作者： macob 2005年11月3日, 星期四 14:13　回复（0） |　引用（1）加入博采

网络管理

关于作者

日历　年月日

快速登录

搜索

快速浏览

最新文章

文章索引

在线留言

友情博客

最新评论

友情链接

我的菠菜

访问统计：
文章个数:135
评论个数:26
留言条数:0

网络管理

文章

英语特殊符号的读法　（作者置顶）

linux links 　（作者置顶）

资源链接　（作者置顶）

构建网管基线的最佳实践　（作者置顶）

醒酒

入侵检测系统之日志检测详解- -

入侵检测系统之日志检测详解- -

已锁定

无状态静态过滤器的缺陷

已锁定

Bro：一个开放源码的高级NIDS系统

+ 用户名：
+ 密　码：

网络管理

关于作者

日历 document.write(d.getFullYear());年document.write(d.getMonth()+1);月document.write(day)日

快速登录

搜索

快速浏览

最新文章

文章索引

在线留言

友情博客

最新评论

友情链接

我的菠菜

访问统计： 文章个数:135 评论个数:26 留言条数:0

网络管理

文章

英语特殊符号的读法 （作者置顶）

linux links （作者置顶）

资源链接 （作者置顶）

构建网管基线的最佳实践 （作者置顶）

醒酒

入侵检测系统之日志检测详解- -

入侵检测系统之日志检测详解- -

已锁定

无状态静态过滤器的缺陷

已锁定

Bro：一个开放源码的高级NIDS系统

日历　年月日

访问统计：
文章个数:135
评论个数:26
留言条数:0

英语特殊符号的读法　（作者置顶）

linux links 　（作者置顶）

资源链接　（作者置顶）

构建网管基线的最佳实践　（作者置顶）