Nginx 诡异 SSL_PROTOCOL_ERROR 问题排查

这两天在检查一台 Nginx 配置的时候,遇到了一个极端诡异的问题。一段很通用的配置,配在这个服务器上,就会 100% 导致 Chrome 报 ERR_SSL_PROTOCOL_ERROR 。但是这段配置非常的通用,是用 Mozilla 提供的工具生成的。

而且在 iPhone 的 Safari 上访问又是完全正常的,服务器日志也看不到任何错误。看到的请求相应码也是完全正确的 200 。

先贴出配置:

# https://mozilla.github.io/server-side-tls/ssl-config-generator/
    listen 443 ssl http2;

    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;


    # modern configuration. tweak to your needs.
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;

可以看到是在 Mozilla 网站上选择  和 Modern 生成出来的配置。

在测试过程中,排查了各种问题,包括但不限于 SSL 证书问题,HTTP Basic Auth 问题,http2 问题等等,然而都没有解决这个现象。

一次偶然的尝试,发现只要注释掉我给这个 server 特殊配置的这段逻辑,使用服务器通用的 ssl.ngx 文件中的 SSL 配置,就不会出现问题。于是开始先使用 ssl.ngx 文件中的配置,然后逐行替换,来查找具体出现问题的配置。

终于,当我将配置中的这行加上时,问题出现了:

ssl_session_tickets off;

于是以这个配置作为关键字搜索,找到了这么一篇文章:

https://community.letsencrypt.org/t/errors-from-browsers-with-ssl-session-tickets-off-nginx/18124/5

I’m posting this here both because this question was recently asked and because it took me many hours of troubleshooting to figure out the issue as while I found several references to the problem on Google, no one seemed to have a real solution. So here it is:

ssl_session_tokens off breaks if it’s not set the same for all ssl-enabled server{} blocks. So if you have 2 server configurations and and you have ssl_server_tokens set to on in one (which is the default so it counts even if you omit it) and set to off in another, it will break the one where it’s set to off in certain browsers. The easiest way to resolve this, unless you have multiple http{} blocks, is to just set it to off in the http{} block. I have not tested to see if you you can have different settings in different http{} blocks as I haven’t had need to set up more than one http{} block.

For others looking for this issue, I want to add that Chrome will respond with: ERR_SSL_PROTOCOL_ERROR while Firefox responds with: SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET and curl responds with: gnutls_handshake() failed: An unexpected TLS packet was received. IE seemed to work, surprisingly.

简单翻译一下,这里是说,如果你的 nginx 开了多个 https 的 server,其中某些 server 没有配置 ssl_server_tokens off; ,而有些 server 配置了这个选项,那么就会导致没有手动 off 的 server 采用默认值 on,而手动 off 掉的 server 采用 off。这种情况会导致 nginx 和浏览器之间的握手出现问题,从而导致 Chrome 报出 ERR_SSL_PROTOCOL_ERROR ,FireFox 则会报出 SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET 。

那么解决方法也很简单,只要在所有的 server 块统一这个配置就好了。要么都设置为 on,要么都设置为 off,问题解决。目前没有尝试多个 http 块隔离两个 server,建议还是将这个配置统一一下。

 

 

nginx rewrite 的一个小坑

今天在配置 Nginx 的时候写了这么一个 location

location /a {
    rewrite /a/(.*) /$1 break;
    ...
}

然后发现当我直接访问 /a 的时候,rewrite 并没有生效,后端收到的还是 /a 而不是我想象中的 / 。想了想可能是结尾 / 的问题,于是这样改:

location /a {
    rewrite /a(.*) $1 break;
    ...
}

结果新的问题来了,由于这样匹配到的 $1 是空的,所以 Nginx 报错了,the rewritten URI has a zero length

所以这种情况下只好这么写:

location /a/ {
    rewrite /a(.*) $1 break;
    ...
}

注意第一行的末尾 / 。这种情况下,访问 /a 会被 Nginx 自动重定向到 /a/ ,然后重写之后的 uri 就是 /,问题解决。

Nginx 配置 ECC RSA 双证书

Config Nginx for parallel ECC and RSA Certificate

先决条件

Nginx 1.11.0 以上

OpenSSL 1.0.2 以上

申请证书

首先申请 ECC 证书,这个不多说,很多方法都可以,大部分 CA 现在也都可以签署。生成 CSR 的命令是:

openssl ecparam -out 证书名.key -name prime256v1 -genkey && openssl req -new -key 证书名.key -nodes -out 证书名.csr

拿到证书之后,还是像之前一样将中级 CA 拼接在证书后面,得到给 Nginx 使用的 domain-cert.crt

配置 Nginx

首先是将两个证书链都加入 Nginx 的配置文件:

ssl_certificate     example.com.rsa.crt;
ssl_certificate_key example.com.rsa.key;

ssl_certificate     example.com.ecdsa.crt;
ssl_certificate_key example.com.ecdsa.key;

如果要使用 CT 的话有两种方法:

1. 将两个证书的 CT 信息放到同一目录,并做如下设置:

ssl_ct on;
ssl_ct_static_scts /path/to/sct/dir;

这样 Nginx CT 模块会自动在这个目录下查找相应证书的 CT 信息并发送

2. 可以单独配置每个证书的 CT 文件:

ssl_ct on;

ssl_certificate example.com.rsa.crt;
ssl_certificate_key example.com.rsa.key;
ssl_ct_static_scts xample.com.rsa.scts;

ssl_certificate example.com.ecdsa.crt;
ssl_certificate_key example.com.ecdsa.key;
ssl_ct_static_scts example.com.ecdsa.scts;

然后问题来了。很多盆友这么配置之后可能发现用 Chrome 之类的明明支持 ECC 的浏览器却并没有用 ECC 证书。这是为什么呢?

问题就出在  ssl_ciphers  这个配置项上面。

如果我们用各种网上推荐的配置,需要注意顺序问题。以 Cloud Flare 的配置为例:

#https://github.com/cloudflare/sslconfig/blob/master/conf
ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers                 EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers   on;

注意到这里面的算法都是优先使用 RSA 的,所以服务器和浏览器协商出来的一定是 RSA ,这就导致 Nginx 会自动发送 RSA 证书链给浏览器。

这里可以用 openssl 验证一下:

# openssl ciphers -V 'EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5' | column -t
0xC0,0x2F  -  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)  Mac=AEAD
0xC0,0x2B  -  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)  Mac=AEAD
0xC0,0x27  -  ECDHE-RSA-AES128-SHA256        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(128)     Mac=SHA256
0xC0,0x23  -  ECDHE-ECDSA-AES128-SHA256      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(128)     Mac=SHA256
0xC0,0x13  -  ECDHE-RSA-AES128-SHA           SSLv3    Kx=ECDH  Au=RSA    Enc=AES(128)     Mac=SHA1
0xC0,0x09  -  ECDHE-ECDSA-AES128-SHA         SSLv3    Kx=ECDH  Au=ECDSA  Enc=AES(128)     Mac=SHA1
0x00,0x9C  -  AES128-GCM-SHA256              TLSv1.2  Kx=RSA   Au=RSA    Enc=AESGCM(128)  Mac=AEAD
0x00,0x3C  -  AES128-SHA256                  TLSv1.2  Kx=RSA   Au=RSA    Enc=AES(128)     Mac=SHA256
0x00,0x2F  -  AES128-SHA                     SSLv3    Kx=RSA   Au=RSA    Enc=AES(128)     Mac=SHA1
0xC0,0x30  -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(256)  Mac=AEAD
0xC0,0x2C  -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(256)  Mac=AEAD
0xC0,0x28  -  ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(256)     Mac=SHA384
0xC0,0x24  -  ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(256)     Mac=SHA384
0xC0,0x14  -  ECDHE-RSA-AES256-SHA           SSLv3    Kx=ECDH  Au=RSA    Enc=AES(256)     Mac=SHA1
0xC0,0x0A  -  ECDHE-ECDSA-AES256-SHA         SSLv3    Kx=ECDH  Au=ECDSA  Enc=AES(256)     Mac=SHA1
0x00,0x9D  -  AES256-GCM-SHA384              TLSv1.2  Kx=RSA   Au=RSA    Enc=AESGCM(256)  Mac=AEAD
0x00,0x3D  -  AES256-SHA256                  TLSv1.2  Kx=RSA   Au=RSA    Enc=AES(256)     Mac=SHA256
0x00,0x35  -  AES256-SHA                     SSLv3    Kx=RSA   Au=RSA    Enc=AES(256)     Mac=SHA1
0xC0,0x12  -  ECDHE-RSA-DES-CBC3-SHA         SSLv3    Kx=ECDH  Au=RSA    Enc=3DES(168)    Mac=SHA1
0xC0,0x08  -  ECDHE-ECDSA-DES-CBC3-SHA       SSLv3    Kx=ECDH  Au=ECDSA  Enc=3DES(168)    Mac=SHA1
0x00,0x0A  -  DES-CBC3-SHA                   SSLv3    Kx=RSA   Au=RSA    Enc=3DES(168)    Mac=SHA1

会看到第一个选择就是使用 RSA,而不是椭圆曲线 ECDSA。

再来验证一下 Mozilla 给出的配置:

# openssl ciphers -V '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-GCM-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:ECDHE-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' | column -t 
0xC0,0x2B  -  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)  Mac=AEAD
0xC0,0x2F  -  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)  Mac=AEAD
0xC0,0x2C  -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(256)  Mac=AEAD
0xC0,0x30  -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(256)  Mac=AEAD
0x00,0x9E  -  DHE-RSA-AES128-GCM-SHA256      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(128)  Mac=AEAD
0x00,0x9F  -  DHE-RSA-AES256-GCM-SHA384      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(256)  Mac=AEAD
0xC0,0x23  -  ECDHE-ECDSA-AES128-SHA256      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(128)     Mac=SHA256
0xC0,0x27  -  ECDHE-RSA-AES128-SHA256        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(128)     Mac=SHA256
0xC0,0x09  -  ECDHE-ECDSA-AES128-SHA         SSLv3    Kx=ECDH  Au=ECDSA  Enc=AES(128)     Mac=SHA1
0xC0,0x28  -  ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(256)     Mac=SHA384
0xC0,0x13  -  ECDHE-RSA-AES128-SHA           SSLv3    Kx=ECDH  Au=RSA    Enc=AES(128)     Mac=SHA1
0xC0,0x24  -  ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(256)     Mac=SHA384
0xC0,0x0A  -  ECDHE-ECDSA-AES256-SHA         SSLv3    Kx=ECDH  Au=ECDSA  Enc=AES(256)     Mac=SHA1
0xC0,0x14  -  ECDHE-RSA-AES256-SHA           SSLv3    Kx=ECDH  Au=RSA    Enc=AES(256)     Mac=SHA1
0x00,0x67  -  DHE-RSA-AES128-SHA256          TLSv1.2  Kx=DH    Au=RSA    Enc=AES(128)     Mac=SHA256
0x00,0x33  -  DHE-RSA-AES128-SHA             SSLv3    Kx=DH    Au=RSA    Enc=AES(128)     Mac=SHA1
0x00,0x6B  -  DHE-RSA-AES256-SHA256          TLSv1.2  Kx=DH    Au=RSA    Enc=AES(256)     Mac=SHA256
0x00,0x39  -  DHE-RSA-AES256-SHA             SSLv3    Kx=DH    Au=RSA    Enc=AES(256)     Mac=SHA1
0xC0,0x08  -  ECDHE-ECDSA-DES-CBC3-SHA       SSLv3    Kx=ECDH  Au=ECDSA  Enc=3DES(168)    Mac=SHA1
0xC0,0x12  -  ECDHE-RSA-DES-CBC3-SHA         SSLv3    Kx=ECDH  Au=RSA    Enc=3DES(168)    Mac=SHA1
0x00,0x16  -  EDH-RSA-DES-CBC3-SHA           SSLv3    Kx=DH    Au=RSA    Enc=3DES(168)    Mac=SHA1
0x00,0x9C  -  AES128-GCM-SHA256              TLSv1.2  Kx=RSA   Au=RSA    Enc=AESGCM(128)  Mac=AEAD
0x00,0x9D  -  AES256-GCM-SHA384              TLSv1.2  Kx=RSA   Au=RSA    Enc=AESGCM(256)  Mac=AEAD
0x00,0x3C  -  AES128-SHA256                  TLSv1.2  Kx=RSA   Au=RSA    Enc=AES(128)     Mac=SHA256
0x00,0x3D  -  AES256-SHA256                  TLSv1.2  Kx=RSA   Au=RSA    Enc=AES(256)     Mac=SHA256
0x00,0x2F  -  AES128-SHA                     SSLv3    Kx=RSA   Au=RSA    Enc=AES(128)     Mac=SHA1
0x00,0x35  -  AES256-SHA                     SSLv3    Kx=RSA   Au=RSA    Enc=AES(256)     Mac=SHA1
0x00,0x0A  -  DES-CBC3-SHA                   SSLv3    Kx=RSA   Au=RSA    Enc=3DES(168)    Mac=SHA1

在这份配置中可以看到,每种套件中使用椭圆曲线部分都被排在了 RSA 前面,所以能尽量协商出支持椭圆曲线的算法。

或者我们还可以更激进一些:

# openssl ciphers -V 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK' | column -t
0xC0,0x2B  -  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AESGCM(128)    Mac=AEAD
0xC0,0x2C  -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AESGCM(256)    Mac=AEAD
0xC0,0x23  -  ECDHE-ECDSA-AES128-SHA256      TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AES(128)       Mac=SHA256
0xC0,0x09  -  ECDHE-ECDSA-AES128-SHA         SSLv3    Kx=ECDH        Au=ECDSA  Enc=AES(128)       Mac=SHA1
0xC0,0x24  -  ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AES(256)       Mac=SHA384
0xC0,0x0A  -  ECDHE-ECDSA-AES256-SHA         SSLv3    Kx=ECDH        Au=ECDSA  Enc=AES(256)       Mac=SHA1
0xC0,0x2F  -  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH        Au=RSA    Enc=AESGCM(128)    Mac=AEAD
0xC0,0x30  -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH        Au=RSA    Enc=AESGCM(256)    Mac=AEAD
0x00,0x9E  -  DHE-RSA-AES128-GCM-SHA256      TLSv1.2  Kx=DH          Au=RSA    Enc=AESGCM(128)    Mac=AEAD
0x00,0xA2  -  DHE-DSS-AES128-GCM-SHA256      TLSv1.2  Kx=DH          Au=DSS    Enc=AESGCM(128)    Mac=AEAD
0x00,0xA3  -  DHE-DSS-AES256-GCM-SHA384      TLSv1.2  Kx=DH          Au=DSS    Enc=AESGCM(256)    Mac=AEAD
0x00,0x9F  -  DHE-RSA-AES256-GCM-SHA384      TLSv1.2  Kx=DH          Au=RSA    Enc=AESGCM(256)    Mac=AEAD
0xC0,0x27  -  ECDHE-RSA-AES128-SHA256        TLSv1.2  Kx=ECDH        Au=RSA    Enc=AES(128)       Mac=SHA256
0xC0,0x13  -  ECDHE-RSA-AES128-SHA           SSLv3    Kx=ECDH        Au=RSA    Enc=AES(128)       Mac=SHA1
0xC0,0x28  -  ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH        Au=RSA    Enc=AES(256)       Mac=SHA384
0xC0,0x14  -  ECDHE-RSA-AES256-SHA           SSLv3    Kx=ECDH        Au=RSA    Enc=AES(256)       Mac=SHA1
0x00,0x67  -  DHE-RSA-AES128-SHA256          TLSv1.2  Kx=DH          Au=RSA    Enc=AES(128)       Mac=SHA256
0x00,0x33  -  DHE-RSA-AES128-SHA             SSLv3    Kx=DH          Au=RSA    Enc=AES(128)       Mac=SHA1
0x00,0x40  -  DHE-DSS-AES128-SHA256          TLSv1.2  Kx=DH          Au=DSS    Enc=AES(128)       Mac=SHA256
0x00,0x6B  -  DHE-RSA-AES256-SHA256          TLSv1.2  Kx=DH          Au=RSA    Enc=AES(256)       Mac=SHA256
0x00,0x38  -  DHE-DSS-AES256-SHA             SSLv3    Kx=DH          Au=DSS    Enc=AES(256)       Mac=SHA1
0x00,0x39  -  DHE-RSA-AES256-SHA             SSLv3    Kx=DH          Au=RSA    Enc=AES(256)       Mac=SHA1
0x00,0x9C  -  AES128-GCM-SHA256              TLSv1.2  Kx=RSA         Au=RSA    Enc=AESGCM(128)    Mac=AEAD
0x00,0x9D  -  AES256-GCM-SHA384              TLSv1.2  Kx=RSA         Au=RSA    Enc=AESGCM(256)    Mac=AEAD
0x00,0x3C  -  AES128-SHA256                  TLSv1.2  Kx=RSA         Au=RSA    Enc=AES(128)       Mac=SHA256
0x00,0x3D  -  AES256-SHA256                  TLSv1.2  Kx=RSA         Au=RSA    Enc=AES(256)       Mac=SHA256
0x00,0x2F  -  AES128-SHA                     SSLv3    Kx=RSA         Au=RSA    Enc=AES(128)       Mac=SHA1
0x00,0x35  -  AES256-SHA                     SSLv3    Kx=RSA         Au=RSA    Enc=AES(256)       Mac=SHA1
0x00,0x6A  -  DHE-DSS-AES256-SHA256          TLSv1.2  Kx=DH          Au=DSS    Enc=AES(256)       Mac=SHA256
0xC0,0x32  -  ECDH-RSA-AES256-GCM-SHA384     TLSv1.2  Kx=ECDH/RSA    Au=ECDH   Enc=AESGCM(256)    Mac=AEAD
0xC0,0x2E  -  ECDH-ECDSA-AES256-GCM-SHA384   TLSv1.2  Kx=ECDH/ECDSA  Au=ECDH   Enc=AESGCM(256)    Mac=AEAD
0xC0,0x2A  -  ECDH-RSA-AES256-SHA384         TLSv1.2  Kx=ECDH/RSA    Au=ECDH   Enc=AES(256)       Mac=SHA384
0xC0,0x26  -  ECDH-ECDSA-AES256-SHA384       TLSv1.2  Kx=ECDH/ECDSA  Au=ECDH   Enc=AES(256)       Mac=SHA384
0xC0,0x0F  -  ECDH-RSA-AES256-SHA            SSLv3    Kx=ECDH/RSA    Au=ECDH   Enc=AES(256)       Mac=SHA1
0xC0,0x05  -  ECDH-ECDSA-AES256-SHA          SSLv3    Kx=ECDH/ECDSA  Au=ECDH   Enc=AES(256)       Mac=SHA1
0x00,0x32  -  DHE-DSS-AES128-SHA             SSLv3    Kx=DH          Au=DSS    Enc=AES(128)       Mac=SHA1
0xC0,0x31  -  ECDH-RSA-AES128-GCM-SHA256     TLSv1.2  Kx=ECDH/RSA    Au=ECDH   Enc=AESGCM(128)    Mac=AEAD
0xC0,0x2D  -  ECDH-ECDSA-AES128-GCM-SHA256   TLSv1.2  Kx=ECDH/ECDSA  Au=ECDH   Enc=AESGCM(128)    Mac=AEAD
0xC0,0x29  -  ECDH-RSA-AES128-SHA256         TLSv1.2  Kx=ECDH/RSA    Au=ECDH   Enc=AES(128)       Mac=SHA256
0xC0,0x25  -  ECDH-ECDSA-AES128-SHA256       TLSv1.2  Kx=ECDH/ECDSA  Au=ECDH   Enc=AES(128)       Mac=SHA256
0xC0,0x0E  -  ECDH-RSA-AES128-SHA            SSLv3    Kx=ECDH/RSA    Au=ECDH   Enc=AES(128)       Mac=SHA1
0xC0,0x04  -  ECDH-ECDSA-AES128-SHA          SSLv3    Kx=ECDH/ECDSA  Au=ECDH   Enc=AES(128)       Mac=SHA1
0x00,0x88  -  DHE-RSA-CAMELLIA256-SHA        SSLv3    Kx=DH          Au=RSA    Enc=Camellia(256)  Mac=SHA1
0x00,0x87  -  DHE-DSS-CAMELLIA256-SHA        SSLv3    Kx=DH          Au=DSS    Enc=Camellia(256)  Mac=SHA1
0x00,0x84  -  CAMELLIA256-SHA                SSLv3    Kx=RSA         Au=RSA    Enc=Camellia(256)  Mac=SHA1
0x00,0x45  -  DHE-RSA-CAMELLIA128-SHA        SSLv3    Kx=DH          Au=RSA    Enc=Camellia(128)  Mac=SHA1
0x00,0x44  -  DHE-DSS-CAMELLIA128-SHA        SSLv3    Kx=DH          Au=DSS    Enc=Camellia(128)  Mac=SHA1
0x00,0x41  -  CAMELLIA128-SHA                SSLv3    Kx=RSA         Au=RSA    Enc=Camellia(128)  Mac=SHA1

可以看到在这份配置中,我几乎将所有的支持椭圆曲线的套件都提到了最前面,来加大协商出支持椭圆曲线算法的套件的可能性。

综上,推荐的配置如下:

ssl_ciphers 'EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:!MD5';
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-GCM-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:ECDHE-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_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';

三者任选其一即可。

 

参考:

https://imququ.com/post/ecc-certificate.html

https://www.zeroling.com/nginx-kai-qi-https-shuang-zheng-shu-zhi-nan/

https://n4l.pw/nginx-dual-certificates.html

https://imququ.com/post/certificate-transparency.html

https://seryo.net/use-ecc-algorithms-issued-a-certificate-request-file.Seryo

Nginx 配置 403 Error Page

今天遇到一个很有意思的问题,就是给 Nginx 配置 403 时候的错误页面。因为这台 Nginx 针对访问 IP 做了一些限制,所以需要给无权限访问的用户展示一个友好的界面。

一开始我的设置是这么写的:

...
allow 10.0.0.0/24;
allow 192.168.0.0/24;
deny 1.2.3.4;
deny 2.3.4.5;

error_page 403 /403.html;
...

可是实际使用发现,无论如何 Nginx 展示的都是内置 Hard Code 进去的那个 404 页面,并不是我想让他展示的友好的界面。

在排除了各种文件权限之类的错误之后,我 Google 了一下发现,这个真正的原因在于前面配置的 deny 不仅 deny 掉了正常页面的访问,同时也将对 /404.html 页面的访问也 deny 掉了。

所以正确的配置是加上下面几句:

location = /403.html {
    root /path/to/403/page/;
    allow all;
    internal;
}

通过强制允许访问 /403.html 的方式来避免这个错误。下面加上 internal 的意思是这个页面不能被正常的访问到,只能因为 error_page 等内部原因而被访问到。详见这里

使用 Nginx 反代 Apache 安装 WordPress

最近由于原先博客主机极度不稳定,所以准备了很久,准备进行主机迁移。由于迁移前的环境和迁移后还是有较大的区别,整体架构也不太一样,所以在这里说说迁移过程中遇到的问题。

环境对比

原主机 新主机
操作系统 CentOS 6 CentOS 7
Web 服务器 Apache 2.2 Openresty 1.9.7 + Apache 2.4
PHP 版本 5.5 5.6
其他 SELinux

SELinux

很多人为了省事,在拿到主机的第一时间就直接禁用了 SELinux。不过在学习了一段时间之后,我发现其实 SELinux 是一个很好的保护机器的手段。

这里简单列举几个需要注意的 SELinux 的配置:

 

httpd_can_network_connect_db boolean 类型,控制 Apache 是否可以连接 DB
http_port_t port 类型,控制 Apache 可以监听的端口
mysqld_port_t port 类型,控制 mysql 可以监听的端口和 Apache 可以连接的 DB 端口

由于我是将 Apache 作为只解析后端 PHP 请求使用,所以需要修改 http_port_t 加入我需要的端口。添加方法类似于:

semanage port -a -t http_port_t  -p tcp 8090

另外由于我没有在本机安装 Mysql 而是使用的远程 Mysql 实例,并且开放的端口并不是标准的 3306,所以需要将端口号添加到 mysqld_port_t 中。

Apache

这玩意是主要的坑所在。下面来一一列举。

配置格式变更

Apache 2.2 和 2.4 的配置文件区别还是比较大的,加了很多新的参数,同时修改了很多配置的方法。最明显的是:

Options -Indexes

Allow from all
Deny from all

这三条配置已经完全被改掉了。如果在配置中出现第一种,会直接起不来。后面的 Allow Deny 的写法虽然不会有问题,但是已经不是官方推荐的了,建议改掉。

配置无效

在配置 Apache 2.4 的 Log Format 的时候,我发现了一个很蛋疼的问题,就是 CentOS yum 安装的版本(2.4.6)有些配置是使用不了的。如:

http://httpd.apache.org/docs/2.4/mod/mod_log_config.html

这个文档中的:

%{UNIT}T	The time taken to serve the request, in a time unit given by UNIT. Valid units are ms for milliseconds, us for microseconds, and s for seconds. Using s gives the same result as %T without any format; using us gives the same result as %D. Combining %T with a unit is available in 2.4.13 and later.

很多参数都有类似的标注(available in 2.4.13 and later),告诉你在旧版本中不能使用。如果不仔细看的话很容易忽略。所以配置之前一定要仔细阅读。

HTTPS

WordPress

由于我的博客是全站 HTTPS 的,因此在 WordPress 上我是有做一些强制 HTTPS 的措施。但是!由于 WordPress 默认的检测 HTTPS 的方法是这样的:

/**
 * Determine if SSL is used.
 *
 * @since 2.6.0
 *
 * @return bool True if SSL, false if not used.
 */
function is_ssl() {
        if ( isset($_SERVER['HTTPS']) ) {
                if ( 'on' == strtolower($_SERVER['HTTPS']) )
                        return true;
                if ( '1' == $_SERVER['HTTPS'] )
                        return true;
        } elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
                return true;
        }
        return false;
}

而我的 HTTPS 是在 Nginx 层做的,所以导致这两个条件均不满足,因此会遇到重定向循环(Redirect Loop)的问题。解决方法有两种:

修改 wp-config.php 文件:

if ( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && ( 'https' == $_SERVER['HTTP_X_FORWARDED_PROTO'] ) ) {
    $_SERVER['HTTPS'] = 'on';
}

这里的修改需要配合修改 Nginx 的 Proxy 设置,增加下面这行:

proxy_set_header X-Request-Protocol $scheme; #http or https

修改 wp-includes/functions.php 文件(4025行左右):

找到上面说的那段代码,将其替换为:

/**
 * Determine if SSL is used.
 *
 * @since 2.6.0
 *
 * @return bool True if SSL, false if not used.
 */
function is_ssl() {
        if ( isset($_SERVER['HTTPS']) ) {
                if ( 'on' == strtolower($_SERVER['HTTPS']) )
                        return true;
                if ( '1' == $_SERVER['HTTPS'] )
                        return true;
        } elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
                return true;
        } elseif ( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && ( 'https' == $_SERVER['HTTP_X_FORWARDED_PROTO'] ) ) {
                return true;
        }
        return false;
}

同时这个修改方法也要配合修改 Nginx 的 Proxy 设置。

注意,虽然可以不做判断直接无脑 $_SERVER[‘HTTPS’] = ‘on’; 或者在那个 is_ssl() 方法中无脑返回 true,但是不建议这样修改。因为这样可能会导致安全上面的问题。

Apache .htaccess

由于我在某些目录中通过 .htaccess 的方式强制重定向了非 HTTPS 请求,因此在将 SSL 交给 Nginx 之后相关的跳转判断也要修改。原先的跳转逻辑是:

RewriteEngine on
RewriteCond   %{HTTPS} !=on
RewriteRule   ^(.*)  https://%{SERVER_NAME}/$1 [L,R]

由于 %{HTTPS} 这个变量判断的是 Apache 传进来的内部参数,我们无法控制,所以需要将这段修改为:

RewriteEngine on
RewriteCond %{HTTP:X-Request-Protocol} ^http$
RewriteRule   ^(.*)  https://%{SERVER_NAME}/$1 [L,R]

这里判断的就是 Nginx 传进来的 X-Request-Protocol 头了。不过这种写法并不能在单独使用 Apache 作为 Web 服务器的时候使用,需要注意。

客户端证书

目前只针对某目录或文件的客户端证书配置还没有测试完成,将在后面更新。

Compiling Nginx with HTTP/2 and ALPN

To have HTTP/2 fully supported in Nginx, you will need OpenSSL 1.0.2+ to have APLN enabled (What is APLN)

Unfortunately, nowadays most linux distributions are shipping with older version of OpenSSL. For example Ubuntu 14.04 is using openssl 1.0.1f

I can also use 3rd party repositories but I couldn’t find out something I think it is trusted

So it leaves me with only one option: compiling from source

Good thing is, it is pretty easy to compile nginx with a custom OpenSSL. You don’t even have to compile the OpenSSL and install into the system (which could break your system dependences)

All you have to do are:

  1. Download the latest stable OpenSSL from https://www.openssl.org/source/ and extract the tar
  2. Download the latest stable nginx from http://nginx.org/en/download.html and extract the tar
  3. Go into nginx source folder and
    ./configure --with-openssl=/path/to/openssl-1.0.2f --with-http_ssl_module --with-http_v2_module
    make && make install
    • Note: –with-openssl points to the openssl source folder instead of the installation folder
  4. Enable HTTP/2 in nginx configure file

That’s it

And here is how you can verify if your website is now supporting HTTP/2 and ALPN

echo |  /usr/local/ssl/bin/openssl s_client -alpn h2 -connect c11e.wodemo.com:443 | grep ALPN

Which will report

  • “ALPN protocol: h2”
  • or “No ALPN negotiated”

SSL 双向认证的一个小问题

最近一直在研究 SSL 双向认证,工作中也经常用到。然后今天遇到了一个非常奇怪的问题,那就是就算配置了

ssl_verify_client optional_no_ca

客户端的访问仍然会失败,证书认证仍然不过。调试了半天,发现了两个问题,那就是:
1. optional_no_ca 并不会像 off 一样放过所有请求,而是对于提交了证书的请求,如果证书验证不过就会握手出错
2. 对于下面这个配置项的设置存在错误:

ssl_verify_depth 1

经过查找资料,找到了这个选项相关的一些说明。(注:以下实验均在 Nginx 和 Apache2.2 上同时进行过)

The depth actually is the maximum number of intermediate certificate issuers, i.e. the number of CA certificates which are max allowed to be followed while verifying the client certificate. A depth of 0 means that self-signed client certificates are accepted only, the default depth of 1 means the client certificate can be self-signed or has to be signed by a CA which is directly known to the server (i.e. the CA’s certificate is under SSLCACertificatePath), etc.

也就是说,当 depth 设置为 1(Nginx 的默认值)的时候,服务端只会接受直接被 CA 签发的客户端证书或自签名的证书。
但是!这段话没说的是,当你放在 SSLCACertificatePath 的文件中的 CA 证书只有中级 CA 的时候,验证仍然是会不过的,看后台的报错会发现:(下面这个是 Apache 的日志,Nginx 的只有 “Error (2): unable to get issuer certificate” 一句)

[Wed Feb 24 04:19:39.975324 2016] [ssl:debug] [pid 13380] ssl_engine_kernel.c(1381): [client xx.xx.xx.xx:48806] AH02275: Certificate Verification, depth 1, CRL checking mode: none [subject: CN=IMM_CA,OU=ROOT,O=ROOT,ST=SH,C=CN / issuer: CN=ST,OU=UP,O=ROOT,ST=SH,C=CN / serial: 02 / notbefore: Jan 14 10:31:00 2013 GMT / notafter: Jan 14 10:31:00 2017 GMT]
[Wed Feb 24 04:19:39.975409 2016] [ssl:info] [pid 13380] [client xx.xx.xx.xx:48806] AH02276: Certificate Verification: Error (2): unable to get issuer certificate [subject: CN=IMM_CA,OU=ROOT,O=ROOT,ST=SH,C=CN / issuer: CN=ROOT_CA,OU=ROOT,O=ROOT,ST=SH,C=CN / serial: 02 / notbefore: Jan 14 10:31:00 2013 GMT / notafter: Jan 14 10:31:00 2017 GMT]

也就是说,直接尝试使用中级 CA 来验证客户端是无法通过的,openssl 会自动的去找中级 CA 的签发者一层层验证上去,直到找到根。
所以,就算将 中级 CA 和 根 CA 都放在信任证书列表中,由于最终 depth 为 2 的缘故,验证还是过不了。

因此,在实际使用的时候,需要注意一下两点:
1. CA 文件中必须同时存在 中级 CA 和 根 CA,必须构成完整证书链,不能少任何一个;
2. 默认的验证深度 SslVerifyDepth ssl_verify_depth 是 1,也就是说只要是中级 CA 签发的客户端证书一律无法通过认证,需要增大该值。

同时还要注意 optional_no_ca 的问题,开了这个选项并不是会放过所有的请求,也会要求证书链完整才能通过。关于这一点个人比较奇怪,因为证书链完整了那就算开 require 应该也能通过了才对。。。
关于这一点做了一些尝试发现以下两种情况:
1. 如果 SSLCACertificateFile/ssl_trusted_certificate SSLCACertificatePath 这两个参数都不设置,那么 optional_no_ca 会放过所有有效的客户端证书(满足客户端证书的基本条件即可);
2. 如果 SSLCACertificateFile/ssl_trusted_certificate SSLCACertificatePath 这两个参数设置了,但是客户端提交的证书并不是这里的 CA 签发的,也会验证成功
但是!如果 SSLCACertificateFile/ssl_trusted_certificate SSLCACertificatePath 这两个参数里设置的证书包括了中级 CA 证书,但是没有包括中级 CA 证书的完整证书链,那么就会报 Error (2): unable to get issuer certificate 错误,验证失败。

Nginx限制每个IP或虚拟机的并发连接数

摘自http://nginx.org/cn/docs/http/ngx_http_limit_conn_module.html

ngx_http_limit_conn_module 模块可以按照定义的键限定每个键值的连接数。特别的,可以设定单一 IP 来源的连接数。

并不是所有的连接都会被模块计数;只有那些正在被处理的请求(这些请求的头信息已被完全读入)所在的连接才会被计数。

配置范例

http {
limit_conn_zone $binary_remote_addr zone=addr:10m;

...

server {

...

location /download/ {
limit_conn addr 1;
}

指令

语法: limit_conn zone number;
默认值: —
上下文: http, server, location
指定一块已经设定的共享内存空间,以及每个给定键值的最大连接数。当连接数超过最大连接数时,服务器将会返回 503 (Service Temporarily Unavailable) 错误。比如,如下配置

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
location /download/ {
limit_conn addr 1;
}

表示,同一 IP 同一时间只允许有一个连接。

当多个 limit_conn 指令被配置时,所有的连接数限制都会生效。比如,下面配置不仅会限制单一IP来源的连接数,同时也会限制单一虚拟服务器的总连接数:

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;

server {
...
limit_conn perip 10;
limit_conn perserver 100;
}

 

如果当前配置层级没有limit_conn指令,将会从更高层级继承连接限制配置。

语法: limit_conn_log_level info | notice | warn | error;
默认值:
limit_conn_log_level error;
上下文: http, server, location
这个指令出现在版本 0.8.18.
指定当连接数超过设定的最大连接数,服务器限制连接时的日志等级。

语法: limit_conn_zone $variable zone=name:size;
默认值: —
上下文: http
设定保存各个键的状态的共享内存空间的参数。键的状态中保存了当前连接数。键的值可以是特定变量的任何非空值(空值将不会被考虑)。 使用范例:

limit_conn_zone $binary_remote_addr zone=addr:10m;
这里,设置客户端的IP地址作为键。注意,这里使用的是$binary_remote_addr变量,而不是$remote_addr变量。$remote_addr变量的长度为7字节到15字节不等,而存储状态在32位平台中占用32字节或64字节,在64位平台中占用64字节。而$binary_remote_addr变量的长度是固定的4字节,存储状态在32位平台中占用32字节或64字节,在64位平台中占用64字节。一兆字节的共享内存空间可以保存3.2万个32位的状态,1.6万个64位的状态。如果共享内存空间被耗尽,服务器将会对后续所有的请求返回 503 (Service Temporarily Unavailable) 错误。

语法: limit_zone name $variable size;
默认值: —
上下文: http
这条指令在 1.1.8 版本中已经被废弃,应该使用等效的limit_conn_zone指令。该指令的语法也有变化:
limit_conn_zone $variable zone=name:size;

Nginx的WordPress中文rewrite规则

 location / {
            root   /www;
            index  index.php index.html index.htm;
            if (-f $request_filename/index.html){
                    rewrite (.*) $1/index.html break;
            }
            if (-f $request_filename/index.php){
                    rewrite (.*) $1/index.php;
            }
            if (!-f $request_filename){
                    rewrite (.*) /index.php;
            }
        }

 

完美支持中文,亲测成功。添加在Location{}中间。

LNMP一键安装包-CentOS 5/6下自动编译安装Nginx,MySQL,PHP

适用环境:

  • 系统支持:CentOS-5 (32bit/64bit)、CentOS-6 (32bit/64bit)
  • 内存要求:≥128M

安装了什么:

  • 1、Nginx-1.2.0
  • 2、MySQL 5.5.24
  • 3、PHP 5.2.17或PHP 5.3.13
  • 4、phpmyadmin 3.5.1
  • 5、ZendOptimizer 3.3.9(可选,只适合PHP 5.2.17)
  • 6、xcache-2.0.0(可选)
  • 7、pure-ftpd-1.0.36(可选)

安全设置

  • 1、使用php-fpm chroot功能使网站与系统完全隔离,起到保护系统及其它虚拟主机的作用
  • 2、修复php-5.2.17 hash dos漏洞
  • 3、优化php.ini文件增强php安全性
  • 4、自动配置规则严格的防火墙
  • 5、使用ddos deflate预防简单的ddos和cc攻击
  • 6、fail2ban阻止暴力破解sshd或pureftpd等
  • 7、源码md5检测,保证源码的安全

如何安装:

  1. wget http://centos.googlecode.com/files/lnmp0.5.2.tar.gz
  2. tar xzf lnmp0.5.2.tar.gz && cd lnmp0.5.2 && chmod +x lnmp.sh && ./lnmp.sh

安装其它

1、执行脚本pureftpd.sh安装pureftpd。
2、执行脚本xcache.sh安装xcache。
3、执行脚本zend.sh安装ZendOptimizer
4、执行脚本nginx-upgrade.sh升级nginx
5、执行脚本php-upgrade.sh升级php(仅支持php-5.3.x系列的升级)
6、执行脚本iptables.sh配置防火墙
7、执行脚本fail2ban.sh安装防暴力破解软件
8、执行脚本ddos.sh (install|uninstall)安装或卸载ddos deflate

使用提示:

LNMP脚本使用

  1. lnmp add(del,list):创建(删除,列出)虚拟主机。
  2. lnmp ftp(add,del,list):创建(删除,列出)ftp用户。
  3. lnmp uninstall:一键卸载lnmp(卸载之前注意备份好数据!)。

程序目录

  1. mysql目录:   /usr/local/mysql
  2. mysql data目录:/usr/local/mysql/data
  3. php目录:     /usr/local/php
  4. nginx目录: /usr/local/nginx
  5. ddos defalte目录:/usr/local/ddos
  6. fail2ban目录    :/etc/fail2ban    :

进程管理

  1. nginx启动(停止|重启|重载配置文件):service nginx start(stop|restart|reload)
  2. mysql(停止|重启|重载配置文件):service mysqld start(stop|restart|reload)
  3. pure-ftpd(停止|重启|重载配置文件):service pure-ftpd start(stop|restart|reload)
  4. php-fpm(停止|重启|重载配置文件):service php-fpm start(stop|restart|reload)

配置文件路径

  1. nginx:/usr/local/nginx/conf
  2. mysql:/etc/my.cnf
  3. php:/etc/php.ini /etc/php.d/
  4. php-fpm:/usr/local/php/etc
  5. pure-ftpd:/etc/pure-ftpd.conf
  6. ddos deflate:/usr/local/ddos/ddos.conf

使用注意

1、mysql root密码存放在/root/.mysqlroot文件中,添加虚拟主机的时候需要调用。如果修改了root密码,请手动更新/root/.mysqlroot文件。
2、由于使用了chroot功能,所以连接mysql的时候只能使用tcp连接,即localhost改为127.0.0.1
3、php-cgi默认是3个,php-5.2.17到/usr/local/php/etc/php-fpm.conf找到对应的pool修改pm.max_children,php-5.3到/usr/local/php/etc/fpm.d里修改。

更新记录

    • 2012年5月29日:发布lnmp0.5.2

1、使用pure-ftpd代替vsftpd
2、增加防密码暴力破解组件fail2ban

    • 2012年5月24日:发布lnmp0.5.1

1、取消mysql-5.1的安装
2、精简安装前的输入
3、解决为vsftpd加载模块问题

    • 2012年5月11日:发布lnmp0.5

1、使用php-fpm chroot完全隔离系统与其它虚拟主机,保证系统及其它虚拟主机的安全。
2、升级php,mysql,phpmyadmin等软件。
3、增加内核优化。
4、新增PHP升级脚本。

    • 2012年3月29日:发布lnmp0.4

1、添加ddos deflate安装预防ddos和cc攻击。
2、升级mysql版本。
3、修改iptables规则增强系统安全。
4、优化php.ini文件增强php安全性。

    • 2012年2月3日:发布lnmp0.3.2

1、php-5.3.9出现严重安全漏洞,需要升级到php-5.3.10

    • 2012年2月2日:发布lnmp0.3.1

1、解决安装PHP时可能出现的undefined reference to `libiconv_open’错误。
2、升级php mysql版本。
3、为了安全隐藏php版本显示。
4、增加php sockets扩展。
5、修正设置时区有可能出现的问题。

    • 2012年1月10日:发布lnmp0.3

1、修正rc版本的几处错误

    • 2012年1月09日:发布lnmp0.3rc

1、增加安装错误检测,提高安装成功率。
2、优化lnmp删除虚拟主机功能。
3、增强卸载功能。
4、添加重装全部或单个软件功能。
5、增加安装进度显示,以便实时了解安装进程。
6、增加自动发送安装失败信息功能,帮助作者优化脚本。
7、自动更改dns服务器为8.8.8.8 8.8.4.4,解决某些网址无法解析的错误。
8、增加升级脚本,方便升级lnmp。

    • 2012年1月03日:发布lnmp0.2.4

1、修复php hash dos漏洞

    • 2011年12月31日:发布lnmp0.2.3

1、更新mysql,phpmyadmin,vsftpd等软件.
2、修复配置文件的一些错误.
3、修改卸载脚本以卸载lnmp更彻底.

    • 2011年12月08日:发布lnmp0.2.2

1、修复mysql5.5.18编译gbk字符集的错误
2、设置mysql5.5.18默认存储引擎为MyISAM,关闭存储引擎innodb,解决了启动mysql占用三百多M内存的问题。
3、增加自动设置域名301,如访问centos.bz转向www.centos.bz。

    • 2011年12月06日:发布lnmp0.2.1

1、修复nginx跨站问题。
2、调整网站目录结构。
3、使用logrotate轮询nginx日志。
4、隐藏nginx版本号。

    • 2011年12月04日:发布lnmp0.2

1、增加PHP-5.3.8和MySQL-5.5.18可选安装。
2、修复vsftpd在64位系统安装失败的问题。
3、增加nginx自动升级脚本。
4、为每个虚拟主机分配不同的用户,增强虚拟主机安全性。
5、修复CentOS-6系统PHP可能安装失败的问题

  • 2011年11月8日:发布lnmp0.1