Debian10でJournaledを使用してログを一元化する方法
序章
システムログは、Linuxシステムを管理する上で非常に重要なコンポーネントです。 これらは、エラーに加えて、セキュリティイベントなどの運用情報を記録するため、システムがどのように機能しているか、またどのように使用されているかについての貴重な洞察を提供します。 Linuxシステムの標準構成では、ログが発生したのと同じシステムにローカルにログを保存します。 これはスタンドアロンシステムでは機能しますが、システムの数が増えるとすぐに問題になります。 これらすべてのログを管理するためのソリューションは、各Linuxホストがログを専用のログ管理サーバーにリアルタイムで送信する集中ログサーバーを作成することです。
一元化されたログソリューションには、各ホストにログを保存する場合と比較して、いくつかの利点があります。
- ログファイルを保存するために各ホストに必要なディスク容量を削減します。
- より多くのストレージ容量で専用ログサーバーを構成できるため、ログをより長く保持できます。
- 複数のシステムからのログと、ホストで利用できるよりも多くのコンピューティングリソースを必要とする高度なログ分析を実行できます。
- システム管理者は、セキュリティ上の理由から直接ログインできない可能性のあるすべてのシステムのログにアクセスできます。
このガイドでは、 systemd ツールスイートのコンポーネントを構成して、クライアントシステムから一元化されたログ収集サーバーにログメッセージを中継します。 TLS証明書を使用して、インターネットなどの安全でないネットワークを介して送信されるログメッセージを暗号化し、相互に認証するようにサーバーとクライアントを構成します。
前提条件
このガイドを開始する前に、次のものが必要です。
- 2台のDebian10サーバー。
- 両方のサーバーでsudo権限を持つroot以外のユーザー。 これを行う方法については、 Debian10による初期サーバーセットアップガイドに従ってください。 ガイドで説明されているように、両方のサーバーで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
The --now
最初のコマンドのオプションは、サービスをすぐに開始します。 次の手順で作成するTLS証明書が取得されるまでこのサービスは開始されないため、2番目のコマンドでは使用しませんでした。
クライアントで、次のコンポーネントを有効にします。 systemd
ログメッセージをサーバーに送信するために使用します。
- sudo systemctl enable systemd-journal-upload.service
次に、サーバーでポートを開きます 19532
と 80
UFWファイアウォールで。 これにより、サーバーはクライアントからログメッセージを受信できるようになります。 ポート 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
および両方のホストのcurlユーティリティ:
- sudo apt install certbot curl
これでインストールしました 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つの証明書をダウンロードし、それらをという1つのファイルに入れます。 letsencrypt-combined-certs.pem
ユーザーのホームディレクトリにあります。
クライアントおよびサーバーで次のコマンドを実行して、証明書をダウンロードし、結合されたファイルを作成します。
- 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証明書を含むファイル。
次に、証明書とキーを含むLet’sEncryptディレクトリのアクセス許可を変更して systemd-journal-remote
それらを読んで使用することができます。
まず、許可を変更して、証明書と秘密鍵を読み取り可能にします。
- 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証明書とキーを読み取るため。 これを解決するには、代わりに使用される一時ユーザーと同じ名前の新しいシステムユーザーを作成します。
まず、という新しいユーザーを作成します systemd-journal-upload
クライアントで次のように adduser
指図:
- sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload
コマンドのこれらのオプションは次のとおりです。
--system
:システムユーザーとして新しいユーザーを作成します。 これにより、ユーザーにUID(ユーザー識別子)番号が与えられます。1000
. UIDが終了しました1000
通常、人間がログインに使用するユーザーアカウントに与えられます。--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
次に、の構成を編集します systemd-journal-upload
、にあります /etc/systemd/journal-upload.conf
. このファイルをテキストエディタで開きます。
- 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 ###"
The -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 ###
これで、ログ集中化サーバーがクライアントシステムからログを正常に収集しています。
結論
この記事では、ログ中央収集サーバーをセットアップし、システムログのコピーをサーバーに中継するようにクライアントを構成しました。 ここで使用したクライアント構成手順を使用して、ログ収集サーバーにメッセージを中継するために必要な数のクライアントを構成できます。