使用Cisco路由器識別和跟蹤資料包泛洪

下載選項

PDF (515.6 KB)
在多種裝置上使用 Adobe Reader 檢視
ePub (87.3 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
Mobi (Kindle) (80.1 KB)
在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視

已更新: 2005 年 5 月 27 日

文件 ID:13609

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

拒絕服務(DoS)攻擊在網際網路上很常見。應對此類攻擊的第一步是找出攻擊的確切型別。許多常用的DoS攻擊都基於高頻寬資料包泛洪或其他重複的資料包流。

將許多DoS攻擊流中的資料包與Cisco IOS®軟體訪問清單條目進行匹配時，可以隔離這些資料包。這對於過濾攻擊很有用。當您描述未知攻擊，以及追蹤「偽造」資料包流返回其實際源時，它也很有用。

Cisco路由器功能（如debug日誌記錄和IP記帳）有時也可用於類似目的，特別是用於新的或不尋常的攻擊。但是，在最新版本的Cisco IOS軟體中，訪問清單和訪問清單日誌記錄是辨識和跟蹤常見攻擊時的首要功能。

必要條件

最常見的DoS攻擊

可能會發生各種DoS攻擊。即使您忽略了使用軟體Bug來關閉具有相對較少流量的系統的攻擊，但事實仍然是，可透過網路傳送的任何IP資料包都可以用來執行泛洪DoS攻擊。當您受到攻擊時，必須始終考慮您所看到的不屬於通常類別的可能性。

然而，除了這一警告之外，記住許多攻擊是相似的，也是一件好事。攻擊者之所以選擇常見漏洞，是因為它們特別有效，特別難以跟蹤，或者是因為工具可用。許多DoS攻擊者缺乏建立自己的工具和使用在網際網路上找到的程式的技能或動機。這些工具往往時髦時尚。

在撰寫本文時，1999年7月，大多數客戶請求思科幫助都涉及「smurf」攻擊。這次襲擊有兩個受害者：一個「終極目標」和一個「反射者」。攻擊者向反射器子網的廣播地址傳送ICMP回應請求(「ping」)的刺激流。這些資料包的源地址被偽裝成最終目標的地址。對於攻擊者傳送的每個資料包，反射器子網上的許多主機都會做出響應。這會淹沒最終目標，浪費兩名受害者的頻寬。

稱為「fraggle」的類似攻擊以相同方式使用定向廣播，但使用UDP回應請求而不是網際網路控制消息協定(ICMP)回應請求。Fraggle的放大係數通常比藍精靈小，因此不太受歡迎。

Smurf攻擊通常由於網路鏈路過載而引起注意。有關這些攻擊和相應防禦措施的完整說明，請參閱拒絕服務攻擊資訊頁。

另一個常見的攻擊是SYN泛洪，其中目標電腦被TCP連線請求泛洪。連線請求資料包的源地址和源TCP埠是隨機的。其目的是強制目標主機維護許多從未完成的連線的狀態資訊。

SYN泛洪攻擊通常會被發現，因為目標主機（通常是HTTP或SMTP伺服器）變得非常緩慢、崩潰或掛起。從目標主機返回的資料流也可能在路由器上引起故障。這是因為此返回流量流向原始資料包的隨機源地址，缺少「真實」IP流量的位置屬性，並且可能會使路由快取溢位。在Cisco路由器上，此問題通常表現為路由器記憶體耗盡。

Smurf和SYN泛洪攻擊共同構成了向Cisco報告的泛洪DoS攻擊中的絕大部分，快速辨識它們非常重要。當您使用思科訪問清單時，這兩種攻擊（以及某些「第二級」攻擊，例如ping泛洪）都可以輕鬆辨識。

DoS表徵訪問清單

想象一下具有兩個介面的路由器。乙太網0連線到企業或小型ISP的內部LAN。Serial 0透過上游ISP提供Internet連線。Serial 0上的輸入資料包速率以全鏈路頻寬「繫結」在一起，LAN上的主機運行緩慢、崩潰、掛起或顯示DoS攻擊的其他跡象。路由器所連線的小型站點沒有網路分析器，即使有蹤跡，該站點的人也很少或根本沒有讀取分析器蹤跡的經驗。

現在，假設您套用存取清單，如以下輸出所示：

access-list 169 permit icmp any any echo
access-list 169 permit icmp any any echo-reply
access-list 169 permit udp any any eq echo
access-list 169 permit udp any eq echo any
access-list 169 permit tcp any any established
access-list 169 permit tcp any any
access-list 169 permit ip any any

interface serial 0
ip access-group 169 in

此清單完全不會過濾任何流量；所有專案都是允許的。但是，因為該清單以有用的方式將資料包分類，所以該清單可用於暫時診斷所有三種型別的攻擊：Smurf、SYN泛洪和Fraggle。

Smurf最終目標

如果您發出show access-list命令，則會看到類似於下面的輸出：

Extended IP access list 169
    permit icmp any any echo (2 matches)
    permit icmp any any echo-reply (21374 matches)
    permit udp any any eq echo
    permit udp any eq echo any
    permit tcp any any established (150 matches)
    permit tcp any any (15 matches)
    permit ip any any (45 matches)

到達串列介面的大部分流量都包含ICMP回應應答資料包。這可能是藍精靈攻擊的特徵，我們的站點是最終目標，而不是反射者。修改訪問清單時，您可以收集有關攻擊的詳細資訊，如以下輸出所示：

interface serial 0
no ip access-group 169 in

no access-list 169
access-list 169 permit icmp any any echo
access-list 169 permit icmp any any echo-reply log-input
access-list 169 permit udp any any eq echo
access-list 169 permit udp any eq echo any
access-list 169 permit tcp any any established
access-list 169 permit tcp any any
access-list 169 permit ip any any

interface serial 0
ip access-group 169 in

此處所作的更改是向與可疑資料流相匹配的訪問清單條目中增加了log-input關鍵字。(低於11.2的Cisco IOS軟體版本缺少此關鍵字。請改用「log」關鍵字。) 這會導致路由器記錄與清單條目匹配的資料包的資訊。假設配置了logging buffered，則可以使用show log命令檢視產生的消息（由於速率限制，累計消息可能需要一些時間）。訊息顯示與以下輸出類似：

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.142 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.113 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.72 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.154 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.15 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.142 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.47 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.35 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.113 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.59 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.82 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.56 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.84 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.47 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.35 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.15 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.33 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

回應應答資料包的源地址以地址字首192.168.212.0/24、192.168.45.0/24和172.16.132.0/24聚集。（192.168.x.x和172.16.x.x網路中的私有地址不會在Internet上；這是實驗圖示。）這是Smurf攻擊的特徵，源地址是Smurf反射器的地址。如果您在相應的Internet「whois」資料庫中查詢這些地址塊的所有者，您可以找到這些網路的管理員，並請求他們幫助處理攻擊。

在smurf事件的這個階段，記住這些反射者是同伴受害者，而不是攻擊者，這一點很重要。在任何DoS泛洪中，攻擊者極少在IP資料包上使用自己的源地址，而在正常工作的Smurf攻擊中，他們也不可能這樣做。泛洪資料包中的任何地址都應假設為完全偽造，或某種型別的受害者地址。Smurf攻擊的最終目標最有成效的方法是與反射器接觸，或者要求反射器重新配置網路以關閉攻擊，或者要求反射器協助追蹤刺激流。

由於Smurf攻擊的最終目標通常是由來自Internet的傳入鏈路過載造成的，因此除了接觸反射器外，通常沒有其它響應。當資料包到達目標控制下的任何電腦時，大多數損壞已經發生。

一種應急措施是要求上游網路提供商過濾掉來自特定反射器的所有ICMP回應應答或所有ICMP回應應答。建議不要永久保留此型別的過濾器。即使對於臨時過濾器，也只應過濾回應應答，而不是過濾所有ICMP資料包。另一種可能是讓上游提供商使用服務品質和速率限制功能來限制回聲應答的可用頻寬。合理的頻寬限制可以無限期地保留。這兩種方法都取決於上游提供商的裝置是否具有必要的容量，有時該容量不可用。

Smurf反射器

如果傳入流量包含回應請求而不是回應應答（換句話說，如果第一個訪問清單條目，而不是第二個條目計算出的匹配項比合理預期的多得多），您會懷疑網路被用作反射器的smurf攻擊，或者可能是簡單的ping泛洪。無論是哪種情況，如果攻擊成功，您都會認為串列線路的出局端以及入站端都會被淹沒。事實上，由於放大係數，您預計外發端的過載比傳入端的要多。

有幾種方法可以區分Smurf攻擊和簡單的ping泛洪：

Smurf刺激資料包傳送到定向廣播地址，而不是單播地址，而普通ping泛洪幾乎總是使用單播。您可以在相應訪問清單條目上看到使用log-input關鍵字的地址。
如果您被用作Smurf反射者，則系統的乙太網端的show interface命令會顯示數量不成比例的輸出廣播，且show ip traffic命令通常還會顯示數量不成比例的已傳送廣播。標準ping泛洪不會增加背景廣播流量。
如果您被用作Smurf反射者，則傳出到Internet的流量將多於從Internet傳入的流量。一般而言，串列介面上的輸出資料包比輸入資料包多。即使刺激流完全填充輸入介面，響應流也大於刺激流，並且分組丟棄被計數。

Smurf反射器比Smurf攻擊的最終目標有更多的選擇。如果反射器要終止攻擊，則通常只需正確使用no ip directed-broadcast（或等效的非IOS命令）即可。這些命令屬於每個配置，即使沒有活動攻擊也是如此。有關如何防止Cisco裝置被Smurf攻擊利用的詳細資訊，請參閱改善Cisco路由器的安全性。有關常見Smurf攻擊的更多一般資訊以及有關保護非Cisco裝置的資訊，請參閱拒絕服務攻擊資訊頁。

Smurf反射器比最終目標更接近攻擊者，因此更適合跟蹤攻擊。如果您選擇跟蹤攻擊，您需要與相關的ISP合作。如果您希望在完成追蹤時採取任何行動，您需要與適當的執法機構合作。如果您試圖跟蹤攻擊，建議您儘快讓執法部門參與進來。有關跟蹤泛洪攻擊的技術資訊，請參閱跟蹤部分。

弗拉格爾

fraggle攻擊與smurf攻擊類似，不同之處在於UDP Echo請求用於刺激資料流而非ICMP Echo請求。訪問清單的第三行和第四行用於辨識欺詐攻擊。對受害者的適當響應是相同的，不同之處在於，在大多數網路中，UDP echo與ICMP echo相比是一項不太重要的服務。因此，您可以完全停用它們，從而減少負面影響。

SYN泛洪

訪問清單的第五和第六行為：

access-list 169 permit tcp any any established
access-list 169 permit tcp any any

第一行匹配已設定ACK位的任何TCP資料包。就我們的目的而言，這實際表示會比對非TCP SYN的任何封包。第二行僅匹配TCP SYN資料包。SYN泛洪很容易從這些清單條目的計數器中辨識。在正常流量中，非SYN TCP資料包的數量至少比SYN多2倍，通常更類似於四或五。在SYN泛洪中，SYN通常比非SYN TCP資料包多出很多次。

建立此簽名的唯一非攻擊條件是，真實連線請求大量過載。一般來說，這樣的過載不會意外發生，並且不會像實際SYN泛洪一樣涉及那麼多的SYN資料包。此外，SYN泛洪通常包含源地址完全無效的資料包；透過使用log-input關鍵字，可以檢視連線請求是否來自此類地址。

有一種稱為「進程表攻擊」的攻擊與SYN泛洪具有某些相似性。在進程表攻擊中，TCP連線完成，然後允許超時且不再有協定流量，而在SYN泛洪中，僅傳送初始連線請求。由於進程表攻擊需要完成TCP初始握手，因此通常必須使用攻擊者具有訪問許可權的真實電腦的IP地址（通常為竊取訪問許可權）發起此攻擊。因此，透過使用資料包日誌記錄，進程表攻擊很容易與SYN泛洪區分開來。進程表攻擊中的所有SYN都來自一個或幾個地址，或者最多來自一個或幾個子網。

SYN泛洪受害者的響應選項非常有限。受攻擊的系統通常是一項重要的服務，阻止對系統訪問通常可以實現攻擊者的目的。許多路由器和防火牆產品（包括Cisco的產品）具有可用於減少SYN泛洪影響的功能。但是，這些特徵的有效性取決於環境。有關詳細資訊，請參閱Cisco IOS防火牆功能集的文檔、Cisco IOS TCP攔截功能的文檔以及改善Cisco路由器的安全性。

可以跟蹤SYN泛洪，但跟蹤過程需要從攻擊者到受害者的路徑上的每個ISP的幫助。如果您決定嘗試跟蹤SYN泛洪，請儘早與執法部門聯絡，並與您自己的上游服務提供商合作。有關使用Cisco裝置進行跟蹤的詳細資訊，請參閱本文檔的跟蹤部分。

其他攻擊

如果您認為自己受到攻擊，並且可以使用IP源地址和目標地址、協定號和埠號來描述該攻擊的特徵，則可以使用訪問清單來測試您的假設。建立與可疑流量匹配的訪問清單條目，將其應用於適當的介面，然後觀察匹配計數器或記錄流量。

記錄日誌和計數器警告

訪問清單條目上的計數器計算與該條目的所有匹配項。如果將訪問清單應用於兩個介面，則看到的計數為聚合計數。

訪問清單日誌記錄不會顯示與條目匹配的每個資料包。日誌記錄受到速率限制，以避免CPU過載。日誌記錄顯示的是一個具有合理代表性的示例，而不是完整的資料包跟蹤。請記住，有些資料包是看不到的。

在某些軟體版本中，訪問清單日誌記錄僅在某些交換模式下工作。如果訪問清單條目計算了大量匹配項，但未記錄任何匹配項，請嘗試清除路由快取，以強制資料包進行進程交換。如果您在具有多個介面的負載繁重的路由器上執行此操作，請務必小心。重建快取時，可能會丟棄大量流量。儘可能使用Cisco Express Forwarding。

訪問清單和日誌記錄對效能有影響，但影響不大。在CPU負載超過80%的路由器上，或在高速介面上應用訪問清單時要小心。

追蹤

DoS資料包的源地址幾乎總是設定為與攻擊者本身無關的值。因此，它們在辨識攻擊者時沒有用處。辨識攻擊源的唯一可靠方法是透過網路逐跳回跟蹤攻擊源。此過程包括重新配置路由器和檢查日誌資訊。在從攻擊者到受害者的路徑上，需要所有網路業者合作。確保合作通常需要執法機構的參與，如果要對攻擊者採取任何行動，執法機構也必須參與。

DoS泛洪的跟蹤過程相對簡單。從已知傳輸泛洪流量的路由器（稱為「A」）開始，辨識A接收流量的路由器（稱為「B」）。接著有人登入B，並找到B接收流量的路由器（稱為「C」）。這個過程會一直持續到找到最終來源為止。

此方法有以下幾種複雜情況，如以下清單所述：

「最終源」可以是被攻擊者攻破的電腦，但實際上它由另一個受害者擁有和操作。在這種情況下，跟蹤DoS泛洪只是第一步。
攻擊者知道他們可以被跟蹤，通常只在有限的時間內繼續攻擊。可能沒有足夠的時間來實際追蹤洪水。
攻擊可能來自多個來源，尤其是當攻擊者相對複雜時。儘量找出儘可能多的來源非常重要。
通訊問題會減慢追蹤程式的速度。通常，所涉及的一個或多個網路業者沒有具備適當技能的員工。
即使找到了攻擊者，法律和政治方面的顧慮也可能使其難以對攻擊者採取行動。

大多數跟蹤DoS攻擊的努力都失敗了。因此，許多網路操作員甚至不會嘗試追蹤攻擊，除非受到壓力。其他許多組織只追蹤「嚴重」攻擊，對「嚴重」的定義不同。有些人在執法介入的情況下才協助追蹤。

使用「log-input」進行跟蹤

如果選擇對穿過Cisco路由器的攻擊進行跟蹤，最有效的方法就是建立與攻擊資料流匹配的訪問清單條目，將log-input關鍵字附加到該條目，然後將訪問清單應用到相應介面（攻擊流透過該介面向最終目標傳送）的出站方向。訪問清單生成的日誌條目標識流量透過的路由器介面，如果介面是多點連線，則提供接收該流量的裝置的第2層地址。第2層地址能夠用於確認鏈中的下一台路由器，如透過使用show ip arp mac-address 命令確認。

SYN泛洪

為了跟蹤SYN泛洪，您可以建立類似於下面的訪問清單：

access-list 169 permit tcp any any established
access-list 169 permit tcp any host victim-host log-input
access-list 169 permit ip any any

這會記錄所有發往目標主機的SYN資料包，包括合法SYN。要確定最有可能實際到達攻擊者的路徑，請詳細檢查日誌條目。通常，泛洪的源是最大數量的匹配資料包到達的源。源IP地址本身毫無意義。您正在查詢源介面和源MAC地址。有時，由於泛洪資料包可能具有無效的源地址，因此可以將泛洪資料包與合法資料包區分開來。源地址無效的任何資料包都可能是泛洪的一部分。

雖然對於SYN泛洪而言比較少見，但是泛洪可能來自多個源。

Smurf刺激

若要追蹤Smurf刺激串流，請使用類似以下的存取清單：

access-list 169 permit icmp any any echo log-input
access-list 169 permit ip any any

請注意，第一個條目不會將其自身限制為發往反射器地址的資料包。原因是大多數Smurf攻擊使用多個反射器網路。如果您未與最終目標取得聯絡，則可能無法知道所有反射器地址。當您的跟蹤資訊接近攻擊源時，您可能會看到回聲請求傳送到越來越多的目的地；這是一個很好的跡象。

但是，如果您處理大量ICMP流量，則可能會生成過多的日誌記錄資訊，使您難以輕鬆閱讀。如果發生這種情況，您可以將目的地址限制為已知使用的反射器之一。另一個有用的策略是使用能利用以下事實的條目：255.255.255.0的網路掩碼在Internet中非常常見。而且，由於攻擊者查詢Smurf反射器的方式，實際用於Smurf攻擊的反射器地址更可能匹配該掩碼。以。0或。255結尾的主機地址在Internet中非常少見。因此，您可以為Smurf刺激串流建立相對特定的辨識器，如以下輸出所示：

access-list 169 permit icmp any host known-reflector echo log-input
access-list 169 permit icmp any 0.0.0.255 255.255.255.0 echo log-input
access-list 169 permit icmp any 0.0.0.0 255.255.255.0 echo log-input
access-list 169 permit ip any any

透過此清單，您可以從日誌中消除許多「雜訊」資料包，而當您更接近攻擊者時，仍極有可能發現額外的刺激流。

沒有「log-input」的追蹤

log-input關鍵字存在於Cisco IOS軟體版本11.2和更高版本中，以及在特別為服務提供者建立的特定11.1型軟體中。舊版軟體不支援此關鍵字。如果使用裝有較舊軟體的路由器，有三個可行選項：

建立訪問清單，但不記錄與可疑流量匹配的條目。依次在每個介面的輸入端應用清單，觀察計數器。查詢匹配率高的介面。此方法具有非常小的效能開銷，並且有利於源介面的辨識。它最大的缺點是不提供鏈路層源地址，因此主要適用於點對點線路。
使用log關鍵字(而不是log-input)建立存取清單專案。再次將清單依次應用於每個介面的傳入端。此方法仍不提供源MAC地址，但可用於檢視IP資料。例如，檢驗資料包流是否真的是攻擊的一部分。效能影響可能介於中等到高之間，而且較新的軟體效能優於較舊的軟體。
使用debug ip packet detail命令收集有關資料包的資訊。此方法提供MAC地址，但可能會嚴重影響效能。使用此方法很容易出錯，使路由器不可用。如果使用此方法，請確保路由器以快速、自主或最佳模式交換攻擊流量。使用存取清單，將偵錯限制為只包含您真正需要的資訊。將調試資訊記錄到本地日誌緩衝區，但關閉將調試資訊記錄到Telnet會話和控制檯。如果可能，安排人員親臨路由器，以便根據需要重新通電。

請記住，debug ip packet命令不會顯示有關快速交換資料包的資訊。您需要發出clear ip cache命令才能捕獲相關資訊。每個clear命令都會提供一兩個debug輸出的資料包。

使用Cisco路由器識別和跟蹤資料包泛洪

下載選項

無偏見用語

關於此翻譯

目錄

簡介

必要條件

需求

採用元件

慣例

最常見的DoS攻擊

DoS表徵訪問清單

Smurf最終目標

Smurf反射器

弗拉格爾

SYN泛洪

其他攻擊

記錄日誌和計數器警告

追蹤

使用「log-input」進行跟蹤

SYN泛洪

Smurf刺激

沒有「log-input」的追蹤

相關資訊

這份文件是否有所幫助？

讓思科協助您