DigiLoog

続きを読む »

• BGPがEstablishedなのにフルルートを受信出来ない

最初にコレが発生したので非常に困った (´・ω・｀)
ネクストホップが存在せずルーティングに乗らないのは良くあるが、そもそも受信してくれなかった。

自宅ラボの検証環境も用いてルーティングを確実に受信出来るコンフィグを投入し、
BGP StateももEstablishedに遷移しているのにピアからルーティングが一向に来なくて途方に暮れた。
どうやっても自力で解決出来なかったので、Vultrサポートに下記の問い合わせを投げた所、
「設定ミスっていたわ。ゴメン！」と返答が来て無事にフルルートを受信出来る様になった。

Dear Vultr Support,
After receiving the ticket "XXX-XXXXX",
  I installed CentOS and FRRouting on my server instance and configured BGP peer.
I was able to set up a peer with Vultr BGP router,
  But after 2 days, I still can't receive a full route.
The configuration of FRRouting and the status of the peer are as follows.

- FRRouting Config
> AS20473# show running-config

- BGP neighbor
> AS20473# show ip bgp neighbors

I think the FRRouting settings are correct,
  But is there any reason why I cannot receive BGP full routes?
Also, can you tell me the status of the Vultr facility?

Regards, XXXXXX.

英文を全く書かないので文法が正しいか判らないが、コレで伝えたい事は上手く伝わった模様。
文で説明するのが面倒だったので、コンフィグとステータスを載せたのが良かったのかもしれない。
もしも、BGPピアを張れない状態になったら遠慮無くサポートに助けを求めると良いと思う。

• サーバスペックとプリペイド料金を迷う

Vultrのサーバはスペック毎に通信量が設定されており、通信量を超過すると面倒臭い事になる。
さらに、支払いは事前にお金を払うプリペイド方式がメインとなっており、
サーバで動かしたいサービスの通信量を予測しながらサーバスペックを選択して支払う必要がある。
勿論、利用分のみクレジットカードで引き落とす事も出来るらしいが、
筆者はオーソドックスにクレジットカード支払いプリペイド方式で払った。

ココで問題となったのはサーバスペックの予測が付かず、インスタンス選定に難儀した事。
という事で、実際に14日間起動しっぱなしにしつつ、
思い出した時にBGPステータスを表示するコマンドを打ち込んだ通信量が次の通り。

意外と通信量を抑える事が出来た (｀・ω・´)
コレはVultrのインスタンスFWでBGPセッション用のTCP:179と、
サーバ管理用のTCP:22以外を全部遮断する事で不要なトラフィックが来なくなった結果だと思う。
LookingGlass用途ならフルルートを受信しつつルータのコマンドさえ打てれば良いので、
通信対象を絞る事で気にする必要が無くなる。

メモリの方はフルルートを処理する為に2GB位の容量が必要になってくる。
Linuxを最適化すればワンランク下の1GBメモリでも動くと思うが、
2GBメモリでもモタつく時があったので止めた方が賢明だと思う。

• BGPフルルートを受信出来るコンフィグがわからない

根本的な話だがフルルートを受信するコンフィグを書いた事が無いので手探りだった。
ググればCiscoやJuniperのBGPサンプルは出てくるが、FRRoutingの様にLinuxルータの物は皆無となる。
という事で、筆者が実際に使ったFRRoutingでBGPフルルートを受信するサンプルコンフィグを載せておく。

AS20473# show running-config
Building configuration...

Current configuration:
!
frr version 7.0
frr defaults traditional
hostname AS20473
log file /var/log/frr/frr.log
service integrated-vtysh-config
!
ip route 169.254.169.254/32 207.148.XXX.ZZZ
ipv6 route 2001:19f0:ffff::1/128 fe80::fc00:XXX:ZZZ:1
!
interface eth0
 ip address 207.148.XXX.YYY/23
 ipv6 address 2001:19f0:7001:5aa7:WWW:XXX:YYY:ZZZ/64
!
router bgp 4288000AAA
 bgp router-id 207.148.XXX.YYY
 neighbor 169.254.169.254 remote-as 64AAA
 neighbor 169.254.169.254 password BGPPASSWORDXXXXX
 neighbor 169.254.169.254 ebgp-multihop 2
 neighbor 169.254.169.254 disable-connected-check
 neighbor 169.254.169.254 update-source 207.148.XXX.YYY
 neighbor 2001:19f0:ffff::1 remote-as 64AAA
 neighbor 2001:19f0:ffff::1 password BGPPASSWORDXXXXX
 neighbor 2001:19f0:ffff::1 ebgp-multihop 2
 neighbor 2001:19f0:ffff::1 disable-connected-check
 neighbor 2001:19f0:ffff::1 update-source 2001:19f0:7001:5aa7:WWW:XXX:YYY:ZZZ
 !
 address-family ipv4 unicast
  neighbor 169.254.169.254 soft-reconfiguration inbound
  no neighbor 2001:19f0:ffff::1 activate
 exit-address-family
 !
 address-family ipv6 unicast
  neighbor 2001:19f0:ffff::1 activate
  neighbor 2001:19f0:ffff::1 soft-reconfiguration inbound
 exit-address-family
!
line vty
!
end

ひとまず動けばOKのコンセプトで書いたのでセキュリティ設定などは追加で入れる必要がある。

ハマりポイントとしては、BGPピアと接続出来る様にスタティックルートを書いておかないと、
BGPセッションを張れてもフルルートがルーティングテーブルに載らなくなる。
OSに細工をするとスタティックルートを書かなくてもフルルートがルーティングに載るのだが、
今回の構成で手っ取り早く確実にルーティングを載せる方法はスタティックルートの設定だった。

………

Vultrは日本であまり聞かない事や管理画面が英語なので敬遠しがちだが、
AWSや国産VPSで無い面白い機能も実装されているのでエンジニアなら1回は触ると良いと思う。
筆者も初めてVultrを触ってみたが遊び程度なら意外と使い物になる事がわかったので、
作って壊す用途でまた契約するかも知れない。

という事でフルルートを受信する事が出来たので、これからインスタンスを削除してこねば。

« 続きを隠す

続きを読む »

攻撃内容は、海外のグローバルIPと国内キャリア偽装グローバルIPから同時にSYNフラッド攻撃が来た。
“ns-lab”では要所に攻撃緩和や自動遮断の仕組みがあるのでロードバランサ・メールサーバは耐えたのだが、
入り口となるFirewall兼NATルータでセッションテーブルが飽和してしまい、対外接続が不安定になった。

ちなみに、”ns-lab”のシステムは全てzabbixで監視しつつ各種ログはsyslogで集約化もしているので、
攻撃内容をリアルタイムで確認しつつ、この記事の様に後から分析する事が楽に出来た。

構成図の”#01″に当たるFirewallの監視ステータスがこちら。左がICMP死活、右がCPU負荷で表示してる。
CPU負荷が突出しているタイミングがあるがバッチ処理の負荷なので対象外。
見るべきなのは、ICMP死活監視が落ちて0の所とCPU負荷監視が取得出来ていない所の2箇所。
コレはセッションテーブルが飽和してしまい、監視用の通信も通らなくなった為に起きた物となる。

Firewallのエラーログはこちら。FirewallにはIIJ SEILを使っているので、ログの見方はドキュメントを見るべし。
“nat session is full”と出ている通り、SYNフラッド攻撃によってNATテーブルを食い潰していた。
セッション維持時間やFirewallポリシーは結構テコ入れしているので、今までに落ちた事は1回位しか無いのだが、
その設定を上回る通信が来たのでセッションを捌ききれなくなった。

攻撃が来ていた時にサーバでセッションを確認した所、見事にSYN_RECVが大量に並んでいた。
画像は10行のみ表示しているが、目視で5,000は軽く超えていたと思う。
攻撃元セグメントは普通のSYNフラッド攻撃がアフリカ辺りの”/24″ブロックから、
グローバルIP詐称型攻撃は国内のISP・キャリア偽る形で合計10箇所位からが同時に来ていた。

………

流石に放置するのは不味いので、Firewallポリシー調整とサーバで通信を遮断。
さらに、全サーバにiptables遮断ルール追加と攻撃緩和用ブラックリストの反映も行った。
コレを行う事で、Ansibleで別途仕込んでいる攻撃自動遮断と連携しながら、
FirewallのNATセッション時間調整とルーティング操作でパケットも捨てられる様になっている。

サーバでサイレントドロップすると、途中のFirewallでは通信を片方向SYNとして捉えさせる事が出来る。
所謂、エンタープライズのFirewallならNATセッションの廃棄時間を、
通信プロトコルや3ウェイハンドシェイク毎に決められるので、
SYNのみの通信のセッション破棄時間を短くすると簡単な防御に仕立てる事が出来る。

BGPを使っているならRTBH(Remotely Triggered Black Hole Filtering)をする事でnullに落とす事も出来る。
FirewallでBGPを喋るのが難しいなら、PBRでも似たような子とが出来るのでお試しあれ。
流石に企業やデータセンターで利用する様な本気の攻撃防御には全然届かないが、
この様な事をやれば自宅サーバを守る程度なら対応する事が出来たりする。

………

自宅サーバと言えどもインターネットにサーバを晒すなら攻撃が来るのは当たり前だが、
今回は久々に手の込んだ物が来たので実際に筆者が実施している防御の一部を記事にしてみた。
世の中にはもっと上を行く自宅ラボやDDoS専用装置を所有している誤家庭もあるが、
やり方次第では対策出来る場合もあるので、参考に出来そうなら防御のヒントにでもして欲しい。

« 続きを隠す