輸出插件使得Snort在向用戶提供格式化輸出時更加靈活。輸出插件在Snort的告警和記錄子系統被調用時運行,在預處理程序和探測引擎以後。規則文件中指令的格式很是相似於預處理程序。
注意:若是在運行時指定了命令行的輸出開關,在Snort規則文件中指定的輸出插件會被替代。例如,若是在規則文件中指定了alert_syslog插件,但在命令行中使用了"-A fast"選項,則alert_syslog插件會被禁用而使用命令行開關。多個輸出插件是在snort的配置文件中指定的。當指定多個輸出插件時,它們被壓入棧而且在事件發生時按順序調用。關於標準的記錄和報警系統,輸出模塊缺省把數據發送到 /var/log/snort.或者經過使用-l命令行參數輸出到一個用戶指定的目錄。在規則文件中經過指定output關鍵字,使得在運行時加載輸出模塊。
格式:
output <name>: <options>
例子:
output alert_syslog: LOG_AUTH LOG_ALERT
Alert_syslog
該插件向syslog設備發送告警(很像命令行中的-s開關)。該插件也容許用戶指定記錄設備,優先於Snort規則文件中的設定,從而在記錄告警方面給用戶更大的靈活性。
可用關鍵字:
選項(Options)
LOG_CONS
LOG_NDELAY
LOG_PERROR
LOG_PID
設備(Facilities)
LOG_AUTH
LOG_AUTHPRIV
LOG_DAEMON
LOG_LOCAL0
LOG_LOCAL1
LOG_LOCAL2
LOG_LOCAL3
LOG_LOCAL5
LOG_LOCAL6
LOG_LOCAL7
LOG_USER
優先級(Priorities)
LOG_EMERG
LOG_ALERT
LOG_CRIT
LOG_ERR
LOG_WARNING
LOG_NOTICE
LOG_INFO
LOG_DEBUG
格式:
alert_syslog: <facility> <priority> <options>
Alert_fast
將報警信息快速的打印在指定文件的一行裏。它是一種快速的報警方法,由於不須要打印數據包頭的全部信息。
格式:
alert_fast: <output filename>
例子:
output alert_fast: alert.fast
Alert_full
打印數據包頭全部信息的報警。這些報警信息寫到缺省的日誌目錄(/var/log/snort)或者寫到命令行指定的目錄。在日誌目錄內,每一個IP都建立一個目錄。產生報警的數據包被解碼後寫到這個目錄下的文件裏。這些文件的建立將大大下降snort的性能。因此這種輸出方法對大多數不適用,但那些輕量級的網絡環境仍是可使用的。
格式:
alert_full: <output filename>
例子:
output alert_full: alert.full
Alert_smb
這個插件將把WinPopup報警信息發送給NETBIOS命名的機器上的一個文件。並不鼓勵使用這個插件,由於它以snort權限執行了一個外部可執行二進制程序,一般是root權限。那個工做站上接受報警信息的文件每行存放一條報警信息。
格式:
alert_smb: <alert workstation filename>
例子;
output alert_smb: workstation.list
Alert_unixsock
打開一個UNIX套接字,而且把報警信息發送到那裏。外部的程序/進程會在這個套接字上偵聽並實時接收這些報警數據。
格式:
alert_unixsock
例子:
output alert_unixsock
Log_tcpdump
log_tcpdump插件將數據包記錄到tcpdump格式的文件中。這便於使用已有的多種檢查tcpdump格式文件的工具,來對收集到的流量數據進行後處理工做。該插件只接受一個參數,即輸出文件名
格式:
log_tcpdump: <output filename>
例子:
output log_tcpdump: snort.log
database
該插件由Jed Pickel提供將Snort數據記錄到Postgres SQL數據庫中。更多的有關安裝和配置該插件的信息能夠在Incident.org (http://www.incident.org/snortdb)找到。這個插件的參數是數據庫名稱和一個參數列表。參數由格式parameter = argument來指定。可用參數以下:
host - 鏈接主機。若是指定了一個非零字串,就使用TCP/IP通信。若是不指定主機名,就會使用Unix domain socket鏈接。
port - 鏈接服務器主機的端口號,或者是Unix-domain鏈接的socket文件名擴展。
dbname - 數據庫名。
user – 數據庫中身份認證用的用戶名。
password - 若是數據庫要求口令認證,就使用這個口令。
sensor_name 爲snort指定一個你本身的名字。若是你不指定,這裏就自動產生一個。
encoding 由於數據包負載和選項都是二進制的,因此沒有一個輕便簡單的方法把它存儲在數據庫中。沒有使用BLOBS,由於它們在穿越數據庫時不是那麼輕便的。因此,咱們提供了一個encoding 選項給你。你能夠從下面的選項中選擇。它們有各自的優缺點。
hex (default) 把二進制數據表示成十六進制字符串
storage requirements – 二進制的二倍容量
searchability – 很好用
human readability – 不是很好讀除非你很滑稽,要求郵件處理。
base64 把二進制數據表示成以64爲基的字符串。
storage requirements二進制的1.3倍容量。
searchability – 沒有郵件處理是不可能的。
human readability –不易讀,要求郵件處理。
ascii 把二進制數據表示成 ascii 碼字符串。這是惟一的能夠釋放數據的選項。非ascii碼數據用… 代替。即便你選擇了這個選項,ip和tcp選項數據還將用十六進制表示,由於那些數據用ascii碼標上沒有任何意義。
storage requirements – 稍微比二進制大,由於避免了一些字符(&,<,>)。
searchability – 對於搜索文本字符串很好用,而搜索二進制串是不可能的。
human readability – 很好用。
detail 你想存儲多少細節數據,有以下選項:
full (缺省值)記錄一個引發報警數據包的全部的細節(包括ip/tcp選項和負載)。
fast 只記錄少許數據。若是選擇了這個選項,你將削減了潛在的分析能力,但這還是一些應用的最佳選項。這將記錄下面的字段(timestamp, signature, source ip, destination ip, source port, destination port, tcp flags, and protocol)
此外,還必須定義一個記錄方法和數據庫類型。有兩種記錄方法,log和alert。設置爲log類型,將啓動這個程序的數據庫記錄功能。若是你設置爲log類型,輸出鏈表將調用這個插件。設置爲alert類型,將啓動這個程序的數據庫報警輸出功能。
當前共有四種數據庫類型:MySQL, PostgreSQL, Oracle, 和 unixODBC-兼容數據庫。
格式:
output database: log, mysql, dbname=snort user=snort host=localhost password=xyz
CSV
CSV輸出插件能夠將報警數據以一種方便的形式輸出到一個數據庫。這個插件要求兩個參數,一個全路徑文件名和輸出模式選項。下面是模式選項列表。若是模式選項缺省,就按模式選項列表中的順序輸出。
timestamp
msg
proto
src
srcport
dst
dstport
ethsrc
ethdst
ethlen
tcpflags
tcpseq
tcpack
tcplen
tcpwindow
ttl
tos
id
dgmlen
iplen
icmptype
icmpcode
icmpid
icmpseq
格式:
output alert_CSV: <filename> <format>
例子:
output alert_CSV: /var/log/alert.csv default
output alert_CSV: /var/log/alert.csv timestamp, msg
Unified
Unified輸出插件被設計成儘量快的事件記錄方法。它記錄一個事件到一個報警文件和一個數據包到一個日誌文件。報警文件包含一個事件的主要信息(ips, protocol, port, message id)。日誌文件包含數據包信息的細節(一個數據包考貝及相關的事件ID)。
這兩個文件都是以spo_unified.h文件中描述的二進制形式寫的。以unix秒爲單位的時間將附加到每一個文件的後面寫出。
格式
output alert_unified: <file name>
output log_unified: <file name>
例子:
output alert_unified: snort.alert
output log_unified: snort.log
Log Null
有時建立這樣的規則是必要的,即在某些狀況下可以發出報警而不記錄數據包。當使用log_null插件時就至關於命令行的-N選項,但這個插件能夠工做在一個規則類型上。
格式:
output log_null
ruletype info {
type alert
output alert_fast: info.alert
output log_null
}
本身動手編寫好的規則
當編寫snort規則時,首先考慮的是效率和速度。
好的規則要包含content選項。2.0版本之後,snort改變了檢測引擎的工做方式,在第一階段就做一個集合模式匹配。一個content選項越長,這個匹配就越精確。若是一條規則不包含content選項,它們將使整個系統慢下來。
當編寫規則時,儘可能要把目標定位在攻擊的地方(例如,將目標定位在1025的偏移量等等)而不只僅是泛泛的指定(如,在這匹配腳本代碼)。Content規則是大小寫敏感的(除非你使用了nocase選項)。不要忘記content是大小寫敏感的和大多數程序的命令都是大寫字母。FTP就是一個很好的例子。考慮以下的規則:
alert tcp any any -> 192.168.1.0/24 21 (content: "user root"; msg: "FTP root login";)
alert tcp any any -> 192.168.1.0/24 21 (content: "USER root"; msg: "FTP root login";)
上面的第二條規則能檢測出大多數的自動以root登錄的嘗試,而第一條規則就不行。Internet 守護進程在接受輸入時是很隨便的。在編寫規則時,很好的理解協議規範將下降錯過攻擊的機會。
加速含有內容選項的規則
探測引擎運用規則的順序和它們在規則中的書寫順序無關。內容規則選項老是最後一個被檢驗。利用這個事實,應該先運用別的快速規則選項,由這些選項決定是否須要檢查數據包的內容。例如:在TCP會話創建起來後,從客戶端發來的數據包,PSH和ACK這兩個TCP標誌老是被置位的。若是想檢驗從客戶端到服務器的有效載荷,利用這個事實,就能夠先進行一次TCP標誌檢驗,這比模式匹配算法(pattern match algorithm)在計算上節約許多。使用內容選項的規則要加速的一個簡便方法就是也進行一次標誌檢驗。基本思想是,若是PSH和ACK標誌沒有置位,就不須要對數據包的有效載荷進行檢驗。若是這些標誌置位,檢驗標誌而帶來的計算能力消耗是能夠忽略不計的。 mysql