Dirty Frag（CVE-2026-43284・43500・46300）とは：Copy Fail 2の対象ディストリと修正版、KEV追加とAndroidの対応

Dirty Frag（ダーティ・フラグ、通称Copy Fail 2）は、LinuxカーネルのIPsec ESP（esp4・esp6）とRxRPC（rxrpc）の受信処理を突くローカル権限昇格の脆弱性です。一般ユーザーの権限から/usr/bin/suなどのページキャッシュを書き換え、rootを取れます。同じ経路の後続Fragnesia（CVE-2026-46300）は10月28日にCISAの悪用確認済み脆弱性カタログ（KEV）へ入り、11月にはAndroidの月例更新にも43284の修正が載りました。3件の違い、ディストリ別の修正版、確認コマンドと緩和策を、2026年11月13日時点の一次情報で整理します。

まとめ：Dirty Fragの要点と今すぐやること

• 中身：esp4・esp6・rxrpcが、ページキャッシュと共有したメモリをその場で復号して書き換える欠陥。CVE-2026-43284（ESP）とCVE-2026-43500（RxRPC）が本体で、CVE-2026-46300（Fragnesia）とCVE-2026-43503（DirtyClone）が同じ部品の後続。
• 悪用：Microsoftが5月8日に、Dirty FragまたはCopy Failを使った可能性のある限定的な攻撃活動を報告。46300は10月28日にKEVへ追加され、PHPのCVE-2026-109618・109619と連鎖してrootでWebシェルを動かせるとCISAが明記した。
• 対象：Ubuntu、Debian、RHEL 8〜10と互換ディストリ、Amazon Linux、Androidなど。RHEL 6・7は3件とも非該当、RHELはrxrpcを出荷しないため43500も非該当。
• 修正版：Ubuntu 24.04は6.8.0-124.124、22.04は5.15.0-181.191、RHEL 9は5.14.0-687.10.1.el9_8で対象の2件が直る（Ubuntuは一般向けGAカーネルの版）。Androidはセキュリティパッチレベル2026-11-05以降。
• つなぎ：IPsecとAFSを使わないホストはesp4・esp6・rxrpcをブロック。IPsecを止められないホストは非特権user namespaceを無効化し、43500の影響を受ける環境ではrxrpcのブロックも併用する。

Copy Fail（CVE-2026-31431）の暫定策であるalgif_aeadのブロックでは、Dirty Fragは防げません。Copy Fail側の修正版はCVE-2026-31431（Copy Fail）のディストリ別修正版と緩和策で扱っています。以下、名前の由来から順に根拠を示します。

Dirty Fragの読み方とCopy Fail 2という別名

Dirty Fragの「Frag」は、カーネルのソケットバッファ（struct sk_buff）が持つfrag（断片）領域のことです。発見者のHyunwoo Kim氏はGitHubのREADMEで、Dirty Pipeの系譜にあり、sk_buffのfragを「汚す」バグなのでこの名前にしたと説明しています。

読み方「ダーティ・フラグ」と設計パターンのdirty flagの違い

カタカナにすると、状態管理の設計手法「dirty flag（変更済みフラグ）」と同じ音になります。「dirty flag ubuntu」「dirty flag android」で脆弱性情報を探している場合は、CVE番号を併記するとDirty Fragの情報を区別しやすくなります。脆弱性を指す「ダーティフラグ」はDirty Fragの表記違いである可能性がありますが、CVE-2026-43284・43500などの番号で対象を確認してください。

「Copy Fail 2: Electric Boogaloo」の由来と発見者

Copy Failを見つけたのはTheoriのTaeyang Lee氏で、Dirty Fragの発見者とは別人です。Kim氏はREADMEで、Copy Failが研究の出発点だったと書いています。「Copy Fail 2: Electric Boogaloo」は、別の研究者が公開済みの修正コミットから作ったPoCのリポジトリ名です。本人はoss-securityへの投稿（2026年5月7日）で、embargoからの漏えいではなく公開コミットを読んで作ったと説明しています。Red Hatもこの通称を併記しています。

公開も異例で、外部要因でembargoが崩れたため、Kim氏はメンテナの求めに応じて5月7日にパッチもCVE番号も無いまま文書を出しました。CVEレコードの公開日は5月8日（43284）と5月11日（43500）です。

3つのCVEとDirtyCloneの違い：成立条件とCVSS

同じ系統でも、攻撃に必要な前提が違います。どの緩和策がどれに効くかは、この表で決まります。CVSSと影響開始版はCVE.orgのkernel.org CNAレコードの値です。

ESP側は、ネットワーク設定の権限を得るために非特権user namespaceを作る必要があります。UbuntuのようにAppArmorでその作成を制限していると成立しません。RxRPC側はnamespaceが要らない代わりに、rxrpcを積むディストリが限られます。ただしUbuntuでは既定で読み込まれます。2件を組み合わせると互いの穴を埋め、主要ディストリのどれでもrootに届く、というのがDirty Fragの全体像です。レース条件に頼らない論理バグで、失敗してもカーネルが落ちにくい点はCopy Failと同じです。

43284のCVSSは、kernel.org CNAがスコープ変更ありの8.8、CISA-ADPとRed Hatが7.8です。Fragnesiaは5月13日にV12のWilliam Bowling氏が公表し、kernel.orgのGreg Kroah-Hartman氏が採番を告知しました。DirtyCloneは6月25日にJFrogが公表したもので、Canonicalの解説によるとモジュールのブロックを済ませていれば影響を受けません。

悪用状況の時系列：Microsoftの観測から46300のKEV追加まで

2026年5月：Microsoft Defenderが観測したsu経由の権限昇格

Microsoftのセキュリティブログ（5月8日、14日更新）は、Defenderが「limited in-the-wild activity」を観測したと書いています。SSHで入った攻撃者がELFバイナリを置いて実行し、直後にsu経由でrootへ上がる流れで、Dirty FragとCopy Failのどちらかと見られています。同じ記事は14日時点で、Fragnesiaの実攻撃は観測していないとしていました。検知名は「Exploit:Linux/DirtyFrag.A」などです。

2026年10月28日：CVE-2026-46300のKEV追加とPHP2Shellとの連鎖

CISAは10月28日、KEVカタログに46300を加えました。登録内容は次のとおりです。

説明文には、PHPのCVE-2026-109618・109619と連鎖させるとPHPのWebシェルを置き、rootでコマンドを実行できると書かれています。PHPの2件は認証なしで遠隔からコードを実行できる欠陥で、10月26日にKEVへ入りました。つまり「ローカルの一般ユーザーが前提だから後回し」という判断は、PHPを公開しているサーバーでは成り立ちません。PHP側の修正版はPHP2Shell（CVE-2026-109618・109619）の影響範囲と修正版にまとめています。是正期限が3日しかないのは、CISAがBOD 26-04の基準で期限を決めているためです。

2026.11.10版のKEVに、43284・43500・43503は載っていません。ただしCISAが付けたSSVCの悪用評価は、43284が「poc」、46300が「active」です。43284と46300は同じESPの経路で緩和策も共通なので、片方だけ直す分け方に意味はありません。

KEV追加を受けた更新の優先順位

• 最優先：インターネットに公開したPHPアプリが動き、カーネルが46300の修正版未満のホスト。PHPとカーネルを同じ作業枠で更新し、先に侵害の痕跡を調べる。
• 次点：コンテナ基盤やCI/CDの共用ランナーなど、他人のコードを動かすホスト。
• 通常枠：社内向けで外からコードを持ち込まれにくいホスト。月次の更新で追いつく。

KEVは46300に「フォレンジック調査を要する」を付けています。再起動でページキャッシュの改ざんは消えますが、置かれたWebシェルやrootで足された設定は残ります。痕跡の探し方は後半の検知の章で示します。KEVを軸に更新の順番を決める運用はKEVで優先度を決めるパッチ管理の手順で解説しています。

ディストリ別の影響と修正版（2026年11月時点）

判断はディストリと更新チャネルに対応するパッケージ版で行います。RHELのEUS・E4Sやリアルタイムカーネルには別の修正版があるため、下表の通常カーネルの値を一律に適用しないでください。上流の版番号は、自前ビルドや上流追従のディストリ向けの目安です。

Ubuntu・Debianで3件を直したカーネルの版

Ubuntuの値はUbuntuのCVEトラッカー、Debianの値はDebianセキュリティトラッカーから取りました。

表のUbuntu欄はGAカーネル（ソースパッケージlinux）の修正版です。22.04以降のGAは同じ版で3件とも修正されていますが、HWE・AWS・Azureなどのカーネルは、それぞれのソースパッケージの修正版で判定します。20.04と18.04は46300だけ後の版で直ったので、5月の更新で止めたホストは46300が残っている可能性があります。20.04以前はUbuntu Pro（ESM）での配布で、16.04（4.4.0-283.317）と14.04（3.13.0-214.265）にも46300の修正が出ています。7.2系の26.10は3件とも非該当です。Ubuntu 26.04の位置づけはUbuntu 26.04 LTSのリリース日と24.04からのアップグレードで確認できます。

RHEL・AlmaLinux・Rocky Linux・CentOS 7の対象可否と修正版

Red HatはRHSB-2026-003で3件をまとめて扱い、いずれもImportantです。CVE-2026-46300のページの修正版は次のとおりで、43503も同じ版で直っています。

RHELはrxrpcを出荷していないため、43500は全バージョンで非該当です。RHEL 7とCentOS 7も3件とも対象外です。停止できないホストには、RHEL 8・9でkpatch-patchが配られました（43284分はRHEL 9.6 EUSで5月18日、RHEL 8などで5月20日、46300分は6月4日以降）。

AlmaLinuxは独自の修正版を先に出しており、版番号がRHELより小さくても修正済みです。AlmaLinuxの告知では、46300を含む版は8が4.18.0-553.124.3.el8_10、9が5.14.0-611.54.5.el9_7、10が6.12.0-124.56.3.el10_1以降です。版の大小だけで判定すると誤ります。AlmaLinux 9・10は、Develリポジトリのkernel-modules-partnerを入れたときだけrxrpc経由（43500）でも影響を受け、8はrxrpcをビルドしていません。Rocky Linuxは自社のエラータで、3件のCVE番号を含む版を確かめてください。

Oracle Linux（UEK）・Amazon Linux・SUSEの修正版

Oracle Linuxは、RHEL互換カーネルとは別に独自のUEK（Unbreakable Enterprise Kernel）を配っており、対象範囲がRHELと違います。Oracle LinuxのCVEページでは、RHELでは非該当の7系でも、UEKなら43284（ELSA-2026-50258ほか、5月9日〜）と46300（ELSA-2026-50288ほか、5月25日〜）の修正が出ています。RHELでは全版非該当の43500も、9・10のUEKは対象で、ELSA-2026-50259などで直っています。Oracle Linuxはuname -rに「uek」が入るかで、どちらのカーネルが動いているかを先に確かめてください。

Amazon Linuxは、セキュリティ速報2026-027-AWS（5月7日公開、27日更新）で43284と43500を扱い、46300は2026-029-AWSに分けています。影響を受けるのは4.14・5.4・5.10・5.15・6.1・6.12・6.18の各カーネルで、修正版はAL2023の6.1ならALAS2023-2026-1694、AL2の5.10ならALAS2KERNEL-5.10-2026-118のように、カーネル系列ごとのアドバイザリに載っています。AWSは更新できない場合の代わりとして、モジュールのブロックに加えsysctl -w kernel.modules_disabled=1（次の再起動まで元に戻せない）も挙げています。SUSEは、SUSEのCVEデータベースでCVE番号ごとに製品別の修正版を確かめてください。

kernel.orgの系列別の修正版

6.6系以降の表掲載系列では、各行の最も新しい修正版以上で3件とも修正済みです（6.12系なら6.12.91以上、7.0系なら7.0.10以上）。5.10・5.15・6.1系は43500の修正版が表で確認できないため、この表だけでは3件の修正完了を判定できません。

5.10〜6.1系の43500は、ディストリ側のバックポートで確かめます。7.1以降は3件とも修正済みです。

AndroidとDirty Frag：2026年11月のセキュリティ情報で修正

GoogleはAndroidセキュリティ情報 2026年11月版（11月2日公開、6日更新）の「2026-11-05 セキュリティ パッチ レベル」のカーネル部品に、CVE-2026-43284（A-510777270、権限昇格、重大度High、Networking）を載せました。6月から11月の版に、43500と46300は載っていません。

43284だけが載った理由は、攻撃チェーンを公開したLSPosedのLSPromiseの説明で分かります。43500に要るRxRPCはAndroidの汎用カーネル（GKI）で無効になっており、43284に要るxfrm-ESPは使えるものの、一般のアプリからはSELinuxで使用が禁じられています。そこでLSPromiseは、Android 17で入ったTelecomの欠陥（CVE-2026-49881、2026年9月に修正）でまずsystem_serverの権限を取り、そこから43284でカーネルに届く構成を取りました。検証機は初期のAndroid 17正式版を載せたPixel 10です。

端末で確かめるには、設定の「セキュリティとプライバシー」などにある「セキュリティ パッチ レベル」（機種によって「Androidのセキュリティアップデート」）の日付を見ます。2026年11月5日以降なら43284の修正を含みます。2026年11月1日の表示だけでは、5日分に分類されたカーネル修正の適用は保証されません。Pixel向けの別の月例情報には、6〜11月の時点で3件とも載っていません。

つまりAndroidでは、端末に入った悪意あるアプリが別の欠陥と組み合わせて初めてrootに届きます。パッチレベルを2026年11月5日以降に上げるのが本筋で、更新が届かない端末では出所の不明なアプリを入れないことが実質的な防御になります。

自環境のカーネルが影響を受けるか確認するコマンド

判定の対象はホストのカーネルです。コンテナはホストのカーネルを共有するので、コンテナの中のディストリ情報では判断できません。版の見方はLinuxのバージョン確認コマンド（os-releaseとuname -r）で解説しています。

# 稼働中のカーネルと、対象モジュールの読み込み状況
uname -r
grep -E '^(esp4|esp6|rxrpc|esp4_offload|esp6_offload) ' /proc/modules || echo "対象モジュールは読み込まれていない"

# Ubuntu / Debian：稼働中カーネルのパッケージ版を修正版と比べる
# 例は Ubuntu 24.04 の GA generic カーネル（6.8.0系）専用。HWE・クラウド用は系列ごとの修正版に置き換える
fixed=6.8.0-124.124
case "$(uname -r)" in
  6.8.0-*-generic)
    pkgver=$(dpkg-query -W -f='${Version}' "linux-image-$(uname -r)")
    if dpkg --compare-versions "$pkgver" ge "$fixed"; then echo "修正版以上: $pkgver"; else echo "修正版未満: $pkgver"; fi ;;
  *) echo "判定対象外の系列: $(uname -r)（HWEやクラウド用はその系列の修正版で比べる）" ;;
esac

# Ubuntu で変更履歴を見るなら linux-modules 側
apt changelog "linux-modules-$(uname -r)" | grep -E -m3 'CVE-2026-(43284|43500|46300)'

# RHEL / Rocky / AlmaLinux 8〜10：稼働中のカーネルに限定して変更履歴を引く
rpm -q --changelog "kernel-core-$(uname -r)" | grep -E -m3 'CVE-2026-(43284|46300)'

Ubuntuでlinux-image-…の変更履歴を引くと、署名用パッケージ（linux-signed）の履歴が返り、CVE番号が出てこないことがあります。モジュール本体を含むlinux-modules-…を指定してください。RHEL系のrpm -q --changelog kernelは、まだ起動していない新しいカーネルの記録まで拾います。kernel-core-$(uname -r)に絞れば、いま動いているカーネルだけを見られます。更新を入れても再起動するまでは古いカーネルが動いている点にも注意してください。

侵害の痕跡を調べる手順と、Dirty Frag系の検知

46300のKEV登録は、CISAのフォレンジック初動調査（Forensics Triage）の対象です。PHPを公開しているホストで、更新の作業に入る前に最低限確かめるコマンドは次のとおりです。

# 1. 公開ディレクトリで内容の最終更新日時が直近14日以内のPHPファイルを洗い出す
sudo find /var/www -type f -name '*.php' -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' | sort

# 2. Webサーバーの実行ユーザーが動かしているシェルを探す
ps -eo user,pid,ppid,lstart,cmd | awk '$1 ~ /^(www-data|apache|nginx)$/ && $9 ~ /(^|\/)(sh|bash|dash|zsh|ksh|ash|fish)$/ {print}'

# 3. これからの悪用に備え、user namespaceの作成とAF_RXRPC(33)ソケットを記録する
sudo auditctl -a always,exit -F arch=b64 -S unshare -F 'auid>=1000' -F 'auid!=unset' -k dirtyfrag_ns
sudo auditctl -a always,exit -F arch=b64 -S unshare -F euid=$(id -u www-data) -k dirtyfrag_web   # Webサーバーの実行ユーザーに合わせる
sudo auditctl -a always,exit -F arch=b64 -S socket -F a0=33 -k dirtyfrag_rxrpc
sudo ausearch -k dirtyfrag_ns -i --start today | tail -n 20

手順1で見覚えの無いファイルが見つかったら、ホストを隔離してから調べます。手順の詳細はWebシェルの検知・除去の手順にあります。

手順3のunshareはブラウザやrootlessコンテナも呼ぶため、記録は大量に出ます。最初のunshareルールはログインUIDが1000以上で未設定ではない利用者の呼び出しを記録します。CLONE_NEWUSERの指定は絞り込んでいないため、user namespaceの作成以外も含み、掲載ルールではclone・clone3や32ビットのシステムコール経由の作成は記録しません。ログインUIDが未設定のWebサービスは、2行目のように実効UIDを条件にした別ルールで拾います。auditctlのルールは再起動で消えるので、残すなら/etc/audit/rules.d/に書きます。製品の検知ルールも出ています。Elastic Security LabsはCopy FailとDirty Fragの解説で「Namespace Manipulation Using Unshare」など5本のルールを示しました。Microsoft Defender for Cloudにも「Potential exploitation of dirtyfrag vulnerability detected」という警告があります。実行時の不審な挙動を拾う仕組みはFalcoのランタイム脅威検知とルール運用で整理しています。

Dirty Fragの対策：つなぎの緩和と恒久パッチ

対処は「更新までのつなぎ」と「恒久パッチ」の2段階です。修正版へ更新して再起動を済ませたら、緩和策は外しても構いません。

esp4・esp6・rxrpcのブロックとIPsecへの影響

IPsecとAFSを使わないホスト向けの手順です。Canonicalの手順を基に、ブロック、取り外し、確認の3段で書いています。

# 1. 今後の読み込みを禁止する
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/dirty-frag.conf
# Ubuntu / Debian は起動初期の読み込みも止めるため initramfs を作り直す
sudo update-initramfs -u -k all

# 2. 読み込み済みなら取り外す（使用中なら失敗する）
sudo rmmod esp4 esp6 rxrpc 2>/dev/null

# 3. 外れたかを確かめる。残っていれば再起動で反映する
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "まだ読み込まれている" || echo "読み込まれていない"

esp4とesp6はIPsecのESPを担います。使用中のモジュールはrmmodが拒否するので、動いているIPsec接続がこの操作で切れることはありません。ただし次の起動からIPsecが動かなくなります。拠点間VPNやstrongSwanを動かすホストでは、再起動の時点でVPNが止まります。rxrpcはAFSの通信基盤なので、AFSを使う組織ではファイル共有が止まります。IPsecの仕組みはIPsecの仕組みとAH・ESP・IKEの役割で解説しています。研究者のREADMEが挙げるecho 3 > /proc/sys/vm/drop_caches（カーネルがcleanと扱うページキャッシュなどの破棄）は一時的にディスクI/Oを増やすので、本番機では再起動の枠で済ませるほうが安全です。

user namespaceの無効化でIPsecを止めずに防ぐ方法

IPsecを止められないホスト向けに、Red Hatは非特権user namespaceの無効化を示しています。43284と46300に効き、IPsecは動いたままです。

echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/dirty-frag.conf
sudo sysctl --system
sysctl user.max_user_namespaces   # 0 なら反映済み

副作用として、Podmanのrootlessコンテナ、Flatpak、ChromeやFirefoxのサンドボックスが動かなくなります。rxrpc側の43500はnamespaceを使わないので防げません。RHEL系は43500が非該当なのでこれだけで足りますが、Ubuntuではrxrpcのブロックを併用します。rootlessコンテナを業務で使うホストでは選べない手段なので、更新を前倒しするしかありません。

恒久パッチの適用とライブパッチを選ぶ条件

# Ubuntu / Debian
sudo apt update && sudo apt upgrade && sudo reboot
# RHEL / Rocky / AlmaLinux
sudo dnf update kernel && sudo reboot

再起動後、前の章の確認コマンドで稼働中の版が修正版以上になったことを確かめて完了です。止められないホストには、Ubuntu ProのLivepatch、RHELのkpatch-patch、SUSEのLive Patchingがあります。ただし対応する系列が限られ、次の計画停止で正規の更新へ置き換える前提です。

4月末のCopy Failから6月のDirtyCloneまで、同じ系統の公表が2か月で4回続きました。CVEごとに追うより、カーネル更新を月次で回す運用に切り替えるほうが手戻りが少なくなります。ESPやrxrpcを使わないサーバーは、修正後もブロックを残す判断が合理的です。公開サーバーが多く、どこにPHPやIPsecが残っているか把握しきれない場合は、一創の脆弱性診断・セキュリティ診断で外部からの洗い出しと修正の優先順位付けを相談できます。

コンテナ・Kubernetes環境でDirty Fragが危険な理由

コンテナはホストのカーネルを共有するため、コンテナ内の非特権ユーザーがDirty Fragを使うとホストのページキャッシュを書き換えられます。Canonicalはコンテナ脱出につながりうると説明しており、CI/CDの共用ランナーでは1つのジョブの侵害が同じノードの他のジョブやシークレットに及びます。ホストのカーネル更新を済ませたうえで、ESP側の前提であるuser namespaceの作成をコンテナに許さない設定が被害を狭めます。PodにはseccompProfile.type: RuntimeDefaultを設定し、採用ランタイムのプロファイルが対象のnamespace作成を制限することを確認したうえで、各コンテナのsecurityContext.capabilities.dropに["ALL"]を設定し、必要な権限だけをaddで戻してください。イメージ側の権限の絞り方はDockerfileの書き方とベストプラクティスで扱っています。

よくある質問

Copy Fail 2とは何ですか？Copy Failと同じ脆弱性ですか？

Dirty Fragの通称です。Copy Fail（CVE-2026-31431）とは別の欠陥で、発見者も別人です。名前は、公開済みの修正コミットから別の研究者が作ったPoCのリポジトリ名「Copy Fail 2: Electric Boogaloo」に由来します。Copy Failの緩和策（algif_aeadのブロック）ではDirty Fragを防げません。

Dirty FragのCVE番号はいくつありますか？

本体は2件で、CVE-2026-43284（esp4・esp6）とCVE-2026-43500（rxrpc）です。Red HatのRHSB-2026-003は、後続のFragnesia（CVE-2026-46300）を加えた3件をまとめて扱っています。6月に名前の付いたDirtyClone（CVE-2026-43503）も同じ部品の欠陥で、多くのディストリは46300と同じ版で直しています。

Dirty FragのPoCは公開されていますか？

研究者のGitHubで公開されています。研究者はレース条件に頼らず成功率が高いと説明しています。Microsoftは5月に、Dirty FragまたはCopy Failを使った可能性のある限定的な攻撃活動を観測しました。検証で動かす場合も、本番と同じネットワークに置かないでください。

RHEL 7やCentOS 7は影響を受けますか？

Red HatはRHEL 6・7を3件とも非該当としています。RHEL 8・9・10は43284と46300が対象で、43500はrxrpcを出荷していないため非該当です。AlmaLinuxは独自の修正版を先に出しているので、版番号の大小ではなくアドバイザリの版で判定してください。

Androidスマホは対策が必要ですか？

43284はAndroidセキュリティ情報2026年11月版で修正されました。設定で「セキュリティ パッチ レベル」が2026年11月5日以降になっていれば修正済みです。更新が届かない端末では、出所の不明なアプリを入れないことが防御になります。

関連記事

• CVE-2026-31431（Copy Fail）とは｜ディストリ別の修正版・GKEとEKSの対応と緩和策
• PHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版、悪用の実態と更新できない場合の設定【2026年10月】
• パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順
• Webシェルとは？仕組み・代表例と検知・除去の手順をTomcat・PHP・IISのコマンド例で解説
• IPsecとは？仕組み・AH/ESP/IKEとVPNでの使い方、SSL/TLSとの違いと選び方を解説