クイズ 6. ファイアウォールとホストセキュリティ
サポート対象バージョン: Ubuntu Server 24.04 LTS（主環境）、Rocky Linux 9（代替環境） 最終更新日: 2026 年 9 月 15 日
クライアント .10、サーバー .20、別の管理用 NIC、コンソール経由の復旧方針を使います。解説を表示する前に答えを選んでください。
クライアントからこのサーバーへ SSH 接続します。サーバーのファイアウォールから見ると、これは受信、送信、転送のどのトラフィックですか？
- A) 転送。リモート接続があればサーバーはすべてルーターになるため。
- B) 送信。サーバーが応答を送信するため。
- C) 新しい接続に対しては受信。応答はその接続に属する。ほかのホストのトラフィックをルーティングするなら転送となる。
- D) どれでもない。SSH はファイアウォールを迂回するため。
解答を表示
解答: C
解説: 方向は、どのホストからどのパケット経路を観測するかによって決まります。このサーバーは宛先であり、ルーターではありません。ステートフルな応答処理があるため、新しい接続は拒否されても、既存の SSH 接続が維持されることがあります。このラボでは NAT や転送の変更は必要ありません。
UFW にはすでに広範囲の SSH 許可ルールがあります。
.10からの許可を追加すれば、アクセスは.10だけに制限されますか？- A) いいえ。既存の広い許可ルールは残る。順序と先行するカスタムルールを調べ、レッスンに従って対象を限定した許可を追加した後、同じエンドポイントに対する拒否を追加する。
- B) はい。新しいルールは古いルールを自動的にすべて消す。
- C) はい。コメントに「secure」と書けばよい。
- D) firewalld も有効にした場合に限る。
解答を表示
解答: A
解説: 範囲の狭い許可ルールは追加されるものであり、既存ルールを取り消すものではありません。このレッスンでは、同じラボ NIC／宛先／ポートを対象に、TCP 22 と 8000 のクライアント許可ルールを拒否ルールより前に追加します。これにより、SSH の許可を維持したまま HTTP の許可だけを取り消せます。カスタムの before.rules が結果に影響する場合もあるため、実際の管理元と処理順を確認してください。管理サービスを 2 つ競合させても、セキュリティは高まらず、判断が難しくなります。
レッスンで行う UFW ルールの変更とクリーンアップについて、正しい説明はどれですか？
- A) 実行時だけの変更なので、10 分後に失効する。
- B) 以前に覚えたルール番号で削除すれば、常に正確に削除できる。
- C) レッスン開始前に有効だった場合でも、クリーンアップでは UFW を無効にする必要がある。
- D) ルールは保存されて適用される。正常に追加できたルールを正確な指定で削除し、レッスンで元々無効だった UFW を有効化した場合に限り、元の無効状態へ戻す。
解答を表示
解答: D
解説: この UFW の手順には、firewalld のようなルール単位の永続／実行時の区別はありません。ルールの位置は変わることがありますが、インターフェイス、送信元、宛先、プロトコル、ポートが意図するルールを定義します。HTTP だけを試す場合は、独立した TCP 8000 の許可だけを削除します。復元するときは、残っているラボ用拒否ルールより前に挿入してください。この実験では TCP 22 の許可を削除しないでください。最初に有効化する際は、管理アクセスも確認してください。NIC 設定が変わらなくても、すべての受信サービスが維持されるとは限りません。
Rocky のラボインターフェイスを新しい空の firewalld zone に入れるのはなぜですか？
- A) zone があれば MAC アドレスは不要になる。
- B) 既定または既存の zone では SSH が広く許可されている可能性がある。専用のラボ用 zone を作れば、管理用 NIC を移さずに意図した許可だけを設定しやすくなる。
- C) すべての zone は ICMP と IPv6 を自動的にブロックする。
- D) source binding やポリシーを確認する必要がなくなる。
解答を表示
解答: B
解説: NetworkManager の connection.zone が空の場合、既定の zone が使われます。既存のサービス、target、source binding、ポリシー、direct rule が実際の許可内容を変えることがあります。ラボのアクティブなプロファイル UUID と、空欄も含めた元の zone の値を記録し、管理用プロファイルには触れないでください。
--timeout=600を指定して rich rule を追加しました。reload 後はどうなりますか？- A) 実行時だけのルールは失われ、保存済みのポリシーが使われる。インターフェイスと zone のバインドは別の変更である。
- B) タイムアウトが自動的に永続設定になる。
- C) NetworkManager のすべてのアドレスが消去される。
- D) 実行時の設定が常に永続設定を上書きするため、何も変わらない。
解答を表示
解答: A
解説: 試験用ルールはタイムアウト後に失効し、reload 時にも失われます。保存済みのルールにするには、明示的な永続設定と実行時への読み込みが必要です。reload は無関係な実行時の変更も破棄することがあるため、安易に使わないでください。また、--runtime-to-permanent で未知の状態をすべてコピーしないでください。ラボ用 zone によって新しい SSH 接続が許可されなくなった場合は、コンソールからの復旧も必要です。
許可されたクライアントが
.20:8000から HTTP 200 を受け取りました。裏付けられる主張はどれですか？- A) 許可されていないすべての送信元をテストし、拒否されることを確認した。
- B) ほかに広範囲の許可ルールは存在しない。
- C) このテスト中に、このクライアントからこのリスニングサービスへ接続できた。送信元制限を主張するには、ポリシーの確認と、別途実施した拒否テストが必要である。
- D) SELinux はすべてのアプリケーションがすべてのファイルを読み取れるよう許可している。
解答を表示
解答: C
解説: 許可された経路のテストが成功しても、その結果が示す範囲は限られます。サーバー自身または localhost からのリクエストは、外部クライアントが拒否されるテストではありません。リスナー、経路、インターフェイス／zone、ルールを比較し、実際に測定した内容を報告してください。範囲を限定した Python サーバーと一時ファイルは、ファイアウォールポリシーとは別に停止／削除してください。
ファイルに意図的に誤った SELinux タイプを設定しました。レッスンに沿った復旧方法はどれですか？
- A) SELinux を全体的に無効にする。
- B) すべてのユーザーに再帰的な書き込み権限を与える。
- C) すべての監査記録に対して広範な許可ポリシーを作成する。
- D) パスに期待されるコンテキストを調べ、
restorecon -nで事前確認してから、そのファイルのポリシーラベルを復元し、matchpathcon -Vで検証する。
解答を表示
解答: D
解説: Unix のモードと SELinux コンテキストは、別々に検査されます。chcon は現在のラベルを変更しますが、永続的なパスマッピングは作成しません。restorecon はポリシーのファイルコンテキストルールを使います。カスタムの永続パスには、意図的な semanage fcontext のマッピングが必要な場合がありますが、一時ファイルを使うこの演習では必要ありません。
ausearchでは一致する AVC がなく、Fail2ban の ban 数も 0 件でした。妥当な解釈はどれですか？- A) 両方のツールによって攻撃が不可能だと証明された。
- B) 検索した記録／カウンターが空だった。どの証拠が存在するかは、フィルター、期間、journal のメタデータ、権限、実際のイベントによって決まる。
- C) エラーが出るまで enforcing モードを無効にする。
- D) ブルートフォースを繰り返し、スコアを 0 より大きくする。
解答を表示
解答: B
解説: ラベルを扱うこの演習では、制限されたアクセスを意図的に発生させないため、AVC が記録されるとは限りません。Fail2ban が正常に待機している場合も、設定に誤りがある場合もあります。実際の journal の unit、backend/filter/action、起動ログを確認してください。このレッスンでは、ブルートフォースを明示的に行わず、強制適用が実際にテスト済みだとも主張しません。
Rocky Linux 9 でのオプションパッケージのセットアップとして適切なものはどれですか？
- A) 既存状態を記録し、ディストリビューションの手順に従って必要な CRB の前提条件と EPEL 9 を有効にする。候補と署名を確認して、必要なパッケージだけをインストールする。
- B) 署名検証を無効にして、任意のメジャーバージョンの EPEL を使う。
- C) DNF で依存関係を解決できなければ、Ubuntu のパッケージをインストールする。
- D) インストール後、ほかのパッケージが依存していても既存の CRB/EPEL を無効にする。
解答を表示
解答: A
解説: EPEL はオプションのソフトウェアを提供し、CRB は依存関係を提供します。対応する EL のメジャーリリース、リポジトリの識別情報、ゲストのアーキテクチャが重要です。同じ準備はレッスン 7 のオプションである iftop にも使えます。リポジトリを無効にしても、インストール済みパッケージは元に戻りません。オプションのインストールを完全に元に戻す場合は、記録したスナップショットを使ってください。
- ラボの境界を守った Fail2ban の設定とクリーンアップはどれですか？
- A)
backend=systemdと推測した/var/log/auth.logを使い、ban をすべて flush する。 - B) 既存の本番 jail をそのまま使い、確認せずに停止する。
- C) 専用の journal ベースの SSH jail とラボ限定の action を検証し、状態を調べる。表示されたコース用アドレスだけを unban し、その jail を停止して、自分が所有する 2 ファイルを削除してからファイアウォールの zone をクリーンアップする。
- D) サービスが有効であれば、filter とファイアウォール action も正しく動作しているとみなす。
解答を表示
解答: C
解説: journal backend では logpath ではなく journalmatch を使います。action はラボの許可ルールより前に適用し、ラボのインターフェイス／zone、.20、TCP 22 に限定する必要があります。解釈済みの構成をテストし、action の展開内容を調べてください。誤って ban したアドレスは元に戻し、zone を削除する前に jail を停止します。無関係なファイアウォール状態を flush しないでください。追加の証拠がなければ、設定／起動を確認したと報告し、攻撃検出が証明されたとはしないでください。