firewalld SELinux LinuC102 第9回

LinuC レベル1 102試験対策シリーズの第9回です。前回は MTA を扱い、最後に「オープンリレーを避ける ＝ 不要なものを外部に公開しない」という話をしました。今回はその考え方を正面から扱います。ファイアウォール（AlmaLinux の firewalld、Ubuntu の ufw）でホストへの通信を絞り込み、SELinux でプロセスの動きそのものを制限する ── サーバを守る2つの仕組みを実機で読み解きます。

今ここマップ

LinuC 102 試験対策シリーズ（全12回）

  第1回 シェル環境のカスタマイズ
  第2回 Bashスクリプト入門
  第3回 ネットワーク基礎
  第4回 ネットワークトラブルシューティングとDNS
  第5回 ユーザ・グループ管理と sudo 設定
  第6回 ジョブスケジューリングと時刻管理
  第7回 ログ管理実践
  第8回 メール配送エージェント(MTA)の基本
▶ 第9回 ファイアウォールと SELinux 入門    ← いまここ
  第10回 暗号化によるデータ保護
  第11回 クラウドセキュリティの基礎
  第12回 オープンソースの文化

この記事で身につくこと

1. ファイアウォールの「最小公開」の考え方を説明できる
2. firewall-cmd で zone / service / port を確認・追加できる
3. runtime と permanent の違いを理解し、--permanent + --reload を使い分けられる
4. Ubuntu の ufw で firewalld と同等の設定ができる
5. SELinux の3モードを理解し、getenforce / ausearch で状態と拒否を確認できる

第1章：なぜホストにファイアウォールが必要なのか

1.1 攻撃面を最小にする

サーバが外部に開けているポートは、そのまま 攻撃者の入口候補 になります。攻撃者は常にインターネット全体をスキャンし、開いているポート・動いているサービス・既知の脆弱性を探しています。この「攻撃される可能性のある面積」を 攻撃面（アタックサーフェス） と呼びます。

ファイアウォールの役割は明快です。「必要なポートだけ開け、それ以外は全部閉じる」。これを 最小公開の原則 と呼びます。誰のためかというと：

• セキュリティ担当のため：攻撃面が狭いほど、守るべき対象も、監視すべき対象も少なくて済む
• 運用担当のため：「このサーバは22番と443番しか開いていない」と言い切れる状態は、障害調査でも構成管理でも楽
• 開発担当のため：デバッグ用に一時的に開けたポートを閉じ忘れる、という事故を仕組みで防ぐ

1.2 二重の防御 ── 境界とホスト

ファイアウォールは1箇所だけではありません。現代の構成では2層になっています。

• ネットワークファイアウォール（境界）：データセンターやクラウドの入口。クラウドなら「セキュリティグループ」がこれにあたる
• ホストファイアウォール（各サーバ）：サーバ1台ごとに設定する。今回扱う firewalld / ufw がこれ

境界が突破されても各ホストで止める ── この「多層防御（Defense in Depth）」の発想が、ホストファイアウォールを設定する理由です。さらに今回はもう一段深く、SELinux で「プロセスが乗っ取られても、そのプロセスにできることを制限する」層も学びます。

第2章：firewalld の概念

2.1 firewalld は nftables のフロントエンド

Linux カーネルには Netfilter というパケット処理の仕組みがあり、その操作には伝統的に iptables、現在は nftables が使われます。ただし、これらは生で扱うと記述が複雑です。そこで firewalld は nftables を抽象化し、人間が扱いやすい単位（zone / service）で管理できるようにした管理ツールです。

2.2 zone ── 信頼度ごとのルール束

firewalld の最大の特徴が zone（ゾーン）です。zone は「ネットワークの信頼度ごとに用意されたルールの束」で、ネットワークインターフェースを zone に割り当てて使います。

AlmaLinux の既定ゾーンは public です。

2.3 service と port

zone の中で「何を許可するか」を指定する方法が2つあります。

• service（サービス）：ポート番号に名前を付けた定義。ssh＝22/tcp、http＝80/tcp、https＝443/tcp。ポート番号を覚えなくてよい
• port（ポート）：ポート番号を直接指定。8080/tcp のような独自ポート用

2.4 runtime と permanent

firewalld の設定には 2つの層 があり、これが試験でも実務でも最重要ポイントです。

--permanent を付けない変更は runtime のみ ── 再起動すると消えます。--permanent を付けた変更は設定ファイルに書かれますが、すぐには runtime に反映されません。--reload を実行して初めて runtime に取り込まれます。「--permanent で書いて --reload で反映」がワンセットです。

第3章：firewall-cmd の実践（linuc-alma）

3.1 状態とゾーンを確認する

実行コマンド（linuc-alma）：

$ sudo firewall-cmd --state
$ sudo firewall-cmd --get-default-zone
$ sudo firewall-cmd --get-active-zones

実行結果：

running
public
public
  interfaces: eth0 eth1

firewalld は稼働中（running）、既定ゾーンは public、2枚の NIC（eth0 / eth1）が public に所属しています。

3.2 ゾーンの中身を見る

実行コマンド（linuc-alma）：

$ sudo firewall-cmd --list-all

実行結果：

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0 eth1
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

注目は services: cockpit dhcpv6-client ssh の行です。既定で開いているのはこの3つだけ。ssh（リモート管理）、cockpit（Web 管理コンソール）、dhcpv6-client（IPv6 アドレス取得）。最小公開が初期状態で実現されています。

3.3 サービスを追加する

Web サーバを公開するために http サービスを許可します。--permanent で設定し、--reload で反映します。

実行コマンド（linuc-alma）：

$ sudo firewall-cmd --permanent --add-service=http
$ sudo firewall-cmd --reload
$ sudo firewall-cmd --list-services

実行結果：

success
success
cockpit dhcpv6-client http ssh

http が許可リストに加わりました。利用可能なサービス名は sudo firewall-cmd --get-services で一覧でき、100以上の定義があります。

3.4 独自ポートを追加する

サービス定義に無い独自ポート（例：8080）は --add-port で直接指定します。

実行コマンド（linuc-alma）：

$ sudo firewall-cmd --permanent --add-port=8080/tcp
$ sudo firewall-cmd --reload
$ sudo firewall-cmd --list-ports

実行結果：

success
success
8080/tcp

3.5 削除する

追加したルールは --remove-service / --remove-port で消します。検証で開けたものは必ず後始末します。

実行コマンド（linuc-alma）：

$ sudo firewall-cmd --permanent --remove-service=http
$ sudo firewall-cmd --permanent --remove-port=8080/tcp
$ sudo firewall-cmd --reload
$ sudo firewall-cmd --list-services

実行結果：

success
success
success
cockpit dhcpv6-client ssh

元の3サービスに戻りました。

第4章：Ubuntu の ufw（linuc-ubuntu）

4.1 ufw とは

Ubuntu の標準ファイアウォール管理ツールは ufw（Uncomplicated Firewall ＝「複雑でないファイアウォール」）です。firewalld と同じく Netfilter のフロントエンドですが、zone のような概念は持たず、ルールを単純に並べる 設計です。その分、覚えることが少なくて済みます。

Ubuntu Server の最小構成には ufw が入っていないことがあります。導入します。

実行コマンド（linuc-ubuntu）：

$ sudo apt-get update
$ sudo apt-get install -y ufw

4.2 有効化 ── SSH を許可してから

ufw の既定ポリシーは 「受信は拒否（deny incoming）」です。つまり ufw enable した瞬間、許可していない通信は全部遮断されます。SSH 経由で作業しているなら、有効化の前に必ず SSH を許可します。これを忘れると自分自身が締め出されます。

実行コマンド（linuc-ubuntu）：

$ sudo ufw allow OpenSSH
$ sudo ufw enable
$ sudo ufw status verbose

実行結果：

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)

Default: deny (incoming), allow (outgoing) ── 受信は拒否、送信は許可が既定です。ufw allow OpenSSH の OpenSSH は アプリケーションプロファイル（ufw app list で一覧）で、22/tcp に対応します。ufw allow 22/tcp と書いても同じです。

4.3 ポートの追加・確認・削除

実行コマンド（linuc-ubuntu）：

$ sudo ufw allow 8080/tcp
$ sudo ufw status numbered
$ sudo ufw delete allow 8080/tcp

ufw status numbered の実行結果（例）：

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] 8080/tcp                   ALLOW IN    Anywhere
[ 3] OpenSSH (v6)               ALLOW IN    Anywhere (v6)
[ 4] 8080/tcp (v6)              ALLOW IN    Anywhere (v6)

番号付き表示にすると、sudo ufw delete 2 のように番号で削除することもできます。firewalld と違い、ufw は ルールが即座に永続化 されます（--permanent 相当の操作は不要）。

4.4 firewalld と ufw の対比

表記や単位は違いますが、やっていることは同じ ── Linux カーネルの Netfilter にパケットフィルタリングのルールを設定しています。どちらのディストロを触っても「最小公開」という考え方は共通です。

第5章：SELinux 入門 ── 強制アクセス制御

5.1 通常のパーミッション（DAC）の限界

第8回（101シリーズ）で学んだ rwx のパーミッションは DAC（任意アクセス制御）と呼ばれます。「ファイルの所有者が、自分の裁量でアクセス権を決められる」方式です。これには2つの弱点があります。

• root は無制限：root になれば DAC は事実上すべて無視できる
• プロセス乗っ取りに弱い：Web サーバが脆弱性で乗っ取られると、攻撃者は「Web サーバ権限でできること全部」を実行できてしまう

そこで登場するのが SELinux（Security-Enhanced Linux）です。SELinux は MAC（強制アクセス制御）で、「ポリシー」というシステム全体のルールが、各プロセスの動きを強制的に制限します。たとえ root のプロセスでも、ポリシーで許されていない動きはできません。「Web サーバプロセスは Web コンテンツ以外のファイルを読めない」といった制限を、所有者の裁量とは無関係に強制します。

5.2 3つのモード

現在のモードを確認します。

実行コマンド（linuc-alma）：

$ getenforce
$ sestatus

実行結果：

Enforcing
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33

getenforce はモードだけを1語で返します。sestatus は詳細を表示します。ポリシーは targeted（主要なサービスだけを制限し、それ以外は緩い、という実用的なポリシー）です。

5.3 モードの切り替えと永続設定

モードの一時切り替えは setenforce です。

setenforce で切り替えられるのは Enforcing ⇔ Permissive だけです。Disabled へは setenforce では行けません。Disabled にするには /etc/selinux/config を編集して再起動する必要があります（そして、それは推奨されません ── 第9章参照）。

永続設定は /etc/selinux/config です。

実行コマンド（linuc-alma）：

$ cat /etc/selinux/config | grep -v '^#'

実行結果：

SELINUX=enforcing
SELINUXTYPE=targeted

第6章：SELinux のコンテキスト

6.1 すべてにラベルが付く

SELinux は、すべてのファイル・プロセス・ポートに コンテキスト（ラベル）を付けて管理します。ポリシーは「このコンテキストのプロセスは、このコンテキストのファイルにアクセスしてよい」という形で書かれています。

ファイルのコンテキストは ls -Z で見えます。

実行コマンド（linuc-alma）：

$ ls -Z /etc/passwd /etc/shadow /etc/hosts

実行結果：

system_u:object_r:passwd_file_t:s0 /etc/passwd
     system_u:object_r:shadow_t:s0 /etc/shadow
   system_u:object_r:net_conf_t:s0 /etc/hosts

コンテキストは user:role:type:level の 4要素です。

実務でほぼ常に意識するのは type です。/etc/passwd は passwd_file_t、/etc/shadow は shadow_t ── ファイルの役割ごとに別の type が付き、ポリシーが「どの type のプロセスがどの type のファイルを触れるか」を決めます。

6.2 プロセスと自分のコンテキスト

プロセスは ps -eZ、自分自身は id -Z で確認します。

実行コマンド（linuc-alma）：

$ ps -eZ | head -3
$ id -Z

実行結果（例）：

LABEL                               PID TTY          TIME CMD
system_u:system_r:init_t:s0           1 ?        00:00:02 systemd
system_u:system_r:kernel_t:s0         2 ?        00:00:00 kthreadd
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

systemd は init_t、カーネルスレッドは kernel_t。ログインしている developer ユーザは unconfined_t ── これは「SELinux の細かい制限を受けない」type です。targeted ポリシーでは、一般ユーザの対話操作は制限せず、サービス（httpd、sshd 等）を重点的に閉じ込める 設計になっています。

6.3 コンテキストのズレを直す

SELinux のトラブルで最も多いのが コンテキストのズレ です。たとえば /home 配下で作ったファイルを /var/www/html に mv で移動すると、コンテキストが移動元のまま（user_home_t 等）になり、Web サーバ（httpd_t）が読めずに 403 エラーになります。

定石は「semanage fcontext でルールを足してから restorecon で適用」です。chcon は一時しのぎで、restorecon を実行すると上書きされます。

第7章：SELinux 拒否の調査

7.1 AVC denial ── 拒否はログに残る

SELinux が何かを拒否すると、/var/log/audit/audit.log に AVC（Access Vector Cache）denial として記録されます。これを読みやすく検索するのが ausearch です。

実行コマンド（linuc-alma）：

$ sudo ausearch -m avc -ts today

実行結果（拒否が無いクリーンな状態）：

<no matches>

-m avc は AVC メッセージに絞る指定、-ts today は今日以降の指定です。拒否が発生していれば、ここに「どのプロセスが」「どのファイルに」「何をしようとして拒否されたか」が出ます。さらに setroubleshoot パッケージを入れると sealert コマンドで人間向けの解説（推奨される修正コマンド付き）が得られます。

7.2 boolean ── ポリシーのスイッチ

SELinux ポリシーには boolean という ON/OFF スイッチが多数用意されています。ポリシーを書き換えずに、よくある挙動を切り替えられます。

$ getsebool -a              （boolean 一覧）
$ sudo setsebool -P httpd_can_network_connect on   （-P で永続）

たとえば「Web サーバから外部 DB に接続したい」なら、ポリシーを自作するのではなく httpd_can_network_connect boolean を on にするのが正解です。

第8章：現場での使いどころ

現場での使いどころ

• 新サービス公開時のポート開放：Web サーバを立てたら firewall-cmd --permanent --add-service=https --reload。開けた後に外部から実際に届くか確認する
• クラウドでの二重化：AWS のセキュリティグループ（境界）で絞り、さらに各 EC2 の firewalld / ufw（ホスト）でも絞る。片方の設定ミスをもう片方が補う
• SELinux 拒否でサービスが起動しない：「設定は正しいのに動かない」ときは ausearch -m avc -ts recent を真っ先に見る。コンテキストのズレなら restorecon、機能不足なら boolean を確認
• DocumentRoot を変えたとき：Web サーバのコンテンツ置き場を既定（/var/www/html）から変更したら、semanage fcontext で新パスにルールを足して restorecon。これを忘れると 403 になる
• 「とりあえず disable」をしない文化：SELinux やファイアウォールを切れば確かに「動く」。だが攻撃面を自ら広げているだけ。チームとして「切らずに直す」を共有する
• 検証で開けたポートの後始末：デバッグで一時的に開けたポートは、検証が終わったら必ず --remove-port / ufw delete で閉じる。開けっ放しが事故のもと

第9章：ヒヤリハット

# まず原因を確認
$ sudo ausearch -m avc -ts recent
# コンテキストのルールを追加して適用
$ sudo semanage fcontext -a -t httpd_sys_content_t '/opt/myapp(/.*)?'
$ sudo restorecon -Rv /opt/myapp

第10章：やってみよう

linuc-alma と linuc-ubuntu で次の4つの演習を実行してください。所要時間は25〜35分です。SSH(22)を塞がないよう注意し、開けたものは後始末します。

演習1：firewalld の状態を確認する（linuc-alma）

実行コマンド（linuc-alma）：

$ sudo firewall-cmd --state
$ sudo firewall-cmd --get-default-zone
$ sudo firewall-cmd --get-active-zones
$ sudo firewall-cmd --list-all

確認ポイント：既定ゾーンが public、許可サービスが cockpit dhcpv6-client ssh の3つ。

演習2：サービスを追加して後始末する（linuc-alma）

実行コマンド（linuc-alma）：

$ sudo firewall-cmd --permanent --add-service=http
$ sudo firewall-cmd --reload
$ sudo firewall-cmd --list-services
$ sudo firewall-cmd --permanent --remove-service=http
$ sudo firewall-cmd --reload
$ sudo firewall-cmd --list-services

確認ポイント：追加後に http が現れ、削除後に元の3サービスに戻る。--reload を忘れると --list-services に反映されない（runtime と permanent の違いを確認できる）。

演習3：SELinux の状態とコンテキスト（linuc-alma）

実行コマンド（linuc-alma）：

$ getenforce
$ sestatus
$ ls -Z /etc/passwd /etc/shadow
$ ps -eZ | head -5
$ id -Z
$ sudo ausearch -m avc -ts today

確認ポイント：getenforce が Enforcing、ファイルとプロセスにコンテキスト（type）が付いている、自分は unconfined_t、AVC 拒否は <no matches>。setenforce は実行しないこと（Enforcing 維持）。

演習4：ufw を確認する（linuc-ubuntu）

linuc-ubuntu に SSH でログインして実行します。

実行コマンド（linuc-ubuntu）：

$ sudo apt-get install -y ufw
$ sudo ufw app list
$ sudo ufw status verbose

確認ポイント：ufw が導入でき、ufw app list に OpenSSH がある。ufw status は導入直後は inactive。この演習では ufw enable しないこと ── 有効化すると SSH 接続に影響しうるため、本記事の検証範囲では状態確認に留めます。実際に有効化する場合は、必ず先に sudo ufw allow OpenSSH を実行してください。

困ったらマニュアルを引きます。man firewall-cmd man firewalld.zone man ufw man selinux man ausearch man semanage-fcontext。firewall-cmd --help も役立ちます。

理解度チェック

次の5問を ○×で答えてください。解答は記事末尾にあります。

1. firewalld で --permanent を付けずに --add-service したルールは、再起動後も残る。
2. firewalld の --permanent 付きの変更は、--reload を実行しないと現在動作中のルール（runtime）には反映されない。
3. Ubuntu の ufw は、ufw enable した時点で既定では受信を拒否するため、有効化前に SSH を許可しておく必要がある。
4. SELinux の Permissive モードは、ポリシー違反を拒否しないがログには記録する。
5. SELinux で Web ファイルが読めず 403 になったときの正しい対応は、setenforce 0 で SELinux を無効化することである。

解答

1. ×（--permanent 無しは runtime のみ＝再起動で消える）
2. ○（permanent は設定ファイルに書かれるが、--reload で runtime に取り込まれる）
3. ○（ufw の既定は deny incoming。有効化前に ufw allow OpenSSH 必須）
4. ○（Permissive は拒否せず記録のみ。原因調査・移行に使う）
5. ×（無効化は問題を隠すだけ。正しくは ausearch で原因確認 → restorecon や semanage fcontext でコンテキスト修正）

次回予告

次回（第10回）は 「暗号化によるデータ保護 — SSH鍵認証・GnuPG・OpenSSL」 です。共通鍵暗号と公開鍵暗号の違い、ssh-keygen での鍵生成と ssh-copy-id による配布、gpg での暗号化・署名、openssl での証明書操作を扱います。今回の「アクセスを制限する」に続き、「データそのものを守る」層を学びます。

LinuC 102 試験対策シリーズ（全12回）

1. シェル環境のカスタマイズ：環境変数・エイリアス・履歴・ロケール
2. Bashスクリプト入門：if/for/関数で書く現場の自動化スクリプト
3. ネットワーク基礎：TCP/IP・ip コマンド・NetworkManager
4. ネットワークトラブルシューティングとDNSクライアント設定
5. ユーザ・グループ管理と sudo 設定の実務（useradd, visudo）
6. ジョブスケジューリングと時刻管理：cron, systemd timer, chrony, NTP
7. ログ管理実践：journalctl と rsyslog の使い分け
8. メール配送エージェント(MTA)の基本：postfix の動作確認
9. ファイアウォール（firewalld / ufw）と SELinux 入門
10. 暗号化によるデータ保護：SSH鍵認証・GnuPG・OpenSSL
11. クラウドセキュリティの基礎：IAM・公開鍵管理・SSH踏み台構成
12. オープンソースの文化：主要ライセンス（GPL/MIT/Apache）とコミュニティ