OpenSSH の脆弱性について

こんにちは、クラウドエースの SRE チームに所属している妹尾です。
今回は OpenSSH の脆弱性についての記事です。

(この記事は 7/4 に速報版から正式版へ更新しました)

2024/07/02 に、CVE-2024-6387が発表されました。
これは放置しておくと SSH を受け付ける全てのサーバーを乗っ取る事ができてしまう脆弱性です。
厄介なことにデフォルト設定の SSH-Server と、ある程度の時間があればサーバーを乗っ取れてしまうので、緊急度もかなり高めになっております。
そして Compute Engine もこの影響を受ける ので、多くの環境で対策が必要となります。

結局どうすればいいの

Google が公表している、 GCP-2024-040 の手順に従いましょう。
(日本語訳ページだとまだ公表されてないようですので、英語版を見てください)

具体的には、以下のような対策になります。

Linux ディストリビューションのアップデートを適用する (オススメ)

一番確実、かつ簡単な方法です。
RHEL 系(CentOS, Rocky Linux 等) なら dnf upgrade -y openssh-server
Debian 系(Debian, Ubuntu 等)なら apt update; apt-get upgrade -y openssh-server
のようなコマンドになるはずです。

対策バージョンが提供されているか、どのバージョンが対策済みかはディストリビューションによって異なりますので
各ディストリビューションのページを参照しましょう。
例 : Ubuntu / RHEL / Debian

COS(Container-Optimized OS) を使っている場合は、実行イメージを更新しましょう。
cos-113-18244-85-49 cos-109-17800-218-69 cos-105-17412-370-67 cos-101-17162-463-55 かそれ以上であれば OK です。

default-allow-ssh ファイアウォール ルールを削除する (オススメその2)

普段から意識されている方は問題ないのですが、デフォルト設定のまま Google Cloud を使っている場合は 全世界からの SSH (22番ポート) を許可するよう構成 されています。
アクセス元がはっきりしているのであれば、アクセス元のグローバル IP アドレスを調べてそこだけ許可すればこのような攻撃はほとんどシャットアウトできます。
日常的にこのような構成が取れるようになれば、サーバーへの攻撃頻度はグッと減りますのでオススメです。

攻撃を緩和できるよう sshd を構成する

どうしても SSH のルールが縛れない場合は、先ほど記載した Google の記事に対策スクリプトがあります。
これを実行することで、攻撃成立までの時間稼ぎができます。
完全なシャットアウトでない事を理解しつつ、適用していきましょう。

OpenSSH Server を無効化する (非推奨)

まず SSH-Server が不必要であれば無効化してしまう手もあります。
ただし一度無効にすると SSH できなくなって、再度有効にする手段が限られてしまいます。 (インスタンスのスナップショットを取っておいて有効化したい時に戻すなど)
管理の側面でなんだかんだ必要になる可能性も高いので、消す時は慎重に……

脆弱性について

今回話題になった CVE-2024-6387 の CVSS スコアは 8.1 でした。
CVE とは脆弱性の対策をするために、その情報を全世界で共有するプロジェクトで、
CVSS は脆弱性の危険度を数値化して示す国際基準です
0.0 が安全 10.0 が危険の 100 段階で、一般的に 7.0 以上は危険 9.0 を超えたら緊急という認識が多いです。
(つまり今回の脆弱性はかなり危険ということがわかりますね)

脆弱性は日々発見されていて Google Cloud だけでなく、 AWS や Azure 、 Ubuntu や RHEL などの Linux ディストリビューションの他
Windows や Mac に影響するものも存在しています。

コンピューターがプログラムで動いていて、そのプログラムが人が作っている以上、
どうやってもバグは存在するので、これらと上手く付き合っていく必要があります。

普段から供えるのが吉

今回のような脆弱性は、情報が出た事には既に攻撃されているといったケースが少なくありません。
重要なのはそのバグにいち早く気付いて対策をすることで、これに完全に対応するには日頃からセキュリティ意識を持った運用が必要です。

Google Cloud 上でできる、より具体的な方法を紹介します。

ネットワーク経路や権限の最小化

少々手間はかかりますが、一番強力に保護できる方法です。

• ファイアウォールで通信経路を限定する / IAP での認証を噛ませる

  通信経路は、必要である場所だけオープンにするのが望ましいです。
  まずデフォルトで存在している default ネットワークは可能なら削除してしまい、新規でネットワークを定義するのをオススメします。
  先ほど紹介したように全世界から SSH や RDP できるようなルールが採用されているほか、不要なサブネットワークが定義されていることが多いです。
  (既に使っているサービスがないかよく確認しましょう)

  新規でネットワークを作成したら、 SSH や HTTP(S) の通信が必要なアドレスにのみファイアウォールを設定して許可しましょう。
  Google Cloud ネットワーク内通信であれば、タグやサービス アカウントに紐付いたファイアウォール ルールを設定するのがオススメです。

  また、 IAP TCP forwarding を利用することで、グローバル IP アドレスを付与せずに SSH や RDP をする事も可能です。
  ファイアウォール ルールで許可するよりこちらの方が防御力に優れますので、可能なら積極的に利用すべきです。

  VPC からインターネットへの外向き通信は、 NAT を利用することでよりセキュアに通信が可能です。

• サービス アカウントを積極的に発行して必要最低限の IAM 権限を振り分ける

  インスタンス 1 種類につき 1 つのサービス アカウントを作成して、そのンスタンスからアクセスするリソースにのみ権限を付与しましょう。
  これで意図しないリソースへの操作をブロックできます。
  職務の分離、最小権限の原則という名前でも知られています。

  ここでいう インスタンス 1 種類 とは、同じ仕事をするインスタンスのことを指します。例えば、インスタンス グループにはそのグループ毎にサービス アカウントがあるとベストです。

  インスタンスだけでなく、 Kubernetes や Cloud Build 等のマネージド サービスも同様に構成するとより良いでしょう。

定期的なアップデート

これは Google Cloud のみならず、他のクラウドサービスからローカル環境まで全てに言えます。

自動でできるのが一番なので、例えば Linux であれば cron に登録するなどして積極的にアップデートしていきたいところです。

マネージド サービスを利用することも有力です。
Cloud Run や App Engine を利用すれば自動的にアップデートを適用くれますので、対応に当てる労力がグッと減ります。
Compute Engine でも VM Manager のパッチ機能を活用することで、プロジェクトもしくは組織単位で更新を管理できます。

また別の問題にはなりますが、 terraform や npm 等で利用しているモジュールのバージョンについても積極的なアップデートが望まれます。
アップデートによる非互換の問題は、現代においてはセマンティック バージョニングがほぼ解決してくれています。
各ツールのアップデート ポリシーも確認しつつ、柔軟性のあるバージョン指定をしましょう。

脆弱性についての通知を受け取れるようにする

全エンジニアがここまでやる必要はないですが、もし興味があったらやってみることをオススメします。

CVE 公式サイトを定期的にチェックするのも良いですが、有志がRSSフィードを作ってくれているので、これを活用するのも良いでしょう。

利用しているプロダクトが、独自でセキュリティに関するフィードやページを公開していることもあります。一度探してみることをオススメします。
例えば Kubernetes Engine (GKE) は、リリースノートの中にセキュリティに関する情報が含まれています。

もしインパクトがある脆弱性が見つかったら、チームやお客様へ共有して対策のきっかけにしてみましょう。

日々継続すること

何より重要なのは、これらの取り組みを継続することです。
そして継続してやらなければならないことは、積極的に仕組み化してしまうのが一番です。

上記に上げた対策を仕組みや運用として取り込んでいくことが一番の対策であり、正常運用への重要なポイントです。

まとめ

最近、大企業がセキュリティの問題で大きな被害を被っている事例もあります。
"ぎゃふん"と言わないためにも、ちょっとずつセキュリティに向き合う時間を増していけると良いですね。