パスワードを忘れた？ アカウント作成
Close
26890 story
インターネット

データセンタ内のARP spoofing攻撃で通信改ざんが発生、対策の定石は? 69

ストーリー by mhatta
こればかりは借りてる側ではどうしようもないからな 部門より

あるAnonymous Coward 曰く、

INTERNET Watchの記事によると、さくらインターネットのレンタルサーバの1台がクラックされ、6月1日1時52分〜6月2日17時23分の期間、ARP spoofing攻撃が発生していたとのことです。これにより、さくらインターネットの「専用サーバ10Mスタンダード」プランの「219.94.145.0〜219.94.145.127」のIPアドレスのサーバの通信経路が変更されてしまい、クラックされたマシンを通して外部と通信する状態になっていたとのこと。セキュリティホールmemoの記事によりますと、さくらでホストされていたethna.jp や jp2.php.net などのウェブサイトで、HTMLにウイルスを埋め込む<iframe>タグが差し込まれていたと報告されており、どうやらクラックされたマシン上で通信の改ざんが行われたようです。
さくらインターネットは、障害情報のページで「6月4日追記」として、今後の対策を次のように挙げています。

  • ネットワーク配下の専用サーバによる IP アドレスの不正利用に関しましては、いち早く検知できるためのシステムを整備いたします。
  • また、不正利用が判明した際には、速やかにネットワークから隔離できる体勢を早急に整備いたします。
これは完全には防げないという話のように聞こえますが、そんなものなのでしょうか。ネットワーク技術に詳しいスラド諸兄のご解説をお願いします。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

データセンタ内のARP spoofing攻撃で通信改ざんが発生、対策の定石は? More

  • 簡易補足 (スコア:4, 参考になる)

    by token (7668) on 2008年06月05日 10時52分 (#1356912) 日記
    # タレコミ文の ARP Spoofing の説明先が en.wikipedia.org なので
    # 適当なページを拾ってみた

      * ARPスプーフィングで通信傍受！ [jugem.jp]
    --
    俯瞰しよう。何事も俯瞰しなくちゃ駄目だ。

  • sakura 使ってます (スコア:2, 興味深い)

    by elderwand (34630) on 2008年06月05日 11時33分 (#1356941) 日記
    同じ sakura の、クラスＢ的に同じネットワークからの ssh brute force が多いです。それなりに防衛してます。

    今回のニュースで、自分のホストだけ防衛していてもダメかもしれないと思い、こんなスクリプトを cron で動かそうかと考えました。

    #!/bin/sh
    cd $HOME/sec
    lastarp=`/bin/cat lastarp`
    router=`/bin/netstat -r | /bin/awk '$1=="default" {print $2}'`
    newarp=`/usr/sbin/arp ${router}`
    if [ "X${lastarp}" != "X${newarp}" ] ; then
        echo "Warning: arp table changed ... "
        echo ">> ${newarp}"
        echo "${newarp}" > lastarp
    fi


    コマンドパスは OS 依存ですので、ご注意。

  • NetScreenのログイン開けっ放し？ (スコア:2, 参考になる)

    by nagika (30998) on 2008年06月05日 20時07分 (#1357307)
    http://aquadrops.jp/archives/362 [aquadrops.jp]
    ポカミスかどうかは知らないけど、勘弁して欲しいよね。

  • Macのサーバー (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2008年06月05日 10時11分 (#1356872)
    MacはWebサーバーにならないの？
    もしもサーバーがMacだったら、こんな事態は防げたと思うんだ。

    • Re:Macのサーバー (スコア:1)

      by elderwand (34630) on 2008年06月05日 13時19分 (#1357051) 日記
      spoof されたのが MAC address だけに、、、ていうオチですか？
      シェア
      親コメント

    • Macのサーバならサーバ管理者がなにもしなくても、arpテーブルがちゃんと管理できて、かつ、arp偽装が防御できるという情報は初耳ですが、情報元プリーズ。

      ♯たぶん、アップルに問い合わせても「できません」と言われるに一票

      シェア
      親コメント

    • MACのサーバー (スコア:1)

      by SteppingWind (2654) on 2008年06月05日 13時37分 (#1357066)

      MacのサーバじゃなくてMAC(というかARP)の代理サーバを立てるという手もありますね. これに加えてクライアント側で指定された代理サーバのMACアドレス以外とのARP送受信を禁止するように設定すれば, 重要/必要なARP情報については集中管理できます.

      一例としてFreeBSDの場合, ARP代理サーバについてはarp(8) [freebsd.org]コマンドの"-s"オプションのあたり, クライアント側のフィルタリングについてはipfw(8) [freebsd.org]の"mac"および"mac-type"オプションあたりが参考になると思います. ARPフィルタリングはネットワーク機器側でやった方が確実かも.

      # ipfilterはよく知らない

      ARPの実装について知りたいならif_arp.h [watson.org]を読むのが一番確実そう.

      シェア
      親コメント

    • Re: (スコア:0)

      by Anonymous Coward
      なんつーか、Mac嫌い乙、としかいいようがないな…
      ＃マッチポンプ？

      ＃まあ親コメントもろとも沈めてくだされ

    • Re: (スコア:0)

      by Anonymous Coward
      もちろんあるよ。

      http://www.apple.com/jp/server/macosx/ [apple.com]

      ベースがfreebsdだから、超堅牢。

      犬糞なんかを使ってるところはご愁傷様。
      • それを言ったら、さくらインターネットもレンタルサーバのOSはFreeBSD使ってると思うんですが・・・
        シェア
        親コメント

        • Re:Macのサーバー (スコア:1, おもしろおかしい)

          by Anonymous Coward on 2008年06月05日 11時43分 (#1356958)
          OpenBSDなら！OpenBSDならきっとなんとかしてくれる！！

          ＃彼に言わせればきっと「人間も(ソーシャルクラックを食らわないように)もっとセキュアに書き換えないとならない」んだろうな。
          シェア
          親コメント

        • Re:Macのサーバー (スコア:1)

          by saitoh (10803) on 2008年06月05日 16時04分 (#1357180)
          今回トラブルが起きたのはレンタルサーバではなく「専用サーバ」です。専用サーバでは、借り受けた顧客が、FreeBSD/Linux/Windows（ほかにもあったっけ？）の中からどれかを選ぶ、ということになっていたはず。
          シェア
          親コメント

    • Re: (スコア:0)

      by Anonymous Coward
      昔月9800円プランで使ってたときはLinuxだったけど、今は金出せばWindowsServer入れられるプランとか有るの？

  • 未だに責任の所在が曖昧 (スコア:1)

    by Grace (23965) on 2008年06月05日 10時46分 (#1356903)
    現時点でも未だにウイルスの内容と感染者に対するさくらインターネットからの
    フォローや、ウイルスチェックのための特設ページや告知がないのは
    それらは各サーバー管理者がやるべきことであり、
    さくらインターネットは責任を負わないという風に見えるのですが
    規約や法律的に考えてどうなのでしょうか。
    クラッキングされたであろう該当サーバーや管理責任者も非公開なので、
    事業者間での損害賠償請求を推奨しているわけでもないようですし。
      • 責任はないとはおもいますが、これは不賛成。このばあい、仮にどんなに大きくさくらインターネットのトップページに情報を載せたところで、「ゆずソフト」に訪れた訪問者にそれを伝えるという点でなんの意味もないでしょう。現実的には、高木氏の言う A でやられた場合は、可能性のあるサイトに公表義務を課してしまう方が現実的でしょうから、状況を発表するという義務は当然負わせるのが妥当じゃないでしょうか。

        ＃第一、ゆずソフトは URL でさくらだということを直接明らかにしていないし。

        シェア
        親コメント

    • Re: (スコア:0)

      by Anonymous Coward
      具体的な状況を想定していないでしょう。規約にそんなことは載ってないし、載せて、細かい事例に対処するほどの料金体系でもないと思う。

      しかも、データセンター側に、使用している側の情報を載せるほどの力はないでしょう。
      どこの会社がどこの会社のサービスを使ってますっていう情報ですからね。

      インターネット使っててウィルスに感染してもISPは補償しないのと同じ原理かと思いますが、これは普通の感覚ではないですか？もちろん、最近のISPはウィルスに感染していると、拡散しないように接続を切断したりすることはありますが。

  • スタティックにする？ (スコア:1, 参考になる)

    by Anonymous Coward on 2008年06月05日 10時46分 (#1356905)
    すでに他の方も仰っていますが、ARP偽装を防ぐには
    ルータ等のARPテーブルをスタティック（静的、手動設定）にするしか
    無いかと思います。ただ、サーバの台数などを考えると難しいかも。

    今後は、OSの初期設定時にMACも独自設定（連番など？）するような方法が
    増加するんでしょうか。
    そしてルータ側には、最初から静的なテーブルを読み込ませておくというのはどうでしょう。

    サーバが仮想マシンだったら、その辺も簡単でしょうね。
    (VMWareなら、.vmxファイル内の記述を変更すればok?）

    • さくらの技術レベル、サポート力とレンタルサーバがどういう仕組みで運用されているか知りませんが、ルータのarpテーブル手管理はしててなんら不思議ではないですねぇ。

      もしも、これしてないとルータがARPテーブル汚染してたら業者の責任問題ですやん。

      さくら利用者さんのコメントもありましたが、さくら内部の他のホストからのssh攻撃多発とすると、さくらのレンタルサーバは踏まれまくりと考えた方がよさそうですな。やはりここは自衛の観点からも、arpデーモン停止、arpテーブル手管理のうえパケットフィルタかけまくりしかないと思われ。

      でも、さくらがarpテーブルに登録すべき情報を教えてくれないとなんとも。

      シェア
      親コメント
      • 話が見えないんですが…

        ルータのarpテーブル手管理はしててなんら不思議ではないですねぇ。
        どんなさくらインターネットによるルータの「手管理」を想定されてるんでしょうか？ルータ側をいじってどうなるという問題ではないと思うんですが。
        それに、MACアドレスは偽装(ってか、設定により変更)可能ですしねえ。
        シェア
        親コメント

    • 今後は、OSの初期設定時にMACも独自設定（連番など？）するような方法が増加するんでしょうか。
      しないと思いますが、したら何か利点がありますかね？
      むしろ、連番だとMACアドレスを予想できてまずいんじゃないかと。

      サーバが仮想マシンだったら、その辺も簡単でしょうね。
      (VMWareなら、.vmxファイル内の記述を変更すればok?）
      Xenだと、/etc/xen以下のDomU設定ファイルで指定できますね。
      でも、仮想マシンの中からifconfig eth0 hw ether AN:YM:AC:AD:DR:ES みたいに変更される危険もあります。
      シェア
      親コメント
    • http://www.ietf.org/rfc/rfc3021.txt [ietf.org]にあるように、/31のP2P接続にしちゃうって手も。
      正直、サーバマシンが同一サブネット内に複数ないと困るような環境（レンタルサーバだし）じゃないのですから、悪くない手だと思いますけどね。

      複数台のサーバとバランサーを置いてやるような環境なら、そこはstaticに書けばいいでしょう。
      そこでも無駄に大きなサブネットにしないようにするなどの手は打てるはずです。
      シェア
      親コメント

  • PPPoE (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2008年06月05日 11時17分 (#1356931)
    全サーバをPPPoEで接続させれば根本的に解決。

    • Re:PPPoE (スコア:1)

      by elderwand (34630) on 2008年06月05日 11時41分 (#1356955) 日記
      具体的な手順解説を希望。

      レンタルサーバがネットに繋がっていないと(ssh で)入れないので、その状態からどうやって認証まで行けるのか悩んでます。
      シェア
      親コメント

  • 改竄を防ぐだけなら (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2008年06月05日 12時00分 (#1356972)
    SSL でも使っていれば防げたりしなかったんですか？

  • ネットワーク型のIDS (スコア:1)

    by 65535 (25198) on 2008年06月05日 15時55分 (#1357168)
    サーバーのあるセグメントに、ネットワーク型のIDS入れとけば
    ARPスプーフィングの兆候を検出できます。（すべての製品でできるかは知らないけど）
    なので、ARPスプーフィングを試みられた段階で対処することは可能と思います。

    今回の件では、そういう製品を使ってなかったってことでしょう。
    良くてもインターネットとの出入り口付近にIPS入れただけってな感じでしょうか。

    全セグメントの監視やるとコストに跳ね返るから
    安価なサービス提供とは相容れないでしょうけど。
  • 数が増えるとあんまり現実的ではないなぁ

    • Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1, 参考になる)

      by Anonymous Coward on 2008年06月05日 11時35分 (#1356943)
      スイッチレベルでbroadcastを抑制すればいいんじゃないの？
      ルータと話せればいいだけだし（つーか、他のサーバとスイッチ経由で会話できるってだけで怖いと思うんだけどさ）
      シェア
      親コメント
      • 通信相手がたまたま隣のサーバであることもありうるのでそれは困ります．
        シェア
        親コメント
        • NAT環境だと困らない場合もありますね。
          シェア
          親コメント
          • 困るのレベルによりますけどね．もちろん困らない「場合も」ある事は否定しませんが．
            スイッチ折り返しでいいはずがルータ折り返しになるので，トラフィックの多いサーバが収容されているデータセンターだとそこがボトルネックになりかねません．

            そもそもデータセンターでNATするメリットってあるんですかね．
            データセンターの管理者にとってもサーバの管理者にとってもマッピングの管理/把握が面倒になるだけのような．

            VLANで全サーバのブロードキャストドメインを分けておいて，もったいないお化けが出ないようにNAT，ということならありかもしれない．
            シェア
            親コメント

            • トラフィックの多いサーバが収容されているデータセンターだとそこがボトルネックになりかねません．
              それって、ルータの選定に失敗してるんじゃ…

              そもそもデータセンターでNATするメリットってあるんですかね．
              ＜＜略＞＞
              VLANで全サーバのブロードキャストドメインを分けておいて，もったいないお化けが出ないようにNAT，ということならありかもしれない．
              加えて、NAT環境ならCIDRブロックの端から端まで無駄なく使うことができたりしますね。普通は少なくとも両端がネットワークアドレスとブロードキャストアドレスに取られちゃうから。
              あと、ルータなどのネットワーク機器や冗長化・負荷分散システムのアドレスを取られずに済むとか。

              ちなみに、サーバ間で通信させたくないだけなら、マルチプルVLAN [allied-telesis.co.jp]ってのもありますよ。
              シェア
              親コメント
              • >それって、ルータの選定に失敗してるんじゃ…

                いいえ．
                本来(なにが本来か知りませんけど)ルータが処理する必要のないトラフィックですから，そのために無駄に高価なルータを購入する必要がでてきます．

                >ちなみに、サーバ間で通信させたくないだけなら、マルチプルVLANってのもありますよ。

                ？
                私は，サーバ間での通信が必要だ，と主張しているのですよ．

                アドレス使用効率を高めるためのNATというのはこのご時世では有効かもしれません．まだアドレス配布もしていて，価格も上がっていない現状ではそこまでひっ迫しているという話はあまり聞こえては来ませんが，将来のために削れるところは削っておくところも出てきているんでしょうかね．
                シェア
                親コメント

              • それって、ルータの選定に失敗してるんじゃ…
                いいえ．
                本来(なにが本来か知りませんけど)
                まあ、NAT環境なら、本来処理すべきトラフィックで、NAT環境でないなら、そうでなない、としか言い様がないですね。

                のために無駄に高価なルータを購入する必要がでてきます．
                NAT環境でNAT用にルータと別の機器を準備するって手もあります。

                私は，サーバ間での通信が必要だ，と主張しているのですよ．
                それは知っていますが、#1357158 [srad.jp]で、

                VLANで全サーバのブロードキャストドメインを分けておいて，
                を受けての意見です。
                「VLANで全サーバのブロードキャストドメインを分け」る意味は何ですか？高価なルータを買うのを避けたいとすると、なおさら意図が読めないんですが。少なくとも、L2の安いスイッチで済むところが、L3でVLANを使える高いスイッチが必要になりますよね。
                シェア
                親コメント
              • >VLANで全サーバのブロードキャストドメインを分けておいて

                「VLANで全サーバのL3を分けておいて」と書いた方がよかったですかね．確かにマルチプルVLANでもブロードキャストドメインは分かれてしまうので．
                同じL3のままL2を分割してしまうと隣のサーバと通信できなくなるので，L3を分けるという話です．別コメントでVLANを分ける話が出ていたのでそれを使ってみました．

                >高価なルータを買うのを避けたいとすると、

                これはNATを使うメリットを考えた時の案ですからね．
                必要(でかつトレードオフする)なら導入すればいいのです．

                >L3でVLANを使える高いスイッチが必要になりますよね。

                L3は必要ないですよね．
                L2SWはVLANスイッチングができればいいです．まぁ，必要なものは買うんでしょう，VLAN＋NATしたいのだとすれば．

                もちろんVLANもNATも無しで(そして高価な機器を導入しなくても)ARP spoofingを解決する手段があるならそれに越したことはないとは思っていますが．
                シェア
                親コメント
              • んー、言っていることがよく解らない。

                「VLANで全サーバのL3を分けておいて」と書いた方がよかったですかね．
                ＜＜略＞＞

                L3でVLANを使える高いスイッチが必要になりますよね。
                L3は必要ないですよね．L2SWはVLANスイッチングができればいいです．
                L3で分けるのなら、L3SW(もしくはルータ)が必要なのでは？
                ルータは既にあるから、それとL2SWを組み合わせて使えば実現不可能ではありませんが、ルータにポートを追加するか、タグVLANサブインターフェースを設定する必要がありそうです。それとNAT処理をさせるのと、どっちが良いか疑問です。
                シェア
                親コメント
              • 別に「実現不可能ではない」というほど現実離れしたものではありません．
                おっしゃるようにL3SWでやってもいいし，ルータでやってもいい，どちらでもいいです．
                シェア
                親コメント

              • L3SWでやってもいいし，ルータでやってもいい，どちらでもいいです．
                やはり言っている事がよく解りません。#1357158 [srad.jp]では、

                スイッチ折り返しでいいはずがルータ折り返しになるので，トラフィックの多いサーバが収容されているデータセンターだとそこがボトルネックになりかねません．
                と言っていたのと整合しません。「どちらでもいい」のではなく、「L3でVLANを使える高いスイッチが必要」(#1357210 [srad.jp])なのでは？

                また、#1357296 [srad.jp]では、

                L3は必要ないですよね．L2SWはVLANスイッチングができればいいです．
                って言ってました。これは、L2SW+(既存)ルータで実現、って話だったんですか？ルータにタグVLANを処理させるのと1:1 NATを処理させるのとでは、負荷の点で大差無いと思います。ならば、どちらの場合も「そのために無駄に高価なルータを購入する必要」(#1357176 [srad.jp])を検討すべきでは？
                ＃1:n NAT(IP masquerade)ならまだ話は解りますが。
                シェア
                親コメント
              • L3SWでもルータでもいいですけど，必要(な性能とコストがトレードオフする)なら高価な製品を買えばいいんです．
                「無駄に」高価なルータを購入する必要はありません．

                ちなみに私の測定した範囲ですので全ての実装でそうとは言い切れませんが，ルータでの1q tagの処理とNATの処理では，1q tagはハードウェア処理できますが，NATはIPチェックサムの再計算があるので1q tag処理のほうが圧倒的に軽いです．

                ところで，最初の話は「NATが必要な(のでもうそこにある)環境」を想定されていたのですか．
                NATの必要性は提示されていなかったので「無駄に高価な～」という話をしてしまいましたけど，NATが必要だという前提で話をしていたのなら，おっしゃる通りだと思います．
                前提が違ったのなら結果的に議論を誤誘導してしまったわけで，#1357158 [srad.jp]はマイナスモデしてもらって沈めたほうがいいですね．

                本題はあくまで「ARP spoofigを防ぐ」という話です．VLANとかNATとかどうでもいいんです．たまたまそういう技術を使った案を思いついたというだけで．
                私は「ARP spoofingを防ぎつつ隣接サーバとの通信は保障し，おまけでグローバルアドレスを効率的に利用する」ための一つの案を提示しただけです．その概念的議論のために，そのたった一つの案について，ここまで技術的にブレイクダウンする必要があるとは思えません．

                よりよい案があるならそれを出していただければいいですし，そもそも「ARP spoofingを防ぎつつ…」という前提に無理があるというのならそちらを指摘していただければすむ事です．
                シェア
                親コメント

              • たまたまそういう技術を使った案を思いついたというだけで．＜＜略＞＞そのたった一つの案について，ここまで技術的にブレイクダウンする必要があるとは思えません．
                単なる思い付きで、大して検討していない意見だ、というのなら、それはそれで構いません。雑談ですから、理論的に完璧な意見しか許されない、と言うわけではありません。
                シェア
                親コメント
              • >単なる思い付きで、大して検討していない意見だ
                などと言ったつもりはありませんよ．
                ARP spoofingに直接関係ないレベル以上に掘り下げた検討は本題ではないはずだ，という趣旨です．

                検討ということなら，1q tagの処理性能にしても，(L2|L3)SWやルータのコストや性能にしても，私自身はそういう評価(単独性能評価や相互接続試験など)を多くのベンダの機器で行っています．
                モデルとしての有用性はともかく，技術的に非現実的だとは思っていませんが，それはこのストーリーからはオフトピです．まぁ，すでにオフトピもいいとこなんでもういいですけど．

                どなたか#1357158 [srad.jp]以降沈めてもらえませんかね．
                シェア
                親コメント

  • 全部L3処理 (スコア:0)

    by Anonymous Coward on 2008年06月05日 10時52分 (#1356913)
    全Portすべてルータポート、上位L7でバランシングとNAT。 ベンダーが提案してたら怖いな…。
typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds