解析思科路由器性能的奧秘
思科路由器的性能被普遍認(rèn)定為是比較高的，但具體是一個(gè)什么情況呢？今天我們集中剖析一下思科路由器的性能：
我們可以通過將很多DoS攻擊流中的數(shù)據(jù)包與Cisco IOS軟件的訪問控制列表?xiàng)l目進(jìn)行匹配，以隔離這些數(shù)據(jù)包。顯而易見，這對(duì)過濾攻擊非常有價(jià)值，并且能夠幫助我們識(shí)別未知攻擊，跟蹤“欺騙”數(shù)據(jù)包流的真正來源。
某些時(shí)候，我們可將Cisco路由器的一些功能（如debug日志和IP記數(shù)）用于類似用途，尤其在遭遇新攻擊或者非常規(guī)攻擊的情況下。然而，隨著Cisco IOS軟件的最新版本的發(fā)布，訪問控制列表和訪問控制列表日志已經(jīng)成為識(shí)別和追蹤常見攻擊的重要功能。
最常見的DoS攻擊我們可能受到多種類型的DOS攻擊。既使我們忽略那些利用軟件錯(cuò)誤使用較小的數(shù)據(jù)流量來關(guān)閉系統(tǒng)的攻擊，事實(shí)上仍然是任何通過網(wǎng)絡(luò)傳送的IP數(shù)據(jù)包都可以用來實(shí)施泛洪DoS攻擊。遭受攻擊時(shí)，您必須時(shí)刻考慮到這種攻擊可能是一種非常規(guī)的攻擊。
雖然我們提出上述告警，然而您還應(yīng)該記住一點(diǎn)：很多攻擊是相似的。攻擊者會(huì)選擇利用常見的攻擊方法，原因在于這些方法特別有效，并且難以跟蹤，或者因?yàn)榭捎霉ぞ咻^多。很多DoS攻擊者缺乏創(chuàng)建自己的工具的技術(shù)或動(dòng)力，而會(huì)使用在互聯(lián)網(wǎng)上找到的程序；這些工具通常已經(jīng)過期了或不流行了。
在撰寫本文時(shí)（1999年7月），大部分向Cisco請(qǐng)求幫助的客戶都遭受了"smurf"攻擊。這種攻擊的受害者分為兩類：“最終目標(biāo)”或“反射者”。攻擊者將ICMP響應(yīng)請(qǐng)求（"ping"）的激勵(lì)數(shù)據(jù)發(fā)送到反射者子網(wǎng)的廣播地址。這些數(shù)據(jù)包的源地址被偽裝為最終目標(biāo)的地址。反射者子網(wǎng)上的很多主機(jī)對(duì)攻擊者發(fā)送的每個(gè)數(shù)據(jù)包作出了回應(yīng)，從而使最終目標(biāo)數(shù)據(jù)泛洪，并且消耗受害雙方的帶寬。
另外一種類似的攻擊稱為“fraggle”，它通過相同的方法來利用定向廣播，但它采用的是UDP回應(yīng)請(qǐng)求，來代替ICMP回應(yīng)請(qǐng)求。Fraggle的擴(kuò)散系數(shù)通常低于smurf，也沒有smurf常用。Smurf攻擊通常會(huì)被察覺，因?yàn)榫W(wǎng)絡(luò)鏈路將會(huì)超載。
SYN泛洪是另外一種常見攻擊，該攻擊使用TCP連接請(qǐng)求來泛洪目標(biāo)機(jī)器。連接請(qǐng)求數(shù)據(jù)包的源地址和源TCP端口被打亂，目的是迫使目標(biāo)主機(jī)為很多永無休止的連接維護(hù) 好狀態(tài)信息。
SYN泛洪攻擊通常會(huì)被察覺，因?yàn)槟繕?biāo)主機(jī)（通常為HTTP和SMTP服務(wù)器）將發(fā)生速度變得極慢、崩潰或者死機(jī)的現(xiàn)象。從目標(biāo)主機(jī)返回的流量可能導(dǎo)致路由器發(fā)生故障；因?yàn)檫@種返回流量會(huì)流向被打亂的原數(shù)據(jù)包的源地址，它不具備“真正的”IP流量的位置屬性，并可能使路由器緩存溢出。在Cisco路由器上，發(fā)生此問題的跡象通常是路由器的內(nèi)存容量耗盡。
在Cisco接到的報(bào)告中，smurf和SYN泛洪攻擊在泛洪DoS攻擊中占據(jù)了絕大多數(shù)比例，因而迅速識(shí)別這兩種攻擊至關(guān)重要。幸運(yùn)的是，我們可以使用Cisco訪問控制列表輕而易舉地識(shí)別上述兩種攻擊（以及一些“二級(jí)”攻擊，例如ping泛洪）。
識(shí)別DoS的訪問控制列表想象一臺(tái)帶有二個(gè)接口的路由器。ethernet 0連接到一個(gè)公司或小型ISP的內(nèi)部局域網(wǎng)。Serial 0提供通過上一級(jí)ISP提供互聯(lián)網(wǎng)連接。Serial 0上的輸入數(shù)據(jù)包率被“固定”在整個(gè)鏈路帶寬上，局域網(wǎng)上的主機(jī)運(yùn)行緩慢，會(huì)發(fā)生崩潰和死機(jī)的現(xiàn)象或者表現(xiàn)出DoS攻擊的其它跡象。路由器連接地點(diǎn)沒有網(wǎng)絡(luò)分析器，即使能夠進(jìn)行追蹤，但工作人員卻在讀取分析器追蹤方面缺乏經(jīng)驗(yàn)或者根本沒有經(jīng)驗(yàn)。
現(xiàn)在，假定我們按照如下方法使用訪問控制列表：
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
該訪問控制列表根本沒有過濾任何流量，所有條目均為許可。然而，由于它通過有效的方法對(duì)數(shù)據(jù)包進(jìn)行了分類，因此該表可用于臨時(shí)診斷三種類型的攻擊：smurf、SYN泛洪和fraggle。
Smurf最終目標(biāo)
如果發(fā)出show access-list命令，我們將看到與以下內(nèi)容相似的輸出：
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)
顯而易見，到達(dá)串行接口的大部分流量由ICMP響應(yīng)答復(fù)數(shù)據(jù)包組成。這可能是smurf攻擊的跡象，我們的站點(diǎn)是最終目標(biāo)，而并非反射者。通過更改訪問控制列表，我們能夠輕易收集到有關(guān)攻擊的更多信息，如以下信息：
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
我們在此處進(jìn)行了更改，將log-input關(guān)鍵詞添加到與可疑流量匹配的訪問控制列表?xiàng)l目中（版本低于11.2的Cisco IOS 軟件沒有該關(guān)鍵詞，我們可使用關(guān)鍵詞“l(fā)og”取代）。這樣可使路由器記錄與訪問控制列表?xiàng)l目匹配信息。假定配置了logging buffered，我們可以通過使用show log命令看到產(chǎn)生的結(jié)果信息（由于速率限制，信息收集可能需要一段時(shí)間）。
%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
我們可以發(fā)現(xiàn)，響應(yīng)答復(fù)數(shù)據(jù)包的源地址集中有幾個(gè)地址前綴：192.168.212.0/24、192.168.45.0/24和172.16.132.0/24（顯而易見，192.168.x.x and 172.16.x.x網(wǎng)絡(luò)中的專用地址不在互聯(lián)網(wǎng)上，這是一個(gè)實(shí)驗(yàn)室例證）。這正是smurf攻擊的特征，源地址是smurf反射者的地址。我們可在相應(yīng)的互聯(lián)網(wǎng)“whois”數(shù)據(jù)庫中查詢這些地址塊的主人，從而找到這些網(wǎng)絡(luò)的管理者，并請(qǐng)求他們協(xié)助對(duì)付攻擊。
應(yīng)該記住，在smurf攻擊中，這些反射者同是受害者，并非攻擊者，這一點(diǎn)非常重要。在任何DoS泛洪中，很少有攻擊者在IP數(shù)據(jù)包上使用自己的源地址。在任何有效的smurf攻擊中，他們都不可能這樣做。應(yīng)該假定泛洪數(shù)據(jù)包的所有地址都是完全偽裝的，或者就是某種類型的受害者。對(duì)smurf攻擊的最終目標(biāo)而言，最有效的方法是與反射者主人聯(lián)系，要求他們重新配置其網(wǎng)絡(luò)，以停止攻擊或者要求他們幫助跟蹤激發(fā)數(shù)據(jù)流。
由于smurf攻擊對(duì)最終目標(biāo)的損害通常是互聯(lián)網(wǎng)的進(jìn)入鏈路超載，因此，除與反射者聯(lián)系之外，我們通常沒有其它的應(yīng)對(duì)措施；截止數(shù)據(jù)包到達(dá)目標(biāo)控制下的任何機(jī)器時(shí)，大部分損害已經(jīng)發(fā)生。
有一種權(quán)宜之計(jì)，就是要求上一級(jí)網(wǎng)絡(luò)供應(yīng)商過濾所有ICMP響應(yīng)答復(fù)，或者過濾來自特定反射者的ICMP響應(yīng)答復(fù)。這種類型的過濾器不能永久使用。即使對(duì)臨時(shí)過濾器來說，也只應(yīng)該過濾響應(yīng)答復(fù)，而并非過濾所有ICMP數(shù)據(jù)包。另外還有一種可能的方法，讓上一級(jí)供應(yīng)商使用服務(wù)質(zhì)量和速率限制功能，以限制響應(yīng)答復(fù)的可用帶寬，可以無限期地保留合理的帶寬限制。上述兩種方法都要求上一級(jí)供應(yīng)商的設(shè)備擁有必要的功能，某些時(shí)候他們可能沒有足夠的功能。
Smurf反射者
如果入流量由響應(yīng)請(qǐng)求組成，而不是由響應(yīng)答復(fù)組成（換句話說，如果第一個(gè)訪問控制列表?xiàng)l目計(jì)算的匹配數(shù)量遠(yuǎn)高于合理預(yù)測的數(shù)量，而第二個(gè)條目沒有發(fā)生這種情況），我們應(yīng)該懷疑，我們的網(wǎng)絡(luò)在smurf攻擊中被用作反射者，或者遭受了一次ping泛洪攻擊。在這兩種情況下，如果攻擊成功，我們的串行線的輸出和輸入端將被淹沒。實(shí)際上，由于擴(kuò)散因素的原因，輸出端的超載比輸入端更加嚴(yán)重。
我們可使用如下方法區(qū)別smurf攻擊和簡單的ping泛洪：
Smurf激勵(lì)數(shù)據(jù)包會(huì)發(fā)到定向的廣播地址，而并非單播地址，而普通ping泛洪通常使用單播地址。正如上文所述，我們可以在相應(yīng)的訪問控制列表?xiàng)l目上使用log-input關(guān)鍵詞看到這些地址。
如果您被用作smurf反射者，則系統(tǒng)的以太網(wǎng)端的show interface命令會(huì)顯示數(shù)量不成比例的輸出廣播，show ip traffic命令通常還會(huì)顯示一些數(shù)量不成比例的被發(fā)送廣播。標(biāo)準(zhǔn)的ping泛洪不會(huì)增加后臺(tái)廣播流量。 中國
如果您被用作smurf反射者，發(fā)往互聯(lián)網(wǎng)的出流量將多于來自互聯(lián)網(wǎng)的入流量。一般而言，串行接口上的輸出數(shù)據(jù)包多于輸入數(shù)據(jù)包。即使激勵(lì)流完全占用輸入接口，響應(yīng)流也將大于激勵(lì)流，數(shù)據(jù)包丟棄將被計(jì)數(shù)。
與smurf攻擊的最終目標(biāo)相比，smurf反射者的選擇范圍更廣。如果反射者要終止攻擊，通常只需正確使用no ip directed-broadcast命令（或同等的non-IOS命令）。即使沒有實(shí)時(shí)攻擊，這些命令也可以使用在每個(gè)配置中。要獲得有關(guān)防止您的Cisco設(shè)備在smurf攻擊中被利用的更多信息，請(qǐng)參閱 提高Cisco路由器的安全性。要獲得有關(guān)smurf攻擊和保護(hù)非Cisco設(shè)備的基本信息,與最終目標(biāo)相比，smurf反射者與攻擊者的距離更近一步，因此它在跟蹤攻擊方面處于更加有利的位置。如果您要跟蹤攻擊，則需要與有關(guān)ISP進(jìn)行合作。完成跟蹤后，如果要采取行動(dòng)，您還需要與相關(guān)執(zhí)法機(jī)構(gòu)進(jìn)行合作。如果要跟蹤攻擊，應(yīng)盡早要求執(zhí)法機(jī)構(gòu)介入。請(qǐng)參閱跟蹤部分 以獲得有關(guān)跟蹤泛洪攻擊的技術(shù)信息。
Fraggle攻擊與smurf攻擊類似，不同之處是它使用UDP響應(yīng)請(qǐng)求作為激勵(lì)流，而沒有使用ICMP響應(yīng)請(qǐng)求。在訪問控制列表地第三第四行定義了識(shí)別fraggle攻擊。受害者的應(yīng)對(duì)措施也相同，不同之處在于：在大多數(shù)網(wǎng)絡(luò)中，UDP回應(yīng)業(yè)務(wù)的重要性低于ICMP回應(yīng)，因此我們可以完全禁用它而不會(huì)帶來較多地負(fù)面影響。
SYN泛洪
我們的訪問控制列表的第五行和第六行分別是：
access-list 169 permit tcp any any established
access-list 169 permit tcp any any
第一行將任何TCP數(shù)據(jù)包與ACK位設(shè)置進(jìn)行匹配。真正能夠幫助我們識(shí)別攻擊的是它能匹配任何不是TCP SYN的數(shù)據(jù)包。因此，第二行只需匹配非TCP SYN數(shù)據(jù)包。我們可以很容易地通過這些訪問控制列表?xiàng)l目的計(jì)數(shù)器識(shí)別SYN泛洪；在正常流量中，非SYN TCP數(shù)據(jù)包的數(shù)量至少要比SYN多一倍，通常能夠達(dá)到SYN的4或5倍。在SYN泛洪中，SYN的數(shù)量通常超出非SYN TCP數(shù)據(jù)包若干倍。
如果沒有遭受攻擊，唯一能夠產(chǎn)生此種現(xiàn)象的條件是：真正的連接請(qǐng)求大量超載。一般來說，這種超載現(xiàn)象不會(huì)出人意料地發(fā)生，也不會(huì)象真正的SYN泛洪那樣發(fā)送盡可能多的SYN數(shù)據(jù)包。此外，SYN泛洪通常包括地址完全無效的數(shù)據(jù)包，使用log-input關(guān)鍵詞能夠查看連接請(qǐng)求是否來自此類地址。
有一種攻擊通常被稱為"進(jìn)程表攻擊"，它與SYN泛洪有一些相似。在進(jìn)程表攻擊中，TCP連接實(shí)際上已經(jīng)結(jié)束，在沒有更多的協(xié)議流量時(shí)允許超時(shí)連接，而不會(huì)產(chǎn)生更多協(xié)議流量，而在SYN泛洪中，它們只會(huì)發(fā)送最初的連接請(qǐng)求。由于流程表攻擊要求完成TCP初次交接（往往竊取通道），因此它通常必須通過攻擊者真正進(jìn)入的機(jī)器的IP地址來發(fā)動(dòng)。因此，使用數(shù)據(jù)包日志能夠輕易地將它和SYN泛洪區(qū)別開來。流程表中的所有SYN來自一個(gè)或多個(gè)地址，或者頂多來自一個(gè)或幾個(gè)子網(wǎng)。
不幸的是，SYN泛洪的受害者能夠采取的應(yīng)對(duì)措施非常有限。遭受攻擊的系統(tǒng)通常承擔(dān)重要業(yè)務(wù)，攻擊者也通常能夠達(dá)到阻塞該系統(tǒng)入口的目的。很多路由器和防火墻產(chǎn)品，包括Cisco的產(chǎn)品，具備一些能夠減輕SYN泛洪的影響的功能，但這些功能的有效性取決于環(huán)境。要獲得更多信息，請(qǐng)參閱“Cisco IOS 防火墻功能設(shè)置”文檔（Cisco IOS TCP攔截功能的文檔）和 提高Cisco路由器的安全性。
我們也可能跟蹤SYN泛洪，但跟蹤過程要求攻擊者和受害者之間的路徑上的每一個(gè)ISP的協(xié)助。如果您決心嘗試追蹤SYN泛洪，應(yīng)盡早與執(zhí)法部門聯(lián)系，并與您自己的上一級(jí)服務(wù)供應(yīng)商合作。請(qǐng)參閱本文件的跟蹤部分，以獲得使用Cisco路由器進(jìn)行跟蹤的詳細(xì)信息。
其它攻擊: 如果您確信自己受到攻擊，并且能夠通過IP源地址和目的地址、協(xié)議號(hào)和端口號(hào)來識(shí)別該攻擊，那么您可使用訪問控制列表來驗(yàn)證您的假設(shè)。您可以創(chuàng)建一個(gè)與懷疑流量匹配的訪問控制列表?xiàng)l目，將其用于相應(yīng)接口，觀察匹配計(jì)數(shù)器或記錄流量。
日志和計(jì)數(shù)器告警:請(qǐng)記住，訪問控制列表?xiàng)l目上的計(jì)數(shù)器會(huì)計(jì)算所有與該條目的匹配。如果您在兩個(gè)接口上都使用訪問控制列表，那么您看到的計(jì)數(shù)將是總計(jì)數(shù)。
訪問控制列表日志不會(huì)顯示與條目匹配的每個(gè)數(shù)據(jù)包。日志受到速率限制，以防止CPU超載。日志顯示的是適當(dāng)?shù)挠写硇缘睦?，而并非完整的?shù)據(jù)包追蹤。請(qǐng)記住，有一些數(shù)據(jù)包是您無法看見的。
在一些軟件版本中，訪問控制列表日志只能在某些交換模式下工作。如果訪問控制列表?xiàng)l目對(duì)大量匹配進(jìn)行計(jì)數(shù)，但卻沒有進(jìn)行記錄，應(yīng)嘗試清除路由器緩存，以迫使數(shù)據(jù)包按照過程進(jìn)行交換。在負(fù)載很高的多接口路由器上進(jìn)行上述操作時(shí)，我們應(yīng)該謹(jǐn)慎，大量數(shù)據(jù)流可能在重建緩存時(shí)被丟棄。
訪問控制列表和日志會(huì)影響性能，但影響不會(huì)很大。當(dāng)路由器運(yùn)行的CPU負(fù)載達(dá)到80%時(shí)，或在高速接口上使用訪問控制列表時(shí)，應(yīng)小心謹(jǐn)慎。
跟蹤
DoS數(shù)據(jù)包的源地址通常被設(shè)置為與攻擊者毫無關(guān)聯(lián)的地址，因而該地址對(duì)確認(rèn)攻擊者沒有任何作用。識(shí)別攻擊來源的唯一可靠方法是通過網(wǎng)絡(luò)逐跳進(jìn)行跟蹤。這一過程包括重新配置路由器，檢查日志信息，請(qǐng)求從攻擊者到受害者的路徑上的所有網(wǎng)絡(luò)運(yùn)營商予以合作。要確保成功合作，通常需要執(zhí)法機(jī)構(gòu)介入，如果要對(duì)攻擊者采取措施，也必須有執(zhí)法機(jī)構(gòu)介入。
DoS泛洪的跟蹤過程相對(duì)比較簡單。從一臺(tái)承載泛洪流量的已知路由器（稱為A）開始，我們可以識(shí)別A接收流量的來源路由器（稱為B）。然后登錄B，找到B接受流量的來源路由器（稱為C）。按照此過程繼續(xù)查找，直至找到最終來源。
這種方法牽涉到下述幾個(gè)問題：
"最終來源"實(shí)際上可能是攻擊者掌握權(quán)限的一臺(tái)計(jì)算機(jī)，其擁有者和操作者可能是另外一位受害者。在此情況下，跟蹤DoS泛洪只是第一個(gè)步驟。
攻擊者知道他們可能被跟蹤，因此他們的攻擊的持續(xù)時(shí)間較短，我們可能沒有足夠的時(shí)間來跟蹤泛洪。攻擊可能來自多個(gè)來源，尤其在攻擊者相對(duì)較為老練的情況下。應(yīng)盡可能多地確認(rèn)來源，這一點(diǎn)非常重要。通信問題減緩了跟蹤過程。涉及到的一個(gè)或多個(gè)網(wǎng)絡(luò)運(yùn)營商可能沒有精通技術(shù)的人員，這種情況經(jīng)常發(fā)生。即使我們找到了攻擊者，但法律和政治方面的原因卻使我們很難對(duì)其采取行動(dòng)。
事實(shí)上，大部分嘗試跟蹤DoS攻擊的努力都以失敗告終。由于這個(gè)原因，很多網(wǎng)絡(luò)運(yùn)營商甚至可能拒絕嘗試跟蹤一個(gè)攻擊，除非他們承受到某些壓力。其它很多運(yùn)營商只跟蹤“嚴(yán)重”攻擊，并且他們對(duì)“嚴(yán)重”的定義各不相同。有些運(yùn)營商只有在執(zhí)法機(jī)構(gòu)介入時(shí)才會(huì)協(xié)助進(jìn)行跟蹤。
使用"log-input"進(jìn)行跟蹤
如果您要跟蹤通過一臺(tái)Cisco路由器來跟蹤一個(gè)攻擊，最有效的方法就是建立與攻擊數(shù)據(jù)流匹配的訪問控制列表?xiàng)l目，加上 log-input關(guān)鍵詞，然后將訪問控制列表提取出應(yīng)用到接口上（攻擊流量通過該接口向最終目標(biāo)傳送）。訪問控制列表產(chǎn)生的日志條目將識(shí)別流量通過的路由器接口，如果接口是多點(diǎn)連接，它將提供它所接收流量的設(shè)備的第2層地址。第2層地址能夠用于確認(rèn)鏈中的下一臺(tái)路由器，如通過使用show ip arp mac-address命令確認(rèn)。
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
該數(shù)據(jù)表將記錄所有到目標(biāo)主機(jī)的SYN數(shù)據(jù)包，包括非法SYN。要確認(rèn)通往攻擊者的最可能的真實(shí)路徑，應(yīng)仔細(xì)審查日志條目。通常來說，匹配數(shù)據(jù)包數(shù)量最多的來源就是泛洪來源。請(qǐng)記住，源IP地址本身并沒有任何意義；您尋找的是源接口和源MAC地址。在某些時(shí)候，我們也許能夠區(qū)分非法數(shù)據(jù)包和泛洪數(shù)據(jù)包，因?yàn)榉汉閿?shù)據(jù)包可能含有無效的源地址，任何源地址無效的數(shù)據(jù)包很有可能是泛洪數(shù)據(jù)的一部分。請(qǐng)記住，泛洪可能有多個(gè)來源，盡管這種情況與SYN泛洪相比比較罕見。
Smurf激勵(lì):要跟蹤smurf激發(fā)數(shù)據(jù)流，可使用以下訪問控制列表：
access-list 169 permit icmp any any echo log-input
access-list 169 permit ip any any
注意，第一個(gè)條目并非只限于發(fā)送到反射者地址的數(shù)據(jù)包。原因是大多數(shù)smurf攻擊會(huì)使用多個(gè)反射者網(wǎng)絡(luò)。如果您沒有與最終目標(biāo)保持聯(lián)系，您可能無法知道所有的反射者地址。當(dāng)您的跟蹤更加接近攻擊來源時(shí)，您可能開始發(fā)現(xiàn)，響應(yīng)請(qǐng)求的目的地越來越多；這是一個(gè)好現(xiàn)象。
然而，如果您處理大量ICMP流量，可能會(huì)產(chǎn)生過多日志信息，使您難以閱讀。如果發(fā)生此種情況，您可以將目的地的地址限定為已知被使用的反射者之一。另外一種有效策略是使用一個(gè)條目，利用255.255.255.0的子網(wǎng)掩碼在互聯(lián)網(wǎng)上非常普遍這一事實(shí)。鑒于攻擊者尋找smurf反射者的方法，實(shí)際用于smurf攻擊的反射者地址更可能和這個(gè)掩碼匹配。以.0和.255結(jié)尾的主機(jī)地址在互聯(lián)網(wǎng)上非常罕見，因而您可為smurf激勵(lì)流建立相對(duì)比較特殊的識(shí)別符。
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
您可以通過該訪問控制列表清除您的日志中的“噪音”數(shù)據(jù)包，當(dāng)您逐漸接近攻擊者時(shí)，您還有很大機(jī)會(huì)發(fā)現(xiàn)其它的激勵(lì)流。
不使用log-input進(jìn)行跟蹤
Cisco IOS 軟件11.2版和更高版本,以及一些專為服務(wù)供應(yīng)商市場開發(fā)的基于11.1的軟件都支持log-input關(guān)鍵詞。舊版本的軟件不支持該關(guān)鍵詞。如果您使用的路由器運(yùn)行的是較舊的版本，您有三個(gè)可行的選擇：建立訪問控制列表，不進(jìn)行記錄，但條目必須匹配可疑流量。依次在每個(gè)接口的輸入端采用訪問控制列表，觀察計(jì)數(shù)器。尋找匹配率高的接口。這種方法的運(yùn)行開銷非常低，利于確認(rèn)源接口。其最大的缺陷是無法提供鏈路層的源地址，因此它最適用于點(diǎn)到點(diǎn)線路。
使用log（而不是log-input）關(guān)鍵詞創(chuàng)建訪問控制列表?xiàng)l目。再次將訪問控制列表應(yīng)用到每個(gè)接口的進(jìn)入端上。這種方法無法提供源MAC地址，但可用于查看IP數(shù)據(jù)，例如驗(yàn)證數(shù)據(jù)包流確實(shí)是攻擊數(shù)據(jù)的一部分。對(duì)系統(tǒng)性能的影響的程度為中等或上等，新軟件的性能強(qiáng)于舊軟件。
使用debug ip packet detail來收集有關(guān)數(shù)據(jù)包的信息。這種方法可提供MAC地址，但對(duì)性能卻產(chǎn)生了嚴(yán)重的影響。使用該方法易于出錯(cuò)，可能導(dǎo)致路由器無法使用。如果您使用該方法，應(yīng)確保路由器以快速、自主或優(yōu)化的方式交換攻擊流量。使用訪問控制列表，將調(diào)試限定在您真正需要的信息的范圍內(nèi)。將調(diào)試信息記錄在本地日志緩沖區(qū)，但要關(guān)閉log到Telnet會(huì)話和控制臺(tái)的調(diào)試信息的記錄。如果可能，應(yīng)安排人員守候路由器，確保必要時(shí)更換路由器電源。
請(qǐng)記住，debug ip packet無法顯示有關(guān)快速交換數(shù)據(jù)包的信息，要獲取這些信息，您必須使用clear ip cache命令。每個(gè)clear命令將為您提供一個(gè)或兩個(gè)調(diào)試輸出的數(shù)據(jù)包。
【編輯推薦】
