0. はじめに

元システムエンジニアです。

最近はコンサルとかアドバイザー系の業務が中心だったため、製品検証の機会が少なかったのですが、とある案件にかかわることがきっかけでLinuxの検証環境の構築が必要になりました。

今回の用途は、製品検証のために、運用系の検証（SyslogとかSNMP Trapとか）を行ったため、そのあたりのお話となります（どんな内容下記になる方は、目次をご覧ください）。

年齢が年齢のため、何かに記録しておかないと、すぐ忘れてしまうので、Qiitaにメモを残すことにします。
（何か月後かに同じような検証をするときに、再度調べなおすのが手間なので）

ちなみにこういう情報共有系って、何が良いのか迷いますよね。
（昔はExcelで作って、会社のファイルサーバに置いていたような…）

1. AlmaLinuxを構築しよう

検証環境は案件に応じて構築しますが、今回はLinux環境です。
昔はCentOSを使っていましたが、今はAlmaLinuxですかね、やっぱり。
（今回は8.10と9.6を使用します）

1-1. インストール時

基本的にポチポチするだけなので、今回は省略。
（さあ、この判断が吉と出るか凶と出るかは、未来の自分のみぞ知る）

2. AlmaLinuxを設定しよう

2-1. AlmaLinuxバージョン確認

さあ、まずはインストールされているバージョンを確認してみましょう。

$ cat /etc/almalinux-release

AlmaLinux release 8.10 (Cerulean Leopard)

AlmaLinux 9.6の場合は、こんな感じです。

$ cat /etc/almalinux-release

AlmaLinux release 9.6 (Sage Margay)

2-2. IPアドレスの確認

TeraTerm等でリモート接続するので、まずはIPアドレスを確認しましょう。

$ ip addr show | grep inet | grep -v inet6

    inet 127.0.0.1/8 scope host lo
    inet 172.27.32.121/20 brd 172.27.47.255 scope global dynamic noprefixroute eth0
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0

外部接続用は"eth0"なので、今回のIPアドレスは"172.27.32.121"ですね。
これがあれば、TeraTerm等から接続できますね。

2-3. ホスト名の変更

次にホスト名を変更しましょう。
（インストール時に変更しとけよ、と思いつつ…）

まず、ホスト名の確認です。

$ hostnamectl status

   Static hostname: localhost.localdomain
Transient hostname: linux.local
         Icon name: computer-vm
           Chassis: vm
        Machine ID: ebca3a09b35b49598fe01b5237167dd7
           Boot ID: 090293c47d57491897a8a591acbe477e
    Virtualization: microsoft
  Operating System: AlmaLinux 8.10 (Cerulean Leopard)
       CPE OS Name: cpe:/o:almalinux:almalinux:8::baseos
            Kernel: Linux 4.18.0-553.el8_10.x86_64
      Architecture: x86-64

Static hostnameが"現在のホスト名"。

では、ホスト名を変更しましょう。今回はホスト名を"alma8"に変更します。

$ sudo hostnamectl set-hostname alma8

では、ホスト名が変更されたかどうか、確認しましょう。

$ hostnamectl status

   Static hostname: alma8
         Icon name: computer-vm
           Chassis: vm
        Machine ID: ebca3a09b35b49598fe01b5237167dd7
           Boot ID: 090293c47d57491897a8a591acbe477e
    Virtualization: microsoft
  Operating System: AlmaLinux 8.10 (Cerulean Leopard)
       CPE OS Name: cpe:/o:almalinux:almalinux:8::baseos
            Kernel: Linux 4.18.0-553.el8_10.x86_64
      Architecture: x86-64

きちんとホスト名が"alma8"に変更されていることが確認できました。

ちなみに別の環境だと、こんな感じになります。

$ hostnamectl status

 Static hostname: unyo
       Icon name: computer-vm
         Chassis: vm 
      Machine ID: 2f7f65b4e3464fa48d6d84295c2428fb
         Boot ID: 96f9b5762da949b09b717847108ed0b5
  Virtualization: vmware
Operating System: AlmaLinux 9.6 (Sage Margay)
     CPE OS Name: cpe:/o:almalinux:almalinux:9::baseos
          Kernel: Linux 5.14.0-570.12.1.el9_6.x86_64
    Architecture: x86-64
 Hardware Vendor: VMware, Inc.
  Hardware Model: VMware Virtual Platform
Firmware Version: 6.00

こちらはVMware Workstation Pro上の仮想マシン、先ほどのはHyper-V上の仮想マシンです。
同じような仮想環境でも、情報量が異なるのは面白いですね。

さて、ついでに/etc/hostsも確認します。

$ cat /etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

はい、旧ホスト名が残ってますね…
修正しましょう（どんな手を使ってもいいですが、私はviで）。

$ sudo vi /etc/hosts

いい感じで編集します。

さて、きちんと変更されたか確認しましょう。

$ cat /etc/hosts

127.0.0.1  localhost    alma8
#::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

いったんIPv6は使用しないので、コメントアウトで。

2-4. SELinux

さて、次にSELinuxの設定確認です。
古のシステムエンジニアは、必ずと言っていいほどSELinuxに苦しめられています（苦しめられたことがない人は、とても幸せなSE生活を送ってますね）。

セキュリティ的には優秀なやつなんですが、検証のときは、ね…

有効無効を確認せずに検証すると、残業時間が増えますので、確認方法を覚えておきましょう。

SELinux設定の確認

$ sestatus

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

"enabled"になっていますね、アブナイアブナイ…

とりあえず無効にしましょう。

sudo vi /etc/selinux/config

SELINUX=enforcing　になっている行を
SELINUX=disabled　に変更します。

保存して、再起動

$ sudo reboot

OS起動後にSELinux設定を確認します。

$ sestatus

SELinux status:                 disabled

無効化されました、これで一安心。

なお、ログは残すけど実際にはブロックしない"Permissive"という設定にすることもできます。
その場合、SELINUX=permissive　に設定します。
アプリ等の動作確認をしたい場合は、この設定が便利ですね。

2-5. Secure Boot

さて、LinuxにはSecure Boot設定というものもあります。
（まあ実は、Windowsにもあったりします）

こやつはこやつで、いろいろしでかしますので、設定確認は必須です。
（いや、セキュリティ的にはいいやつなんですよ、でも検証環境だと…）

Secure Boot設定の確認

$ mokutil --sb-state

SecureBoot enabled

Ohhh...有効化されてますね…

この設定、残念ながらコマンドでOFFにできる類のものではないので、OFFにしたい場合はご注意ください。
ハードウェア設定や、各仮想環境の設定をご確認ください。
また、一部環境（某仮想環境やクラウド）では、そもそもSecure Bootを使えない場合もあります。

ちなみに今回Qiita用の環境構築には、わざわざHyper-Vを使用しております。マッチポンプですね。
（VMware Workstation ProはSecure Boot未対応のため、環境を作れませんでした）

なお、Secure Bootがサポートされていない環境（VMware Workstation Proなど）でmokutilを実行すると…

# mokutil --sb-state

bash: mokutil: コマンドが見つかりませんでした...
コマンド mokutil' を提供するためにパッケージ 'mokutil' をインストールしますか? [N/y]

そもそもコマンドがインストールされていないようです。
試しに、インストールしてみると…

コマンド mokutil' を提供するためにパッケージ 'mokutil' をインストールしますか? [N/y]y

 * キューで待機中...
 * パッケージの一覧をロード中。...
以下のパッケージはインストールされるべきものです:
 efivar-libs-38-3.el9.x86_64    Library to manage UEFI variables
 mokutil-2:0.6.0-4.el9.x86_64   Tool to manage UEFI Secure Boot MoK Keys
変更したまま継続しますか？ [N/y] y

 * キューで待機中...
 * 認証を待ち受け中...
 * キューで待機中...
 * パッケージの一覧をロード中。...
 * パッケージをダウンロード中...
 * データを要求中...
 * 変更をテスト中...
 * パッケージのインストール中...
EFI variables are not supported on this system

という感じで、インストールできませんでした…

ある環境ではできることが、別の環境ではできないってやつですね。
（こういうささやかな情報が、詳細設計や要件ヒアリングにじみーに効いてきます…が、それはまた別のお話）

2-6. ファイアウォール

さて、お次はファイアウォールです。
AlmaLinuxではfirewalldを利用しています。

ステータス確認

$ systemctl status firewalld

● firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; preset>
     Active: active (running) since Wed 2025-10-08 16:17:28 JST; 42s ago
       Docs: man:firewalld(1)
   Main PID: 851 (firewalld)
      Tasks: 2 (limit: 22768)
     Memory: 40.6M
        CPU: 457ms
     CGroup: /system.slice/firewalld.service
             mq851 /usr/bin/python3 -s /usr/sbin/firewalld --nofork --nopid

10月 18 08:17:28 unyo systemd[1]: Starting firewalld - dynamic firewall daemon.>
10月 18 08:17:28 unyo systemd[1]: Started firewalld - dynamic firewall daemon.

Active欄を確認すると、"active(running)"となっているため、稼働していることがわかります。

なお、起動/停止は次の通りです。

起動

$ sudo systemctl start firewalld

停止

$ sudo systemctl stop firewalld

バージョン確認

続いて、バージョンを確認してみましょう。

$ sudo firewall-cmd --version

1.3.4

バージョン番号だけ表示してくれます、シンプルですね。

なお、パッケージ情報からバージョンを確認することもできます。

$ rpm -qa | grep firewalld

firewalld-filesystem-1.3.4-9.el9_5.noarch
firewalld-1.3.4-9.el9_5.noarch

ネットワークインターフェースと、ゾーンと、サービスの関係の話

さて、firewalldを設定する際に必要な知識として、ネットワークインターフェース/ゾーン/サービスがあります。

ネットワークインターフェースは、説明不要ですね？
サーバ等が、他のサーバ等と通信するための出入り口となるものです。
（逆に、こういう用語を簡単に説明するのが難しかったりしますね…精進せねば…）

ネットワークの基礎的なことは「3分間NetWorking」を見てください。

本もあります（私も持ってます）。
※改めて発行日付を見たら、結構昔の本ですね…最近はもっと良い本があるのかしら？

さて、お次はゾーンです。
ゾーンは、ファイアウォールで制御したい内容を取りまとめたものです。
公式ドキュメントでは「trust level（信頼レベル）」と表現しています。
そのため、信頼度に応じて、複数ゾーンを定義することになります（例えば「機密ゾーン」「社内ゾーン」「公共ゾーン」など）。

最後に、サービスです。
サービスは、ファイアウォールによる具体的なアクセス制御の定義です。
例えば、httpsによる通信を許可するとか、ftpによる通信を拒否するとか、です。

ネットワークインターフェース/ゾーン/サービスの関係は、次の通りです。

インターフェースは、1つのゾーンにのみ所属できます（複数ゾーンには所属できません）。

ゾーンは、1つのインターフェースを持つこともできますし、複数インターフェースを持つこともできます。
ゾーンは、1つのサービスを持つこともできますし、複数サービスを持つこともできます。

サービスは、1つのゾーンに紐づけることもできますし、複数ゾーンに紐づけることもできます。

では、firewalldの設定を確認してみましょう。

（アクティブ）ゾーンの確認

$ firewall-cmd --get-active-zones

public
  interfaces: ens160

この環境では、「public」ゾーンのみアクティブです。
紐づいているネットワークインターフェースは「ens160」ですね。

「アクティブ」とは、有効になっているという意味です。

逆に、無効になっているゾーンも存在します。
調べ方は次の通りです。

すべての（アクティブ/インアクティブ含む）ゾーンの確認

$ sudo firewall-cmd --list-all-zones

block
  target: %%REJECT%%
  icmp-block-inversion: no
  interfaces:
  sources:
  services:
  ports:
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

dmz
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: ssh
  ports:
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

  （略）

いっぱい表示されるので、ここでは省略します（ご自身の環境がある場合は、確認してみてください）。
※コマンドが微妙に違うんですよね、getとlist…

特定ゾーンの詳細設定確認

それでは、特定ゾーンの詳細を確認していましょう。
今回は「public」ゾーンの詳細を確認します。

$ sudo firewall-cmd --zone=public --list-all

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

色々ありますが、上から順にみていきましょう。

まず「target」です。これはルールに該当しないものをどう扱うかを決めるものです。
「default」の場合、「明示的に許可したもの以外は拒否する」となります。
firewallとしては一般的な考え方ですね。

「icmp-block-inversion」は、ICMP通信をどう扱うか決めるものです。
「icmp-blocks」とセットで使用するので、後ほどまとめて説明します。

「sources」は、特定のIPアドレス/ネットワーク範囲からの通信をどう扱うか決めるものです。
明示的に許可したいものを追加します。

「services」は、サービスによる通信をどう扱うか決めるものです。
具体的なサービスは/usr/lib/firewalld/servives/以下にXML形式で定義されています。
今回は「cockpit dhcpv6-client ssh」となっているので、3つのサービスによる通信が許可されています。
※実際によく使うのは、sshですね。

具体的に定義内容を見てみましょう。

$ cat /usr/lib/firewalld/services/ssh.xml

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>SSH</short>
  <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description>
  <port protocol="tcp" port="22"/>
</service>

SSHというサービスが、プロトコル=TCP、ポート=22で定義されていますね。
※気になる方は他のサービスがどういう定義なのか、調べてみてくださいね。

「ports」は、特定ポートによる通信をどう扱うか決めるものです。
主にサービスとして定義されていないポートが対象となります。

「protocols」は、特定プロトコルによる通信をどう扱うか決めるものです。
特定プロトコルだけまるっと許可したい、という用途にぴったりです。

「forward」は、パケット転送をどう扱うか決めるものです。
「yes」の場合、「転送を許可する」となります。
※この環境では「no」でよい気がしますね（パケット転送しないので）。

「masquerade」は、マスカレードをどう扱うか決めるものです。
パケット転送に似ている機能ですが、IPアドレスを書き換える点が異なります。
「no」の場合、「マスカレードを許可しない」となります。

マスカレードは、内部のIPアドレスを持っている通信を外部に転送する場合、必要になります。
これは、内部IPアドレスのまま外部に送ってしまうと、戻りの通信先が無くなってしまう（外部から内部IPアドレスには通信できない）ためです。
※内部IPアドレスは、192.168.0.xみたいなプライベートIPアドレスのことです。

「forward-ports」は、特定ポートの通信を別のポート番号に変更するか決めるものです。
「forward」「masquerade」を使っている場合は、設定が必要ですね。

「source-ports」は、送信元の特定ポートによる通信をどう扱うか決めるものです。
※送信先ポートの場合は「ports」で設定します。

「icmp-blocks」は、特定のICMP通信をどう扱うか決めるものです。
ややこしいのは、前述の「icmp-block-inversion」次第で動きが変わります。
例えば、「icmp-block-inversion: no」の場合、「icmp-blocks」で指定したICMP通信を拒否します（指定したもの以外は許可）。
逆に、「icmp-block-inversion: yes」の場合、「icmp-blocks」で指定したICMP通信を許可します（指定したもの以外は拒否）。

「rich rules」は、特定ルールに基づく通信をどう扱うか決めるものです。
今まで紹介した単純なルールだけでは制御しにくい場合に使用します。
※これが使いこなせると、立派なfirewalld使いですが、運用を考えるとルールはシンプルにしておきたいですね

さて、具体的な設定方法ですが、次の「2-7. Syslogサーバ」の中で紹介していきます。

2-7. Syslogサーバ

さて、次はSyslogサーバです。
検証するときに、ログを確認したい場面は多々あると思います。
サーバのローカル環境でファイルに保存するのもありですが、集約管理も魅力的ですよね。

今回は、Syslogサーバを立てて、他のサーバからのログを受け付ける前提で進めます。

パッケージの確認（インストール済みかどうか）

$ rpm -q rsyslog

rsyslog-8.2412.0-1.el9.x86_64

ステータス確認

$ systemctl status rsyslog

● rsyslog.service - System Logging Service
     Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; >
     Active: active (running) since Thu 2025-10-16 09:14:13 JST; 12min >
       Docs: man:rsyslogd(8)
             https://www.rsyslog.com/doc/
   Main PID: 1105 (rsyslogd)
      Tasks: 3 (limit: 22768)
     Memory: 3.0M
        CPU: 154ms
     CGroup: /system.slice/rsyslog.service
             mq1105 /usr/sbin/rsyslogd -n

10月 18 09:14:13 unyo systemd[1]: Starting System Logging Service...
10月 18 09:14:13 unyo rsyslogd[1105]: [origin software="rsyslogd" swVer>
10月 18 09:14:13 unyo systemd[1]: Started System Logging Service.
10月 18 09:14:13 unyo rsyslogd[1105]: imjournal: journal files changed,>

Active欄を確認すると、"active(running)"となっているため、稼働していることがわかります。

設定

いろいろ設定変更が必要です。

受信の許可
ログの保存先

それでは、順番に見ていきましょう。

受信の許可

リモートからのログを受信できるようにします。
ここでは514/UDPと514/TCPを受信できるようにします。

rsyslogのメイン設定ファイルは/etc/rsyslog.confですが、
追加設定は/etc/rsyslog.d/以下に.confファイルを置いていきます。
（これはrsyslog.confに「include(file="/etc/rsyslog.d/*.conf" mode="optional")」という設定があるためです）

設定ファイルは/etc/rsyslog.d/10-accept.confとします。
ファイルの内容は次の通りです。

# Enable UDP 514
module(load="imudp")
input(type="imudp" port="514")

# Enable TCP 514
module(load="imtcp")
input(type="imtcp" port="514")

ログの保存先

次に、リモートから受信したログをファイルに保存します。

設定ファイルは/etc/rsyslog.d/20-save.confとします。
ファイルの内容は次の通りです。

template(name="RemoteLogs" type="string"
         string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
*.* ?RemoteLogs
& stop

string="/var/log/～"の部分が、ログの保存先になります。
この会の例では接続元ホスト名毎にディレクトリを、
プログラム毎にファイルを分けています（が、この辺りは皆さんの自由です）。

.の部分が、ログの記録内容となります。
最初のの部分は、facilityです。
次のの部分が、priorityです。

今回の例では全部取得することにしていますが、実際は要件に合わせて設定してください。
（検証段階ではpriorityはこのままでもいいですが、実運用だとerror以上が多いかと）

ファイアウォール設定変更

さて、次はfirewalldの設定変更です（「2-6. ファイアウォール」で先送りにしたやつです）。
今は514/UDPと514/TCPの通信を遮断している（許可していない）設定になっているため、これを変更します。

$ sudo firewall-cmd --add-port=514/udp --permanent
$ sudo firewall-cmd --add-port=514/tcp --permanent

設定追加が成功すると、「success」と表示されます。

次に、追加した設定を読み込ませます。

$ sudo firewall-cmd --reload

success

Syslogサーバ設定チェック

さて、追加設定したconfファイルの構文（設定）が正しいか、チェックします。

$ sudo rsyslogd -N1

rsyslogd: version 8.2412.0-1.el9, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

特にエラーもないため、大丈夫そうですね。

Syslogサーバ再起動

では、再起動です。

$ sudo systemctl restart rsyslog

状態を確認しましょう。

$ sudo systemctl status rsyslog

● rsyslog.service - System Logging Service
     Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; >
     Active: active (running) since Thu 2025-10-16 15:04:44 JST; 26s ago
       Docs: man:rsyslogd(8)
             https://www.rsyslog.com/doc/
   Main PID: 3178 (rsyslogd)
      Tasks: 9 (limit: 22768)
     Memory: 3.5M
        CPU: 18ms
     CGroup: /system.slice/rsyslog.service
             mq3178 /usr/sbin/rsyslogd -n

10月 18 15:04:44 unyo systemd[1]: Starting System Logging Service...
10月 18 15:04:44 unyo rsyslogd[3178]: warning during parsing file /etc/>
10月 18 15:04:44 unyo rsyslogd[3178]: [origin software="rsyslogd" swVer>
10月 18 15:04:44 unyo systemd[1]: Started System Logging Service.
10月 18 15:04:44 unyo rsyslogd[3178]: imjournal: journal files changed,>

問題なさそうです。よしよし。

ポート起動確認

それでは、514/UDPと514/TCPのポートが起動しているかどうか、確認しましょう。

$ sudo ss -lntup | grep 514

udp   UNCONN 0      0            0.0.0.0:514        0.0.0.0:*    users:(("rsyslogd",pid=3178,fd=4))
udp   UNCONN 0      0               [::]:514           [::]:*    users:(("rsyslogd",pid=3178,fd=5))
tcp   LISTEN 0      25           0.0.0.0:514        0.0.0.0:*    users:(("rsyslogd",pid=3178,fd=6))
tcp   LISTEN 0      25              [::]:514           [::]:*    users:(("rsyslogd",pid=3178,fd=7))

514/UDPと514/TCPが起動していて、かつプロセス名が「rsyslogd」になっています。
問題なさそうですね。

ログ記録確認

それでは、実際に他のサーバから、Syslogサーバにログ転送できるかどうか確認してみましょう。
今回構築したサーバとは別のサーバ（Linux）にログインし、loggerコマンドで次のようにログを送信します。

$ logger -n <SyslogサーバIPアドレス> -P 514 -d "Syslog test from A-Server to Syslog-Server."

ここで＜SyslogサーバIPアドレス＞には、先ほどまで構築/設定していたSyslogサーバのIPアドレスを入力します。

さて、今度はSyslogサーバにログインし、ログを確認しましょう。
ログファイルは/var/log/remote/<ホスト名>/<プログラム名>.logです。

$ cat /var/log/remote/<ホスト名>/<プログラム名>.log

Oct 18 15:39:36 <ホスト名> <プログラム名> Syslog test form A-Server to Syslog-Server.

いい感じでログが記録されていますね、成功です！
（運用を考慮すると、ログのローテーションは別途考えないといけないのですが、これはまたの機会に）

2-8. SNMP Trap受信サーバ（SNMP Trap Receiver）

さて、お次はSNMP Trapの受信です。
（SNMP全般だと、正直それだけで１冊本が書けるレベルなので、今回はSNMP Trapの話に絞ります）
※ちなみに「私が」本が書けるとは言っていませんので、そのあたりはお察しください！

SNMP Trapは、ネットワーク機器やハードウェアアプライアンス等が自身の異常等を通知する仕組みです。
（SNMP=Simple Network Management Protocol）

このSNMP Trapを受け取るのがSNMP Trap受信サーバ（SNMP Trap Receiver）です。

ネットワーク機器やハードウェアアプライアンスを取り扱う場合、SNMP Trapを受信できる環境があった方が、検証が捗ります。
というわけで、SNMP Trap受信サーバ（SNMP Trap Receiver）を構築してみましょう。

インストール有無確認

では最初に、必要なパッケージがインストールされているか、確認しましょう。

$ rpm -qa | grep net-snmp

net-snmp-libs-5.9.1-17.el9.x86_64

ライブラリはインストール済みですが、SNMP本体や関連ツールはインストールされていないようです。

インストール

それでは、インストールしましょう。

$ sudo dnf install net-snmp net-snmp-utils -y

（長いので、省略）

インストール済み:
  lm_sensors-libs-3.6.0-10.el9.x86_64              mariadb-connector-c-3.2.6-1.el9_0.x86_64
  mariadb-connector-c-config-3.2.6-1.el9_0.noarch  net-snmp-1:5.9.1-17.el9.x86_64
  net-snmp-agent-libs-1:5.9.1-17.el9.x86_64        net-snmp-utils-1:5.9.1-17.el9.x86_64
  perl-File-Copy-2.34-481.1.el9_6.noarch           perl-Term-ReadLine-1.17-481.1.el9_6.noarch

完了しました!

インストール後の確認

$ rpm -qa | grep net-snmp

net-snmp-libs-5.9.1-17.el9.x86_64
net-snmp-agent-libs-5.9.1-17.el9.x86_64
net-snmp-5.9.1-17.el9.x86_64
net-snmp-utils-5.9.1-17.el9.x86_64

SNMP Trap受信設定

では、SNMP Trapを受信するために必要な設定をしていきましょう。
対象となるファイルは/etc/snmp/snmptrapd.confです。
既にファイルがある場合は、編集するので事前バックアップを取っておきましょう。

$ sudo cp -p /etc/snmp/snmptrapd.conf /etc/snmp/snmptrapd.conf.bak

snmptrapd.confに記載する内容は次の通りです。

authCommunity log,execute,net public
logOption f /var/log/snmptrapd.log

１行目はSNMP Trapを受信する際の設定です。
決まり文句のauthCommunityに続けて、SNMP Trap受信設定（log,execute,net）、コミュニティ名（public）を定義します。

SNMP Trap受信設定の部分は、SNMP Trapに対して許可する権限を設定します。
logは、ログに記録することを許可
executeは、スクリプトの実行を許可
netは、ネットワーク経由のSNMP Trapを受信することを許可
という意味になります。

最後のコミュニティ名は、送受信の両方で一致させる必要がある文字列です。publicは有名なコミュニティ名で、主に検証用途で使用します。

２行目はログの追加設定です。
「f」は、ファイル出力という意味になります。出力先のファイル名を指定します（今回の場合は/var/log/snmptrapd.log）。

SNMP Trap受信サーバ設定チェック

それでは次に、設定があっているか（構文として問題ないか）確認しましょう。

$ sudo snmptrapd -f -Lo -n -d

NET-SNMP version 5.9.1

エラーが出なければ問題ありません。なお、プロンプトが返ってきませんので、Ctrl + Cを使いましょう。

サービス起動確認

次はサービス起動確認です。
まず、サービスの状態を確認しましょう。

$ sudo systemctl status snmptrapd

○ snmptrapd.service - Simple Network Management Protocol (SNMP) Trap Daemon.
     Loaded: loaded (/usr/lib/systemd/system/snmptrapd.service; disabled; preset: disabled)
     Active: inactive (dead)

inactiveですね。
まあ、先ほどインストールしたばかりなので、当然と言えば当然ですね。

それでは、起動していきましょう。

$ sudo systemctl enable --now snmptrapd

Created symlink /etc/systemd/system/multi-user.target.wants/snmptrapd.service → /usr/lib/systemd/system/snmptrapd.service.

自動的にリンクが作成されましたね。
なお、--nowは、同時に起動もしてくれる便利な引数です。
覚えておきたいですね！

では、状態を確認しましょう。

$ sudo systemctl status snmptrapd

● snmptrapd.service - Simple Network Management Protocol (SNMP) Trap Daemon.
     Loaded: loaded (/usr/lib/systemd/system/snmptrapd.service; enabled; preset: disabled)
     Active: active (running) since Mon 2025-10-19 15:58:53 JST; 6min ago
   Main PID: 34240 (snmptrapd)
      Tasks: 1 (limit: 22768)
     Memory: 2.3M
        CPU: 26ms
     CGroup: /system.slice/snmptrapd.service
             mq34240 /usr/sbin/snmptrapd -Lsd -f

10月 19 15:58:53 unyo systemd[1]: Starting Simple Network Management Protocol (SNMP) Trap Dae>
10月 19 15:58:53 unyo snmptrapd[34240]: NET-SNMP version 5.9.1
10月 19 15:58:53 unyo systemd[1]: Started Simple Network Management Protocol (SNMP) Trap Daem>

Active: active (running)になっていますね。問題なしです。

ポート起動確認

それでは、ポートが起動しているかどうか、確認しましょう。

$ sudo ss -lntup | grep 162

udp   UNCONN 0      0            0.0.0.0:162        0.0.0.0:*    users:(("snmptrapd",pid=34240,fd=7))

ポートも問題ないですね。

ファイアウォール設定

ファイアウォールの設定も変更しましょう。
SNMP Trapは162/UDPを使用します。

$ sudo firewall-cmd --add-port=162/udp --permanent

success

追加した設定を読み込ませます。

$ sudo firewall-cmd --reload

success

SNMP Trapテスト

それではSNMP Trapを試しに飛ばしてみましょう。
今回は、同じサーバ間で試します。

$ snmptrap -v2c -c public localhost '' NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification

上記は、SNMP Trapを送る時の一例です。

では、Trap受信できているか、確認しましょう。

$ sudo journalctl -u snmptrapd -n 5 --no-pager

10月 19 17:57:37 unyo systemd[1]: Stopped Simple Network Management Protocol (SNMP) Trap Daemon..
10月 19 17:58:04 unyo systemd[1]: Starting Simple Network Management Protocol (SNMP) Trap Daemon....
10月 19 17:58:04 unyo snmptrapd[34848]: NET-SNMP version 5.9.1
10月 19 17:58:04 unyo systemd[1]: Started Simple Network Management Protocol (SNMP) Trap Daemon..
10月 19 17:58:42 unyo snmptrapd[34848]: 2025-10-20 17:58:42 localhost [UDP: [127.0.0.1]:44936->[127.0.0.1]:162]:
                                         DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2754205) 7:39:02.05        SNMPv2-MIB::snmpTrapOID.0 = OID: NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification

最後の行にきちんと表示されていますね。成功です。

念のため、別のサーバからもSNMP Trapを送ってみましょう。
別のサーバにログインし、次のコマンドを実行します。

$ snmptrap -v2c -c public ＜SNMP Trap受信サーバのIPアドレス＞ '' NET-SNMP-EXAMPLES-MIB
::netSnmpExampleHeartbeatNotification

さて、元のサーバに戻り、次のコマンドを実行します。

$ sudo journalctl -u snmptrapd -n 1 --no-pager

10月 19 18:27:16 unyo snmptrapd[34848]: 2025-10-19 18:27:16 unyo [UDP: [192.168.92.134]:44196->[192.168.92.134]:162]:
                                         DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2925538) 8:07:35.38        SNMPv2-MIB::snmpTrapOID.0 = OID: NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification

※「192.168.92.134」は、私が構築したSNMP Trap受信サーバのIPアドレスです
※「unyo」は、私が構築したSNMP Trap受信サーバのホスト名です

よかった、こちらも問題なさそうです。

9. まとめ

今回は、Linuxサーバの構築に必要な基本設定と、ファイアウォール、Syslog、SNMP Trapについてまとめてみました。

私が最近使ったものにフォーカスしたため、皆さんには物足りない内容になっているかもしれませんが、これをベースに自分で調べて、構築して、試行錯誤してもらえればよいかなと思っています。

9-1. 先送り

今回、先送りにしたもの（今後記載したいもの）は次の通りです。

SNMP（今回紹介したSNMP Trap以外の部分）
メール
それぞれの仕組みの通信の強化（UDP→TCPとか、暗号化とか）

この辺り、いずれ記事にできればと思っています。

90. おわりに

90-1. それでもシステムエンジニアを名乗りたい自分へ

生成AIの脅威に怯えつつ、この記事を書いています。
以前は調べ物をするときはGoogle検索（ググる）が中心だった私ですが、
最近はもっぱら生成AIと壁打ちです。
（ChatGPT課金勢です）

アバウトな問い合わせに対しても答えてくれるし、
昔の知識しか持っていない私にも、最新情報を教えてくれます。

あと、何回同じような質問をしても、嫌がらずに/めんどくさがらずに答えてくれるところ。徳の高い僧侶と対話している感じ。
※個人の見解です

正直、私のような古のシステムエンジニアこそ生成AIを活用するべきだと感じています。

生涯現役！

えるしっているか、さいきんのしすてむえんじにあは、ifconfig/netstatをつかわない
※ifconfig →　ip addr show
※netstat　→　ss

97. 参考文献

98. 更新履歴

2025.10.27 初版

99. EoF(End of File)