利用Nginx auth模块快速搭建OAuth2.0 SSO单点登录系统

0

假设我们起了一个服务器在 1234 端口,但是我暴露在公网上,但是又需要被授权的人方便的使用,一般情况下我们会在程序里简单加一个密码验证,或者直接使用 Auth_Basic 设置一个用户名与密码。Nginx Auth_Basic 扫描是恶意爬虫最喜欢干的事,而限制 Auth_Basic 重试次数又需要配置 Fail2ban 之类的日志监控程序,很麻烦。

在应用层设置密码对大多数开发人员来说并没有什么难点,但是有时候我们搭建的系统并不是自己开发的,甚至是已经编译好的庞然大物,就有些困难了。

这里分享一个10分钟快速搭建 OAuth2.0 授权登录系统的方法,本文使用 github 作为示例。

SSH设置socks5代理

0

由于各大运营商不同时间段出口带宽拥堵的问题,需要维护又连接不上服务器很恼火,整理一下通过代理访问SSH服务器的配置。

macOS / Linux 环境

~/.ssh/config

Host hostname
    ProxyCommand nc -x 127.0.0.1:1080 %h %p

命令行使用方法 ssh -o "ProxyCommand=nc -x 127.0.0.1:1080 %h %p" [email protected]

windows 环境

%UserProfile%\.ssh\config

Host hostname
    ProxyCommand C:\Program Files\Git\mingw64\bin\connect.exe -S 127.0.0.1:1080 %h %p

批处理中要这样使用 ssh -o "ProxyCommand=C:\Program Files\Git\mingw64\bin\connect.exe -S 127.0.0.1:1080 %%h %%p" [email protected]

Centos 升级 libstdc 库文件

0
libstdc++.so.6: version `GLIBCXX_3.4.20' not found

错误信息是由于gcc版本低导致的,Centos通过yum无法升级,标准方案是手动编译安装,但是gcc编译少要半个小时,腾讯云的云盘可能要编译几个小时,不过有个取巧的办法,可以手动下载debian的二进制文件,下载地址 http://ftp.de.debian.org/debian/pool/main/g/gcc-*/ 根据需要选择 i386.deb 与 amd64.deb ,lib目录下放的是32位,lib64目录下是64位,如果是在其他奇怪的目录可以通过 file 命令查看原文件是32还是64位。

高能预警!!!
glibc是linux系统的核心部分,系统的很多文件就是基于这个程序编译,以下操作可能会导致未知的后果,仅限开发阶段,生产环境万万不可以。

然后在debian下解压出需要的文件

cd /usr/lib[ro lib64]
chmod +x libstdc++.so.6.0.20
rm -f libstdc++.so.6
ln -s libstdc++.so.6.0.20 libstdc++.so.6

再检查一次看看

$ strings /usr/lib/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_DEBUG_MESSAGE_LENGTH

glibc

查看glibc版本

# 查看链接
ls -l /lib/libc.so.*
# ldd 返回glibc版本
ldd --version

编译 glibc

curl -O http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.gz
tar zxf glibc-2.18.tar.gz 
cd glibc-2.18/
mkdir build
cd build/
../configure --prefix=/usr
make -j2
make install

nginx 配置文件历史 – fastcgi_params 与 fastcgi.conf

0

首先这是一个历史遗留问题,这篇文章没有什么技术点,只是对刚接触 nginx 的同学解开一点可能遇到的困惑。

在诸多发行版中默认 nginx 安装后你会发现在 /etc/nginx 目录下有两个fastcgi配置文件,fastcgi_params 与 fastcgi.conf,运行diff后你会发现他们的区别只有一行,既fastcgi.conf多了一个fastcgi_params配置

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;

SCRIPT_FILENAME 参数对PHP的运行是必不可少的,它的作用是告诉后端 PHP 应该执行哪个文件,但是由于历史原因他并没有被添加到 fastcgi_params 中。

在 nginx 0.6.x 时代,nginx 提供的默认配置中使用的是硬编码的方式

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /var/www/foo$fastcgi_script_name;
    fastcgi_pass backend;
}

这对迁移造成了不必要的麻烦,后来 nginx 建议大家使用 $document_root 来替代真实路径,大家慢慢开始使用它来替换之前的硬编码方式,但是很多年以后很多人依然在使用绝对路径,于是 nginx 在 0.8.30 中开始提供一个新的配置文件 fastcgi.conf来保持向后兼容,这样以来社区就可以推荐大家使用 fastcgi.conf 不需要在 location 中手动添加 SCRIPT_FILENAME。

现在我们引入这个文件可以使用下面的方式

location ~ \.php$ {
    include fastcgi.conf;
    fastcgi_pass backend;
}

如果你发现你的配置文件是

location ~ \.php$ {
    include fastcgi_params;
    SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass backend;
}

那也不用着急去修改自己的配置文件,无论使用这两种的哪一种,对 nginx 来说都是一样的。

搭建自己的临时邮箱

4

托管安装

Forsaken Mail 没有域名限制,只需要将自己的域名解析到已经部署的任意服务器。

自行搭建环境要求

1、服务器需要开启25端口

2、域名解析

# MX记录
xx.com MX 10 mx.xx.com
# A记录 
mx.xx.com A 服务器IP
# A记录
mail.xx.com A 服务器IP

ESNI 加密装甲中的最后一个缝隙

1

随着TLS 1.3问世,网络流量迈入了新时代,DoH和DoT都是将不同形式的数据包通过TLS 1.3加密,网络中可嗅探的数据变得越来越少,我前面发过一篇透过公共Wi-Fi 热点上网究竟安不安全,DNS加密后并且全程使用HTTPS协议,网关中依然会泄露访问的域名。

这里就需要普及一个名词叫做SNI,简单说因为服务器和客户端建立加密连接之前,客户端需要请求证书并明文发送主机名给服务器,服务器发送证书后,本地客户端再加以校验,这是因为通常同一个服务器端会部署多个域名服务,TLS握手发生在建立加密连接之前,如果直接扔过来一个加密包服务器端无法知道包的内容,也无法决定返回哪一个证书,所以网关仍然可以获取客户端访问的域名列表。

题外话:由于SNI的特性,通常NGINX服务器直接通过域名访问会泄露配置文件中的第一个证书,而有心者这可以通过证书内容获取很多信息,这个“漏洞”暂时还无法解决。

IETF在最新的草案中设计了一种新的加密SNI机制 Encrypted Server Name Indication(ESNI),ESNI要求DNS服务器负责随解析记录分发一个公钥,这样在TLS握手时,客户端就可以将通过加密DNS获取的公钥一并发送给服务器来直接建立加密连接,从而堵上了信息泄露的最后一个口子。

ESNI目前还在草案中,甚至还有很多可用性修复工作正在进行中,不过各大浏览器上已经在积极适配,Cloudflare在ESNI上特别积极,他们已经在1.1.1.1和所有Cloudflare节点部署ESNI完成。

目前浏览器支持方面比较悲观,仅Firefox 62+可以开启,Chrome开发组表示ESNI需要基于安全稳定的DNS服务,将会放在DoH适配之后,Cloudflare还煞有介事的制作了一个ESNI支持检测

Firefox 开启 ESNI 方法
在地址栏输入about:config进入设置页面,修改network.trr.mode选项,设置为2优先使用DoH,设置为3则仅使用DoH。
修改network.trr.uri选项可以指定DoH服务器,默认是https://mozilla.cloudflare-dns.com/dns-query,我们也可以手动修改为https://dns.google.com/experimental或者https://1.0.0.1/dns-query

也可以修改network.trr.resolvers值后,在选项 网络设置中配置服务器。

[{ "name": "Cloudflare", "url": "https://mozilla.cloudflare-dns.com/dns-query" },{ "name": "1.0.0.1", "url": "https://1.0.0.1/dns-query" },{ "name": "Google", "url": "https://dns.google/dns-query" },{ "name": "朽木", "url": "https://dns.xiumu.org/dns-query" }]

接下来点击修改network.security.esni.enabled即可开启ESNI。

DNS、DoH、DoT、DNSCrypt 都是什么?解密DNS所有黑科技

0

国内的环境下说起DNS首先要解决的就是DNS抢答、运营商劫持,更有甚者v2ex曾有人爆料电信运营商内部出现高级内鬼劫持Cloudflare节点跳转菠菜网站,这里我整理一些常见的解决方案以及各种方案的利弊。

首先什么是DNS?

DNS是一项互联网基础服务,它通过几台互联网根服务器的数据库分发给各个子节点,将域名和IP地址进行对应,多数情况下使用TCP和UDP的53端口通讯。换句话说DNS负责告诉你访问的网络服务究竟对应的是哪家公司或机房的服务器,详细内容参见DNS记录类型列表,这里就不再赘述。那么问题来了如果它告诉你的答案是精心伪造的呢?

为什么要使用加密DNS?

由于DNS规则制定在互联网早期,也根本没有考虑到会出现DNS缓存投毒攻击的情况,所以DNS服务器都是明文通讯,这就导致数据包可以在传输中受到干扰,且支持抢答,结果就导致了很多运营商或者组织在互联网上搭建了很多恶意节点分发虚假数据,干扰部分网络的正常访问、插播广告,而网络管理员和运营商劫持DNS插播广告是或拿来做数据分析本身是一块比较大的蛋糕,作为既得利益者更会阻碍DNS加密协议的推行(腹黑揣测)。

怎么防止DNS干扰?

Linux 环境启用PHP yaf拓展

1
# 下载yaf
wget -c http://pecl.php.net/get/yaf-3.0.8.tgz
# 解压缩
cd yaf-3.0.8/ && phpize
# 编译安装
./configure --with-php-config=php-config
make && make install
# 启用拓展
echo 'extension=yaf.so
yaf.use_namespace=1' > /etc/php/7.3/mods-available/yaf.ini
ln -s /etc/php/7.3/mods-available/yaf.ini /etc/php/7.3/fpm/conf.d/20-yaf.ini
# 重启服务
service php7.3-fpm restart

透过公共Wi-Fi 热点上网究竟安不安全?

1

先说结论,HTTPS大面积普及的情况下,免费Wi-Fi的安全性虽然不高,但是绝对没有那么差!关于这个话题炒的未免太过了

虽然不能说SSL/TLS加密是绝对安全的,但是如果使用的设备本身没有携带后门,你不是FBI正在调查的国际逃犯,也没有在网监的监控名单,对普通用户来说公共Wi-Fi仅仅是用网银App是没有安全方面问题的

信息泄露很多情况是因为你不知道什么App是用HTTP明文通讯或者允许假证书HTTPS访问的,因为大流量的App开启HTTPS加密对服务器也是一个额外的负载,用HTTP是可以直接节省下真金白银的,在公共网络中尽量不要使用小众App,尤其是个人开发者的作品,即使你觉得那些信息即使泄露也无所谓,也会带来被社工、撞库的风险

如果你能确定你的设备根证书是可以信任的,加上可信应用商城下载的浏览器(最好是支持HSTS的,如chrome)、官方版本的微信、支付宝、网银App,浏览网页的时候https旁边有绿色的小锁,中间人什么也做不了

不建议在不可信网络环境中进行更新/安装App等操作,尤其是弹出来诱导你安装的App,这可能会给中间人有可乘之机

也不建议访问所有http协议,由于攻击者无法破解TLS加密,所以他们可能会劫持DNS,使本来走HTTPS的流量走自行搭建的反向代理HTTP协议,他们也会精心制作钓鱼网站来诱导你主动提供有用的信息

由于SSL/TLS本身的协议缺陷或者算法漏洞,导致的可能出现的中间人攻击,运营者会第一时间修复的,银行的信息安全专家也不是只领工资不干活的

如果连HTTPS都无法信任的话,电信运营商的服务器就不会被入侵吗,流量就一定安全吗,伪基站了解一下

极端情况黑客精心打造的利用了可以震惊世界的TLS协议本身漏洞或者设备的0day来攻击你,你躲在地下室接入在家里拉的专线也未必就安全

如果有自建VXN,以上都是废话了