2023年5月27日土曜日

Windows用Zabbix Agent 2インストール手順

Zabbixは監視対象OSにZabbix Agentと呼ばれるエージェントを導入することで、CPUやメモリの使用率を取得やログの監視をするなどの監視を実現することができる。

Zabbix Agentは、新しくGo言語で開発された「Zabbix Agent 2」という新バージョンが存在する。以前のZabbix Agentとの違いは以下公式マニュアルに記載があるが、これから新しく監視対象を追加する場合は、基本的にZabbix Agent 2を選択した方がよいだろう。

本記事では、Windows用Zabbix Agent 2インストール手順を記載する。以前(Zabbix 3.0や4.0の時代)は手作業でZabbix Agentのバイナリを配置してサービスへの登録やWindowsファイアウォールの設定などが必要だったが、現在はMSIによるインストーラ形式で公開されており、インストールは非常に楽になっていた。

環境

  • Zabbix Server : 6.0.17
  • 監視対象OS : Windows Server 2022
  • Zabbix Agent 2バージョン : 6.0.17

Windows用Zabbix Agent 2インストール手順

1. Zabbix Agent 2のダウンロード

Zabbix Agent 2は以下URLからダウンロードできる。

今回は、以下の通り、Zabbix 6.0用のエージェントを指定する。

項目 設定値
OS DISTRIBUTION Windows
OS VERSION Any
HARDWARE amd64
ZABBIX VERSION 6.0 LTS
ENCRYPTION OpenSSL
PACKAGING MSI

指定すると、従来のZabbix AgentとZabbix Agent 2の二種類が表示されるので、Zabbix Agent 2のMSIインストーラをダウンロードする。

2. インストールウィザード実行

ダウンロードしたMSIインストーラは、そのままダブルクリックして実行すれば、インストールウィザードが起動する。

インストールウィザードでは複雑な設定はないため画面は割愛するが、最低限、自身のホスト名やZabbix ServerのIPアドレスを指定すればよい。

画面 操作説明
Welcome to Zabbix Agent 2 Setup Wizard そのまま「Next」を選択。
End-User License Agreement 同意のチェックボックスにチェックし、「Next」を選択。
Custom Setup そのまま「Next」を選択。
Zabbix Agent 2 service configuration ここでは、監視対象OSのホスト名、Zabbix ServerのDNS名/IPアドレス、ポート番号、アクティブチェック時のZabbix ServerのDNS名/IPアドレスなどを指定する。ホスト名は、Windowsのコンピューター名から自動的に入力がされているが、すべて英大文字になっている注意する。Zabbix Serverで登録しているホスト名と大文字・小文字が一致していない場合、監視が正常に動作しない場合があるため、その場合は小文字に修正してインストールを進めよう。
Ready to install Zabbix Agent 2 そのまま「Install」を選択。

インストールが終わると、Zabbix Agent 2はサービス登録され自動起動される。

また、Windowsファイアウォールの受信の規則において、「Zabbix Agent 2 listen port」というルールが追加され、Zabbix Serverからの通信を受け付けるようになっている。

3. Zabbix Serverでホスト登録を行い疎通できることを確認

Zabbix Serverで監視対象のWindows OSのホスト登録を行い、「Windows by Zabbix agent」のテンプレートを適用してみよう。しばらくしてエージェントの状態が緑表示になれば、問題なくZabbix ServerとZabbix Agent 2間で疎通が取れていることになる。

以上で、Windows用Zabbix Agent 2インストール手順は完了となる。

2023年5月20日土曜日

Azure AD Connectバージョンアップ手順 (2.1.15.0→2.1.20.0)

本記事では、Azure AD Connectをバージョンアップする手順 (2.1.15.0→2.1.20.0)を記載する。なお、Azure AD Connect自体の導入手順については、以下別記事を参照いただきたい。

Azure ADを1.xから2.xにバージョンアップする手順は、以下別記事を参照いただきたい。

環境

バージョンアップ対象となるオンプレADは以下の通り。

  • Windows Server 2016 Standard
  • Azure AD Connect
    • バージョンアップ前 : 2.1.15.0
    • バージョンアップ後 : 2.1.20.0

Azure AD Connectバージョンアップ手順

1. インストーラをダウンロード

Azure AD Connectの最新版を以下からダウンロードし、ADに配置する。

ダウンロードされるファイルの詳細は「Details」から確認できる。今回のターゲットバージョンは「2.1.20.0」となる。

2. インストーラ実行

インストーラをダブルクリックし実行すると、「Azure Active Directory Connecのアップグレード」が表示されるので、「アップグレード」を選択する。

3. グローバル管理者のパスワードを入力

「Azure ADに接続」にてAzure ADのグローバル管理者のパスワードを指定する。

4. バージョンアップ開始

「構成の準備完了」で「アップグレード」を選択すると、バージョンアップが開始される。バージョンアップは1分もあれば完了する。

5. 動作確認

最後に、問題なくAzure AD Connectが動作していることを確認する。Azure Portalでも確認することができなるが、詳細な情報を確認できないので、Micorosoft 365管理センターより確認する。

「最新のディレクトリ同期」の時間がバージョンアップ以降であり、「ディレクトリ同期のクライアントバージョン」が最新の「2.1.20.0」に更新されていることがわかる。

以上で、Azure AD Connectのバージョンアップ手順は完了となる。

2023年5月13日土曜日

Linuxで信頼されるルート証明書として自己署名証明書を登録する

Windowsでは、自己署名証明書を「信頼されたルート証明機関」の証明書として登録することで、ブラウザでローカルのシステムにアクセスした際の証明書エラーを出さないようにできる。

以下、参考URLとなる。

Linuxでも同様に、自己署名証明書を「信頼されたルート証明機関」の証明書として登録することで証明書エラーを発生させなくすることが可能となる。

本記事では、Linuxで信頼されるルート証明書として自己署名証明書を登録し、コマンドやブラウザで証明書エラーを表示させないようにする手順を記載する。

環境

本手順の確認環境は以下となる。Red Hat系のOSであれば、同様の手順で対応できるはずだ。

  • OS : AlmaLinux release 8.6

登録する証明書情報は以下のとなる。

  • CN = My Private CA
  • O = Default Company Ltd
  • S = Tokyo
  • C = JP

自己署名証明書を「信頼されたルート証明機関」の証明書として登録する手順

1. 証明書を配置

証明書を配置する前に、「信頼されたルート証明機関」の証明書リストを以下コマンドで出力してみよう。当然だが登録前なので、ここには自己署名証明書の情報は出力されない。

# trust list
pkcs11:id=%D2%87%B4%E3%DF%37%27%93%55%F6%56%EA%81%E5%36%CC%8C%1E%3F%BD;type=cert
    type: certificate
    label: ACCVRAIZ1
    trust: anchor
    category: authority

~(以下略)~

今回の自己署名証明書はcacert.pemで事前に作成している。これを/etc/pki/ca-trust/source/anchors/のディレクトリにコピーする。

# cp cacert.pem /etc/pki/ca-trust/source/anchors/

2. 証明書反映コマンド実行

証明書配置後、以下コマンドで反映する。これだけで作業は完了となる。

# update-ca-trust

最後に、証明書の登録状況を確認しておこう。追加された証明書が一番上に表示されるはずだ。

# trust list | head -6
pkcs11:id=%28%C6%94%08%49%18%A4%19%B3%94%A9%0D%F1%54%95%00%AA%98%87%F9;type=cert
    type: certificate
    label: My Private CA
    trust: anchor
    category: authority

CA証明書登録後の接続確認

1. curlによる確認

まず、CA証明書登録前の情報を確認してみると、以下の通り、SSL certificate problem: unable to get local issuer certificate(ローカルで発行された証明書が取得できない)のエラーで接続に失敗していることがわかる。
※ちなみに、本エラーを無視して強制的に接続する場合は、-kオプションを付与すればよい。

# curl -v https://192.168.11.50
* Rebuilt URL to: https://192.168.11.50/
*   Trying 192.168.11.50...
* TCP_NODELAY set
* Connected to 192.168.11.50 (192.168.11.50) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

CA証明書を登録後、再度同一コマンドで接続すると、今度はSSL certificate verify ok.のメッセージが出力されており、接続に成功していることがわかる。

# curl -v https://192.168.11.50
* Rebuilt URL to: https://192.168.11.50/
*   Trying 192.168.11.50...
* TCP_NODELAY set
* Connected to 192.168.11.50 (192.168.11.50) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=JP; ST=Tokyo; L=Default City; O=Default Company Ltd; CN=t1050harb
*  start date: Apr 29 04:08:32 2023 GMT
*  expire date: Apr 26 04:08:32 2033 GMT
*  subjectAltName: host "192.168.11.50" matched cert's IP address!
*  issuer: C=JP; ST=Tokyo; O=Default Company Ltd; CN=My Private CA
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: 192.168.11.50
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx

~(以下略)~

2. ブラウザによる確認

ブラウザはFirefoxにて確認する。ブラウザによる接続も、まずはCA証明書登録前の状態を確認すると、「潜在的なセキュリティリスクあり」の警告でエラーになる。

CA証明書を登録後は、特に警告表示なく接続先の画面が表示される。アドレスバーからも、「このサイトとの接続は安全です。」と表示されていることがわかる。

以上で、Linuxで信頼されるルート証明書として自己署名証明書を登録し、コマンドやブラウザで証明書エラーを表示させないようにする手順は完了となる。

2023年5月6日土曜日

OSSのコンテナレジストリ「Harbor」を自己署名証明書でHTTPS通信させる

以前、OSSのコンテナレジストリ「Harbor」を構築する手順を記載した。

上記手順では、手順簡略化のためにHarborとDocker間をHTTPにて通信するよう構成したが、本来HarborもDockerもHTTPSによるSSL通信を前提としている。

そこで今回は、Harborに自己署名証明書を登録し、HarborとDocker間をHTTPSにて通信できるよう構成してみた。

環境

Harbor自体はDockerコンテナとして動作する。Harbor及びDockerが動作するOSとしてはAlmaLinuxを使用した。

  • OS : AlmaLinux release 8.6
  • Docker : 23.0.5
  • Docker Compose : v2.17.3
  • Harbor : v2.8.0

Harborをインストールするサーバのホスト名とIPアドレスは以下となり、DNSで名前解決できる状態としてある。

  • ホスト名 : t1050harb
  • IPアドレス : 192.168.11.50

自己署名証明書作成

自己署名証明書のSSLサーバ証明書の作成手順は、以下記事を参照すること。

本記事では、手順の概要のみ記載する。

1. 秘密鍵の作成

秘密鍵を作成するディレクトリは任意の場所で問題ないが、不特定多数が見れないディレクトリが望ましい。

今回は/etc/pki/tls/misc/に作成することとする。秘密鍵はopensslコマンドを使って以下の通り作成する。

# cd /etc/pki/tls/misc/
# openssl genrsa 2048 > server.key

2. CSRを作成

作成した秘密鍵からCSRを作成する。

# openssl req -new -key server.key > server.csr

オレオレ認証局として構築済みのサーバに、先ほど作成したserver.csrをコピーし、/etc/pki/tls/misc/newreq.pemというファイル名で配置する。

3. SAN情報を作成

近年のサーバ証明書は、Common Nameに記載された情報ではなく、SAN(Subject Alternative Name; サブジェクト代替名)と呼ばれる情報に記載されたFQDNやIPアドレスの情報と、接続先のURLが一致することを確認する。

今回は、SANの情報として、Harborのホスト名、FQDN、IPアドレスを登録するようにした。

# cd /etc/pki/tls/misc/
# cat << EOF > san.txt
subjectAltName = DNS:t1050harb, DNS:t1050harb..example.com, IP:192.168.11.50
EOF

4. オレオレ認証局にて署名

CSRへの署名はCAスクリプトを用いて実施する。Red Hat 8以降のopensslにはCAスクリプトが含まれていないため、以前のバージョンのRPMなどから入手すること。

# ./CA -sign

作成された証明書はnewcert.pemという名前で保存されるので、ファイル名を変えておこう。

# ls -l newcert.pem
-rw-r--r-- 1 root root 4199  4月 29 13:08 newcert.pem
cp newcert.pem server_t1050harb.crt

5. 秘密鍵とサーバ証明書を配置

作成した秘密鍵とサーバ証明書は、それぞれ以下ディレクトリに配置する。

証明書 ファイル名 ディレクトリ
サーバ証明書 server_t1050harb.crt /etc/pki/tls/certs/
秘密鍵 server_t1050harb.key /etc/pki/tls/private/

Harborインストール

Harborのインストール手順も大きくは以前の記事の手順と変わらない。

インストール時に使用する設定ファイルであるharbor.ymlのみ差異があるため、その個所を抜粋して記載する。

1. harbor.ymlの修正

HTTPSで通信させる場合は、harbor.ymlの修正箇所は以下3か所のみとなる。

  • hostname
  • certificate
  • private_key

harbor.yml

# Configuration file of Harbor

# The IP address or hostname to access admin UI and registry service.
# DO NOT use localhost or 127.0.0.1, because Harbor needs to be accessed by external clients.
hostname: t1050harb.example.com ←★ホスト名を設定する。DNSなどで名前解決できる場合はFQDN設定が望ましい

# http related config
http:
  # port for http, default is 80. If https enabled, this port will redirect to https port
  port: 80

# https related config
https:
  # https port for harbor, default is 443
  port: 443
  # The path of cert and key files for nginx
  certificate: /etc/pki/tls/certs/server_t1050harb.crt ←★サーバ証明書のパスを指定
  private_key: /etc/pki/tls/private/server_t1050harb.key ←★秘密鍵のパスを指定

~(以下略)~

4. ログイン確認

harbor.yml修正後インストールを行い、HarborのGUIに以下デフォルトユーザー・パスワードでアクセスしてみよう。

  • ユーザー名 : admin
  • パスワード : Harbor12345

ブラウザで証明書情報を確認すると、作成した自己署名証明書でHTTPS通信されていることが確認できる。オレオレ認証局のCA証明書を「信頼されたルート証明機関」の証明書として登録しておけば、ブラウザの証明書エラーも表示されることなくアクセスできる。

DockerからHarborへ接続

次にDockerからHTTPSで接続するための設定を行う。結論から言うと、単純に何もしないと以下の通りdocker loginした際にx509: certificate signed by unknown authorityのエラーで失敗する。

# docker login 192.168.11.50
Username: admin
Password:
Error response from daemon: Get "https://192.168.11.50/v2/": x509: certificate signed by unknown authority

1. オレオレ人書局のCA証明書を「信頼されたルート証明機関」の証明書として配置

エラーを解消するために、オレオレ人書局のCA証明書を信頼される証明書として配置する。Dockerの場合はOSの証明書設定とは別に、以下ルールに沿った配置が必要となる。

  • ディレクトリは/etc/docker/certs.d/[FQDN or IPアドレス]で作成する
  • CA証明書のファイルはca.crtというファイル名にする

今回は、DockerからIPアドレスで接続するため、192.168.11.50でフォルダを作成し、CA証明書を配置する。

# mkdir -p /etc/docker/certs.d/192.168.11.50
# cp /tmp/ca.crt /etc/docker/certs.d/192.168.11.50/ca.crt

2. Dcokerから接続確認

Doockerからの接続確認は、docker loginコマンドで行う。ユーザ名・パスワードは、HarborのGUIログイン時に使用するものと同じとなる。

  • ユーザー名 : admin
  • パスワード : Harbor12345

以下のようにLogin Succeededと表示されれば成功となる。

# docker login 192.168.11.50
Username: admin
Password:
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

もし、以下のようにService Unavailableのエラーが表示される場合は、何らかの理由でコンテナレジストリへの接続に失敗している。

# docker login 192.168.11.50
Username: admin
Password:
Error response from daemon: Get "https://192.168.11.50/v2/": Get "https://t1050harb..example.com/service/token?account=admin&client_id=docker&offline_token=true&service=harbor-registry": Service Unavailable

Service Unavailableのエラーの場合は、そもそも接続に失敗している可能性がある。DNSの名前解決(DNSを使えない場合はhostsにレコードを登録する)や、プロキシ除外設定(IPアドレスだけでなくFQDNも除外する)などの設定に問題がないか確認してみよう。

最後に、docker logoutを実行し、認証情報の削除を行う。

# docker logout 192.168.11.50
Removing login credentials for 192.168.11.50

以上で、Harborに自己署名証明書を登録し、HarborとDocker間をHTTPSにて通信できるよう構成する手順は完了となる。

人気の投稿