mhattaによる
2008年06月05日 10時00分の掲載
こればかりは借りてる側ではどうしようもないからな部門より
こればかりは借りてる側ではどうしようもないからな部門より
ある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 アドレスの不正利用に関しましては、いち早く検知できるためのシステムを整備いたします。
- また、不正利用が判明した際には、速やかにネットワークから隔離できる体勢を早急に整備いたします。
この議論は賞味期限が過ぎたので、保存されている。
新たにコメントを書くことはできない。
簡易補足 (スコア:4, 参考になる)
# 適当なページを拾ってみた
* ARPスプーフィングで通信傍受! [jugem.jp]
俯瞰しよう。何事も俯瞰しなくちゃ駄目だ。
sakura 使ってます (スコア:2, 興味深い)
今回のニュースで、自分のホストだけ防衛していてもダメかもしれないと思い、こんなスクリプトを cron で動かそうかと考えました。
コマンドパスは OS 依存ですので、ご注意。
NetScreenのログイン開けっ放し? (スコア:2, 参考になる)
ポカミスかどうかは知らないけど、勘弁して欲しいよね。
Macのサーバー (スコア:1, おもしろおかしい)
もしもサーバーがMacだったら、こんな事態は防げたと思うんだ。
未だに責任の所在が曖昧 (スコア:1)
フォローや、ウイルスチェックのための特設ページや告知がないのは
それらは各サーバー管理者がやるべきことであり、
さくらインターネットは責任を負わないという風に見えるのですが
規約や法律的に考えてどうなのでしょうか。
クラッキングされたであろう該当サーバーや管理責任者も非公開なので、
事業者間での損害賠償請求を推奨しているわけでもないようですし。
Re:未だに責任の所在が曖昧 (スコア:2, 興味深い)
以下、高木氏の見解。
Webサイト運営者から状況を発表せよというのは酷な話ではないだろうか。 [takagi-hiromitsu.jp]
親コメント
スタティックにする? (スコア:1, 参考になる)
ルータ等のARPテーブルをスタティック(静的、手動設定)にするしか
無いかと思います。ただ、サーバの台数などを考えると難しいかも。
今後は、OSの初期設定時にMACも独自設定(連番など?)するような方法が
増加するんでしょうか。
そしてルータ側には、最初から静的なテーブルを読み込ませておくというのはどうでしょう。
サーバが仮想マシンだったら、その辺も簡単でしょうね。
(VMWareなら、.vmxファイル内の記述を変更すればok?)
PPPoE (スコア:1, すばらしい洞察)
改竄を防ぐだけなら (スコア:1, すばらしい洞察)
ネットワーク型のIDS (スコア:1)
ARPスプーフィングの兆候を検出できます。(すべての製品でできるかは知らないけど)
なので、ARPスプーフィングを試みられた段階で対処することは可能と思います。
今回の件では、そういう製品を使ってなかったってことでしょう。
良くてもインターネットとの出入り口付近にIPS入れただけってな感じでしょうか。
全セグメントの監視やるとコストに跳ね返るから
安価なサービス提供とは相容れないでしょうけど。
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1, 参考になる)
ルータと話せればいいだけだし(つーか、他のサーバとスイッチ経由で会話できるってだけで怖いと思うんだけどさ)
親コメント
Re:全部L3処理 (スコア:1)
親コメント