96537


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

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

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

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

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


CC BY-SA 4.0
2023-10-20T05:48:25.313
96528
2023-10-21T02:37:12.393
19992
question
mysql security
MySQL5.7のExtended Support Endsにつきまして


MySQL
に限らず一般的な話ですが、サポート期間終了後は機能追加、バグ修正、脆弱性への対応などが行われなくなります。(どのようなリスクが発生しうるかは一概には言えません)

[MySQL テクニカル・サポート](https://www.mysql.com/jp/support/)

> **MySQL Extended Support** \- Premier Support期間エラー修正を含む、Premier
> Support期間終了後3年間、特定のMySQLリリースに対する追加サポートを提供します。MySQLメンテナンス・リリース、アップデート、バグ修正（エラー修正)およびセキュリティ情報を提供します。

[MySQL 5.7 EOL: Migrating to a MySQL
Alternative](https://www.pingcap.com/blog/mysql-57-eol-mysql-alternatives-
tidb/)

> On October 21, 2023, MySQL 5.7 will reach its end of life (EOL). This means
> that Oracle, the company behind MySQL, will no longer provide official
> updates, bug fixes, or security patches for MySQL 5.7.
>
> MySQL 5.7は2023年10月21日にサポート終了 (EOL) を迎えます。これはMySQLの背後にある企業であるOracle社が、MySQL
> 5.7の公式アップデート、バグ修正、セキュリティパッチを提供しなくなることを意味します。


CC BY-SA 4.0
2023-10-20T06:24:58.793
96529
2023-10-20T06:24:58.793
3060
96528
answer


>   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.への回答のみとさせていただきます。)


CC BY-SA 4.0
2023-10-21T01:03:00.100
96537
2023-10-21T01:03:00.100
7347
96528
answer


>   2. もう一点の脆弱性対策については想像がつきません
>

EOLによって開発元が脆弱性修正を行わなくなったソフトウェアに対して、第三者(サードパーティー)が脆弱性対策を行う方法はいくつかあります。

### 開発を引き継ぐ(ソースレベルの修正)

そのソフトウェアがオープンソースであった場合、第三者が開発を引き継ぎ、ソースレベルで脆弱性の対応を行うというのがあります。

セキュリティに詳しく、ソースを分析して修正できる、かなり優秀な開発チームを持っていないと難しいですが、お金があればできないことはありません。

具体例

  * RHELで長期サポート対象の一部のアプリケーション(例えば、Python 3.9の公式サポートは2025年10月までですが、RHEL9のPython 3.9は2032年5月までRedHat社が独自にサポートします)

### バイナリパッチを当てる(バイナリレベルの修正)

ソースコードが無い場合でも、バイナリベレルでパッチを適用し、脆弱性をなくす方法があります。この手法はパッチ作成時にリバースエンジニアリングが必要になるため、ソフトウェアのライセンスによっては禁止されている場合があります。

バイナリのみでの分析が簡単で無いため、非常に高度な知識が必要になり、そのような対応チームを雇うにはそれなりの金額になります。ソースコードが無いため、完全な解析ができず、対応が不十分になる可能性もあります。

具体例

  * 0pachよるWindows 7へのパッチ(実際は「マイクロパッチ」という仕組みで、実行中プロセスに直接適用されるモノらしい)
  * Winnyの脆弱性に対する第三者によるパッチ

### セキュリティ製品で防御する

よくあるセキュリティ製品としては別回答でも述べたWAFやDBF等のことです。他にも、一般的なUTMではIPS機能があるので、それを利用するというのもあります。主にネットワーク経由の攻撃を防ぎたいという場合は、有用な手段の一つです。サーバーの外側に置く方法だけでは無く、サーバー自体にインストールし、ネットワークアクセスやメモリ状態などを監視・防御するという製品もあります。

どのような製品であっても、全て防いでくれるというわけではありません。製品(というより防御方法)によっては対応できない脆弱性も存在します。価格はセキュリティ製品によって様々ですが、手軽にある程度の脆弱性対応ができるのがメリットです。

具体例は多数のWAFやUTMが販売されていますので、それらを参照してください。

* * *

ぱっと思いつくのはこれぐらいですが、他にもあるかも知れません。ただ、どのような対策を実施しているかはシステムによるので、必ずこれを実施しているとは限りません。

一般的に、上記で述べたような対策を実施するよりも、サポートされているバージョンへのアップデートする方が安価かつ低リスクになります。バージョンアップや代替製品への移行が高額すぎる場合や実施には非常に大きいリスクが発生する場合に、最後の手段として採用されるかもしれない程度と思ってください。

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


CC BY-SA 4.0
2023-10-21T02:37:12.393
96539
2023-10-21T02:37:12.393
7347
96528
answer