IBM Cloud VSIのCentOSイメージを確認する

#### 1.経緯
　IBM cloud上で簡単な研修用の環境を用意するにあたり、久々にIBM cloud (VPC)でIaaSのVSIを使ったのですが、2015年ごろのクラシックネットワーク環境から細々と作法が異なった点、OSハードニング項目の主要な確認点など、備忘録として残しておきます。(2022/11/末時点の情報です。)
　
#### 2.利用環境
 - IBM Cloud (VPCネットワーク)
 - Cent OS 7.9 (ibm-centos-7-9-minimal-amd64-7 というストックイメージです。)

#### 3.IBM Cloud提供のOSイメージ
　昔のIaaSでは、各ディストリビューションのプレーンなイメージを選択して、細かいユーザ設定やSSH設定などのハードニングはインストール後に個別に実行していた記憶でしたが、最近はクラウドベンダー提供のイメージやcloud-initが利用され、より汎用的にIaaSを構成しやすくなっている印象です。
- クラウドベンダー提供イメージ
    - [参考：ibmcloud ストック・イメージ](https://cloud.ibm.com/docs/vpc?topic=vpc-about-images)
    - OS設計者がまず真っ先に設定するSSHやNTP設定など、基本的なところが設定してありました。ちまちま個別にコマンドで設定したり、シェルを準備していたようなところが既に設定されているイメージ。
    - 商用設計向けにはポート番号などちゃんと確認は必要かと思いますが、デフォルトでインストールされていないであろうモジュールなどがあらかじめ入っている点に注意。今までちゃんと伝統的に共通手順やシェルで自動化していたような場合は、逆に<b><i>何が設定されていて何が設定されていないのかを確認することがまず必要</i></b>になるかと思いました。

##### 3-1.管理user
　オーダー時にコンソールで登録する公開鍵によって、vpcuserとrootの公開鍵が設定される。

##### 3-2.SSH
　ストックイメージの起動時にはsshdは稼働しており、主な項目は以下の設定になっています。
- パスワード認証は禁止
    - PasswordAuthentication no
    - ChallengeResponse no
- SSHポートは22
- ROOT SSHは許可
[参考： sshd_configの設定項目の理解を目指す](https://unskilled.site/sshd_config%E3%81%AE%E8%A8%AD%E5%AE%9A%E9%A0%85%E7%9B%AE%E3%81%AE%E7%90%86%E8%A7%A3%E3%82%92%E7%9B%AE%E6%8C%87%E3%81%99/)
[参考：sshd_config に RSAAuthentication no を設定する必要はもうない](https://qiita.com/mogya/items/7f4a765a22e7e881dae5)

##### 3-3./etc/shadow
　起動時の状態は以下のようになっています。
- rootパスワードは未設定 (第二フィールドが`*`)
- cloud-initで作成する一般userと、初期に作成されるvpcuserも特に指定しなければパスワード未設定(第二フィールドが`!!`)
- [参考:Linux豆知識 180「/etc/shadow」ファイル](https://linuc.org/study/knowledge/510/)


##### 3-4.PAM関連 (ユーザーアカウントロック、期限)
　起動時　PAMは有効です。
```
$ sudo cat /etc/ssh/sshd_config | grep PAM
（略)
# WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several
UsePAM yes
```
password-authはデフォルトで以下の設定。3回ログイン失敗まで設定されていました。
 (sshログインが対象なのでコンソールログインは対象外,rootも対象外)

```
$ cat password-auth | grep fail
auth        required      pam_faildelay.so delay=2000000
auth        required      pam_faillock.so preauth silent fail_interval=900 unlock_time=0 deny=3
auth        [default=die] pam_faillock.so authfail fail_interval=900 unlock_time=0 deny=3
account     required      pam_faillock.so
```

※コンソールからのログイン失敗についてもアカウントのロックを行いたい場合は`/etc/pam.d/system-auth`にも、同様の設定を行う必要があります。



password有効期限は90日
```
$ sudo cat /etc/login.defs | grep DAYS
# PASS_MAX_DAYS     90
# PASS_MIN_DAYS Minimum number of days allowed between password changes.
PASS_MAX_DAYS     90
PASS_MIN_DAYS 0
```
rootのパスワード変更設定
```
$ sudo chage -l root
Last password change : 11月 11, 2022
Password expires : never
Password inactive : never
Account expires : never
Minimum number of days between password change : 0
Maximum number of days between password change : 99999
Number of days of warning before password expires : 7
```
一般ユーザのパスワード変更設定
```
$ sudo chage -l use1
Last password change : 11月 10, 2022
Password expires :  2月 08, 2023
Password inactive : never
Account expires : never
Minimum number of days between password change : 0
Maximum number of days between password change : 90
Number of days of warning before password expires : 7
```
:::note info
ログイン認証失敗時の解除設定について
faillock 解除方法
```
$ sudo faillock --user xx --reset
```
現在のfaillock状況確認方法
```
$ sudo faillock
user1:
When                Type  Source                                           Valid
root:
When                Type  Source                                           Valid
vpcuser:
When                Type  Source                                           Valid
```
:::

:::note warn
通常rootでの直接のsshは禁止すると思うので、`PermitRootLogin no` を設定すると思いますが、一般ユーザーパスワードは90日設定になっているため、放置しておくとssh時に存在しないパスワード変更を要求されて、ログイン可能なユーザが何もない詰み状態になる可能性があります。
90日以上の運用を予定しているサーバーについては、コンソールでのrootアクセスが可能であることなど、一般ユーザーのアカウントをメンテできるような仕組みを考えておく必要がありそうです。
:::
##### 3-5.ntp
　　デフォルトで稼働済。ibmcloudのドキュメントによると、NTPサーバーは以下です。
`
NTP サーバーは、time.adn.networklayer.com で利用できます。これは、161.26.0.6 に解決されます。`
　[参考： NTPに変わるChronyって何が変わったの？](https://qiita.com/legitwhiz/items/5b2d56ce9a0ee29a24f9)
　[参考: ibmcloud NTPサーバー](https://cloud.ibm.com/docs/vpc?topic=vpc-service-endpoints-for-vpc&locale=ja#network-time-protocol-ntp-servers)
```
$ sudo systemctl status chronyd
● chronyd.service - NTP client/server
   Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
   Active: active (running) since 木 2022-11-10 23:34:07 JST; 21h ago
     Docs: man:chronyd(8)
           man:chrony.conf(5)
 Main PID: 656 (chronyd)
   CGroup: /system.slice/chronyd.service
           └─656 /usr/sbin/chronyd

11月 10 23:34:07 localhost.localdomain systemd[1]: Starting NTP client/server...
11月 10 23:34:07 localhost.localdomain chronyd[656]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 +DEBUG)
11月 10 23:34:07 localhost.localdomain chronyd[656]: Frequency 3.815 +/- 23.504 ppm read from /var/lib/chrony/drift
11月 10 23:34:07 localhost.localdomain systemd[1]: Started NTP client/server.
11月 10 23:34:13 ciintbast02 chronyd[656]: Selected source 161.26.0.6
11月 10 23:36:37 ciintbast02 chronyd[656]: Source 52.148.114.188 replaced with 172.104.34.44
```

#### 4.その他VPCでのVSI作成における作法について
- cloud-init (ユーザー・データ)
    - 参考:[ibmcloud ユーザー・データ](https://cloud.ibm.com/docs/vpc?topic=vpc-user-data)
    - 参考:[cloud-initを使ったLinux OSの初期設定](https://qiita.com/yamada-hakase/items/40fa2cbb5ed669aaa85b)
    - IaaSの注文時点で、OS個別に作成する予定のユーザ情報や、OSの上で稼働する予定のnginxモジュールなどの設定情報を登録しておくことによって、注文後のデプロイ時に、該当の設定を自動で適応するというもの。
    - 雰囲気としては、<b><i>コンテナでいうところのDockerfileによく似ている</i></b>。(ベースコンテナに自動追加する設定をするのではなく、ベースOSに自動追加する設定をしている感覚)
    - 　負荷分散で稼働する複数台のアプリサーバーなど、同じ設定のサーバーを複数用意するだとか、開発用/テスト用/本番用など、ほぼ同じ設定で環境変数が違うサーバーを作成する際に、ベースとなるcloud-initの設定ファイルから作成すると、diffもしやすく便利そう。
    - 　ちなみに、検証として手持ちの設定が簡単にできるか試してみたところ、便利ではあるものの、初回の設定ファイル作成時の検証にまぁまぁ手間がかかる印象でした。なぜなら<b><i>毎回OSを再構築しなければならないので、設定ファイルのテストに時間がかかる</i></b>。さらにインデントやスペースなど気づきにくい誤記で思った通りの動作にならないなど、<b><i>設定更新にはかなり慎重になる必要がある</i></b>のではと感じました。
    - 　とはいえ仕組み自体は活用できれば何十何百の大量のOSをクラウド運用する現場では重宝すると考えられます。
    - 　[参考： 対応環境](https://cloudinit.readthedocs.io/en/latest/topics/availability.html)
    - 　[参考：cloud-config設定例](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups)

- 浮動IP
    - クラシックネットワークや、オンプレでのネットワーク設計に馴染んできた人であれば、インターネット用の公開アドレスを利用するには、ネットワークインターフェース(ethX)をインターネット用・内部アドレス用で２つ定義しなければならないのではと勘違いしていまいそうになるのですが、VPCの場合、デバイス定義は1つ(eth0)だけでよく、外部からアクセス可能にするための２つ目のIPは浮動IPとしてeth0に付与することになります(エイリアスのようなもの)。
    - OS側でethXやらルーティングテーブルやらを設定しなくて良く、コンソールで後から付け外しできるので、セキュリティ設定を完了した後にインターネットアクセスを許可する(浮動IPを付与する)、などの段取りもやりやすくなったように感じました。
    - なお、VSIからのアウトバウンド通信だけしかなく、インターネットアドレスを不要とする場合は浮動IPではなくパブリック・ゲートウェイを利用するとのこと。[(参考:ibmcloud 外部接続)](https://cloud.ibm.com/docs/vpc?topic=vpc-about-networking-for-vpc&interface=ui#external-connectivity)
    - また、VPC内で複数サブネットを利用する場合、eth1以降の複数ネットワークデバイス定義もできるものの、オーダーしたVSIのプロファイルの種類によって、追加できるネットワークインターフェースの数に制約があるそうです。[(参考:ibmcloud ネットワーク・インターフェースについて)](https://cloud.ibm.com/docs/vpc?topic=vpc-using-instance-vnics&interface=ui#about-network-interfaces)

#### 5.おわりに (所感)
　Linuxが地味に進化していて、systemctl周りのモジュールが変わっていたり、を調べるのにやはり時間がかかりました。クラウドもどんどん仕様が変わっていくものと思うので、油断ができない・・・。