大概今年 2 月份看到飞牛 OS 的路径穿越漏洞，觉得非常震惊，同时也带给我一个思考，就是不仅仅是飞牛，我们在云服务器，或者 NAS ，往往会部署非常多的服务，开很多端口，如果直接 DMZ 出去，这个攻击面是相当大的，而且不能依赖这些服务本身提供的登录接口来保护安全，因为你 A 服务是安全的，那 B 服务，C 服务呢，这是很难绷的
所以，面向切面编程（ AOP ）的思想由此体现，我们需要一个统一的，公共的，层，来集中解决这个问题
假设上游的服务就是存在漏洞的，并且还需要暴露到公网，那么中间需要加一层，这个层，以上游服务必然存在漏洞为前提而设计的
一开始的思路，是非常经典的 port knocking ，但做了点改动，用网页登录的方式，认证用户后调用 iptables 放行用户，然后在实际体验的过程中，发现用户体验有点差，随后发现了，其实可以用反向代理服务器，用 AOP 的思路，再叠加层来实现
所以后来的开发中心，集中到网关层，在统一网关，我们可以居中调度，可以知道流量从哪里来，打算去哪里，也知道如何去审查流量，还能继续叠加 WAF 层，鉴权层，日志审计层，甚至针对特定应用的 patch 层
然后，设计出了架构
Golang 单独编写的网关服务+monorepo typescript 的管理面
职责分离（ SOC ）
Go 网关：7999
monorepo-admin-server: 7998 ，管理面 API 端口
monorepo-auth-server: 7997 ，AUTH 外部访问鉴权
monorepo-admin-view: 7996 ，管理面前端
它们之间通过标准 API 来通信，Go 网关部分和 monorepo 部分是解耦的，monorepo 不关心 Go 网关如何实现，它可以用其他技术或容器提供服务
最终，对方案进一步改进和优化，得到了最终产品形态
https://www.fnknock.cn/
从一个专注安全的网关服务，转型成为公网暴露的综合工具
市面上已有 authelia ，但 authelia caddy 配置略有门槛，而 fnknock ，似乎更为简单
https://github.com/kci-lnk/fn-knock-turborepo
所以，面向切面编程（ AOP ）的思想由此体现，我们需要一个统一的，公共的，层，来集中解决这个问题
假设上游的服务就是存在漏洞的，并且还需要暴露到公网，那么中间需要加一层，这个层，以上游服务必然存在漏洞为前提而设计的
一开始的思路，是非常经典的 port knocking ，但做了点改动，用网页登录的方式，认证用户后调用 iptables 放行用户，然后在实际体验的过程中，发现用户体验有点差，随后发现了，其实可以用反向代理服务器，用 AOP 的思路，再叠加层来实现
所以后来的开发中心，集中到网关层，在统一网关，我们可以居中调度，可以知道流量从哪里来，打算去哪里，也知道如何去审查流量，还能继续叠加 WAF 层，鉴权层，日志审计层，甚至针对特定应用的 patch 层
然后，设计出了架构
Golang 单独编写的网关服务+monorepo typescript 的管理面
职责分离（ SOC ）
Go 网关：7999
monorepo-admin-server: 7998 ，管理面 API 端口
monorepo-auth-server: 7997 ，AUTH 外部访问鉴权
monorepo-admin-view: 7996 ，管理面前端
它们之间通过标准 API 来通信，Go 网关部分和 monorepo 部分是解耦的，monorepo 不关心 Go 网关如何实现，它可以用其他技术或容器提供服务
最终，对方案进一步改进和优化，得到了最终产品形态
https://www.fnknock.cn/
从一个专注安全的网关服务，转型成为公网暴露的综合工具
市面上已有 authelia ，但 authelia caddy 配置略有门槛，而 fnknock ，似乎更为简单
https://github.com/kci-lnk/fn-knock-turborepo
Select Language