数据篡改即是对计算机网络数据进行修改、增加或删除，造成数据破坏。数据库数据被攻击了首先得查看是被删除了还是被篡改了?是否有备份数据，是否能够进行恢复并加固。本文来自数据库技术专家张正，主要描述了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进行数据恢复, 感谢原作者分享。
MySQL에 저장된 절차는 무엇입니까?May 01, 2025 am 12:27 AM저장된 절차는 성능을 향상시키고 복잡한 작업을 단순화하기 위해 MySQL에서 사전 컴파일 된 SQL 문입니다. 1. 성능 향상 : 첫 번째 편집 후 후속 통화를 다시 컴파일 할 필요가 없습니다. 2. 보안 향상 : 권한 제어를 통해 데이터 테이블 액세스를 제한합니다. 3. 복잡한 작업 단순화 : 여러 SQL 문을 결합하여 응용 프로그램 계층 로직을 단순화합니다.
쿼리 캐싱은 MySQL에서 어떻게 작동합니까?May 01, 2025 am 12:26 AMMySQL 쿼리 캐시의 작동 원리는 선택 쿼리 결과를 저장하는 것이며 동일한 쿼리가 다시 실행되면 캐시 된 결과가 직접 반환됩니다. 1) 쿼리 캐시는 데이터베이스 읽기 성능을 향상시키고 해시 값을 통해 캐시 된 결과를 찾습니다. 2) MySQL 구성 파일에서 간단한 구성, query_cache_type 및 query_cache_size를 설정합니다. 3) SQL_NO_CACHE 키워드를 사용하여 특정 쿼리의 캐시를 비활성화하십시오. 4) 고주파 업데이트 환경에서 쿼리 캐시는 성능 병목 현상을 유발할 수 있으며 매개 변수의 모니터링 및 조정을 통해 사용하기 위해 최적화해야합니다.
다른 관계형 데이터베이스를 통해 MySQL을 사용하면 어떤 장점이 있습니까?May 01, 2025 am 12:18 AMMySQL이 다양한 프로젝트에서 널리 사용되는 이유에는 다음이 포함됩니다. 1. 고성능 및 확장 성, 여러 스토리지 엔진을 지원합니다. 2. 사용 및 유지 관리, 간단한 구성 및 풍부한 도구; 3. 많은 지역 사회 및 타사 도구 지원을 유치하는 풍부한 생태계; 4. 여러 운영 체제에 적합한 크로스 플랫폼 지원.
MySQL에서 데이터베이스 업그레이드를 어떻게 처리합니까?Apr 30, 2025 am 12:28 AMMySQL 데이터베이스를 업그레이드하는 단계에는 다음이 포함됩니다. 1. 데이터베이스 백업, 2. 현재 MySQL 서비스 중지, 3. 새 버전의 MySQL 설치, 4. 새 버전의 MySQL 서비스 시작, 5. 데이터베이스 복구. 업그레이드 프로세스 중에 호환성 문제가 필요하며 Perconatoolkit과 같은 고급 도구를 테스트 및 최적화에 사용할 수 있습니다.
MySQL에 사용할 수있는 다른 백업 전략은 무엇입니까?Apr 30, 2025 am 12:28 AMMySQL 백업 정책에는 논리 백업, 물리적 백업, 증분 백업, 복제 기반 백업 및 클라우드 백업이 포함됩니다. 1. 논리 백업은 MySQLDump를 사용하여 데이터베이스 구조 및 데이터를 내보내며 소규모 데이터베이스 및 버전 마이그레이션에 적합합니다. 2. 물리적 백업은 데이터 파일을 복사하여 빠르고 포괄적이지만 데이터베이스 일관성이 필요합니다. 3. 증분 백업은 이진 로깅을 사용하여 변경 사항을 기록합니다. 이는 큰 데이터베이스에 적합합니다. 4. 복제 기반 백업은 서버에서 백업하여 생산 시스템에 미치는 영향을 줄입니다. 5. AmazonRDS와 같은 클라우드 백업은 자동화 솔루션을 제공하지만 비용과 제어를 고려해야합니다. 정책을 선택할 때 데이터베이스 크기, 가동 중지 시간 허용 오차, 복구 시간 및 복구 지점 목표를 고려해야합니다.
MySQL 클러스터링이란 무엇입니까?Apr 30, 2025 am 12:28 AMmysqlclusteringenhancesdatabaserobustness andscalabilitydaturedingdataacrossmultiplenodes.itusesthendbenginefordatareplicationandfaulttolerance, highavailability를 보장합니다
MySQL의 성능을 위해 데이터베이스 스키마 설계를 어떻게 최적화합니까?Apr 30, 2025 am 12:27 AMMySQL에서 데이터베이스 스키마 설계 최적화는 다음 단계를 통해 성능을 향상시킬 수 있습니다. 1. 인덱스 최적화 : 공통 쿼리 열에서 인덱스 생성, 쿼리의 오버 헤드 균형 및 업데이트 삽입. 2. 표 구조 최적화 : 정규화 또는 정상화를 통한 데이터 중복성을 줄이고 액세스 효율을 향상시킵니다. 3. 데이터 유형 선택 : 스토리지 공간을 줄이기 위해 Varchar 대신 Int와 같은 적절한 데이터 유형을 사용하십시오. 4. 분할 및 하위 테이블 : 대량 데이터 볼륨의 경우 파티션 및 하위 테이블을 사용하여 데이터를 분산시켜 쿼리 및 유지 보수 효율성을 향상시킵니다.
MySQL 성능을 어떻게 최적화 할 수 있습니까?Apr 30, 2025 am 12:26 AMtooptimizemysqlperformance, followthesesteps : 1) 구현 properIndexingToSpeedUpqueries, 2) useExplaintoAnalyzeanDoptimizeQueryPerformance, 3) AdvertServerConfigUrationSettingstingslikeInnodb_buffer_pool_sizeandmax_connections, 4) uspartOflEtOflEtOflestoI
핫 AI 도구
Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱
AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.
Undress AI Tool
무료로 이미지를 벗다
Clothoff.io
AI 옷 제거제
Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!
인기 기사
뜨거운 도구
에디트플러스 중국어 크랙 버전
작은 크기, 구문 강조, 코드 프롬프트 기능을 지원하지 않음
PhpStorm 맥 버전
최신(2018.2.1) 전문 PHP 통합 개발 도구
SecList
SecLists는 최고의 보안 테스터의 동반자입니다. 보안 평가 시 자주 사용되는 다양한 유형의 목록을 한 곳에 모아 놓은 것입니다. SecLists는 보안 테스터에게 필요할 수 있는 모든 목록을 편리하게 제공하여 보안 테스트를 더욱 효율적이고 생산적으로 만드는 데 도움이 됩니다. 목록 유형에는 사용자 이름, 비밀번호, URL, 퍼징 페이로드, 민감한 데이터 패턴, 웹 셸 등이 포함됩니다. 테스터는 이 저장소를 새로운 테스트 시스템으로 간단히 가져올 수 있으며 필요한 모든 유형의 목록에 액세스할 수 있습니다.
안전한 시험 브라우저
안전한 시험 브라우저는 온라인 시험을 안전하게 치르기 위한 보안 브라우저 환경입니다. 이 소프트웨어는 모든 컴퓨터를 안전한 워크스테이션으로 바꿔줍니다. 이는 모든 유틸리티에 대한 액세스를 제어하고 학생들이 승인되지 않은 리소스를 사용하는 것을 방지합니다.
스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경
