包過濾日誌實驗

❶ Slf4j + Logback 怎麼過濾掉第三方包中的日誌顯示

其實這跟 Slf4J 通用日誌框架沒什麼關系，單單是 Logback 的事，把 Slf4J 扯進來只因它們是對黃金組合。
我們在 log4j 中想要不顯示第三方包的非常冗餘的日誌輸出時，只要在 log4j.properties 中寫上：
log4j.logger.org.hibernate=ERROR

這樣在 hibernate 里的日誌級別在 ERROR 以下的 TRACE、DEBUG、WARN 和 INFO 將不被輸出，控制台會比較的干凈。
Logback 的配置文件是 logback.xml，曾經在裡面給 <appender> 加的 <pattern> 是：
<pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>

logger 名顯示 35 字元，類名優先顯示全，類全限名超過總長度則取前面若干包名的首字母連接起來，於是產生了像下面那樣的日誌輸出：
7937 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Returning cached instance of singleton
7781 [main] DEBUG o.h.loader.entity.EntityLoader - Static select for entity
這在 Log4J 中是未曾見過的。當時還以為日誌名就是 o.s.b.f 這樣的東西，於是在 logback.xml 中用
<logger name="o.s.b" level="WARN"/>
<logger name="o.h" level="WARN"/>

本文原始鏈接 http://gloveangels.com/slf4j-logback-filter-logger/, 來自 隔葉黃鶯 Unmi Blog
這樣的代碼來進行封鎖，根本就無濟於事，大量的虛芹 spring、hibernate 的 DEBUG、INFO 等日誌照樣輸出。這時惦記起 Logback 的 filter 功能來了，配置上：
<filter>
<evaluator> <!-- defaults to type ch.qos.logback.classic.boolex.JaninoEventEvaluator -->
<expression><![CDATA[
event.getThreadName().contains("Catalina")
|| event.getLoggerName().contains("o.s.b.f")
|| event.getLoggerName().contains("o.h.")
]]></expression>
</evaluator>
<OnMismatch>NEUTRAL</OnMismatch>
<OnMatch>DENY</OnMatch>
</filter>

也是沒有效果的。想來亂拆 Logback 與 Log4J 相比不會這么差勁的，再怎麼也是出自一人之手，想來思路應是一致的，還是該回到 <logger> 的配置上來。
還是 Google 威武，找到答案了：logback per-logger configuration is not working。原來像 "o.s.b.f"差陪畢 和 "o.h." 這樣的東西只是神馬浮雲，假象而已，它們實際所代表的 logger 名並未變，分別是:
org.springframework.beans.factory.support.DefaultListableBeanFactory
org.hibernate.loader.entity.EntityLoader
所以呢，在 logback.xml 中像 Log4J 一樣寫上
<logger name="org.hibernate" level="WARN"/>
<logger name="org.springframework" level="WARN"/>

就把 Spring 和 Hibernate 的日誌輸出稍加過濾了，都是 %logger{35} 中的那個 {35} 惹的禍，不過也靠它多了解了一點東西。如果只寫成 %logger 話那時候當然可以很快的解決問題的。

❷ 簡述入侵檢測常用的四種方法

入侵檢測系統所採用的技術可分為特徵檢測與異常檢測兩種。

1、特徵檢測

特徵檢測(Signature-based detection) 又稱Misuse detection ，這一檢測假設入侵者活動可以用一種模式來表示，系統的目標是檢測主體活動是否符合這些模式。

它可以將已有的入侵方法檢查出來，但對新的入侵方法無能為力。其難點在於如何設計模式既能夠表達「入侵」現象又不會將正常的活動包含進來。

2、異常檢測

異常檢測(Anomaly detection) 的假設是入侵者活動異常於正常主體的活動。根據這一理念建立主體正常活動的「活動簡檔」，將當前主體的活動狀況與「活動簡檔」相比較，當違反其統計規律時，認為該活動可能是「入侵」行為。

異常檢測的難題在於如何建立「活動簡檔」以及如何設計統計演算法，從而不把正常的操作作為「入侵」或忽略真正的「入侵」行為。

(2)包過濾日誌實驗擴展閱讀

入侵分類：

1、基於主機

一般主要使用操作系統的審計、跟蹤日誌作為數據源，某些也會主動與主機系統進行交互以獲得不存在於系統日誌中的信息以檢測入侵。

這種類型的檢測系統不需要額外的硬體．對網路流量不敏感，效率高，能准確定位入侵並及時進行反應，但是佔用主機資源，依賴於主機的可靠性，所能檢測的攻擊類型受限。不能檢測網路攻擊。

2、基於網路

通過被動地監聽網路上傳輸的原始流量，對獲取的網路數據進行處理，從中提取有用的信息，再通過與已知攻擊特徵相匹配或與正常網路行為原型相比較來識別攻擊事件。

此類檢測系統不依賴操作系統作為檢測資源，可應用於不同的操作系統平台；配置簡單，不需要任何特殊的審計和登錄機制；可檢測協議攻擊、特定環境的攻擊等多種攻擊。

但它只能監視經過本網段的活動，無法得到主機系統的實時狀態，精確度較差。大部分入侵檢測工具都是基於網路的入侵檢測系統。

3、分布式

這種入侵檢測系統一般為分布式結構，由多個部件組成，在關鍵主機上採用主機入侵檢測，在網路關鍵節點上採用網路入侵檢測，同時分析來自主機系統的審計日誌和來自網路的數據流，判斷被保護系統是否受到攻擊。

❸ 求助網路多媒體技術應用ARP協議分析

ARP協議分析

ARP（AddressResolutionProtocol）地址扮畢絕解析協議數鋒用於將計算機的網路地址（IP地址32位）轉化為物理地址（MAC地址48位）[RFC826]。ARP協議是屬於鏈路層的協議，在乙太網中的數據幀從一個主機到達網內的另一台主機是根據48位的乙太網地址（硬體地址）來確定介面的，而不是根據32位的IP地址。內核（如驅動）必須知道目的端的硬體地址才能發送數據。當然，點對點的連接是不需要ARP協議的。

ARP協議的數據結構：
typedefstructarphdr
{
unsignedshortarp_hrd;/*硬體類型*/
unsignedshortarp_pro;/*協議類型*/
unsignedchararp_hln;/*硬體地址長度*/
unsignedchararp_pln;/*協議地址長度*/
unsignedshortarp_op;/*ARP操作類型*/
unsignedchararp_sha[6];/*發送者的硬體地址*/
unsignedlongarp_spa;/*發送者的協議地址*/
unsignedchararp_tha[6];/*目標的硬體地址*/
unsignedlongarp_tpa;/*目標的協議地址*/
}ARPHDR,*PARPHDR;
為了解釋ARP協議的作用，就必須理解數據在網路上的傳輸過程。這里舉一個簡單的PING例子。
假設我們的計算機IP地址是192.168.1.1，要執行這個命令：ping192.168.1.2。該命令會通過ICMP協議發送ICMP數據包。該過程需要經過下面的步驟：
1、應用程序構造數據包，該示例是產生ICMP包，被提交給內核（網路驅動程序）；
2、內核檢查是否能夠轉化該IP地址為MAC地址，也就是在本地的ARP緩存中查看IP-MAC對應表；
3、如果存在該IP-MAC對應關系，那麼跳到步驟9；如果不存在該IP-MAC對應關系，那麼接續下面的步驟；
4、內核進行ARP廣播，目的地的MAC地址是FF-FF-FF-FF-FF-FF，ARP命令類型為REQUEST（1），其中包含有自己的MAC地址；
5、當192.168.1.2主機接收到該ARP請求後，就發送一個ARP的REPLY（2）命令，其中包含自己的MAC地址；
6、本地獲得192.168.1.2主機的IP-MAC地址對應關系，並保存到ARP緩存中；
7、內核將把IP轉化為MAC地址，然後封裝在乙太網頭結構中，再把數據發送出去；

使用arp-a命令就可以查看本地的ARP緩存內容，所以，執行一個本地的PING命令後，ARP緩存就會存在一個目的IP的記錄了。當然，如果你的數據包是發送到不同網段的目的地，那麼就一定存在一條網關的IP-MAC地址對應的記錄。

知道了ARP協議的作用，就能夠很清楚地知道，數據包的向外傳輸很依靠ARP協議，當然，也就是依賴ARP緩存。要知道，ARP協議的所有操作都是內核自動完成的，同其他的應用程序沒有任何關系。同時需要注意的是，ARP協議只使用於本網路。

ARP協議的利用和相關原理介紹。

一、交換網路的嗅探

ARP協議並不只在發送了ARP請求才接收ARP應答。當計算機接收到ARP應答數據包的時候，就會對本地的ARP緩存進行更新，將應答中的IP和MAC地址存儲在ARP緩存中。因此，在上面的假設網路中，B向A發送一個自己偽造的ARP應答，而這個應答中的數據為發送方IP地址是192.168.10.3（C的IP地址），MAC地址是DD-DD-DD-DD-DD-DD（C的MAC地址本來應該是CC-CC-CC-CC-CC-CC，這里被偽造了）。當A接收到B偽造的ARP應答，就會更新本地的ARP緩存，將本地的IP-MAC對應表更換為接收到的數據格式，由於這一切都是A的系統內核自動完成的，A可不知道被偽造了。

ARP欺騙的主要用途就是進行在交換網路中的嗅探。有關交換網路的嗅探不是本文的討論內容。

二、IP地址沖突

我們知道，如果網路中存在相同IP地址的主機的時候，就會報告出IP地址沖突的警告。這是怎麼產生的呢？

比如某主機B規定IP地址為192.168.0.1，如果它處於開機狀態，那麼其他機器A更
改IP地址為192.168.0.1就會造成IP地址沖突。其原理就是：主機廳姿A在連接網路（或更改IP地址）的時候就會向網路發送ARP包廣播自己的IP地址，也就是freearp。如果網路中存在相同IP地址的主機B，那麼B就會通過ARP來reply該地址，當A接收到這個reply後，A就會跳出IP地址沖突的警告，當然B也會有警告。

因此用ARP欺騙可以來偽造這個ARPreply，從而使目標一直遭受IP地址沖突警告的困擾。

三、阻止目標的數據包通過網關

比如在一個區域網內通過網關上網，那麼連接外部的計算機上的ARP緩存中就存在網關IP-MAC對應記錄。如果，該記錄被更改，那麼該計算機向外發送的數據包總是發送到了錯誤的網關硬體地址上，這樣，該計算機就不能夠上網了。

這里也主要是通過ARP欺騙進行的。有兩種辦法達到這樣的目的。

1、向目標發送偽造的ARP應答數據包，其中發送方的IP地址為網關的地址，而MAC地址則為一個偽造的地址。當目標接收到該ARP包，那麼就更新自身的ARP緩存。如果該欺騙一直持續下去，那麼目標的網關緩存一直是一個被偽造的錯誤記錄。當然，如果有些了解的人查看ARP-a，就知道問題所在了。

2、這種方法非常狠，欺騙網關。向網關發送偽造的ARP應答數據包，其中發送方的IP地址為目標的IP地址，而MAC地址則為一個偽造的地址。這樣，網關上的目標ARP記錄就是一個錯誤的，網關發送給目標的數據報都是使用了錯誤的MAC地址。這種情況下，目標能夠發送數據到網關，卻不能接收到網關的任何數據。同時，目標自己查看ARP-a卻看不出任何問題來。

四、通過ARP檢測混雜模式節點

在混雜模式中，網卡進行包過濾不同於普通模式。本來在普通模式下，只有本地地址的數據包或者廣播（多播等）才會被網卡提交給系統核心，否則的話，這些數據包就直接被網卡拋棄。現在，混合模式讓所有經過的數據包都傳遞給系統核心，然後被sniffer等程序利用。
通過特殊設計的ARP請求可以用來在一定程度上檢測處於混雜模式的節點，比如對網路中的每個節點都發送MAC地址為FF-FF-FF-FF-FF-FE的ARP請求。對於網卡來說這不是一個廣播地址（FF-FF-FF-FF-FF-FF），所以處於普通模式的節點就會直接拋棄該數據包，但是多數操作系統核心都認為這是一個廣播地址，如果有一般的sniffer程序存在，並設置網卡為混雜模式，那麼系統核心就會作出應答，這樣就可以判斷這些節點是否存在嗅探器了。

可以查看，很多基於ARP的攻擊都是通過ARP欺騙實現的。至於ARP欺騙的防範，還是盡可能使用靜態的ARP。對於WIN，使用arp-s來進行靜態ARP的設置。當然，如果能夠完全使用靜態的IP+MAC對應，就更好了，因為靜態的ARP緩存只是相對的。

當然，可以有一些方法來實現ARP欺騙的檢測。設置一個ARP的嗅探器，其中維護著一個本地網路的IP-MAC地址的靜態對應表，查看所有經過的ARP數據，並檢查其中的IP-MAC對應關系，如果捕獲的IP-MAC對應關系和維護的靜態對應關系對應不上，那麼就表明是一個欺騙的ARP數據包了。

一個ARP數據包發送程序源代碼和編譯好的EXE程序可以參考ARPSender程序。注意：需要先安裝WinPcap。

協議分析六類常見錯誤
協議分析器是網路管理員庫中最強有力的工具之一。它能將難處理、耗時長、讓CEO們感到惱火甚至不得不重啟所有機器的問題轉變為能短時處理、易於在每周例行狀態報告中反映的問題，為公司省下大量的時間與金錢。

然而，就像其它任何復雜工具一樣，它必須被適當運用才能獲得最大的效益。在使用協議分析器診斷網路故障時，應當盡量避免……

錯誤1分析器誤置

正確放置分析器對快速診斷故障具有決定性作用。設想分析器是置於網路中的窗口，猶如建築物窗口一般，視野的改變依賴於從哪個窗口看出去。從南面窗口望去是看不到建築物北面高速公路上交通的擁擠狀況的。在分析置於網路不當位置的分析器時，跟蹤往往要花很長時間。那麼，怎樣正確放置分析器呢？我們可以舉例說明。

以下為幾個可能出現的問題及原因分析：

設想A：一台主機，伺服器A，主機不能與其它任何主機通信。可能的原因：

1）伺服器A沒有正確配置；

2）伺服器A配置的網卡出錯；

3）伺服器A所在區域網出了問題；

4）伺服器A所在區域網段出錯。

設想B：一台主機，伺服器B，主機不能與遠程網X中的任何一台主機通信；且區域網或其它遠程網中的主機無任何故障（這就意味著問題不可能出現在伺服器B或伺服器B所在區域網段上）。

可能原因：

1）伺服器B有關網路X的部分配置錯誤；

2）伺服器B用於連接到網路X的路由器所在網段的連接出了問題；

3）伺服器B所在區域網與網路X的一處或多處鏈接出了問題；

4）網路X用於連接到伺服器B所在網路的路由器所在網段出了問題；

5）網路X出了問題。

設想C：一台主機，伺服器C，主機不能與區域網中另一主機通信，但與網路中其它主機通信正常（這意味著問題不可能出現在伺服器C或伺服器C所在區域網段）。

可能的原因：

1）主機C錯誤配置；

2）主機C網卡出現故障；

3）主機C所在區域網段出了問題。

設想D：一台主機，伺服器D，主機不能與一遠程主機通信，但與伺服器D所在區域網段的其它主機通信正常，到遠程網或遠程網自身的連接亦無故障。

可能原因：

1）主機D錯誤配置；

2）主機D網卡出錯；

3）主機D所在區域網段出了問題。

這些問題當中個別的不用分析器也可診斷或排除。例如：設想A中的第三種情況，就能通過檢查伺服器A所在區域網的其它主機決定故障所在；設想D中的第二和第三種情況亦能通過這種方法確定（假設主機D能與區域網中其它主機通信）。

一台伺服器或主機的錯誤配置通過檢測很容易被發現。但另外一些問題，像網路或網段中的故障，就需要分析器來診斷。

在以上所有可能的設想中，一開始或許會將分析器置於離最有可能出現問題的主機或是懷疑有問題的網路、網段盡可能近的地方，但是如果未發現有意義的問題，得准備好移動分析器，要知道，在出現故障的位置被確定以前，所做的一切都是建立在猜想基礎上的。在以上設想B的第三種情況中，伺服器B所在區域網和網路X中都應該有分析器，至少分析器應該能夠從一端被移動到另一端。

例如，一次故障中，一台伺服器突然停止了工作。人們起初懷疑是站點人員對伺服器實施了誤操作所致，實際上跟蹤器表明，是因為眾多主機向伺服器發送連接請求信息的同時伺服器卻沒有響應，致使伺服器死鎖。

在花了幾天時間來判斷到底伺服器出了什麼問題後，被告知觀察跟蹤器，於是請求站點操作員將跟蹤器從主機所在區域網（這里指設想B中第三種情況的網路X）移到伺服器所在區域網。結果發現訪問控制列表沒有被正確添加到伺服器所在區域網的路由器上，這份錯誤的訪問控制列表過濾了所有來源於客戶端主機所在網路的信息。假若當初多一些懷疑的話，就會發現在伺服器所在區域網中根本就沒見到過連接請求信息。因為沒有同時查看網路兩端的情況，致使站點很多天不能工作。

怎麼知道跟蹤器在網路的哪一端起作用呢？在跟蹤器中，發自客戶端主機的幀信息都具有實客戶端所有的源MAC地址，與此同時，目標MAC地址則存放在路由器中。

不幸的是，問題變得越來越復雜，僅僅知道分析器連接於哪個網路還不夠。當將一個區域網分解成多個部分時，首要的是去找到空閑Hub埠或同軸電纜的分接頭，然而，在網路交換環境下，並不是僅僅將分析器接入交換設備的空閑埠就萬事大吉了。

大多數交換設備都具備將特定埠指定為分接頭或映像埠的能力，只是所用術語因交換設備製造廠商不同而有別。如果所有來自或發往特定埠的通信同樣能發送到映像埠，這時只要將分析器連接到映像埠，所有設置即告完成。

但問題在於有些交換設備不能將兩埠之間的通信發送到映像埠。舉例說，在雙工環境下，作為監控的連接之一部分的兩台主機能同時發送信息，交換機也能接收每幀數據並將其傳輸到鏈接中的另外埠。但對於映像埠，必須對某一數據幀進行緩沖，如果這樣處理了太多幀，緩沖區就會溢出，數據幀就會丟失，跟蹤因此變得不可靠。更糟的是，根本就不知道是在跟蹤不可靠的線索。

某些交換設備支持內部分析器功能，這類交換機本身能夠俘獲傳向被跟蹤對象的數據幀。這種功能部件的可靠性依賴於交換機的緩沖容量。在某些情況下，我們不得不選擇映像埠或是內部分析器方式。但只要有可能，最好是將主機之一和分析器連接到Hub，並將Hub掛到交換機上。

為什麼這么做呢？這是因為即使確信交換機有足夠容量緩存所有數據幀，以至於映像埠或內部分析器不可能丟數據，跟蹤仍然是不可靠的。例如，標准乙太網中，一個處於交換機有故障埠的RJ45連接器每當交換機向伺服器傳輸數據幀時都會創建互動式會話，交換機將此解釋成為一次沖突並停止工作，當嘗試16次之後數據幀就會撤消，但數據幀仍被發送到映像埠，因此跟蹤器發現了數據幀並顯示伺服器響應失敗。另一種情況是：不合規格的配線導致1%的數據幀破壞。如果將分析器與第一種情況（任何位置的數據幀都能傳送）中提到的的主機一起掛到Hub，或者與第二種情況（網路中有被破壞的數據幀）中主機一起掛到Hub，接收交換機的埠會在未將數據幀發往映像埠之前就將它們撤消，跟蹤器沒有任何錯誤指示。當然，每當改變一種方式，都得冒一定風險來糾正可能出現的意外問題。如果RJ45連接器出現故障僅僅是因為沒有在交換機埠將其固定好，那麼只要將連接器重新插入Hub，故障或許也就不存在了，至少問題是得到了解決。

另外需要記住的是，對於交換設備，在其網段內每個埠都是有效的，因此當連接到伺服器的交換埠未發現問題時，應將Hub（或分析器）移動到主機或路由器交換埠。

還有，注意不能將Hub掛到雙工環境。有些分析器能以雙工方式工作，這類分析器有兩個乙太網口和一個功能模塊，功能模塊將通信對分為兩部分，並分別發送到每一乙太網口，之後軟體把從每個乙太網口接收來的數據結合成單一的跟蹤鏈。如果網路是雙工環境，就需要這種分析器。

錯誤2過多的過濾

過濾功能允許協議分析器忽略某些數據幀，從而為感興趣的幀騰出更多的俘獲緩沖空間。如果能過濾來源於較高協議層的數據，如IP地址和埠號以至更高層數據，則分析器幾乎很少需要基於源或目標MAC地址的過濾。然而，實際跟蹤中通常出現的問題是過濾太多。

有一個站點出現過這樣的故障：伺服器與一特定客戶端之間的連接出了問題，莫名其妙地斷開了，其它客戶端都沒有任何問題。由於客戶端與伺服器處在同一子網，一旦發生斷開現象，使客戶端與伺服器恢復連接的唯一辦法是重新啟動伺服器。

這個站點安裝了分析器，同時因為數據量大，配置了過濾器，只允許俘獲兩主機（基於MAC地址）之間的數據幀。前兩天中沒有發現問題，但在第三天問題出現了：跟蹤表明伺服器突然停止了發送多路會話和最後一次會話。當從伺服器端ping客戶端時，跟蹤器顯示伺服器沒有發送任何數據幀。站點操作員得出的結論是：TCP棧或操作系統出了問題。

於是請求另一次跟蹤，這次沒有使用過濾器。一天半以後俘獲了另一事件：跟蹤清楚表明伺服器持續發送數據，而與此同時卻再也沒有得到應答。經過更深層挖掘，發現伺服器數據幀的目標MAC地址突然改變了。

既然目標MAC地址不再與客戶端的相匹配，那麼第一次未使用過濾器的跟蹤就不再俘獲到MAC地址，同時表明伺服器已停止了工作。另外發現就在地址改變之前，伺服器無故收到帶有為客戶端IP地址配置的新MAC地址的ARP信息包，這導致伺服器升級ARP緩存並向錯誤主機發送數據。

通過ARP數據幀的源MAC地址由無故發送ARP的主機向下跟蹤，不知何故，主機居然同時配置了復用於客戶端的靜態IP地址和DHCP地址。當主機啟動時，分配的是靜態地址，這與伺服器相沖突，於是調用DHCP，正確地址才配置上。

基於這一點可得出這樣一個結論：用過濾器看似很有道理，但很多時候問題的根源往往以假象出現在過濾器之外，如果跟蹤器沒有表明問題的起因，過濾器應當關閉，或至少應當擴展一下，直至跟蹤器確實查出原因。僅當所有過濾器都關閉後跟蹤器仍無法查出問題起因，才可以得出結論——對網路已無計可施了。

錯誤3

俘獲時幀太短

前面例子中表明，站點操作員使用過濾器是因為網路中數據量過大。分析器僅能俘獲大約3分鍾時間的數據，這使得站點操作員幾乎不可能發現問題的發生並使分析器及時加以阻止以真正找到問題的起因。分析器能夠俘獲數據幀而沒有將它們填入俘獲緩沖區的時間長短取決於網路的速度、網路中幀的數量、幀的大小以及俘獲緩沖區的大小。

幾乎所有分析器都能控制俘獲數據幀的大小，這在處理連接問題和不太高協議層問題時顯得很有用。在通常情況下，只要俘獲數據的第一個64位元組也就足夠了。因此，如果網路中所有幀都是1024位元組而僅有3分鍾俘獲時間，那麼僅俘獲64位元組將允許有超過30分鍾的俘獲時間。

錯誤4

觸發器安裝不正確

觸發器告訴分析器執行某項操作，比如終止俘獲。當等待問題發生而又不知道將何時發生時，觸發器顯得很有用。

安裝觸發器意味著沒有必要隨時以手動方式來控制分析器。觸發器安裝的最大問題往往是沒有正確定義，這會大大延長解決問題的時間。

當然，應該詳細知道怎樣安裝觸發器，並且，若有可能，在使用之前進行測試。有時可以安裝另一台分析器來發送觸發數據幀，以確認俘獲分析觸發器已正確安裝。

使用觸發器帶來的另一問題是，許多分析器允許設置將被預觸發的俘獲緩沖區的百分比。舉例來說，可以指定50%的緩沖區在觸發之前俘獲，而另外50%的緩沖區在觸發之後俘獲。預觸發的百分比通常是0、25、50、75或100。

如果預觸發值設置不當，就有可能俘獲不到足夠的相關數據幀來診斷問題所在。預觸發值有可能被錯誤設置是因為其默認設置對現行問題往往不適用：也許是因為未將針對前一問題的設置升級，也許是因為粗心的滑鼠操作或錯誤按鍵。無論何種原因，一定要確認觸發器已正確安裝。

那麼怎樣來設置呢？通常是將預觸發百分比設為100%，以知道是什麼原因導致觸發器關閉。

當然，只有當觸發器在觸發某事件時，它才處於關閉狀態。過去使用過特殊的觸發程序，它能測試狀態，然後發送信息包，分析器可將此信息包用作觸發器。測試狀態可以是日誌文件中的錯誤信息，或是上例中無法創建連接的情況。一般整個程序也就一百多行或稍長一些。

錯誤5

日期/時間設置不正確

沒有正確設置分析器上的日期/時間看似一件小事，很多時候可能也確實是這樣。然而，當處理廣域網路中的問題時，有時同時運行兩台分析器，網路每端一台，則正確設置日期/時間是相當有用的。

如果將兩台分析器時鍾設置相同，調整跟蹤會變得更為容易。假定在一個例子中，通過發現通用幀並比較時間，會發現其中一台用了4小時37分，比另一台提前了15.7891秒，如果時鍾設置同步誤差在1到2秒，時間差距計算也就容易多了。

另外，如果需要費勁地隨主機中的事件調整跟蹤，由於基於時間包的同步是不可選的，則設置相同的日期/時間絕對具有實質意義。

錯誤6不理解協議

很多分析器具有「專家分析」功能，指的是它們能保持對信息的追蹤，像序列號、時間信息、顯示重傳信息、凍結窗口、無應答狀態等等。這類分析相當有用，但也有可能造成誤導，尤其在分析器沒有正確報錯時。

舉個例子，有一種情況：從一遠程位置發來的遠程登錄會話無法建立，而發自局域工作站的遠程登錄會話卻沒有問題。於是站點操作人員在遠程登錄伺服器所在的區域網掛一分析器，跟蹤器表明從遠程主機到遠程登錄伺服器的數據幀沒有報錯；於是他們得出結論是操作系統故障。

另一位操作人員查看跟蹤器發現，局域端遠程登錄會話連接到埠2323，而遠程會話連接到埠23。另外，遠程登錄伺服器響應遠程連接請求的信息包包含了RST標志設置。

在這里，站點操作人員沒有仔細查看TCP細節，因此沒有意識到不同埠號和RST包的重要性，他們依賴來源於分析器的診斷信息，既然遠程登錄伺服器的埠23沒有安裝，憑感覺猜想也認為是操作系統出了問題。然而，若站點工作人員了解TCP和遠程登錄，他們就會立即發現問題所在並能在5分鍾內找到一個好的解決辦法。

事實上是，他們等半天時間來安裝跟蹤器，結果失去了遠程網上數目相當可觀的客戶。

❹ 什麼是包過濾技術其特點是什麼

包過濾（Packet
Filtering）技術：是基於協議特定的標准，路由器在其埠能夠區分包和限制包的技術。
包過濾技術的特點：對小型的、不太復雜的站點包過濾較容易實現。但是他們很少有或沒有日誌記錄能力,
所以網路管理員很難確認系統是否正在被入侵或已經被入侵了。這種防火牆的最大缺陷是依賴一個單一的部件來保護系統。

❺ 迪普FW將包過濾日誌發送給UMC，UMC不顯示包過濾日誌

FW日誌發送格式需選擇為流日誌格式。包過濾日誌、會話日誌發送給UMC，格式需選擇「流日誌」。

❻ 什麼是過慮包技術

樓主說的是不是包過濾技術
包過濾技術

包過濾技術(IP Filtering or packet filtering) 的原理在於監視並過濾網路上流入流出的IP包，拒絕發送可疑的包。基於協議特定的標准，路由器在其埠能夠區分包和限制包的能力叫包過濾（Packet Filtering）。由於Internet 與Intranet 的連接多數都要使用路由器，所以Router成為內外通信的必經埠，Router的廠商在Router上加入IP 過濾 功能，過濾路由器也可以稱作包過濾路由器或篩選路由器（Packet Filter Router）。防火牆常常就是這樣一個具備包過濾功能的簡單路由器，這種Firewall應該是足夠安全的，但前提是配置合理。然而一個包過濾規則是否完全嚴密及必要是很難判定的，因而在安全要求較高的場合，通常還配合使用其它的技術來加強安全性。

常用的優秀的個人防火牆有Norman Personal Firewall、天網防火牆等。

路由器逐一審查數據包以判定它是否與其它包過濾規則相匹配。每個包有兩個部分：數據部分和包頭。過濾規則以用於IP順行處理的包頭信息為基礎，不理會包內的正文信息內容。包頭信息包括：IP 源地址、IP目的地址、封裝協議(TCP、UDP、或IP Tunnel)、TCP/UDP源埠、ICMP包類型、包輸入介面和包輸出介面。如果找到一個匹配，且規則允許這包，這一包則根據路由表中的信息前行。如果找到一個匹配，且規則拒絕此包，這一包則被舍棄。如果無匹配規則，一個用戶配置的預設參數將決定此包是前行還是被舍棄。

包過濾規則允許Router取捨以一個特殊服務為基礎的信息流，因為大多數服務檢測器駐留於眾所周知的TCP/UDP埠。例如，Telnet Service 為TCP port 23埠等待遠程連接，而SMTP Service為TCP Port 25埠等待輸入連接。如要封鎖輸入Telnet、SMTP的連接，則Router舍棄埠值為23、25的所有的數據包。

表9.1 一些常用網路服務和使用的埠

服務名稱
埠號
協議
說明

ftp-data
20
tcp
FTP數據

ftp
21
tcp
FTP控制

telnet
23
tcp
如BBS

smtp
25
tcp
發email用

time
37
tcp
timserver

time
37
udp
timserver

domain
53
tcp
DNS

domain
53
udp
DNS

tftp
69
udp

gopher
70
tcp
gopher查詢

http
80
tcp
www

pop3
110
tcp
收email用

nntp
119
tcp
新聞組，usernet

netbios-ns
137
tcp
NETBIOS 名稱服務

netbios-ns
137
udp
NETBIOS 名稱服務

netbios-dgm
138
udp
NETBIOS 數據報服務

netbios-ssn
139
tcp
NETBIOS Session服務

snmp
161
udp
SNMP

snmptrap
162
udp
SNMP trap

irc
194
tcp
IRC網路聊天服務

ldap
389
tcp
輕型目錄服務協議

https
443
tcp
SSL加密

https
443
udp

典型的過濾規則有以下幾種：允許特定名單內的內部主機進行Telnet輸入對話、只允許特定名單內的內部主機進行FTP輸入對話、只允許所有Telnet 輸出對話、只允許所有FTP 輸出對話、拒絕來自一些特定外部網路的所有輸入信息。

有些類型的攻擊很難用基本包頭信息加以鑒別，因為這些獨立於服務。一些Router可以用來防止這類攻擊，但過濾規則需要增加一些信息，而這些信息只有通過以下方式才能獲悉：研究Router選擇表、檢查特定的IP選項、校驗特殊的片段偏移等。這類攻擊有以下幾種：

源IP地址欺騙攻擊：入侵者從偽裝成源自一台內部主機的一個外部地點傳送一些信息包；這些信息包似乎像包含了一個內部系統的源IP地址。如果這些信息包到達Router的外部介面，則舍棄每個含有這個源IP地址的信息包，就可以挫敗這種源欺騙攻擊。

源路由攻擊：源站指定了一個信息包穿越Internet時應採取的路徑，這類攻擊企圖繞過安全措施，並使信息包沿一條意外(疏漏)的路徑到達目的地。可以通過舍棄所有包含這類源路由選項的信息包方式，來挫敗這類攻擊。

殘片攻擊：入侵者利用IP殘片特性生成一個極小的片斷並將TCP報頭信息肢解成一個分離的信息包片斷。舍棄所有協議類型為TCP、IP片斷偏移值等於1的信息包，即可挫敗殘片的攻擊。

從以上可看出定義一個完善的安全過濾規則是非常重要的。通常，過濾規則以表格的形式表示，其中包括以某種次序排列的條件和動作序列。每當收到一個包時，則按照從前至後的順序與表格中每行的條件比較，直到滿足某一行的條件，然後執行相應的動作(轉發或舍棄)。有些數據包過濾在實現時，「動作」這一項還詢問，若包被丟棄是否要通知發送者(通過發ICMP信息)，並能以管理員指定的順序進行條件比較，直至找到滿足的條件。

對流進和流出網路的數據進行過濾可以提供一種高層的保護。建議過濾規則如下：

（1）任何進入內部網路的數據包不能把網路內部的地址作為源地址。

（2）任何進入內部網路的數據包必須把網路內部的地址作為目的地址。

（3）任何離開內部網路的數據包必須把網路內部的地址作為源地址。

（4）任何離開內部網路的數據包不能把網路內部的地址作為目的地址。

（5）任何進入或離開內部網路的數據包不能把一個私有地址（private address）或在RFC1918中 127.0.0.0/8.）的地址作為源或目的地址。

（6）阻塞任意源路由包或任何設置了IP選項的包。

（7）保留、DHCP自動配置和多播地址也需要被阻塞。0.0.0.0/8 、169.254.0.0/16 、192.0.2.0/24 、224.0.0.0/4 、240.0.0.0/4。

包過濾路由器的優點：

（1）一個過濾路由器能協助保護整個網路。絕大多數Internet防火牆系統只用一個包過濾路由器；

（2）過濾路由器速度快、效率高。執行包過濾所用的時間很少或幾乎不需要什麼時間，由於過濾路由器只檢查報頭相應的欄位，一般不查看數據報的內容，而且某些核心部分是由專用硬體實現的，如果通信負載適中且定義的過濾很少的話，則對路由器性能沒有多大影響；

（3）包過濾路由器對終端用戶和應用程序是透明的。當數據包過濾路由器決定讓數據包通過時，它與普通路由器沒什麼區別，甚至用戶沒有認識到它的存在，因此不需要專門的用戶培訓或在每主機上設置特別的軟體。

包過濾路由器的局限性：

（1）定義包過濾器可能是一項復雜的工作。因為網管員需要詳細地了解Internet各種服務、包頭格式和他們在希望每個域查找的特定的值。如果必須支持復雜的過濾要求的，則過濾規則集可能會變得很長很復雜，並且沒有什麼工具可以用來驗證過濾規則的正確性。

（2）路由器信息包的吞吐量隨過濾器數量的增加而減少。路由器被優化用來從每個包中提取目的IP地址、查找一個相對簡單的路由表，而後將信息包順向運行到適當轉發介面。如果過濾可執行，路由器還必須對每個包執行所有過濾規則。這可能消耗CPU的資源，並影響一個完全飽和的系統性能。

（3）不能徹底防止地址欺騙。大多數包過濾路由器都是基於源IP地址、目的IP地址而進行過濾的，而IP地址的偽造是很容易、很普遍的。

（4）一些應用協議不適合於數據包過濾。即使是完美的數據包過濾，也會發現一些協議不很適合於經由數據包過濾安全保護。如RPC、X- Window和FTP。而且服務代理和HTTP的鏈接，大大削弱了基於源地址和源埠的過濾功能。

（5）正常的數據包過濾路由器無法執行某些安全策略。例如，數據包說它們來自什麼主機，而不是什麼用戶，因此，我們不能強行限制特殊的用戶。同樣地，數據包說它到什麼埠，而不是到什麼應用程序，當我們通過埠號對高級協議強行限制時，不希望在埠上有別的指定協議之外的協議，而不懷好意的知情者能夠很容易地破壞這種控制。

（6）一些包過濾路由器不提供任何日誌能力，直到闖入發生後，危險的封包才可能檢測出來。它可以阻止非法用戶進入內部網路，但也不會告訴我們究竟都有誰來過，或者誰從內部進入了外部網路，

與圖1封裝過程相反，在網路連接的
獲取數據就由下而上依次把包頭剝離。
另一邊（接收方）的工作是解包。即在另一邊，為了

在數據包過濾系統看來
種將被包過濾路由器檢查的
，包的最重要信息是各層依次加
包的包頭內容。
上的包頭。在下文中將主要介紹各

二、 數據包過濾是怎樣工作的

包過濾技術可以允許或不允許某些包在網路上傳遞，它依據以下的根據：
(1)將包的目的地址作為判斷依據；
(2)將包的源地址作為判斷依據；
(3)將包的傳送協議作為判斷依據。
大多數包過濾系統判斷是否傳送包時
讓我們進行類似以下情況的操作：
都不關心包的具體內容。作為防火牆包過濾系統只能

(1)不允許任何用戶從外部網用Telnet登錄；
(2)允許任何用戶使用SMTP往內部網發電子郵件；
(3)只允許某台機器通過NNTP往內部網發新聞。
但包過濾不能允許我們進行如下操作：
(1)允許某個用戶從外部網用Telnet登錄而不允許其它用戶進行這種操作；
(2)允許用戶傳送一些文件而不允許用戶傳送其它文件。
數據包過濾系統不能識
的文件信息。包過濾系統的
為例，假定不讓客戶使用Te
現有的條件下可以作到，但
其它用戶就永遠不在重新安
行設置，也就無所謂機器中
別數據包中的用戶信息。同樣數
主要特點是讓用戶在一台機器上
lnet而將網路中現有機器上的Te
是不能保證在網路中新增機器時
裝Telnet服務。如果有了包過濾
的Telnet服務是否存在的問題了
據包過濾系統也不能識別數據包中
提供對整個網路的保護。以Telnet
lnet服務關閉，作為系統管理員在
，新機器的Telnet服務也被關閉或
系統，由於只要在包過濾中對此進
。

路由器為所有用戶進出
絡中的特定位置的過濾路由
內部郵件的包——就是那種
常被作為地址偽裝入侵的一
濾路由器來實現我們設計的
在這種位置上的包過濾路由
網還是來自於外部網。
網路的數據流提供了一個有用的
器來提供。比如，我們考慮這樣
看起來好象來自於內部主機而其
部分。入侵者總是用這種包把他
安全規則，唯一的方法是通過參
器才能通過查看包的源地址，從

阻塞點。而對有關的保護只能由網
的安全規則，讓網路拒絕任何含有
實是來自於外部網的包，這種包經
們偽裝成來自於內部網。要用包過
數網路上的包過濾路由器。只有處
而辨認出這個包到底是來自於內部

三、 包過濾的優缺點

1.包過濾的優點
包過濾方式有許多優點
就可保護整個網路。如果站
這台路由器上設定合適的包
，而其主要優點之一是僅用一個
點與網際網路間只有一台路由器，
過濾，我們的站點就可以獲得很
放置在戰略要津上的包過濾路由器
那麼不管站點規模有多大，只要在
好的網路安全保護。

包過濾不需要用戶軟體的支撐，也不
何培訓。當包過濾路由器允許包通過時，
甚至感覺不到包過濾功能的存在，只有在
器的不同。包過濾工作對用戶來講是透明
下完成包過濾。
要求對客戶機做特別的設置，也沒有必要對用戶做任
它看起來與普通的路由器沒有任何區別。此時，用戶
有些包在禁入和禁出時，用戶才認識到它與普通路由
的。這種透明就是可在不要求用戶作任何操作的前提

包過濾產品比較容易獲得。在市場上
從網上免費下載的都提供了包過濾功能。
。Drawbrige、KralBrige以及Screened也
。
有許多硬體和軟體的路由器產品不管是商業產品還是
比如，Cisco公司的路由器產品就包含有包過濾功能
都具有包過濾功能，而且還能從Internet上免費下載

2. 包過濾的缺點
盡管包過濾系統有許多優點，但是它仍有缺點和局限性：
1） 在機器中配置包過濾規則比較困難；
2） 對包過濾規則設置的測試也很麻煩；
3） 許多產品的包過濾
。
功能有這樣或那樣的局限性，要

找一個比較完整的包過濾產品很難

包過濾系統本身就存有
系統的安全性的影響。因為
些平常應該拒絕的包也能進
某些缺陷，這些缺陷對系統的安
代理服務的缺陷僅僅會使數據無
出網路，這對系統的安全性是一
全性的影響要大大超過代理服務對
法傳送，而包過濾的缺陷會使得一
個巨大的威脅。

即使在系統中安裝了比較完整的包過
太合適。比如，對Berkeley的「r"命令（
，用包過濾系統就不太合適。有些安全規
來自於哪台主機的信息而無來自於哪個用
濾系統，我們也會發現對有些協議使用包過濾方式不
rcp、rsh、rlogin）和類似於NFS和NIS/YS協議的RPC
則是難以用包過濾規則來實現的。比如，在包中只有
戶的信息。因此，若要過濾用戶就不能使用包過濾。

❼ 包過濾防火牆

1.1 包過濾防火牆的一般概念
1.1.1 什麼是包過濾防火牆
包過濾防火牆是用一個軟體查看所流經的數據包的包頭（header），由此決定整個包的命運。它可能會決定丟棄（DROP）這個包，可能會接受（ACCEPT）這個包（讓這個包通過），也可能執行其它更復雜的動作。
在Linux系統下,包過濾功能是內建於核心的（作為一個核心模塊，或者直接內建），同時還有一些可以運用於數據包之上的技巧，不過最常用的依然是查看包頭以決定包的命運。
包過濾防火牆將對每一個接收到的包做出允許或拒絕的決定。具體地講，它針對每一個數據報的報頭，按照包過濾規則進行判定，與規則相匹配的包依據路由信息繼續轉發，否則就丟棄。包過濾是在IP層實現的，包過濾根據數據包的源IP地址、目的IP地址、協議類型（TCP包、UDP包、ICMP包）、源埠、目的埠等報頭信息及數據包傳輸方向等信息來判斷是否允許數據包通過。
包過濾也包括與服務相關的過濾，這是指基於特定的服務進行包過濾，由於絕大多數服務的監聽都駐留在特定TCP/UDP埠，因此，為阻斷所有進入特定服務的鏈接，防火牆只需將所有包含特定TCP/UDP目的埠的包丟棄即可。
1.1.2 包過濾防火牆的工作層次
包過濾是一種內置於Linux內核路由功能之上的防火牆類型，其防火牆工作在網路層。
1.1.3 包過濾防火牆的工作原理
（1）使用過濾器。數據包過濾用在內部主機和外部主機之間， 過濾系統是一台路由器或是一台主機。過濾系統根據過濾規則來決定是否讓數據包通過。用於過濾數據包的路由器被稱為過濾路由器。
數據包過濾是通過對數據包的IP頭和TCP頭或UDP頭的檢查來實現的，主要信息有：
* IP源地址
* IP目標地址
* 協議（TCP包、UDP包和ICMP包）
* TCP或UDP包的源埠
* TCP或UDP包的目標埠
* ICMP消息類型
* TCP包頭中的ACK位
* 數據包到達的埠
* 數據包出去的埠
在TCP/IP中，存在著一些標準的服務埠號，例如，HTTP的埠號為80。通過屏蔽特定的埠可以禁止特定的服務。包過濾系統可以阻塞內部主機和外部主機或另外一個網路之間的連接，例如，可以阻塞一些被視為是有敵意的或不可信的主機或網路連接到內部網路中。
（2）過濾器的實現。數據包過濾一般使用過濾路由器來實現，這種路由器與普通的路由器有所不同。
普通的路由器只檢查數據包的目標地址，並選擇一個達到目的地址的最佳路徑。它處理數據包是以目標地址為基礎的，存在著兩種可能性：若路由器可以找到一個路徑到達目標地址則發送出去；若路由器不知道如何發送數據包則通知數據包的發送者「數據包不可達」。
過濾路由器會更加仔細地檢查數據包，除了決定是否有到達目標地址的路徑外，還要決定是否應該發送數據包。「應該與否」是由路由器的過濾策略決定並強行執行的。
路由器的過濾策略主要有：
* 拒絕來自某主機或某網段的所有連接。
* 允許來自某主機或某網段的所有連接。
* 拒絕來自某主機或某網段的指定埠的連接。
* 允許來自某主機或某網段的指定埠的連接。
* 拒絕本地主機或本地網路與其它主機或其它網路的所有連接。
* 允許本地主機或本地網路與其它主機或其它網路的所有連接。
* 拒絕本地主機或本地網路與其它主機或其它網路的指定埠的連接。
* 允許本地主機或本地網路與其它主機或其它網路的指定埠的連接。
1.1.4 包過濾器操作的基本過程
下面做個簡單的敘述：
（1）包過濾規則必須被包過濾設備埠存儲起來。
（2）當包到達埠時，對包報頭進行語法分析。大多數包過濾設備只檢查IP、TCP、或UDP報頭中的欄位。
（3）包過濾規則以特殊的方式存儲。應用於包的規則的順序與包過濾器規則存儲順序必須相同。
（4）若一條規則阻止包傳輸或接收，則此包便不被允許。
（5）若一條規則允許包傳輸或接收，則此包便可以被繼續處理。
（6）若包不滿足任何一條規則，則此包便被阻塞。
1.1.5 包過濾技術的優缺點
（1）優點：
→對於一個小型的、不太復雜的站點，包過濾比較容易實現。
→因為過濾路由器工作在IP層和TCP層，所以處理包的速度比代理伺服器快。
→過濾路由器為用戶提供了一種透明的服務，用戶不需要改變客戶端的任何應用程序，也不需要用戶學習任何新的東西。因為過濾路由器工作在IP層和TCP層，而IP層和TCP層與應用層的問題毫不相關。所以，過濾路由器有時也被稱為「包過濾網關」或「透明網關」，之所被稱為網關，是因為包過濾路由器和傳統路由器不同，它涉及到了傳輸層。
→過濾路由器在價格上一般比代理伺服器便宜。
（2）缺點：
→一些包過濾網關不支持有效的用戶認證。
→規則表很快會變得很大而且復雜，規則很難測試。隨著表的增大和復雜性的增加，規則結構出現漏洞的可能 性也會增加。
→這種防火牆最大的缺陷是它依賴一個單一的部件來保護系統。如果這個部件出現了問題，會使得網路大門敞開，而用戶其至可能還不知道。
→在一般情況下，如果外部用戶被允許訪問內部主機，則它就可以訪問內部網上的任何主機。
→包過濾防火牆只能阻止一種類型的IP欺騙，即外部主機偽裝內部主機的IP，對於外部主機偽裝外部主機的IP欺騙卻不可能阻止，而且它不能防止DNS欺騙。
雖然，包過濾防火牆有如上所述的缺點，但是在管理良好的小規模網路上，它能夠正常的發揮其作用。一般情況下，人們不單獨使用包過濾網關，而是將它和其他設備（如堡壘主機等）聯合使用。
包過濾的工作是通過查看數據包的源地址、目的地址或埠來實現的，一般來說，它不保持前後連接信息，過濾決定是根據 當前數據包的內容來做的。管理員可以做一個可接受機和服務的列表，以及一個不可接受機和服務的列表。在主機和網路一級，利用數據包過濾很容易實現允許或禁止訪問。
由此不難看出這個層次的防火牆的優點和弱點，由於防火牆只是工作在OSI的第三層（網路層）和第四層（傳輸層），因此包過濾的防火牆的一個非常明顯的優勢就是速度，這是因為防火牆只是去檢查數據報的報頭，而對數據報所攜帶的內容沒有任何形勢的檢查，因此速度非常快。與此同時，這種防火牆的缺點也是顯而易見的，比較關鍵的幾點如下所述。
（1）由於無法對數據報的內容進行核查，一次無法過濾或審核數據報的內容
體現這一問題的一個很簡單的例子就是：對某個埠的開放意味著相應埠對應的服務所能夠提供的全部功能都被開放，即使通過防火牆的數據報有攻擊性，也無法進行控制和阻斷。例如在一個簡單的Web伺服器，而包過濾的防火牆無法對數據報內容進行核查。因此，未打相應補丁的提供Web服務的系統，及時在防火牆的屏蔽之後，也會被攻擊著輕易獲取超級用戶的許可權。
（2）由於此種類型的防火牆工作在較低層次，防火牆本身所能接觸道德信息較少，所以它無法提供描述細致事件的日誌系統。
此類防火牆生成的日誌常常只是包括數據報捕獲的時間、網路層的IP地址、傳輸層的埠等非常原始的信息。至於這個數據報內容是什麼，防火牆不會理會，而這對安全管理員而言恰恰是很關鍵的。因為及時一個非常優秀的系統管理員，一旦陷入大量的通過/屏蔽的原始數據包信息中，往往也是難以理清頭緒，這在發生安全事件時給管理員的安全審計帶來很大的困難。
（3）所有可能用到的埠（尤其是大於1024的埠）都必須開放，對外界暴露，從而極大地增加了被攻擊的可能性
通常對於網路上所有服務所需要的數據包進出防火牆的二埠都要仔細考慮，否則會產生意想不到的情況。然而我們知道，當被防火牆保護的設備與外界通信時，絕大多數應用要求發出請求的系統本身提供一個埠，用來接收外界返回的數據包，而且這個埠一般是在1024到65536之間不確定的，如果不開發那個這些埠，通信將無法完成，這樣就需要開發那個1024以上的全部埠，允許這些埠的數據包進出。而這就帶來非常大的安全隱患。例如：用戶網中有一台UNIX伺服器，對內部用戶開放了RPC服務，而這個服務是共做在高埠的，那麼這台伺服器非常容易遭到基於RPC應用的攻擊。
（4）如果網路結構比較復雜，那麼對管理員而言配置訪問控制規則將非常困難
當網路發展到一定規模時，在路由器上配置訪問控制規則將會非常繁瑣，在一個規則甚至一個地址處出現錯誤都有可能導致整個訪問控制列表無法正常使用。

❽ 急!!!利用 iptables 實現 linux 防火牆功能有關問題

自己看:
什麼是Iptables？

iptables 是建立在 netfilter 架構基礎上的一個包過濾管理工具，最主要的作用是用來做防火牆或透明代理。Iptables 從 ipchains 發展而來，它的功能更為強大。Iptables 提供以下三種功能：包過濾、NAT（網路地址轉換）和通用的 pre-route packet mangling。包過濾：用來過濾包，但是不修改包的內容。Iptables 在包過濾方面相對於 ipchians 的主要優點是速度更快，使用更方便。NAT：NAT 可以分為源地址 NAT 和目的地址 NAT。

Iptables 可以追加、插入或刪除包過濾規則。實際上真正執行這些過慮規則的是 netfilter 及其相關模塊（如 iptables 模塊和 nat 模塊）。Netfilter 是 Linux 核心中一個通用架構，它提供了一系列的 「表」（tables），每個表由若干 「鏈」（chains）組成，而每條鏈中可以有一條或數條 「規則」（rule）組成。

系統預設的表為 「filter」，該表中包含了 INPUT、FORWARD 和 OUTPUT 3 個鏈。

每一條鏈中可以有一條或數條規則，每一條規則都是這樣定義的：如果數據包頭符合這樣的條件，就這樣處理這個數據包。當一個數據包到達一個鏈時，系統就會從第一條規則開始檢查，看是否符合該規則所定義的條件： 如果滿足，系統將根據該條規則所定義的方法處理該數據包；如果不滿足則繼續檢查下一條規則。最後，如果該數據包不符合該鏈中任一條規則的話，系統就會根據該鏈預先定義的策略來處理該數據包。

? table，chain，rule

iptables 可以操縱3 個表：filter 表，nat 表，mangle 表。

NAT 和一般的 mangle 用 -t 參數指定要操作哪個表。filter 是默認的表，如果沒有 -t 參數，就默認對 filter 表操作。

Rule 規則：過濾規則，埠轉發規則等，例如：禁止任何機器 ping 我們的伺服器，可以在伺服器上設置一條規則：

iptables -A INPUT -s ! 127.0.0.1 -p icmp -j DROP

從 –s 開始即是一條規則，-j 前面是規則的條件，-j 開始是規則的行為（目的）。整條命令解釋為，在filter 表中的 INPUT 規則鏈中插入一條規則，所有源地址不為 127.0.0.1 的 icmp 包都被拋棄。

Chain 規則鏈：由一系列規則組成，每個包順序經過 chain 中的每一條規則。chain 又分為系統 chain和用戶創建的 chain。下面先敘述系統 chain。

filter 表的系統 chain： INPUT，FORWAD，OUTPUT

nat 表的系統 chain： PREROUTING，POSTROUTING，OUTPUT

mangle 表的系統 chain： PREROUTING，OUTPUT

每條系統 chain 在確定的位置被檢查。比如在包過濾中，所有的目的地址為本地的包，則會進入INPUT 規則鏈，而從本地出去的包會進入 OUTPUT 規則鏈。

所有的 table 和 chain 開機時都為空，設置 iptables 的方法就是在合適的 table 和系統 chain 中添相應的規則。

--------------------------------------------------------------

IPTABLES 語法：

表: iptables從其使用的三個表（filter、nat、mangle）而得名, 對包過濾只使用 filter 表, filter還是默認表,無需顯示說明.

操作命令: 即添加、刪除、更新等。

鏈：對於包過濾可以針對filter表中的INPUT、OUTPUT、FORWARD鏈，也可以操作用戶自定義的鏈。

規則匹配器：可以指定各種規則匹配，如IP地址、埠、包類型等。

目標動作：當規則匹配一個包時，真正要執行的任務，常用的有：

ACCEPT 允許包通過

DROP 丟棄包

一些擴展的目標還有：

REJECT 拒絕包，丟棄包同時給發送者發送沒有接受的通知

LOG 包有關信息記錄到日誌

TOS 改寫包的TOS值

為使FORWARD規則能夠生效,可使用下面2種方法的某種:

[root@rhlinux root]# vi /proc/sys/net/ipv4/ip_forward
[root@rhlinux root]# echo "1" > /proc/sys/net/ipv4/ip_forward

[root@rhlinux root]# vi /etc/sysconfig/network
[root@rhlinux root]# echo "FORWARD_IPV4=true" > /etc/sysconfig/network

--------------------------------------------------------

iptables語法可以簡化為下面的形式:

iptables [-t table] CMD [chain] [rule-matcher] [-j target]

--------------------------------------------------------

常用操作命令:

-A 或 -append 在所選鏈尾加入一條或多條規則

-D 或 -delete 在所選鏈尾部刪除一條或者多條規則

-R 或 -replace 在所選鏈中替換一條匹配規則

-I 或 -insert 以給出的規則號在所選鏈中插入一條或者多條規則. 如果規則號為1,即在鏈頭部.

-L 或 -list 列出指定鏈中的所有規則,如果沒有指定鏈,將列出鏈中的所有規則.

-F 或 -flush 清除指定鏈和表中的所由規則, 假如不指定鏈,那麼所有鏈都將被清空.

-N 或 -new-chain 以指定名創建一條新的用戶自定義鏈,不能與已有鏈名相同.

-X 或 -delete-chain 刪除指定的用戶定義簾,必需保證鏈中的規則都不在使用時才能刪除,若沒有指定鏈,則刪除所有用戶鏈.

-P 或 -policy 為永久簾指定默認規則(內置鏈策略),用戶定義簾沒有預設規則,預設規則也使規則鏈中的最後一條規則,用-L顯示時它在第一行顯示.

-C 或 -check 檢查給定的包是否與指定鏈的規則相匹配.

-Z 或 -zero 將指定簾中所由的規則包位元組(BYTE)計數器清零.

-h 顯示幫助信息.

-------------------------------------------------------------

常用匹配規則器:

-p , [!] protocol 指出要匹配的協議,可以是tcp, udp, icmp, all, 前綴!為邏輯非,表示除該協議外的所有協議.

-s [!] address[/mask] 指定源地址或者地址范圍.

-sport [!] port[:port] 指定源埠號或范圍,可以用埠號也可以用/ETC/SERVICES文件中的名子.

-d [!] address[/mask] 指定目的地址或者地址范圍.

-dport [!] port[:port] 指定目的埠號或范圍,可以用埠號也可以用/ETC/SERVICES文件中的名子.

-icmp-type [!] typename 指定匹配規則的ICMP信息類型(可以使用 iptables -p icmp -h 查看有效的ICMP類型名)

-i [!] interface name[+] 匹配單獨或某種類型的介面,此參數忽略時,默認符合所有介面,介面可以使用"!"來匹配捕食指定介面來的包.參數interface是介面名,如 eth0, eht1, ppp0等,指定一個目前不存在的介面是完全合法的,規則直到介面工作時才起作用,折中指定對於PPP等類似連接是非常有用的."+"表示匹配所有此類型介面.該選項只針對於INPUT,FORWARD和PREROUTING鏈是合法的.

-o [!] interface name[+] 匹配規則的對外網路介面,該選項只針對於OUTPUT,FORWARD,POSTROUTING鏈是合法的.

[!] --syn 僅僅匹配設置了SYN位, 清除了ACK, FIN位的TCP包. 這些包表示請求初始化的TCP連接.阻止從介面來的這樣的包將會阻止外來的TCP連接請求.但輸出的TCP連接請求將不受影響.這個參數僅僅當協議類型設置為了TCP才能使用. 此參數可以使用"!"標志匹配已存在的返回包,一般用於限制網路流量,即只允許已有的,向外發送的連接所返回的包.

----------------------------------------------------------

如何制定永久規則集:

/etc/sysconfig/iptables 文件是 iptables 守護進程調用的默認規則集文件.

可以使用以下命令保存執行過的IPTABLES命令:

/sbin/iptables-save > /etc/sysconfig/iptables

要恢復原來的規則庫,可以使用:

/sbin/iptables-restore < /etc/sysconfig/iptables

iptables命令和route等命令一樣,重啟之後就會恢復,所以:

[root@rhlinux root]# service iptables save
將當前規則儲存到 /etc/sysconfig/iptables： [ 確定 ]

令一種方法是 /etc/rc.d/init.d/iptables 是IPTABLES的啟動腳本,所以:

[root@rhlinux root]# /etc/rc.d/init.d/iptables save
將當前規則儲存到 /etc/sysconfig/iptables： [ 確定 ]

以上幾種方法只使用某種即可.

若要自定義腳本,可直接使用iptables命令編寫一個規則腳本,並在啟動時執行:

例如若規則使用腳本文件名/etc/fw/rule, 則可以在/etc/rc.d/rc.local中加入以下代碼:

if [-x /etc/fw/rule]; then /etc/fw/sule; fi;

這樣每次啟動都執行該規則腳本,如果用這種方法,建議NTSYSV中停止IPTABLES.

----------------------------------------------------------

實例：

鏈基本操作：

[root@rh34 root]# iptables -L -n
（列出表/鏈中的所有規則，包過濾防火牆默認使用的是filter表，因此使用此命令將列出filter表中所有內容，-n參數可加快顯示速度，也可不加-n參數。）

[root@rh34 root]# iptables -F
（清除預設表filter中所有規則鏈中的規則）

[root@rh34 root]# iptables -X
（清除預設表filter中使用者自定義鏈中的規則）

[root@rh34 root]# iptables -Z
（將指定鏈規則中的所有包位元組計數器清零）

------------------------------------------------------------

設置鏈的默認策略，默認允許所有，或者丟棄所有：

[root@rh34 root]# iptables -P INPUT ACCEPT
[root@rh34 root]# iptables -P OUTPUT ACCEPT
[root@rh34 root]# iptables -P FORWARD ACCEPT
（以上我們在不同方向設置默認允許策略，若丟棄則應是DROP，嚴格意義上防火牆應該是DROP然後再允許特定）

---------------------------------------------------------------

向鏈中添加規則，下面的例子是開放指定網路介面（信任介面時比較實用）：

[root@rh34 root]# iptables -A INPUT -i eth1 -j ACCEPT
[root@rh34 root]# iptables -A OUTPUT -o eth1 -j ACCEPT
[root@rh34 root]# iptables -A FORWARD -i eth1 -j ACCEPT
[root@rh34 root]# iptables -A FORWARD -o eth1 -j ACCEPT

--------------------------------------------------------------

使用用戶自定義鏈：

[root@rh34 root]# iptables -N brus
（創建一個用戶自定義名叫brus的鏈）

[root@rh34 root]# iptables -A brus -s 0/0 -d 0/0 -p icmp -j DROP
（在此鏈中設置了一條規則）

[root@rh34 root]# iptables -A INPUT -s 0/0 -d 0/0 -j brus
（向默認的INPUT鏈添加一條規則，使所有包都由brus自定義鏈處理）

----------------------------------------------------------------

基本匹配規則實例：

匹配協議：

iptables -A INPUT -p tcp
（指定匹配協議為TCP）

iptables -A INPUT -p ! tcp
（指定匹配TCP以外的協議）

匹配地址：

iptables -A INPUT -s 192.168.1.1
（匹配主機）

iptables -A INPUT -s 192.168.1.0/24
（匹配網路）

iptables -A FORWARD -s ! 192.168.1.1
（匹配以外的主機）

iptables -A FORWARD -s ! 192.168.1.0/24
（匹配以外的網路）

匹配介面：

iptables -A INPUT -i eth0
iptables -A FORWARD -o eth0
（匹配某個指定的介面）

iptables -A FORWARD -o ppp+
（匹配所有類型為ppp的介面）

匹配埠：

iptables -A INPUT -p tcp --sport www
iptables -A INPUT -p tcp --sport 80
（匹配單一指定源埠）

iptables -A INPUT -p ucp --dport 53
（匹配單一指定目的埠）

iptables -A INPUT -p ucp --dport ! 53
（指定埠以外）

iptables -A INPUT -p tcp --dport 22:80
（指定埠范圍，這里我們實現的是22到80埠）

---------------------------------------------------------------------------------

指定IP碎片的處理：

[root@rh34 root]# iptables -A FORWARD -p tcp -s 192.168.1.0/24 -d 192.168.1.234 --dport 80 -j ACCEPT
[root@rh34 root]# iptables -A FORWARD -f -p tcp -s 192.168.1.0/24 -d 192.168.1.234 --dport 80 -j ACCEPT

[root@rh34 root]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 192.168.1.0/24 192.168.1.234 tcp dpt:http
ACCEPT tcp -f 192.168.1.0/24 192.168.1.234 tcp dpt:http

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

----------------------------------------------------------------------------------

設置擴展的規測匹配：

（希望獲得匹配的簡要說明，可使用： iptables -m name_of_match --help）

多埠匹配擴展：

iptables -A INPUT -p tcp -m multiport --source-port 22,53,80
（匹配多個源埠）

iptables -A INPUT -p tcp -m multiport --destination-port 22,53,80
（匹配多個目的埠）

iptables -A INPUT -p tcp -m multiport --port 22,53,80
（匹配多個埠，無論是源還是目的埠）

-----------------------------------------------------------------------------

TCP匹配擴展：

iptables -A INPUT -p tcp --tcp-flags SYN,FIN,ACK SYN
（表示SYN、ACK、FIN的標志都要被檢查，但是只有設置了SYN的才匹配）

iptables -A INPUT -p tcp --tcp-flags ALL SYN,ACK
（表示ALL：SYN、ACK、FIN、RST、URG、PSH的標志都被檢查，但是只有設置了SYN和ACK的才匹配）

iptables -p tcp --syn
（選項--syn是以上的一種特殊情況，相當於「--tcp-flags SYN,RST,ACK SYN」的簡寫）

--------------------------------------------------------------------------------

limit速率匹配擴展：

[root@redhatlinux9 root]# iptables -A FORWARD -m limit --limit 300/hour
（表示限制每小時允許通過300個數據包）

[root@redhatlinux9 root]# iptables -A INPUT -m limit --limit-burst 10
（--limit-burst指定觸發時間的值(默認為5)，用來比對瞬間大量數據包的數量。）
（上面的例子用來比對一次同時湧入的數據包是否超過十個，超過此上限的包將直接被丟棄）

[root@redhatlinux9 root]# iptables -A FORWARD -p icmp -m limit --limit 3/m --limit-burst 3
（假設均勻通過，平均每分鍾3個，那麼觸發值burst保持為3。如果每分鍾通過的包的數目小於3，那麼觸發值busrt將在每個周期(若每分鍾允許通過3個，則周期數為20秒)後加1，但最大值為3。每分鍾要通過的包數量如果超過3，那麼觸發值busrt將減掉超出的數值，例如第二分鍾有4個包，那麼觸發值變為2，同時4個包都可以通過，第三分鍾有6個包，則只能通過5個，觸發值busrt變為0。之後，每分鍾如果包數量小於等於3個，則觸發值busrt將加1，如果每分鍾包數大於3，觸發值busrt將逐漸減少，最終維持為0）
（即每分鍾允許的最大包數量等於限制速率(本例中為3)加上當前的觸發值busrt數。任何情況下，都可以保證3個包通過，觸發值busrt相當於是允許額外的包數量）

---------------------------------------------------------------------------------

基於狀態的匹配擴展（連接跟蹤）：

每個網路連接包括以下信息：源和目的地址、源和目的埠號，稱為套接字對(cocket pairs)；協議類型、連接狀態(TCP協議)和超時時間等。防火牆把這些叫做狀態(stateful)。能夠監測每個連接狀態的防火牆叫做狀態寶過濾防火牆，除了能完成普通包過濾防火牆的功能外，還在自己的內存中維護一個跟蹤連接狀態的表，所以擁有更大的安全性。

其命令格式如下：

iptables -m state --state [!] state [,state,state,state]

state表示一個用逗號隔開的的列表，用來指定的連接狀態可以有以下4種：

NEW：該包想要開始一個連接（重新連接或將連接重定向）。

RELATED：該包屬於某個已經建立的連接所建立的新連接。例如FTP的數據傳輸連接和控制連接之間就是RELATED關系。

ESTABLISHED：該包屬於某個已經建立的連接。

INVALID：該包不匹配於任何連接，通常這些包會被DROP。

例如：

[root@redhatlinux9 root]# iptables -A INPUT -m state --state RELATED,ESTABLISHED
（匹配已經建立的連接或由已經建立的連接所建立的新連接。即匹配所有的TCP回應包）

[root@redhatlinux9 root]# iptables -A INPUT -m state --state NEW -i ! eth0
（匹配所有從非eth0介面來的連接請求包）

下面是一個被動(Passive)FTP連接模式的典型連接跟蹤
[root@redhatlinux9 root]# iptables -A INPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT
[root@redhatlinux9 root]# iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT

下面是一個主動(Active)FTP連接模式的典型連接跟蹤
[root@redhatlinux9 root]# iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
[root@redhatlinux9 root]# iptables -A INPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT

--------------------------------------------------------------------------------------

日誌記錄：

格式為： -j LOG --log-level 7 --log-prefix "......"

[root@redhatlinux9 root]# iptables -A FORWARD -m tcp -p tcp -j LOG

[root@redhatlinux9 root]# iptables -A FORWARD -m icmp -p icmp -f -j LOG

[root@redhatlinux9 root]# iptables -A FORWARD -s 192.168.1.0/24 -d 10.10.10.0/24 -p tcp --sport 80 -j LOG

[root@redhatlinux9 root]# iptables -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-prefix "INPUT packet died:"

[root@redhatlinux9 root]# iptables -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New net syn:"

------------------------------------------------

回答你的問題:

1:設置為DROP默認不允許,然後你再開啟,這樣比門戶大開再阻止某些服務來的安全(避免遺漏)

2:前面阻止了後面就無效了,有先後順序的.

3:你了解了服務和埠號等即可用規則限制.

❾ 迪普防火牆配置包過濾日誌存儲到本地，本地查詢不到，怎麼回事

包過濾策略的動作是否勾選命中日誌，本地存儲日誌條數有限，查詢當天日誌確認是否正常，建議日誌發送迪普的統一管理平台UMC上存儲。

❿ android 怎麼使用應用的包名通過logcat命令來過濾某個應用的日誌

本文介紹如何在 shell 命令行中過濾 adb logcat 輸出的幾個小技巧。 開發當中經常看到別人的 log 如洪水般瞬間刷滿了屏幕，對自己有用的信息都被淹沒了，影響心情也影響效率。下面是幾個我所知道的過濾方法。 1. 只顯示需要的輸出，白名單 最方便的當然是通過管道使用 grep 過濾了，這樣可以使用 grep 強大的正則表達式匹配。簡單的匹配一行當中的某個字元串，例如 MyApp： adb logcat grep MyApp adb logcat grep -i myapp #忽略大小寫。 adb logcat grep --color=auto -i myapp #設置匹配字元串顏色。更多設置請查看 grep 幫助。 進階一點可以使用 grep 的正則表達式匹配。例如上一個例子會匹配一行中任意位置的 MyApp，可以設置為僅匹配 tag。默認的 log 輸出如下，如果修改過輸出格式相應的表達式也要修改。 I/CacheService( 665): Preparing DiskCache for all thumbnails. 可以看出 tag 是一行開頭的第三個字元開始，根據這點寫出表達式： adb logcat grep "^..MyApp" 根據這個格式也可以設置只顯示某個優先順序的 log，再匹配行首第一個字元即可。例如僅顯示 Error 級別 tag 為 MyApp 的輸出： adb logcat grep "^E.MyApp" 當然也可以匹配多個，使用 分割多個匹配表達式，要加轉義符。例如要匹配 tag 為 MyApp 和 MyActivity 的輸出： adb logcat grep "^..MyApp\^..MyActivity" adb logcat grep -E "^..MyApp^..MyActivity" #使用 egrep 無須轉義符 2. 過濾不需要的輸出，黑名單 還是使用 grep，用法也跟上面的一樣，加一個 -v 即可。例如要過濾 tag 為 MyApp 和 MyActivity 的輸出： adb logcat grep -v "^..MyApp\^..MyActivity" adb logcat grep -vE "^..MyApp^..MyActivity" #使用 egrep 無須轉義符 3. 顯示同一個進程的所有輸出 有時一個程序裡面的 tag 有多個，需要輸出該程序（同一個 PID）的所有 tag；僅使用 tag 過濾有時也會漏掉一些錯誤信息，而一般錯誤信息也是和程序同一個 PID。還是通過 grep 實現，思路是先根據包名找到 pid 號，然後匹配 pid。寫成 shell 腳本如下，參數是程序的 java 包名（如 com.android.media）。 查看源代碼列印幫助 1 #!/bin/bash 2 packageName=$1 3 pid=`adb shell ps grep $packageName awk '{print $2}'` 4 adb logcat grep --color=auto $pid 4. 從當前開始顯示 logcat 有緩存，如果僅需要查看當前開始的 log，需要清空之前的。 adb logcat -c && adb logcat 5. 過濾 log 文件 有時需要分析 log 文件，過濾 log 文件還是使用 grep。例如 log 文件為 myapp.log，要匹配 tag 為 MyApp 和 MyActivity 的輸出，然後輸出到 newmyapp.log： cat myapp.log grep "^..MyApp\^..MyActivity" > newmyapp.log Windows 下推薦使用 Notepad++，一個免費強大的記事本，支持正則表達式查找替換。可以高亮顯示匹配內容，也可以刪除不需要的內容。 以上的技巧主要用到了 grep，其實 logcat 本身也有過濾功能，可以根據 tag、優先順序過濾 log，具體請參考 Android 官方文檔 Reading and Writing Logs。如果喜歡使用圖形界面，請參考 Using DDMS，DDMS 裡面的 logcat 也可以同樣過濾。 android的logcat詳細用法 Android日誌系統提供了記錄和查看系統調試信息的功能。日誌都是從各種軟體和一些系統的緩沖區中記錄下來的，緩沖區可以通過 logcat 命 令來查看和使用. 使用logcat命令 你可以用 logcat 命令來查看系統日誌緩沖區的內容: [adb] logcat [<option>] ... [<filter-spec>] ... 請查看Listing of logcat Command Options ，它有對logcat命 令有詳細的描述 . 你也可以在你的電腦或運行在模擬器/設備上的遠程adb shell端來使用logcat命 令，也可以在你的電腦上查看日誌輸出。 $ adb logcat 你也這樣使用： # logcat 過濾日誌輸出 每一個輸出的Android日誌信息都有一個標簽和它的優先順序. 日誌的標簽是系統部件原始信息的一個簡要的標志。（比如：「View」就 是查看系統的標簽）. 優先順序有下列集中，是按照從低到高順利排列的: V — Verbose (lowest priority) D — Debug I — Info W — Warning E — Error F — Fatal S — Silent (highest priority, on which nothing is ever printed) 在運行logcat的時候在前兩列的信息中你就可以看到 logcat 的標簽列表和優先順序別,它是這樣標出的:<priority>/<tag> . 下面是一個logcat輸出的例子,它的優先順序就似乎I,標簽 就是ActivityManage: I/ActivityManager( 585): Starting activity: Intent { action=android.intent.action...} 為了讓日誌輸出能體現管理的級別,你還可以用過濾器來控制日誌輸出,過濾器可以幫助你描述 系統的標簽等級. 過濾器語句按照下面的格式描tag:priority ... , tag 表 示是標簽,priority 是表示標簽的報告的最低等級. 從上面的tag的中可以得到日誌的優先順序. 你可以在過濾器中多次寫tag:priority . 這些說明都只到空白結束。下面有一個列子，例子表示支持所有的日誌信息，除了那些標簽 為」ActivityManager」和優先順序為」Info」以上的和標簽為」 MyApp」和優先順序為」 Debug」以上的。 小等級,優先權報告為tag. adb logcat ActivityManager:I MyApp:D *:S 上面表達式的最後的元素 *:S ,，是設置所有的標 簽為」silent」，所有日誌只顯示有」View」 and 「MyApp」的，用 *:S 的另一個用處是 能夠確保日誌輸出的時候是按照過濾器的說明限制的，也讓過濾器也作為一項輸出到日誌中. 下面的過濾語句指顯示優先順序為warning或更高的日誌信息: adb logcat *:W 如果你電腦上運行logcat ，相比在遠程adbshell端，你還可以 為環境變數ANDROID_LOG_TAGS :輸入一個參數來設置默認的過濾 export ANDROID_LOG_TAGS="ActivityManager:I MyApp:D *:S" 需要注意的是ANDROID_LOG_TAGS 過濾器如果 通過遠程shell運行logcat 或 用adb shell logcat 來 運行模擬器/設備不能輸出日誌. 控制 日誌輸出格式 日誌信息包括了許多元數據域包括標簽和優先順序。可以修改日誌的輸出格式，所以可以顯示出特 定的元數據域。可以通過 -v 選項得到格式化輸出日誌的相關信息. brief — Display priority/tag and PID of originating process (the default format). process — Display PID only. tag — Display the priority/tag only. thread — Display process:thread and priority/tag only. raw — Display the raw log message, with no other metadata fields. time — Display the date, invocation time, priority/tag, and PID of the originating process. long — Display all metadata fields and separate messages with a blank lines. 當啟動了logcat ，你可以通過-v 選 項來指定輸出格式: [adb] logcat [-v <format>] 下面是用 thread 來產生的日誌格式: adb logcat -v thread 需要注意的是你只能-v 選項來規定輸出格式 option. 查看 可用日誌緩沖區 Android日誌系統有循環緩沖區，並不是所有的日誌系統都有默認循環緩沖區。為了得到 日誌信息，你需要通過-b 選項來啟動logcat 。如果要使用循環緩沖區，你需要查看剩餘的 循環緩沖期: radio — 查看緩沖區的相關的信息. events — 查看和事件相關的的緩沖區. main — 查看主要的日誌緩沖區 -b 選項使用方法: [adb] logcat [-b <buffer>] 下面的例子表示怎麼查看日誌緩沖區包含radio 和 telephony信息: adb logcat -b radio 查看 stdout 和stderr 在默認狀態下，Android系統有stdout 和 stderr (System.out和System.err ) 輸出到/dev/null ， 在運行Dalvik VM的進程中，有一個系統可以備份日誌文件。在這種情況下，系統會用stdout 和stderr 和 優先順序 I.來記錄日誌信息 通過這種方法指定輸出的路徑，停止運行的模擬器/設備，然後通過用setprop 命 令遠程輸入日誌 $ adb shell stop $ adb shell setprop log.redirect-stdio true $ adb shell start 系統直到你關閉模擬器/設備前設置會一直保留，可以通過添加/data/local.prop 可 以使用模擬器/設備上的默認設置 Logcat命令列表 Option Description -b <buffer> 載入一個可使用的日誌緩沖區供查看，比如event 和radio . 默認值是main 。具體查看Viewing Alternative Log Buffers. -c 清楚屏幕上的日誌. -d 輸出日誌到屏幕上. -f <filename> 指定輸出日誌信息的<filename> ， 默認是stdout . -g 輸出指定的日誌緩沖區，輸出後退出. -n <count> 設置日誌的最大數目<count> .， 默認值是4，需要和 -r 選 項一起使用。 -r <kbytes> 每<kbytes> 時 輸出日誌，默認值為16，需要和-f 選 項一起使用. -s 設置默認的過濾級別為silent. -v <format> 設置日誌輸入格式，默認的是brief 格 式，要知道更多的支持的格式，參看Controlling Log Output Format .