ブログに戻る
·9分で読める·productdevbook

Macで特定アプリのインターネット接続をブロックする方法

macOSでアプリのインターネット接続をブロックする実用的な方法。システム全体を壊さずに済む手順を解説します。

  • macOS
  • Security
  • Privacy
  • Tutorial

2022年に買ったアプリが起動ごとに本国に電話します。ホットスポット中にゲームが3GBアップデートをダウンロードしたい。スキャンユーティリティが何度もアップデートを確認し続ける。アプリを完全にMacのインターネットアクセスから遮断したい——アンインストールせず、システムの残りも壊さずに。

朗報: macOSはユーザが実際必要とするアプリのインターネット遮断方法をいくつか与えます。悪い知らせ: 各々が異なるトレードオフを持ち、間違った選択は静かに失敗するか、壊すつもりのなかったものを壊します。これが実用プレイブック。

ユーザが知るべきMacアプリのインターネット遮断4つの方法

ほとんどの人が選ぶべき大まかな順:

  1. Little Snitch — 専用外向きファイアウォール。アプリ別ルール、初回接続時のプロンプト、編集用GUI。
  2. LuLu — Objective-Seeによる無料オープンソース外向きファイアウォール。Little Snitchより洗練されていない、似たコアアイデア。
  3. macOSアプリケーションファイアウォール+ネットワークフィルタ — 組み込みファイアウォールは受信のみ。外向き遮断にはサードパーティのネットワーク拡張またはpfルールが必要。
  4. /etc/hosts遮断 — 鈍い、部分的、ただ既知のテレメトリエンドポイントには有用。

完全にオフラインにしたい単一アプリには、オプション1か2が正しい答え。他は状況次第。

オプション1: Little Snitch(標準)

Little Snitchは外向き接続を傍受するネットワーク拡張をインストールします。見たことのないアプリが本国に電話しようとすると、Little Snitchがプロンプトを表示します: 1度許可、永遠に許可、1度拒否、永遠に拒否——オプションのスコープ付き(このホスト名のみ、任意のポートなど)。

1つのアプリを完全に遮断するには:

  1. Little Snitch → ネットワークモニター → ルールを開く。
  2. アプリ名を検索。
  3. 既存のルールを削除し次回既定の拒否プロンプトに頼るか、明示的な「拒否——/Applications/YourApp.appからの任意のプロセス——任意の接続」を追加。
  4. 対象アプリを終了して再起動。

Little Snitchは無料デモ(セッションあたり3時間)付きの有料ソフトウェア。カーネルレベルで頼るツールに、一度払うのは正しい動き。

重要なルールスコープ

  • プロセスパス — Little Snitchはディスク上のパスをキーにするので、Sparkle経由のアプリ更新が再プロンプトしうる。再承認するかルールを「任意のバージョン」に設定。
  • ヘルパープロセス — Slack、Discord、Chromeなどのアプリは独自のルールを必要とするヘルパーバイナリを持ちます。親を許可しヘルパーを忘れると、トラフィックがすり抜けうる。ovaのようなモニターはヘルパーを親の下に折りたたむので、これが起きるときに見えます。

オプション2: LuLu(無料)

LuLuはLittle Snitchがすることをより小さい機能セットでします。同じネットワーク拡張モデル、同じプロンプトとルールフロー。トラフィックグラフを表示したりホスト名ベースのフィルタリングをきれいにはしませんが、「この1つのアプリを遮断」のユースケースには完全に十分。

objective-see.orgからダウンロード、Applicationsへドラッグ、ネットワーク拡張権限を許可、沈黙させたいバイナリの拒否ルールを追加。

オプション3: macOS組み込みファイアウォール(限定)

macOSアプリケーションファイアウォールはシステム設定 → ネットワーク → ファイアウォールにあります。受信接続を遮断します。外向きは遮断しません。だから「アプリのインターネット通信を止める」の問いには、組み込みファイアウォールは答えではありません。

受信も遮断したいなら——たとえばアプリが公開したくないローカルサーバを動かす——ファイアウォールをトグルオン、オプションをクリック、拒否リストにアプリを追加。

オプション4: /etc/hosts遮断(部分的)

特定のテレメトリエンドポイントには、ホスト名をブラックホールにできます:

sudo nano /etc/hosts

追加:

0.0.0.0 telemetry.example.com
0.0.0.0 analytics.example.com

Ctrl-Oで保存、Ctrl-Xで終了。それからDNSをフラッシュ:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

これは実際にシステムDNSを参照するアプリにのみ動きます。IPをハードコードするか独自のDNSを使うアプリは/etc/hostsを完全に迂回。DoHを使うブラウザは迂回。だから/etc/hostsを既知のエンドポイント用のスナイパーライフルとして扱い、汎用遮断ではない。

みんなが飛ばす検証ステップ

遮断のセットアップは仕事の半分。残り半分は動作確認。これが別個のモニタリングツールが居場所を稼ぐところ。

パターン:

  1. Little Snitch / LuLu / hostsファイルで遮断を設定
  2. メニューバーで**ovaを開く**。約1Hzでアプリ別トラフィックをサンプリング。
  3. 対象アプリを起動して使う。 クリックして回る。本国に電話していたアクションをトリガー——アップデートチェック、ログイン、同期。
  4. アプリ別行を観察。 上下0KB/sのままなら遮断は保たれる。何か外向きが見えたらリーク。

リークが起こる2つの理由:

  • ヘルパープロセスがカバーされていない。 親アプリが拒否されているが、Slack HelperUpdater.appは依然許可の独自ルールを持つ。
  • 遮断前にキャッシュされた接続。 ルールが存在する前にアプリが長く生きた接続を開いた。アプリを完全に終了し(右クリック → 終了、またはCmd-Q)、再起動。
ライブ検証
Little Snitch拒否ルールを設定後、ovaで通信量ゼロを確認。ヘルパープロセスは親の下に折りたたまれているので、別のPIDからのリークを見逃しません。

特殊ケース

LANアクセスを保ちながらアプリを遮断

一部のアプリはAirPlayスピーカーやローカルプリンタと話す必要があるがインターネットに到達すべきではない。Little Snitchで「任意を拒否」を設定し、LANマルチキャスト/ブロードキャストの許可例外を追加。macOSのローカルネットワーク権限もこれをゲートする——システム設定 → プライバシーとセキュリティ → ローカルネットワークを確認し、アプリがLANを必要としないなら取り消し。

Wi-Fiでアプリを遮断、イーサネットでは許可

Little Snitchはプロファイルをサポート。「カフェ」と「自宅」を作成、異なるルールを添付、メニューバー経由で切り替え。

更新のみ遮断、それ以外すべて許可

ほとんどのアプリは更新トラフィックを機能トラフィックから分離。アップデータバイナリ(しばしばYourApp.app/Contents/Library/LoginItems/または/Library/LaunchDaemons/内)を見つけ、その特定のパスに拒否ルールを追加。アプリを実行、ovaを観察——機能はまだ動き、更新はログでネットワークエラーで失敗するはず。

ファイアウォール遮断が実際に保たれるか確認

ovaはライブのアプリ別トラフィックを表示するので、Little Snitchルールが仕事をしたか確認できます——ローカル、署名済み、約3MB。

macOS用ダウンロード

実例: おしゃべりなユーティリティを沈黙させる

3年前にスクリーンショットユーティリティを買ったとします。生涯ライセンス、以前は静かだったが、今は起動ごとに本国に電話し、新しいオーナーシップを信用しません。

  1. Little Snitchをインストール。 ルールがどう感じるか見るための最初の1時間にトライアルでOK。
  2. スクリーンショットユーティリティを起動。 Little Snitchがプロンプト: 「Snipsterがapi.snipster.appに接続したい」。拒否 → 永遠に → 任意のポートをクリック。
  3. アプリを1週間使う。 機能が動くなら拒否は保たれた。機能が壊れたら、何を呼ぼうとしたか見る——Little Snitchのログに——特定エンドポイントを許可するか決める。
  4. 横でovaを実行。 通常使用中、アプリ別レートが0KB/sのままか確認。

このパターンは、ローカルで仕事をするのに実際にインターネットを必要としないアプリに動きます。

遮断が修正しないこと

正直になるべきこと:

  • APNs経由のプッシュ通知。 macOSはApple Pushをアプリではなくapsd経由でルーティング。アプリを遮断してもその通知を遮断しません。代わりにシステム設定で通知を無効化。
  • システム拡張とデーモン。 一部のアプリは/Library/LaunchDaemons/下にバックグラウンドデーモンをインストール。アプリを終了してもデーモンは終了しません。アプリの公式アンインストーラを使うか、launchctl list | grep -i appname経由でデーモンをリスト。
  • IPをハードコードするアプリ。 まれだが存在。Little Snitchでホスト名ではなくIPで遮断。
  • XPCサービスを使うサンドボックス化されたApp Storeアプリ。 時にユーザ可視のアプリは静かでXPCヘルパーが話す。ヘルパープロセスと同じ修正——Little Snitchのプロセスツリーで見つけ、ルールを追加。

「モニター+ファイアウォール」が永続的なセットアップな理由

ファイアウォールだけ動かせます。モニターだけ動かせます。経験豊富なMacユーザのほとんどは両方動かす:

  • ファイアウォール(Little Snitch / LuLu)はカーネルでポリシーを設定し遮断。
  • モニター(ovaまたは同様)は現実を表示——まだ何が話しているか、どれだけ、いつ。

両者は異なる問いに答えます。「ルールが動いたか?」はモニターの問い。「どの新しいアプリが本国に電話しようとしているか?」はファイアウォールプロンプトの問い。一緒に完全な絵を与えます。

まとめ

エンドツーエンドにMacアプリのインターネットアクセスを遮断するには: 遮断にLittle SnitchまたはLuLu、受信も必要なときのみmacOSアプリケーションファイアウォール、DNSベースの遮断で十分なときは既知エンドポイントに/etc/hostsを使う。それからモニターで検証、確認していないルールは実際持っていないルールだから。

ネットワークを切断すれば、ほとんどのアプリはオフラインで問題なく動く。動かないものは速く分かる——そしてそもそもどの機能がローカルだったかについて有用な何かを学んだことになります。