MySQL数据库遭到攻击篡改—使用备份和binlog进行数据恢复-mysql チュートリアル-php.cn

ホームページ

データベース

mysql チュートリアル

MySQL数据库遭到攻击篡改—使用备份和binlog进行数据恢复

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB

Jun 07, 2016 pm 04:42 PM

mysql使用バックアップ攻撃データベース改ざん

数据篡改即是对计算机网络数据进行修改、增加或删除，造成数据破坏。数据库数据被攻击了首先得查看是被删除了还是被篡改了?是否有备份数据，是否能够进行恢复并加固。本文来自数据库技术专家张正，主要描述了MySQL遭到攻击篡改数据，利用从库的备份和主库的B

数据篡改即是对计算机网络数据进行修改、增加或删除，造成数据破坏。数据库数据被攻击了首先得查看是被删除了还是被篡改了?是否有备份数据，是否能够进行恢复并加固。本文来自数据库技术专家张正，主要描述了MySQL遭到攻击篡改数据，利用从库的备份和主库的Binlog进行不完全恢复。

以下是作者原文：

一、发现问题

今天是2014-09-26，开发大清早就说昨晚数据库遭到了攻击。数据库中某文章表的文章内容字段遭到篡改，全部改成了同一篇文章。

通过查看日制发现数据是在 2014-09-25 21:53:57 遭到篡改。

所有的内容全部被改成了如下：

subject: 桂林阳朔自助游

content:

          一直都是自助游，从不喜欢?团。去之前都是在网上做足了功课，真的是很感谢那些写游记写攻略的朋友。所以，现在也想把自己的体会和经验写出来，和大家分享，希望对后来的朋友有帮助。

         一个月前，朋友约我去阳朔一游，阳朔也是我一直想去的地方，特别是传说中的西街。上网搜集资料，制定出我们的行程计划（呵呵，可能是职业习惯吧，制定计划和行程安排是我们的强项，计划性和灵活性是我们的特点），目的很明确，是度假休闲，不必游走于各个景点，其实我想朋友们也在很多地方都旅游多了，也知道有些景点是怎么出来的，各地都一样。

          制定好主旋律后，我们的大致行程安排如下：

          十九号桂林集中，二十号出发去阳朔，先去阳朔安顿下来（有些人是从桂林带着行李在杨堤路口下车，直接先去漓江漂流，然后再去阳朔，好像节约时间，不过，我们因为没有安排那么满，也不想带着行李游玩，所以选择先去阳朔安顿，和客栈老板好好聊聊情况后，再决定具体细节）

         ?次度假的主要内容是：漓江漂流；遇龙河漂流（全漂），十里画廊；西街打望，发呆，西街酒吧，印象刘三姐，其他的根据情况和心情临时决定。

我把文章贴出来，先谴责一下，很可能是某旅游社的人为了打广告雇人干的。

二、解决方法

这个库我们是每天凌晨备份，保留30天的备份。主库的Binlog保留时间为7天。

因此很容易想到的方法是将从库2014-09-25凌晨的备份拿出来恢复，然后通过主库的Binlog通过时间段来筛选出凌晨至2014-09-25 21:53:56的所有更改，之后的数据，经业务确认，可以舍弃掉。或者后面再通过其他方法慢慢将这部分数据找出来。但是当务之急，是立马恢复数据库。

三、找备份及时间点

在备份的从库上检查备份：

crontab -l
#0 3 * * * /data/opdir/mysqlbak/backup_mysqldump.sh 6084 >> /data/opdir/mysqlbak/6084/mysql-bakup.log 2>&1

发现备份任务让注释了

查看备份文件：

<p>[root@localhost 6084]# ll</p><p>total 128</p><p>drwxr-xr-x 2 root root 4096 Aug 25 03:13 20140825</p><p>drwxr-xr-x 2 root root 4096 Aug 26 03:13 20140826</p><p>drwxr-xr-x 2 root root 4096 Aug 27 03:13 20140827</p><p>drwxr-xr-x 2 root root 4096 Aug 28 03:13 20140828</p><p>drwxr-xr-x 2 root root 4096 Aug 29 03:13 20140829</p><p>drwxr-xr-x 2 root root 4096 Aug 30 03:13 20140830</p><p>drwxr-xr-x 2 root root 4096 Aug 31 03:13 20140831</p><p>drwxr-xr-x 2 root root 4096 Sep  1 03:13 20140901</p><p>drwxr-xr-x 2 root root 4096 Sep  2 03:13 20140902</p><p>drwxr-xr-x 2 root root 4096 Sep  3 03:13 20140903</p><p>drwxr-xr-x 2 root root 4096 Sep  4 03:13 20140904</p><p>drwxr-xr-x 2 root root 4096 Sep  5 03:13 20140905</p><p>drwxr-xr-x 2 root root 4096 Sep  6 03:13 20140906</p><p>drwxr-xr-x 2 root root 4096 Sep  7 03:13 20140907</p><p>drwxr-xr-x 2 root root 4096 Sep  8 03:13 20140908</p><p>drwxr-xr-x 2 root root 4096 Sep  9 03:13 20140909</p><p>drwxr-xr-x 2 root root 4096 Sep 10 03:13 20140910</p><p>drwxr-xr-x 2 root root 4096 Sep 11 03:13 20140911</p><p>drwxr-xr-x 2 root root 4096 Sep 12 03:13 20140912</p><p>drwxr-xr-x 2 root root 4096 Sep 13 03:13 20140913</p><p>drwxr-xr-x 2 root root 4096 Sep 14 03:13 20140914</p><p>drwxr-xr-x 2 root root 4096 Sep 15 03:13 20140915</p><p>drwxr-xr-x 2 root root 4096 Sep 16 03:13 20140916</p><p>drwxr-xr-x 2 root root 4096 Sep 17 03:13 20140917</p><p>drwxr-xr-x 2 root root 4096 Sep 18 03:14 20140918</p><p>drwxr-xr-x 2 root root 4096 Sep 19 03:14 20140919</p><p>drwxr-xr-x 2 root root 4096 Sep 20 03:13 20140920</p><p>drwxr-xr-x 2 root root 4096 Sep 21 03:13 20140921</p><p>drwxr-xr-x 2 root root 4096 Sep 22 03:14 20140922</p><p><strong>drwxr-xr-x 2 root root 4096 Sep 23 18:33 20140923</strong></p><p>-rw-r--r-- 1 root root 5475 Sep 23 18:33 mysql-bakup.log</p>

备份只到20140923日，下午18:33分。

备份日志最后一段截取：

?tail -n 5 mysql-bakup.log
deleting backup of 30 days ago — 20140824
2014-09-23 18:19:12 begin backup …
20140824 deleted OK
2014-09-23 18:33:43 end backup …

因为这些表是在从库备份的，而且表都是MyiSAM的表。查看备份脚本，是先Stop Slave之后，才开始备份，因此从备份脚本输出的日志中找到备份开始的时间是：

2014-09-23 18:19:12

通过：

Drwxr-xr-x 2 root root 4096 Sep 23 18:33 20140923

可看到结束时间是：2014-09-23 18:33:00

现在考虑到底是以备份开始的时间：2014-09-23 18:19:12 为Start-DateTime还是以2014-09-23 18:33:00 为Start-DateTime。

前面提到备份脚本是从库进行备份的，是在2014-09-23 18:19:12开始的，在这个时刻备份开始，执行了Stop Slave；因此整个备份的状态反映的是从库2014-09-23 18:19:12 这个时间的状态。而且通过监控可以看到在这个时间点，从库的延迟为0，因此可以认为这个备份就是?主库在这个时间的备份。

NOTES：
（有人可能会因为从库上有Binlog，从库也会接受主库的Binlog之类的机制而造成混淆。这里要结合我们具体的备份方式和恢复方式来看，以选出正确的时间点。）

前面提到通过日志查到遭到篡改的时间为：2014-09-25?21:53:57，因此可以将2014-09-25?21:53:56作为Stop-DateTime

因此Binlog命令应该是这样：

<strong>mysqlbinlog --database=[db_name] --start-datetime='2014-09-23 </strong><strong>18:19:12</strong><strong>' --stop-datetime='2014-09-25 21:53:56' <br></strong><strong>[binlog_name] > binlog_name0000x.sql</strong>

四、具体的恢复操作

清楚了这些，具体的操作就简单了：

1.从备份机拷贝备份：

SCP:/data/MySQLbak/20140923/20140923.db_name.gz :/data/opdir/20140926

2.恢复测试机解压：

gunzip 20140923.db_name.gz

3.恢复测试机导入(测试恢复库中之前没有db_name这个库)：

MySQL -uroot -pxxxxxx -S /tmp/MySQL.sock

4.将主库的Binlog拷贝到恢复测试机：

查看主库Binlog

-rw-rw---- 1 MySQL MySQL  87669492 Sep 23 00:00 MySQL-bin.000469<br>-rw-rw---- 1 MySQL MySQL 268436559 Sep 23 04:20 MySQL-bin.000470<br>-rw-rw---- 1 MySQL MySQL 268435558 Sep 23 17:32 MySQL-bin.000471<br>-rw-rw---- 1 MySQL MySQL  37425262 Sep 24 00:00 MySQL-bin.000472<br>-rw-rw---- 1 MySQL MySQL 137389819 Sep 25 00:00 MySQL-bin.000473<br>-rw-rw---- 1 MySQL MySQL 147386521 Sep 26 00:00 MySQL-bin.000474<br>我们需要的Binlog时间段为：2014-09-23 18:28:00 至 2014-09-25 21:53:56<br>因此只需要：<br>-rw-rw---- 1 MySQL MySQL  37425262 Sep 24 00:00 MySQL-bin.000472<br>-rw-rw---- 1 MySQL MySQL 137389819 Sep 25 00:00 MySQL-bin.000473<br>-rw-rw---- 1 MySQL MySQL 147386521 Sep 26 00:00 MySQL-bin.000474

将这3个Binlog ?Copy过去：

SCP MySQL-bin.000472 :/data/opdir/20140926
SCP MySQL-bin.000473 :/data/opdir/20140926
SCP MySQL-bin.000474 :/data/opdir/20140926

5.使用MySQLBinlog 生成SQL脚本：

MySQLBinlog --database=[db_name] --start-datetime='2014-09-23 18:19:12' --stop-datetime='2014-09-25 21:53:56' <br>MySQL-bin.000472 > 472.SQL<br>MySQLBinlog --database=[db_name] --start-datetime='2014-09-23 18:19:12' --stop-datetime='2014-09-25 21:53:56' <br>MySQL-bin.000473 > 473.SQL<br>MySQLBinlog --database=[db_name] --start-datetime='2014-09-23 18:19:12' --stop-datetime='2014-09-25 21:53:56' <br>MySQL-bin.000474 > 474SQL

6.Binlog生成的SQL脚本导入：

待20140923.db_name导入到恢复测试库之后，将MySQLBinlog生成的SQL脚本导入到数据库中：

MySQL -uroot -pxxxxxx -S /tmp/MySQL.sock db_name MySQL -uroot -pxxxxxx -S /tmp/MySQL.sock db_name MySQL -uroot -pxxxxxx -S /tmp/MySQL.sock db_name

7.导入完成后检查数据正确性：

大致看一下数据的情况，然后可以通过时间字段来看一下情况：

MySQL> select max(createtime),max(updatetime) from table_name;<br>+-----------------+-----------------+<br>| max(createtime) | max(updatetime) |<br>+-----------------+-----------------+<br>|      1411648043 |      1411648043 |<br>+-----------------+-----------------+<br>1 row in set (0.00 sec)

时间差不多为晚上20:27了

这个判断，作为DBA，查看部分数据，只能起到辅助作用，具体的需要到底是否OK，需要业务开发的人来判断。

经过业务开发确认后，即可将该数据导出后，再导入到线上主库中。

8、将该库导出，并压缩：

MySQLdump -uroot -pxxxxxx -S /tmp/MySQL.sock -q db_name table_name > table_name.SQL

压缩：

gzip table_name.SQL

SCP 到主库（复制的时候，请将网络因素考虑进去，确认不会占用过多带宽而影响其他线上业务）

9.恢复测试的数据导入到线上主库中：

线上主库操作：

操作之前，最好让开发把应用业务那段先暂停，否则可能会影响导入。比如这个表示MyISAM的，应用那边如果不听有update进来，就会阻塞数据导入。

a、主库将原始被篡改的表改名：（不要上来就drop，先rename，后续确认没问题了再考虑drop，因为很多问题不是一瞬间就能全部反映上来的）

rename table_name to old_table_name;

b、解压：

gunzip table_name.SQL.gz

c、导入新表数据：

MySQL -uroot -pxxxxxx -S /tmp/MySQL.sock db_name

后面就需要开发来进一步验证数据是否 OK 了。验证没问题后，再启动应用程序。

原文地址：MySQL数据库遭到攻击篡改—使用备份和binlog进行数据恢复, 感谢原作者分享。

声明

この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

MySQLのストアドプロシージャとは何ですか？May 01, 2025 am 12:27 AM

ストアドプロシージャは、パフォーマンスを向上させ、複雑な操作を簡素化するためのMySQLのSQLステートメントを事前に拡大します。 1。パフォーマンスの改善：最初のコンピレーションの後、後続の呼び出しを再コンパイルする必要はありません。 2。セキュリティの改善：許可制御を通じてデータテーブルアクセスを制限します。 3.複雑な操作の簡素化：複数のSQLステートメントを組み合わせて、アプリケーションレイヤーロジックを簡素化します。

クエリキャッシュはMySQLでどのように機能しますか？May 01, 2025 am 12:26 AM

MySQLクエリキャッシュの実用的な原則は、選択クエリの結果を保存することであり、同じクエリが再度実行されると、キャッシュされた結果が直接返されます。 1）クエリキャッシュはデータベースの読み取りパフォーマンスを改善し、ハッシュ値を使用してキャッシュされた結果を見つけます。 2）単純な構成、mysql構成ファイルでquery_cache_typeとquery_cache_sizeを設定します。 3）SQL_NO_CACHEキーワードを使用して、特定のクエリのキャッシュを無効にします。 4）高周波更新環境では、クエリキャッシュがパフォーマンスボトルネックを引き起こし、パラメーターの監視と調整を通じて使用するために最適化する必要がある場合があります。

他のリレーショナルデータベースでMySQLを使用することの利点は何ですか？May 01, 2025 am 12:18 AM

MySQLがさまざまなプロジェクトで広く使用されている理由には、次のものがあります。1。複数のストレージエンジンをサポートする高性能とスケーラビリティ。 2。使いやすく、メンテナンス、シンプルな構成とリッチツール。 3。豊富なエコシステム、多数のコミュニティとサードパーティのツールサポートを魅了します。 4。複数のオペレーティングシステムに適したクロスプラットフォームサポート。

MySQLのデータベースアップグレードをどのように処理しますか？Apr 30, 2025 am 12:28 AM

MySQLデータベースをアップグレードする手順には次のものがあります。1。データベースをバックアップします。2。現在のMySQLサービスを停止します。3。MySQLの新しいバージョンをインストールします。アップグレードプロセス中に互換性の問題が必要であり、Perconatoolkitなどの高度なツールをテストと最適化に使用できます。

MySQLに使用できるさまざまなバックアップ戦略は何ですか？Apr 30, 2025 am 12:28 AM

MySQLバックアップポリシーには、論理バックアップ、物理バックアップ、増分バックアップ、レプリケーションベースのバックアップ、クラウドバックアップが含まれます。 1. Logical BackupはMySqldumpを使用してデータベースの構造とデータをエクスポートします。これは、小さなデータベースとバージョンの移行に適しています。 2.物理バックアップは、データファイルをコピーすることで高速かつ包括的ですが、データベースの一貫性が必要です。 3.インクリメンタルバックアップは、バイナリロギングを使用して変更を記録します。これは、大規模なデータベースに適しています。 4.レプリケーションベースのバックアップは、サーバーからバックアップすることにより、生産システムへの影響を減らします。 5. Amazonrdsなどのクラウドバックアップは自動化ソリューションを提供しますが、コストと制御を考慮する必要があります。ポリシーを選択するときは、データベースサイズ、ダウンタイム許容度、回復時間、および回復ポイントの目標を考慮する必要があります。

MySQLクラスタリングとは何ですか？Apr 30, 2025 am 12:28 AM

mysqlclusteringenhancesdatabaserobustnessnessnessnessnessnistandistributiondistributingdataacrossmultiplenodes.itesthendbenginefordatareplication andfaulttolerance、保証highavailability.setupinvolvesconfiguringmanagement、data、ssqlnodes、carefulmonitoringringandpe

MySQLのパフォーマンスのためにデータベーススキーマ設計を最適化するにはどうすればよいですか？Apr 30, 2025 am 12:27 AM

MySQLのデータベーススキーマ設計の最適化は、次の手順を通じてパフォーマンスを改善できます。1。インデックス最適化：一般的なクエリ列にインデックスを作成し、クエリのオーバーヘッドのバランスをとり、更新を挿入します。 2。テーブル構造の最適化：正規化または反通常化によりデータ冗長性を削減し、アクセス効率を改善します。 3。データ型の選択：Varcharの代わりにINTなどの適切なデータ型を使用して、ストレージスペースを削減します。 4。パーティション化とサブテーブル：大量のデータボリュームの場合、パーティション化とサブテーブルを使用してデータを分散させてクエリとメンテナンスの効率を改善します。

MySQLのパフォーマンスをどのように最適化できますか？Apr 30, 2025 am 12:26 AM

tooptimizemysqlperformance、soflowthesesteps：1）properindexingtospeedupqueries、2）useexplaintoanalyzeandoptimize Queryperformance、3）AductServerContingSettingStingsinginginnodb_buffer_pool_sizeandmax_connections、4）

See all articles

ホットAIツール

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

脱衣画像を無料で

Clothoff.io

AI衣類リムーバー

Video Face Swap

完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

ホットツール

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

MantisBT

Mantis は、製品の欠陥追跡を支援するために設計された、導入が簡単な Web ベースの欠陥追跡ツールです。 PHP、MySQL、Web サーバーが必要です。デモおよびホスティングサービスをチェックしてください。

mPDF

mPDF は、UTF-8 でエンコードされた HTML から PDF ファイルを生成できる PHP ライブラリです。オリジナルの作者である Ian Back は、Web サイトから「オンザフライ」で PDF ファイルを出力し、さまざまな言語を処理するために mPDF を作成しました。 HTML2FPDF などのオリジナルのスクリプトよりも遅く、Unicode フォントを使用すると生成されるファイルが大きくなりますが、CSS スタイルなどをサポートし、多くの機能強化が施されています。 RTL (アラビア語とヘブライ語) や CJK (中国語、日本語、韓国語) を含むほぼすべての言語をサポートします。ネストされたブロックレベル要素 (P、DIV など) をサポートします。