ConoHaの追加情報（2021/11/15）

本件についてブログコメントを頂きました。
私以外にもConoHaで同様の被害に遭われた方がいらっしゃるようです。発生タイミングまで近いとのことで、実はVPSのご近所さんだったという可能性もありますが、仮にそうでないとすると、黒いドロドロとした陰謀を感じざるを得ません。
（もしかして記事の閲覧数が他と比べて多いのは、声を上げない被害者が多いと言うこと？）

話を戻すと、ConoHa全体が標的になっているか、あるいはConoHa以外のVPSも標的になっている可能性があるということです。もしVPSを運用している人がいれば、取り急ぎご自身のサーバのarpテーブルを確認された方が良いかと思います。
デフォルトゲートウェイは、一般にCISCOルータのHSRP仮想MACアドレスや、VRRPの仮想MACアドレスなどになっていると思われます。（そうでないケースもあるので、決めつけはダメ）
ただ、確実に言えることは、基本的にデフォルトゲートウェイのMACアドレスはユニークであるべきで、どこかのVPSノードと重複していることはありえません。（そうなっていたらアウト！）

OpenBSDはOS標準（カーネル？）でarp汚染監視を行っており「arp info overwritten for xxx」といったログが残りますが、Linuxディストリビューションの勝手は分かりませんので、必要ならarp監視ツールを導入するのも良いと思います。


ちなみに、通信はsshやhttpsのように暗号化されているのでarpスプーフィングでパケットを盗聴されても問題ないと思っている人がいるかもしれませんが、大きな間違いです。通信先のトレンドは情報の宝庫です。

例）特定のIPアドレスとの通信が多い
→IPアドレスで身元が分かる場合があり、法人であれば、その法人の管理するVPSであることが判明。

例）特定のIPアドレスとの通信が多い＋他の法人と通信を行っている
→該当VPSが社外との通信を行っている業務サーバであることが判明。
　時期や通信の時間帯によって、経理データなどと特定できる場合あり。

例）サービス特有のポートで通信
→80、443、25、587などは用途がモロバレですね。
　telnetポート（TCP/23）で通信しようものなら、パケットキャプチャされて情報漏洩です。

例）サービス隠蔽がバレる
→管理通信にはssh（TCP/22）を使うことが多いですが、該当ポートの通信がなく、
　TCP/2022などでインタラクティブな通信を検出した場合、sshのポート番号変更（サービス隠蔽）がバレてしまいます。

といった感じで、過信は厳禁です。
まあ、私はConoHaを長期契約してしまっているので、そう簡単に引っ越すことはできないのですけどね。また、VPS業界全体を覆うようなクラッキングの動きであれば、他にどこに行っても同じでしょうし。

タグ：conoha