Q&A
> 試験通信もpingやtracerouteといったネットワーク層レベルのものでなくアプリケーション層レベルで行ってしまえば
> ニーズがよくわかりませんね
応答がない状態だとアプリケーションレベルではどうにもならず、ネットワークレベルで調査したくないですか? 「その時だけicmpを通せば」というほど融通は利かないです、なかなか。
ヘルプデスクの悩み
お客様から「ホームページが見えない」と問い合わせを受けたとき、proxy や dnsについては比較的簡単に確認出来るのですが、icmp echo を通していないとのことで、ping や traceroute がタイムアウトしてしまいます。
原因がお客様側かこちら側もわからず、タイミングをあわせてブラウザを操作してもらいつつ、ネットワーク構成を参照しながらログをひとつひとつ確認するのに骨が折れるのですが、 icmp echo を通すように変更することはできないものでしょうか。なぜ通していないのでしょうか。
セキュリティオフィスの悩み
ネットワークセキュリティの観点から、申請のあったプロトコル以外は通さないこととしているのですが、運用部門が icmp echo が通らないので不便だ、と相談してきました。しかも、通信元/通信先を限定するのでは意味がないとのことで、icmp echo の任意の通信を通すように言っています。
通信元/通信先を限定せずに開放することによるセキュリティリスクを見極められないため、判断に困っています。どのようなリスクがあるでしょうか。
回答4件
0
仕事柄ウェブサイトへの侵入事件を調べていますが、「ICMPを制御していたら侵入を防げた」というものはまず見かけません。
また、Google、ヤフーなどの大手サービスや、LACやNRIセキュアなど日本の著名セキュリティ企業のウェブサイトを調べますと、pingはちゃんと通ります。
したがって、ICMP ECHOを許可することによるリスクは、多くの企業は許容可能と考えていることになります。
上記のような事実から、私個人としては「別に許容しても大したリスクはないし、いいのでは?」と思いますが、最終的にはご自身の（その企業の）判断です。
投稿2017/07/06 22:28
総合スコア11705
0
最初にご容赦いただきたいのですが、私はセキュリティ方面は専門分野でないため、現在の現場実務的にはどういう基準で対応されているものなのかを知りません。私が知らない問題や、脆弱性があることも十分考えられます。ご注意ください。
まず最初に言えることとして、「ICMPパケットだから」という条件だけでの解放は明確に×でしょう。これについては他の返答やIPAの調査報告書あたりでもいろいろ書かれている通りです。
次に、許可する「方向」の制限も必要だと思われます。サーバ側からのping/tracerouteは、多くの場合、クライアントがNATの壁の向こうにいるため不要だと思われるからです。
以上を踏まえて、クライアント側からのping/tracerouteに反応を返すために、ICMP echo request/echo replyだけ通すとした場合のリスクを考えればよいとした場合、問題となりそうなのは、私が知る限り、Ping of DeathとSmurf攻撃、あとは単純なflood攻撃でしょうか。いずれも対策は知られていますので、適切に設定で対処していれば問題ないのではないかと思います。
セキュリティの観点から言えば確かに、必要がない穴は開けないのは当然のことです。しかし、どんな穴にしたところで未知の脆弱性がある可能性は常にあることも事実ですので、未知の脆弱性を根拠に穴を開けない等というなら、何も公開できないということになることも忘れてはならないと思います。
誰が使うかもわからないような穴ではなく、明確な用途があるというのであれば、開ける穴を必要最小限に限定した上で、明確に対策できない危険があるかを調べ、そんな危険がないのであれば開けた上で、何か明確な問題が新たに見つかったら閉めるなり対策するなりする監視・調査・対応対象として扱うようにする（＝管理下に置く）べきだと思います。
もちろん、そのために必要な労力が大きく、そんなコストは払えないので開けないという判断もありだと思いますが・・・
ICMPが全部ブロックされた環境、というのは、ping of death攻撃が知られた頃に対応できない機器があるので閉じられたのではないか、とか、その後対策がされた機器への置き換えが済んだことで大手サービスはping応答を返すようになったのではないか、とか、最近はtracerouteすると途中の情報が何段も得られないけどゴールはできる環境が多いこととか、そのあたりも判断基準として考えてみてはいかがでしょうか。
投稿2017/07/28 21:09
総合スコア591
0
仰るとおり、セキュリティにおいて「不要な通信は許容しない」というのは鉄則です。論点の一つは「試験的なpingやtracerouteを不要な通信と意味づけるか」といったところだと思います。
エンドユーザ側からすれば保守上の都合は大きなものではないので、これを「不要」とするのもアリだとおもいます。試験通信もpingやtracerouteといったネットワーク層レベルのものでなくアプリケーション層レベルで行ってしまえば問題はありません。（ネットワークレベルの試験を行うときはその時だけicmpを通せばいいですし、フィルタをかければ他の通信の心配もありません）
以上が、私の私見です。が、「icmpをフィルタ制限なしで通したい」というニーズがよくわかりませんね。
投稿2017/07/09 13:48
総合スコア4830
0
icmpを対策なしに開放すると知っている範囲では以下のセキュリティリスクがあります。
・OSがバレる
・マシンのタイムスタンプがバレる
OSがバレれば脆弱性を突かれる危険性が高まり
タイムスタンプがバレるとタイムスタンプを使っている認証系は突破される危険性が高まります。
上記の他に、IPAが調査報告書を公開していたので参考になると思います。
ヘルプデスク、運用部門双方から「icmp echo」を通せと言われると通したくなりますよね。
ですが、冷静に"心を氷にして"対応しなければならないと思いますよ。
下記の観点で考えるとどうでしょうか。
A. icmp echoを通すことで削減されるコストとロス
B. icmp echoを通したことが関与した情報漏洩やサービス停止で発生するロス
究極、AがBを上回ればGoですが、Bには金額換算できない「社会的信用の喪失」が伴いますよね。
また、「ホームページが見えない」状況はicmp echoを通したところで解決はしないはずです。
ログにて分析が可能だというのなら、人の手でやっていることを機械化（自動化）する方向で
考えるのが一つの解決策と思います。コストはかかりますがBに比べれば安くなるでしょう。
icmp解放は最も安い対応方法ではありますが、「安物買いの銭失い」「只より高い物はない」
と思いますし、何より怖いのは「セキュリティ対策に対する軽視が広がる」ことです。
1つ許すと次も次もと広がってしまいます。一度どこかで火の手が上がれば大炎上です。
私個人のヘルプデスク、運用部門への回答は
「楽がしたい程度なら出直せ」「作業の効率化をしろ」
とします。おまけに右頬を引っ叩きます。
左頬を差し出す程の覚悟や状況があるなら相談に乗って一緒になって上層にエスカレーション。
セキュリティオフィスにはそのくらいの権限や責任があって良いと思います。
投稿2017/07/06 19:29
編集2017/07/11 16:28
総合スコア804
私がヘルプデスクや運用部門の人間なら、この例のような意見に対してセキュリティオフィスの人間から右頬を引っ叩かれたならグーで殴り返します。
この場合、具体的な代案を提示すべきは常にセキュリティオフィス側の仕事です。決してヘルプデスクや運用部門の仕事ではありません。
さらに言えば、結論としてどうすべきかの判断をするのはあくまで経営者なのであって、セキュリティオフィスにそんな権限はありません。
セキュリティというのは、常に不便さとのトレードオフです。その落としどころを探るのがセキュリティオフィスの仕事のはずです。
右頬を引っ叩く覚悟、殴り返される覚悟を持つことは必要ですが、その場合でも叩くべきは常に経営者であって、決してヘルプデスクや運用部門ではないはずです。
レスポンスありがとうございます。
himazin.blmさんのご指摘は全くその通りだと思います。
また、ご指摘いただいた部分についていささか煽るような表現をしたことをお詫び申し上げます。
私はユーザ系企業で受託システム開発・保守を行っているので、ヘルプデスクや運用部門の人間とも交流があります。開発を行う人間として、セキュリティオフィスに対する認識はhimazin.blmさんのご指摘に同意ものであります。
その立場である私が上記の回答をしたとするとどうでしょう。
私の回答をあえて肯定する考え方はないか。私がした回答の裏を探ってみてもらえたらと思います。
私のした回答は「icmp echo」というスコープに対して、範囲が広くなってしまう思いはありました。
ただ、質問者がセキュリティオフィスの担当者のように思えた事と、結論が「icmp echoを許容する」になるだろうと思ったので、あえてこの回答にて投稿しました。
明日か明後日あたりに、いただいたご指摘に対する返信と、私がこの回答をした理由（前述の"回答の裏"）をコメントさせていただこうと思います。
IPAの調査報告書、参考になります。
「OSがバレる」については、言われてみれば確かに、と思う一方、「タイムスタンプがバレる」は、そうかな? NTPとかで揃えるのが一般的だからバレるもなにも同じでは? と思っています。
以前、あるプロジェクトで災対切替テストをした際、待機系の海外回線を通れなかったということがあり、調査したら、icmpを塞いでいたために大きなパケットが通れなかったことが原因だった、ということがありました。そんなこともあり、icmp をやみくもに塞ぐのもどうかと思うようになっていたのですが、今回、とある調査にあたって traceroute が応答してくれず、あれそういえばなんで閉じているんだろう、と思ったのが質問の背景です。
matoobaさん、コメントありがとうございます。
「タイムスタンプがバレる」とTCP初期化シーケンス番号を正確に推測可能になります。
TCP初期化シーケンス番号が予測できで、パケットのサイズがわかると偽装が可能になります。
多少の語弊はありますが「パケットを偽装して端末に侵入する」ことが可能になります。
（といっても、古くからある脆弱性で各種対処法は産まれています。しかし、Timestampは閉じよっていうのは現在もペネトレやると指摘事項として現れます。閉じるべしってことですね。icmp echoは指摘事項に出てきてないです。某社ではという前提で。）
タイムスタンプを使っている認証方式も突破される可能性は高くなります。
乱数を使っている認証でもシード値にタイムスタンプを使っていると同様です。
> あれそういえばなんで閉じているんだろう
これから"回答の裏"を投稿します。
当初の回答と同じく「icmp解放だなんて許さん」とう筋書で刺激的な表現をしちゃいますが、
「待機系の海外回線を通れなかったとう事例があって、icmpが必要なのだ」という”根拠があれば”
価値は十分にあると思うので関係各所と調整して進められると良いと思います。
私の回答の裏について記しておきます。
himazin.blmさんからいただいたご指摘には同意するものであります。しかし、それは"要望をする側の立場においては"という前置きがあります。私がした回答は"要望を受ける側の立場"としてのものです。私が仕事上付き合いのあるセキュリティオフィスとの調整において似たような経験があり、そこで得た理解を元に回答させていただきました。
同意すると申し上げておきながら、実を申し上げると himazin.blm さんからいただいたご指摘の内容に同意るのは、過去の私です。指摘いただいた内容は私がかつて持っていた認識と全く同じでした。前述の経験を通し、現在ではその考えを改めて修正しています。
現状の私が himazin.blm さんと完全に意見が合致するのは「セキュリティというのは、常に不便さとのトレードオフ」という部分のみです。その他は「やりがちな間違った認識」というのがコメントに対する総括です。
以下、現在の私のご指摘に対する回答です。
前提として、セキュリティオフィスの業務分掌が「情報の保護とリスク管理」であるものとします。
■「具体的な代案を提示すべきは常にセキュリティオフィス側の仕事」
これをSAやSEの立場にある人間が言う場合、それは間違いです。具体的な対案を出すのはセキュリティオフィスではありません。システムを構築し運用を設計するSAやSEの仕事です。「icmpを閉じる」とはシステムの設計なのです。そしてシステムの設計と構築はは通常企画から移行にかけてレビューを経て行われているものなので、その観点ではセキュリティオフィスの出る幕はないか、意義を唱えることは「icmpを許可しない」という現状≒セキュリティ上の決定を、その分野を司る業務分掌をもつはずの自分が自らを否定する行為になります。変更をかけるのであれば、利用部門が要望を出し、その要望をもって対応すべきシステムをそのシステムの主管箇所が対応をするものです。セキュリティオフィスはこの対応に際してレビューをする立場となるはずです。
■「結論としてどうすべきかの判断をするのはあくまで経営者なのであって、セキュリティオフィスにそんな権限はありません。」
これも間違いです。経営者はあらゆる判断を下しますが、すべてのことを実際に判断するわけでもなければ、できるわけでもありません。故に組織は存在し、業務分掌が行われ権限が移譲されます。経営者が行うことは責任を負うことです。必ずしも判断することではないのです。セキュリティオフィスという組織の存在は、経営者からその部分のいくばくかの判断を業務分掌として移譲されていることを示します。ご指摘の内容を鑑みて、おっしゃるように経営者と同等の権限はないとしても、「そんな権限はない」と切って捨てられるほど軽々しい権限を委譲されているものではないのです。担当者レベルではその色を感じることは少ないでしょが、セキュリティオフィスの組織長レベルになれば「現代において己の判断が企業の存亡に係る」と言うほどの緊張と責任を背負っている人も少なくない。そういう組織です。
判断を下すのは経営者とは限らず、経営者は責任を負うことになる存在であり、
セキュリティオフィスとは、経営から業務を分掌されることで一部判断を委ねられた重要な組織なのだ
というのが私の認識です。
■「落としどころを探るのがセキュリティオフィスの仕事」
"落としどころ"とは"要望によって得られる効果に対してどの程度のリスクを許容するか"が具体です。
諮る事柄は「icmpを解放することに対してリスク許容してもらえますか？」となると思います。
これに対して「OKだよ」と答えを出す材料を出すか、それをセキュリティオフィスに求めるか。
「他の企業が許可しているから我が社だって許可したって大丈夫」って言いうか、言わせるか。
結局はそこで議論が平行線になるはずです。判断材料が必要になります。判断材料、つまり金です。
私は回答において「コスト」や「ロス」を見て判断すると書きました。「金で判断となる」と。
※回答表誤りがありましたのでお詫びして訂正します。（回答本文も訂正します）
コストとは、ユーザ部門や運用部門にて発生する工数を指します。
ロスとは、機会損失による収入や回収の消失および損害賠償を指します。
（当初回答ではコストとロスを逆の意味で書いていました）
ロスはセキュリティオフィスが想定損害額を見積もることはできるでしょう。ですがコストは別。
コストを出せるのは、今回の場合ヘルプデスクと運用部門です。
そのコストが損害賠償額に対してどうかが「落とす」「落とさない」の判断ポイントになります。
落としどころを探るセキュリティオフィスは、落としどころに必要な情報を自身で得られないのです。
忘れてはならないのは情報の所管箇所です。
セキュリティオフィス、ヘルプデスク、運用部門。いずれも情報の所管箇所ではありません。
情報の所管箇所とは、例えば顧客情報であれば営業部門。技術や設計情報であれば設計部門といった組織。セキュリティ事件において、直接的にダメージを受ける組織はこれら情報の所管箇所です。
金の判断をなしにセキュリティオフィスが落としどころを探るとするならば、こうした情報所管組織に対して漏洩リスクを許諾してもらえるかどうか諮るような話になります。
今回の「icmpを解放する」のを情報所管部門が許諾する可能性があるとすれば、情報所管組織自身がクレームや自身の業務に支障が出るほどの不都合が発生している状況がある場合しか考えられません。もし、そんな状況があるならば、それはシステムの設計そのものを見直すべきで、となればセキュリティオフィスが関わる以前の話です。
落としどころをセキュリティオフィスに出せと言ったところで、
セキュリティオフィスが判断や情報所管組織を説得するには根拠や材料が必要。
その情報はセキュリティオフィスだけで出せるものでなく、ポイントとなる情報は要望元が持つ。
要求したところで、目的を達成するための情報は自分自身で提出しなければならない認識です。
今回でいえば、ヘルプデスクや運用部門が頑張る必要があるということです。
といった裏がありまして、
「楽がしたい程度なら出直せ」「作業の効率化をしろ」と言い、
それでもしたいというなら「相談に乗って一緒になってエスカレーション」
つまり、「人の手でやっていることを機械化（自動化）する方向を実施するための調整」をする
と回答を投稿しました。
「骨は折れるがログを見て確認できる」ならば、ヘルプデスクに必要なのは「icmpの解放」ではないのです。
「通信元/通信先を限定している」ならば、運用が語るべきは「通信先/通信先を限定しないことの意義」なのです。
不満は十分。必要なのは要件定義。
そして、要件はいずれにおいても「icmpの解放ではない」という認識で、
だから「そんなリスクは犯さず」「ちゃんと考えさせて検討させる」ことが必要だと思っています。
これが、私のmatobaaさんに向けたメッセージです。
最後に、あえて聞きます。
仮に自分自身が経営者であった時
現状、運用で対応が行えている事実があるのに
複数案あるわけでもなくセキュリティリスクを対価にするという案一択の状態で
かつコスト面について全く触れもせずに
裁可願いますという内容で
聞いてみたら、エスカレーションされてきた理由が「不便だから」です
そういう企画書が来た。
どう答えますか？
指摘の要望としての視座・視点での言い分は非常によくわかる。
けれど、その視座・視点での主張や指摘には説得力があるのか。
私た書いた今回のコメントを論破（セキュリティオフィスが動けるような後押しが）できるのか。
もしもできるのであれば、私自身とても知りたいです。
セキュリティオフィスとの調整は大変なのでね。
私があなたの言っていた「解答の裏」に期待していたのは、
ICMP type0,8(echo reply/echo request)だけを通すとかの絞り切った設定にしても、
そこからクラックされてしまう具体的で致命的な危険が、
Ping of death対策が進んでいる現時点でも存在する事例を挙げた上で、
ICMPはどう限定をかけたとしても無条件で危険なので閉めなければならない、
という流れになることだけでした。残念です。
>最後に、あえて聞きます。(略)どう答えますか？
これじゃ判断できんわあ。
まず誰がどのくらい不便なん？具体的に数字にならんの？安くいい感じに済ませる方法ないんかな？
それで、緊急なんこれ？お客様に余計な手間かけさせてる？いかんなあ。
これセキュリティの話だよね？じゃあセキュリティオフィスのAくん、その辺まとめて持ってきて。
とりあえずはスピード重視の概算でええからね。判断はそれ見てからね。
コメントありがとうございます。
おっしゃる通りだと思います。
ICMPはどう限定をかけたとしても無条件で危険であると言うとができません。
経営はダメージよりもコストとロスのコントロールを優先しているようです。
ご期待に応える回答が私にはできません。
matobaaさんへ
質問は「リスクを知りたい」とありますが、「判断に困っています」という言葉から「icmp echoを通したいが通してよい根拠が欲しい」と勝手ながら解釈を変え、提案を一つさせていただきます。的外れであれば流してください。
困らずにicmp echoを通す判断をするには、ペネトレーションテスト（ペンテスト）を行うことをお勧めします。
理由はリスクを調べる（これを調べきるのはたぶん無理）よりも何かと楽で得るものもあるからです。
ペネトレーションテストをすることで、検査時時点の脆弱性やリスクの有無が客観的にわかるとともに、脆弱性がリスクが検出されなかった場合、その時点で一般的に認識されている脆弱性が存在しないことが示されます。これはicmp echoをとして良いと言える明確な根拠になります。仮に脆弱性やリスクが検知されても、その内容や対策を知ることができます。
ペネトレーションテストをしておけば、万が一、億が一にセキュリティインシデントが発生した時にも最低限の言い訳として評価されます。
ペネトレーションテストについては「E-light」さんの下記の記事が参考になります。
https://e-light-security.jp/blog/20160317_1001.html
ペネトレーションテストを行う会社はいくつかあります。費用は見積もりにて得ることになります。
「とりあえずはスピード重視の概算」としてはペネトレーションテストの費用だけで良いと思います。
脆弱性がリスクがあった時の対応費用は、内容によって変わるのでテスト後になります。
また、全く別の情報漏洩対策として、情報漏えい賠償責任保険でカバーする手段もあります。
上長や経営に諮る際に情報としてあると、判断の援けになると思います。
これまでコメントさせていただいた以上の回答や対応策はありません。私自身力不足です。
「icmp を通すか、塞ぐか」という質問から脱線してしまいましたが、以上です。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。