受欢迎的博客标签

Part1 - Linux 安全清单

Published

针对生产环境,整套 Linux 操作系统及 .NET Web 应用的安全防护体系可从 OS、SSH、应用层到依赖项全面加固

 

操作系统安全

 

ssh访问安全

 

应用程序权限

 

操作系统安全

操作系统安全0day(Zero-Day):是指尚未被公开披露、也没有官方补丁的系统级安全漏洞。

配置 unattended-upgrades 自动安装系统关键安全更新

部署 Fail2ban 监控认证失败日志并自动封禁异常 IP

 

ssh访问安全

指定特定 IP 范围才允许连接 SSH 端口

 

第三方应用程序安全

 

用 Docker 容器化部署第三方服务(如 Redis、MongoDB、Nginx)

容器内部运行使用非 root 用户

使用精简的基础镜像(如 [mcr.microsoft.com/dotnet/aspnet:8.0-alpine](https://mcr.microsoft.com/dotnet/aspnet:8.0-alpine))。

 

diy应用程序安全

.net web app

使用了有安全漏洞的 NuGet 包

在当前解决方案中找到并修复有安全漏洞的 NuGet 包,更新到兼容的安全版本并验证构建通过

包 "MessagePack" 2.5.187 具有已知的 中 严重性漏洞,https://github.com/advisories/GHSA-2f33-pr97-265q

 

frpc

漏洞原理:在使用 routeByHTTPUser 作为访问控制的 HTTP vhost 路由路径中,frp 存在凭据处理不一致的问题。攻击者可以通过构造请求绕过身份验证,直接访问受保护的后端服务。

依赖库漏洞

Go 语言编写的项目,frp 的历史版本经常受到底层标准库或第三方加密库(如 golang.org/x/crypto、go-jose 等)漏洞的影响

 

 

Docker 安全

1.默认情况下,容器内的 root 通常受到命名空间和 Linux capabilities 等机制限制,并不等于宿主机 root。但如果使用 --privileged、添加危险 capabilities,或者使用 host PID 等高权限配置,攻击面会显著扩大

2.利用 Linux 内核或容器运行时漏洞

所有普通 Docker 容器都共享宿主机内核。假如攻击者能利用内核漏洞实现容器逃逸,就可能突破容器隔离。Docker Engine、containerd、runc 等组件的漏洞也可能造成风险

3.docker 内以root用户运行,意味着如果容器进程被入侵,它有可能访问和修改底层主机上的所有文件。如果容器进程以root身份运行,它有可能写入主机的文件系统或生成监听来自远程系统的连接的进程。

4.通过宿主机服务或网络接口攻击

容器可能访问宿主机上的管理端口、数据库、Docker API 或局域网内其他设备。如果这些服务缺少认证或存在漏洞,就可能形成进一步入侵的路径。

 

http://192.168.2.125:8070/#/devices ,同一局域网,宿主机 sudo ufw status
Status: active

To Action From
-- ------ ----
22/tcp ALLOW Anywhere 
8123/tcp ALLOW Anywhere 
22/tcp (v6) ALLOW Anywhere (v6) 
8123/tcp (v6) ALLOW Anywhere (v6) ,为何可以访问?

 

在宿主机 ufw(防火墙)只放行了 22 和 8123 端口的情况下,你依然能访问 8070 端口,通常是因为 该服务运行在 Docker 容器中,且使用了端口映射(如 -p 8070:8070)。
这是 Linux 系统中一个非常经典且常见的“防火墙失效”现象,根本原因如下:

核心原因:Docker 绕过了 UFW
Docker 直接操作 iptables:当 Docker 启动并映射端口时,它会直接在 Linux 内核的 iptables 中添加转发规则(通常在 PREROUTING 链和 DOCKER 链中)[1]。
UFW 的规则流向靠后:UFW 只是一个管理 iptables 的前端工具,它生成的规则主要放在 ufw-user-input 等自定义链中。
网络包处理顺序:当外部请求访问你的 8070 端口时,Linux 内核在处理网络包时,先匹配到了 Docker 的路由转发规则。Docker 直接把流量丢给了对应的容器,完全没有走 UFW 的过滤逻辑[1]。因此,无论你的 sudo ufw status 里写了什么,对 Docker 映射的端口都是无效的[1]。


解决方案

命令行启动:将 -p 8070:8070 改为 -p 127.0.0.1:8070:8070

 

 

 

 

 

 

vultr 通过云控制台新建普通用户

通过普通用户安装docker

用普通用户在根目录下创建子目录,并赋予普通用户读写权限,仅限普通用户和docker读写权限