nginx安全配置规范

说起网络攻击，可能很多人只知道大名鼎鼎的DDoS攻击，这种攻击廉价且效果出众，直接通过第四层网络协议用他的带宽把你的带宽顶掉，造成网路阻塞，防不胜防。不过还有一种网络攻击其实比起DDOS更频繁出现，就是CC（Challenge Collapsar）攻击，一般来说是利用网站代码漏洞，不停地发大量数据包请求，造成对方服务器回应这些请求导致资源耗尽，一直到宕机崩溃。这种攻击属于第七层的网络协议，一方面在服务器层面是正常的请求，所以这种情况想根本解决问题，只能从代码入手。但是另一方面，也就可以用其他来限制他访问，例如nginx的配置上也是能稍微防一下。

隐藏版本号

1
2
3
http {
    server_tokens off;
}

经常会有针对某个版本的nginx安全漏洞出现，隐藏nginx版本号就成了主要的安全优化手段之一，当然最重要的是及时升级修复漏洞。

开启HTTPS

1
2
3
4
5
6
7
8
9
10
server {
    listen 443;
    server_name opstrip.com;
    
    ssl on;
    ssl_certificate /etc/nginx/certs/opstrip.com.pem;
    ssl_certificate_key /etc/nginx/certs/opstrip.com.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;
}
中间件网络安全

more >>

Letsencrypt通过DNS的TXT记录来验证域名有效性

说明

我们在使用letsencrypt获取免费的HTTPS证书的时候，letsencrypt需要对域名进行验证。默认情况下它的验证方式是这样的：

certbot程序在web目录的根目录下放置一个文件。
letsencrypt的服务器通过域名来访问这个文件，来验证你申请的域名是属于你的
但有时候我们想为内网的某台主机设置HTTPS，因为内网的主机无法被letsencrypt的服务器访问到，certbot --nginx certonly就会出现Connection refused的错误。

为了解决上述问题，我们可以更改验证方式，使用DNS记录来验证域名。

安装部署

备忘录

more >>

实战：在 CentOS7上部署 Jumpserver1.2

实战：CentOS7 一步步部署安装 jumpserver1.2，看看都踩过哪些坑。
Jumpserver 终于升级到1.2版本了！之前试用了1.0版本，由于 Bug 太多，搭建的时候各种报错，简直噩梦。搭建后还是有乱码等问题，因时间关系就没继续折腾了。这次听说1.2版本修复了不少 Bug，效果不错就决定继续折腾了。

部署环境

系统：CentOS7.4
IP： 172.31.12.12
关闭 selinux 及防火墙

备忘录

more >>

Centos7.3 Kubernetes集群部署

下午抽空整了下Kubernetes环境，限于资源的原因，这个环境比较简单：一台master，两台node。搞起！

环境介绍及准备

物理机操作系统

物理机操作系统采用CentOS7.4 64位，细节如下。

1
2
3
4
[root@opstrip.com ~]# uname -a
Linux opstrip.com 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@opstrip.com ~]# cat /etc/redhat-release 
CentOS Linux release 7.4.1708 (Core)

主机信息

本文准备了三台机器用于部署k8s的运行环境，细节如下：

HostName IP Node/function
K8s-master 172.31.12.12 kubernetes, etcd
K8s-node1 172.31.12.13 kubernetes-node, flannel
K8s-node1 172.31.12.14 kubernetes-node, flannel

环境准备

主机名修改

学习笔记

more >>

安装最新版jumpserver

线上一直在使用0.3.2版本的jumpserver。随着机器与人员的增多，跳板机的可用性也越来越低了。今天抽空测试了下新版本的jumpserver0.5.0，发现居然增加了redis做celery broker，性能应该有所提升。至于提升多少性能，还要用过一段时间才知道。今天先部署吧。

环境

系统: CentOS 7
IP: 172.31.12.12
关闭 selinux和防火墙

  • CentOS 7

$ setenforce 0 # 可以设置配置文件永久关闭
$ systemctl stop iptables.service
$ systemctl stop firewalld.service

  • CentOS 6

$ setenforce 0
$ service iptables stop

准备Python3和Python虚拟环境

安装依赖包

1
$ yum -y install wget sqlite-devel xz gcc automake zlib-devel openssl-devel epel-release

编译安装

备忘录

more >>

升级安装Python3

创建安装目录

1
[root@myprecious opt]# mkdir /usr/local/python3

下载Python3

1
[root@myprecious opt]# wget https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tar.xz

编译安装

1
2
3
4
[root@myprecious opt]# tar xf Python-3.6.4.tar.xz && cd Python-3.6.4
[root@myprecious Python-3.6.4]# ./configure --prefix=/usr/local/python3
[root@myprecious Python-3.6.4]# make
[root@myprecious Python-3.6.4]# make install
Python3Python升级Linux备忘录

more >>

在LINUX下如何查找CC攻击

什么是CC攻击?CC攻击就是利用大量代理服务器对目标计算机发起大量连接，导致目标服务器资源枯竭造成拒绝服务。那么如何判断查询CC攻击呢?本文主要介绍了一些Linux下判断CC攻击的命令。

查看所有80端口的连接数

1
netstat -nat|grep -i "80"|wc -l

对连接的IP按连接数量进行排序

1
netstat -anp | grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
安全运维

more >>

英特尔、谷歌和AWS回应CPU安全事件：AMD和ARM也有问题，影响巨大

英特尔方面解释称，其已经向 ARM 、AMD 以及其它多家操作系统供应商报告了此项漏洞。该方同时强调，该漏洞最初是由谷歌公司的 Zero 项目安全小组所发现，这一说法也得到了谷歌方面的证实。

英特尔公司指出，其将发布微代码更新以解决此项问题，而随时间推移这些修复补丁中的一部分亦将被引入硬件当中。

据英特尔所说，本来他们是计划下周当软件和固件都比较完善的时候向用户披露这个信息的，但是由于媒体的报道不准确，引起舆论哗然才让其不得不提前发布声明。在回应时，Intel 表示，这些漏洞不存在被攻击、修改或删除数据的可能，还表示 媒体报道此“漏洞”或“缺陷”是英特尔的产品独有的问题这一说法是不准确的。基于目前为止的分析，许多类型的计算设备（不同供应商的处理器和操作系统）也很容易受到这些攻击。

微软公司拒绝就此事发表评论，不过预计微软也将推出自己的对应补丁。此外，AWS、谷歌公司也发布了自己的报告（见下文）。

意味着什么: 就目前来讲，我们可以看到各大主要芯片与操作系统供应商已经意识到问题的存在，并努力发布修复程序。第一款补丁很可能被纳入微软的新一轮补丁周二发布。目前还不清楚这批补丁会影响到多少不同类型的软件与 CPU 架构，也不明确具体将给 PC 性能造成怎样的影响。

但是，补丁带来的影响会不会比安全问题本身更令人难以接受？根据初步报道，取决于具体任务与处理器型号的不同，PC 用户可能因此遭遇“5% 到 30% 之间的性能衰减”。

英特尔方面似乎 坚信普通用户不会受到任何负面影响。其在一份声明中指出：“与一部分报道相反，任何潜在的性能影响都将取决于实际工作负载。而对普通计算机用户而言，其不会产生任何显著的影响，且性能衰减将随时间推移而得到缓解。”

资讯

more >>