無償で使えるDELL EMCのストレージアプライアンス「UnityVSA」のインストール手順

DELLより提供されている仮想ストレージアプライアンスである「UnityVSA」は、コミュニティエディションが用意されており、管理可能な容量が4TBに制限されているものの、無償で使用することができるストレージアプライアンスとなる。

• データ ストレージ管理ソフトウェアのダウンロード | Dell Technologies Japan

UnityVSAではNFS/CIFSのファイルストレージ機能だけでなくiSCSIによるブロックストレージ機能も利用できる。さらにはスナップショットやレプリケーションの機能も利用できることから、一般的なストレージOSの動作確認や、設定手順・操作手順の学習用途として、非常に有用となる。
※本記事では説明はしないが、VMware SRMなどと連携して、アレイベースのレプリケーションを利用したDR動作の検証なども実施できる。

本記事では、ストレージアプライアンスである「UnityVSA」をESXi上の仮想マシンとしてインストールする手順を紹介する。

環境

今回は、ESXi上にUnityVSAのアプライアンスを展開する。CPUは2コア、メモリは12GB必要となり、メモリの使用量がやや大きいので注意すること。

• UnityVSA 5.0.3
• ESXi 6.7 Update 3

インストール手順

1. OVAファイルをダウンロード

以下URLにて「Agree & Download」をクリックして、OVAファイルをダウンロードする。

• UnityVSA and Unity Cloud Edition | Dell Technologies Japan

2. OVAのデプロイ

ESXiにてダウンロードしたOVAをデプロイする。デプロイ時にホスト名とIPアドレスを設定することができるが、なぜか設定が反映されない状態で起動してしまう。

そのため、IPアドレスが固定されないことから、初期設定時はDHCPでIPアドレスを取得できる必要がある。
※厳密にはCLIにてIPアドレス設定をすればDHCPはなくても構築はできると思われる。

3. UnityVSAの起動

デプロイ後、UnityVSAを起動させる。起動完了まで、10～15分要するので、気長に待つこと。起動が完了すると、コンソール上に「Unisphere IP」として、DHCPで取得したIPアドレスが表示される。

初期設定手順

1. UnityVSAへログイン

コンソールに表示されたIPアドレスに対して、Webブラウザよりログインを行う。デフォルトのユーザとパスワードは以下のとなる。

• ユーザ : admin
• パスワード : Password123#

2. インストールウィザードに従い初期設定実施

初回ログイン時にはインストールウィザードにて初期設定の実施が必要となる。以下設定項目と設定項目を記載する。

設定項目	説明
Admin and Service Password	任意のパスワードを設定。「Set service password the same as admin password」にチェックする。別パスワードを設定したい場合はチェックを外す。
DNS Servers	「Configure DNS server address manually」を選択し、DNSサーバのIPアドレスを設定する。
NTP Servers	NTPサーバのIPアドレスを設定する。
Unisphere Licenses	「【補足】ライセンス発行」を参照。
Pools	プールは後で作成することとし、設定せず次に進む。
Alert Settings	特にメールによる監視設定は不要となるため、設定せず次に進む。
Proxy Server	UnityVSAはインターネット接続せずとも使用できるので設定不要となる。
iSCSI Interfaces	iSCSI用のインタフェースは後で作成することとし、設定せず次に進む。
NAS Servers	NFSやCIFSで用いるNAS Serversは後で作成することとし、設定せず次に進む。

【補足】ライセンス発行

インストールウィザードの「Unisphere Licenses|」の画面では以下のようにインストール時に自動生成される「System UUID」が表示される。

この情報を控えたうえで、DELLの評価ライセンス発行サイトに登録しライセンスの発行を行う。

正常にライセンス発行がされるとライセンスファイル(XXXX_EUVSA_XXXX_18-Jun-2021.licといったファイル名)がダウンロードできる。

ダウンロードしたライセンスファイルをアップロードすることで、UnityVSAのライセンス登録は完了となる。

プール設定

1. UnityVSAの仮想マシンに仮想ディスクを追加

UnityVSAではデータを保存する領域を「プール」という単位で管理する。OVAファイル展開時に仮想ディスクが3つ接続されているが、これらはOSインストール領域であり、プールとしては利用できないため、VMware Host ClientやvSphere Clientなどから、新規ディスクを仮想マシンに接続する。

なお、仮想ディスクを接続すると自動でディスクを認識するため、UnityVSAの再起動等は不要となる。

2. プールを作成

左メニューにて「Pools」を選択し、「Pools」タブを選択する。「+」を押してファイルシステムを新規作成する。

以下に、プールを作成するための設定項目を記載する。

設定項目	説明
Name and Description	プールの名前を指定する。
Tier Assignment	UnityVSAに接続した仮想ディスクを選択し、「Storage Tier」を設定する。私の環境はSSDだったため、Performance Tierを選択した。
Tier	特に設定項目はないためスキップする。
Virtual Drives	特に設定項目はないためスキップする。
Capability Profile Name	特に設定項目はないためスキップする。

NFS設定

1. NFS Serverの作成

UnityVSAでは、NFSやCIFSを利用する際に、まずNAS Serverと呼ばれるファイル共有機能の作成が必要となる。

左メニューにて「File」を選択し、「NAS Server」タブを選択する。「+」を押してNAS Serverを新規作成する。

以下に、NAS ServerをNFSで利用するための設定項目を記載する。

設定項目	説明
General	NAS Serverの名前、プールを選択する。冗長化されたUnityを使う場合は、動作するコントローラ (SP ; Storage Processerという) を選択することができる。今回はシングル構成なのでSP Aを選択する。
Interface	NAS Serverが使用するインタフェースとIPアドレスを設定する。ここで設定したIPアドレスに対して、NFSやCIFSのファイル共有ができるようになる。
Sharing Protocols	「Enable NFSv4」を選択する。
Unix Directory Service	NISやLDAPによる認証を行う場合は設定するが、今回はスキップする。
DNS	NAS Serverに名前解決を行わせる場合は設定するが、今回は設定不要のためスキップする。
Replication	NFSやCIFS領域をレプリケーションする場合は、NAS Serverのレプリケーションの設定が必要となる。今回はレプリケーションの設定は不要のためスキップする。

2. ファイルシステム及びNFS領域の作成

左メニューにて「File」を選択し、「File Systems」タブを選択する。「+」を押してファイルシステムを新規作成する。ファイルシステムを作成する際に、NFSやCIFSの設定を行うことができる。

<図>

以下に、ファイルシステムをNFSで利用するための設定項目を記載する。

設定項目	説明
Protocol	「Linux/Unix Shares (NFS)」または「Windows Shares (SMB)」を選択する。今回はNFSとする。NAS Serverが複数ある場合は、紐づけるNAS Serverを選択する。
Name	ファイルシステムの名称を設定する。
FLR	FLRはFile Level Retentionのことであり、指定した期間を超えて保管されているファイルの変更や削除をできないよう、ロックを掛ける機能となる。今回は設定しないが、一度有効にすると無効化できないので注意すること。
Storage	プール及びサイズを選択する。最小サイズは3GBとなる。
Shares	NFSまたはCIFSを選択する。NFSの場合はNFSのエクスポート名を指定する。
Access	NFS領域にアクセスする設定を行う。デフォルト権限は「No Access」としてアクセス拒否をし、必要なホストのみに権限を付けるホワイトリスト方式による設定が定番だろう。
Snapshot	定期的にスナップショットを取得する場合は設定する。
Replication	今回はレプリケーションの設定は不要のためスキップする。

iSCSI設定

1. iSCSI用インタフェースの作成

iSCSIを利用する前に、まずはiSCSI用のインタフェースを作成する。左メニューにて「Block」を選択し、「iSCSI Interfaces」タブを選択する。「+」を押してインタフェースを新規作成する。

インタフェース作成は、割り当てるインタフェースとIPアドレスを設定する。IQNの名前に付与されるIQN Aliasは自動で設定されるので、特に問題なければそのままでよいだろう。

2. iSCSI用のLUNを作成

左メニューにて「Block」を選択し、「LUNs」タブを選択する。「+」を押してインタフェースを新規作成する。

以下に、LUN作成時の設定項目を記載する。

設定項目	説明
Configure	LUNの名称、保存先プール、サイズを設定する。最小サイズは1GBとなる。
Access	LUN領域にアクセスする設定を行う。今回は設定手順は割愛するが、「Hosts」メニューにて、iSCSIイニシエータのIQN情報を登録する必要がある。
Snapshot	定期的にスナップショットを取得する場合は設定する。
Replication	今回はレプリケーションの設定は不要のためスキップする。

まとめ

以上で、UnityVSAのESXi上へのインストールと初期設定の手順は完了となる。もう1台UnityVSAを作れば、UnityVSA間でレプリケーションを実装することもできる。VMware製品の各種機能(VASAやSRMなど)とも連携可能であり、エンタープライズ製品とほぼ同様の機能を無償で使えるため、非常に有用であると感じた。

firewalld入門

Red Hat Enterprise Linux 7 (以下、RHEL 7) 以降は、サーバのファイアウォール機能として、iptablesからfirewalldに変更になっている。iptablesの入門記事は、以前以下にて記載している。

• iptables入門

自宅の検証用途の場合は、firewalldの設定を省略することが多く、ずっと使うことを避けていたのだが、そろそろ一度使い方を確認してみようと思い、実際にfirewalldの設定手順を確認してみた。

環境

RHEL 7のfirewalldで動作確認を行ったが、CentOSなどのRed Hat系のディストリビューションであれば、操作方法は同じとなる。

なお、今回は入門編ということで、firewalldで着信トラフィックのみ通信許可する設定手順を記載しており、発信トラフィックの設定方法については別途記載することにする。また、ゾーンに関してもデフォルト設定を利用することとし、ゾーンの変更や新規作成は実施しない。

通信許可設定手順

1. firewalldサービスを起動

firewalldの設定を行う際は、firewalldサービスが起動している必要がある。もし停止している場合は、以下の通り起動させておく。

# systemctl enable firewalld
# systemctl start firewalld

2. 設定前確認

firewalldの設定はすべてfirewall-cmdにて実施する。

まずは、firewall-cmd --get-active-zonesでアクティブになっているゾーンを確認してみよう。以下結果は、インタフェースens192に対して、publicというゾーンが設定されていることを示している。

# firewall-cmd --get-active-zones
public
  interfaces: ens192

次に、アクティブになっているpublicゾーンの設定をfirewall-cmd --list-allで確認してみよう。以下コマンド実行結果のservicesの項目に着目すると、publicゾーンのデフォルトでは、SSH (22/tcp) とDHCPv6クライアント (546/tcp) のみ通信が許可されていることがわかる。

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: ssh dhcpv6-client
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

本記事では、publicゾーンに対して以下通信を許可するための設定手順を記載する。

• NTP (123/tcp, 123/udp)
• Zabbix Agent (10050/tcp)

3. 通信許可設定を追加 (サービス名を指定する場合)

サービス名を使ってルールを設定する場合は、firewall-cmd --add-service=[サービス名]にて行う。サービス名は/etc/servicesから名前を確認する。例えば、NTPのサービス名はntpとなり、123/tcpと123/udpがポート番号として定義されていることがわかる。

# cat /etc/services | grep '^ntp'
ntp             123/tcp
ntp             123/udp                         # Network Time Protocol

以上をふまえ、以下の通り設定投入を行う。

# firewall-cmd --add-service=ntp
success

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: ssh dhcpv6-client ntp　★<--ntpが追加
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

【補足】firewalldのランタイムルールとパーマネントルール

firewalldには「ランタイムルール」と「パーマネントルール」の2つがあり、これらの違いを理解しておく必要がある。

ルール	設定保持	設定コマンド	説明
ランタイムルール	×	firewall-cmd	実際に反映されているルール。スイッチ製品のrunning-configのイメージ。
パーマネントルール	○	firewall-cmd --permanent	保存されているルール。スイッチ製品のstartup-configのイメージ。

2つのルールがあることによって、firewalldは大きく以下2つの流れで設定できる。

1. ランタイムルール設定後、firewall-cmd --runtime-to-permanentにてパーマネントルールに反映
2. パーマネントルールに設定後、fiewall-cmd --reloadにてランタイムルールに反映

どちらの設定手順を採用するかについては、好み、流派、状況などによって変わると思うが、設定コマンドがシンプルかつ設定切り戻しが容易なことから、本記事では1つめの「ランタイムルール設定→パーマネントルールに反映」の手順を採用する。

4. 通信許可設定を追加 (ポート番号を指定する場合)

ポート番号ではなく、直接特定のポート番号を指定することも可能となる。今回は、Zabbix Agentで使用する10050/tcpのポートを例として設定することにする。

なお、Zabbix Agentはzabbix-agentとしてサービス名が定義されているので、サービス名による設定も可能となる。

# cat /etc/services | grep '^zabbix-agent'
zabbix-agent    10050/tcp               # Zabbix Agent
zabbix-agent    10050/udp               # Zabbix Agent

ポート番号を使ってルールを設定する場合は、firewall-cmd --add-port=[ポート番号]/[tcpまたはudp]にて行う。今回は、10050/tcpでポート番号を指定した。

# firewall-cmd --add-port=10050/tcp
success

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: ssh dhcpv6-client ntp
  ports: 10050/tcp　★<--ポート番号が追加
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

5. パーマネントルールに反映

ランタイムルールは、firewalldやOS再起動を行うと設定が消えてしまうため、ランタイムルールの設定をパーマネントルールに反映することによって設定の保存を行う必要がある。

逆に言えば、ランタイムルールの設定に問題があり設定を切り戻す場合は、fiewall-cmd --reloadにてパーマネントルールを再読み込みさせるだけでよい。

ランタイムルールをパーマネントルールに反映する前に、現在のパーマネントルールの確認をfirewall-cmd --permanent --list-allにて行う。設定反映前であるため、先ほどランタイムルールに設定したntpサービスやポート番号の設定が存在しないことがわかる。

# firewall-cmd --permanent --list-all
public
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: ssh dhcpv6-client
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

firewall-cmd --runtime-to-permanentにてパーマネントルールへ設定反映を行う。

# firewall-cmd --runtime-to-permanent
success

再度、パーマネントルールを確認すると、以下の通りランタイムルールに設定したルールが反映されていることがわかる。

# firewall-cmd --permanent --list-all
public
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: ssh dhcpv6-client ntp　★<--ntpが追加
  ports: 10050/tcp　★<--ポート番号が追加
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

以上で、firewalldの通信許可設定は完了となる。

firewalldコマンドまとめ

最後に本手順で記載したコマンドを一覧にまとめて記載する。

設定	コマンド
アクティブとなっているゾーンの確認	firewall-cmd --get-active-zones
ランタイムルールの確認	firewall-cmd --list-all
パーマネントルールの確認	firewall-cmd --permanent --list-all
パーマネントルールに反映	firewall-cmd --runtime-to-permanent
パーマネントルールの再読み込み	fiewall-cmd --reload
ルール追加 (サービス名)	firewall-cmd --add-service=[サービス名]
ルール追加 (ポート番号)	firewall-cmd --add-port=[ポート番号]/[tcpまたはudp]
ルール削除 (サービス名)	firewall-cmd --remove-service=[サービス名]
ルール削除 (ポート番号)	firewall-cmd --remove-port=[ポート番号]/[tcpまたはudp]

SquidのSSL Bumpを使ってHTTPS (SSL) 通信を可視化する

近年はセキュリティの観点から、Web通信はHTTPではなくHTTPS (HTTP over SSL/TLS) が利用されることが多い。HTTPSはブラウザとWebサーバ間の通信が暗号化されるため、当然ではあるが、通信の詳細な情報を第三者が確認することはできない。

しかし、近年はフィッシング詐欺などの悪意のあるサイトであっても、SSLサーバ証明書を導入しHTTPS通信とすることで、一見問題がないようなサイトと偽装することも多くなっている。そのような危険な通信を可視化することためには、一度HTTPSの通信を復号し、セキュリティチェックを実施したうえで、再度暗号化することが定番の手法となっている。

復号した通信であれば、通信ログをSIEMなどのログ管理・分析ツールに連携したり、サンドボックスなどで通信先サイトへアクセスした際の振る舞い検知などが実施でき、セキュリティの強化が可能となる。
※ただし、復号化と暗号化処理が増えることから、専用のネットワーク機器ではない場合はスループットが極端に落ちるため、導入時は注意すること。

プロキシサーバとして昔から利用されるOSS製品である「Squid」においても、「SSL Bump」と呼ばれる機能にて実装が可能である。

本記事では、SquidのSSL Bumpを有効化し、HTTPS (SSL) 通信を可視化する手順を記載する。

環境

• OS : CentOS 8.2
• Squid : Squid 4.4

手順

1. SSL Bump用の秘密鍵とサーバ証明書の作成

SSL Bumpでは、Squidが都度SSL証明書を発行することで、クライアントのSSL通信をSquidで終端する。このクライアント⇔Squid間で実施するSSL通信の鍵交換の際に使用する鍵情報となる「Diffie-Hellmanパラメータ (DHパラメータ)」を事前に作成する。

DHパラメータはopensslコマンドにて生成でき、処理に数分を要する。ファイル名はbump_dhparam.pemとして作成する。

# cd /etc/squid/
# openssl dhparam -outform PEM -out bump_dhparam.pem 2048
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
.........................................

～(以下略)～

次に、SSL通信の際に使用するSSLサーバ証明書の秘密鍵と公開鍵のペアを作成する。秘密鍵のファイル名はbump.key、公開鍵のファイル名はbump.crtとし、opensslコマンドで作成を行う。

# cd /etc/squid/
# openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -keyout bump.key -out bump.crt
Generating a RSA private key
.............................................+++++
....+++++
writing new private key to 'bump.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:JP　←★JPを指定
State or Province Name (full name) []:Tokyo　←★任意で指定
Locality Name (eg, city) [Default City]:　←★そのままエンター
Organization Name (eg, company) [Default Company Ltd]:　←★そのままエンター
Organizational Unit Name (eg, section) []:　←★そのままエンター
Common Name (eg, your name or your server's hostname) []:Squid Private CA　←★任意。今回は「Squid Private CA」とした
Email Address []:　←★そのままエンター

2. SSL証明書保管用DBの作成

前述した通りSSL Bumpでは、SquidがクライアントとSSL通信するため、都度SSLサーバ証明書を発行する。作成した証明書情報を補完するためのDBを作成する。

# mkdir -p /var/lib/squid
# rm -rf /var/lib/squid/ssl_db

# /usr/lib64/squid/security_file_certgen -c -s /var/lib/squid/ssl_db -M 20MB
Initialization SSL db...
Done

# chown -R squid:squid /var/lib/squid
# ls -l /var/lib/squid/
合計 0
drwxr-xr-x 3 squid squid 48  7月 29 19:54 ssl_db

3. squid.confに設定追加 (追加内容の説明)

SSL Bumpを有効化するためsquid.confに設定を追加する。設定箇所自体は多くないものの見慣れない設定が多いため、以下に簡単な説明を記載していく。

ただし、細かい設定内容は未調査となるため、必要に応じて、Squidの公式サイトを参照するようお願いしたい。

• squid : Optimising Web Delivery

sslcrtd_program、sslproxy_cert_error及びssl_bump

SSL Bump特有の以下設定を追加する。

sslcrtd_program /usr/lib64/squid/security_file_certgen -s /var/lib/squid/ssl_db -M 20MB
sslproxy_cert_error allow all
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all

設定内容は以下の通りとはなるが、詳細は以下を確認いただきたい。

• Squid 4.16 Configuration File: sslcrtd_program
• Squid 4.16 Configuration File: sslproxy_cert_error
• Squid 4.16 Configuration File: ssl_bump

設定値	説明
sslcrtd_program行	証明書作成のコマンドを指定。-sオプションでSSL保管先のDBを指定する。-MオプションでDBに保管するSSL証明書の最大サイズを指定する。
sslproxy_cert_error allow all	証明書の検証にてエラーがあってもすべて許可する。
acl step1 at_step SslBump1 ssl_bump peek step1 ssl_bump bump all	SSL Bumpのアクションをstep1についてpeekとし、それ以外のstep2、step3についてはbumpに設定する。詳細は公式サイトを参照すること。

http_port

通常のhttp_portはSquidの待ち受けポート番号を指定するのみだが、SSL Bumpの場合は以下のように多数の設定を行う。

http_port 8080 tcpkeepalive=60,30,3 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB tls-cert=/etc/squid/bump.crt tls-key=/etc/squid/bump.key cipher=HIGH:MEDIUM:!LOW:!RC4:!SEED:!IDEA:!3DES:!MD5:!EXP:!PSK:!DSS options=NO_TLSv1,NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE tls-dh=prime256v1:/etc/squid/bump_dhparam.pem

各設定値の説明を以下に記載する。詳細は以下公式サイトを確認いただきたい。

• Squid 4.16 Configuration File: http_port

設定値	説明
http_port 8080	Squidの待ち受けポートを8080番に設定。
tcpkeepalive=60,30,3	通信がアイドルとなった際のキープアライブの設定。左から順に、アイドルとみなす経過時間(秒)、アイドル中の監視間隔(秒)、タイムアウトとみなす回数(秒)となる。今回の設定の場合は、60秒経過後から30秒 x 3回通信が確認できなかった場合、通信の切断を行う。
ssl-bump	SSL Bumpを使用する。これによりクライアントから受信したHTTPS通信が一度復号化される。
generate-host-certificates=on	SSLサーバー証明書を動的に作成する。
dynamic_cert_mem_cache_size=20MB	証明書作成時に使用するキャッシュのサイズ。デフォルト4MB。
tls-cert=/etc/squid/bump.crt	SSLサーバ証明書のパスを指定。
tls-key=/etc/squid/bump.key	SSLサーバ証明書の秘密鍵のパスを指定。
cipher=HIGH:MEDIUM:!LOW:!RC4:!SEED:!IDEA:!3DES:!MD5:!EXP:!PSK:!DSS	暗号化スイートの設定。
options=NO_TLSv1,NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE	オプションの設定。TLSv1禁止、SSLv3禁止、一時的なDHキーの使用をするためオプションを記載。
tls-dh=prime256v1:/etc/squid/bump_dhparam.pem	先ほど作成したDHパラメータファイルを指定。

4. squid.confに設定追加 (実際の設定内容)

最終的にsquid.confは以下の通りとなった。

# ACLs
acl localnet src 192.168.33.0/24
acl localnet src 192.168.11.0/24

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT

# SSL Bump
sslcrtd_program /usr/lib64/squid/security_file_certgen -s /var/lib/squid/ssl_db -M 20MB
sslproxy_cert_error allow all
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all

# Access rules
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

http_access allow localhost manager
http_access deny manager

http_access allow localnet
http_access allow localhost
http_access deny all

# Squid Access Pport
http_port 8080 tcpkeepalive=60,30,3 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB tls-cert=/etc/squid/bump.crt tls-key=/etc/squid/bump.key cipher=HIGH:MEDIUM:!LOW:!RC4:!SEED:!IDEA:!3DES:!MD5:!EXP:!PSK:!DSS options=NO_TLSv1,NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE tls-dh=prime256v1:/etc/squid/bump_dhparam.pem

# Cache directory
cache_dir ufs /var/spool/squid 100 16 256

# Core dump directory
coredump_dir /var/spool/squid

# Cache settings
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320

上記を反映させるため、Squidを再起動する。

# systemctl restart squid

5. OSに証明書の登録

Windowsクライアントを例として、証明書の登録手順を記載する。

先ほど作成したSquidの証明書となるbump.crtをエクスポートして、インポート対象のOSに配置する。

「ファイル名を指定して実行」→「certlm.msc」を実行し、証明書の管理画面を表示させる。

「信頼されたルート証明機関」を右クリックし、「すべてのタスク」→「インポート」を選択する。

「証明書のインポートウィザード」が表示されるため、以下の通り設定する。

設定項目	設定値
証明書のインポートウィザードの開始	そのまま次へ
インストールする証明書ファイル	bump.crtを選択
証明書ストア	「信頼されたルート証明機関」を選択

動作確認

まず、SSL Bump設定前のSquidのaccess.logを確認すると、見ての通りCONNECTメソッドのログしか表示されない。

1627814980.824    394 192.168.11.240 TCP_TUNNEL/200 556 CONNECT cas.criteo.com:443 - HIER_DIRECT/182.161.74.15 -
1627814981.360    928 192.168.11.240 TCP_TUNNEL/200 339 CONNECT quriosity.yahoo.co.jp:443 - HIER_DIRECT/183.79.219.252 -
1627814981.360   1114 192.168.11.240 TCP_TUNNEL/200 339 CONNECT yads.c.yimg.jp:443 - HIER_DIRECT/182.22.31.124 -
1627814981.634  47616 192.168.11.240 TCP_TUNNEL/200 339 CONNECT ybx-test.yahoo.co.jp:443 - HIER_DIRECT/183.79.248.124 -
1627814981.657    318 192.168.11.240 TCP_TUNNEL/200 8737 CONNECT nav.smartscreen.microsoft.com:443 - HIER_DIRECT/13.67.52.249 -
1627814986.983  60014 192.168.11.240 TCP_TUNNEL/200 39 CONNECT static.criteo.net:443 - HIER_DIRECT/182.161.74.1 -
1627814989.985  60514 192.168.11.240 TCP_TUNNEL/200 39 CONNECT gum.criteo.com:443 - HIER_DIRECT/182.161.74.11 -

SSL Bump設定後のログでは、以下の通りGETやPOSTのログが表示される。
※ログは見やすくするために少し重複情報をを間引いて記載している。

1627815054.587     30 192.168.11.240 NONE/200 0 CONNECT dsb.yahoo.co.jp:443 - HIER_DIRECT/183.79.219.252 -
1627815054.604     24 192.168.11.240 NONE/200 0 CONNECT www.yahoo.co.jp:443 - HIER_DIRECT/182.22.25.124 -
1627815054.611     31 192.168.11.240 NONE/200 0 CONNECT s.yimg.jp:443 - HIER_DIRECT/183.79.249.124 -
1627815054.615     35 192.168.11.240 NONE/200 0 CONNECT yads.c.yimg.jp:443 - HIER_DIRECT/183.79.219.124 -
1627815054.623     28 192.168.11.240 TCP_MISS/202 471 POST https://dsb.yahoo.co.jp/api/v1/stream - HIER_DIRECT/183.79.219.252 application/json
1627815054.636     56 192.168.11.240 NONE/200 0 CONNECT adservice.google.co.jp:443 - HIER_DIRECT/2404:6800:4004:818::2002 -
1627815054.639     59 192.168.11.240 NONE/200 0 CONNECT adservice.google.com:443 - HIER_DIRECT/2404:6800:4004:81e::2002 -
1627815054.653     27 192.168.11.240 TCP_MISS/202 471 POST https://dsb.yahoo.co.jp/api/v1/stream - HIER_DIRECT/183.79.219.252 application/json
1627815054.743    133 192.168.11.240 TCP_MISS/200 63418 GET https://www.yahoo.co.jp/ - HIER_DIRECT/182.22.25.124 text/html
1627815054.806     10 192.168.11.240 TCP_MISS/304 293 GET https://s.yimg.jp/images/weather/general/next/256_day.png - HIER_DIRECT/183.79.249.124 -
1627815054.819     10 192.168.11.240 TCP_MISS/304 293 GET https://s.yimg.jp/images/shp_edit/other/fc/other/Edit/21081_660_200.jpg - HIER_DIRECT/183.79.249.124 -

また、SSL Bump有効時は一見通常のWebアクセスと同様にHTTPS通信ができているように見え、アドレスバーの鍵マークも正常に表示される。ただし、鍵マークをクリックしてSSLサーバ証明書の詳細情報を確認すると、Squidの自己署名証明書である「Squid Private CA」となっていることがわかる。

以上でSquidによるSSL Bumpの設定は完了となる。

参考

• Squid サービスでの SSL Bump の設定
• 自己署名 SSL 証明書の作成
• squid : Optimising Web Delivery

ZabbixのHousekeepingの仕組みと手動による実行手順

Zabbixでは保存期間を超過したアイテムのヒストリ・トレンドや障害イベントなどのデータを定期的に自動で削除する機能が備わっており、この処理をHousekeepingと呼ぶ。

本記事では、ZabbixのHousekeepingの動作に関する調査結果と、手動でHousekeepingを実行する手順について記載する。

環境

• OS : CentOS 8.1
• Zabbix : 5.0.8

Housekeepingの実行間隔と1回あたりの削除の上限数

Housekeepingに関するパラメータは/etc/zabbix/zabbix_server.confに以下の2つが存在する。

①HousekeepingFrequency

HousekeepingFrequencyは、Housekeepingの実行間隔となる。0は定期実行の無効化となり、1～24時間の間で設定が可能となる。通常はデフォルト値となる1時間毎の設定で問題ないだろう。

HousekeepingFrequency=1

②MaxHousekeeperDelete

MaxHousekeeperDeleteは、各ヒストリやイベント単位で設けられる削除データ数の上限数となる。0に設定すると無制限で対象となるすべてのデータの削除を行う。デフォルトは5,000件で設定されており、たとえ1秒間隔でデータ取得を行うアイテムがあったとしても1時間あたり3,600件となることから、削除が追い付く計算となる。

MaxHousekeeperDelete=5000

もし、1時間で5,000件以上の大量のアイテムなどのデータが登録されるような環境ではHousekeepingの処理が追い付かないため、本設定のチューニング (最大1,000,000件まで設定可能) をする必要がある。

Housekeepingはデータを徐々に削除する

ZabbixのHousekeepingは、削除対象のデータを徐々に削除する仕様となっており、削除処理に伴うデータベースへの負荷を抑えるよう動作する。具体的には、削除対象のデータの最も古いデータの時間からHousekeepingFrequencyの時間の4倍の時間 (1時間毎であれば4時間) に存在するデータを削除対象とする。

定期的にHousekeepingを実行している場合は、本処理を意識する必要はないが、データの保存期間を途中で短くした場合には、データが一度では削除されず徐々に消される動作となるため注意が必要となる。

なお、データの保存期間の設定は、ZabbixのGUIにて「管理」→「一般設定」→「データの保存期間」にて設定が可能となる。

このHousekeepingの動作については、以下サイトで詳細に解説されている。

• 緩やかなhousekeeping【MIRACLE ZBX 2.2】 — サイバートラスト株式会社

Housekeepingを手動で実行する

このようにHousekeepingが徐々に削除される仕様があるが、場合によっては時間を待たずにデータを消したい場合がある。そのような場合は、コマンドにて直接Housekeepingを実行すればい。

# zabbix_server -R housekeeper_execute
zabbix_server [9056]: command sent successfully

実行結果は、/var/log/zabbix/zabbix_server.logに出力される。手動実行の場合のみforced execution of the housekeeperというメッセージが表示される。

# tail -10 /var/log/zabbix/zabbix_server.log | grep house
  1816:20210216:200333.918 executing housekeeper
  1816:20210216:200335.168 housekeeper [deleted 64354 hist/trends, 0 items/triggers, 0 events, 0 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 1.248852 sec, idle for 1 hour(s)]
  1816:20210216:201236.878 forced execution of the housekeeper
  1816:20210216:201236.878 executing housekeeper
  1816:20210216:201237.695 housekeeper [deleted 9750 hist/trends, 0 items/triggers, 0 events, 0 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 0.816834 sec, idle for 1 hour(s)]

1回実行しただけでは、最も古いデータから4時間分しか削除されないため、for文を使って繰り返し実行させる。例えば、以下は600回のHousekeepingを実行し、少なくとも100日分のデータ (4時間 x 600回 = 100日) を削除する例となる。なお、以下コマンドでは負荷を抑えるため、sleepによる実行間隔の調整を実施している (以下のコマンドでは0.5秒で設定している)。

# for i in {1..600}; do zabbix_server -R housekeeper_execute > /dev/null 2>&1; sleep 0.5; done

参考

• 1 Zabbix server [Zabbix Documentation 5.0]