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

ある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 アドレスの不正利用に関しましては、いち早く検知できるためのシステムを整備いたします。
• また、不正利用が判明した際には、速やかにネットワークから隔離できる体勢を早急に整備いたします。

これは完全には防げないという話のように聞こえますが、そんなものなのでしょうか。ネットワーク技術に詳しいスラド諸兄のご解説をお願いします。

簡易補足

[token (7668)]

# タレコミ文の ARP Spoofing の説明先が en.wikipedia.org なので
# 適当なページを拾ってみた

  * ARPスプーフィングで通信傍受！ [jugem.jp]

--
俯瞰しよう。何事も俯瞰しなくちゃ駄目だ。

sakura 使ってます

[elderwand (34630)]

同じ 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 依存ですので、ご注意。

Re:sakura 使ってます

[nakack (2942)]

arpwatch がいいんじゃないの?

Re:sakura 使ってます

[elderwand (34630)]

SW HUB が使われている（であろう）この頃では、ネットワークにつながれたマシンの MAC アドレスを収集するには、こちらから積極的に ping をかけるとかしないといけないんですが、アパート間借の身としては、隣近所、用もないのにノックしてまわるのは気が引けます。

なので、default router だけが分かればよしとします。

NetScreenのログイン開けっ放し？

[nagika (30998)]

http://aquadrops.jp/archives/362 [aquadrops.jp]
ポカミスかどうかは知らないけど、勘弁して欲しいよね。

Macのサーバー

[Anonymous Coward]

MacはWebサーバーにならないの？
もしもサーバーがMacだったら、こんな事態は防げたと思うんだ。

Re:Macのサーバー

[elderwand (34630)]

spoof されたのが MAC address だけに、、、ていうオチですか？

Re:Macのサーバー

[hautbrion (36016)]

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

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

MACのサーバー

[SteppingWind (2654)]

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:

[Anonymous Coward]

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

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

Re:

[Anonymous Coward]

もちろんあるよ。

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

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

犬糞なんかを使ってるところはご愁傷様。

Re:Macのサーバー

[fslasht (3370)]

それを言ったら、さくらインターネットもレンタルサーバのOSはFreeBSD使ってると思うんですが・・・

Re:Macのサーバー

[Anonymous Coward]

OpenBSDなら！OpenBSDならきっとなんとかしてくれる！！

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

Re:Macのサーバー

[saitoh (10803)]

今回トラブルが起きたのはレンタルサーバではなく「専用サーバ」です。専用サーバでは、借り受けた顧客が、FreeBSD/Linux/Windows（ほかにもあったっけ？）の中からどれかを選ぶ、ということになっていたはず。

Re:

[Anonymous Coward]

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

未だに責任の所在が曖昧

[Grace (23965)]

現時点でも未だにウイルスの内容と感染者に対するさくらインターネットからの
フォローや、ウイルスチェックのための特設ページや告知がないのは
それらは各サーバー管理者がやるべきことであり、
さくらインターネットは責任を負わないという風に見えるのですが
規約や法律的に考えてどうなのでしょうか。
クラッキングされたであろう該当サーバーや管理責任者も非公開なので、
事業者間での損害賠償請求を推奨しているわけでもないようですし。

Re:未だに責任の所在が曖昧

[Anonymous Cowpat (32210)]

以下、高木氏の見解。
Webサイト運営者から状況を発表せよというのは酷な話ではないだろうか。 [takagi-hiromitsu.jp]

Re:未だに責任の所在が曖昧

[alp (1425)]

責任はないとはおもいますが、これは不賛成。このばあい、仮にどんなに大きくさくらインターネットのトップページに情報を載せたところで、「ゆずソフト」に訪れた訪問者にそれを伝えるという点でなんの意味もないでしょう。現実的には、高木氏の言う A でやられた場合は、可能性のあるサイトに公表義務を課してしまう方が現実的でしょうから、状況を発表するという義務は当然負わせるのが妥当じゃないでしょうか。

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

Re:

[Anonymous Coward]

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

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

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

スタティックにする？

[Anonymous Coward]

すでに他の方も仰っていますが、ARP偽装を防ぐには
ルータ等のARPテーブルをスタティック（静的、手動設定）にするしか
無いかと思います。ただ、サーバの台数などを考えると難しいかも。

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

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

Re:スタティックにする？

[hautbrion (36016)]

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

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

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

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

Re:スタティックにする？

[Ryo.F (3896)]

話が見えないんですが…

ルータのarpテーブル手管理はしててなんら不思議ではないですねぇ。

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

Re:スタティックにする？

[Ryo.F (3896)]

今後は、OSの初期設定時にMACも独自設定（連番など？）するような方法が増加するんでしょうか。

しないと思いますが、したら何か利点がありますかね？
むしろ、連番だとMACアドレスを予想できてまずいんじゃないかと。

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

Xenだと、/etc/xen以下のDomU設定ファイルで指定できますね。
でも、仮想マシンの中からifconfig eth0 hw ether AN:YM:AC:AD:DR:ES みたいに変更される危険もあります。

Re:スタティックにする？

[nemunemu (19747)]

http://www.ietf.org/rfc/rfc3021.txt [ietf.org]にあるように、/31のP2P接続にしちゃうって手も。
正直、サーバマシンが同一サブネット内に複数ないと困るような環境（レンタルサーバだし）じゃないのですから、悪くない手だと思いますけどね。

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

Re:スタティックにする？

[Ryo.F (3896)]

さくらが一台一台のサーバをその都度設定すればいいのかもしれませんが、

その他に、入れ替えた機器のMACアドレスを設定し直すって手もありますね。とはいえ、

また、ゲートウェイをVRRPみたいな仕組みで冗長構成とかにしてると切り替わったときに大変です。

そんなのも含めて設計するのは大変なことに違いはありません。VRRPとかだと、OSが更新されると動作が変わるなんてことも無いとは言えないし。
L3機器とL3構成にした負荷分散装置でMACアドレスの付け替えが違ったなんてこともあったなあ。

サーバを収容するL2SWでサーバ=サーバ間の通信を制限することもできます。例えば、アライドのマルチプルVLAN [allied-telesis.co.jp]とか。
が、この手のレンタルサーバサービスは、XenとかVMwareとかの仮想サーバで、サーバ間接続は仮想ネットワークでしょう。Linuxの仮想ブリッジにフィルタとか書けるんだっけ？

Re:スタティックにする？

[Ryo.F (3896)]

後で気づいたんですが、VRRP自体は仕組み的に仮想MACアドレスを使うのでStaticにARPテーブルで指定する分には問題ありません。

そうでもないんじゃないかな？VRRP機器の実装によるけど、サーバからVRRP機器へのフレームは、宛先がVRRP用仮想MACアドレスだけど、VRRP機器からサーバへのパケットは、送信元がVRRP機器固有のMACアドレスだったり、L3的にVRRP機器向こう側にある機器のMACアドレスが使われるって場合もあるよ。
このあたりはVRRPの仕様にはない部分じゃないかと思うので、機器が変わる度、OSが変わる度に検証してみないと解らない。MACアドレスを静的に管理するのは結構難しい。

さくらインターネットのレンタルサーバの場合は、１台専用サーバですね。

おお、本当だ。訂正。
しかし安いねえ。こんだけ安いんじゃ、多少問題があっても文句は言えんと思うな、個人的には。
文句を言うなら、レベルの高い(かつ、おそらく値段も高い)別の業者と契約すべきなんじゃないかな。

PPPoE

[Anonymous Coward]

全サーバをPPPoEで接続させれば根本的に解決。

Re:PPPoE

[elderwand (34630)]

具体的な手順解説を希望。

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

改竄を防ぐだけなら

[Anonymous Coward]

SSL でも使っていれば防げたりしなかったんですか？

Re:改竄を防ぐだけなら

[gtk (14477)]

確かにSSLを使っていれば防げた問題、とはいえるが…現実的にはちとご無体な話じゃありませんかい？
(CPU資源的にもコスト的にも)

Re:改竄を防ぐだけなら

[wildcard (416)]

>証明書の購入
でも安いところならIE,Firefox,Safari,Opera他にすべて証明機関として入ってて5年$122、ってのもあるぜ
http://www.onlinessl.jp/product/starterssl.html [onlinessl.jp]　とか
ひとつとっておけばいろいろ使えるし、趣味の運営でも場合によってはありなんじゃないかと思わないでもない

ネットワーク型のIDS

[65535 (25198)]

サーバーのあるセグメントに、ネットワーク型のIDS入れとけば
ARPスプーフィングの兆候を検出できます。（すべての製品でできるかは知らないけど）
なので、ARPスプーフィングを試みられた段階で対処することは可能と思います。

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

全セグメントの監視やるとコストに跳ね返るから
安価なサービス提供とは相容れないでしょうけど。

手作業でARPテーブルを設定してARP応答はフィルタするとか

[Anonymous Coward]

数が増えるとあんまり現実的ではないなぁ

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[Anonymous Coward]

スイッチレベルでbroadcastを抑制すればいいんじゃないの？
ルータと話せればいいだけだし（つーか、他のサーバとスイッチ経由で会話できるってだけで怖いと思うんだけどさ）

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[rascal (33552)]

通信相手がたまたま隣のサーバであることもありうるのでそれは困ります．

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[Ryo.F (3896)]

NAT環境だと困らない場合もありますね。

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[rascal (33552)]

困るのレベルによりますけどね．もちろん困らない「場合も」ある事は否定しませんが．
スイッチ折り返しでいいはずがルータ折り返しになるので，トラフィックの多いサーバが収容されているデータセンターだとそこがボトルネックになりかねません．

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

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

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[Ryo.F (3896)]

トラフィックの多いサーバが収容されているデータセンターだとそこがボトルネックになりかねません．

それって、ルータの選定に失敗してるんじゃ…

そもそもデータセンターでNATするメリットってあるんですかね．
＜＜略＞＞
VLANで全サーバのブロードキャストドメインを分けておいて，もったいないお化けが出ないようにNAT，ということならありかもしれない．

加えて、NAT環境ならCIDRブロックの端から端まで無駄なく使うことができたりしますね。普通は少なくとも両端がネットワークアドレスとブロードキャストアドレスに取られちゃうから。
あと、ルータなどのネットワーク機器や冗長化・負荷分散システムのアドレスを取られずに済むとか。

ちなみに、サーバ間で通信させたくないだけなら、マルチプルVLAN [allied-telesis.co.jp]ってのもありますよ。

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[rascal (33552)]

>それって、ルータの選定に失敗してるんじゃ…

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

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

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

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

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[Ryo.F (3896)]

それって、ルータの選定に失敗してるんじゃ…

いいえ．
本来(なにが本来か知りませんけど)

まあ、NAT環境なら、本来処理すべきトラフィックで、NAT環境でないなら、そうでなない、としか言い様がないですね。

のために無駄に高価なルータを購入する必要がでてきます．

NAT環境でNAT用にルータと別の機器を準備するって手もあります。

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

それは知っていますが、#1357158 [srad.jp]で、

VLANで全サーバのブロードキャストドメインを分けておいて，

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

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[rascal (33552)]

>VLANで全サーバのブロードキャストドメインを分けておいて

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

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

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

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

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

もちろんVLANもNATも無しで(そして高価な機器を導入しなくても)ARP spoofingを解決する手段があるならそれに越したことはないとは思っていますが．

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[Ryo.F (3896)]

んー、言っていることがよく解らない。

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

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

L3は必要ないですよね．L2SWはVLANスイッチングができればいいです．

L3で分けるのなら、L3SW(もしくはルータ)が必要なのでは？
ルータは既にあるから、それとL2SWを組み合わせて使えば実現不可能ではありませんが、ルータにポートを追加するか、タグVLANサブインターフェースを設定する必要がありそうです。それとNAT処理をさせるのと、どっちが良いか疑問です。

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[rascal (33552)]

別に「実現不可能ではない」というほど現実離れしたものではありません．
おっしゃるようにL3SWでやってもいいし，ルータでやってもいい，どちらでもいいです．

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[Ryo.F (3896)]

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)ならまだ話は解りますが。

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[rascal (33552)]

L3SWでもルータでもいいですけど，必要(な性能とコストがトレードオフする)なら高価な製品を買えばいいんです．
「無駄に」高価なルータを購入する必要はありません．

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

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

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

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

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[Ryo.F (3896)]

たまたまそういう技術を使った案を思いついたというだけで．＜＜略＞＞そのたった一つの案について，ここまで技術的にブレイクダウンする必要があるとは思えません．

単なる思い付きで、大して検討していない意見だ、というのなら、それはそれで構いません。雑談ですから、理論的に完璧な意見しか許されない、と言うわけではありません。

Re:手作業でARPテーブルを設定してARP応答はフィルタするとか

[rascal (33552)]

>単なる思い付きで、大して検討していない意見だ
などと言ったつもりはありませんよ．
ARP spoofingに直接関係ないレベル以上に掘り下げた検討は本題ではないはずだ，という趣旨です．

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

どなたか#1357158 [srad.jp]以降沈めてもらえませんかね．

全部L3処理

[Anonymous Coward]

全Portすべてルータポート、上位L7でバランシングとNAT。 ベンダーが提案してたら怖いな…。

Re:全部L3処理

[gtk (14477)]

うちみたいに /30 で切りまくりんぐなのもどーかと。(涙

Re:全部L3処理

[hautbrion (36016)]

貴重なIPv4アドレス資源を無駄遣いするという点ではもったいないおばけが出そうですが、サーバの運用管理体制が信用できない場合はこれが一番確実かと。