解析思科路由器性能的奧秘
思科路由器的性能被普遍認定為是比較高的，但具體是一個什么情況呢？今天我們集中剖析一下思科路由器的性能：
我們可以通過將很多DoS攻擊流中的數據包與Cisco IOS軟件的訪問控制列表條目進行匹配，以隔離這些數據包。顯而易見，這對過濾攻擊非常有價值，并且能夠幫助我們識別未知攻擊，跟蹤“欺騙”數據包流的真正來源。
某些時候，我們可將Cisco路由器的一些功能（如debug日志和IP記數）用于類似用途，尤其在遭遇新攻擊或者非常規攻擊的情況下。然而，隨著Cisco IOS軟件的最新版本的發布，訪問控制列表和訪問控制列表日志已經成為識別和追蹤常見攻擊的重要功能。
最常見的DoS攻擊我們可能受到多種類型的DOS攻擊。既使我們忽略那些利用軟件錯誤使用較小的數據流量來關閉系統的攻擊，事實上仍然是任何通過網絡傳送的IP數據包都可以用來實施泛洪DoS攻擊。遭受攻擊時，您必須時刻考慮到這種攻擊可能是一種非常規的攻擊。
雖然我們提出上述告警，然而您還應該記住一點：很多攻擊是相似的。攻擊者會選擇利用常見的攻擊方法，原因在于這些方法特別有效，并且難以跟蹤，或者因為可用工具較多。很多DoS攻擊者缺乏創建自己的工具的技術或動力，而會使用在互聯網上找到的程序；這些工具通常已經過期了或不流行了。
在撰寫本文時（1999年7月），大部分向Cisco請求幫助的客戶都遭受了"smurf"攻擊。這種攻擊的受害者分為兩類：“最終目標”或“反射者”。攻擊者將ICMP響應請求（"ping"）的激勵數據發送到反射者子網的廣播地址。這些數據包的源地址被偽裝為最終目標的地址。反射者子網上的很多主機對攻擊者發送的每個數據包作出了回應，從而使最終目標數據泛洪，并且消耗受害雙方的帶寬。
另外一種類似的攻擊稱為“fraggle”，它通過相同的方法來利用定向廣播，但它采用的是UDP回應請求，來代替ICMP回應請求。Fraggle的擴散系數通常低于smurf，也沒有smurf常用。Smurf攻擊通常會被察覺，因為網絡鏈路將會超載。
SYN泛洪是另外一種常見攻擊，該攻擊使用TCP連接請求來泛洪目標機器。連接請求數據包的源地址和源TCP端口被打亂，目的是迫使目標主機為很多永無休止的連接維護 好狀態信息。
SYN泛洪攻擊通常會被察覺，因為目標主機（通常為HTTP和SMTP服務器）將發生速度變得極慢、崩潰或者死機的現象。從目標主機返回的流量可能導致路由器發生故障；因為這種返回流量會流向被打亂的原數據包的源地址，它不具備“真正的”IP流量的位置屬性，并可能使路由器緩存溢出。在Cisco路由器上，發生此問題的跡象通常是路由器的內存容量耗盡。
在Cisco接到的報告中，smurf和SYN泛洪攻擊在泛洪DoS攻擊中占據了絕大多數比例，因而迅速識別這兩種攻擊至關重要。幸運的是，我們可以使用Cisco訪問控制列表輕而易舉地識別上述兩種攻擊（以及一些“二級”攻擊，例如ping泛洪）。
識別DoS的訪問控制列表想象一臺帶有二個接口的路由器。ethernet 0連接到一個公司或小型ISP的內部局域網。Serial 0提供通過上一級ISP提供互聯網連接。Serial 0上的輸入數據包率被“固定”在整個鏈路帶寬上，局域網上的主機運行緩慢，會發生崩潰和死機的現象或者表現出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響應答復數據包組成。這可能是smurf攻擊的跡象，我們的站點是最終目標，而并非反射者。通過更改訪問控制列表，我們能夠輕易收集到有關攻擊的更多信息，如以下信息：
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 and 172.16.x.x網絡中的專用地址不在互聯網上，這是一個實驗室例證）。這正是smurf攻擊的特征，源地址是smurf反射者的地址。我們可在相應的互聯網“whois”數據庫中查詢這些地址塊的主人，從而找到這些網絡的管理者，并請求他們協助對付攻擊。
應該記住，在smurf攻擊中，這些反射者同是受害者，并非攻擊者，這一點非常重要。在任何DoS泛洪中，很少有攻擊者在IP數據包上使用自己的源地址。在任何有效的smurf攻擊中，他們都不可能這樣做。應該假定泛洪數據包的所有地址都是完全偽裝的，或者就是某種類型的受害者。對smurf攻擊的最終目標而言，最有效的方法是與反射者主人聯系，要求他們重新配置其網絡，以停止攻擊或者要求他們幫助跟蹤激發數據流。
由于smurf攻擊對最終目標的損害通常是互聯網的進入鏈路超載，因此，除與反射者聯系之外，我們通常沒有其它的應對措施；截止數據包到達目標控制下的任何機器時，大部分損害已經發生。
有一種權宜之計，就是要求上一級網絡供應商過濾所有ICMP響應答復，或者過濾來自特定反射者的ICMP響應答復。這種類型的過濾器不能永久使用。即使對臨時過濾器來說，也只應該過濾響應答復，而并非過濾所有ICMP數據包。另外還有一種可能的方法，讓上一級供應商使用服務質量和速率限制功能，以限制響應答復的可用帶寬，可以無限期地保留合理的帶寬限制。上述兩種方法都要求上一級供應商的設備擁有必要的功能，某些時候他們可能沒有足夠的功能。
Smurf反射者
如果入流量由響應請求組成，而不是由響應答復組成（換句話說，如果第一個訪問控制列表條目計算的匹配數量遠高于合理預測的數量，而第二個條目沒有發生這種情況），我們應該懷疑，我們的網絡在smurf攻擊中被用作反射者，或者遭受了一次ping泛洪攻擊。在這兩種情況下，如果攻擊成功，我們的串行線的輸出和輸入端將被淹沒。實際上，由于擴散因素的原因，輸出端的超載比輸入端更加嚴重。
我們可使用如下方法區別smurf攻擊和簡單的ping泛洪：
Smurf激勵數據包會發到定向的廣播地址，而并非單播地址，而普通ping泛洪通常使用單播地址。正如上文所述，我們可以在相應的訪問控制列表條目上使用log-input關鍵詞看到這些地址。
如果您被用作smurf反射者，則系統的以太網端的show interface命令會顯示數量不成比例的輸出廣播，show ip traffic命令通常還會顯示一些數量不成比例的被發送廣播。標準的ping泛洪不會增加后臺廣播流量。 中國
如果您被用作smurf反射者，發往互聯網的出流量將多于來自互聯網的入流量。一般而言，串行接口上的輸出數據包多于輸入數據包。即使激勵流完全占用輸入接口，響應流也將大于激勵流，數據包丟棄將被計數。
與smurf攻擊的最終目標相比，smurf反射者的選擇范圍更廣。如果反射者要終止攻擊，通常只需正確使用no ip directed-broadcast命令（或同等的non-IOS命令）。即使沒有實時攻擊，這些命令也可以使用在每個配置中。要獲得有關防止您的Cisco設備在smurf攻擊中被利用的更多信息，請參閱 提高Cisco路由器的安全性。要獲得有關smurf攻擊和保護非Cisco設備的基本信息,與最終目標相比，smurf反射者與攻擊者的距離更近一步，因此它在跟蹤攻擊方面處于更加有利的位置。如果您要跟蹤攻擊，則需要與有關ISP進行合作。完成跟蹤后，如果要采取行動，您還需要與相關執法機構進行合作。如果要跟蹤攻擊，應盡早要求執法機構介入。請參閱跟蹤部分 以獲得有關跟蹤泛洪攻擊的技術信息。
Fraggle攻擊與smurf攻擊類似，不同之處是它使用UDP響應請求作為激勵流，而沒有使用ICMP響應請求。在訪問控制列表地第三第四行定義了識別fraggle攻擊。受害者的應對措施也相同，不同之處在于：在大多數網絡中，UDP回應業務的重要性低于ICMP回應，因此我們可以完全禁用它而不會帶來較多地負面影響。
SYN泛洪
我們的訪問控制列表的第五行和第六行分別是：
access-list 169 permit tcp any any established
access-list 169 permit tcp any any
第一行將任何TCP數據包與ACK位設置進行匹配。真正能夠幫助我們識別攻擊的是它能匹配任何不是TCP SYN的數據包。因此，第二行只需匹配非TCP SYN數據包。我們可以很容易地通過這些訪問控制列表條目的計數器識別SYN泛洪；在正常流量中，非SYN TCP數據包的數量至少要比SYN多一倍，通常能夠達到SYN的4或5倍。在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超載。日志顯示的是適當的有代表性的例子，而并非完整的數據包追蹤。請記住，有一些數據包是您無法看見的。
在一些軟件版本中，訪問控制列表日志只能在某些交換模式下工作。如果訪問控制列表條目對大量匹配進行計數，但卻沒有進行記錄，應嘗試清除路由器緩存，以迫使數據包按照過程進行交換。在負載很高的多接口路由器上進行上述操作時，我們應該謹慎，大量數據流可能在重建緩存時被丟棄。
訪問控制列表和日志會影響性能，但影響不會很大。當路由器運行的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的子網掩碼在互聯網上非常普遍這一事實。鑒于攻擊者尋找smurf反射者的方法，實際用于smurf攻擊的反射者地址更可能和這個掩碼匹配。以.0和.255結尾的主機地址在互聯網上非常罕見，因而您可為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進行跟蹤
Cisco IOS 軟件11.2版和更高版本,以及一些專為服務供應商市場開發的基于11.1的軟件都支持log-input關鍵詞。舊版本的軟件不支持該關鍵詞。如果您使用的路由器運行的是較舊的版本，您有三個可行的選擇：建立訪問控制列表，不進行記錄，但條目必須匹配可疑流量。依次在每個接口的輸入端采用訪問控制列表，觀察計數器。尋找匹配率高的接口。這種方法的運行開銷非常低，利于確認源接口。其最大的缺陷是無法提供鏈路層的源地址，因此它最適用于點到點線路。
使用log（而不是log-input）關鍵詞創建訪問控制列表條目。再次將訪問控制列表應用到每個接口的進入端上。這種方法無法提供源MAC地址，但可用于查看IP數據，例如驗證數據包流確實是攻擊數據的一部分。對系統性能的影響的程度為中等或上等，新軟件的性能強于舊軟件。
使用debug ip packet detail來收集有關數據包的信息。這種方法可提供MAC地址，但對性能卻產生了嚴重的影響。使用該方法易于出錯，可能導致路由器無法使用。如果您使用該方法，應確保路由器以快速、自主或優化的方式交換攻擊流量。使用訪問控制列表，將調試限定在您真正需要的信息的范圍內。將調試信息記錄在本地日志緩沖區，但要關閉log到Telnet會話和控制臺的調試信息的記錄。如果可能，應安排人員守候路由器，確保必要時更換路由器電源。
請記住，debug ip packet無法顯示有關快速交換數據包的信息，要獲取這些信息，您必須使用clear ip cache命令。每個clear命令將為您提供一個或兩個調試輸出的數據包。
【編輯推薦】
