フィッシングサイトを踏んだ話

 普段「フィッシングメールに気をつけましょう」と言っている側の人が、あっさりとリンクを踏んでしまった。

やはり人間の認知こそが最大のセキュリティホールであることを自覚し、とても反省したので記録に残します。

引っかかった環境

• AndroidのYahoo!メールアプリ
• 昔からWebサービスやメルマガの登録に使っているアドレスのため、かなり汚れていて、スパム・フィッシング等のメールが毎日たくさん来る。

自分の背景

• スパムメールの観測はそこそこ好きで、PCからだと配信元や誘導先を調査したりしている。
• SBI証券に口座を持っている。
• 昨今のネット証券各社の不正取引のニュースを気にしており、つい先日ログイン方法をFIDOに変えた。

対象のフィッシングメール

普通に見れば、どうみてもフィッシング。

なぜリンクを踏んでしまったか

• 朝の通勤中でぼけーっとしていた。
• SPF・DKIMが(不正なドメインで)PASSしており、SPAMフィルタにひっかからず、受信箱に入ってきていた。
• 日本語が比較的まともだったので、中身をよく精査しなかった。
• ここ最近、証券各社から正規の注意喚起メールがたくさんきていたので、その一環だと思った。
• ちょうどSBI証券の認証を変えたばかりだったので、「今一度ログインを確認しておくか」と思った。

うーん、言い訳の数え役満。

リンクを踏むとどうなるのか

Chrome先生の神Blockが発動。

Google Safe Browsingのブラックリストに一致し止めてくれました。Chomeだけでなく、Firefox、Edge等でアクセスしても同様となります。

なお、別途隔離環境で調べたところ、接続先はHTTPSで証明書も正しく構成されていましたが、アクセスするとSBI証券のログイン画面にリダイレクトされるようになっていました。ごにょごにょ。

反省点まとめ

• わかってはいたものの、メールの日本語がまともかどうかという判断ポイントは、もう捨てないとダメ。
• 人間、興味関心のあるメールはつい見てしまう。
• Google Safe Browsingはホントすごいが、いたちごっこなので、必ずしも助けてくれるわけではない。

以後気をつけますとしか言いようがないのが悲しい…。

Tailscaleがすごいという話

 Tailscaleがすごいのでいろいろ調べた、というメモ。

ここのところ出先から自宅リソースを使いたいことが割とあって、シン・テレワークシステムやChromeリモートデスクトップでWindowsに入ってそこから操作をしていたのだけれど、さすがに不便なので考え直そうかと。

せっかくなのでモダンにWireGuardで組もうとしていたのだけれど、調べたら「Tailscaleを知ってしまったらもう戻れない」みたいな声が多く、試しに入れてみたら、本当にゼロコンフィグのコストゼロでプライベート網が組めてしまい驚いた。めちゃくちゃすごい。

tailscale.com

Tailscaleとは？

クライアントをインストールするだけでVPN網が組めてしまうネットワークサービス。

Googleで分散システムを研究していたエンジニアたちが2019年にトロントで企業し、2020年にサービス開始。

個人利用はなんと無償。法人向けにも複数の契約プランがあるが、いずれもお安い。

サポートドキュメントもしっかり公開されており、わかりやすい。

tailscale.com

なお、基盤をTailscale社ではなく自分でホストするためのOSS、「headscale」もある。Tailscale社とは独立したOSSだが、Tailscaleとの互換性がある。

headscale.net

Tailscaleの基盤技術

WireGuardによるメッシュVPN

Tailscaleは中央集中型ではなく、ノード間をピアツーピアでメッシュ接続する。ベース技術であるWireGuardが軽量で低遅延なので、メッシュネットワークが負荷にならない。

すごいNATトラバーサル

ノードがルータ配下にいてプライベートIPしか持っていなくても、自動でNATを越えて通信経路を確立してくれる。ユーザ側でNATやポート、ファイアウォールの穴あけなどを一切考慮する必要がない。

具体的な動作としては、Tailscaleのコーディネーションサーバが仲介してUDPホールパンチングを行っている。コーディネーションサーバは接続時の認証や仲介を行っているのみで、実通信はノード同士で行われる。

DERPリレーによるフォールバック中継

DERP(Designated Encrypted Relay for Packets)サーバは、Tailscale独自のトラフィック中継サーバで、NATトラバーサルがどうしても成立せず、ノード同士の直接通信ができない場合のみ、トラフィックの中継を担う。

なお、通信自体はノード間でWireGuardにより暗号化されており、DERPサーバは通信を復号することはできない。

​MagicDNSによる名前解決

Tailscaleのプライベート網内で内部DNSが動作しており、各ノードのコンピュータ名と網内IPアドレスを自動で登録してくれる。これにより、ユーザはノードのIPアドレスを気にせず、コンピュータ名でアクセスができる。

ネットワーク的な特徴

ピアツーピアのメッシュネットワークである

前述のとおり、ノード間の通信は直接行われる。中央ノードでトラフィックを管理する仕組みではない。よって、全通信のログを取ったりもできない。仕組み上、トラフィックを監査する系のセキュリティ機能には対応できない。

通常は、ノード同士の通信のみがVPNを通り、その他の通信(インターネット通信など)は、通常どおりの経路でVPNとは関係なく通信する。

出口ノードを作ることが可能

特定のノードを出口ノードとして指定して、全通信を特定のノードからインターネットへ出す設定が可能。例として、海外にいるときにVPN接続して全通信を自宅から出し、接続先Webサイトの地域制限を回避する用途などに使える。

高い耐障害性

たとえばTailscaleに障害が発生して、コーディネーションサーバが利用不可となった場合でも、すでにピアツーピアで接続されたノード同士は影響を受けない。DERPで通信中継している場合や、新規に接続しようとした場合には、NGとなる。

コーディネーションサーバは、世界中のリージョンに展開されており、各リージョンに最低3台以上いるらしいので、そうそう問題はなさそう。日本は東京に設備があり、近隣では香港とシンガポールにあるので、たとえ日本が全台Downしてもどちらかにつながり利用可能。

ノードをルータ的に動作させることもできる

ノードと同じLANサブネット内にいる、Tailscaleクライアントが入っていない端末を、ノード経由でルーティングして通信させることができる。設定はデフォルトではOFFなので有効化が必要。

セキュリティ的な特徴

Tailscaleが通信を見ることはできない

前述のとおり、ピアツーピア通信かつエンドツーエンドで暗号化されるという仕組み上、Tailscaleが通信を覗き見することはできない。なお、Tailscaleの管理画面ではノードの接続履歴と、フローログ(有償プランのみ)を取ることはできる。

ACLの設定は可能

このノード同士は通信させる・させないといったルールは、ACLを書くことで設定可能。ユーザまたはグループを作って指定もできるので、たとえば組織外のゲストにはこのノードのみアクセスさせる、といった設定ができる。

その他の特徴

クライアントの対応が幅広い

Windows、Linux、macOS、iOS、Androidと基本的なところはしっかり対応している他、QNAP、SynologyのNAS用クライアントもある。

Tailscale SSH

Tailscaleに鍵管理を任せることで、自分で鍵作成せずにSSHできるようになる仕組み。前述のACLでアクセス元やユーザを絞ることもできる。地味にすごい便利。

個人利用での用途

• 出先から自宅リソースにアクセスしたい
• 遠方の実家NWをメンテナンスしたい
• 海外から日本経由でインターネットに出たい
• パブリッククラウドと自宅環境でクラスタリングしたい

とかか。用途はレガシなーVPNと大きく変わるものではなさそう。

法人向けとして使えるか?

メルカリでリモートアクセスに採用されている模様。

tailscale.com

もし自分のお客に勧めるなら、とにかくコストを安くしたくて、かつ自分で運用管理ができるならおすすめか。小～中規模のエンジニア組織であればバチッっとはまりそう。

仮に日本のレガシーな企業に入れようとすると、以下を考える必要があると思う。

TailscaleはあくまでVPNソリューションであり、通信部分のセキュリティ対策(Webフィルタリング、CASBなど)は別で必要。その辺を考えると2025年現在はSASE/SSEを入れる方針になりがちだが、そうするならばTailscaleでなくSASE/SSEが持っているプライベートアクセスソリューションを使ったほうがシンプルになるので、悩ましいかも。メルカリの構成が知りたい。

あと、ACL管理を真面目にやる必要がでるため、運用どうするかねという気もする。

 

すべてのリモートアクセス機器を終わらせたい

 

オンプレミスなリモートアクセス装置を用いたリモートアクセスは、もはや限界

タイトルは誇張表現ですが、今こそリモアク構成を見直して、不毛な運用を終わらせてくれと、CVE-2025-22457 のせいで強く思ったよ、というお話です。

なお、本記事の内容はすべて場末のネットワーク屋の観測範囲での主観です。正しい情報はセキュリティ系の専門家をあたっていただくようお願いします。

背景の振り返り

Ivanti (旧Pulse Secure) や Fortigateを使ったリモートアクセスは、コロナ禍以前から、協力会社のアクセスや、緊急時対応用経路として広く企業ネットワークに導入されていましたが、用途としては限定的なものでした。

しかしながら、急にコロナが来たので(QCK)、多くの企業はリスク検討をする余裕もなく、既存のリモートアクセス経路を拡張する形でリモートワーク環境を用意しました。当時のPulse Secureは冗長化・上位機種への買い替え特需で大いに儲かりました。

しかし、リモートアクセス装置は侵入ポイントとしてもめちゃくちゃ優秀でした。

• インターネットに直接繋がっている上に、不特定多数のIPアドレスから接続する前提のため、接続元IP制限はかけられず、原則誰でもアクセスできる。
• なので、クライアント証明書認証・多要素認証など、何かしらプラス認証するべきだが、その整備が間に合わずID/Passのみで認証している企業もそこそこあった。
• 接続後のユーザのアクセス権限も特に制御せず、リモアクできれば以後社内アクセス全許可にしている例もあった。

上記より、悪意ある第三者が普通に認証して社内NWに入られる事例も見ましたし、

• リモアク装置を真面目に運用しておらず、ファームウェアのアップデートがずっとされていない機器も。
• コロナ以後、以前よりさらにIvantiやFortigateが攻撃対象としてメジャーになり、全世界から常時偵察されるようになった。

という背景で、脆弱性を悪用して入られる例もよくありました。

多くはランサムウェアに感染して事態に気づき、調べてみたら侵入経路はファームの古いリモアク装置だったという、そんな感じ。侵入に気づいていない例もあるんだろうと思う。つらい。

そんなわけで、ネットワーク屋としては「リモアク装置の認証は厳しくしよう」「アクセス制御もちゃんとかけよう」「アップデートはすぐ適用しよう」を言いつつ、並行して「機器の運用はつらいのでオンプレを捨ててサービスに移行しよう」という営業をしてきたわけなんですが。

CVE-2025-22457はマジ勘弁

2025年4月に顕在化した Ivantiの脆弱性 CVE-2025-22457 で、もうこれは運用無理でしょと確信した次第。

www.jpcert.or.jp

事の経緯は以下のような流れで、

• 2025年2月、当該脆弱性に関する情報が公開され、アップデートが提供されたものの、当時はBugfixレベルの低リスク扱いだったため、アップデートを見送った企業も多かった。
• しかしながら、2025年4月4日頃、この脆弱性が実際に悪用され、既に多数の侵入事例が観測されている旨が公表された。当初の評価とは異なり、重大な脆弱性であったことが後から判明した次第。
• 2月のアップデートを適用していない企業においては、Ivanti製品を経由して3月中旬から侵入されている可能性がある。

しかも、この脆弱性を利用した侵入においては、改ざん検知ツールを回避/改ざんしているという話もあり、侵入があったかどうかを確認できない可能性も。

また面白いのが(面白くない)、攻撃者は2月の修正プログラムをリバースエンジニアリングして、この脆弱性の悪用手法を確立したと推測されている点で、もうこんなんお手上げじゃんとげんなりした次第。

こんな色々起こるオンプレリモアク装置の面倒見にかける情シス工数はない。

すべてのリモートアクセス機器を終わらせたい

というわけで、リモアク装置の運用から解放されたいです。心から。

移行先の選択肢として考えられるのは、ざっくり分けると以下でしょうか。

• リモアクの口をインターネットに直接晒さなくて良い構成のサービスにする
  • Netskope Private Access、Zscaler Private Access 等
• クラウドサービスを利用し、リモアク運用を専門家に任せる
  • Catoクラウド、通信キャリアが提供するリモートアクセスサービス等

せっかくなので、この機会に合わせてSASE導入を…という営業トークに持っていきたい気持ちはありつつ、取り急ぎリモアク機器だけでも手放してほしいです。

何卒よろしくお願いいたします。