MySQL/MariaDBサーバーを保護する方法

MongoDBデータベースへの攻撃の後、最近、MySQLサーバーがランサムウェアの標的になっていることもわかりました。パブリッククラウドとプライベートクラウドの採用が増えていることを考えると、これは驚くべきことではありません。構成が不十分なデータベースをクラウドで実行すると、大きな責任になる可能性があります。

このブログ投稿では、MySQLまたはMariaDBサーバーを保護および保護する方法に関するいくつかのヒントを紹介します。

攻撃ベクトルを理解する

SCMagazineの引用：
「攻撃は、MySQLデータベースのルートパスワードを総当たり攻撃することから始まります。ログインすると、MySQLデータベースとテーブルがフェッチされます。次に、攻撃者は「警告」と呼ばれる新しいテーブルを作成します。このテーブルには、連絡先の電子メールアドレス、ビットコインアドレス、および支払い要求が含まれています。」

記事に基づいて、攻撃ベクトルは、ブルートフォース方式でMySQLルートパスワードを推測することから始まります。ブルートフォース攻撃は、攻撃者が最終的に正しく推測することを期待して、多くのパスワードまたはパスフレーズを試みることで構成されます。つまり、通常、短いパスワードは非常に迅速に検出できますが、長いパスワードには数日から数か月かかる場合があります。

ブルートフォースは、あらゆるサービスに発生する一般的な攻撃です。 MySQL（および他の多くのDBMS）にとって残念なことに、ユーザー認証中に特定のアドレスからのブルートフォース攻撃を検出してブロックする、すぐに使用できる機能はありません。ただし、MySQLは認証の失敗をエラーログに記録します。

パスワードポリシーを確認する

MySQLパスワードポリシーを確認することは、常にサーバーを保護するための最初のステップです。 MySQLのルートパスワードは、アルファベット、数字、記号を組み合わせて十分に強力であり（覚えにくくなります）、安全な場所に保存する必要があります。パスワードは定期的に、少なくとも暦四半期ごとに変更してください。攻撃ベクトルに基づくと、これはハッカーが標的とする最も弱い点です。データを大切にする場合は、この部分を見落とさないでください。

ClusterControlによって実行されるMySQLの展開は、常にベンダーのセキュリティのベストプラクティスに従います。たとえば、GRANT中にワイルドカードホストが定義されることはなく、構成ファイルに保存されている機密性の高いログインクレデンシャルはOSのrootユーザーにのみ許可されます。展開段階で強力なパスワードを指定することを強くお勧めします。

MySQLサーバーを分離する

標準の実稼働環境では、データベースサーバーは通常、下位レベルの層に配置されます。このレイヤーは保護され、アプリケーションやロードバランサーなどの上位層からのみアクセス可能である必要があります。データベースがアプリケーションと同じ場所にある場合は、非ローカルアドレスに対してロックダウンし、代わりにMySQLソケットファイルを使用することもできます（オーバーヘッドが少なく、安全性が高くなります）。

ここでは、「bind-address」パラメーターの構成が重要です。 MySQLバインディングは、サーバー上のIPアドレス（0.0.0.0）なし、1つ、またはすべてに制限されていることに注意してください。選択の余地がなく、MySQLがすべてのネットワークインターフェイスをリッスンする必要がある場合は、既知の適切なソースからのMySQLサービスへのアクセスを制限してください。ファイアウォールアプリケーションまたはセキュリティグループを使用して、データベースに直接アクセスする必要があるホストからのアクセスのみをホワイトリストに登録します。

場合によっては、MySQLサーバーを統合の目的（監視、監査、バックアップなど）のためにパブリックネットワークに公開する必要があります。周囲に境界線を引く限り、それで問題ありません。不要なソースにMySQLサーバーを「表示」させないでください。 3306がMySQLサービスのデフォルトポートであることを世界中の何人が知っているかは間違いありません。ネットワークアドレスに対してポートスキャンを実行するだけで、攻撃者は1分以内にサブネット内の公開されたMySQLサーバーのリストを作成できます。露出のリスクを最小限に抑えるために、MySQL構成ファイルで「port」パラメーターを構成してカスタムMySQLポートを使用することをお勧めします。

ユーザーポリシーを確認する

重要な管理権限、特にGRANT、SUPER、およびPROCESSを保持する特定のユーザーを制限します。サーバーがスレーブである場合は、super_read_onlyを有効にすることもできます。これは、MySQL5.7.8およびPerconaServer 5.6.21以降でのみ使用できます（残念ながら、MariaDBでは使用できません）。有効にすると、サーバーは、SUPER特権を持つユーザーであっても、スレーブステータスログがテーブルである場合にレプリケーションリポジトリを更新する以外に、更新を許可しません。デフォルトのテストデータベースと空のパスワードを持つユーザーを削除して、侵入の範囲を狭めます。これは、ClusterControlによって実行されるセキュリティチェックの1つであり、データベースアドバイザーとして実装されています。

1つのアカウントに許可される接続の数を制限することもお勧めします。これを行うには、mysqldでmax_user_connections変数を設定するか（デフォルトは0、無制限に等しい）、GRANT / CREATE USER /ALTERUSERステートメントでリソース制御オプションを使用します。 GRANTステートメントは、アカウントによるサーバーへの同時接続数の制限をサポートしています。例：

mysql> GRANT ALL PRIVILEGES ON db.* TO 'db_user'@'localhost' WITH MAX_USER_CONNECTIONS 2;

ClusterControlを使用して、MAX_USER_CONNECTIONSリソース制御オプションでMySQLアカウントを作成します

MySQLサーバーのデフォルトの管理者ユーザー名は「root」です。ハッカーは、その権限にアクセスしようとすることがよくあります。このタスクをさらに難しくするには、「root」の名前を別の名前に変更します。 MySQLユーザー名の長さは最大32文字です（MySQL 5.7.8より前は16文字）。以下に示すように、RENAMEステートメントを使用して、スーパー管理者ユーザーに長いユーザー名を使用することができます。

mysql> RENAME USER root TO new_super_administrator_username;

ClusterControlユーザーへの補足として、ClusterControlは、データベースサーバーを自動化および管理するために、MySQLのrootユーザーとパスワードを知っている必要があります。デフォルトでは、「ルート」を検索します。 rootユーザーの名前を別の名前に変更する場合は、cmon_X.cnf（XはクラスターID）内で「monitored_mysql_root_user ={new_user}」を指定し、CMONサービスを再起動して変更を適用します。

バックアップポリシー

ハッカーは身代金が支払われるとデータを取り戻すと述べていましたが、通常はそうではありませんでした。バックアップの頻度を増やすと、削除したデータを復元する可能性が高くなります。たとえば、毎日の増分バックアップで週に1回の完全バックアップの代わりに、1時間ごとの増分バックアップで1日1回の完全バックアップをスケジュールできます。 ClusterControlのバックアップ管理機能を使用すると、これを簡単に実行でき、問題が発生した場合にデータを復元できます。

バイナリログ（binlogs）を有効にしている場合は、さらに優れています。毎日完全バックアップを作成し、バイナリログをバックアップできます。ビンログはポイントインタイムリカバリにとって重要であり、バックアップ手順の一部として定期的にバックアップする必要があります。 DBAは、この単純な方法を見逃す傾向があります。これは1セントの価値があります。ハッキングされた場合でも、ハッカーがバイナリログを削除していなければ、発生する前の最後の時点にいつでも回復できます。バイナリログのパージは、攻撃者がSUPER権限を持っている場合にのみ可能であることに注意してください。

もう1つの重要なことは、バックアップファイルが復元可能でなければならないということです。時々バックアップを確認し、復元する必要があるときに予期しない事態を回避します。

Web/アプリケーションサーバーを保護する

MySQLサーバーを分離した場合でも、攻撃者がWebサーバーまたはアプリケーションサーバーを介してサーバーにアクセスする可能性があります。悪意のあるスクリプト（クロスサイトスクリプティング、SQLインジェクションなど）をターゲットWebサイトに挿入することで、アプリケーションディレクトリにアクセスし、アプリケーションファイルを読み取ることができます。これらには、データベースのログイン資格情報などの機密情報が含まれている場合があります。これを確認することで、攻撃者はデータベースにログインし、すべてのテーブルを削除して、「身代金」テーブルを内部に残すことができます。被害者を身代金として受け取るために、必ずしもMySQLのrootユーザーである必要はありません。

Webサーバーを危険にさらす方法は何千もあり、この目的でインバウンドポート80または443を実際に閉じることはできません。 WebサーバーをHTTPベースのインジェクションから保護するには、もう1つの保護レイヤーが必要です。 Apache ModSecurity、NAXSI（nginxの場合はWAF）、WebKnight（IISの場合はWAF）などのWebアプリケーションファイアウォール（WAF）を使用するか、CloudFlare、Akamai、Amazon CloudFrontなどの安全なコンテンツ配信ネットワーク（CDN）でWebサーバーを実行することができます。

常に最新の状態に保つ

非特権ユーザーが自分自身をスーパーユーザーにエスカレートできる、重大なゼロデイMySQLエクスプロイトについて聞いたことがあるでしょうか。怖いですね。幸いなことに、すべての既知のベンダーは、この問題のバグ修正を含むようにリポジトリを更新しました。

本番環境で使用する場合は、ベンダーのリポジトリからMySQL/MariaDBパッケージをインストールすることを強くお勧めします。パッケージが通常古くなっているデフォルトのオペレーティングシステムリポジトリに依存しないでください。 Galera ClusterやMySQLレプリケーションなどのクラスター環境で実行している場合は、常に最小限のダウンタイムでシステムにパッチを適用することができます。これをルーチンにして、アップグレード手順を可能な限り自動化してみてください。

ClusterControlは、シングルクリックでMySQL / MariaDBのマイナーバージョンローリングアップグレード（一度に1ノード）をサポートします。メジャーバージョンのアップグレード（MySQL5.6からMySQL5.7へのアップグレードなど）では、通常、既存のパッケージをアンインストールする必要があり、自動化するのは危険な作業です。このようなアップグレードには、慎重な計画とテストが必要です。

結論

ランサムウェアは、お金のかからない金の壺です。将来的にはセキュリティ違反が増える可能性があり、何かが起こる前に行動を起こす方がよいでしょう。ハッカーはそこにある多くの脆弱なサーバーを標的にしており、この攻撃は他のデータベース技術にも広がる可能性が非常に高いです。データの保護は、データベース管理者にとって常に課題です。本当の敵は犯罪者ではなく、重要な資産を保護するという私たちの態度です。