IPC$（プロセス間通信共有）とは？仕組みとセキュリティリスクを徹底解説

Windowsのネットワーク機能を調べていると、「IPC$」という謎の共有フォルダを見かけることがありますよね。この「IPC$」は、他の管理共有（C$やADMIN$）とは少し違った、特殊な役割を持っているんです。

実は、IPC$は「ファイルを共有するための共有フォルダ」ではありません。これはWindowsのプロセス同士が、ネットワーク越しに会話するための「通信チャンネル」なんですよ。

今回は、このちょっと不思議なIPC$について、基礎から応用、そしてセキュリティリスクまで、分かりやすく解説していきますね。

IPC$とは何か？
名前付きパイプとIPC$の関係
IPC$の動作の仕組み
1. 接続プロセスの詳細
2. 実際の接続コマンド
NULLセッション攻撃とは
WindowsバージョンごとのIPC$のセキュリティ
IPC$のセキュリティ対策
IPC$の正当な用途
IPC$の確認とトラブルシューティング
よくある質問（Q&A）
まとめ

IPC$とは何か？

基本的な定義

IPC$（Inter-Process Communication Share）は、プロセス間通信のための特殊な共有リソースです。「$」が付いているので隠し共有の一種なのですが、他の管理共有とは根本的に違う性質を持っています。

IPC$の最大の特徴

ファイルシステム上には実際には存在しない
ファイルやフォルダにアクセスするためのものではない
プロセス同士の通信を仲介する「パイプ役」

つまり、C$が「Cドライブへのアクセス」を提供するのに対して、IPC$は「プログラム同士の会話」を可能にする仕組みなんですね。

プロセス間通信（IPC）とは

そもそも「プロセス間通信（Inter-Process Communication、略してIPC）」とは何でしょうか。

コンピューター上では、多くのプログラム（プロセス）が同時に動いています。Webブラウザ、メールソフト、Windowsのシステムサービスなど、これらのプログラムは時にお互いに情報をやり取りする必要があるんです。

具体例

Webブラウザがプリンタードライバに「この文書を印刷して」と依頼
メールソフトがウイルス対策ソフトに「この添付ファイルをスキャンして」と要求
アプリケーションがWindowsのシステムサービスに「この処理の許可をください」と問い合わせ

こういった、プログラム同士のコミュニケーションを実現する仕組みが「プロセス間通信」なんですね。

IPC$の役割

IPC$は、このプロセス間通信をネットワーク越しに行うための入口となります。

IPC$が提供する機能

リモートプロシージャコール（RPC）の実行
名前付きパイプへのアクセス
ネットワーク上の他のコンピューターとの通信セットアップ
共有リソースの情報収集

例えば、あなたがネットワーク上の他のパソコンのフォルダを開こうとしたとき、まず最初にIPC$に接続して「どんな共有フォルダがあるか教えて」と問い合わせるんです。その後、実際のフォルダ（C$やデータ用の共有フォルダ）にアクセスする、という流れなんですよ。

名前付きパイプとIPC$の関係

名前付きパイプとは

IPC$を理解するには、「名前付きパイプ（Named Pipes）」という概念を知っておく必要があります。

名前付きパイプは、プロセス間でデータをやり取りするための「通路」です。水道管（パイプ）のように、データが一方から他方へ流れていくイメージですね。

名前付きパイプの特徴

一方のプロセスが書き込んだデータを、もう一方のプロセスが読み取れる
双方向の通信が可能
ネットワーク越しにも使用できる
それぞれのパイプには「名前」が付いている

IPC$と名前付きパイプの関係

IPC$は、これらの名前付きパイプへのネットワーク経由のアクセスを提供する窓口なんです。

仕組みの流れ

クライアントが\\サーバー名\IPC$に接続
認証が成功すると、サーバー上の名前付きパイプにアクセス可能に
特定の名前付きパイプ（例：\pipe\lsarpc）を開く
そのパイプを通じてRPC関数を呼び出す
サーバー側のプロセスが処理を実行して結果を返す

つまり、IPC$は「名前付きパイプという通路がある部屋への入口のドア」のような存在なんですね。

主要な名前付きパイプの例

Windowsには、さまざまな用途の名前付きパイプが用意されています。

1. \pipe\lsarpc（LSA RPC）

ローカルセキュリティ機関（LSA）とのRPC通信
ユーザー認証、セキュリティポリシーの照会
ドメイン情報の取得

2. \pipe\samr（SAM Remote）

セキュリティアカウントマネージャー（SAM）データベースへのアクセス
ユーザーアカウントやグループ情報の列挙
パスワードポリシーの確認

3. \pipe\netlogon

ドメインコントローラーとの通信
ドメイン認証の処理
セキュアチャンネルの確立

4. \pipe\srvsvc（Server Service）

サーバーサービスの管理
共有フォルダの情報取得
リモート管理操作

5. \pipe\wkssvc（Workstation Service）

ワークステーションサービスの情報
ネットワーク接続の状態確認

これらのパイプは、それぞれ異なるWindowsコンポーネントが管理していて、アクセス権限も個別に設定されているんです。

IPC$の動作の仕組み

接続プロセスの詳細

IPC$への接続は、通常の共有フォルダへの接続とは少し違ったプロセスをたどります。

ステップ1：SMBネゴシエーション

クライアントとサーバーがSMBプロトコルのバージョンを合意
使用する暗号化方式やセキュリティ設定を決定

ステップ2：セッションセットアップ（認証）

ユーザー名とパスワード、またはKerberosチケットを提示
サーバーが認証情報を検証
認証が成功すると、セッションが確立される

ステップ3：ツリーコネクト（IPC$への接続）

クライアントが「IPC$に接続したい」とリクエスト
サーバーが接続を許可するか判断
許可されると、IPC$への接続が確立

ステップ4：名前付きパイプのオープン

特定の名前付きパイプ（例：\pipe\srvsvc）を開く
そのパイプのアクセス権限をチェック
許可されていれば、パイプが開かれる

ステップ5：RPC関数の実行

パイプを通じてRPC関数を呼び出す
関数ごとにアクセス権限が再度チェックされる
許可されていれば、関数が実行されて結果が返される

このように、複数の段階で認証・認可が行われるため、単にIPC$に接続できたからといって、すべての情報にアクセスできるわけではないんですね。

実際の接続コマンド

IPC$への接続は、コマンドラインから簡単に行えます。

通常の接続（ユーザー認証あり）

net use \\192.168.1.100\IPC$ /user:Administrator

このコマンドを実行すると、パスワードの入力を求められ、認証が成功すればIPC$に接続できます。

接続の確認

net use

現在の接続状況が一覧表示され、IPC$への接続も確認できますよ。

接続の切断

net use \\192.168.1.100\IPC$ /delete

不要になった接続は、このコマンドで切断できます。

NULLセッション攻撃とは

NULLセッションの概念

IPC$には、非常に深刻なセキュリティリスクがあります。それがNULLセッション（Null Session）攻撃です。

NULLセッションとは、ユーザー名もパスワードも提供せずに、匿名でIPC$に接続することを指します。

NULLセッションの接続コマンド

net use \\192.168.1.100\IPC$ "" /user:""

空の文字列（””）をユーザー名とパスワードとして指定することで、匿名接続を試みるんです。

なぜNULLセッションが可能だったのか

「認証なしで接続できるなんて、なぜそんな危険な仕組みがあるの？」と思いますよね。

実は、これには歴史的な理由があります。古いバージョンのWindows（Windows 2000やWindows NT）では、ネットワークの利便性を優先して、一部の情報を匿名ユーザーにも提供する設計になっていたんです。

設計の意図

ネットワーク上のコンピューターの一覧を取得
共有フォルダの存在を確認
ドメインの基本情報を取得
ユーザーログオンの処理を簡略化

当時は、企業内ネットワークは「信頼できる安全な環境」という前提があったんですね。しかし、この設計が後に大きなセキュリティホールとなってしまったんです。

NULLセッションで取得可能な情報

NULLセッションが確立されると、攻撃者は驚くほど多くの情報を入手できてしまいます。

1. ユーザーアカウント情報

ユーザー名の一覧
アカウントの説明
最終ログオン時刻
パスワードの有効期限

2. グループ情報

ローカルグループとドメイングループの一覧
グループのメンバー情報
管理者グループのメンバー

3. 共有フォルダ情報

すべての共有フォルダの名前
共有のコメント
共有の種類（ディスク、プリンタなど）

4. パスワードポリシー

最小パスワード長
パスワードの有効期限
パスワード履歴の保持数
アカウントロックアウトのポリシー

5. システム情報

OSのバージョンとビルド番号
ドメインまたはワークグループ名
コンピューター名
インストールされているサービス

これらの情報は、攻撃者にとって次の攻撃を計画するための貴重な情報源となってしまうんです。

NULLセッション攻撃の実例

攻撃者は、次のような手順でNULLセッションを悪用します。

ステップ1：NULLセッションの確立

net use \\target.company.com\IPC$ "" /user:""

ステップ2：情報収集ツールの使用

攻撃者は、DumpSec、Winfo、enum、rpcclientなどのツールを使って情報を収集します。

DumpSecの例

DumpSec /computer=\\target.company.com /rpt=users /saveas=csv /outfile=users.csv

このコマンドで、すべてのユーザーアカウントの情報がCSVファイルに保存されます。

rpcclientの例（Linux環境）

rpcclient -U "" -N target.company.com
rpcclient $> enumdomusers
rpcclient $> queryuser 0x1f4

これで、ユーザーの詳細情報を次々と取得できてしまうんです。

ステップ3：取得した情報の悪用

ユーザー名リストを使ったパスワード推測攻撃（ブルートフォース）
管理者アカウントの特定と集中攻撃
パスワードポリシーに合わせた効率的な攻撃
共有フォルダへの不正アクセスの試行

攻撃の実際の影響

NULLセッション攻撃は、次のような深刻な被害をもたらす可能性があります。

情報漏洩のリスク

組織内のすべてのユーザー名が判明
誰が管理者かが特定される
ネットワーク構造が明らかになる

パスワードクラッキングの促進

有効なユーザー名が分かるので、攻撃が効率化
パスワードポリシーが分かるので、辞書攻撃が最適化される
アカウントロックアウトの回数が分かるので、検出を回避しやすくなる

さらなる攻撃の足がかり

特定したアカウントへのフィッシング攻撃
ソーシャルエンジニアリングの材料
標的型攻撃の準備

WindowsバージョンごとのIPC$のセキュリティ

Windows 2000 / NT 4.0の時代

最もNULLセッションが危険だった時代です。

デフォルト設定

NULLセッション接続が完全に許可されている
匿名ユーザーが多くの情報を取得可能
RestrictAnonymousレジストリ値が0（無制限）

当時は、企業内ネットワークが外部と厳密に分離されていることが前提だったため、このような設計でも問題視されていなかったんですね。

Windows XP / Server 2003の改善

このバージョンから、セキュリティが段階的に強化されました。

Windows XP Professional

ワークグループ環境では「簡易ファイル共有」がデフォルトで有効
簡易ファイル共有が有効な場合、すべての接続がGuestアカウントとして扱われる
結果的に、管理共有へのアクセスが制限される

Windows Server 2003

RestrictAnonymousの設定が改善
匿名アクセスで利用できるパイプを制限するポリシーが追加
デフォルトでは、まだNULLセッションが可能（互換性のため）

Windows Vista / 7以降の大幅改善

Windows Vistaから、UACの導入により状況が大きく変わりました。

UAC（ユーザーアカウント制御）の影響

リモートUAC制限機能が追加
ローカルアカウントでのリモートアクセスが厳しく制限
ドメイン環境では影響なし（互換性維持）

Windows 7 / Server 2008 R2

匿名アクセスのデフォルト設定がさらに厳格化
「Everyone」グループが匿名セッションに含まれなくなった

Windows 10 / Server 2016以降の現在

現在のWindowsでは、NULLセッションのリスクは大幅に低減されています。

デフォルト設定

NULLセッション接続は可能だが、取得できる情報がほとんどない
名前付きパイプへの匿名アクセスがデフォルトで拒否される
SMB暗号化が標準化

ただし、ドメインコントローラーは例外です。Active DirectoryやRemote Desktop Servicesなどの機能が、一部の匿名アクセスを必要とするため、特定のパイプへの匿名アクセスが許可されているんです。

ドメインコントローラーで許可される可能性のあるパイプ

\pipe\lsarpc
\pipe\samr
\pipe\netlogon

これは、ドメイン環境での認証処理に必要なため、完全には無効化できないんですね。

IPC$のセキュリティ対策

1. RestrictAnonymousレジストリ設定

Windows 2000/XP/Server 2003では、RestrictAnonymousレジストリ値で匿名アクセスを制御できます。

レジストリキー

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous

設定値の意味

0（デフォルト）: 匿名アクセスを許可（最も危険）
1（中レベル）: SAMアカウントと共有の列挙を制限
2（高レベル）: 明示的な匿名権限がない限り、すべての匿名アクセスを拒否

設定方法

レジストリエディタ（regedit）を管理者権限で起動
上記のキーに移動
RestrictAnonymousの値を2に変更
システムを再起動

注意点

設定値を2にすると、一部のアプリケーションが動作しなくなる可能性がある
特に、古いバージョンのWindowsとの通信で問題が発生する場合がある
必ずテスト環境で影響を確認してから本番環境に適用する

2. 匿名でアクセス可能なパイプの制限

Windows Server 2003以降では、より細かい制御が可能です。

グループポリシーでの設定

ローカルセキュリティポリシー（secpol.msc）を開く
「ローカルポリシー」→「セキュリティオプション」を選択
次の設定を確認・変更

重要なポリシー設定

ネットワークアクセス: 匿名でアクセスできる名前付きパイプ

デフォルト値を確認
不要なパイプを削除
完全に空にすると、すべての匿名パイプアクセスが拒否される

ネットワークアクセス: Everyone のアクセス許可を匿名ユーザーに適用する

無効に設定することを推奨
無効にすると、匿名ユーザーはEveryoneグループのアクセス権を継承しなくなる

ネットワークアクセス: 匿名 SID/名前の変換を許可する

無効に設定
これにより、SIDから名前への変換、名前からSIDへの変換が匿名では不可能になる

ネットワークアクセス: SAM アカウントの匿名列挙を許可しない

有効に設定
ユーザーアカウントの列挙を防止

ネットワークアクセス: SAM アカウントと共有の匿名列挙を許可しない

有効に設定
アカウントと共有の両方の列挙を防止

3. NetBIOSポートのブロック

NULLセッション攻撃は、NetBIOS over TCP/IP（NBT）を使用することが多いです。

ファイアウォールでブロックするポート

TCP 139: NetBIOS Session Service
TCP 445: SMB over TCP（Direct Hosting）
UDP 137: NetBIOS Name Service
UDP 138: NetBIOS Datagram Service

Windows Defenderファイアウォールでの設定

「Windowsセキュリティ」を開く
「ファイアウォールとネットワーク保護」を選択
「詳細設定」をクリック
「受信の規則」で該当ポートをブロック

ただし、社内ネットワークでファイル共有を使っている場合、これらのポートをブロックすると正常な業務に支障が出るので注意が必要ですよ。

4. SMB v1の無効化

古いSMB v1プロトコルには多くのセキュリティ脆弱性があります。

PowerShellでの無効化（管理者権限が必要）

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

確認コマンド

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Stateが「Disabled」になっていれば、無効化は成功です。

5. 監査とログの有効化

NULLセッション接続の試行を検出するために、監査を有効にしましょう。

監査の設定

ローカルセキュリティポリシー（secpol.msc）を開く
「ローカルポリシー」→「監査ポリシー」を選択
次の項目を設定

有効にすべき監査項目

ログオンイベントの監査: 成功と失敗の両方
アカウントログオンイベントの監査: 成功と失敗の両方
オブジェクトアクセスの監査: 失敗のみでも可

イベントログの確認

イベントビューアーで「Windowsログ」→「セキュリティ」を開く
イベントID 4624（ログオン成功）とイベントID 4625（ログオン失敗）を監視
ログオンタイプが「3（ネットワーク）」で、アカウント名が空の場合はNULLセッションの可能性

6. ネットワークセグメンテーション

最も効果的な対策は、ネットワークを適切に分離することです。

推奨される対策

一般ユーザーのセグメントとサーバーのセグメントを分離
DMZ（非武装地帯）の設定
VLANによる論理的な分離
ファイアウォールでセグメント間の通信を制御

これにより、万が一攻撃者が内部ネットワークに侵入しても、被害の範囲を限定できます。

IPC$の正当な用途

IPC$は危険なだけではありません。実は、Windowsの多くの正常な機能で使われているんです。

1. ネットワークブラウジング

エクスプローラーで「ネットワーク」を開いて他のコンピューターを見る時、IPC$が使われています。

動作の流れ

ユーザーが「ネットワーク」をクリック
Windowsが周辺のコンピューターを検索
各コンピューターのIPC$に接続（自動的に認証情報を使用）
\pipe\srvsvcを通じて共有フォルダの一覧を取得
エクスプローラーに表示

2. 共有フォルダへのアクセス

共有フォルダにアクセスする際も、実はIPC$が最初に使われます。

アクセスのプロセス

\\server\shareにアクセスしようとする
まずIPC$に接続してセッションを確立
認証が成功すると、目的の共有フォルダにアクセス
その後の通信では、確立されたセッションが使われる

3. リモート管理ツール

多くのWindows管理ツールが、IPC$と名前付きパイプを利用しています。

使用例

コンピューターの管理（compmgmt.msc）: リモートコンピューターを管理
イベントビューアー: リモートコンピューターのログを表示
サービスコンソール（services.msc）: リモートサービスの管理
レジストリエディタ（regedit）: リモートレジストリへの接続

PsExecなどのSysinternalsツール

PsExecは、リモートでコマンドを実行するための非常に便利なツールですが、内部的にはIPC$を使っています。

psexec \\remotecomputer -u Administrator cmd

このコマンドは、次の手順で動作します。

IPC$に接続
ADMIN$にサービス実行ファイルをコピー
サービスコントロールマネージャー経由でサービスを起動
名前付きパイプを通じて入出力を転送

4. Active Directoryの機能

ドメイン環境では、IPC$が重要な役割を果たします。

使用される場面

ドメインコントローラーへのログオン認証
グループポリシーの適用
ドメインユーザー情報の取得
Kerberos認証の前処理

ドメインコントローラーでは、これらの機能のために、一部の名前付きパイプへの匿名アクセスが必要なんですね。

5. プリンターの共有

ネットワークプリンターを使う際も、IPC$が関係しています。

印刷のプロセス

プリントサーバーのIPC$に接続
利用可能なプリンターの一覧を取得
プリンタードライバーをダウンロード（必要な場合）
印刷ジョブをスプーラーに送信

IPC$の確認とトラブルシューティング

現在のIPC$接続の確認

自分のパソコンに誰がIPC$経由で接続しているか確認できます。

net sessionコマンド

net session

このコマンドで、現在接続しているクライアントとユーザー名が表示されます。

コンピューターの管理での確認

「コンピューターの管理」を開く
「共有フォルダー」→「セッション」をクリック
接続中のユーザーとコンピューター名が表示される
「開いているファイル」で、どのパイプが使われているか確認可能

IPC$接続でよくあるエラー

エラー: システムエラー 5 が発生しました。アクセスが拒否されました。

このエラーは、認証情報が正しくない場合に表示されます。

原因と対処法

ユーザー名またはパスワードが間違っている → 正しい認証情報を使用
アカウントに管理者権限がない → 管理者権限のあるアカウントを使用
UAC制限により拒否されている → LocalAccountTokenFilterPolicyを設定
アカウントがロックアウトされている → アカウントのロックを解除

エラー: システムエラー 53 が発生しました。ネットワークパスが見つかりません。

このエラーは、対象のコンピューターに到達できない場合に表示されます。

原因と対処法

ネットワーク接続の問題 → pingコマンドで疎通確認
ファイアウォールでポートがブロックされている → ポート139/445を開放
Serverサービスが停止している → サービスを起動
コンピューター名の解決に失敗 → IPアドレスで試す

エラー: システムエラー 1219 が発生しました。同じユーザーによる、サーバーまたは共有リソースへの複数のユーザー名での複数の接続は許可されていません。

このエラーは、同じコンピューターに異なるユーザー名で接続しようとした場合に表示されます。

対処法

# 既存の接続を確認
net use

# 既存の接続を削除
net use \\コンピューター名\IPC$ /delete

# 新しいユーザー名で再接続
net use \\コンピューター名\IPC$ /user:新しいユーザー名

Windowsの制限により、同じコンピューターへは1つのユーザー名でしか接続できないんです。

IPC$が使えない場合の診断手順

1. Serverサービスの確認

sc query lanmanserver

STATE が RUNNING になっているか確認します。

2. ファイアウォールの確認

netsh advfirewall firewall show rule name="ファイルとプリンターの共有"

このルールが有効になっているか確認します。

3. 共有の確認

net share

IPC$が一覧に表示されるか確認します。表示されない場合、Serverサービスに問題がある可能性があります。

4. イベントログの確認

イベントビューアーで「Windowsログ」→「システム」を開き、Serverサービス関連のエラーがないか確認しましょう。

よくある質問（Q&A）

Q1: IPC$は削除できますか？

いいえ、IPC$は削除できません。

IPC$はServerサービスによって自動的に作成される特殊な共有で、手動で削除しようとしても、すぐに再作成されてしまいます。これは、Windowsのネットワーク機能の根幹に関わるものなので、削除することはできないんです。

もしIPC$を無効化したい場合は、Serverサービス自体を停止する必要がありますが、これを行うとすべてのファイル共有機能が使えなくなるので注意が必要ですよ。

Q2: IPC$を完全に安全にする方法はありますか？

完全に安全にする唯一の方法は、Serverサービスを停止することですが、これは現実的ではありません。

実用的な対策としては、次の組み合わせが推奨されます。

RestrictAnonymousを2に設定
匿名アクセス可能なパイプを制限
ファイアウォールで不要な通信をブロック
強力なパスワードポリシーの適用
定期的な監査ログの確認

完全な安全性はありませんが、これらの対策でリスクを大幅に低減できますよ。

Q3: NULLセッション攻撃は今でも有効ですか？

Windows 10やWindows Server 2016以降では、ほとんど無効です。

デフォルト設定では、NULLセッション接続は確立できても、取得できる情報がほとんどありません。ただし、次のような状況では、まだリスクがあります。

注意が必要な状況

古いWindows（Windows 7、Server 2008 R2以前）を使っている
セキュリティ設定が緩和されている（互換性のため）
ドメインコントローラー（一部の機能のため、限定的な匿名アクセスが必要）

特に、古いバージョンのWindowsが混在する環境では、まだNULLセッションのリスクがあるので注意が必要ですね。

Q4: IPC$とC$の違いは何ですか？

根本的な性質が違います。

C$（ドライブ共有）

ファイルシステムへのアクセスを提供
実際にCドライブのファイルとフォルダにアクセス可能
エクスプローラーで開くことができる
ファイルのコピーや削除が可能

IPC$（プロセス間通信共有）

ファイルシステム上には存在しない
プログラム同士の通信チャンネルを提供
エクスプローラーでは開けない
名前付きパイプを通じたRPC通信に使用される

つまり、C$は「ファイルの入口」、IPC$は「プログラム通信の入口」という違いなんですね。

Q5: 自分のパソコンにNULLセッションで接続されているか確認できますか？

はい、イベントログで確認できます。

確認方法

イベントビューアーを開く
「Windowsログ」→「セキュリティ」を選択
イベントID 4624（ログオン成功）を検索
次の条件を満たすイベントを探す

ログオンタイプ: 3（ネットワーク）
アカウント名: ANONYMOUS LOGON または空白
認証パッケージ: NTLM

このようなイベントが頻繁に記録されている場合、NULLセッション接続が試行されている可能性があります。

対処法

直ちにRestrictAnonymous設定を強化
ファイアウォールルールを見直す
不審なIPアドレスをブロック
ネットワーク管理者に報告

Q6: ドメイン環境ではIPC$の設定を変更しても大丈夫ですか？

ドメインコントローラーでは慎重に対応する必要があります。

ドメインコントローラーでは、Active Directoryの機能やKerberos認証のために、一部の名前付きパイプへの匿名アクセスが必要です。

変更してはいけない設定

ドメインコントローラーでRestrictAnonymousを2に設定すると、認証が失敗する可能性
\pipe\lsarpc、\pipe\samr、\pipe\netlogonの匿名アクセスを完全に無効化

一般のワークステーションやメンバーサーバーでは、セキュリティ設定を強化しても問題ありませんよ。

ただし、どんな環境でも、必ずテスト環境で確認してから本番環境に適用することが重要ですね。

Q7: IPC$はファイル転送に使えますか？

いいえ、IPC$は直接的なファイル転送には使えません。

IPC$はファイルシステムへのアクセスを提供するものではなく、プロセス間通信のための共有です。ファイルを転送したい場合は、次のいずれかを使います。

ファイル転送の方法

C$やD$などのドライブ共有を使用
通常の共有フォルダを作成して使用
FTPやSCPなどのファイル転送プロトコルを使用

ただし、PsExecのようなツールはIPC$を使って間接的にファイルを転送します。具体的には、IPC$で接続してから、ADMIN$にファイルをコピーするという方法を取るんです。

Q8: Linux/MacからWindowsのIPC$にアクセスできますか？

はい、可能です。

Linux環境では、Sambaパッケージに含まれるsmbclientやrpcclientを使ってIPC$にアクセスできます。

smbclientの例

smbclient //192.168.1.100/IPC$ -U Administrator

rpcclientの例（NULLセッション）

rpcclient -U "" -N 192.168.1.100

macOSでも、SMBクライアント機能を使ってIPC$にアクセス可能です。ただし、macOSの場合は主にGUIからの共有フォルダアクセスが中心で、IPC$を直接操作することは少ないですね。

まとめ

IPC$は、Windowsネットワークの根幹を支える重要な仕組みですが、同時に大きなセキュリティリスクも抱えています。

重要なポイントのおさらい

IPC$は特殊な共有 – ファイルではなく、プロセス間通信を仲介
名前付きパイプへのアクセス – RPC通信の入口として機能
NULLセッションのリスク – 古いWindowsでは匿名接続が可能だった
現代のWindowsでは改善 – Windows 10以降はリスクが大幅に低減
完全な削除は不可能 – Windowsの基本機能のため、削除できない

推奨されるセキュリティ対策

RestrictAnonymousを適切に設定（ワークステーションでは2を推奨）
匿名アクセス可能なパイプを制限
ファイアウォールで不要な通信をブロック
イベントログの監査を有効化
古いWindowsからの移行を検討

IPC$は、うまく管理すれば強力なツールですが、放置すれば深刻なセキュリティホールになり得ます。特に、企業ネットワークでは、定期的なセキュリティ設定の見直しが重要ですね。

最新のWindowsを使い、適切なセキュリティ設定を行うことで、IPC$のリスクを最小限に抑えながら、必要な機能を活用していきましょう！