2018年6月

查找nginx安装的路径以及相关安装操作命令

Linux环境下,怎么确定Nginx是以那个config文件启动的?

[root@localhost ~]# ps -ef | grep nginx
root 21196 1 0 23:40 ? 00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 21197 21196 0 23:40 ? 00:00:00 nginx: worker process
root 21199 20993 0 23:42 pts/0 00:00:00 grep --color=auto nginx

检查是否已经安装有nginx及对应目录:

[root@localhost ~]# find /|grep nginx.conf
/etc/nginx/conf.d
/etc/nginx/conf.d/example_ssl.conf
/etc/nginx/conf.d/default.conf
/etc/nginx/nginx.conf

还可以用以下两个命令,找安装的路径

[root@localhost ~]# netstat -tnlp|grep nginx
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 21196/nginx: master

然后看到一行记录,复制最后的一个数据(进程ID)

ps -aux |grep 进程ID

就可以看到nginx的启动方式了。

[root@localhost ~]# ps -aux |grep 21196
root 21196 0.0 0.0 48044 924 ? Ss 23:40 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root 21204 0.0 0.2 112648 2320 pts/0 S+ 23:45 0:00 grep --color=auto 21196

查看服务器上安装的nginx版本号,主要是通过ngix的-v或-V选项
Linux下查看Nginx安装目录、版本号信息?
-v 显示 nginx 的版本。
-V 显示 nginx 的版本,编译器版本和配置参数。

[root@localhost ~]# /usr/sbin/nginx -v
nginx version: nginx/1.8.0

===================================
查看linux系统版本命令

[root@localhost ~]# cat /proc/version
Linux version 4.1.5-x86_64-linode61 (maker@build) (gcc version 4.7.2 (Debian 4.7.2-5) ) #7 SMP Mon Aug 24 13:46:31 EDT 2015
[root@localhost ~]# cat /etc/redhat-release
CentOS Linux release 7.0.1406 (Core)

===================================
Ubuntu下安装nginx,直接apt-get install nginx就行了

CentOS 下安装nginx:

centos7系统库中默认是没有nginx的rpm包的,所以我们自己需要先更新下rpm依赖库

(1)使用yum安装nginx需要包括Nginx的库,安装Nginx的库

rpm -ivh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm

rpm包的安装:
1.安装一个包

# rpm -ivh

2.升级一个包,没安装过的不能使用升级命令

# rpm -Uvh

3.移走一个包

# rpm -e

安装准备依赖lib库

yum install gcc-c++ pcre pcre-devel zlib zlib-devel openssl openssl-devel

(2)使用下面命令安装nginx

#yum install nginx

(3)启动Nginx

#service nginx start

#systemctl start nginx.service

(4)重启nginx

service nginx restart


原文链接:https://www.cnblogs.com/zdz8207/p/CentOS-nginx-yum.html

Xshell很好用,然后有时候想在windows和linux上传或下载某个文件,其实有个很简单的方法就是rz,sz。
首先你的Linux上需要安装安装lrzsz工具包,(如果没有安装请执行以下命令,安装完的请跳过)

yum  install lrzsz

安装完毕即可使用。

rz,sz是便是Linux/Unix同Windows进行ZModem文件传输的命令行工具,所以要在Xshell连接属性中的设置上传协议为Zmodem和接受的文件路径等

windows端需要支持ZModem的telnet/ssh客户端(xshell支持,好像putty不支持),SecureCRT就可以用SecureCRT登陆到Unix/Linux主机(telnet或ssh均可)。

运行命令rz,即是接收文件(上传到Linux上),xshell就会弹出文件选择对话框,选好文件之后关闭对话框,文件就会上传到linux里的当前目录。也可以直接把要上传的文件拖到xshell上完成上传。

运行命令sz file 就是发文件到windows上(保存的目录是可以配置) 比ftp命令方便多了,而且服务器不用再开FTP服务了。

创建完 vm 实例后,可以使用控制台里的网页标签的ssh进行远程连接,但是用起来有延迟,不好用,xshell是非常强大的安全终端模拟软件,使用它来远程控制服务器很好用。

使用 xshell 连接 google vps 得进行一些配置,下面说一下步骤。

首先打开 xshell ,点击工具->新建用户密钥生成向导。

把公钥这串字符串记下,点击完成。

然后去 google cloud 控制台,点击Compute Engine->元数据->ssh密钥,修改,点击添加一项,然后把公钥复制到文本框里,在最后的“==”后面加一个空格,然后输入上面起的密钥名称,点击保存

然后再在 xshell 里新建一个连接,填写 IP 地址。

点击用户身份验证,方法选择“Public Key”,用户名填写上面的密钥名称,下面的用户密钥选择跟密钥名称相同的那个,输入密码,点击确定

然后就可以进行远程操作了。

随着HTTPS的覆盖率越来越广,SSL证书的需求量也在上升。为了更加完善HTTPS加密协议的使用,2017年3月CA | B论坛(一个全球证书颁发机构和浏览器的技术论坛)发起了一项关于对域名强制检查CAA的一项提案的投票,获得187票支持,投票有效,提议通过。

提议通过后,将于2017年9月8日根据Mozilla的Gervase Markham提出的检查CAA记录作为基准要求来实施。
什么是DNS CAA?

证书颁发机构授权(全称Certificate Authority Authorization,简称CAA)为改善PKI(Public Key Infrastructure:公钥基础设施)生态系统强度,减少证书意外错误发布的风险,通过DNS机制创建CAA资源记录,从而限定了特定域名颁发的证书和CA(证书颁发机构)之间的联系。

CAA是保护域名免受钓鱼的安全措施,网站运营商可以通过该措施来保护域名免于错误发布。在2013年由RFC 6844进行了标准化,允许CA“降低意外证书错误的风险”。默认情况下,每个公共CA都可以为公共DNS中的任何域名颁发证书,只要它们验证对该证书的控制域名。这意味着,如果在许多公共CA的验证过程中有任何一个错误,每个域名都可能受到影响。CAA为域名持有者提供了降低风险的途径。

而DNS Certification Authority Authorization(DNS证书颁发机构授权)是一项借助互联网的域名系统(DNS),使域持有人可以指定允许为其域签发证书的数字证书认证机构(CA)的技术。它会在 DNS 下发 IP 的同时,同时下发一条资源记录,标记该域名下使用的证书必须由某证书颁发机构颁发。

CAA记录格式

根据规范(RFC 6844),CAA记录格式由以下元素组成:

CAA <flags> <tag> <value>

名词解释:

CAA:DNS资源记录类型

<flags>:认证机构限制标志

<tag>:证书属性标签

<value>:证书颁发机构、策略违规报告邮件地址等

<flags>定义为0~255无符号整型,取值:

Issuer Critical Flag:0

1~7为保留标记

<tag>定义为US-ASCII0~9,取值:
CA授权任何类型的域名证书(Authorization Entry by Domain) : issue

CA授权通配符域名证书(Authorization Entry by Wildcard Domain) : issuewild

指定CA可报告策略违规(Report incident by IODEF report) : iodef

auth、path和policy为保留标签

定义为八位字节序列的二进制编码字符串,一般填写格式为:

[domain] [“;” * 参数]

设置CAA资源记录

需要当限制域名example.com及其子域名可由机构GlobalSign颁发不限类型的证书,同时也可由GDCA(trustauth.cn)颁发证书通配符,其他一律禁止,并且当违反配置规则时,发送通知邮件到example@example.com

配置如下(为便于理解,二进制值值已经过转码,下同):
example.com. CAA 0 issue "letsencrypt.org"

example.com. CAA 0 issue “globalsign.com”

example.com. CAA 0 issuewild “trustauth.cn”

example.com. CAA 0 iodef “mailto:example@example.com

子域名:如果子域名有单独列出证书颁发要求,例如:

example.com. CAA 0 issue “globalsign.com”

alpha.example.com. CAA 0 issue “trustauth.cn”

那么,因子域策略优先,所以只有GDCA为可以域名alpha.example.com颁发证书。

通配符:此外,CAA记录也可用于将通配符证书的颁发权限指定仅限一家CA。

domain.com. CAA 0 issuewild ” http://trustauth.cn

如果不想手动设置CAA记录,也可以通过自动生成工具生成一段CAA记录,发布到DNS系统中。

CAA记录查询

CAA记录是一个相对较新的资源记录,目前很多工具并不支持。以dig为例,不能适用其标准语法。若需要查询CAA记录,dig时需要直接指定RR类型(type257)。

例如:

$ dig google.com type257

; <<>> DiG 9.8.3-P1 <<>> google.com type257

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64266

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;google.com. IN TYPE257

;; ANSWER SECTION:

google.com. 86399 IN TYPE257 \# 19 0005697373756573796D616E7465632E636F6D

;; Query time: 51 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Thu Dec 29 21:07:18 2016

;; MSG SIZE rcvd: 59

该查询的输出是二进制编码记录,需要转码才能知道具体CAA策略。

最后

目前,国内大多数的DNS解析商均不支持CAA记录解析。但随着HTTPS逐步取代HTTP的趋势,使用SSL证书升级HTTPS的解决方案将被大量采纳。为了避免HTTPS证书的错误签发,相信不久的将来,CAA记录解析将被兼容。同时数安时代(GDCA)作为已通过WEBTRUSR国际认证的CA机构,将会坚持不断深入研发,为各大网络商业平台提供更安全的信息安全证书,为涉足互联网的企业打造更安全的生态环境,建立更具公信力的企业网站形象。

文章转载于https://www.trustauth.cn/wiki/24242.html

钥固定(Public Key Pinning)是指一个证书链中必须包含一个白名单中的公钥,也就是说只有被列入白名单的证书签发机构(CA)才能为某个域名*.example.com签发证书,而不是你的浏览器中所存储的任何 CA 都可以为之签发。本文讲述了这种机制的背景知识,并提供了 Apache、 Lighttpd 和 NGINX 上的配置范例。
HTTP 公钥固定扩展
用你使用的银行做个例子,它一直使用 CA 公司 A 为其签发证书。但是在当前的证书体系下,CA 公司 B、CA 公司 C 和 NSA 的 CA 都能给你的银行创建证书,而你的浏览器会毫无疑虑的接受它们,因为这些公司都是你所信任的根 CA。

如果你的银行实现了 HPKP 并固定了它们的第一个中级证书(来自 CA 公司 A),那么浏览器将不会接受来自CA 公司 B 和 CA 公司 C 的证书,即便它们也有一个有效的信任链。HPKP 也允许你的浏览器将这种违例行为报告给该银行,以便银行知道被伪造证书攻击了。

HTTP 公钥固定扩展是一个从2011年开始开发的针对 HTTP 用户代理(即浏览器)的公钥固定标准。它由 Google 发起,甚至在 Chrome 中实现的固定机制可以使用一个人工维护的网站公钥固定列表,这个列表包含了固定的几个网站的公钥签名。(LCTT 译注:Chrome 和 FireFox 32 及以后版本都支持公钥固定机制,并使用内置的人工维护的公钥固定列表数据,这些数据随着浏览器软件的更新而更新,主要包括几个大型站点。目前还只有 Chrome 38+ 支持通过 HTTP 响应头传递公钥固定信息。)

以下是 HPKP 的几个功能简述:

HPKP 是在 HTTP 层面设置的,使用 Public-Key-Pins (PKP)响应头。
该规则的保留周期通过 max-age 参数设置,单位是秒。
PKP 响应头只能用于正确的安全加密通讯里面。
如果出现了多个这样的响应头,则只处理第一个。
固定机制可以使用includeSubDomains参数扩展到子域。
当接收到一个新的 PKP 响应头时,它会覆盖之前存储的公钥固定和元数据。
公钥固定是用哈希算法生成的,其实是一个“主题公钥信息(SKPI)”指纹。
本文首先会介绍一些 HPKP 工作的原理,接下来我们会展示给你如何得到需要的指纹并配置到 web 服务器中。

SPKI 指纹 - 理论
以下摘自 Adam Langley 的帖子,我们哈希的是一个公钥,而不是证书:

通常来说,对证书进行哈希是一个显而易见的解决方案,但是其实这是错的。不能这样做的原因是 CA 证书可以不断重新签发:同一个公钥、主题名可以对应多个证书,而这些证书有不同的延展或失效时间。浏览器从下至上地在证书池中构建证书链时,另外一个版本的证书可能就替代匹配了你原本所期望的证书。

举个例子,StartSSL 有两个根证书:一个是以 SHA1 签名的,另外是一个是 SHA256。如果你希望固定住 StartSSL 作为你的 CA,那么你该使用哪个证书呢?你也许可以使用这两个,但是如果我不告诉你,你怎么会知道还有一个根证书呢?

相反地,对公钥进行哈希则不会有这个问题:

浏览器假定子证书是固定不动的:它总是证书链的起点。子证书所携带的签名一定是一个有效的签名,它来自其父证书给这个证书专门签发的。这就是说,父证书的公钥相对于子证书来说是固定的。所以可推论公钥链是固定的。

唯一的问题是你不能固定到一个交叉认证的根证书上。举个例子,GoDaddy 的根证书是 Valicert 签名的,这是为了让那些不能识别 GoDaddy 根证书的老客户可以信任其证书。然而,你不能固定到 Valicert 上,因为新的客户在证书链上发现了 GoDaddy 证书就会停止上溯(LCTT 译注:所以就找不到固定信息了)。

此外,我们是对 SubjectPublicKeyInfo(SPKI)进行哈希而不是对公钥位串。SPKI 包括了公钥类型、公钥自身及其相关参数。这很重要,因为如果对公钥进行哈希就有可能导致发生曲解攻击。对于一个 Diffie-Hellman 公钥而言:如果仅对公钥进行哈希,而不是对完整的 SPKI,那么攻击者可以使用同样的公钥而让客户端将其解释为其它组。同样地,这样也有可能强制将一个 RSA 密钥当成 DSA 密钥解释等等。

固定在哪里
你应该固定在什么地方?固定你自己的公钥并不是一个最好的办法。你的密钥也许会改变或撤销。你也许会使用多个证书,经常轮换证书的话密钥就改变了。也许由于服务器被入侵而撤销证书。

最容易但是不是太安全的方法是固定第一个中级 CA 证书。该证书是签名在你的网站证书之上的,所以签发该证书的 CA 的公钥肯定是在证书链上的。

采用这种方法你可以从同一个 CA 更新你的证书而不用担心固定信息不对。如果该 CA 发行了一个不同的根证书,也许你会遇到一些问题,对此并没有太好的解决方案。不过你可以通过如下做法来减轻这种问题的影响:

从一个不同的 CA 申请一个备用的证书,并固定该备份。
RFC 里面说你至少需要做两个固定。一个是当前连接所使用的证书链上的,另外一个是备份的。

另外的固定是对备份公钥的,它可以是来自另外一个给你签发证书的不同 CA 的 SKPI 指纹。

在这个问题上还有一种更安全的方法,就是事先创建好至少三个独立的公钥(使用 OpenSSL,参见此页 了解 Javascript OpenSSL 命令生成器),并将其中两个备份到一个安全的地方,离线存储、不要放到网上。

为这三个证书创建 SPKI 指纹并固定它们,然后仅使用第一个作为当前的证书。当需要时,你可以使用备份密钥之一。不过你需要让 CA 给你做签名来生成证书对,这可能需要几天,依你的 CA 的工作情况而定。

对于 HPKP 来说这没有问题,因为我们使用的是公钥的 SPKI 哈希,而不是证书。失效或不同的 CA 签名链并不影响。

如果你按照上述方法生成并安全存储了至少三个独立的密钥,并固定它们,也可以防止你的 CA 撤销你的网站证书并签发一个假证书时出现问题。

Web 服务器配置
下面你可以看到三个主流 Web 服务器的配置方法。这只是一个 HTTP 响应头,绝大多数 Web 服务器都可以设置它。它只需要设置到 HTTPS 网站上。

下面的例子固定到 COMODO RSA Domain Validation Secure Server CA 及备份的 Comodo PositiveSSL CA 上,30天失效期,包括所有的子域。
可以使用如下的 OpenSSL 命令来生成 SPKI 指纹,它出现在 RFC 草案 中:

openssl x509 -noout -in certificate.pem -pubkey | \
openssl asn1parse -noout -inform pem -out public.key;
openssl dgst -sha256 -binary public.key | openssl enc -base6

会的到类似于klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=
替换下方的这一串
Apache

编辑你的 Apache 配置文件(如 /etc/apache2/sites-enabled/website.conf 或 /etc/apache2/httpd.conf或者./ssl.conf),并添加下列行到你的 VirtualHost 中:
# 如需要,载入 headers 模块

LoadModule headers_module modules/mod_headers.so

Header set Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains"

Lighttpd

将下列行添加到你的 Lighttpd 配置文件(如 /etc/lighttpd/lighttpd.conf):

server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
    setenv.add-response-header  = ( "Public-Key-Pins" => "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains")
}

NGINX

添加以下行到你的 HTTPS 配置的 server 块中:

add_header Public-Key-Pins 'pin-sha256="klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY="; pin-sha256="633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q="; max-age=2592000; includeSubDomains';

报告功能

HPKP 报告功能允许浏览器报告任何违例给你。

如果你在响应头中添加了附加的 report-uri="http://example.org/hpkp-report" 参数,并用该 URI 处理接收到的数据的话,客户端会在发现违例时发送报告给你。这个报告是以 POST 方式发送到你指定的 report-uri 上,并以类似下面的 JSON 格式:

{
    "date-time": "2014-12-26T11:52:10Z",
    "hostname": "www.example.org",
    "port": 443,
    "effective-expiration-date": "2014-12-31T12:59:59",
    "include-subdomains": true,
    "served-certificate-chain": [
        "-----BEGINCERTIFICATE-----\nMIIAuyg[...]tqU0CkVDNx\n-----ENDCERTIFICATE-----"
    ],
    "validated-certificate-chain": [
        "-----BEGINCERTIFICATE-----\nEBDCCygAwIBA[...]PX4WecNx\n-----ENDCERTIFICATE-----"
    ],
    "known-pins": [
        "pin-sha256=\"dUezRu9zOECb901Md727xWltNsj0e6qzGk\"",
        "pin-sha256=\"E9CqVKB9+xZ9INDbd+2eRQozqbQ2yXLYc\""
    ]
}

非强制,只报告
HPKP 也可以设置为非强制的,可以使用 Public-Key-Pins-Report-Only 来只发送违例报告给你。

这样可以让你在网站不可访问或 HPKP 配置不正确时不固定,之后你可以将这个响应头改为 Public-Key-Pins 来强制固定。