MySQL5.7のExtended Support Endsにつきまして


MySQL5.7のExtended Support Endsが2023年10月30日になっておりこの件について理解を深めたく質問させていただいております。

経緯として2023年10月現在、国内のレンタルサーバでMySQL8に対応しているところが少ないのである会社様のサポートに「MySQL8は使えますか？」と問い合わせたところ以下のような回答をいただきました。

「データベースについては準備中です。また5.7に関しても外部から直接アクセスできない仕様になっており、脆弱性対策も行なっているのですぐには影響はないと思います。」  
このような現状でサーバ会社様も非常に大変なプロジェクトを進めているのだなと理解しつつも以下３点の疑問が生まれました。

１．外部から直接アクセスできない仕様になっておりという部分について、私の理解ではMySQLサーバがプライベートなネットワーク環境に隔離されていてオリジンサーバからのみアクセスを受け付けるような仕様になっていると考えましたが、こちらでリスクがかなり低減されるということでしょうか？低減される具体例があれば教えてください。  
２．もう一点の脆弱性対策については想像がつきませんでしたのでおそらくこういったことをされているという例をご教授いただけましたら幸いです。  
３．この状況で11月以降MySQL5.7を使用し続けた場合、現実に起こってもおかしくないリスクとしてどのようなものがあるかも教えていただけましたら幸いです。

レンタルサーバの対応はそれぞれの事情もあると思いますのでそこは考慮せず、一般論としておそらくこういうことではないかという形で疑問にご回答いただけたら嬉しいです。よろしくお願いいたします。




>   1. 低減される具体例があれば教えてください。
>

脆弱性と言っても色々なタイプがあります。そのタイプによって、対象サーバーへの直接アクセスを制限し、信頼されたサーバーからのみアクセスのみに限定することで、防げる場合と防げない場合、防げる場合でも別の脆弱性と組み合わさると防げなく場合があります。

たとえば、次のような二つの脆弱性が仮にあったとしましょう(現実に、このような脆弱性が存在するかはわかりません)。

  1. データベース接続時のユーザー認証でユーザー名に「特定の文字列」が含まれるとデータベースサービスが落ちる。
  2. クエリの中の値で「特定の文字列」が含まれるとデータベースサービスが落ちる。

どちらもDoS(サービス拒否)攻撃を可能にする脆弱性です。このデータベースサーバーはプライベートネットワークにのみ接続されており、そのネットワークはインターネットにはルーティングされておらず、データベースサーバーを利用するWebアプリケーションサーバー、管理サーバー(DNSとWebプロキシを兼ねる)のみ存在するとします。データベースサーバーはWebアプリケーションサーバー経由で利用されますが、その時接続するデータベースのユーザーはWebアプリケーションサーバー用の固定のユーザーです。。データベースサーバーの管理やアップデートは管理サーバー経由とします。Webアプリケーションサーバーと管理サーバーはインターネットにも接続されているとします。

このような状況で、1.の脆弱性を利用してインターネットからDoS攻撃を行うのは困難です。なぜなら、直接データベースサーバーに接続できないからです。Webアプリケーションサーバー経由で攻撃しようにも、接続時のユーザー名は固定であるため、これを「特定の文字列」が含まれる物に変更することができません。つまり、1.の脆弱性を利用する攻撃は防げると言えます。

では、2.の脆弱性はどうでしょう。Webアプリケーションサーバーの作りによるかも知れませんが、よくあるWebアプリでは、任意の文字列を入れるような所(備考とか、メモとか、ユーザー情報ならプロフィールとか)があって、そこで投稿されたデータがそのままデータベースに保存できるものが多いです。このような所を利用して、「特定の文字列」を入れてしまえばどうでしょうか？そう、2.の脆弱性によってサービスが落ち、DoS攻撃が成功してしまいます。つまり、2.の脆弱性を利用する攻撃は防げないと言えます。

ここで終わらないのがセキュリティの難しいところです。プライベートなネットワーク環境なら、1.は防げるけど2.は防げないと単純な話では **ありません**
。条件が揃えば1.は防げませんし、逆に2.を防げるときもあると言うことです。

たとえば、管理サーバーの管理に不備があったり、脆弱性があったりして、それらを利用したプロセスの乗っ取りなどにより、管理サーバーから任意のパケットを送信できるとしたらどうでしょうか？管理サーバーはプライベートネットワークに繋がっているので、データベースサーバーに直接アクセスできます。そう、管理サーバーから1.の脆弱性を突くことがでできると言うことです。プライベートネットワークに置いてあれば安全なのでは無く、プライベートネットワークに入ることができる全ての経路がしっかり管理されて初めて安全だと言えるのです。

このように一つの脆弱性だけでは成功しない場合でも、別の脆弱性と組み合わせると成功できる場合があります。今回の例では影響はDoS攻撃ですが、認証が成功したり、管理者権限が取れたり、任意実行が可能になったりするような脆弱性ですと、重大な情報漏洩に繋がる可能もあります。

逆に2.は絶対に防げないかというと、そうではありません。そのような脆弱性がわかっていれば、Webアプリケーションサーバー側で「特定の文字列」を弾くと言うことが可能です。また、データベースファイアウォール(DBF)をWebアプリケーションサーバーとデータベースサーバーの間に置くというのもあります。こういった製品の中には既知の脆弱性を突くような攻撃を防ぐことができるものがあります。

このように既知の脆弱性というのは、単純にその脆弱性をなくすという対処方法だけでは無く、その脆弱性を利用した攻撃を防ぐという対処方法もあります。よく見るのは、特定の機能を利用した脆弱性の場合で、その機能が運用上必須ではない場合、脆弱性に対応できるまではその機能を無効にするという物です。ただ、ちょっと注意してほしいのは、これらは既知であればという話です。未知の脆弱性の場合は防ぐ方法もわからないため、対応しようがありません。

* * *

では、1.や2.のようなタイプの脆弱性が実在するのかです。データベースの脆弱性はあまり詳しくないので、Webサーバーで例を出してみましょう。構成は、プライベートネットワークだけに接続されたWebアプリケーションサーバー(Apache
HTTP
Server)とインターネットとプラベートネットワークに接続されたリバースプロキシサーバー(nginx)の組み合わせて、インターネットからの接続はリバースプロキシサーバー経由でWebアプリケーションサーバーに接続(HTTPSで受信してHTTPSで接続する)できるとします。リバースプロキシサーバーは常に最新状態にできますが、Webアプリケーションサーバーはサポート切れのOSを利用してアップデート不可だったとします。

上記のような状況で次の脆弱性はどうなるでしょうか？

  1. [Heartbleed](https://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%BC%E3%83%88%E3%83%96%E3%83%AA%E3%83%BC%E3%83%89)
  2. [Shellshock](https://ja.wikipedia.org/wiki/2014%E5%B9%B4%E3%82%B7%E3%82%A7%E3%83%AB%E3%82%B7%E3%83%A7%E3%83%83%E3%82%AF%E8%84%86%E5%BC%B1%E6%80%A7)

どちらも世界中で多大な被害を与えた脆弱性です。脆弱性発覚後、対応パッチはすぐにだされましたが、WebアプリケーションサーバーはOSサポート切れで対応できない(対応パッチが存在しない)となった時どうなるかです(リバースプロキシサーバーは対応済み)。

Heartbleedを成功させるには、TLS通信そのものでHeartbeatを送り続けるという工夫が必要です。WebアプリケーションサーバにTLS通信を行うのはリバースプロキシサーバーです。インターネットからは直接HTTPS接続させず、一旦接続を受け取った代理サーバーが内部のサーバーにHTTPS接続(構成によってはHTTPの場合もある)を行うのがリバースプロキシです。インターネットからいくらHeartblead攻撃を行っても、リバースプロキシサーバーは対応済みなので成功しません。WebアプリケーションサーバーへのHTTPS接続(TLS通信)は不正なことを行わないリバースプロキシサーバーなので、その攻撃が伝わることがないからです。

これは一旦通信を受け取って、それを代理で問い合わせるリバースプロキシであるから防げることです。もし、パケットをそのまま内部のWebアプリケーションに通してしまうようなただのNATや負荷分散装置の場合は、防ぐことができません。

では、Shellshockの方はどうなのかというと影響を受ける可能性が高いです。ShellshockはBashの脆弱性ですが、多くのLinuxではbashがデフォルトのシェルになっており、この状況でCGIが有効だとこの脆弱瀬に重大な影響を受けます。実際の所はCGIで外部コマンド呼び出しをして言うなどの条件があるのですが、攻撃方法がとても簡単です。どれかのヘッダ(ユーザーエージェントなど)に「特定の文字列」を入れるだけで、任意のコマンドが実行出来ます。

ユーザーエージェントにその「特定の文字列」があっても、これは正式なHTTPS通信できます。リバースプロキシサーバーはそのままWebアプリケーションサーバーにその文字列を渡してしまうでしょう。そうなると、Webアプリケーションサーバーで任意のコマンドが実行され、攻撃成功となると言うことです。

これもリバープロキシサーバーにWebアプリケーションファイアウォール(WAF)の機能を持たせる等の方法で防ぐことができます。これはデータベースサーバーで言ったDBFの関係と似たようなモノです。

つまり、Heartbleedは上で上げた1.の脆弱性のタイプ、Shellshockは2.の脆弱性のタイプと言えます。ただ、実際の脆弱性のタイプは様々あり、1.や2.で分けれるとは限らないと言うこと、構成や条件によっては、同じ脆弱性でも1.であったり、2.であったりすることもあります。

* * *

プライベートネットワークに置くことで防げる脆弱性はあります。ただ、全てを防げるわけでは無いと言うことにも注意が必要です。それらに対しては、DBFやWAFのようなセキュリティ製品でさらに防御を固める必要があるかも知れません(これらの製品でも全てを防げるわけではありません)。また、プライベートネットワーク自体の管理が愚かであれば、せっかく防げていた脆弱性を付かれてしまうという場合もあります。それらを踏まえてリスクを考える必要があります。

(長くなったので、この回答は1.への回答のみとさせていただきます。)




>   1. 低減される具体例があれば教えてください。
>

脆弱性と言っても色々なタイプがあります。そのタイプによって、対象サーバーへの直接アクセスを制限し、信頼されたサーバーからのみアクセスのみに限定することで、防げる場合と防げない場合、防げる場合でも別の脆弱性と組み合わさると防げなく場合があります。

たとえば、次のような二つの脆弱性が仮にあったとしましょう(現実に、このような脆弱性が存在するかはわかりません)。

  1. データベース接続時のユーザー認証でユーザー名に「特定の文字列」が含まれるとデータベースサービスが落ちる。
  2. クエリの中の値で「特定の文字列」が含まれるとデータベースサービスが落ちる。

どちらもDoS(サービス拒否)攻撃を可能にする脆弱性です。このデータベースサーバーはプライベートネットワークにのみ接続されており、そのネットワークはインターネットにはルーティングされておらず、データベースサーバーを利用するWebアプリケーションサーバー、管理サーバー(DNSとWebプロキシを兼ねる)のみ存在するとします。データベースサーバーはWebアプリケーションサーバー経由で利用されますが、その時接続するデータベースのユーザーはWebアプリケーションサーバー用の固定のユーザーです。。データベースサーバーの管理やアップデートは管理サーバー経由とします。Webアプリケーションサーバーと管理サーバーはインターネットにも接続されているとします。

このような状況で、1.の脆弱性を利用してインターネットからDoS攻撃を行うのは困難です。なぜなら、直接データベースサーバーに接続できないからです。Webアプリケーションサーバー経由で攻撃しようにも、接続時のユーザー名は固定であるため、これを「特定の文字列」が含まれる物に変更することができません。つまり、1.の脆弱性を利用する攻撃は防げると言えます。

では、2.の脆弱性はどうでしょう。Webアプリケーションサーバーの作りによるかも知れませんが、よくあるWebアプリでは、任意の文字列を入れるような所(備考とか、メモとか、ユーザー情報ならプロフィールとか)があって、そこで投稿されたデータがそのままデータベースに保存できるものが多いです。このような所を利用して、「特定の文字列」を入れてしまえばどうでしょうか？そう、2.の脆弱性によってサービスが落ち、DoS攻撃が成功してしまいます。つまり、2.の脆弱性を利用する攻撃は防げないと言えます。

ここで終わらないのがセキュリティの難しいところです。プライベートなネットワーク環境なら、1.は防げるけど2.は防げないと単純な話では **ありません**
。条件が揃えば1.は防げませんし、逆に2.を防げるときもあると言うことです。

たとえば、管理サーバーの管理に不備があったり、脆弱性があったりして、それらを利用したプロセスの乗っ取りなどにより、管理サーバーから任意のパケットを送信できるとしたらどうでしょうか？管理サーバーはプライベートネットワークに繋がっているので、データベースサーバーに直接アクセスできます。そう、管理サーバーから1.の脆弱性を突くことがでできると言うことです。プライベートネットワークに置いてあれば安全なのでは無く、プライベートネットワークに入ることができる全ての経路がしっかり管理されて初めて安全だと言えるのです。

このように一つの脆弱性だけでは成功しない場合でも、別の脆弱性と組み合わせると成功できる場合があります。今回の例では影響はDoS攻撃ですが、認証が成功したり、管理者権限が取れたり、任意実行が可能になったりするような脆弱性ですと、重大な情報漏洩に繋がる可能もあります。

逆に2.は絶対に防げないかというと、そうではありません。そのような脆弱性がわかっていれば、Webアプリケーションサーバー側で「特定の文字列」を弾くと言うことが可能です。また、データベースファイアウォール(DBF)をWebアプリケーションサーバーとデータベースサーバーの間に置くというのもあります。こういった製品の中には既知の脆弱性を突くような攻撃を防ぐことができるものがあります。

このように既知の脆弱性というのは、単純にその脆弱性をなくすという対処方法だけでは無く、その脆弱性を利用した攻撃を防ぐという対処方法もあります。よく見るのは、特定の機能を利用した脆弱性の場合で、その機能が運用上必須ではない場合、脆弱性に対応できるまではその機能を無効にするという物です。ただ、ちょっと注意してほしいのは、これらは既知であればという話です。未知の脆弱性の場合は防ぐ方法もわからないため、対応しようがありません。

* * *

では、1.や2.のようなタイプの脆弱性が実在するのかです。データベースの脆弱性はあまり詳しくないので、Webサーバーで例を出してみましょう。構成は、プライベートネットワークだけに接続されたWebアプリケーションサーバー(Apache
HTTP
Server)とインターネットとプラベートネットワークに接続されたリバースプロキシサーバー(nginx)の組み合わせて、インターネットからの接続はリバースプロキシサーバー経由でWebアプリケーションサーバーに接続(HTTPSで受信してHTTPSで接続する)できるとします。リバースプロキシサーバーは常に最新状態にできますが、Webアプリケーションサーバーはサポート切れのOSを利用してアップデート不可だったとします。

上記のような状況で次の脆弱性はどうなるでしょうか？

  1. [Heartbleed](https://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%BC%E3%83%88%E3%83%96%E3%83%AA%E3%83%BC%E3%83%89)
  2. [Shellshock](https://ja.wikipedia.org/wiki/2014%E5%B9%B4%E3%82%B7%E3%82%A7%E3%83%AB%E3%82%B7%E3%83%A7%E3%83%83%E3%82%AF%E8%84%86%E5%BC%B1%E6%80%A7)

どちらも世界中で多大な被害を与えた脆弱性です。脆弱性発覚後、対応パッチはすぐにだされましたが、WebアプリケーションサーバーはOSサポート切れで対応できない(対応パッチが存在しない)となった時どうなるかです(リバースプロキシサーバーは対応済み)。

Heartbleedを成功させるには、TLS通信そのものでHeartbeatを送り続けるという工夫が必要です。WebアプリケーションサーバにTLS通信を行うのはリバースプロキシサーバーです。インターネットからは直接HTTPS接続させず、一旦接続を受け取った代理サーバーが内部のサーバーにHTTPS接続(構成によってはHTTPの場合もある)を行うのがリバースプロキシです。インターネットからいくらHeartblead攻撃を行っても、リバースプロキシサーバーは対応済みなので成功しません。WebアプリケーションサーバーへのHTTPS接続(TLS通信)は不正なことを行わないリバースプロキシサーバーなので、その攻撃が伝わることがないからです。

これは一旦通信を受け取って、それを代理で問い合わせるリバースプロキシであるから防げることです。もし、パケットをそのまま内部のWebアプリケーションに通してしまうようなただのNATや負荷分散装置の場合は、防ぐことができません。

では、Shellshockの方はどうなのかというと影響を受ける可能性が高いです。ShellshockはBashの脆弱性ですが、多くのLinuxではbashがデフォルトのシェルになっており、この状況でCGIが有効だとこの脆弱瀬に重大な影響を受けます。実際の所はCGIで外部コマンド呼び出しをして言うなどの条件があるのですが、攻撃方法がとても簡単です。どれかのヘッダ(ユーザーエージェントなど)に「特定の文字列」を入れるだけで、任意のコマンドが実行出来ます。

ユーザーエージェントにその「特定の文字列」があっても、これは正式なHTTPS通信できます。リバースプロキシサーバーはそのままWebアプリケーションサーバーにその文字列を渡してしまうでしょう。そうなると、Webアプリケーションサーバーで任意のコマンドが実行され、攻撃成功となると言うことです。

これもリバープロキシサーバーにWebアプリケーションファイアウォール(WAF)の機能を持たせる等の方法で防ぐことができます。これはデータベースサーバーで言ったDBFの関係と似たようなモノです。

つまり、Heartbleedは上で上げた1.の脆弱性のタイプ、Shellshockは2.の脆弱性のタイプと言えます。ただ、実際の脆弱性のタイプは様々あり、1.や2.で分けれるとは限らないと言うこと、構成や条件によっては、同じ脆弱性でも1.であったり、2.であったりすることもあります。

* * *

プライベートネットワークに置くことで防げる脆弱性はあります。ただ、全てを防げるわけでは無いと言うことにも注意が必要です。それらに対しては、DBFやWAFのようなセキュリティ製品でさらに防御を固める必要があるかも知れません(これらの製品でも全てを防げるわけではありません)。また、プライベートネットワーク自体の管理が愚かであれば、せっかく防げていた脆弱性を付かれてしまうという場合もあります。それらを踏まえてリスクを考える必要があります。

(長くなったので、この回答は1.への回答のみとさせていただきます。)

