寻觅生命中的那一片浅草......

文章属于类别 安全

利用undrop-for-innodb恢复MySQL数据

这是一个MySQL数据恢复工具,我们尝试下恢复MySQL数据

1 环境说明

  • VMware 8H2G
  • CentOS 6.2 64bit
  • MySQL version: 5.7.17-11 Percona Server
  • 一个没有任何读写的测试数据库实例
  • innodb_file_per_table on

2 安装

比较简单

cd /dist/src
git clone https://github.com/twindb/undrop-for-innodb.git
cd undrop-for-innodb/
make
gcc `$basedir/bin/mysql_config --cflags` `$basedir/bin/mysql_config --libs` -o sys_parser sys_parser.c

3 环境准备

create database recover;
use recover;
CREATE TABLE `actor` (
  `actor_id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
  `first_name` varchar(45) NOT NULL,
  `last_name` varchar(45) NOT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`actor_id`),
  KEY `idx_actor_last_name` (`last_name`)
) ENGINE=InnoDB AUTO_INCREMENT=201 DEFAULT CHARSET=utf8;

insert into actor(first_name, last_name) values('zhang', 'jian');
insert into actor(first_name, last_name) values('zhan', 'jian');
insert into actor(first_name, last_name) values('zha', 'jian');
insert into actor(first_name, last_name) values('zh', 'jian');
insert into actor(first_name, last_name) values('z', 'jian');

checksum table actor;
+-----------+------------+
| Table     | Checksum   |
+-----------+------------+
| per.actor | 2184463059 |
+-----------+------------+
1 row in set (0.00 sec)

# 此处模拟误删除表
DROP TABLE actor;

4 开始恢复

由于我们有表结构SQL了,所以本例没有恢复表结构,参考资料中有恢复表结构的操作

避免磁盘被覆盖写

由于是innodb_file_per_table on,就是drop操作会直接删除文件,此时比较稳妥的处理是关掉所有服务,将文件系统挂载为只读,由于本例是测试环境,没有任何写入,所以没有做以下处理

/etc/init.d/mysql stop
# 或者加-f参数,不过好像比较暴力
mount -o remount,ro /data

开始在磁盘上查找InnoDB页文件

本操作会在/dist/src/undrop-for-innodb/生成pages-sda5

cd /dist/src/undrop-for-innodb/

# 73G为df -h显示的sda5的总大小
# 以下指令本例大概会消耗20+小时
./stream_parser -f /dev/sda5 -s 1G -t 73G

将ibdata1分页

此操作不会影响ibdata1,会在/dist/src/undrop-for-innodb/生成pages-ibdata1

./stream_parser -f /data/database/mysql/ibdata1 

获取TABLE ID

21616为TABLE ID

./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t dictionary/SYS_TABLES.sql  | grep 'recover/actor'  
00000001E113    2F0000018C08A0  SYS_TABLES      "recover/actor" 21616   4       33      0       80      ""      21619

获取INDEX ID

其中36728和36729为NDEX ID

./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000003.page -t dictionary/SYS_INDEXES.sql  | grep '21616'
00000001E113    2F0000018C071D  SYS_INDEXES     21616   36728   "PRIMARY"       1       3       21619   4294967295
00000001E113    2F0000018C078F  SYS_INDEXES     21616   36729   "idx\_actor\_last\_name"        1       0       21619   4294967295

恢复数据

根据上面找到的INDEX ID找到对应的pages,sakila/actor.sql为建表SQL文件,好像只需要用到36728这个INDEX ID

从输出可以看到,数据找回了

./c_parser -6f pages-sda5/FIL_PAGE_INDEX/0000000000036728.page -t sakila/actor.sql
-- Page id: 3, Format: COMPACT, Records list: Valid, Expected records: (5 5)
00000001E106    A6000001D60110  actor   201     "zhang" "jian"  "2017-12-04 15:58:38"
00000001E107    A7000002D30110  actor   202     "zhan"  "jian"  "2017-12-04 15:58:38"
00000001E109    A9000002D50110  actor   203     "zha"   "jian"  "2017-12-04 15:58:38"
00000001E10B    AA000002D60110  actor   204     "zh"    "jian"  "2017-12-04 15:58:38"
00000001E10E    AC000002D80110  actor   205     "z"     "jian"  "2017-12-04 15:58:38"

5 其他

  • 大内存和读写性能好的磁盘将有效加快恢复进度

6 参考资料

MySQL · 数据恢复 · undrop-for-innodb

github-undrop-for-innodb

https证书链

应同事要求,把git的地址修改成了https,应用后,浏览器访问是正常的,但git命令行访问时,偶尔会提示证书有问题:

Peer certificate cannot be authenticated with known CA certificates

遇到一两个反馈,就让他们禁用证书检查,或者改用ssh,但反馈多了,觉得这体验的确不够好,虽然安全和方便二者不可兼得,但我们这明明是Symantec颁发的权(mian)威(fei)证书,理论上不应该有问题才对。今天有空,就试着解决下。

犹记得(多么熟悉的三个字,其实是代表了年纪大)上次内网某https应用,有位同事用Chrome访问,死活都提示证书有问题,但其他人又正常,百思不得骑姐。后来是web同事发现并解决了问题,说是证书链不完整,去把中间证书下载回来,加到证书里就解决了。

本次估计也是,但怎么验证?如果是外网,直接用ssllabs_https_check,会打印完整证书链,将网站打印出来的证书和服务器上配置的进行对比,如果不一致,则证明少了中间证书。但我们是内网啊,这网站无法访问到,这时只能放狗+祭出openssl神器了。

查看证书

openssl s_client -showcerts -connect git.example.com:443 -servername git.example.com

Certificate chain节内容,如果下面的开头和结束只出现1次,则代表证书不完整

-----BEGIN CERTIFICATE-----
证书内容
-----END CERTIFICATE-----

至此,我们证实了只有1个证书了,那怎么加入中间证书?

  • 颁发机构一般有提供的
  • 如果当时的压缩包已经不知去向,如果你有2个https应用都是同一个CA颁发的,那么可以用上面openssl的方法去另外一个https应用拿

修改httpd配置,此处列出完整配置

<VirtualHost *:443>                                                                                                                 
    ServerName git.example.com
    CustomLog logs/git.example.com_access.log common
    SSLEngine on
    SSLCertificateFile "/etc/httpd/cert/git.example.com.crt"
    SSLCertificateKeyFile "/etc/httpd/cert/git.example.com.key"
    # 此配置为本次新添加
    SSLCertificateChainFile "/etc/httpd/cert/git.example.com_root_bundle.crt"
    SSLProtocol all -SSLv2 -SSLv3
    ProxyPreserveHost On
    ProxyRequests Off
<Location />
    ProxyPass http://127.0.0.1:8088/
    ProxyPassReverse http://127.0.0.1:8088/
</Location>
</VirtualHost>

最后优雅地重新加载配置

sudo /etc/init.d/httpd graceful

再次用openssl检测,此时服务器端已经返回了完整的证书链,git也正常了。BTW,https水太深了。

为什么浏览器正常呢?因为浏览器会递归请求证书,而递归请求其实很慢,所以也就有了- OCSP Stapling,简单说就是,服务器去帮你把中间证书请求了,一起返回给客户端。

zz:InnoDB个性化备份

来自云栖:InnoDB个性化备份
主要看下面,在slave上执行 stop slave,等一会,就可以通过cp目录的方式备份,好犀利

https简介及常见问题

没有太多情怀,本文主要是解决问题的

https安全的2大部分

  • 身份证明:主要证明server就是该域名的所有者,这里需要一个CA作中间人
  • 数据传输加密:非对称,对称加密

PKI架构

这里是身份证明部分

User, Server, CA,这三者是PKI中的三个角色。User方接收到Server发出的证书,并通过User自身客户端(浏览器或者其他APP等程序)内含的已信任CA(根证书)列表来做校验,只有证实该Server提供的https证书是已信任CA签发的,https通信才可以继续。

假设一个买电脑的情景:A要买电脑,A不熟悉,怕被骗,A知道朋友B对电脑这些很熟,所以他找了B,让B帮忙介绍靠谱的商家,于是B就介绍了商家C给A,后面的交易就是A和C之间(好像有点装…的感觉)进行。

上述A就是User,B就是CA,C就是Server

证书申请

申请证书时候,需要给CA机构提供证书签发申请CSR文件(certificate sigining request)。大部分支持https的web服务程序都可以生成CSR文件。步骤如下:

  1. 根据RSA算法生成公钥私钥对。私钥即需要机密保管的以.key为后缀名的文件,公钥则在.csr文件中。csr文件中还包括生成CSR过程中输入的组织名、域名、联系人邮箱等信息。
  2. 发送CSR文件给证书供应商,比如verisign。供应商对CSR文件做处理,设置有效期限等,并做最为关键的动作:用供应商自己的私钥对证书进行签名。这样就生成了一张有效的SSL证书。
  3. 用户收到证书后,在web服务器(或负载均衡等设备)上,以此前的私钥文件和收到的公钥证书为密钥对,生成SSL配置文件,并绑定到对应的web站点上

也可以让证书供应商直接生成私钥和签过名的证书

可以自建CA

原理和抓包分析

原理

HTTPS工作原理

知识点:

  • 前面协商阶段是非对称加密,后面数据通信的是对称加密

抓包分析

  • 上几个抓包的文件
  • 浏览器查看证书
  • 证书链:证书、中级证书、根证书
  • Record Layer
  • SSL vs TLS

他山之石

来到这里,发现我的表达是多么苍白无力

Nginx配置解析

# 1m可以处理4000个session
ssl_session_cache shared:SSL:20m;
# 缓存
ssl_session_timeout 10m;
# 设置HSTS
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
# Online Certificate Status Protocol,在线证书状态协议
ssl_stapling on
# openssl dhparam -out /data/conf/nginx/cert/dhparam.pem 2048
ssl_dhparam /data/conf/nginx/cert/dhparam.pem;

工具

命令行

# 检测远程服务器的证书
openssl s_client -connect google.com:443 | openssl x509 -text
nmap --script ssl-enum-ciphers -p 443 www.example.com
# 快速生成自签名的ssl证书,10年有效期
openssl req -new -x509 -nodes -out www.example.com.crt -keyout www.example.com.key -days 3650 -subj "/C=CN/ST=Guangdong/L=Guangzhou/O=Microhard/CN=wwww.example.com"
# 获取证书指纹
openssl x509 -fingerprint -in xxx.crt

web工具

检查网站https的安全性并打分,同时会提供建议

ssllabs_https_check

三种解密 HTTPS 流量的方法介绍

三种解密 HTTPS 流量的方法介绍

其他

  • DV SSL,证书信息里没有“组织”,或者“组织”显示的是域名
  • OV SSL,OV SSL证书是 Organization Validation SSL 的缩写,指需要验证网站所有单位的真实身份的标准型SSL证书,此类证书也就是正常的SSL证书,不仅能起到网站机密信息加密的作用,而且能向用户证明网站的真实身份。在证书信息里,可以看“组织”部分,显示的是公司名
  • EV SSL,EV SSL证书是Extended Validation SSL的缩写,指遵循全球统一的严格身份验证标准颁发的SSL证书,是目前业界最高安全级别的SSL证书。用户访问部署了EV SSL证书的网站,不仅浏览器地址栏会显示安全锁标志,而且浏览器地址栏会变成绿色。
  • openssl 0.9.8版本,不支持SNI,所以,如果一台机有多个443虚拟主机,则会有问题
  • Android从2.3开始支持SNI
  • 免费证书
  • OCSP Stapling
  • 来自Mozilla的指南:Server Side TLS
  • ssl加速卡,可以在淘宝上搜索「silicom ssl」
  • 证书的签名算法,主要是SHA1/SHA2,下面的命令,看「Signature Algorithm」,sha256代表是SHA2,老旧的浏览器会不支持SHA2
openssl s_client -connect www.example.com:443| openssl x509 -text
  • nginx实现SSL卸载,某些场景中,我们需要保证业务的安全可靠,因此难免需要使用HTTPS加密保护数据,但是除了在公网做SSL加密之外,内网之间的传输加密倒是意义不大,因此nginx的SSL加密负载就可以派上用场了

常见问题

证书链不完整

大部分同学可以打开,但有个同学就打不开,chrome也是最新版,最后发现是证书不完整,缺了个中级根证书

如果我们用ssllabs检查,它会直接给出提示

This server's certificate chain is incomplete. Grade capped to B.
# 证书路径里也有提示
Extra download

解决,当然是下载中级根证书添加了,可以去证书供应商,但更方便的方法是直接在测试页面下载,在页面右边,有个下载按钮,可以直接下载完整的证书

完整Nginx配置参考

server {
    listen 443 ssl;

    ssl_certificate /etc/nginx/cert/bjornjohansen.no.certchain.crt;
    ssl_certificate_key /etc/nginx/cert/bjornjohansen.no.key;

    ssl_session_cache shared:SSL:20m;
    ssl_session_timeout 60m;

    ssl_prefer_server_ciphers on;

    ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GC
M-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:EC
DHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-
RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;

    ssl_dhparam /etc/nginx/cert/dhparam.pem;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/nginx/cert/trustchain.crt;
    # resolver 8.8.8.8 8.8.4.4;

    #add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header Strict-Transport-Security "max-age=31536000" always;
}
2018年十二月
« 2月    
 12
3456789
10111213141516
17181920212223
24252627282930
31