攻撃内容は、海外のグローバル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専用装置を所有している誤家庭もあるが、
やり方次第では対策出来る場合もあるので、参考に出来そうなら防御のヒントにでもして欲しい。
« 続きを隠す
