Iptable里有沒有辦法通過日志記錄來記錄下請(qǐng)求的URL地址？

feiyi

Iptable里有沒有辦法通過日志記錄來記錄下請(qǐng)求的URL地址？



iptables -A FORWARD -p tcp -j LOG --log-level debug

#比如這個(gè)
iptables -I FORWARD -j DROP -p tcp -s 0.0.0.0/0 -m string --string "cmd.exe"   -j LOG --log-level debug

#有沒有可能記錄下來正在訪問這個(gè)的URL，比如他可能是 abc.com/abc/cmd.exe ?


#比如這個(gè)有沒有可能記錄下來正在訪問80端口的所有URL？

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j LOG --log-level debug

#當(dāng)前只記錄下類似這樣的
Nov 25 18:18:26 localhost kernel: IN=br0 OUT= PHYSIN=eth0 MAC=00:15:17:b5:bc:b4:00:1d:0f:0e:02:95:08:00 SRC=192.168.2.5 DST=192.168.2.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=38736 DF PROTO=TCP SPT=63284 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0

#沒法知道請(qǐng)求的URL。

比如L7-filter等有沒有可能實(shí)現(xiàn)這個(gè)？

不知那位兄弟知道如何解決這個(gè)？

非常感謝您的幫助。

wendaozhe

這個(gè)恐怕是無望了，為什么不用個(gè)squid？，這可是他的強(qiáng)項(xiàng)！

chenyx

iptables日志太大了,不好分析,
安裝squid實(shí)現(xiàn)好點(diǎn)

feiyi

我想實(shí)現(xiàn)透明的網(wǎng)橋模式， 用squid等就是透明代理了，同時(shí)又需要監(jiān)控

iptables -I FORWARD -j DROP -p tcp -s 0.0.0.0/0 -m string --string "qq.com"

像這樣的是可以工作的，但就是不知如何能把這樣的string 給記錄下來。


謝謝

7717060

iptables -I FORWARD -p tcp -s 0.0.0.0/0 -m string --string "qq.com" -j LOG --log-prefix"name"
如果這樣只是記錄匹配qq.com的log而且不是url ,建議還是用squid

blueswxs

原帖由 feiyi 于 2009-11-25 23:45 發(fā)表
Iptable里有沒有辦法通過日志記錄來記錄下請(qǐng)求的URL地址？



iptables -A FORWARD -p tcp -j LOG --log-level debug

#比如這個(gè)
iptables -I FORWARD -j DROP -p tcp -s 0.0.0.0/0 -m string --string ...

L7-filter 如果樓主不擔(dān)心你的速度受影響，那到可以考慮。


L7 filter 簡(jiǎn)介
在Linux的防火墻體系Netfilter下有一個(gè)獨(dú)立的模塊L7 filter 。從字面上看Netfilter是對(duì)網(wǎng)絡(luò)數(shù)據(jù)的過濾，L7 filter是基于數(shù)據(jù)流應(yīng)用層內(nèi)容的過濾。不過實(shí)際上 L7 filter的本職工作不是對(duì)數(shù)據(jù)流進(jìn)行過濾而是對(duì)數(shù)據(jù)流進(jìn)行分類。它使用模式匹配算法把進(jìn)入設(shè)備的數(shù)據(jù)包應(yīng)用層內(nèi)容與事先定義好的協(xié)議規(guī)則進(jìn)行比對(duì)，如果匹配成功就說明這個(gè)數(shù)據(jù)包屬于某種協(xié)議。
  
L7 filter是基于數(shù)據(jù)流工作的，建立在Netfilter connstrack功能之上。因?yàn)橐粋�(gè)數(shù)據(jù)流或者說一個(gè)連接的所有數(shù)據(jù)都是屬于同一個(gè)應(yīng)用的，所以L7 filter沒有必要對(duì)所以的數(shù)據(jù)包進(jìn)行模式匹配，而只匹配一個(gè)流的前面幾個(gè)數(shù)據(jù)包 （比如10個(gè)數(shù)據(jù)包）。當(dāng)一個(gè)流的前面幾個(gè)數(shù)據(jù)包包含了某種應(yīng)用層協(xié)議的特征碼時(shí) （比如QQ），則這個(gè)數(shù)據(jù)流被L7 filter識(shí)別；當(dāng)前面幾個(gè)數(shù)據(jù)包的內(nèi)容沒有包含某種應(yīng)用層協(xié)議的特征碼時(shí)，則L7 filter放棄繼續(xù)做模式匹配，這個(gè)數(shù)據(jù)流也就沒有辦法被識(shí)別。
  
做模式識(shí)別是一個(gè)很消耗計(jì)算資源的操作，特別是在網(wǎng)絡(luò)應(yīng)用下因?yàn)閿?shù)據(jù)量很多所以更體現(xiàn)出對(duì)資源的占用上。在Linux內(nèi)核，L7 filter其實(shí)非常影響網(wǎng)絡(luò)處理的效率。所以在沒有十分必要的時(shí)候盡量不要采用L7 filter做流量分類�，F(xiàn)在出現(xiàn)了一個(gè)運(yùn)行在Linux用戶空間的版本 L7 filter-userspace ，這個(gè)軟件運(yùn)行時(shí)不會(huì)影響內(nèi)核，但是處理效率會(huì)更低。實(shí)際上L7 filter-userspace 調(diào)用了netlink協(xié)議族的功能，整個(gè)處理過程至少進(jìn)行了兩次的數(shù)據(jù)包拷貝操作，能不影響效率嗎？
  
不過話說回來，在對(duì)性能要求不高的應(yīng)用上，L7 filter確實(shí)給我們提供了一個(gè)功能強(qiáng)大的網(wǎng)絡(luò)流量管理工具。使用這個(gè)工具的操作也非常簡(jiǎn)單，只要會(huì) Iptables配置Linux防火墻，就會(huì)配置L7 filter規(guī)則。一個(gè)配置封殺QQ應(yīng)用的例子如下：
Iptables -t mangle -A POSTROUTING -d x.x.x.x -p udp -m layer7 --l7proto qq -j DROP

feiyi

其實(shí)我也想用squid,dansguardian 等工具， 主要的問題有兩個(gè)方面，對(duì)于 后端的服務(wù)器其實(shí)他能知道我們這個(gè)監(jiān)控機(jī)器的IP， 比如通過 REMOTE_ADDR 就可以得到了， 二是我擔(dān)心后端幾百M(fèi)的大流量過來后一般的機(jī)器能不能接受得了。