Alibaba Cloud Security Center #14 Report email

Alibaba Cloud Security Center から毎日レポートがメールで届きます。　このWebサイトを提供するWebサーバに関するセキュリティレポート、その内容を紹介していきます。

レポートメールの内容

レポートのメールは毎日届きます。　届く時間帯は設定次第ですがAM 7:00過ぎです。　たまにAM 10:00 過ぎに届くこともあります。

HTML 形式でSecurity Center のダッシュボードとほぼ同じ内容をグラフィカルに確認することが出来ます。　　20年前位はHTMLメールはNG、基本使わないものという雰囲気がありましたが今はそんなことはなくなりましたよね。 G Suite とOffice 365 (今はMicrosoft 365か）が広まった結果なのかなと。　私もメールの中に画像を張り付けたりを何の抵抗もなく今はやっています。

上の画像だと見づらいとは思いますが、大きく以下の7つの情報を確認することができます。

Safety Score
Asset risk distribution
Alert trend
Vulnerability trend
Baseline Check Trend
Attack Quantity Trend
Security Suggestion

見るべきところはSafety Score が前日より下がっていないかです。あとはセキュリティリスクの数の遷移です。　私の場合は通常時は”1″がリスク数です（SSH Brute Force 攻撃を受けている都合常に”1″)。　これが増えた場合、新しい脆弱性の対応だったり必要なことがわかります。

今回は”Security Suggestion” を取り上げて紹介しつつ、実際に自分のWeb サーバの対処も行っていきます。

3つのリスクについてSecurity Center から”Security Suggestion”として対応策が提案されています。　このメールの中では具体的な実施内容までは記載されていませんがリンクをクリックすることで Security Center にアクセスできます。

ちなみに”Process Now Help” のリンクをクリックすると中国語が言語に指定されたサイトへジャンプします。

Alibaba Cloud を使っていると中国語のホームページが表示されることはよくあります。　びっくりせずに、言語を選択しなおしましょう。　具体的には右上の言語選択から”International”を選びましょう。　　”日本サイト”を選んでもいですが、ログインするアカウントが国際サイト(International)のものであれば最終的には国際サイトにログインされることになります。

提案されたセキュリティ対策の実行

ここからはSecurity Center から実際にセキュリティの対応を実際に実施していきます。

Alibaba Cloud にログインし、Security Center > Overview の画面にアクセスします。 “Fix Now” をクリックします。

3つのリスクについて順番に対処していきます。

Unchecked Urgent Vulnerabilities

“Unchecked Urgent Vulnerabilities” は日本語に訳せば未確認の脆弱性となります。Security Center では世の中の脆弱性情報をリストアップしてくれるのですが、そのリストの内容をちゃんと確認しようと促してくれるという感じです。

“Process Now” をクリックします。

Precaution > Vulnerabilities の画面に遷移します。　今回はKubernetes とNC Cloud に関する脆弱性です。

“Check Now”をクリックします。　影響するかどうかをSecurity Center が確認してくれます。　　すべてをサービス側に委ねることは手軽です。一方、どのような脆弱性か概要は把握しておくことも重要です。そのための情報が欲しい場合はリンクをクリックすることで詳細な情報を Security Center が提供してくれます。　（今回は画面等は出しませんがその説明ページが中国語のみなことは今現在は残念なところ。　Chrome の翻訳など活用しましょう）

チェック完了後、”No Risk” という状態になりました。

Config Assessment has risks

次はConfig Assessment に関するリスク対処です。　Alibaba Cloud の各プロダクトの使い方についてセキュリティ面で改善するべき事柄をSecurity Center が提案してくれます。

“Process Now” をクリックします。

Precaution > Config Assessment の画面に遷移します。 “OSS – Logging Configuration”（OSSのログの構成）について改善事項があるようです。

リンクをクリックします。

説明が以下の通りありますが、要はOSS (オブジェクトストレージ）はアクセスログを大量に出力するからアーカイブストレージに保管することをお勧めするよ、ということです。

During access of OSS, users will generate a large number of access logs. You can convert these access log into archive storage and long-term archive storage.

アーカイブストレージにすればクラウド事業者側が得られる使用料金は減少します。その上でユーザ視点で提案してくれています。　AWS なんかもその傾向が顕著ですがパブリッククラウドはユーザ視点が本当に徹底されていると感じます。目先のちょっとした儲けを狙うのではなくユーザ視点の徹底した追及を続けることで自社のサービス力を高め、ファン（お客様）を増やし、最終的にクラウドサービサーとして勝利者となれると。　AWS もAlibaba もクラウド事業とは別に本業があるから出来る考えとも言えます。

対処を進めます。 “Fix” のリンクをクリックします。

以下の画面の青いバーの”Enable OSS Logging”はリンクではないためクリックしても反応はなく、下に文字で書いてある”Open OSS Management Console, and enable logging at Logging section” から個別に設定してね、とのこと。

Attacks

このWeb サイトへのAttaks (攻撃）について対処します。 “Process Now”をクリックします。

インターネットに SSH ポートをさらしているのでずーとSSH Brute Force 攻撃を受けているだけです。　インターネットの世界なので別にそれが攻撃だとは個人的には思わないです。　Port 22 を開けているということはそこにアクセスしてくるのを許容している訳なので。　

許容しているとは言いつつ、”Anti-brute Force Cracking” 機能を有効化し、ある期間内に一定回数のSSH接続試行があると特定時間ブロックすることにしましたが攻撃数が減るわけでもなく。

下の図はSecurity Center を購入し利用している全期間の攻撃回数のグラフです。”Anti-brute Force Cracking”はグラフでいうと真ん中あたりで導入しましたが攻撃は減るどころか最近は増加傾向です。　まあ、攻撃者は対象者の状態（”Anti-brute Force Cracking” 機能を使ってブロック）など関係なく手当たり次第に攻撃するということです。