亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: 基于包內(nèi)容的關(guān)鍵字過(guò)濾－－－求助 [打印本頁(yè)]

作者: gordenisgk 時(shí)間: 2009-02-12 10:09
標(biāo)題: 基于包內(nèi)容的關(guān)鍵字過(guò)濾－－－求助
目前正在學(xué)校做一個(gè)內(nèi)網(wǎng)安全的項(xiàng)目，合同上有關(guān)鍵字過(guò)濾這個(gè)要求。我們的方案是，在網(wǎng)關(guān)(Linux OS)上將每個(gè)包的數(shù)據(jù)拆開(kāi)，進(jìn)行關(guān)鍵字匹配，如果匹配成功，則drop此包。
查了相關(guān)libpcap的資料，發(fā)現(xiàn)它只能按一定的規(guī)則抓包，而且這些包還是從內(nèi)核空間拷貝到用戶(hù)空間的，并不能改變包的命運(yùn)。能決定包命運(yùn)的有netfilter，不知是否需要從netfilter下手？
不過(guò)，在本論壇上(http://linux.chinaunix.net/bbs/viewthread.php?tid=899077)看到3樓這位大俠說(shuō)可以用libpcap過(guò)濾內(nèi)容，望指點(diǎn)！
本人聯(lián)系方式：QQ：83558633

作者: gordenisgk 時(shí)間: 2009-02-12 12:45
召喚見(jiàn)多識(shí)廣的版主大人出來(lái)！

作者: dreamice 時(shí)間: 2009-02-12 12:48
標(biāo)題: 回復(fù) #1 gordenisgk 的帖子
外包項(xiàng)目么？呵呵

作者: gordenisgk 時(shí)間: 2009-02-12 12:56
回2樓，也不全是，我畢業(yè)設(shè)計(jì)做這個(gè)。
我查了不少資料，libpcap只能截取并不能攔截。特別想問(wèn)一下網(wǎng)址中3樓的那個(gè)人怎么做的！

作者: kns1024wh 時(shí)間: 2009-02-12 23:07
標(biāo)題: 回復(fù) #4 gordenisgk 的帖子
老板不給指點(diǎn)迷途么

作者: dreamice 時(shí)間: 2009-02-13 09:10
標(biāo)題: 回復(fù) #4 gordenisgk 的帖子
你到底想在內(nèi)核做還是在用戶(hù)空間來(lái)做？把你的思路說(shuō)出來(lái)，我可以給你一些建議

作者: chenyx 時(shí)間: 2009-02-13 09:12
試試iptables的string模塊

作者: Godbach 時(shí)間: 2009-02-13 10:35
看看iptables擴(kuò)展的layer7匹配還有ipp2p

作者: dreamice 時(shí)間: 2009-02-13 18:08
標(biāo)題: 回復(fù) #7 chenyx 的帖子
string模塊能對(duì)付一些簡(jiǎn)單的關(guān)鍵字匹配了

作者: Godbach 時(shí)間: 2009-02-22 19:42

原帖由 dreamice 于 2009-2-13 18:08 發(fā)表
string模塊能對(duì)付一些簡(jiǎn)單的關(guān)鍵字匹配了

覺(jué)得要么就直接使用IP Queue機(jī)制把數(shù)據(jù)報(bào)文弄到用戶(hù)控件處理好了。

作者: i.am 時(shí)間: 2009-02-23 13:47
統(tǒng)一ls

作者: dreamice 時(shí)間: 2009-02-23 18:22
標(biāo)題: 回復(fù) #10 Godbach 的帖子
這樣效率如何？
IP queue原來(lái)是干這個(gè)的？

作者: Godbach 時(shí)間: 2009-02-24 09:31
標(biāo)題: 回復(fù) #12 dreamice 的帖子
一般要分析應(yīng)用數(shù)據(jù)的時(shí)候，就可以考慮使用這種機(jī)制，把報(bào)文丟到應(yīng)用空間，用戶(hù)態(tài)根據(jù)報(bào)文的內(nèi)容進(jìn)行判斷，并決定ACCEPT或DROP。當(dāng)然，就算在內(nèi)核態(tài)做也可以哈。

作者: dreamice 時(shí)間: 2009-02-24 11:00

原帖由 Godbach 于 2009-2-24 09:31 發(fā)表
一般要分析應(yīng)用數(shù)據(jù)的時(shí)候，就可以考慮使用這種機(jī)制，把報(bào)文丟到應(yīng)用空間，用戶(hù)態(tài)根據(jù)報(bào)文的內(nèi)容進(jìn)行判斷，并決定ACCEPT或DROP。當(dāng)然，就算在內(nèi)核態(tài)做也可以哈。

iptables的string匹配其實(shí)可以做一些簡(jiǎn)單的關(guān)鍵字匹配檢查，但涉及到應(yīng)用層一些復(fù)雜的匹配規(guī)則，ip queue倒是不錯(cuò)的選擇，但不太清楚其性能如何

作者: Godbach 時(shí)間: 2009-02-25 09:22

原帖由 dreamice 于 2009-2-24 11:00 發(fā)表

iptables的string匹配其實(shí)可以做一些簡(jiǎn)單的關(guān)鍵字匹配檢查，但涉及到應(yīng)用層一些復(fù)雜的匹配規(guī)則，ip queue倒是不錯(cuò)的選擇，但不太清楚其性能如何

恩，iptables的string匹配應(yīng)該功能有限。Ip Queue的可以測(cè)試一下啊

作者: dreamice 時(shí)間: 2009-02-25 14:13

原帖由 Godbach 于 2009-2-25 09:22 發(fā)表

恩，iptables的string匹配應(yīng)該功能有限。Ip Queue的可以測(cè)試一下啊

從它的實(shí)現(xiàn)機(jī)理來(lái)看，效率可能是個(gè)瓶頸——如果大規(guī)模的用這種機(jī)制的話(huà)

作者: Godbach 時(shí)間: 2009-02-25 15:09

原帖由 dreamice 于 2009-2-25 14:13 發(fā)表

從它的實(shí)現(xiàn)機(jī)理來(lái)看，效率可能是個(gè)瓶頸——如果大規(guī)模的用這種機(jī)制的話(huà)

何以見(jiàn)得效率是瓶頸呢？ dreamice兄判斷的原因可否講一下。
難道數(shù)據(jù)報(bào)文在用戶(hù)態(tài)處理而不是在內(nèi)核態(tài)處理，就一定會(huì)導(dǎo)致效率問(wèn)題嗎？

作者: dreamice 時(shí)間: 2009-02-25 23:11

原帖由 Godbach 于 2009-2-25 15:09 發(fā)表

何以見(jiàn)得效率是瓶頸呢？ dreamice兄判斷的原因可否講一下。
難道數(shù)據(jù)報(bào)文在用戶(hù)態(tài)處理而不是在內(nèi)核態(tài)處理，就一定會(huì)導(dǎo)致效率問(wèn)題嗎？

這個(gè)數(shù)據(jù)周轉(zhuǎn)的路徑比較長(zhǎng)，內(nèi)核的匹配-->用戶(hù)空間-->用戶(hù)空間Process-->內(nèi)核空間
整個(gè)走了一圈，數(shù)據(jù)包的延遲就不用說(shuō)了，如果量比較大，這個(gè)效率是可想而知的。

作者: Godbach 時(shí)間: 2009-02-26 12:30

原帖由 dreamice 于 2009-2-25 23:11 發(fā)表

這個(gè)數(shù)據(jù)周轉(zhuǎn)的路徑比較長(zhǎng)，內(nèi)核的匹配-->用戶(hù)空間-->用戶(hù)空間Process-->內(nèi)核空間
整個(gè)走了一圈，數(shù)據(jù)包的延遲就不用說(shuō)了，如果量比較大，這個(gè)效率是可想而知的。

我覺(jué)得可以這樣理解：
（1）內(nèi)核空間對(duì)某些報(bào)文的數(shù)據(jù)部分處理的效率沒(méi)有用戶(hù)空間高，或者處理的速度上相差比較大；
（2）內(nèi)核把數(shù)據(jù)包丟到應(yīng)用空間之后，就可以處理其他報(bào)文了，直到這個(gè)報(bào)文再次被丟回內(nèi)核空間。

作者: dreamice 時(shí)間: 2009-02-27 23:31
標(biāo)題: 回復(fù) #19 Godbach 的帖子
那被丟上去這個(gè)報(bào)文的延遲就可想而知了

作者: Godbach 時(shí)間: 2009-02-28 15:09
看來(lái)得網(wǎng)上搜一下又沒(méi)有測(cè)試過(guò)IP Queue效率的問(wèn)題。要么就得自己測(cè)試看看了。

作者: dreamice 時(shí)間: 2009-02-28 19:11

原帖由 Godbach 于 2009-2-28 15:09 發(fā)表
看來(lái)得網(wǎng)上搜一下又沒(méi)有測(cè)試過(guò)IP Queue效率的問(wèn)題。要么就得自己測(cè)試看看了。

雖然我沒(méi)有測(cè)試結(jié)果，但我敢肯定，這個(gè)比在內(nèi)核處理延時(shí)要大的，本身就是在內(nèi)核空間處理用戶(hù)空間的數(shù)據(jù)分析，效率都非常低的。

作者: Godbach 時(shí)間: 2009-02-28 22:12

本身就是在內(nèi)核空間處理用戶(hù)空間的數(shù)據(jù)分析，效率都非常低的。

其實(shí)我覺(jué)得，單單從處理報(bào)文的應(yīng)用數(shù)據(jù)上來(lái)看，內(nèi)核并不一定比應(yīng)用空間的效率高。相對(duì)內(nèi)核來(lái)說(shuō)，應(yīng)用空間會(huì)有更高效的工具處理應(yīng)用數(shù)據(jù)。

作者: sunki 時(shí)間: 2009-03-28 23:58
關(guān)鍵字過(guò)濾，就算是硬件防火墻也是CPU占100％，可以用snort＋iptables 試試

作者: Godbach 時(shí)間: 2009-03-29 17:13

原帖由 sunki 于 2009-3-28 23:58 發(fā)表
關(guān)鍵字過(guò)濾，就算是硬件防火墻也是CPU占100％，可以用snort＋iptables 試試

這個(gè)應(yīng)該和流量大小有關(guān)吧

作者: tompanpan 時(shí)間: 2009-04-23 11:36
還是比較贊同dreamice的說(shuō)法的，我之前有測(cè)試過(guò)，大概對(duì)原有延時(shí)會(huì)提升50％－150%的增加，但是實(shí)際情況是原來(lái)延時(shí)是<1ms，用ip queue之后延時(shí)還是小于<1ms，當(dāng)然我是用ping做的測(cè)試，結(jié)果不一定能反應(yīng)問(wèn)題本質(zhì)，畢竟這個(gè)影響跟用戶(hù)層如何處理有關(guān)系，但是正如dreamice所說(shuō)的，從內(nèi)核到用戶(hù)態(tài)，從用戶(hù)態(tài)到內(nèi)核態(tài)，對(duì)效率的影響必定是較大的，這里的效率影響點(diǎn)主要是內(nèi)核和用戶(hù)態(tài)的切換以及用戶(hù)態(tài)處理的影響兩點(diǎn)－_－

作者: gordenisgk 時(shí)間: 2009-04-29 14:49
謝謝大家的幫助，我目前以基本上實(shí)現(xiàn)了這個(gè)功能，我是使用iptables -A INPUT -p tcp --sport 80 -j NFQUEUE使數(shù)據(jù)包發(fā)送到用戶(hù)空間，然后從數(shù)據(jù)鏈路層還原到應(yīng)用層，主要處理的http協(xié)議里面的數(shù)據(jù)，包括gzip壓縮的格式。

作者: platinum 時(shí)間: 2009-04-29 15:03

原帖由 gordenisgk 于 2009-4-29 14:49 發(fā)表
謝謝大家的幫助，我目前以基本上實(shí)現(xiàn)了這個(gè)功能，我是使用iptables -A INPUT -p tcp --sport 80 -j NFQUEUE使數(shù)據(jù)包發(fā)送到用戶(hù)空間，然后從數(shù)據(jù)鏈路層還原到應(yīng)用層，主要處理的http協(xié)議里面的數(shù)據(jù)，包括gzip壓縮 ...

呃，這樣�。�
那難度不小

如果你要在網(wǎng)絡(luò)層處理應(yīng)用層數(shù)據(jù)流的話(huà)，還要考慮丟包重傳、亂序等情況
如果你收到的數(shù)據(jù)包序號(hào)是 1、2、3、3、4（3 重傳過(guò)一次），那么這個(gè)數(shù)據(jù)內(nèi)容恐怕是不能被 gunzip 的……

作者: gordenisgk 時(shí)間: 2009-04-30 10:34
亂序的問(wèn)題應(yīng)該不用考慮，Netfilter似乎已經(jīng)解決了這個(gè)問(wèn)題。到是重傳的包有點(diǎn)麻煩，可能這邊處理的速度慢了，服務(wù)器沒(méi)有收到ack。我很想做一個(gè)網(wǎng)頁(yè)重定向的功能，不知道怎么實(shí)現(xiàn)？

作者: platinum 時(shí)間: 2009-04-30 11:01

原帖由 gordenisgk 于 2009-4-30 10:34 發(fā)表
亂序的問(wèn)題應(yīng)該不用考慮，Netfilter似乎已經(jīng)解決了這個(gè)問(wèn)題。

好像沒(méi)有吧
netfilter 可以被看成是一個(gè) hook 點(diǎn)
NAT 模式我不清楚，但如果是橋模式的話(huà)，只要 TCP 數(shù)據(jù)的 window 在合法范圍之內(nèi)，數(shù)據(jù)被視為是正確的，不會(huì)被 DROP，會(huì)原封不動(dòng)的發(fā)到另一邊

而且無(wú)論 netfilter 能否解決亂序問(wèn)題，正如你所說(shuō)，重傳情況也是必須要考慮的，亂序和重傳的情況其實(shí)是一樣的，如果重傳能解決，亂序也沒(méi)問(wèn)題

作者: gordenisgk 時(shí)間: 2009-05-03 16:39
大家?guī)臀蚁胍幌氚。绻覚z測(cè)到了關(guān)鍵字，想讓這個(gè)網(wǎng)頁(yè)重定向到指定網(wǎng)頁(yè)該怎么實(shí)現(xiàn)呢？？？

作者: wzhuzhu 時(shí)間: 2009-05-07 09:16
修改目的地址和端口，然后重新計(jì)算checksum的值。

歡迎光臨 Chinaunix (http://72891.cn/)