Braveブラウザーがポートスキャンブロック機能を搭載する
Braveブラウザ、他のブラウザが未実装のセキュリティ機能を追加 - マイナビ
Brave browser will prevent websites from port scanning visitors - Malwarebytes
マイナビの記事では記者が「他のWebブラウザがBraveのようにローカルホストのリソースをブロッキングする機能を追加するかどうかはまだ不明だが、導入されることが期待されている」と締めているが、個人的には色々と疑問だ。実装方法や挙動が不明のため評価待ちといったところではないだろうか。
そもそもの話として、Braveの新機能をサイバーセキュリティー業界での一般語＝ポートスキャンとしてしまっていいのか怪しい。
まず、サイバーセキュリティー業界で一般論的なポートスキャンの話をする。
ポートスキャンはサイバーセキュリティーにおいて、防衛側も攻撃側も行う「情報収集」、あるいは企業などのIT部門が行うインベントリーの構築手段の一部である。組織内のネットワーク上のどのアドレスにどのようなホストが存在するのか？そのホストではどのようなサービスやアプリケーションがインストールされ・動作しているのか？といった個々の情報を組織ネットワーク単位で収集し、ネットワーク上に存在するホスト/ソフトウェア資産をデータベース化する。これに手作業の入力など他の情報を一箇所に集約データベースがインベントリーである。
その情報収集方法として、フィンガープリンティングなどと呼ばれるが、スキャン対象のホストのどのポートでどのようなサービスが動作しているか検出する。例えばWebサーバーがリスニングしているTCP 80ポートにHTTPリクエストを送信して「Server: Apache/2.4.41 (Unix)」などと返ってきたら「Apache HTTP ServerサービスがUNIX/Linuxサーバー上で動作しておりHTTPをリッスンしている」ということが判るわけだが、サイバーセキュリティー的には同時にHTTPサーバーがApache 2.4.41で脆弱性があるバージョンである可能性があることが判り、サイバーセキュリティーの防衛側であれば、自分たちがどういったホスト/ソフトウェア資産と脆弱性を持っているのか把握し対策を講じることになるだろうし、攻撃側であればその脆弱性を利用してホストを攻撃しようとするかもしれない。
余談だが、このためセキュリティーポリシーの整備された組織ではポートスキャン自体を禁止されている場合もある（例：セキュリティーチームなど特定IT部門以外によるポートスキャンを検知→攻撃者の可能性）。
このような理由で、一般論としてホストベースのファイヤーウォールなどでポートスキャンのブロックはセキュリティー機能として存在するが、Webブラウザーというかユーザー空間のアプリケーションでブロックすることは一般的でない。
一般的にはLinuxであればnetfilterカーネルモジュールやWindowsであればWindows Defender Firewallなどがカーネルレベル（TCP/IPでいうトランスポート層とネットワーク層）で行う。というのも、例えばApache HTTP ServerやMicrosoft IISといったHTTPサーバーがTCP 80をリッスンする場合、OSのカーネルがインターネット層からトランスポート層（第2層～第4層）までの処理を行い、ユーザー空間（TCP/IPでいうアプリケーション層=第5層）のサービスの下で動作するスーパーサーバー（LinuxのsystemdやWindowsのsvchost）がカーネルとサービス/アプリケーションとの橋渡しを行うので、ユーザー空間で動作するサードパーティーアプリケーションにポートスキャンのブロックを実装しても他のサービスが使っているポートを監視することはできないからである（TCP/UDPポート毎に各サービス・アプリケーション宛に振り分けられた後のため）。
また、そもそも仮にユーザー空間に実装するとしても、アプリケーションとしての実装ではOSの起動時から終了時まで防護されないことになるためサービスとして実装される必要がある。（従来のポートスキャンに対する従来のnetfilter型firewallであれば）
Braveブラウザーの開発者も当然このことを承知しているはずで、ここでいう「ポートスキャン」は一般的な意味＝ネットワーク経由でマシンに対する（OSカーネルのTCP/IPスタックを経由した）TCP/UDPポートのスキャンとは異なるはずだが、では、なぜWebブラウザーでどういった「ポートスキャン」をブロックする必要があるのかMalwarebytesの記事に概要が説明されている。要点を大雑把に挙げると：
- 訪問者のマシンにポートスキャンを行うWebサイトが存在する
- Webブラウザーはローカルリソースへのアクセスに対し防御・制限していない場合が多い
筆者は寡聞にして、この「ポートスキャンを行うWebサイト」の挙動に詳しくないのだが、恐らくはWebコンテンツに埋め込んだJavaScriptを使ってWebブラウザーに実行させているのだろう。例えばGoogle Chromeの場合JavaScriptエンジン＝V8はNode.jsのようなもの（というかNode.jsがChromeのV8エンジンの流用）だから、ポートスキャナーをJavaScriptで実装しGoogle Chrome内蔵のV8エンジンで実行させることは難しくないだろう。
そして、一般には、安全と見做されるマシン上の安全と見做されるアプリケーションから外部へのアクセスは、ローカルホストではブロックされないことが多いから、ネットワークセキュリティー（例：VLANを使ったアイソレーションなど）次第ではローカルネットワークに対するスキャンも可能だろう。
この場合、Braveがブロックしようとしている「ポートスキャン」とは、サイバーセキュリティー業界での一般的なポートスキャン＝「ネットワーク経由でマシンに対する（OSカーネルのTCP/IPスタックを経由した）TCP/UDPポートのスキャン」とはフローが異なり、「Webブラウザーでローカル実行されるスクリプトから、ローカルホスト・ローカルネットワークに対するTCP/UDPポートのスキャン」という意味なのだろう（記事を読んだ筆者の理解）。
そうすると、恐らくこの「ポートスキャン」のブロック機能とは、Webブラウザー上でサイト毎にサンドボックス実行した上で、サンドボックス内とサンドボックス外との通信をモニタリング・ブロックすることになるのだと思うのだが、サンドボックス外に対するHTTP GETがユーザー操作によるものか、JavaScriptのポートスキャン機能によるものか判別は困難そうに思われる。
家庭用ルーターはRISC-Vに置き換わるのか？
MangoPi RISC-V router will support dual GbE, dual USB 2.0, CAN bus, RS485, and more - CNX Software
CNX-SoftwareがRISC-VベースのSoCを利用したルーター型の開発ボード「MangoPi RISC-V」について報じているのだが、その中で「ルーターは主にMIPSベースのプロセッサーが使われてきて、そしてArmベースに置き換わったが、次はもしかしたらRISC-Vかもしれない」としているのが興味深い。
家庭用ルーターがRISC-Vベースになるかは不明だが、個人的にはWiSoCと呼ばれるルーター用プロセッサー提供元の動向次第ではないかと思う。
まず、ルーターでMIPSからArmに移行した経緯は、ちょうどIEEE 802.11nから802.11acに替わった時期に合致するのだが、振り返ってみるとMIPSからArmへの移行そのものは複合的な要因だったのではないかと思う。
IEEE 802.11nから802.11acへの移行により、WiSoCの性能がMIPSでは限界が見えてきたというような理由もあるのだろうが、それだけならMIPSのままでもMIPS 24K→34K/1004K→InterAptiv/ProAptivなどの選択肢もあったはずである。恐らく、究極的な理由はMIPSの製品ロードマップや会社そのものの動向が不明瞭だったとか、WiSoCのメジャープレイヤーがAtheros・Broadcom（いずれもMIPSユーザー）・Freescale（PowerPCユーザー）からQualcomm・MediaTek・Realtek（いずれもArmユーザー）に交代したとかいう複数の理由が重なった結果ではないかと思う（FreescaleもBroadcomも別製品ではArmを扱っていたが）。
また、802.11n・初期802.11acのメジャープレイヤーの3社がいずれも802.11nから802.11acへの転換期＝2008～2014年頃に買収されており、親会社の意向もあったのかもしれない。
| 年 | 買収した企業 | 買収された企業 |
|---|---|---|
| 2011 | Qualcomm | Atheros Communications |
| 2015 | Avago Technologies | Broadcom |
| 2015 | NXP Semiconductor | Freescale Semiconductor |
さらに、この時期はMIPSも新IPは発表しつつもゴタゴタが続いてロードマップが不明瞭になってきており、対するArmはスマートフォン用SoCで絶好調・毎年新IPを発表していたから、性能不足を理由にMIPSからArmに乗り換えるには良い時期だったのかもしれない。
Qualcomm・MediaTek・Realtekといった企業からすれば、既存製品のノウハウをWiSoC開発に活かすことは理に適っている。
組込用半導体は作って終わりではなく、10年間超に渡る供給保証・各種ドキュメント・BSP/SDKなどと呼ばれる開発キットがセットで提供される必要があり、そのサービスの質が評価される。
例えばQualcommの場合、スマートフォン用SoC＝SnapdragonファミリーではCAF=Code Aurora Forumで既に実績があったから、同社のWiSoC=IPQファミリーでもCAFが使用されることは理に適っていたはずだ。MediaTekもスマートフォン用SoCで・RealtekもSTBやNAS用SoCでArmベースのSoC・各種ドキュメント・BSP/SDKで既にエコシステムが存在したからWiSoCでArmへの移行は既存製品を活かす意味でも効果的だったはずだ。
これが、802.11nから802.11acの過渡期に発生したWiSoCにおけるMIPSからArmへの移行の経緯だが、ではArmからRISC-Vへ移行するのか？というと予想は難しい。
ルーターはスマートフォンとは違い純粋な組込機器にため、CPUアーキテクチャーの違いによるアプリケーションの互換性は問題となり難いからArmからRISC-Vへ移行の技術的な難易度は低そうに見えるし、恐らくCNX記事中のMangoPiホビー用開発ボードようなニッチなマーケットには今後も登場することだろう。
しかし、未だにクローズドな組込以外ではRISC-Vの採用は少ない（恐らくRISC-VのメジャープレイヤーはHDD/SSDのコントローラーに採用しているWestern Digital・Seagateと、GPU内のコントローラーに使用しているNVIDIAだろう）ことを考えると、Qualcomm/MediaTek/RealtekがArmで実現しているようなシナジーやエコシステムをRISC-Vで実現できそうには思えない。
