Clever Geek Handbook

ルヌタヌに察する1぀のDDOS攻撃の歎史ずJuniperルヌティング゚ンゞンの保護方法

このサヌビスの結果、サヌバヌ䞊のDDOSに察凊しなければならないこずがよくありたしたが、しばらく前に別の攻撃に遭遇したしたが、準備ができおいたせんでした。 攻撃は、BGPセッションをサポヌトし、デヌタセンタヌサブネットのアナりンスを実行するJuniper MX80ルヌタヌで実行されたした。 攻撃者の目暙は、圓瀟のサヌバヌの1぀に配眮されたWebリ゜ヌスでしたが、攻撃の結果、デヌタセンタヌ党䜓が倖郚ず通信するこずなく残りたした。 攻撃の詳现、およびそのような攻撃に察凊するためのテストず方法。



攻撃履歎



歎史的に、ネットワヌクに向かうすべおのUDPトラフィックはルヌタヌでブロックされたす。 攻撃の最初の波17:22は、アップリンクルヌタヌからのナニキャストパケットのスケゞュヌルであるUDPトラフィックのみでした。

画像

ルヌタに接続されたスむッチポヌトからのナニキャストパケットのグラフ

画像

すべおのトラフィックがルヌタヌフィルタヌのロバであるこずを瀺したす。 ルヌタヌのアップリンク䞊のナニキャストパケットのフロヌは40䞇件増加し、UDPパケットによる攻撃は17:33たでしか続きたせんでした。 その埌、攻撃者は戊略を倉曎し、UDP攻撃に加えお、ルヌタヌ自䜓だけでなく、攻撃されたサヌバヌにもTCP SYN攻撃を远加したした。 グラフからわかるように、ルヌタヌが非垞に悪くなったため、zabbixぞのSNMPの送信が停止したした。 SYNの波の埌、ピアずのBGPセッションはルヌタヌのポヌトで萜ち始めたした各ポヌトから3぀のアップリンクを䜿甚しお、ipv4ずipv6の完党なビュヌを取埗したす、悲劇的な゚ントリがログに衚瀺されたした 

Jun 27 17:35:07 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 19 rcvcc: 0 TCP state: 4, snd_una: 1200215741 snd_nxt: 1200215760 snd_wnd: 15358 rcv_nxt: 4074908977 rcv_adv: 4074925361, hold timer out 90s, hold timer remain 0s Jun 27 17:35:33 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 38 rcvcc: 0 TCP state: 4, snd_una: 244521089 snd_nxt: 244521108 snd_wnd: 16251 rcv_nxt: 3829118827 rcv_adv: 3829135211, hold timer out 90s, hold timer remain 0s Jun 27 17:37:26 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 19 rcvcc: 0 TCP state: 4, snd_una: 1840501056 snd_nxt: 1840501075 snd_wnd: 16384 rcv_nxt: 1457490093 rcv_adv: 1457506477, hold timer out 90s, hold timer remain 0s


埌で刀明したように、攻撃埌、TCP SYN波によりルヌタヌのルヌティング゚ンゞンの負荷が増加し、その埌すべおのBGPセッションが䜎䞋し、ルヌタヌは単独で䜜業を埩元できたせんでした。 ルヌタヌぞの攻撃は数分間続きたしたが、远加の負荷が原因で、ルヌタヌは3぀のアップリンクからの完党なビュヌを凊理できず、セッションが再び䞭断したした。 すべおのBGPセッションを亀互に䞊げるこずによっおのみ䜜業を埩元できたした。 さらに攻撃がサヌバヌ自䜓に行きたした。



ベンチテストず攻撃の再生



攻撃の暙的ずしお、ゞュニパヌMX80は戊闘ルヌタヌず同じファヌムりェアバヌゞョンで䜿甚されたした。 攻撃者ずしお、10Gbカヌドずubuntuサヌバヌ+ quaggaがむンストヌルされたサヌバヌが䜿甚されたした。 トラフィックゞェネレヌタヌは、hping3ナヌティリティ呌び出しを備えたスクリプトでした。 トラフィックの「バヌスト」の有害な圱響を確認するため、スクリプトは䞀時的な䞭断を䌎うトラフィックを生成したした。30秒の攻撃-2秒の攻撃なし。 たた、実隓の玔粋さのために、ルヌタヌずサヌバヌの間でBGPセッションが発生したした。 そのずきにむンストヌルされたバトルルヌタヌの構成では、BGPおよびSSHポヌトはルヌタヌのすべおのむンタヌフェむス/アドレスで開かれおおり、フィルタリングされおいたせんでした。 同様の構成がスタンドルヌタヌに転送されたした。



最初のテストフェヌズは、ルヌタヌのBGP179ポヌトに察するTCP SYN攻撃でした。 IP゜ヌスアドレスは、構成内のピアアドレスず䞀臎したす。 アップリンクではuPRFが有効になっおいないため、IPアドレスのスプヌフィングは陀倖されたせんでした。 セッションが確立されたした。 クアッガ偎から 

 BGP router identifier 9.4.8.2, local AS number 9123 RIB entries 3, using 288 bytes of memory Peers 1, using 4560 bytes of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 9.4.8.1 4 1234 1633 2000 0 0 0 00:59:56 0 Total number of neighbors 1


ゞュニパヌの偎から 

 user@MX80> show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 2 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 9.4.8.2 4567 155 201 0 111 59:14 1/2/2/0 0/0/0/0


攻撃の開始埌13:52〜1.2 Mppsのトラフィックがルヌタヌに到達したす。

画像

たたは380Mbps

画像

ルヌタのCPU REおよびCPU FEの負荷が増加したす。

画像

タむムアりト90秒埌、BGPセッションはクラッシュし、䞊昇しなくなりたした。

7月4日13:54:01 MX80 rpd [1407]bgp_hold_timeout40359.4.8.2に送信されたNOTIFICATION倖郚AS 4567コヌド4保留タむマヌの期限切れ゚ラヌ、理由9.4.8.2倖郚AS 4567のホヌルドタむム期限切れ 、゜ケットバッファヌsndcc38 rcvcc0 TCP状態4、snd_una3523671294 snd_nxt3523671313 snd_wnd114 rcv_nxt1556791630 rcv_adv1556808014、タむマヌを90秒保持、タむマヌを0に保持


ルヌタは、BGPポヌトで着信TCP SYNの凊理でビゞヌであり、セッションを確立できたせん。 ポヌトには倚くのパッケヌゞがありたす

ナヌザヌ@ MX80> 監芖トラフィックむンタヌフェむスge-1 / 0/0 カりント20

135539.219155 IP 9.4.8.2.2097> 9.4.8.1.bgpS 144346220014434622000win 512

135539.219169 IP 9.4.8.2.27095> 9.4.8.1.bgpS 2956772902956772900win 512

135539.219177 IP 9.4.8.2.30114> 9.4.8.1.bgpS 3809954803809954800win 512

135539.219184 IP 9.4.8.2.57280> 9.4.8.1.bgpS 8142092188142092180win 512

135539.219192 IP 9.4.8.2.2731> 9.4.8.1.bgpS 1313509161313509160win 512

135539.219199 IP 9.4.8.2.2261> 9.4.8.1.bgpS 214533002421453300240win 512

135539.219206 IP 9.4.8.2.z39.50> 9.4.8.1.bgpでS 123817535012381753500win 512

135539.219213 IP 9.4.8.2.2098> 9.4.8.1.bgpS 137864526113786452610win 512

135539.219220 IP 9.4.8.2.30115> 9.4.8.1.bgpS 19257188​​3519257188​​350win 512

135539.219227 IP 9.4.8.2.27096> 9.4.8.1.bgpS 2862293212862293210win 512

135539.219235 IP 9.4.8.2.2732> 9.4.8.1.bgpS 146974016614697401660win 512

135539.219242 IP 9.4.8.2.57281> 9.4.8.1.bgpS 117964554211796455420win 512

135539.219254 IP 9.4.8.2.2262> 9.4.8.1.bgpS 150766351215076635120win 512

135539.219262 IP 9.4.8.2.914c / g> 9.4.8.1.bgpS 121940418412194041840win 512

135539.219269 IP 9.4.8.2.2099> 9.4.8.1.bgpS 5776164925776164920win 512

135539.219276 IP 9.4.8.2.267> 9.4.8.1.bgpS 125731085112573108510win 512

135539.219283 IP 9.4.8.2.27153> 9.4.8.1.bgpS 196542754219654275420win 512

135539.219291 IP 9.4.8.2.30172> 9.4.8.1.bgpS 144688023514468802350win 512

135539.219297 IP 9.4.8.2.57338> 9.4.8.1.bgpS 2063771492063771490win 512

135539.219305 IP 9.4.8.2.2789> 9.4.8.1.bgpS 8384838728384838720win 512


2番目のテストフェヌズは、ルヌタヌのBGP179ポヌトに察するTCP SYN攻撃です。 送信元IPアドレスはランダムに遞択され、ルヌタヌ構成で指定されたピアアドレスず䞀臎したせんでした。 この攻撃は、ルヌタヌに同じ圱響を及がしたした。 ログの統䞀された結論で蚘事を匕き䌞ばさないために、負荷グラフのみを瀺したす。

画像

スケゞュヌルに埓っお、攻撃の開始の瞬間がはっきりず芋えたす。 BGPセッションも萜ち、回埩に倱敗したした。



ビル保護REルヌタヌの抂念



ゞュニパヌの機噚の機胜は、ルヌティング゚ンゞンREずパケット転送゚ンゞンPFEの間でタスクを分離するこずです。 PFEは、事前に圢成されたスキヌムに埓っおフィルタリングおよびルヌティングするこずにより、通過するトラフィックのフロヌ党䜓を凊理したす。 REは、ルヌタヌtraceroute、ping、sshぞの盎接呌び出しを凊理し、サヌビスサヌビスBGP、NTP、DNS、SNMPのパケットを凊理し、PFEルヌタヌのトラフィックのフィルタリングおよびルヌティングスキヌムを䜜成したす。



ルヌタを保護する䞻な目的は、RE宛おのすべおのトラフィックをフィルタリングするこずです。 フィルタヌを䜜成するず、DDOS攻撃によっお䜜成された負荷をCPU REからルヌタヌのCPU PFEに転送できたす。これにより、REは実際のパケットのみを凊理し、他のトラフィックにCPU時間を浪費したせん。 保護を構築するには、フィルタリングの察象を決定する必芁がありたす。 IPv4甚のフィルタヌを蚘述するためのスキヌムは、 Douglas Hanks Jr.の本から匕甚されおいたす。 -Day One BookM、MX、およびTシリヌズのルヌティング゚ンゞンの保護 。 私の堎合、ルヌタヌの回路は次のずおりでした。



IPv4



IPv6によれば、私の堎合、フィルタヌはBGP、NTP、ICMP、DNS、およびtracerouteにのみ適甚されたした。 唯䞀の違いは、ICMPトラフィックのフィルタリングです。IPv6はビゞネス目的でICMPを䜿甚するためです。 他のプロトコルはIPv6アドレッシングを䜿甚したせんでした。



スペルチェックの構成



juniperでフィルタヌを䜜成するための䟿利なツヌル-prefix-listがありたす。これにより、フィルタヌ眮換のためにIPアドレス/サブネットのリストを動的にコンパむルできたす。 たずえば、蚭定で指定されたネむバヌのipv4 BGPアドレスのリストを䜜成するには、次の構造が䜿甚されたす。 

 prefix-list BGP-neighbors-v4 { apply-path "protocols bgp group <*> neighbor <*.*>"; }


コンパむル結果のリスト

show configuration policy-options prefix-list BGP-neighbors-v4 | 継承を衚瀺する

##

## apply-pathは次のように拡匵されたした。

## 1.1.1.1/32;

## 2.2.2.2/32;

## 3.3.3.3/32;

##

apply-path "protocols bgp group <*> neighbor <*。*>";


すべおのフィルタヌの動的プレフィックスリストを䜜成したす。 

 /*   ipv4   BGP */ prefix-list BGP-neighbors-v4 { apply-path "protocols bgp group <*> neighbor <*.*>"; } /*   ipv6   BGP */ prefix-list BGP-neighbors-v6 { apply-path "protocols bgp group <*> neighbor <*:*>"; } /*   ipv4  NTP */ prefix-list NTP-servers-v4 { apply-path "system ntp server <*.*>"; } /*   ipv6  NTP */ prefix-list NTP-servers-v6 { apply-path "system ntp server <*:*>"; } /*   ipv4    */ prefix-list LOCALS-v4 { apply-path "interfaces <*> unit <*> family inet address <*>"; } /*   ipv6    */ prefix-list LOCALS-v6 { apply-path "interfaces <*> unit <*> family inet6 address <*>"; } /*   ipv4  SNMP  */ prefix-list SNMP-clients { apply-path "snmp client-list <*> <*>"; } prefix-list SNMP-community-clients { apply-path "snmp community <*> clients <*>"; } /*    TACACS+ */ prefix-list TACPLUS-servers { apply-path "system tacplus-server <*>"; } /*        */ prefix-list INTERNAL-locals { /*      -    */ 192.168.0.1/32; } /*      ,    SSH */ prefix-list MGMT-locals { apply-path "interfaces fxp0 unit 0 family inet address <*>"; } /*   */ prefix-list rfc1918 { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; } /* Loopback */ prefix-list localhost-v6 { ::1/128; } prefix-list localhost-v4 { 127.0.0.0/8; } /*   ipv4   BGP */ prefix-list BGP-locals-v4 { apply-path "protocols bgp group <*> neighbor <*.*> local-address <*.*>"; } /*   ipv6   BGP */ prefix-list BGP-locals-v6 { apply-path "protocols bgp group <*> neighbor <*:*> local-address <*:*>"; } /*   ipv4  DNS */ prefix-list DNS-servers-v4 { apply-path "system name-server <*.*>"; } /*   ipv6  DNS */ prefix-list DNS-servers-v6 { apply-path "system name-server <*:*>"; }


垯域幅を制限するためにポリサヌを䜜成したす。 

 /*   1Mb */ policer management-1m { apply-flags omit; if-exceeding { bandwidth-limit 1m; burst-size-limit 625k; } /*      */ then discard; } /*   5Mb */ policer management-5m { apply-flags omit; if-exceeding { bandwidth-limit 5m; burst-size-limit 625k; } /*      */ then discard; } /*   512Kb */ policer management-512k { apply-flags omit; if-exceeding { bandwidth-limit 512k; burst-size-limit 25k; } /*      */ then discard; }


以䞋の「コピヌアンドペヌスト」の䞋で、最終保護オプションのフィルタヌの構成NTPおよびICMPトラフィックのスルヌプットのしきい倀が削枛されたした。しきい倀を䞋げる理由に぀いおは、テストのセクションで詳しく説明したす。 ipv4フィルタヌを構成したす。

IPv4フィルタヌ 
 /*  BGP  */ filter accept-bgp { interface-specific; term accept-bgp { from { source-prefix-list { BGP-neighbors-v4; } destination-prefix-list { BGP-locals-v4; } /*    .     . */ tcp-established; protocol tcp; port bgp; } then { count accept-bgp; accept; } } } /*  SSH  */ filter accept-ssh { apply-flags omit; term accept-ssh { from { destination-prefix-list { MGMT-locals; } protocol tcp; destination-port ssh; } then { /*    */ policer management-5m; count accept-ssh; accept; } } } /*  SNMP  */ filter accept-snmp { apply-flags omit; term accept-snmp { from { source-prefix-list { SNMP-clients; SNMP-community-clients; } destination-prefix-list { /*       */ INTERNAL-locals; } protocol udp; destination-port [ snmp snmptrap ]; } then { count accept-snmp; accept; } } } /*  ICMP  */ filter accept-icmp { apply-flags omit; /*    ICMP */ term discard-icmp-fragments { from { is-fragment; protocol icmp; } then { count discard-icmp-fragments; discard; } } term accept-icmp { from { protocol icmp; icmp-type [ echo-reply echo-request time-exceeded unreachable source-quench router-advertisement parameter-problem ]; } then { /*    */ policer management-1m; count accept-icmp; accept; } } } /*  traceroute  */ filter accept-traceroute { apply-flags omit; term accept-traceroute-udp { from { destination-prefix-list { LOCALS-v4; } protocol udp; /*   TTL = 1 */ ttl 1; destination-port 33434-33450; } then { /*    */ policer management-1m; count accept-traceroute-udp; accept; } } term accept-traceroute-icmp { from { destination-prefix-list { LOCALS-v4; } protocol icmp; /*   TTL = 1 */ ttl 1; icmp-type [ echo-request timestamp time-exceeded ]; } then { /*    */ policer management-1m; count accept-traceroute-icmp; accept; } } term accept-traceroute-tcp { from { destination-prefix-list { LOCALS-v4; } protocol tcp; /*   TTL = 1 */ ttl 1; } then { /*    */ policer management-1m; count accept-traceroute-tcp; accept; } } } /*  DNS  */ filter accept-dns { apply-flags omit; term accept-dns { from { source-prefix-list { DNS-servers-v4; } destination-prefix-list { LOCALS-v4; } protocol udp; source-port 53; } then { /*    */ policer management-1m; count accept-dns; accept; } } } /*         */ filter discard-all { apply-flags omit; term discard-ip-options { from { ip-options any; } then { /*      */ count discard-ip-options; log; discard; } } term discard-TTL_1-unknown { from { ttl 1; } then { /*      */ count discard-TTL_1-unknown; log; discard; } } term discard-tcp { from { protocol tcp; } then { /*      */ count discard-tcp; log; discard; } } term discard-udp { from { protocol udp; } then { /*      */ count discard-udp; log; discard; } } term discard-icmp { from { destination-prefix-list { LOCALS-v4; } protocol icmp; } then { /*      */ count discard-icmp; log; discard; } } term discard-unknown { then { /*      */ count discard-unknown; log; discard; } } } /*  TACACS+  */ filter accept-tacacs { apply-flags omit; term accept-tacacs { from { source-prefix-list { TACPLUS-servers; } destination-prefix-list { INTERNAL-locals; } protocol [ tcp udp ]; source-port [ tacacs tacacs-ds ]; tcp-established; } then { /*    */ policer management-1m; count accept-tacacs; accept; } } } /*  NTP  */ filter accept-ntp { apply-flags omit; term accept-ntp { from { source-prefix-list { NTP-servers-v4; localhost-v4; } destination-prefix-list { localhost-v4; LOCALS-v4; } protocol udp; destination-port ntp; } then { /*    */ policer management-512k; count accept-ntp; accept; } } } /*            */ filter accept-common-services { term protect-TRACEROUTE { filter accept-traceroute; } term protect-ICMP { filter accept-icmp; } term protect-SSH { filter accept-ssh; } term protect-SNMP { filter accept-snmp; } term protect-NTP { filter accept-ntp; } term protect-DNS { filter accept-dns; } term protect-TACACS { filter accept-tacacs; } }


ipv6の同様のフィルタヌ

IPv6フィルタヌ 
 /*  BGP  */ filter accept-v6-bgp { interface-specific; term accept-v6-bgp { from { source-prefix-list { BGP-neighbors-v6; } destination-prefix-list { BGP-locals-v6; } tcp-established; next-header tcp; port bgp; } then { count accept-v6-bgp; accept; } } } /*  ICMP  */ filter accept-v6-icmp { apply-flags omit; term accept-v6-icmp { from { next-header icmp6; /*     ,   ipv6  icmp */ icmp-type [ echo-reply echo-request time-exceeded router-advertisement parameter-problem destination-unreachable packet-too-big router-solicit neighbor-solicit neighbor-advertisement redirect ]; } then { policer management-1m; count accept-v6-icmp; accept; } } } /*  traceroute  */ filter accept-v6-traceroute { apply-flags omit; term accept-v6-traceroute-udp { from { destination-prefix-list { LOCALS-v6; } next-header udp; destination-port 33434-33450; hop-limit 1; } then { policer management-1m; count accept-v6-traceroute-udp; accept; } } term accept-v6-traceroute-tcp { from { destination-prefix-list { LOCALS-v6; } next-header tcp; hop-limit 1; } then { policer management-1m; count accept-v6-traceroute-tcp; accept; } } term accept-v6-traceroute-icmp { from { destination-prefix-list { LOCALS-v6; } next-header icmp6; icmp-type [ echo-reply echo-request router-advertisement parameter-problem destination-unreachable packet-too-big router-solicit neighbor-solicit neighbor-advertisement redirect ]; hop-limit 1; } then { policer management-1m; count accept-v6-traceroute-icmp; accept; } } } /*  DNS  */ filter accept-v6-dns { apply-flags omit; term accept-v6-dns { from { source-prefix-list { DNS-servers-v6; } destination-prefix-list { LOCALS-v6; } next-header udp; source-port 53; } then { policer management-1m; count accept-v6-dns; accept; } } } /*  NTP  */ filter accept-v6-ntp { apply-flags omit; term accept-v6-ntp { from { source-prefix-list { NTP-servers-v6; localhost-v6; } destination-prefix-list { localhost-v6; LOCALS-v6; } next-header udp; destination-port ntp; } then { policer management-512k; count accept-v6-ntp; accept; } } } /*     */ filter discard-v6-all { apply-flags omit; term discard-v6-tcp { from { next-header tcp; } then { count discard-v6-tcp; log; discard; } } term discard-v6-udp { from { next-header udp; } then { count discard-v6-udp; log; discard; } } term discard-v6-icmp { from { destination-prefix-list { LOCALS-v6; } next-header icmp6; } then { count discard-v6-icmp; log; discard; } } term discard-v6-unknown { then { count discard-v6-unknown; log; discard; } } } /*            */ filter accept-v6-common-services { term protect-TRACEROUTE { filter accept-v6-traceroute; } term protect-ICMP { filter accept-v6-icmp; } term protect-NTP { filter accept-v6-ntp; } term protect-DNS { filter accept-v6-dns; } }


次に、lo0.0サヌビスむンタヌフェむスにフィルタヌを適甚する必芁がありたす。 JunOSでは、このむンタヌフェむスを䜿甚しおPFEずREの間でデヌタを転送したす。 構成は次の圢匏を取りたす。 

 lo0 { unit 0 { family inet { filter { input-list [ accept-bgp accept-common-services discard-all ]; } } family inet6 { filter { input-list [ accept-v6-bgp accept-v6-common-services discard-v6-all ]; } } } }


むンタヌフェむスの入力リストでフィルタヌが指定される順序は非垞に重芁です。 input-listで指定されたフィルタヌを巊から右に通過するこずにより、各パッケヌゞの有効性がチェックされたす。



フィルタヌ詊隓



フィルタヌを適甚した埌、同じスタンドで䞀連のテストを実斜したした。 各テストの埌、ファむアりォヌルカりンタヌはクリアされたした。 ルヌタの通垞の攻撃なしの負荷は、1106-11:08のグラフに衚瀺されたす。 テスト期間党䜓のppsチャヌト

画像

テスト期間党䜓のCPUグラフ

画像



5 Mb / sのトラフィックしきい倀でのicmpフラッドテストが最初に実行されたしたチャヌト10:21-10:24。 フィルタヌカりンタヌずグラフにはトラフィックの垯域幅制限が衚瀺されたすが、このストリヌムでさえ負荷を増加させるのに十分だったため、しきい倀は1Mb / sに枛少したした。 カりンタヌ 

 Filter: lo0.0-i Counters: Name Bytes Packets accept-bgp-lo0.0-i 0 0 accept-icmp-lo0.0-i 47225584 1686628 accept-ntp-lo0.0-i 152 2 accept-snmp-lo0.0-i 174681 2306 accept-ssh-lo0.0-i 38952 702 accept-traceroute-icmp-lo0.0-i 0 0 accept-traceroute-tcp-lo0.0-i 841 13 accept-traceroute-udp-lo0.0-i 0 0 discard-TTL_1-unknown-lo0.0-i 0 0 discard-icmp-lo0.0-i 0 0 discard-icmp-fragments-lo0.0-i 0 0 discard-ip-options-lo0.0-i 0 0 discard-tcp-lo0.0-i 780 13 discard-udp-lo0.0-i 18743 133 discard-unknown-lo0.0-i 0 0 Policers: Name Bytes Packets management-1m-accept-ntp-lo0.0-i 0 0 management-1m-accept-traceroute-icmp-lo0.0-i 0 0 management-1m-accept-traceroute-tcp-lo0.0-i 0 0 management-1m-accept-traceroute-udp-lo0.0-i 0 0 management-5m-accept-icmp-lo0.0-i 933705892 33346639 management-5m-accept-ssh-lo0.0-i 0 0


1 Mb / sのトラフィックしきい倀で繰り返しicmpフラッドテストグラフ10:24-10:27。 REルヌタヌの負荷は19から10に䜎䞋し、PFEの負荷は30に䜎䞋したした。 カりンタヌ 

 Filter: lo0.0-i Counters: Name Bytes Packets accept-bgp-lo0.0-i 0 0 accept-icmp-lo0.0-i 6461448 230766 accept-ntp-lo0.0-i 0 0 accept-snmp-lo0.0-i 113433 1497 accept-ssh-lo0.0-i 33780 609 accept-traceroute-icmp-lo0.0-i 0 0 accept-traceroute-tcp-lo0.0-i 0 0 accept-traceroute-udp-lo0.0-i 0 0 discard-TTL_1-unknown-lo0.0-i 0 0 discard-icmp-lo0.0-i 0 0 discard-icmp-fragments-lo0.0-i 0 0 discard-ip-options-lo0.0-i 0 0 discard-tcp-lo0.0-i 360 6 discard-udp-lo0.0-i 12394 85 discard-unknown-lo0.0-i 0 0 Policers: Name Bytes Packets management-1m-accept-icmp-lo0.0-i 665335496 23761982 management-1m-accept-ntp-lo0.0-i 0 0 management-1m-accept-traceroute-icmp-lo0.0-i 0 0 management-1m-accept-traceroute-tcp-lo0.0-i 0 0 management-1m-accept-traceroute-udp-lo0.0-i 0 0 management-5m-accept-ssh-lo0.0-i 0 0


次のテストは、倖郚の構成に含たれおいないIPアドレスからのルヌタヌのBGPポヌトのフラッドでしたチャヌト10:29-10:36。 カりンタヌからわかるように、フラッド党䜓が廃棄tcpフィルタヌREに萜ち着き、PFEの負荷のみが増加したした。 REの負荷は倉曎されおいたせん。 カりンタヌ 

 Filter: lo0.0-i Counters: Name Bytes Packets accept-bgp-lo0.0-i 824 26 accept-icmp-lo0.0-i 0 0 accept-ntp-lo0.0-i 0 0 accept-snmp-lo0.0-i 560615 7401 accept-ssh-lo0.0-i 33972 585 accept-traceroute-icmp-lo0.0-i 0 0 accept-traceroute-tcp-lo0.0-i 1088 18 accept-traceroute-udp-lo0.0-i 0 0 discard-TTL_1-unknown-lo0.0-i 0 0 discard-icmp-lo0.0-i 0 0 discard-icmp-fragments-lo0.0-i 0 0 discard-ip-options-lo0.0-i 0 0 discard-tcp-lo0.0-i 12250785600 306269640 discard-udp-lo0.0-i 63533 441 discard-unknown-lo0.0-i 0 0 Policers: Name Bytes Packets management-1m-accept-icmp-lo0.0-i 0 0 management-1m-accept-ntp-lo0.0-i 0 0 management-1m-accept-traceroute-icmp-lo0.0-i 0 0 management-1m-accept-traceroute-tcp-lo0.0-i 0 0 management-1m-accept-traceroute-udp-lo0.0-i 0 0 management-5m-accept-ssh-lo0.0-i 0 0


セッションは萜ちたせん 

 user@MX80# run show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 2 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 9.4.8.2 4567 21 22 0 76 8:49 1/2/2/0 0/0/0/0


4番目のフラッドテストが実行されたしたグラフ10:41-10:46。NTPポヌトぞのUDPフィルタヌ蚭定では、このポヌトでの盞互䜜甚はルヌタヌ構成で指定されたサヌバヌに制限されたす。スケゞュヌルによるず、負荷はPFEルヌタヌでのみ28たで䞊昇したす。カりンタヌ 

 Filter: lo0.0-i Counters: Name Bytes Packets accept-bgp-lo0.0-i 0 0 accept-icmp-lo0.0-i 0 0 accept-ntp-lo0.0-i 0 0 accept-snmp-lo0.0-i 329059 4344 accept-ssh-lo0.0-i 22000 388 accept-traceroute-icmp-lo0.0-i 0 0 accept-traceroute-tcp-lo0.0-i 615 10 accept-traceroute-udp-lo0.0-i 0 0 discard-TTL_1-unknown-lo0.0-i 0 0 discard-icmp-lo0.0-i 0 0 discard-icmp-fragments-lo0.0-i 0 0 discard-ip-options-lo0.0-i 0 0 discard-tcp-lo0.0-i 0 0 discard-udp-lo0.0-i 1938171670 69219329 discard-unknown-lo0.0-i 0 0 Policers: Name Bytes Packets management-1m-accept-icmp-lo0.0-i 0 0 management-1m-accept-ntp-lo0.0-i 0 0 management-1m-accept-traceroute-icmp-lo0.0-i 0 0 management-1m-accept-traceroute-tcp-lo0.0-i 0 0 management-1m-accept-traceroute-udp-lo0.0-i 0 0 management-5m-accept-ssh-lo0.0-i 0 0


5回目のフラッドテストが実行されたしたチャヌト10:41-11:04。IPスプヌフィングを䜿甚したNTPポヌトぞのUDP。RE負荷は12増加し、PFE負荷は22に増加したした。カりンタヌによるず、フラッドが1 Mb / sのしきい倀にかかっおいるこずは明らかですが、これはREの負荷を増やすのに十分です。トラフィックのしきい倀は最終的に512Kb / sに枛少したした。カりンタヌ 

 Filter: lo0.0-i Counters: Name Bytes Packets accept-bgp-lo0.0-i 0 0 accept-icmp-lo0.0-i 0 0 accept-ntp-lo0.0-i 34796804 1242743 accept-snmp-lo0.0-i 630617 8324 accept-ssh-lo0.0-i 20568 366 accept-traceroute-icmp-lo0.0-i 0 0 accept-traceroute-tcp-lo0.0-i 1159 19 accept-traceroute-udp-lo0.0-i 0 0 discard-TTL_1-unknown-lo0.0-i 0 0 discard-icmp-lo0.0-i 0 0 discard-icmp-fragments-lo0.0-i 0 0 discard-ip-options-lo0.0-i 0 0 discard-tcp-lo0.0-i 0 0 discard-udp-lo0.0-i 53365 409 discard-unknown-lo0.0-i 0 0 Policers: Name Bytes Packets management-1m-accept-icmp-lo0.0-i 0 0 management-1m-accept-ntp-lo0.0-i 3717958468 132784231 management-1m-accept-traceroute-icmp-lo0.0-i 0 0 management-1m-accept-traceroute-tcp-lo0.0-i 0 0 management-1m-accept-traceroute-udp-lo0.0-i 0 0 management-5m-accept-ssh-lo0.0-i 0 0


IPスプヌフィングを䜿甚したNTPポヌトぞのUDPの繰り返しテスト11:29-11:34以䞋のチャヌト䞊、ただし、トラフィックのしきい倀は512Kb / sです。負荷グラフ

画像

カりンタヌ 

 Filter: lo0.0-i Counters: Name Bytes Packets accept-bgp-lo0.0-i 0 0 accept-icmp-lo0.0-i 0 0 accept-ntp-lo0.0-i 21066260 752363 accept-snmp-lo0.0-i 744161 9823 accept-ssh-lo0.0-i 19772 347 accept-traceroute-icmp-lo0.0-i 0 0 accept-traceroute-tcp-lo0.0-i 1353 22 accept-traceroute-udp-lo0.0-i 0 0 discard-TTL_1-unknown-lo0.0-i 0 0 discard-icmp-lo0.0-i 0 0 discard-icmp-fragments-lo0.0-i 0 0 discard-ip-options-lo0.0-i 0 0 discard-tcp-lo0.0-i 0 0 discard-udp-lo0.0-i 82745 602 discard-unknown-lo0.0-i 0 0 Policers: Name Bytes Packets management-1m-accept-icmp-lo0.0-i 0 0 management-1m-accept-traceroute-icmp-lo0.0-i 0 0 management-1m-accept-traceroute-tcp-lo0.0-i 0 0 management-1m-accept-traceroute-udp-lo0.0-i 0 0 management-512k-accept-ntp-lo0.0-i 4197080384 149895728 management-5m-accept-ssh-lo0.0-i 0 0




おわりに



実斜したすべおのテストの結果、DDOS攻撃に耐性のあるREトラフィックフィルタヌの構成を取埗するこずができたした。珟時点では、この構成はすでに戊闘ルヌタヌに適甚されおおり、問題は特定されおいたせん。戊闘MX80のカりンタヌによるず 

 Filter: lo0.0-i Counters: Name Bytes Packets accept-v6-bgp-lo0.0-i 31091878 176809 accept-v6-icmp-lo0.0-i 1831144 26705 accept-v6-ntp-lo0.0-i 0 0 accept-v6-traceroute-icmp-lo0.0-i 0 0 accept-v6-traceroute-tcp-lo0.0-i 48488 684 accept-v6-traceroute-udp-lo0.0-i 0 0 discard-v6-icmp-lo0.0-i 0 0 discard-v6-tcp-lo0.0-i 0 0 discard-v6-udp-lo0.0-i 0 0 discard-v6-unknown-lo0.0-i 0 0 Policers: Name Bytes Packets management-1m-accept-v6-icmp-lo0.0-i 0 0 management-1m-accept-v6-traceroute-icmp-lo0.0-i 0 0 management-1m-accept-v6-traceroute-tcp-lo0.0-i 0 0 management-1m-accept-v6-traceroute-udp-lo0.0-i 0 0 management-512k-accept-v6-ntp-lo0.0-i 0 0 Filter: lo0.0-i Counters: Name Bytes Packets accept-bgp-lo0.0-i 135948400 698272 accept-dns-lo0.0-i 374 3 accept-icmp-lo0.0-i 121304849 1437305 accept-ntp-lo0.0-i 87780 1155 accept-snmp-lo0.0-i 1265470648 12094967 accept-ssh-lo0.0-i 2550011 30897 accept-tacacs-lo0.0-i 702450 11657 accept-traceroute-icmp-lo0.0-i 28824 636 accept-traceroute-tcp-lo0.0-i 75378 1361 accept-traceroute-udp-lo0.0-i 47328 1479 discard-TTL_1-unknown-lo0.0-i 27790 798 discard-icmp-lo0.0-i 26400 472 discard-icmp-fragments-lo0.0-i 0 0 discard-ip-options-lo0.0-i 35680 1115 discard-tcp-lo0.0-i 73399674 1572144 discard-udp-lo0.0-i 126386306 694603 discard-unknown-lo0.0-i 0 0 Policers: Name Bytes Packets management-1m-accept-dns-lo0.0-i 0 0 management-1m-accept-icmp-lo0.0-i 38012 731 management-1m-accept-tacacs-lo0.0-i 0 0 management-1m-accept-traceroute-icmp-lo0.0-i 0 0 management-1m-accept-traceroute-tcp-lo0.0-i 0 0 management-1m-accept-traceroute-udp-lo0.0-i 0 0 management-512k-accept-ntp-lo0.0-i 0 0 management-5m-accept-ssh-lo0.0-i 0 0


廃棄フィルタヌに「巊」のトラフィックがどれだけ蓄積されおいるかを確認できたす。



コメントのすべおの質問に答えおうれしいです。


More articles:


All Articles