centos 7下SSH的一些安全配置

0、说明

0.1、实验环境系统为Centos 7.4系统,最小化安装后未做任何配置

1、修改SSH默认连接端口

1.1、确保SELinux处于关闭状态

[root@imzcy ~]# setenforce 0
[root@imzcy ~]# sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

1.2、编辑sshd_config配置文件,修改默认端口(17行左右)。并重启sshd服务使配置生效

[root@imzcy ~]# grep ^Port /etc/ssh/sshd_config 
Port 10022
[root@imzcy ~]# systemctl restart sshd

1.3、firewalld防火墙添加规则,放行tcp/10022端口

#添加防火墙规则
[root@imzcy ~]# firewall-cmd --permanent --zone=public --add-port=10022/tcp
[root@imzcy ~]# firewall-cmd --reload

#确认配置
[root@imzcy ~]# firewall-cmd --list-all |grep 10022
  ports: 10022/tcp

这时候就可以使用10022端口连接ssh服务器了。
可能遇到的问题:

如果修改完ssh端口号,重启sshd服务报错,然后注释掉之前的更改就能正常重启,请使用getenforce命令检查下selinux状态是否为关闭

2、禁止root用户远程登录

#2.1、修改sshd_config配置文件(38行左右)
[root@imzcy ~]# grep ^PermitRootLogin /etc/ssh/sshd_config 
PermitRootLogin no
[root@imzcy ~]# 

#2.2、重启sshd服务,使配置立即生效
[root@imzcy ~]# systemctl restart sshd

3、限制ssh访问服务器的源IP

#编辑hosts.allow配置文件,追加一行内容
[root@imzcy ~]# echo "sshd:192.168.43.226:allow" >>/etc/hosts.allow

#编辑hosts.deny配置文件,追加一行内容
[root@imzcy ~]# echo "sshd:ALL" >>/etc/hosts.deny

这里只写了一种方法,还可以通过修改sshd_config配置文件来限制源IP,也可以使用firewalld来限制源IP

4、限制ssh访问服务器的用户名

#修改sshd_config配置文件,允许zcy用户ssh访问服务器(以空格分开用户;添加完允许,默认拒绝其他所有用户)
[root@imzcy ~]# echo "AllowUsers zcy" >>/etc/ssh/sshd_config

#重启sshd服务,使配置立即生效
[root@imzcy ~]# systemctl restart sshd

5、修改telnet ssh端口时显示的版本号

#5.1、查看sshd位置
[root@imzcy ~]# whereis sshd
sshd: /usr/sbin/sshd /usr/share/man/man8/sshd.8.gz

#5.2、查看SSH版本
[root@imzcy ~]# ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017

#5.3、查看sshd程序关于版本的信息
[root@imzcy ~]# strings /usr/sbin/sshd |grep OpenSSH_7.4
OpenSSH_7.4p1-RHEL7-7.4p1-11
OpenSSH_7.4
OpenSSH_7.4p1

#5.4、使用sed替换版本(记得一定要先备份下)
[root@imzcy ~]# cp -p /usr/sbin/sshd ./
[root@imzcy ~]# sed -i 's/OpenSSH_7.4/OpenSSH_2.3/g' /usr/sbin/sshd

#5.5、重启下sshd服务,没有报错即可
[root@imzcy ~]# systemctl restart sshd

再使用telnet连接ssh端口,显示的版本则为:SSH-2.0-OpenSSH_2.3

openwrt上用cifs挂载samba共享文件夹

用cifs挂载的时候不知道什么原因一直提示错误:

mount error(22): Invalid argument

花了一天时间找google,终于找到个方法,在后面加参数 vers=1.0 什么原理我也不知道,反正能行就好。

mount.cifs //192.168.2.1/op/1 /mnt/sda1/123 -o username=root,password=root,rw,vers=1.0

Tomcat禁用端口方法

tomcat默认启用端口解释:

  • 8005,tomcat关闭端口。
  • 8080,tomcat页面http端口。通常我们会修改为80
  • 8009,tomcat-AJP代理端口,通常做负载均衡用

多套tomcat防端口冲突方法:

1、修改conf/server.xml中的三个端口:8005,8080,8009,分别重置为新端口。这个感觉操作起来有些繁琐,

2、建议tomcat仅使用单个 http 端口。

2-1、禁用关闭端口

将 Server 元素的 port 属性设置为 -1,这将禁用 Tomcat 关闭端口。
我们强制tomcat不使用关闭端口,通过使用“kill -9 PID”命令来停止任何独立应用程序实例。
只需要将tomcat/conf/server.xml中的:

<Server port="8005" shutdown="SHUTDOWN"> 

修改为

<Server port="-1" command="SHUTDOWN"> 

2-2、禁用AJP
应通过注释掉tomcat/conf/server.xml中显示的节来禁用 AJP 连接器,以确保我们不会遇到端口冲突。

    <!-- Define an AJP 1.3 Connector on port 8009 --> 
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> 

修改为:

    <!-- Define an AJP 1.3 Connector on port 8009 
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> 
    --> 

2-3、修改http端口为80

    <Connector port="80" protocol="org.apache.coyote.http11.Http11NioProtocol"  
               connectionTimeout="20000"  
               redirectPort="8443" maxThreads="150"/> 

记一次SSH配置相关问题

今天新租了一VPS,在解决了IP被屏蔽等问题后,着手解决使用XShell连接SSH时存在的问题。如图:

未分类

同时连接速度也肉眼可见地慢。。。慢。。慢。

于是百度、Google 说是安装不完全,于是就安装

yum -y install xorg-x11-xauth

但是仍然有问题,报出这样的问题

/usr/bin/xauth: file /root/.Xauthority does not exist

最终把ssh配置的AllowAgentForwarding也改为yes就OK了(去掉注释)
前提是X11Forwarding yes这一条配置也要yes,不过默认应该都是的
我ssh的配置文件路径/etc/ssh/sshd_config
至此问题就完美解决了。

WordPress一次性搞定ssl全局设置以及潜在问题解决

首先按照自己的项目运行服务器把证书安装好,干货君以腾讯云为例:证书安装指引 – SSL 证书 – 文档平台 – 腾讯云文档平台 – 腾讯云。

干货君使用nginx反向代理,apache作为项目运行服务器为例,修改nginx/conf文件夹下面的nginx.conf(将下方代码块添加到文件中或把文件中443代码块按此方式设置)。

server {
listen 443;
server_name www.nrgh.org; #填写绑定证书的域名
ssl on;
ssl_certificate 1_www.nrgh.org_bundle.crt;
ssl_certificate_key 2_www.nrgh.org.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #按照这个协议配置
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;#按照这个套件配置
ssl_prefer_server_ciphers on;
location / {
#项目路径,或反向代理的代码块
proxy_pass http://nrgh;
} 
}

未分类

上方搞定在nginx.conf中加入下面这个代码块,你要负载均衡(集群使用)也是在这个代码块中搞

upstream www{
#下方写要代理的ip和端口号,下面ip是乱写的,真实的已隐去
server 111.111.205.11:56;
}

未分类

server {
listen 80;
server_name http://www.nrgh.org
if ($scheme = http ) {
#http请求转换为https
return 301 https://$server_name$request_uri;
}
#即所有请求都到这里去找分配
location / {
#全局实现80进来的请求,重定向为https了
proxy_pass http://www;
#rewrite ^/(.*) https://$server_name/$1 permanent;
}
}

上面都配置之后,运行 nginx -t 并重启nginx试试效果

接下来说下会出现的问题:

1、上面都搞定之后,wordpress网站可能出现css和js还是走http请求,文章链接走https请求,这时候需要你把wordpress的媒体文件绝对路径替换相对路径,方法如下:

2、wordpress/wp-admin 后台进不去,登录无反应;

3、百度找了很多解决方法,却依然没有解决,甚至搞的连网站都打不开了;

4、等等。。。

一、系统文件修改

路径:网站根目录wp-includesfunctions.php
找到代码 require( ABSPATH . WPINC . ‘/option.php’ );
在下方添加:

add_filter('script_loader_src', 'agnostic_script_loader_src', 20,2); function agnostic_script_loader_src($src, $handle) { return preg_replace('/^(http|https):/', '', $src); } add_filter('style_loader_src', 'agnostic_style_loader_src', 20,2); function agnostic_style_loader_src($src, $handle) { return preg_replace('/^(http|https):/', '', $src); }

二、后台文件修改

路径:网站根目录wp-config.php
找到代码:

*
* @package WordPress
*/

在下方添加如下代码:

$_SERVER['HTTPS'] = 'on';
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);

三、安装插件

完成以上两步操作后,可以正常访问https开头的网站和后台,
下载这个叫“really-simple-ssl”的WordPress插件:

Really Simple SSL

登录后台安装此插件。

至此,真正意义上解决wordpress全站开启https的ssl证书问题。

wordpress启用https301重定向htaccess规则

谷歌浏览器一直在推行https,而今年更新通知7月份会将http标记为不安全,于是下定决心博客启用https。经过一番折腾,最后终于改造成功,但是最后找了很多http301重定向到https的规则,很多都只能定向首页,而不能全站301。最后才找到一个可以用的,分享给大家

未分类

htaccess规则

如果是没有htaccess规则,可以直接用以下规则

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

如果已有如下默认规则,

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# BEGIN WordPress
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# EDN WordPress

注:规则必须加载 # BEGIN WordPress和# EDN WordPress之外

301状态码检测

可以通过站长工具(http://tool.chinaz.com/pagestatus/)进行状态码检测

未分类

检测主页和内页同时返回正确的301状态码,可以到百度站长平台进行https验证

验证后很快快照就会更新成https

他们将生产环境从 nginx 迁移到 envoy

导读:随着Service Mesh在最近一年进入人们的视野,Envoy 作为其中很关键的组件,也开始被广大技术人员熟悉。本文作者所在公司已经从 nginx 迁移到 Envoy。

随着我们下一代产品发布,我们将代理软件从 nginx 切换到 Envoy 。

我们很早就开始关注 Envoy。 公司的一些人之前在 Twitter 工作,其中一些人和 Matt Klein 一起组建了 Twitter 的边缘代理 TFE。 我们知道 Lyft 正在计划建立一个基于 TFE 的开源代理模型,我们对此很感兴趣。 不幸的是,我们刚开始做自己产品的时候它还没有准备好,所以起初我们还是使用 nginx。

我们很高兴看到 Envoy 的最初功能集合中包含了大量灵活运用微服务的想法。 我们更加兴奋地看到它的社区已经成型并且技术已经成熟。 现在 Envoy 提供的功能(相比于 nginx)可以使我们能够更快地为客户提供新功能。当然,Envoy 的功能路线图也非常令人兴奋。

选择代理

在启动Turbine Labs时,我们就知道负载均衡将成为我们基础架构的关键组成部分。

在2015年秋季的时候,代理软件并不是我们今天看到的样子。

我们选择 nginx 是因为它轻巧,经过大量生产环境测试,开源,相对来说易于扩展,并且拥有蓬勃发展的用户群体。然而我们必须做很多额外的工作才能在 nginx 之上构建一个全功能的流量管理解决方案。

服务发现,统计管理和更细粒度的负载均衡是现代基础架构的关键特性。 我们在 nginx 之上来实现这些功能,虽然已经花了很长时间,但仍有很多工作要做。

相比之下,Envoy 有很多非常有用功能(如 gRPC,tracing 等等),同时提供类似(或更好)的性能,稳定性和社区。

克服反对意见

采用任何新技术都需要考虑相反的意见。 由于我们已经部署了代理服务,不仅需要考虑到自己的问题,还需要考虑到客户提出的问题。 对于开源项目,这些问题通常分为以下几类:

我们一直密切关注 Envoy 的开发进展,并对它的成熟速度感到惊讶。已经有不少公司在生产环境使用 Envoy。Envoy 现在是一个 CNCF 项目,这意味着社区是透明和开放的。 代码贡献者来自很多公司,我们也在其中。

成本也是需要考虑的因素。随着 sidecars 成为更普遍的部署方式,代理会得到更广泛的应用。 虽然许多客户将继续集中式运行负载均衡,但我们希望代理软件可以优雅地支持边车部署模型。

Envoy 采用 C++ 11 编写,运行时占用的内存很少,与依赖较重运行时的代理相比,显着减少了 sidecars 部署的负担。

服务提供方的好处

应始终谨慎对待技术堆栈的大型更改。我们没有轻易转向 Envoy,但我们获得的好处以及我们可以传递给我们客户的好处非常显著。

可管理性

从一开始,Envoy 就被设计为可以大规模管理。 我们已经做了很多工作来使我们的基于 nginx 的代理可管理,但是这个配置接口不太容易地暴露给其他工具。

Envoy 数据平面 API 为其集中管理提供了一个开放标准。 我们可以提供一个集中的,开放的控制点,而不是复制配置文件。

可扩展性

nginx 是一个非常成功,稳定的开源项目。 其配置文件和模块生态系统具有较大的外围应用,并有大量现有用户支持。 给 nginx 贡献核心代码是非常有挑战性的,这导致在许多情况下需要编写自定义模块或 Lua 脚本以扩展其功能。

Envoy 更为聚焦,使用更为现代的语言支持改变代理行为。过去几个月中,我们向 Envoy 提交了超过 30 个功能,其中包括 OSX 构建 ,子集负载均衡和 upstream 日志记录等主要功能。

服务使用方的好处

更丰富的群集模型

我们在 nginx 上做了一些扩展,从而增强其 upstream 模型并添加更多细节。在同时部署同一服务的多个版本时,仅仅了解实例的主机和端口是不够的。

Envoy(通过我们贡献的补丁)允许将任意元数据附加到服务实例,以及定义基于该元数据定义路由规则。这使先进的流量管理技术成为可能,例如增量发布, 蓝/绿版本,无缝整体分解和生产测试 。

多协议支持

NGINX支持很多协议。 Envoy 的架构可以轻松地添加对新协议的支持,并且它也提供了多种协议支持。 虽然 HTTP 占据了互联网流量的很大一部分,但增加对 Redis,Mongo,Dynamo,websockets 和 gRPC 流量的可见性也是非常重要的。

动态服务发现

随着微服务,容器变得越来越流行,服务拓扑变得更加动态。配置文件中的服务器列表很快就会过时。 Envoy 使用一种最终一致的模型来进行 API 驱动的服务发现,并且能够很好地处理变化频繁的实例。

我们目前从各种平台收集数据,而 Envoy 的群集发现服务(CDS)为我们提供了比固定配置文件更自然的抽象。 Envoy 通过支持监听器发现服务(LDS)和路由发现服务(RDS)支持路由拓扑发现,从而进一步加强了这一点。 最终允许从中央控制点动态重新配置大部分服务拓扑,这非常有用。

网络策略

微服务意味着网络更加依赖于服务抽象边界。 随着相互依赖的服务数量日渐增长,系统100%没问题的时间会变少,整个系统经常有部分功能处于降级状态。

管理网络策略(如重试,超时和速率限制)对于在面对系统健康问题时保持顺畅的客户体验至关重要。Envoy 允许在代理(每个路由) 和客户端(每个请求的基础上)配置这些策略。 这可以灵活地实现(难以用 nginx 实现的)极细粒度弹性策略。

监测

Envoy 使用行业标准的请求日志,还提供与各种监测系统的集成。 它还提供对 Zipkin 和 Lightstep 的原生支持,以便追踪整个请求链。

如何更快迁移

我们对迁移到 Envoy 的过程非常满意。 它稳定,快速,轻便,并拥有一个伟大的社区。 它的架构使其非常适合微服务,但它同样适合做边缘代理。 作为基础服务,使用配置API而非静态配置文件真是太棒了。

如果你已经开始使用 Envoy,或者正在考虑迁移到 Envoy,那就可以考虑使用我们的服务。凭借广泛的服务发现和卓越的管理界面,我们可以帮助您快速,平稳地部署和运营 Envoy。

英文原文:

https://blog.turbinelabs.io/our-move-to-envoy-bfeb08aa822d

更多 Envoy 介绍:

https://www.envoyproxy.io/

Nginx利用fastcgi_cache缓存php页面

前言

fastcgi_cache是一个nginx的插件,用于缓存fastcgi接口的执行结果,例如缓存php的执行结果。特别是php网站的首页与一些非交互页面,利用fastcgi_cache可以大幅度提升访问速度,并且降低php的执行压力。

配置

1. 在nginx的主配置文件

在主配置文件(nginx.conf)中添加缓存域

fastcgi_cache_path /dev/shm/nginx-cache levels=1:2 keys_zone=cgi_wpcache:200m inactive=1d;

fastcgi_cache_path:缓存文件的路径,/dev/shm/为tmfs缓存文件系统,

实际储存在内存中,所以读写IO性能更高。
levels:缓存目录的结构层次,例如1:2,缓存文件会就生成在指定目录的再下两层目录中。
keys_zone:缓存域名称,在vhost内进行缓存时需要调用。
inactive:缓存不活动时间,若缓存内容在指定时间内未被访问将会被清理出缓存域。

2. 站点配置

location /archives/ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /data/webroot/$fastcgi_script_name;
include fastcgi_params;
  fastcgi_cache cgi_wpcache;
  fastcgi_cache_methods GET HEAD;
  fastcgi_cache_key $request_method$host$request_uri;
  fastcgi_cache_valid 200 2d;
  fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
  add_header X-Cache “$upstream_cache_status”;
}

fastcgi_cache:指定缓存域
fastcgi_cache_methods:指定缓存的请求方式
fastcgi_cache_key:指定缓存文件的标识,这个标识会MD5转码存储在缓存域的目录下
fastcgi_cache_valid:指定缓存状态,例如上文中只缓存响应状态码为200的请求所产生的返回页面两天
fastcgi_ignore_headers:默认情况下fastcgi_cache会忽略有特殊header的请求,并不进行缓存,官网说明。但当我们添加这个参数后,这些限制将不在存在。
add_header 将会在返回请求的response的header中添加一个X-Cache字段表示是否进行了缓存。如果需要也可以在nginx日志中通过log_format添加$upstream_cache_status字段

  • ·MISS 未命中,请求被传送到后端
  • ·HIT 缓存命中
  • ·EXPIRED 缓存已经过期请求被传送到后端
  • ·UPDATING 正在更新缓存,将使用旧的应答
  • ·STALE 后端将得到过期的应答

3.验证

配置完成后重新加载nginx后通过curl -I 访问如下:

[root@localhost local]# curl -I localhost/archives/1.php
HTTP/1.1 200 OK
Server: nginx/1.14.0
Date: Mon, 25 Jun 2018 06:48:05 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/7.0.30
Expires: Tue, 26 Jun 2018 06:48:05 GMT
Cache-Control: max-age=86400
X-Cache: MISS

第一次访问 X-Cache: MISS 说明还未进行缓存。

[root@localhost local]# curl -I localhost/archives/1.php
HTTP/1.1 200 OK
Server: nginx/1.14.0
Date: Mon, 25 Jun 2018 06:50:57 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/7.0.30
Expires: Tue, 26 Jun 2018 06:48:05 GMT
Cache-Control: max-age=86400
X-Cache: HIT

第二次访问发现X-Cache: HIT,表明/archives/1.php这个url已经被缓存,再下次访问nignx将不再会去请求php-fpm进行执行,而会直接从缓存中读取并返回,能够大大提高网站速度。

4. 遇到问题

a)访问空白
配置完毕后发现时常会出现页面访问空白的情况,再清空缓存目录后重新访问就恢复了。
经过测试发现是由于第一次使用HEAD方式访问,返回一个body为空的响应并被缓存了,所以之后再次访问就获取到了空白的页面。
这是由于fastcgi_cache_key中没有设置$request_method,将GET和HEAD的请求存储到了同一个key中。

b)页面缓存失败,一直MISS
默认情况下,请求的header中包含“Expires”, “Cache-Control”, “Set-Cookie”等,页面将不会被缓存,所以添加fastcgi_ignore_headers Cache-Control Expires Set-Cookie;即可。

nginx下禁止访问.git等隐藏文件夹

今天进腾讯云的控制台 偶然发现腾讯云一直给我提示的漏洞 其中有一个挺为严重的 汗.png

未分类

我的网站配置下并没有屏蔽隐藏文件夹例如.git等文件夹的访问 甚至可以直接下载隐藏文件夹的内容
确实是我没有想到的 如果你也有这种情况 就需要进行配置服务器来禁止敏感文件的访问了 否则就直接暴露在大庭广众之下了…

nginx的配置很简单

在server{}段内增加
代码如下:

location ~ /.
{
deny all;
}

这样就把所有的隐藏文件夹给屏蔽访问了 如果想单独屏蔽某一隐藏文件夹的访问只需要

location ^~ /.git
{
return 444;
}

阿里云DOCKER标准日志采集(NGINX)

部署Logtail容器

1. 拉取Logtail镜像

docker pull registry.cn-hangzhou.aliyuncs.com/log-service/logtail

2. 启动Logtail容器

docker run -d -v /:/logtail_host:ro -v /var/run/docker.sock:/var/run/docker.sock --env ALIYUN_LOGTAIL_CONFIG=/etc/ilogtail/conf/${your_region_name}/ilogtail_config.json --env ALIYUN_LOGTAIL_USER_ID=${your_aliyun_user_id} --env ALIYUN_LOGTAIL_USER_DEFINED_ID=${your_machine_group_user_defined_id} registry.cn-hangzhou.aliyuncs.com/log-service/logtail

参数说明

参数                                  参数说明

${your_region_name}                 region名,请替换为您创建的日志服务project所在Region。Region名称请从Logtail安装参数列表中选择。
${your_aliyun_user_id}                  用户标识,请替换为您的阿里云主账号用户ID。主账号用户ID为字符串形式。
${your_machine_group_user_defined_id}   您集群的机器组自定义标识。如您尚未开启自定义标识,请参考自定义机器组的步骤一,开启userdefined-id。

示例:docker run -d -v /:/logtail_host:ro -v /var/run/docker.sock:/var/run/docker.sock –env ALIYUN_LOGTAIL_CONFIG=/etc/ilogtail/conf/cn-hangzhou_internet/ilogtail_config.json –env ALIYUN_LOGTAIL_USER_ID=1473463995701522 –env ALIYUN_LOGTAIL_USER_DEFINED_ID=aliyun-sunaiwen-machine registry.cn-hangzhou.aliyuncs.com/log-service/logtail

查看lables配置信息

docker inspect 3fb1dd4bd2c7

logtail配置

未分类

未分类