ネットワークの世界へようこそ！NOC（ネットワークオペレーションセンター）で日々、パケットの荒波と格闘しているシニアエンジニアです。
皆さんは、ネットワークの調子が悪いときに、とりあえずpingで生存確認をしたり、tracerouteでどこで詰まっているかを調べたりした経験はありませんか？ これらのコマンドは、インフラエンジニアにとっての「聴診器」のようなもので、トラブルシューティングの初手としてなくてはならない相棒ですよね。
でも、ちょっと待ってください。
「便利な診断ツール」という顔の裏側で、実はこれらがサイバー攻撃の武器として悪用されるリスクを孕んでいることをご存知でしょうか？
今回は、私たちが普段何気なく使っているCLI診断ツールに潜むセキュリティの罠と、それを防ぐための現場の知恵について、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！
—
1. 診断ツールは「親切な案内係」…だけど悪党も利用する？
まず、pingやtracerouteがやっていることを、現実の世界に例えてみましょう。
イメージしてみてください。あなたは巨大なオフィスビル（データセンター）の受付係です。
そこへ、見知らぬ人物がやってきてこう尋ねます。
- 「おーい、ビルの中に人はいますかー？」（
pingのイメージ） - 「3階の奥の部屋に行くには、どの廊下を通って、どの扉をノックすればいいですか？」（
tracerouteのイメージ）
受付係としては、仕事熱きビジネスマンかもしれないし、困っているお客さんかもしれないので、「はい、いますよ」「あちらの廊下を通ってくださいね」と親切に答えますよね。これがネットワークの正常な状態です。
しかし、もしこれが「悪意を持ったいたずらっ子」だったらどうでしょう？
何千人もの人間が、一斉に昼夜問わず「おーい！」「おーい！」と大声で叫び続け、ありとあらゆる通路のルートを根掘り葉掘り聞いてきたら……？
受付は大パニックになり、本当に用事のある大切なお客さん（正当な通信）の対応ができなくなってしまいますよね。
これが、ネットワークの世界で言うDDoS（分散型サービス拒否）攻撃や、ネットワークスキャンの正体です。診断ツールが持つ「誰にでも返事をする」という特性は、時として攻撃者にとって格好の踏み台になってしまうのです。
—
2. なぜICMPやTracerouteは狙われるのか？
ネットワーク診断でよく使われるpingは、ICMP（Internet Control Message Protocol）という仕組みを使っています。これは、相手が生きているかどうかを確かめるための、いわば「お返事バトン」のようなものです。
また、tracerouteは、宛先までの途中にいるルーター（中継地点）に対して「そこを通るとき、ちょっと返事をしてよ！」とお願いしながらパケットを送り出します。
攻撃者はこの仕組みを悪用します。
例えば、架空の送信元IPアドレスを名乗って（これを「IPスプーフィング」と言います）、世界中のサーバーに対して一斉にpingを大量に送りつけるとどうなるでしょうか？
サーバーたちは、その架空の標的めがけて一斉に「ここにいますよ！」とお返事を送り返します。結果として、標的となったサーバーやネットワーク回線は、津波のように押し寄せるお返事の嵐でパンクしてしまうのです。これが有名な「Smurf（スマーフ）攻撃」などの古典的かつ強力なDDoS手法です。
—
3. 現場の防衛策：ICMPのブロックと「レートリミット」
こうした脅威からインフラを守るため、私たちNOCのエンジニアは、ルーターやファイヤーウォールで適切な交通整理（アクセス制限）を行っています。
すべてを完全にシャットアウトしてしまうと、今度は「本当にトラブルが起きたときに原因が分からない」というジレンマに陥ります。そのため、現場では以下のようなバランスを取った運用が一般的です。
1. 外からの不要なICMPは基本ブロックする
インターネットの境界に位置するルーターで、外から内側への不要なICMPパケット（特にEcho Request、いわゆるpingの要求）をドロップ（破棄）するように設定します。
2. 「レートリミット（速度制限）」をかける
すべてを拒否するのではなく、「1秒間に受け付けるのは最大5回まで！」というように、お返事のペースに制限を設けます。これなら、人間がトラブルシューティングでpingを打つ分には問題なく返事が返ってきますが、攻撃者が自動ツールで何万発も送り込んできても、ルーターが「ちょっと落ち着いて！」と無視してくれるため、パンクを防げます。
実際のネットワーク機器（Cisco等）での設定例
参考までに、Ciscoのルーターなどでよく見られる、ICMPのレートリミット（Control Plane Policingなど）の概念的な設定イメージを見てみましょう。
! 制御プレーン（ルーター自体のCPUや処理能力）を守るための設定例
control-plane
host
! ICMPのエコー要求（ping）が1秒間に10回を超えたら、それ以上は処理せずに捨てる
police cir 10000 conform-action transmit exceed-action drop*※実際の機器やOSによって構文は異なりますが、「過剰な要求は受け付けない（drop）」という思想はどのインフラでも共通です。*
—
4. トラブルシューティング時の「あれ？返事がないぞ？」への向き合い方
私たちエンジニアが、いざ現場で障害対応をしているとき、pingを打っても全く反応がない（Request timeoutになる）ケースによく遭遇します。
初心者の方だと、「あ、サーバーが落ちている！」と焦ってしまいがちですが、百戦錬磨のエンジニアはこう考えます。
「サーバーが死んでいるのか、それともセキュリティポリシーでICMPをわざと弾いているだけなのか？」
この見極めが非常に重要です。
例えば、Webサーバーとして動いているのにpingが返ってこない場合、ICMPはブロックされていても、HTTP（ポート80）やHTTPS（ポート443）の通信は生きていて、Webサイト自体は正常に閲覧できるということがよくあります。
ですから、診断を行う際は、pingという一つの手段だけに頼るのではなく、次のような多角的な視点を持つことが大切です。
pingがダメなら、tracerouteやポートスキャン系のツール（ncやtelnetなど）で特定の出入り口（ポート）が生きていないか確認する。- 自社や自分の管理下にあるネットワークであれば、適切な監視とセキュリティのバランスが取れているか、ファイアウォールのルールを再確認する。
—
まとめ
今回は、CLI診断ツールに潜むセキュリティのリスクと、アクセス制限の裏側についてお話ししました。
pingやtracerouteは便利な半面、攻撃者に悪用されるリスク（DDoSやスキャン）がある。- セキュリティを守るため、現場ではICMPの制限やレートリミットをかけて交通整理をしている。
- 「返事がない＝障害発生」とは限らない。セキュリティポリシーによるブロックの可能性も常に頭に入れておく。
ツールはあくまで道具です。その裏側でパケットがどう振る舞い、どのようなリスクを抱えているのかを理解することで、皆さんのエンジニアとしてのスキルは一段と深まります。
一歩ずつ、確実に知識を積み重ねて、頼れるインフラエンジニアへの道を一緒に歩んでいきましょう！ それではまた次回の現場でお会いしましょう。
コメント