从这次飞牛 0day 这么恶劣的影响来看，在公网上开放服务真的是非常危险，尤其是碰到 0day 漏洞持续这么久不作为，更加重了影响。
我为了方便一些服务使用，比如 dokuwiki, mtphotos 以及自己用 docker 部署的一些小工具，都还是开放了公网的端口访问，采用 DDNS 。
目前我的方案是这样，即使服务原生还权限验证包括什么 2FA 啥的，我都把它们部署在内网提供 http 服务，然后自己部署了一套 caddy （之前是用 nginx)来提供 https 再加一层 basic auth 认证。
比如 dokuwiki 和 mtphotos ，他们本身都有用户名认证，但是我在外网需要访问的时，打开对应的端口时需要先输入外层的 basic auth 认证才会进入这些服务自己的登陆界面，再输入用户名密码。
这套方案是之前在公司部署 jira 和 confluence 时折腾出来的，老早部署了 jira 之后三天两头被网关发邮件说有漏洞，后来在外面套了一层 https+basic auth 之后就再也没被扫到过了。
按我的理解，这些漏洞不管怎么严重最终都是需要通过开放的端口来进行命令注入的，只要最外层的 https basic auth 不泄漏其实他们就进不去那些有漏洞的服务端口。
这个方案有两个缺点，一是每次需要输入两次认证，有些浏览器似乎会较长时间记住外层的 basic auth 比如 firefox 但是 safari 就需要每次都输入（不过只要网页不关闭就不需要重复输入）；二是有些服务是占用了 http header 里的 auth 字段导致外层的 basic auth 和服务的用户认证冲突。
这里要表扬一下 mtphotos ，最早的时候 mtphotos 就是使用了 http header 里的 auth 字段来传输认证导致和我外层的 basic auth 冲突，后来在群里提出这种用户之后（虽然有其它用户不屑这种用法），作者很快就更新了认证机制，现在不管是网页打开 mtphotos 还是 app 连接 mtphotos 都支持这种双层认证。
不知道这种方案有没有其它缺陷？ https 的 basic auth 应该是最简单粗暴，除了中间人攻击外应该不会有什么漏洞绕过吧？
我为了方便一些服务使用，比如 dokuwiki, mtphotos 以及自己用 docker 部署的一些小工具，都还是开放了公网的端口访问，采用 DDNS 。
目前我的方案是这样，即使服务原生还权限验证包括什么 2FA 啥的，我都把它们部署在内网提供 http 服务，然后自己部署了一套 caddy （之前是用 nginx)来提供 https 再加一层 basic auth 认证。
比如 dokuwiki 和 mtphotos ，他们本身都有用户名认证，但是我在外网需要访问的时，打开对应的端口时需要先输入外层的 basic auth 认证才会进入这些服务自己的登陆界面，再输入用户名密码。
这套方案是之前在公司部署 jira 和 confluence 时折腾出来的，老早部署了 jira 之后三天两头被网关发邮件说有漏洞，后来在外面套了一层 https+basic auth 之后就再也没被扫到过了。
按我的理解，这些漏洞不管怎么严重最终都是需要通过开放的端口来进行命令注入的，只要最外层的 https basic auth 不泄漏其实他们就进不去那些有漏洞的服务端口。
这个方案有两个缺点，一是每次需要输入两次认证，有些浏览器似乎会较长时间记住外层的 basic auth 比如 firefox 但是 safari 就需要每次都输入（不过只要网页不关闭就不需要重复输入）；二是有些服务是占用了 http header 里的 auth 字段导致外层的 basic auth 和服务的用户认证冲突。
这里要表扬一下 mtphotos ，最早的时候 mtphotos 就是使用了 http header 里的 auth 字段来传输认证导致和我外层的 basic auth 冲突，后来在群里提出这种用户之后（虽然有其它用户不屑这种用法），作者很快就更新了认证机制，现在不管是网页打开 mtphotos 还是 app 连接 mtphotos 都支持这种双层认证。
不知道这种方案有没有其它缺陷？ https 的 basic auth 应该是最简单粗暴，除了中间人攻击外应该不会有什么漏洞绕过吧？
 |
1
dushixiang 5 小时 36 分钟前
除了每次都需要输入账号密码之外没啥问题，但是 basic auth 设置的简单了容易被爆破，设置的复杂了有记不住，每次都要去密码本里面找。
所以我的 Next-Terminal 就可以完美的解决这种问题，想要访问必须先登录鉴权，支持设置验证码、暴力破解账号 或 IP 锁定，也支持设置禁止密码登录，使用 Passkey 。 一个演示地址 https://baidu.typesafe.cn 登录 test/test 账号有权限访问，manager/manager 无权限访问 |
 |
2
f1ynnv2 OP @dushixiang 感谢大佬，看了一下这个方案，真的是完美啊比 basic auth 体验好多了，尤其是支持 passkey 。准备付费了。 有一些疑问，像是 mtphotos 这种 app 和网页连接一样的端口，网页登录的时候可以通过 next terminal 鉴权，那 app 登录的时候是不是就没办法通过 next terminal 了？
|
|
3
dushixiang 5 小时 19 分钟前
@f1ynnv2 目前已经增加了一个临时 IP 白名单的功能，点击后会自动放行 IP XX 分钟（这个时间可以自定义），另外还可以通过内置的 API Token 来定时请求接口来放行 IP 。
|
 |
4
Heisenhower 4 小时 5 分钟前
装一个雷池（ safeline ）社区版就够用了
|
 |
5
bigtan 4 小时 2 分钟前
我家里的小主机啥的都是 ipv6 直接公网可以访问，不过我都是更新比较勤，而且 ssh 只开 key ，到现在还没出过事。
|
 |
6
gvdlmjwje 2 小时 1 分钟前
搭楼问个问题，我也是 ddns 的方案，nginx proxy manager 做 https 反代的，如果我要加一层雷池 waf 应该加在哪里？现在的路径是这样的：腾讯云 DNS——路由器公网映射 IP:8443——NPM(泛域名+SSL)——docker 。应该吧 waf 加在 NMP 前级吗？
|
Select Language