Alibaba Cloud Security Center #23 Routine work

今週、仕事にかまけていたら Secure Score が 85 まで低下していました。　セキュリティ事故が起きる前に Security Center からどのようなリスクがあるのか確認し、Security Center から提供される対処方法を実施していきます。

Security Risks の確認

まずはどのようなリスクがあるのか確認します。大きく3つのリスクがあることがわかります。　1つ目は脆弱性 (Unchecked Urgent Vulnerabilities)、2つ目は Alibaba Cloud のプロダクトの設定に関するリスク(Config Assessment Risks)、3つ目は Attacks ということで外部からの攻撃のようです。

Attacks への対応

脆弱性の対応はこれまで何度も紹介しているので割愛します。　まずは Attacks から確認していきます。

ECS インスタンス（Ubuntu) への SSH Brute force です。　基本的には Blocked のステータスなので実害はありません。

SSH Brute force は 2/27 頃から始まっていますが、このタイミングでこのブログをホストする Web サーバの前段に Alibaba Cloud Server Load Balancer を追加しました。　Server Load Balancer を追加したことで Server Load Balancer が公開している Public IP への SSH 接続が今回検知された可能性があります。　可能性としたのは、Server Load Balancer の Listener としては 80 と 443 の TCP port しか Listen していないためです。　

対策として Server Load Balancer の設定を進めます。 Access Control を設定します。

ただ、 Server Load Balancer の ACL は IP Address の定義と Listener の紐付けとなり、今回やりたい SSH 通信を明示的に Block するという使い方は出来ないことがわかります。　Access Control の設定はとりやめます。

ECS インスタンスへの Security Group では SSH の接続元は限定していることを確認しました。　最初は SSH Brute Force なら大した話ではないと考えたのですが、どうしてこの SSH 接続が発生するのか（できるのか）わからなくなってきました。　タイミングとしては Server Load Balancer を追加したときからです。　一方、ECSインスタンスの Security Group では指定のIP以外のSSHは遮断しています。　そして Server Load Balancer では Listener として 80/443 しか公開していない状況です。　理論的には ECS インスタンスへの SSH 接続できる経路は存在しないということです。

調査を続けます。　まずはECS インスタンスにログインし、実際に SSH 接続の試みがあったのか確認することにします。しかし、/var/log/auth には SSH の接続のログが見つかりません。　Security Center では以下のスクリーンショットのとおり今日の朝、04:01:15 に接続されているとのことですが、ECS インスタンス(Ubuntu)への実際の SSH 接続は行われていないようです。　なお、2つの IP Address 、23.129.64.201 と 23.129.64.202 、はTor 経由でSSH Brute Force をかけてきたようです。

原因の仮説として、Server Load Balancer の Public IP アドレスへの SSH Brute Force を Security Center が検知したのかもしれません。　

実験として Alibaba Cloud の外から（ SSH アクセスを許可していないIPアドレスより）、Server Load Balancer に SSH で接続を試みます。　その結果として Security Center に SSH Brute Force のログが残るかどうか確認します。

接続テストはこのブログを書いていいる Chromebook から Windows Virtual Desktop の Azure 上の Windows 10 に接続し、 Tera Term から実行します。

接続先の Server Load Balancer は SSH の TCP port 22 を Listen していないため、Connection timed out となります。

Security Center を確認しますが、今朝方のログしか表示されません。　先程行った当方によるテストの接続はみあたりません。　　

調べられることは調べたのですが、本来、SSH Brute Force は起こり得ない（SSH接続できる経路がない）にもかかわらず Security Center で Attack 検知された原因はわかりませんでした。　

過去に Internet に SSH を公開していたときは1日で数百、数千の数で Brute Force が検知されていました。　以下、過去の Security Center の記事ですが、1日に 883 件を検出しています。　

今回は以下のとおり1ヶ月で17件です。　想像の域を出ることはありませんが、Security Group のルールが一時的に開放されてその時に SSH 接続されているのか（この場合、ECS インスタンスの Ubuntu にログは残るはずだが残っていない）、Security Center の誤検知なのか、よくわからない状況です。　まあ、Server Load Balancer を追加したあとからなので私がなにか設定を漏らしているのかもです。　

Config Assessment Risks への対応

まずは、 Security Center から提示されたリスクの内容を確認していきます。

1つ目の　OSS – Bucket Access Permissions は Alibaba Cloud のオブジェクトストレージとなる OSS がパブリックに公開されている設定に関する警告です。　世の中のニュースとして、AWS の S3 について意図せず機密情報を S3 で公開していた事故はよくあると思います。　同じ類の話です。　ただ、今回は意図的に OSS を Static コンテンツを公開する WWW サーバとしてテストしていたところでした。　なのでこちらは Whitelist として対処します。

2つ目は Server Load Balancer のログを有効化しようとの Security Center からの提言です。　上の SSH Brute Force の調査でも Server Load Balancer のログがあればより簡単に調査が進んだということもあります。　これは有効化します。

Server Load Balancer の設定画面から Access Logs をクリックします。

RAM での権限付与を進めます。

ログ取得が有効化されました。

あとはログを保管する Log Service の Project と Logstore を指定します。　実際のログの確認は Log Service となります。

3つ目は OSS versioning の設定です。　これは OSS の versioninig 機能を有効化してデータを保護しようという話です。　Security というと Cracking や Anti Virus が目立ちますが、データや資産を維持できることも重要な要素です。そういう意味では versioning で OSS のデータのバックアップを持つことを Security Center がオススメしてくれているということになります。　今回の OSS はテスト用途なのでこちらは Whitelist として対処します。