アカウント名:
パスワード:
#!/bin/shcd $HOME/seclastarp=`/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}" > lastarpfi
Macのサーバならサーバ管理者がなにもしなくても、arpテーブルがちゃんと管理できて、かつ、arp偽装が防御できるという情報は初耳ですが、情報元プリーズ。
♯たぶん、アップルに問い合わせても「できません」と言われるに一票
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]を読むのが一番確実そう.
以下、高木氏の見解。 Webサイト運営者から状況を発表せよというのは酷な話ではないだろうか。 [takagi-hiromitsu.jp]
＃第一、ゆずソフトは URL でさくらだということを直接明らかにしていないし。
さくらの技術レベル、サポート力とレンタルサーバがどういう仕組みで運用されているか知りませんが、ルータのarpテーブル手管理はしててなんら不思議ではないですねぇ。
もしも、これしてないとルータがARPテーブル汚染してたら業者の責任問題ですやん。
さくら利用者さんのコメントもありましたが、さくら内部の他のホストからのssh攻撃多発とすると、さくらのレンタルサーバは踏まれまくりと考えた方がよさそうですな。やはりここは自衛の観点からも、arpデーモン停止、arpテーブル手管理のうえパケットフィルタかけまくりしかないと思われ。
でも、さくらがarpテーブルに登録すべき情報を教えてくれないとなんとも。
ルータのarpテーブル手管理はしててなんら不思議ではないですねぇ。
今後は、OSの初期設定時にMACも独自設定（連番など？）するような方法が増加するんでしょうか。
サーバが仮想マシンだったら、その辺も簡単でしょうね。(VMWareなら、.vmxファイル内の記述を変更すればok?）
さくらが一台一台のサーバをその都度設定すればいいのかもしれませんが、
また、ゲートウェイをVRRPみたいな仕組みで冗長構成とかにしてると切り替わったときに大変です。
後で気づいたんですが、VRRP自体は仕組み的に仮想MACアドレスを使うのでStaticにARPテーブルで指定する分には問題ありません。
さくらインターネットのレンタルサーバの場合は、１台専用サーバですね。
トラフィックの多いサーバが収容されているデータセンターだとそこがボトルネックになりかねません．
そもそもデータセンターでNATするメリットってあるんですかね．＜＜略＞＞VLANで全サーバのブロードキャストドメインを分けておいて，もったいないお化けが出ないようにNAT，ということならありかもしれない．
それって、ルータの選定に失敗してるんじゃ…いいえ．本来(なにが本来か知りませんけど)
それって、ルータの選定に失敗してるんじゃ…
のために無駄に高価なルータを購入する必要がでてきます．
私は，サーバ間での通信が必要だ，と主張しているのですよ．
VLANで全サーバのブロードキャストドメインを分けておいて，
「VLANで全サーバのL3を分けておいて」と書いた方がよかったですかね．＜＜略＞＞L3でVLANを使える高いスイッチが必要になりますよね。L3は必要ないですよね．L2SWはVLANスイッチングができればいいです．
L3でVLANを使える高いスイッチが必要になりますよね。
L3SWでやってもいいし，ルータでやってもいい，どちらでもいいです．
スイッチ折り返しでいいはずがルータ折り返しになるので，トラフィックの多いサーバが収容されているデータセンターだとそこがボトルネックになりかねません．
L3は必要ないですよね．L2SWはVLANスイッチングができればいいです．
たまたまそういう技術を使った案を思いついたというだけで．＜＜略＞＞そのたった一つの案について，ここまで技術的にブレイクダウンする必要があるとは思えません．
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
簡易補足 (スコア:4, 参考になる)
# 適当なページを拾ってみた
* ARPスプーフィングで通信傍受！ [jugem.jp]
俯瞰しよう。何事も俯瞰しなくちゃ駄目だ。
sakura 使ってます (スコア:2, 興味深い)
今回のニュースで、自分のホストだけ防衛していてもダメかもしれないと思い、こんなスクリプトを cron で動かそうかと考えました。
コマンドパスは OS 依存ですので、ご注意。
Re:sakura 使ってます (スコア:1)
Re:sakura 使ってます (スコア:1)
なので、default router だけが分かればよしとします。
NetScreenのログイン開けっ放し？ (スコア:2, 参考になる)
ポカミスかどうかは知らないけど、勘弁して欲しいよね。
Macのサーバー (スコア:1, おもしろおかしい)
もしもサーバーがMacだったら、こんな事態は防げたと思うんだ。
Re:Macのサーバー (スコア:1)
Re:Macのサーバー (スコア:1)
Macのサーバならサーバ管理者がなにもしなくても、arpテーブルがちゃんと管理できて、かつ、arp偽装が防御できるという情報は初耳ですが、情報元プリーズ。
♯たぶん、アップルに問い合わせても「できません」と言われるに一票
MACのサーバー (スコア:1)
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)
＃マッチポンプ？
＃まあ親コメントもろとも沈めてくだされ
Re: (スコア:0)
http://www.apple.com/jp/server/macosx/ [apple.com]
ベースがfreebsdだから、超堅牢。
犬糞なんかを使ってるところはご愁傷様。
Re:Macのサーバー (スコア:1)
Re:Macのサーバー (スコア:1, おもしろおかしい)
＃彼に言わせればきっと「人間も(ソーシャルクラックを食らわないように)もっとセキュアに書き換えないとならない」んだろうな。
Re:Macのサーバー (スコア:1)
Re: (スコア:0)
未だに責任の所在が曖昧 (スコア:1)
フォローや、ウイルスチェックのための特設ページや告知がないのは
それらは各サーバー管理者がやるべきことであり、
さくらインターネットは責任を負わないという風に見えるのですが
規約や法律的に考えてどうなのでしょうか。
クラッキングされたであろう該当サーバーや管理責任者も非公開なので、
事業者間での損害賠償請求を推奨しているわけでもないようですし。
Re:未だに責任の所在が曖昧 (スコア:2, 興味深い)
以下、高木氏の見解。
Webサイト運営者から状況を発表せよというのは酷な話ではないだろうか。 [takagi-hiromitsu.jp]
Re:未だに責任の所在が曖昧 (スコア:1)
＃第一、ゆずソフトは URL でさくらだということを直接明らかにしていないし。
Re: (スコア:0)
しかも、データセンター側に、使用している側の情報を載せるほどの力はないでしょう。
どこの会社がどこの会社のサービスを使ってますっていう情報ですからね。
インターネット使っててウィルスに感染してもISPは補償しないのと同じ原理かと思いますが、これは普通の感覚ではないですか？もちろん、最近のISPはウィルスに感染していると、拡散しないように接続を切断したりすることはありますが。
スタティックにする？ (スコア:1, 参考になる)
ルータ等のARPテーブルをスタティック（静的、手動設定）にするしか
無いかと思います。ただ、サーバの台数などを考えると難しいかも。
今後は、OSの初期設定時にMACも独自設定（連番など？）するような方法が
増加するんでしょうか。
そしてルータ側には、最初から静的なテーブルを読み込ませておくというのはどうでしょう。
サーバが仮想マシンだったら、その辺も簡単でしょうね。
(VMWareなら、.vmxファイル内の記述を変更すればok?）
Re:スタティックにする？ (スコア:1)
さくらの技術レベル、サポート力とレンタルサーバがどういう仕組みで運用されているか知りませんが、ルータのarpテーブル手管理はしててなんら不思議ではないですねぇ。
もしも、これしてないとルータがARPテーブル汚染してたら業者の責任問題ですやん。
さくら利用者さんのコメントもありましたが、さくら内部の他のホストからのssh攻撃多発とすると、さくらのレンタルサーバは踏まれまくりと考えた方がよさそうですな。やはりここは自衛の観点からも、arpデーモン停止、arpテーブル手管理のうえパケットフィルタかけまくりしかないと思われ。
でも、さくらがarpテーブルに登録すべき情報を教えてくれないとなんとも。
Re:スタティックにする？ (スコア:1)
それに、MACアドレスは偽装(ってか、設定により変更)可能ですしねえ。
Re:スタティックにする？ (スコア:1)
むしろ、連番だとMACアドレスを予想できてまずいんじゃないかと。Xenだと、/etc/xen以下のDomU設定ファイルで指定できますね。
でも、仮想マシンの中からifconfig eth0 hw ether AN:YM:AC:AD:DR:ES みたいに変更される危険もあります。
Re:スタティックにする？ (スコア:1)
正直、サーバマシンが同一サブネット内に複数ないと困るような環境（レンタルサーバだし）じゃないのですから、悪くない手だと思いますけどね。
複数台のサーバとバランサーを置いてやるような環境なら、そこはstaticに書けばいいでしょう。
そこでも無駄に大きなサブネットにしないようにするなどの手は打てるはずです。
Re:スタティックにする？ (スコア:1)
L3機器とL3構成にした負荷分散装置でMACアドレスの付け替えが違ったなんてこともあったなあ。
サーバを収容するL2SWでサーバ=サーバ間の通信を制限することもできます。例えば、アライドのマルチプルVLAN [allied-telesis.co.jp]とか。
が、この手のレンタルサーバサービスは、XenとかVMwareとかの仮想サーバで、サーバ間接続は仮想ネットワークでしょう。Linuxの仮想ブリッジにフィルタとか書けるんだっけ？
Re:スタティックにする？ (スコア:1)
このあたりはVRRPの仕様にはない部分じゃないかと思うので、機器が変わる度、OSが変わる度に検証してみないと解らない。MACアドレスを静的に管理するのは結構難しい。おお、本当だ。訂正。
しかし安いねえ。こんだけ安いんじゃ、多少問題があっても文句は言えんと思うな、個人的には。
文句を言うなら、レベルの高い(かつ、おそらく値段も高い)別の業者と契約すべきなんじゃないかな。
PPPoE (スコア:1, すばらしい洞察)
Re:PPPoE (スコア:1)
レンタルサーバがネットに繋がっていないと(ssh で)入れないので、その状態からどうやって認証まで行けるのか悩んでます。
改竄を防ぐだけなら (スコア:1, すばらしい洞察)
Re:改竄を防ぐだけなら (スコア:1)
(CPU資源的にもコスト的にも)
Re:改竄を防ぐだけなら (スコア:1)
でも安いところならIE,Firefox,Safari,Opera他にすべて証明機関として入ってて5年$122、ってのもあるぜ
http://www.onlinessl.jp/product/starterssl.html [onlinessl.jp] とか
ひとつとっておけばいろいろ使えるし、趣味の運営でも場合によってはありなんじゃないかと思わないでもない
ネットワーク型のIDS (スコア:1)
ARPスプーフィングの兆候を検出できます。（すべての製品でできるかは知らないけど）
なので、ARPスプーフィングを試みられた段階で対処することは可能と思います。
今回の件では、そういう製品を使ってなかったってことでしょう。
良くてもインターネットとの出入り口付近にIPS入れただけってな感じでしょうか。
全セグメントの監視やるとコストに跳ね返るから
安価なサービス提供とは相容れないでしょうけど。
手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:0)
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1, 参考になる)
ルータと話せればいいだけだし（つーか、他のサーバとスイッチ経由で会話できるってだけで怖いと思うんだけどさ）
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1)
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1)
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1)
スイッチ折り返しでいいはずがルータ折り返しになるので，トラフィックの多いサーバが収容されているデータセンターだとそこがボトルネックになりかねません．
そもそもデータセンターでNATするメリットってあるんですかね．
データセンターの管理者にとってもサーバの管理者にとってもマッピングの管理/把握が面倒になるだけのような．
VLANで全サーバのブロードキャストドメインを分けておいて，もったいないお化けが出ないようにNAT，ということならありかもしれない．
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1)
あと、ルータなどのネットワーク機器や冗長化・負荷分散システムのアドレスを取られずに済むとか。
ちなみに、サーバ間で通信させたくないだけなら、マルチプルVLAN [allied-telesis.co.jp]ってのもありますよ。
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1)
いいえ．
本来(なにが本来か知りませんけど)ルータが処理する必要のないトラフィックですから，そのために無駄に高価なルータを購入する必要がでてきます．
>ちなみに、サーバ間で通信させたくないだけなら、マルチプルVLANってのもありますよ。
？
私は，サーバ間での通信が必要だ，と主張しているのですよ．
アドレス使用効率を高めるためのNATというのはこのご時世では有効かもしれません．まだアドレス配布もしていて，価格も上がっていない現状ではそこまでひっ迫しているという話はあまり聞こえては来ませんが，将来のために削れるところは削っておくところも出てきているんでしょうかね．
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1)
「VLANで全サーバのブロードキャストドメインを分け」る意味は何ですか？高価なルータを買うのを避けたいとすると、なおさら意図が読めないんですが。少なくとも、L2の安いスイッチで済むところが、L3でVLANを使える高いスイッチが必要になりますよね。
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1)
「VLANで全サーバのL3を分けておいて」と書いた方がよかったですかね．確かにマルチプルVLANでもブロードキャストドメインは分かれてしまうので．
同じL3のままL2を分割してしまうと隣のサーバと通信できなくなるので，L3を分けるという話です．別コメントでVLANを分ける話が出ていたのでそれを使ってみました．
>高価なルータを買うのを避けたいとすると、
これはNATを使うメリットを考えた時の案ですからね．
必要(でかつトレードオフする)なら導入すればいいのです．
>L3でVLANを使える高いスイッチが必要になりますよね。
L3は必要ないですよね．
L2SWはVLANスイッチングができればいいです．まぁ，必要なものは買うんでしょう，VLAN＋NATしたいのだとすれば．
もちろんVLANもNATも無しで(そして高価な機器を導入しなくても)ARP spoofingを解決する手段があるならそれに越したことはないとは思っていますが．
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1)
ルータは既にあるから、それとL2SWを組み合わせて使えば実現不可能ではありませんが、ルータにポートを追加するか、タグVLANサブインターフェースを設定する必要がありそうです。それとNAT処理をさせるのと、どっちが良いか疑問です。
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1)
おっしゃるようにL3SWでやってもいいし，ルータでやってもいい，どちらでもいいです．
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1)
また、#1357296 [srad.jp]では、って言ってました。これは、L2SW+(既存)ルータで実現、って話だったんですか？ルータにタグVLANを処理させるのと1:1 NATを処理させるのとでは、負荷の点で大差無いと思います。ならば、どちらの場合も「そのために無駄に高価なルータを購入する必要」(#1357176 [srad.jp])を検討すべきでは？
＃1:n NAT(IP masquerade)ならまだ話は解りますが。
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1)
「無駄に」高価なルータを購入する必要はありません．
ちなみに私の測定した範囲ですので全ての実装でそうとは言い切れませんが，ルータでの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応答はフィルタするとか (スコア:1)
Re:手作業でARPテーブルを設定してARP応答はフィルタするとか (スコア:1)
などと言ったつもりはありませんよ．
ARP spoofingに直接関係ないレベル以上に掘り下げた検討は本題ではないはずだ，という趣旨です．
検討ということなら，1q tagの処理性能にしても，(L2|L3)SWやルータのコストや性能にしても，私自身はそういう評価(単独性能評価や相互接続試験など)を多くのベンダの機器で行っています．
モデルとしての有用性はともかく，技術的に非現実的だとは思っていませんが，それはこのストーリーからはオフトピです．まぁ，すでにオフトピもいいとこなんでもういいですけど．
どなたか#1357158 [srad.jp]以降沈めてもらえませんかね．
全部L3処理 (スコア:0)
Re:全部L3処理 (スコア:1)
Re:全部L3処理 (スコア:1)