Ubuntu20.04でJournaledを使用してログを一元化する方法
著者は、 Write for DOnations プログラムの一環として、 Free and Open SourceFundを選択して寄付を受け取りました。
序章
システムログは、Linuxシステムを管理する上で非常に重要なコンポーネントです。 これらは、エラーに加えて、セキュリティイベントなどの運用情報を記録するため、システムがどのように機能しているか、またどのように使用されているかについての貴重な洞察を提供します。 Linuxシステムの標準構成では、ログが発生したのと同じシステムにローカルにログを保存します。 これはスタンドアロンシステムでは機能しますが、システムの数が増えるとすぐに問題になります。 これらすべてのログを管理するためのソリューションは、各Linuxホストがログを専用のログ管理サーバーにリアルタイムで送信する集中ログサーバーを作成することです。
一元化されたログソリューションには、各ホストにログを保存する場合と比較して、いくつかの利点があります。
- ログファイルを保存するために各ホストに必要なディスク容量を削減します。
- 専用のログサーバーをより多くのストレージ容量で構成できるため、ログをより長く保持できます。
- 複数のシステムからのログと、ホストで利用できるよりも多くのコンピューティングリソースを必要とする高度なログ分析を実行できます。
- システム管理者は、セキュリティ上の理由から直接ログインできない可能性のあるすべてのシステムのログにアクセスできます。
このガイドでは、 systemd ツールスイートのコンポーネントを構成して、クライアントシステムから一元化されたログ収集サーバーにログメッセージを中継します。 TLS証明書を使用して、インターネットなどの安全でないネットワークを介して送信されるログメッセージを暗号化し、相互に認証するようにサーバーとクライアントを構成します。
前提条件
このガイドを開始する前に、次のものが必要です。
- 2台のUbuntu20.04サーバー。
- 両方のサーバーでsudo権限を持つroot以外のユーザー。 これを行う方法については、 Ubuntu20.04の初期サーバーセットアップガイドに従ってください。 ガイドで説明されているように、両方のサーバーでUFWファイアウォールも構成する必要があります。
- サーバーを指す2つのホスト名。 ログを生成するclientシステム用の1つのホスト名と、ログコレクションserver用の別のホスト名。 ドメインとDNSのドキュメントを参照して、ホスト名をDigitalOceanドロップレットにポイントする方法を学びます。
このガイドでは、次の2つのホスト名の例を使用します。
client.your_domain：ログを生成するクライアントシステム。server.your_domain：ログ収集サーバー。
このチュートリアルを開始するには、root以外のsudoユーザーとしてSSH経由で別々の端末のクライアントとサーバーの両方にログインします。
注：チュートリアル全体を通して、コマンドブロックには、コマンドを実行するサーバー名（clientまたはserver）のラベルが付いています。
手順1—systemd-journal-remoteをインストールする
この手順では、systemd-journal-remoteパッケージをクライアントおよびサーバーにインストールします。 このパッケージには、クライアントおよびサーバーがログメッセージを中継するために使用するコンポーネントが含まれています。
まず、clientとserverの両方で、システムアップデートを実行して、パッケージデータベースとシステムが最新であることを確認します。
- sudo apt update
- sudo apt upgrade
次に、systemd-journal-remoteパッケージをインストールします。
- sudo apt install systemd-journal-remote
server で、次のコマンドを使用して、ログメッセージを受信するために必要な2つのsystemdコンポーネントを有効にして起動します。
- sudo systemctl enable --now systemd-journal-remote.socket
- sudo systemctl enable systemd-journal-remote.service
最初のコマンドの--nowオプションは、サービスをすぐに開始します。 このサービスは、次の手順で作成するTLS証明書を取得するまで開始されないため、2番目のコマンドでは使用しませんでした。
クライアントで、systemdがサーバーにログメッセージを送信するために使用するコンポーネントを有効にします。
- sudo systemctl enable systemd-journal-upload.service
次に、サーバーで、UFWファイアウォールのポート19532と80を開きます。 これにより、サーバーはクライアントからログメッセージを受信できるようになります。 ポート80は、certbotがTLS証明書を生成するために使用するポートです。 次のコマンドは、これらのポートを開きます。
- sudo ufw allow in 19532/tcp
- sudo ufw allow in 80/tcp
クライアントでは、次のコマンドでポート80を開くだけで済みます。
- sudo ufw allow in 80/tcp
これで、必要なコンポーネントがインストールされ、クライアントとサーバーの基本システム構成が完了しました。 ログメッセージの中継を開始するようにこれらのコンポーネントを構成する前に、certbotを使用してclientおよびserverのLet’sEncryptTLS証明書を登録します。 ] 効用。
ステップ2—Certbotのインストールと証明書の登録
Let’s Encryptは、無料のTLS証明書を発行する認証局です。 これらの証明書を使用すると、コンピューターは、コンピューター間で送信するデータを暗号化することも、互いのIDを確認することもできます。 これらの証明書は、HTTPSを使用してインターネットブラウジングを保護するためのものです。 同じレベルのセキュリティが必要な他のアプリケーションでも同じ証明書を使用できます。 証明書を登録するプロセスは、それらを何に使用するかに関係なく同じです。
このステップでは、certbotユーティリティをインストールし、それを使用して証明書を登録します。 また、有効期限が切れると、証明書の更新も自動的に処理されます。 ここでの登録プロセスは、クライアントとサーバーで同じです。 登録コマンドを実行しているホストと一致するようにホスト名を変更するだけで済みます。
まず、certbotユーティリティがuniverseリポジトリにあるため、Ubuntuのuniverseリポジトリを有効にします。 universeリポジトリをすでに有効にしている場合、これらのコマンドを実行してもシステムには何の影響も与えず、安全に実行できます。
- sudo apt install software-properties-common
- sudo add-apt-repository universe
- sudo apt update
次に、両方のホストにcertbotをインストールします。
- sudo apt install certbot
certbotをインストールしたので、次のコマンドを実行して、クライアントおよびサーバーに証明書を登録します。
- sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain
このコマンドのオプションは次のとおりです。
certonly：証明書を登録し、システムに他の変更を加えません。--standalone：certbotの組み込みWebサーバーを使用して、証明書要求を検証します。--agree-tos：Let’sEncryptの利用規約に自動的に同意します。--email your_email：これは、Let’sEncryptが証明書の有効期限やその他の重要な情報を通知するために使用するメールアドレスです。-d your_domain：証明書が登録されるホスト名。 これは、実行するシステムと一致する必要があります。
このコマンドを実行すると、Let’s Encryptと電子メールアドレスを共有して、彼らの仕事に関するニュースやその他の情報を電子メールで送信できるようにするかどうかを尋ねられます。 これを行うことはオプションです。電子メールアドレスを共有しない場合でも、証明書の登録は正常に完了します。
証明書の登録プロセスが完了すると、証明書とキーファイルが/etc/letsencrypt/live/your_domain/に配置されます。ここで、your_domainは証明書を登録したホスト名です。
最後に、Let’s EncryptのCAと中間証明書のコピーをダウンロードして、同じファイルに入れる必要があります。 journaldはこのファイルを使用して、クライアントとサーバーが相互に通信するときに証明書の信頼性を検証します。
次のコマンドは、Let’s EncryptのWebサイトから2つの証明書をダウンロードし、ユーザーのホームディレクトリにあるletsencrypt-combined-certs.pemという1つのファイルに配置します。
クライアントおよびサーバーで次のコマンドを実行して、証明書をダウンロードし、結合されたファイルを作成します。
- curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem
次に、このファイルを証明書とキーを含むLet’sEncryptディレクトリに移動します。
- sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/
これで、証明書とキーが登録されました。 次のステップでは、ログ収集サーバーを構成して、クライアントからのログメッセージのリッスンと保存を開始します。
ステップ3—サーバーの構成
このステップでは、クライアントからのログメッセージの受け入れを開始できるように、前のステップで生成した証明書とキーファイルを使用するようにサーバーを構成します。
systemd-journal-remoteは、ログメッセージをリッスンするコンポーネントです。 テキストエディタで/etc/systemd/journal-remote.confにある構成ファイルを開き、サーバーで構成を開始します。
- sudo nano /etc/systemd/journal-remote.conf
次に、[Remote]セクションの下のすべての行のコメントを解除し、作成したTLSファイルを指すようにパスを設定します。
[Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem
ここで使用したオプションは次のとおりです。
Seal=false：ジャーナルのログデータに署名します。 最大限のセキュリティが必要な場合は、これを有効にしてください。 それ以外の場合は、falseのままにしておくことができます。SplitMode=host：リモートクライアントからのログは、/var/log/journal/remoteでホストごとに分割されます。 すべてのログを1つのファイルに追加する場合は、これをSplitMode=falseに設定します。ServerKeyFile：サーバーの秘密鍵ファイル。ServerCertificateFile：サーバーの証明書ファイル。TrustedCertificateFile：Let’sEncryptCA証明書を含むファイル。
次に、systemd-journal-remoteがそれらを読み取って使用できるように、証明書とキーを含むLet’sEncryptディレクトリのアクセス許可を変更する必要があります。
まず、permissions を変更して、証明書と秘密鍵が読み取れるようにします。
- sudo chmod 0755 /etc/letsencrypt/{live,archive}
- sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem
次に、秘密鍵のグループ所有権をsystemd-journal-remoteのグループに変更します。
- sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem
これで、systemd-journal-remoteを開始できます。
- sudo systemctl start systemd-journal-remote.service
これで、ログコレクションサーバーが実行され、クライアントからのログメッセージの受け入れを開始する準備が整いました。 次のステップでは、ログをコレクションサーバーに中継するようにクライアントを構成します。
ステップ4—クライアントの構成
このステップでは、ログメッセージをログ収集サーバーに中継するコンポーネントを構成します。 このコンポーネントはsystemd-journal-uploadと呼ばれます。
systemd-journal-uploadのデフォルト構成では、プロセスの実行中にのみ存在する一時ユーザーを使用します。 これにより、systemd-journal-uploadがTLS証明書とキーを読み取ることがより複雑になります。 これを解決するには、代わりに使用される一時ユーザーと同じ名前の新しいシステムユーザーを作成します。
まず、次のadduserコマンドを使用して、クライアントにsystemd-journal-uploadという新しいユーザーを作成します。
- sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload
コマンドのこれらのオプションは次のとおりです。
--system：システムユーザーとして新しいユーザーを作成します。 これにより、1000の下にあるUID（ユーザー識別子）番号がユーザーに提供されます。1000を超えるUIDは通常、人間がログインに使用するユーザーアカウントに与えられます。--home /run/systemd：このユーザーのホームディレクトリとして/run/systemdを設定します。--no-create-home：ホームディレクトリセットは既に存在するため、作成しないでください。--disabled-login：ユーザーはSSHなどを介してサーバーにログインできません。--group：ユーザーと同じ名前のグループを作成します。
次に、Let’sEncrypt証明書ファイルのアクセス許可と所有権を設定します。
- sudo chmod 0755 /etc/letsencrypt/{live,archive}
- sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
- sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem
次に、/etc/systemd/journal-upload.confにあるsystemd-journal-uploadの構成を編集します。 このファイルをテキストエディタで開きます。
- sudo nano /etc/systemd/journal-upload.conf
このファイルを次のように編集します。
[Upload]
URL=https://server.your_domain:19532
ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem
最後に、systemd-journal-uploadサービスを再起動して、新しい構成を使用するようにします。
- sudo systemctl restart systemd-journal-upload.service
これで、クライアントがセットアップされて実行され、ログメッセージがログ収集サーバーに送信されます。 次のステップでは、ログが正しく送信および記録されていることを確認します。
ステップ5—クライアントとサーバーのテスト
このステップでは、クライアントがログメッセージをサーバーに中継していること、およびサーバーがそれらを正しく保存していることをテストします。
ログ収集サーバーは、クライアントからのログを/var/log/journal/remote/のディレクトリに保存します。 最後のステップの最後にclientを再起動すると、ログメッセージの送信が開始されたため、/var/log/journal/remote/にログファイルがあります。 ファイルには、TLS証明書に使用したホスト名にちなんで名前が付けられます。
lsコマンドを使用して、クライアントのログファイルがサーバーに存在することを確認します。
- sudo ls -la /var/log/journal/remote/
これにより、ログファイルを示すディレクトリの内容が出力されます。
Outputtotal 16620
drwxr-xr-x 2 systemd-journal-remote systemd-journal-remote 4096 Jun 30 16:17 .
drwxr-sr-x+ 4 root systemd-journal 4096 Jun 30 15:55 ..
-rw-r----- 1 systemd-journal-remote systemd-journal-remote 8388608 Jul 1 10:46 'remote-CN=client.your_domain'
次に、クライアントにログメッセージを書き込んで、サーバーがクライアントのメッセージを期待どおりに受信していることを確認します。 logger ユーティリティを使用して、clientでカスタムログメッセージを作成します。 すべてが機能している場合、systemd-journal-uploadはこのメッセージをサーバーに中継します。
クライアントで、次のloggerコマンドを実行します。
- sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"
このコマンドの-p syslog.debugは、メッセージの機能と重大度を設定します。 これをsyslog.debugに設定すると、テストメッセージであることが明確になります。 このコマンドは、メッセージ### TEST MESSAGE from client.your_domain ###をクライアントのジャーナルに記録し、クライアントのジャーナルはsystemd-journal-uploadがサーバーに中継します。
次に、サーバーのクライアントのジャーナルファイルを読み取り、クライアントからログメッセージが到着していることを確認します。 このファイルはバイナリログファイルであるため、lessなどのツールで読み取ることはできません。 代わりに、journalctlと--file=オプションを使用してファイルを読み取ります。このオプションを使用すると、カスタムジャーナルファイルを指定できます。
- sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal
ログメッセージは次のように表示されます。
Test log message. . .
Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###
これで、ログ集中化サーバーがクライアントシステムからログを正常に収集しています。
結論
この記事では、ログ中央収集サーバーをセットアップし、システムログのコピーをサーバーに中継するようにクライアントを構成しました。 ここで使用したクライアント構成手順を使用して、ログ収集サーバーにメッセージを中継するために必要な数のクライアントを構成できます。
