7.1. Runmodes
Suricata由多個(gè)稱為線程弥锄，線程模塊和隊(duì)列的“構(gòu)建塊”組成丧靡。 線程就像一個(gè)在計(jì)算機(jī)上運(yùn)行的進(jìn)程。 Suricata是多線程的籽暇，所以多個(gè)線程一次處于活動(dòng)狀態(tài)温治。
線程模塊是功能的一部分。 一個(gè)模塊用于解碼數(shù)據(jù)包戒悠，另一個(gè)模塊是檢測模塊熬荆，另一個(gè)模塊是輸出模塊。 一個(gè)數(shù)據(jù)包可以被多個(gè)線程處理绸狐。 數(shù)據(jù)包將通過隊(duì)列傳遞到下一個(gè)線程卤恳。 數(shù)據(jù)包一次只能由一個(gè)線程處理，但是引擎一次可以處理多個(gè)數(shù)據(jù)包寒矿。 （請參閱Max-pending-packets）一個(gè)線程可以有一個(gè)或多個(gè)線程模塊突琳。 如果他們有更多的模塊，他們只能一次活動(dòng)符相。 線程拆融，模塊和隊(duì)列排列在一起的方式稱為Runmode。
7.1.1不同的Runmodes
您可以從幾個(gè)預(yù)定義的運(yùn)行模式中選擇一個(gè)運(yùn)行模式啊终。 命令行選項(xiàng)-list-runmodes顯示所有可用的運(yùn)行模式镜豹。 所有運(yùn)行模式都有一個(gè)名稱：auto，single孕索，autofp逛艰。 最重要的任務(wù)是檢測; 一個(gè)數(shù)據(jù)包將被檢查數(shù)千個(gè)簽名躏碳。
默認(rèn)運(yùn)行模式的示例：
在pfring模式下搞旭，每個(gè)流程在運(yùn)行模式中遵循其自己的固定路線。
有關(guān)與runmode有關(guān)的命令行選項(xiàng)的更多信息菇绵，請參閱命令行選項(xiàng)肄渗。
7.2 抓包
7.2.1負(fù)載均衡
為了獲得最佳表現(xiàn)，Suricata將需要以“worker”模式運(yùn)行咬最。這實(shí)際上意味著有多個(gè)線程翎嫡，每個(gè)線程運(yùn)行一個(gè)完整的數(shù)據(jù)包管道，每個(gè)線程都從捕獲方法接收數(shù)據(jù)包永乌。這意味著我們依靠捕獲方法來將數(shù)據(jù)包分發(fā)到各個(gè)線程上惑申。其中一個(gè)關(guān)鍵的方面就是Suricata需要以正確的順序在同一個(gè)線程中獲取流程的兩個(gè)方面具伍。
AF_PACKET和PF_RING捕獲方法都有選擇“集群類型”的選項(xiàng)。這些默認(rèn)為'cluster_flow'圈驼，它指示捕獲方法按流（5元組）進(jìn)行散列人芽。這個(gè)散列是對稱的。
Netmap沒有內(nèi)置的cluster_flow模式绩脆∮┨可以使用“l(fā)b”工具單獨(dú)添加：https：//github.com/luigirizzo/netmap/tree/master/apps/lb
警告最近的AF_PACKET變化已經(jīng)“broken”：https：//redmine.openinfosecfoundation.org/issues/1777這種對稱性。目前正在進(jìn)行“解決這個(gè)問題”的工作：https：//redmine.openinfosecfoundation.org/issues/1777#note-7靴迫，但現(xiàn)在停留在內(nèi)核<= 4.2或更新到4.4.16+惕味，4.6.5+或4.7+。
在幾乎所有現(xiàn)代NIC的多隊(duì)列NIC上玉锌，都需要考慮RSS設(shè)置名挥。
7.2.2. RSS
接收端縮放(RSS)是網(wǎng)卡使用的一種技術(shù)，用于將傳入流量分配到網(wǎng)卡上的各個(gè)隊(duì)列中主守。 這是為了提高性能躺同，但重要的是要認(rèn)識到它是為正常流量設(shè)計(jì)的，而不是針對IDS數(shù)據(jù)包捕獲的情況丸逸。 RSS使用哈希算法來將傳入流量分配到各個(gè)隊(duì)列中蹋艺。 這個(gè)散列通常不是對稱的。 這意味著當(dāng)接收到一個(gè)流的雙方時(shí)黄刚，每一方都可能以不同的隊(duì)列結(jié)束捎谨。 可悲的是，在部署Suricata時(shí)憔维，這是使用跨度端口或水龍頭(Trap)時(shí)的常見情況涛救。
這里的問題是，通過使流量的兩端處于不同的隊(duì)列中业扒，分組處理的順序變得不可預(yù)知检吆。 網(wǎng)卡，驅(qū)動(dòng)程序程储，內(nèi)核和Suricata上的時(shí)間差異將導(dǎo)致數(shù)據(jù)包進(jìn)入的順序高于網(wǎng)絡(luò)蹭沛。 這具體是關(guān)于兩個(gè)交通方向之間的不匹配。 例如章鲤，Suricata跟蹤TCP 3次握手摊灭。 由于這個(gè)時(shí)間問題，在客戶端到服務(wù)器端已經(jīng)開始發(fā)送數(shù)據(jù)之后败徊，SYN / ACK只能被Suricata接收帚呼。 Suricata會將此流量視為無效。
AF_PACKET，PF_RING或NETMAP等支持的捕獲方法都不能解決這個(gè)問題煤杀。 這將需要緩沖和分組重新排序眷蜈，這是昂貴的。
要查看配置了多少個(gè)隊(duì)列：
$ ethtool -l ens2f1
Channel parameters for ens2f1:
Pre-set maximums:
RX: 0
TX: 0
Other: 1
Combined: 64
Current hardware settings:
RX: 0
TX: 0
Other: 1
Combined: 8
有些網(wǎng)卡允許您將其設(shè)置為對稱模式沈自。 英特爾X（L）710卡在理論上可以做到這一點(diǎn)端蛆，但是驅(qū)動(dòng)程序還沒有能力做到這一點(diǎn)（工作正在努力解決這個(gè)問題）。 另一個(gè)解決的方法是設(shè)置一個(gè)特殊的“隨機(jī)密鑰”酥泛，使RSS對稱今豆。 見http://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf（PDF）。
然而柔袁，在大多數(shù)情況下呆躲，最佳解決方案是將RSS隊(duì)列的數(shù)量減少到1：
例：
Intel X710 with i40e driver:
ethtool -L $DEV combined 1
有些驅(qū)動(dòng)程序不支持通過ethtool設(shè)置隊(duì)列的數(shù)量。 在某些情況下捶索，有一個(gè)模塊加載時(shí)間選項(xiàng)插掂。 閱讀驅(qū)動(dòng)程序文檔的具體信息。
7.2.3 卸載
網(wǎng)卡腥例，驅(qū)動(dòng)程序和內(nèi)核本身有各種技術(shù)來加速數(shù)據(jù)包的處理辅甥。 通常這些都將被禁用。
LRO / GRO導(dǎo)致將各種較小的數(shù)據(jù)包合并為大“超級數(shù)據(jù)包”燎竖。 這些將需要被禁用璃弄，因?yàn)樗麄兇蚱屏薲size關(guān)鍵字以及TCP狀態(tài)跟蹤。
可以在AF_PACKET和PF_RING上啟用校驗(yàn)和卸載构回，但需要在PCAP夏块，NETMAP等上禁用。
7.2.4 建議
閱讀你的驅(qū)動(dòng)文檔纤掸！ 例如脐供。 對于i40e，RSS隊(duì)列的ethtool更改可能會導(dǎo)致內(nèi)核恐慌借跪，如果做錯(cuò)了政己。
通用：將RSS隊(duì)列設(shè)置為1或確保RSS散列是對稱的。 禁用NIC卸載掏愁。
AF_PACKET：1個(gè)RSS隊(duì)列并停留在內(nèi)核<= 4.2或者確保你有> = 4.4.16歇由，> = 4.6.5或> = 4.7。
例外：如果RSS是對稱群集類型托猩，可以使用“cluster_qm”將Suricata綁定到RSS隊(duì)列印蓖。 禁用除rx / tx csum之外的NIC卸載。
PF_RING：1個(gè)RSS隊(duì)列并使用群集類型“cluster_flow”京腥。 禁用除rx / tx csum之外的NIC卸載。
NETMAP：1個(gè)RSS隊(duì)列溅蛉。 沒有內(nèi)置的基于流量的負(fù)載平衡公浪，但'lb'工具可以有幫助他宛。 另一個(gè)選擇是使用'autofp'runmode。
例外：如果RSS是對稱的欠气，則負(fù)載平衡基于RSS哈希厅各，并且可以使用多個(gè)RSS隊(duì)列。 禁用所有NIC卸載预柒。
