Linux安全技术

• ubuntu14.04 BIND漏洞修复
• 设置zookeeper白名单
• OpenSSH_6.6.1p1升级到openssh-9.1p1
• 跨源资源共享（CORS）配置不当导致安全漏洞
• nginx-1.24.0升级到1.27.0
• 部署wazuh实现对多台 Ubuntu 主机进行集中监控
• 一键可视化Nginx日志
• 如何自查linux系统是否存在漏洞
• 这个被99%运维忽略的功能，竟然能秒杀所有漏洞扫描
• Nginx ssl强化安全配置
• Ubuntu 18.04 部署 ModSecurity（含 Nginx）安装方式
• 服务器为什么会发 RST
• nmap扫描https端口高危漏洞解决方案
• 修复ZooKeeper未授权访问漏洞
• ubuntu14.04用iptables添加屏蔽IP规则
• firewall-cmd命令安全加固OpenClaw服务器
• 针对 Ubuntu 18.04 服务器，要仅封禁特定 IP 地址且不影响其他任何端口及 IP 的访问
• Dubbo 服务运行在 Docker 容器中，修复漏洞方法如下
• 732字节、1秒root、九年无人知——Linux近年最稳定提权漏洞
• 银河麒麟v10高级服务器系统OpenSSH漏洞修复建议
• 银河麒麟v10 升级 SSH由8.2到9.9 二进制安装失败
• 银河麒麟v10高级服务器系统如何防止fiewalld服务自启
• 麒麟v10 kylin v10 清除firewall所有策略恢复原始

ubuntu14.04 BIND漏洞修复

设置zookeeper白名单

OpenSSH_6.6.1p1升级到openssh-9.1p1

跨源资源共享（CORS）配置不当导致安全漏洞

nginx-1.24.0升级到1.27.0

部署wazuh实现对多台 Ubuntu 主机进行集中监控

对多台 Ubuntu 主机（例如 Ubuntu 18.04）进行集中监控，同时实现 **主机入侵检测（HIDS）** 和 **行为监控**，以下是一个轻量级、实用的集中监控方案，适用于中小型企业：

### ✅ 方案目标

* 实现主机入侵检测（Host-based IDS）
* 实现进程、登录、系统变更等行为监控
* 支持集中化日志采集与统一展示
* 成本低、依赖少，易于部署和维护

## 🧩 架构组件

| 角色                  | 工具                                                | 说明                           |
| ------------------- | ------------------------------------------------- | ---------------------------- |
| Agent（每台 Ubuntu 主机） | [Wazuh Agent](https://documentation.wazuh.com)    | 实时监控主机安全事件（文件完整性、登录、root提权等） |
| 集中服务器               | Wazuh Manager + Filebeat + Elasticsearch + Kibana | 管理所有 Agent 数据，并提供可视化界面       |
| 日志转发                | Filebeat                                          | 将日志高效传输至 Elasticsearch       |
| 可选轻量级替代             | [OSSEC](https://www.ossec.net/) + Graylog         | 更轻的方案，但功能相对简单                |

---

## 🛠️ 部署简要步骤

### 1. 安装 Wazuh Server（集中监控端）

部署在一台专用 Ubuntu 主机（建议 ≥4C/8G）

cp /etc/apt/sources.list /etc/apt/sources.list.bak

cat > /etc/apt/sources.list << EOF
deb https://mirrors.aliyun.com/ubuntu/ bionic main restricted universe multiverse
deb-src https://mirrors.aliyun.com/ubuntu/ bionic main restricted universe multiverse
deb https://mirrors.aliyun.com/ubuntu/ bionic-security main restricted universe multiverse
deb-src https://mirrors.aliyun.com/ubuntu/ bionic-security main restricted universe multiverse
deb https://mirrors.aliyun.com/ubuntu/ bionic-updates main restricted universe multiverse
deb-src https://mirrors.aliyun.com/ubuntu/ bionic-updates main restricted universe multiverse
deb https://mirrors.aliyun.com/ubuntu/ bionic-backports main restricted universe multiverse
deb-src https://mirrors.aliyun.com/ubuntu/ bionic-backports main restricted universe multiverse
EOF

apt update && apt upgrade -y

ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime &&\
apt-get install ntpdate -y &&\
if ! crontab -l | grep "ntpdate" &>/dev/null; then
    (echo "*/5 * * * * /usr/sbin/ntpdate ntp.aliyun.com >/dev/null 2>&1"; crontab -l) | crontab
fi

linux系统通过代理上网
vi ~/.bashrc
在文件末尾添加以下内容
cat >> ~/.bashrc << EOF
export http_proxy="http://192.168.8.5:1080"
export https_proxy="http://192.168.8.5:1080"
export ftp_proxy="http://192.168.8.5:1080"
export no_proxy="localhost,127.0.0.1,::1"
EOF
保存关闭
source ~/.bashrc
sudo vi /etc/apt/apt.conf.d/95proxies
添加以下内容：
Acquire::http::Proxy "http://192.168.8.5:1080";
Acquire::https::Proxy "http://192.168.8.5:1080";
Acquire::ftp::Proxy "http://192.168.8.5:1080";

在系统级别配置代理，以便所有应用程序都使用代理服务器
sudo vi /etc/environment
http_proxy="http://192.168.8.5:1080"
https_proxy="http://192.168.8.5:1080"
ftp_proxy="http://192.168.8.5:1080"
no_proxy="localhost,127.0.0.1,::1"
保存关闭
sudo reboot

http_proxy="http://10.2.2.24:1080"
https_proxy="http://10.2.2.24:1080"
ftp_proxy="http://10.2.2.24:1080"
no_proxy="localhost,127.0.0.1,::1"

如果你还需要Docker通过代理上网，可以通过以下步骤配置Docker代理。
创建Docker的systemd目录（如果不存在）：
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo vi /etc/systemd/system/docker.service.d/http-proxy.conf
添加以下内容：
[Service]
Environment="HTTP_PROXY=http://192.168.8.5:1080"
Environment="HTTPS_PROXY=http://192.168.8.5:1080"
Environment="NO_PROXY=localhost,127.0.0.1,::1"
保存关闭
sudo systemctl daemon-reload
sudo systemctl restart docker

curl -sO https://packages.wazuh.com/4.12/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

在 Wazuh 4.x（包括你安装的 4.12.0）中，`admin` 是一个系统保留账户，不允许通过 Web 界面或 API 直接重设密码。

## ✅ 正确的解决方法：

### 🛠 方法一：在命令行重置 `admin` 密码

你可以在 **Wazuh Dashboard 所在的主机上**运行以下命令来重置密码：

```bash
/usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.s reset-admin
```

这将：

* 生成一个新密码
* 输出密码（请记得保存）

### 🛠 方法二：手动设置密码（推荐）

```bash
/usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh --user admin --password 新密码
```

例如：

/usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh --user admin --password Heli@147369.

执行后会看到提示密码修改成功。

## ✅ 修改后重启 Wazuh Dashboard（可选）

如果你登录仍有问题，可重启 Dashboard 服务：

systemctl restart wazuh-dashboard

安装agent

官方方法：在ubuntu20.04 18.04 14.04上测试通过

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.12.0-1_amd64.deb && sudo WAZUH_MANAGER='10.2.2.16' WAZUH_AGENT_NAME='ubuntu20.04-2.18' dpkg -i ./wazuh-agent_4.12.0-1_amd64.deb

10.2.2.16 替换为 wazuh server端ip地址

ubuntu20.04-2.18 替换为该agent的名称

sudo systemctl daemon-reload &&\
sudo systemctl enable wazuh-agent &&\
sudo systemctl start wazuh-agent

其他方法，在ubuntu14.04上测试通过
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list
apt-get update
apt-get install gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add -
echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list
WAZUH_MANAGER="192.168.30.49" apt-get install wazuh-agent

ubuntu安装客户端
service wazuh-agent start

service wazuh-agent status
wazuh-modulesd is running...
wazuh-logcollector is running...
wazuh-syscheckd is running...
wazuh-agentd is running...
wazuh-execd is running...

卸载方法：
1. 停止 agent 服务（可选但推荐）：

sudo systemctl stop wazuh-agent

2. 卸载 wazuh-agent：

sudo apt-get remove --purge wazuh-agent -y

3. 删除相关配置文件（可选，如果你想彻底清除）：

sudo rm -rf /var/ossec
sudo rm -rf /etc/ossec-init.conf
sudo rm -rf /etc/systemd/system/wazuh-agent.service

4. 更新 systemd（可选）：

sudo systemctl daemon-reload

## ✅ 修改 agent 名称的正确方式

Wazuh agent 的名称保存在配置文件中，你可以按以下步骤修改：

### 1. 停止 agent 服务

```bash
sudo systemctl stop wazuh-agent
```

### 2. 修改配置文件 `/var/ossec/etc/ossec.conf`

找到如下配置段落（大约在前几十行）：

```xml
<client>
  <name>ubuntu14.04-2.14</name>
  <server-ip>10.2.2.16</server-ip>
</client>
```

将 `<name>` 修改为你想要的新名称，例如：

```xml
<client>
  <name>ubuntu14.04-new</name>
  <server-ip>10.2.2.16</server-ip>
</client>
```

保存退出。

---

### 3. 删除旧的 `client.keys` 条目（可选，若你在 manager 上要重配）

登录 Wazuh Manager，然后运行：

```bash
/var/ossec/bin/manage_agents
```

选择：

* `R` 删除旧名称对应的 agent
* `A` 添加新名称
* `E` 保存并分发 key，得到以下这串字符

MDA0IHVidW50dTE0LjA0LWNjaW90LTIuMTQgMTAuMi4yLjE0IDEwMjJiY2U2N2ViNGY2MmYzMTAzZGZjNTFlZWMzYzBhNjE1ZjI1ZGNmNzU4ZGRlNjRiMmZjMmY3MWMxMGI1ZWM=

到 agent 端运行：

/var/ossec/bin/manage_agents

选 I ，粘贴key  上面那串字符

### 4. 重启 agent 服务

```bash
sudo systemctl start wazuh-agent
```

---

### ✅ 验证新名称是否生效

查看 agent 日志：

```bash
sudo tail -f /var/ossec/logs/ossec.log
```

你应该能看到类似如下内容：

```
ossec-agent: INFO: Using agent name as configured: 'ubuntu14.04-new'
```

在 Wazuh Manager UI 中刷新 agent 列表，也应能看到新名称。

一键可视化Nginx日志

兄弟们有没有遇到过这种情况？网站突然卡顿，翻遍服务器日志却找不到头绪；想知道哪些 接口被频繁调用，却对着密密麻麻的文本文件抓瞎。今天二冰给大家带来一个开箱即用的运 维神器——用Docker三分钟搭建Nginx Proxy Manager日志可视化平台！

项目简介：GoAccess for Nginx Proxy Manager

项目地址：https://github.com/xavier-hernandez/goaccess-for-nginxproxymanager

这个基于GoAccess的专用镜像，完美适配Nginx Proxy Manager的日志格式。无需研究复杂 的命令行参数，挂载日志目录就能生成酷炫的实时监控面板，流量统计、访问排行、异常请 求一目了然。

四大核心优势

手把手Dockge部署教程

第一步：准备compose.yaml

version: "3" services: goaccess: image: xavierh/goaccess-for-nginxproxymanager:latest container_name: goaccess restart: unless-stopped ports: - "7880:7880" volumes: - /你的日志目录:/opt/log # 例如/volume1/docker/npm/data/logs environment: - TZ=Asia/Shanghai -.UTF-8 - LANGUAGE=zh_CN.UTF-8 - SKIP_ARCHIVED_LOGS=False - EXCLUDE_IPS=127.0.0.1

第二步：Dockge一键部署

打开Dockge面板 -> 创建堆栈 -> 设置堆栈名称 -> 粘贴compose代码 -> 30 秒启动成功！

使用效果全展示

访问 http://你的服务器IP:7880 即可看到：

二冰实测总结

推荐指数：★★★★☆

适合人群：

注意事项：

这个项目最大的惊喜是完美保留了GoAccess的专业分析能力，又通过Docker封装大幅降低了  使用门槛。实测在4核8G服务器上处理百万级日志毫无压力，界面响应速度堪比商业监控系  统。唯一的遗憾是暂不支持多日志源混合分析，不过对专注NPM的用户来说完全够用！

需要看板演示的兄弟，欢迎在评论区留言索取测试地址。如果觉得这篇教程有帮助，记得点 赞收藏支持一波！

最后，奉上我的超级无敌至尊docker库，二冰平时玩过的docker都整理到了这个仓库中了， 一直在更新中，希望有github账号的兄弟能去给点个star，不知道玩啥的，都去这里面找， 都给你们分好类了 仓库链接： https://github.com/TWO-ICE/Awesome-NAS-Docker

Ubuntu系统中文显示教程：

1.安装中文包

apt update
apt install language-pack-zh-hans
2.将区域语言设置为简体中文

localectl set-locale LANG=zh_CN.utf8

localectl status
localectl list-locales | grep zh
localectl set-locale LANG=zh_CN.utf8
localectl status

docker exec -it goaccess /bin/bash
#在容器内执行，建议先备份/var/www/html/index.html
LANG="zh_CN.UTF-8"  ./goaccess -f /opt/log/access.log --log-format=COMBINED > /var/www/html/index.html

显示效果如下：

如何自查linux系统是否存在漏洞

 在Linux系统中，自查系统是否有漏洞是一个重要的安全实践，这可以帮助你及时修补安全漏洞，保护你的系统不被恶意攻击。以下是一些常用的方法和工具，可以帮助你检测Linux系统的安全漏洞：

1. 使用系统更新工具

对于Debian/Ubuntu及其衍生版：

sudo apt update && sudo apt upgrade

对于Fedora/CentOS及其衍生版：

sudo dnf update

2. 使用安全扫描工具

    a. OpenVAS（Open Vulnerability Assessment System）
OpenVAS是一个强大的开源漏洞扫描工具，它可以检测多种类型的漏洞。

安装OpenVAS：

sudo apt install openvas

启动OpenVAS服务并运行扫描：

sudo openvas-start
sudo openvas-check-setup
sudo openvasmd --create-user=admin --role=Admin

b. Nessus
Nessus也是一个流行的商业和开源漏洞扫描工具。虽然它是商业软件，但有免费版本可供使用。

下载并安装Nessus（以开源版本为例）：

sudo apt install nessus

c. Lynis
Lynis是一个安全审计工具，可以检查系统配置并报告潜在的安全问题。

安装Lynis：

sudo apt install lynis

运行Lynis：

sudo lynis audit system

3. 检查常见漏洞的公告和日志

    关注安全公告：订阅相关的安全邮件列表或RSS源，如US-CERT、CVE Mitre等，了解最新的安全漏洞信息。

检查系统日志：查看/var/log/目录下的日志文件，特别是auth.log和syslog，以发现任何异常登录尝试或其他安全相关的事件。

4. 使用在线服务检查已知漏洞数据库

    例如，使用Shodan或Censys等在线服务来检查你的系统是否已经被公开暴露在互联网上，并查看是否有已知的漏洞被利用。这些服务可以帮助你识别你的系统是否容易被攻击。

5. 定期进行渗透测试和安全演练

    定期进行内部渗透测试和安全演练可以帮助你发现和修复未被发现的安全问题。这可以由你的IT团队或外部安全专家执行。

    通过结合使用上述方法和工具，你可以有效地管理和减少Linux系统中的安全风险。

这个被99%运维忽略的功能，竟然能秒杀所有漏洞扫描

凌晨3点的噩梦

你好，我是赵兴晨，97年文科程序员。在公司里身兼数职，具体都做些什么，相信通过我的技术分享你会慢慢了解。

又是一个不眠夜。手机屏幕上密密麻麻的漏洞扫描报告让我头皮发麻——这次足足有几十个中间件版本在疯狂地"求升级"。

作为服务器的运维负责人，我深知这些中间件意味着什么：停机、测试、回滚……各种风险。一个不小心，整个业务都可能受到影响。看着那份长达十多页的漏洞清单，我陷入沉思……

那个改变一切的想法

在我准备通宵达旦制定升级计划时，突然想到了一个被我忽略已久的Linux功能组合：ipset和firewalld。这个想法让我眼前一亮！

既然升级这么麻烦，为什么不换个思路？如果我能让漏洞扫描器发现不了我的服务，那漏洞是不是就等于不存在了呢？这个想法像闪电一样击中了我。

传统方案 VS 神级方案

传统方案

# 在每台服务器上都要配置79条规则
iptables -A INPUT -s 10.0.0.1 -j ACCEPT
iptables -A INPUT -s 10.0.0.2 -j ACCEPT
iptables -A INPUT -s 10.0.0.3 -j ACCEPT
# ... 还有76条

总计:80 × 79 = 6320 条规则!

这不仅管理困难，性能也是灾难级的。每个数据包都要遍历几千条规则才能决定是否放行。

神级方案：ipset 一招制敌

而使用 ipset，你只需要：

# 创建IP集合（一次性）
firewall-cmd --permanent --new-ipset=trusted_servers --type=hash:ip

# 批量导入所有信任IP（一条命令）
firewall-cmd --permanent --ipset=trusted_servers --add-entries-from-file=/tmp/trusted-ips.txt

# 一条规则搞定所有（核心）
firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source ipset="trusted_servers" accept'

总计：每台服务器只需要1条规则！

从 6320 条规则到 80 条规则？不！是从 6320 条规则到 80 条规则！这就是降维打击！

方案详解

ipset + firewalld 旨在一组集群服务器内配置防火墙规则，以实现以下目标：

• • 集群内互信：集群内的所有服务器之间可以互相访问任何端口，不受限制。
• • 对外隔离：所有来自集群外部的访问流量（除了明确允许的，如SSH、HTTP等），都将被默认阻止。
• • 高效管理：采用 ipset 统一管理IP列表，避免为每台服务器单独配置大量重复规则，实现高效、可扩展且易于维护的防火墙策略。

为什么使用 ipset？

在一个拥有 N 台服务器的集群中，如果要在每台服务器上允许其他 N-1 台服务器的访问，就需要配置 N * (N-1) 条独立的防火墙规则。这在管理上是一场灾难。

ipset 是 Linux 内核中的一个框架，它允许你将大量的 IP 地址、网段或 MAC 地址存储在一个集合（set）中。然后，你可以在 firewalld 或 iptables 中仅用一条规则来匹配这整个集合。

优点：

• • 性能极高：内核使用哈希表等高效数据结构来查找IP，速度远快于遍历长长的规则链。
• • 管理便捷：IP地址的增删仅需在 ipset 集合中操作，无需改动核心防火墙规则。

实施步骤

前提条件：

• • 拥有所有服务器的 root 或 sudo 权限。
• • 准备好一份包含所有集群服务器IP地址的列表。
• • 强烈建议使用自动化工具（如 Ansible、SaltStack）来批量执行以下操作。
• • 也可以参考我的开源项目：https://gitcode.com/JasonChenn/batch_operation.git

第1步：创建 IP 地址白名单文件

在一台管理机上，创建一个名为 trusted-ips.txt 的文本文件。将所有需要互相通信的服务器的 IP 地址写入此文件，每行一个。

示例 trusted-ips.txt:

10.0.0.91
10.0.0.92
10.0.0.93
# ... 将所有80个IP地址都加进去
10.0.0.170

第2步：分发 IP 地址列表文件

使用自动化工具或 scp 命令，将 trusted-ips.txt 文件分发到集群中的每一台服务器上。建议放在一个临时目录，例如 /tmp/。

手动 scp 示例：

scp trusted-ips.txt root@10.0.0.91:/tmp/
scp trusted-ips.txt root@10.0.0.92:/tmp/
# ... 对所有服务器执行此操作

第3步：在所有服务器上配置 firewalld

在每一台服务器上执行以下命令序列来创建 ipset 并应用防火墙规则。

# 1. 创建一个永久的 ipset 集合，命名为 trusted_servers
#    --type=hash:ip 指定了集合的类型，适合存储独立的IP地址
sudo firewall-cmd --permanent --new-ipset=trusted_servers --type=hash:ip

# 2. 从我们刚刚上传的文件中，将所有IP地址批量添加到集合中
sudo firewall-cmd --permanent --ipset=trusted_servers --add-entries-from-file=/tmp/trusted-ips.txt

# 3. 添加核心防火墙规则：允许所有来自 trusted_servers 集合中的源IP的流量
#    这条规则被添加到 public zone，你可以根据环境修改为其他 zone
sudo firewall-cmd --permanent --zone=public --add-source=ipset:trusted_servers

# 4. 添加富规则：允许信任源访问所有端口（集群内互信）
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source ipset="trusted_servers" accept'

# 5. 重新加载防火墙配置，使所有永久规则立即生效
sudo firewall-cmd --reload

第4步（关键）：清理默认开放的服务

90%的人会在这里翻车!

这是非常重要的一步，通常是导致策略“无效”的直接原因。

在应用了 ipset 规则后，你可能会发现某些非信任IP（例如 10.0.0.91）依然可以访问集群内的服务器（例如通过 SSH）。这是因为 firewalld 的 public 区域在默认情况下可能已经允许了某些服务。

我们的 ipset 规则是“允许白名单IP访问所有端口”，但系统预设的规则可能是“允许任何人访问 ssh 端口”。这两条规则会同时生效，导致非白名单IP也能通过SSH访问。

诊断命令：
在集群内的服务器上执行，检查 public 区域的配置。

sudo firewall-cmd --zone=public --list-all

问题定位：
如果输出中 services: 这一行包含了 ssh，说明存在此问题。

public (active)
  ...
  sources: ipset:trusted_servers
  services: ssh dhcpv6-client  <-- 问题根源
  ...

修复命令（在所有服务器上执行）：
从 public 区域中移除预设的 ssh 服务，确保所有访问都由我们的 ipset 规则控制。

# 从 public zone 中移除 ssh 服务
sudo firewall-cmd --permanent --zone=public --remove-service=ssh

# 再次重载防火墙使配置生效
sudo firewall-cmd --reload

完成此步骤后，防火墙将严格执行我们设定的白名单策略。

第5步：验证配置

现在,你的服务器对外界来说就像人间蒸发了一样!

在任意一台服务器上执行以下命令，检查配置是否正确。

# 查看当前系统存在的所有 ipset 集合
sudo firewall-cmd --get-ipsets
# 预期输出: trusted_servers

# 查看 trusted_servers 集合中的具体条目
sudo firewall-cmd --info-ipset=trusted_servers
# 预期输出会列出你在 trusted-ips.txt 中添加的所有IP地址

# 查看 public zone 的允许源
sudo firewall-cmd --zone=public --list-sources
# 预期输出: ipset:trusted_servers

如果以上命令的输出都符合预期，那么你的集群防火墙策略已经成功部署。

测试结果:

• • ✅ 内网服务器之间:任意端口互通
• • ❌ 外网扫描器:所有端口都超时
• • ❌ 黑客探测:如同攻击空气

维护：像换灯泡一样简单

当集群需要增加或移除服务器时，维护工作非常简单。

场景：新增一台服务器 10.0.0.188

1. 1. 在管理机上，更新 trusted-ips.txt 文件，在文件末尾添加新IP 10.0.0.188。
2. 2. 将新服务器 10.0.0.188 按照上述第3步的完整流程进行初始化配置（包括富规则）。
3. 3. 将更新后的 trusted-ips.txt 文件分发到所有旧的服务器上。
4. 4. 在所有旧的服务器上执行以下命令，重新加载 IP 列表：

   # 更新 ipset 集合
   sudo firewall-cmd --permanent --ipset=trusted_servers --add-entries-from-file=/tmp/trusted-ips.txt
   
   # 确保富规则存在（如果之前未配置）
   sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source ipset="trusted_servers" accept'
   
   # 重新加载防火墙配置
   sudo firewall-cmd --reload

场景：移除一台服务器

1. 1. 在管理机上，从 trusted-ips.txt 文件中删除该服务器的IP。
2. 2. 将更新后的 trusted-ips.txt 文件分发到所有需要保留的服务器上。
3. 3. 在所有需要保留的服务器上，执行以下命令序列来重建 ipset：

   # 彻底移除旧的集合
   sudo firewall-cmd --permanent --delete-ipset=trusted_servers
   
   # 重新创建 ipset 集合
   sudo firewall-cmd --permanent --new-ipset=trusted_servers --type=hash:ip
   
   # 从更新后的文件中加载IP列表
   sudo firewall-cmd --permanent --ipset=trusted_servers --add-entries-from-file=/tmp/trusted-ips.txt
   
   # 重新添加富规则（删除ipset时富规则也会被清除）
   sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source ipset="trusted_servers" accept'
   
   # 重新加载防火墙配置
   sudo firewall-cmd --reload

安全提醒

这个方案虽然强大,但要明白它的边界:

⚠️ 无法防御内部攻击:如果集群中任何一台服务器被攻陷,攻击者可以访问所有其他服务器.

⚠️ 无法隐藏主机存在:ARP扫描还是能发现主机,但无法访问服务.

但对付漏洞扫描?完美!

写在最后

第二天早上，安全部门找我：“昨晚的漏洞扫描怎么一个都没发现?是不是扫描器坏了？”

我淡定地喝了口咖啡：“可能是服务器今天心情不好,不想被扫描吧。”

有时候，最懒的方案往往是最聪明的方案。

回想起那个不眠之夜，我庆幸自己没有选择"硬刚"升级所有中间件。有时候，换个思路就能找到更优雅的解决方案。

这个被99%运维忽略的ipset功能，确实改变了我的工作方式。如果你也在为漏洞扫描头疼，不妨试试这个方案，说不定会有意想不到的收获！

小贴士：虽然这个方案很好用，但记住它只是隐藏了服务，并不能真正修复漏洞。对于关键业务，该升级的还是要升级的！

你还在为漏洞扫描发愁吗？不如试试这个被99%运维忽略的神器！

记得点赞收藏，说不定哪天就能救你一命！ 😉

Nginx ssl强化安全配置

下面详细解释你给出的 Nginx 配置的作用，以及 应该放在哪个配置段才能生效。

✅ 一、这些配置的作用

1. SSL 安全相关

ssl_stapling on;
ssl_stapling_verify on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
resolver 119.29.29.29 182.254.116.116 valid=300s;
resolver_timeout 5s;

✔ ssl_stapling on

开启 OCSP Stapling，减少浏览器验证证书的延迟，加速 HTTPS。

✔ ssl_stapling_verify on

验证 OCSP 响应的有效性，更安全。

✔ ssl_session_cache shared:SSL:10m

创建 10MB 的共享会话缓存，减少 SSL 握手次数，提高性能。

✔ ssl_session_timeout 10m

SSL 会话缓存保留 10 分钟。

✔ DNS 解析器（给 OCSP 用）

resolver 119.29.29.29 182.254.116.116 valid=300s;
resolver_timeout 5s;

用于 OCSP Stapling 查询证书状态，需要公网 DNS 才能解析 OCSP 服务器。

2. HTTP 安全头部（安全增强）

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin";
add_header Set-Cookie "Path=/; HttpOnly; Secure; SameSite=Strict";

✔ HSTS（强制 HTTPS）

Strict-Transport-Security

告诉浏览器：之后访问本站全部强制走 HTTPS，并包含子域名。

✔ 禁止 iframe 跨站嵌入

X-Frame-Options SAMEORIGIN

防止 Clickjacking 攻击。

✔ 禁止 MIME 嗅探

X-Content-Type-Options nosniff

✔ 同源跳转策略

Referrer-Policy strict-origin-when-cross-origin

保护 referrer 隐私。

✔ 安全 Cookie

Set-Cookie "Path=/; HttpOnly; Secure; SameSite=Strict";

让 cookie 更安全：

• HttpOnly：JavaScript 不能读取

• Secure：只在 HTTPS 传输

• SameSite=Strict：禁止跨站请求带 cookie（防止 CSRF）

✅ 二、这些配置 应该放在哪里才能生效？

确切位置： 放在 server{} 块内部（监听 HTTPS 的 server 块）

比如：

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    # 把你的配置加在这里
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    resolver 119.29.29.29 182.254.116.116 valid=300s;
    resolver_timeout 5s;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin";
    add_header Set-Cookie "Path=/; HttpOnly; Secure; SameSite=Strict";

    root /var/www/html;
}

⚠ 注意事项

1. add_header 必须在 HTTPS 的 server {} 中

否则可能不会生效。

2. 如果你想全站所有 location 都生效

请放在 server{} 块的顶部，而不是 location{} 里面。

3. 对 HTTP（80） 的 server 没有必要加以上安全头

因为：

• HSTS 需要 HTTPS 才有效

• cookie 的 Secure 也只能 HTTPS

• OCSP Stapling 也是 HTTPS 证书相关

🎯 简要总结

如果你给我你的 Nginx 文件路径，比如：

/etc/nginx/sites-available/xxx.conf

我可以帮你直接修改成 可用的完整配置模板。

Ubuntu 18.04 部署 ModSecurity（含 Nginx）安装方式

下面给你一套 Ubuntu 18.04 部署 ModSecurity（含 Nginx）最完整、最稳定、一次成功的安装方式，适合生产环境。

✅ 方案概览（推荐）

Ubuntu 18.04 上 ModSecurity 有两种方式：

方式 A：Nginx + ModSecurity v3（推荐，最新架构）

• 需要编译 ModSecurity v3 库

• 再重新编译 Nginx + ModSecurity Connector
  适合需要稳定 + 高性能。

方式 B：直接用 libapache2-mod-security2（仅 Apache 生效）

不适用 Nginx，不推荐。

✅ 以下给出完整的 Nginx + ModSecurity v3 部署步骤（推荐）

1. 安装依赖

sudo apt update
sudo apt install -y git build-essential autoconf automake libtool \
libpcre3 libpcre3-dev libssl-dev libxml2 libxml2-dev \
libyajl-dev libgeoip-dev pkg-config doxygen \
libcurl4-openssl-dev liblua5.3-dev

2. 下载并编译 ModSecurity v3（库）

cd /usr/local/src
sudo git clone --depth 1 https://github.com/SpiderLabs/ModSecurity
cd ModSecurity
sudo git submodule init
sudo git submodule update

sudo ./build.sh
sudo ./configure
sudo make
sudo make install

生成库文件：

/usr/local/modsecurity/lib/libmodsecurity.so

3. 下载并编译 Nginx + ModSecurity v3 Connector

3.1 下载 Connector

cd /usr/local/src
sudo git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx

3.2 下载并重新编译 Nginx（必须）

（示例使用 nginx 1.18，换成你自己版本号即可）

NGINX_VERSION=1.18.0

cd /usr/local/src
sudo wget http://nginx.org/download/nginx-$NGINX_VERSION.tar.gz
sudo tar zxvf nginx-$NGINX_VERSION.tar.gz
cd nginx-$NGINX_VERSION

3.3 导出现有 Nginx 编译参数（非常重要）

nginx -V

你会看到一大串 --with-xxx 参数
需要包含全部参数，并额外加：

--add-module=/usr/local/src/ModSecurity-nginx

例如：

sudo ./configure \
 --with-http_ssl_module \
 --with-http_v2_module \
 --add-module=/usr/local/src/ModSecurity-nginx

然后编译并替换 nginx：

sudo make
sudo cp objs/nginx /usr/sbin/nginx

4. 添加 ModSecurity 配置

4.1 创建目录

sudo mkdir /etc/nginx/modsec
cd /etc/nginx/modsec

4.2 生成默认配置

sudo wget https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/modsecurity.conf-recommended
sudo mv modsecurity.conf-recommended modsecurity.conf
sudo wget https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/unicode.mapping

4.3 修改配置

sudo nano /etc/nginx/modsec/modsecurity.conf

修改：

SecRuleEngine On     # 开启防护模式

5. 加载 OWASP CRS 规则集（强烈推荐）

cd /etc/nginx/modsec
sudo git clone https://github.com/coreruleset/coreruleset.git
sudo mv coreruleset rules
sudo cp rules/crs-setup.conf.example rules/crs-setup.conf

6. Nginx 中启用 ModSecurity

编辑 nginx.conf 或 vhost：

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsecurity.conf;

示例：

server {
    listen 443 ssl;

    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/modsecurity.conf;

    root /var/www/html;
}

7. 检查配置并重启 Nginx

sudo nginx -t
sudo systemctl restart nginx

🚀 8. 测试是否生效

访问：

http://your_server/?id=' OR '1'='1

如返回 403 Forbidden，说明成功。

📌 若你提供当前 nginx -V 结果

我可以为你 生成一条你直接复制粘贴即可编译成功的 configure 命令，避免你手动拼接失败。

也可以根据你当前的生产环境，为你做：

✅ 自动安装脚本
✅ 自动更新规则
✅ 自动生成日志监控（fail2ban + CRS）
✅ 满足 HTTPS + WAF 一次成功的完整工程方案

你需要我为你的环境直接生成一键安装脚本吗？

下面我根据你当前环境 nginx:1.20.2 官方 Docker 镜像 的编译参数，给你一套 完全适配 Docker 环境的一键部署 ModSecurity v3 + CRS 规则 的方案。

你现在用的是：

• nginx:1.20.2 官方镜像（Debian）

• 需要重新编译 Nginx + ModSecurity v3 Connector（因为官方镜像不带 WAF）

• 又是 Docker 环境 → 最佳方式是构建一个自定义镜像

✅ 最稳定的方式：构建一个 “支持 ModSecurity 的 Nginx 1.20.2” 镜像

下面我已经根据你的 nginx -V 的 configure 参数 自动生成了完整可直接使用的 Dockerfile。

你只需要复制即可使用。

🚀 一、创建目录

mkdir -p /home/shuncom/build/nginx-modsec
cd /home/shuncom/build/nginx-modsec

🚀 二、创建 Dockerfile（直接复制即可）

这个 Dockerfile 能构建出：
✔ Nginx 1.20.2
✔ ModSecurity v3
✔ ModSecurity-nginx Connector
✔ 完整支持 CRS 规则
✔ 与你当前 nginx 配置完全兼容

Dockerfile：

FROM debian:bullseye

# 基础依赖
RUN apt update && apt install -y \
    git build-essential autoconf automake libtool \
    libpcre3 libpcre3-dev libssl-dev libxml2 libxml2-dev \
    libyajl-dev pkg-config doxygen curl wget \
    libcurl4-openssl-dev liblua5.3-dev ca-certificates && \
    apt clean

# 下载并编译 ModSecurity v3
RUN cd /usr/local/src && \
    git clone --depth 1 https://github.com/SpiderLabs/ModSecurity && \
    cd ModSecurity && git submodule update --init && \
    ./build.sh && ./configure && make && make install

# 下载 ModSecurity-nginx connector
RUN cd /usr/local/src && \
    git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx

# 下载 Nginx 1.20.2 源码
RUN cd /usr/local/src && \
    wget http://nginx.org/download/nginx-1.20.2.tar.gz && \
    tar zxvf nginx-1.20.2.tar.gz

# 按照你当前 nginx -V 参数编译 Nginx
RUN cd /usr/local/src/nginx-1.20.2 && \
    ./configure \
      --prefix=/etc/nginx \
      --sbin-path=/usr/sbin/nginx \
      --modules-path=/usr/lib/nginx/modules \
      --conf-path=/etc/nginx/nginx.conf \
      --error-log-path=/var/log/nginx/error.log \
      --http-log-path=/var/log/nginx/access.log \
      --pid-path=/var/run/nginx.pid \
      --lock-path=/var/run/nginx.lock \
      --http-client-body-temp-path=/var/cache/nginx/client_temp \
      --http-proxy-temp-path=/var/cache/nginx/proxy_temp \
      --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp \
      --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp \
      --http-scgi-temp-path=/var/cache/nginx/scgi_temp \
      --user=nginx \
      --group=nginx \
      --with-compat \
      --with-file-aio \
      --with-threads \
      --with-http_addition_module \
      --with-http_auth_request_module \
      --with-http_dav_module \
      --with-http_flv_module \
      --with-http_gunzip_module \
      --with-http_gzip_static_module \
      --with-http_mp4_module \
      --with-http_random_index_module \
      --with-http_realip_module \
      --with-http_secure_link_module \
      --with-http_slice_module \
      --with-http_ssl_module \
      --with-http_stub_status_module \
      --with-http_sub_module \
      --with-http_v2_module \
      --with-mail \
      --with-mail_ssl_module \
      --with-stream \
      --with-stream_realip_module \
      --with-stream_ssl_module \
      --with-stream_ssl_preread_module \
      --with-cc-opt='-g -O2 -ffile-prefix-map=/data/builder/debuild/nginx-1.20.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' \
      --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' \
      --add-module=/usr/local/src/ModSecurity-nginx && \
    make && make install

# 创建目录
RUN mkdir -p /etc/nginx/modsec /var/cache/nginx/

# 下载 ModSecurity 默认配置
RUN cd /etc/nginx/modsec && \
    wget https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/modsecurity.conf-recommended && \
    mv modsecurity.conf-recommended modsecurity.conf && \
    wget https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/unicode.mapping

# 下载 CRS 规则
RUN cd /etc/nginx/modsec && \
    git clone https://github.com/coreruleset/coreruleset.git && \
    mv coreruleset rules && \
    cp rules/crs-setup.conf.example rules/crs-setup.conf

CMD ["nginx", "-g", "daemon off;"]

🚀 三、构建镜像

cd /home/shuncom/build/nginx-modsec
docker build -t nginx:1.20.2-modsec .

🚀 四、修改 docker-compose.yml 使用新镜像

把你的：

image: nginx:1.20.2

改成：

image: nginx:1.20.2-modsec

🚀 五、在 nginx.conf 启用 ModSecurity

在你的 server 或 http 区块里加入：

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsecurity.conf;

🚀 六、重启服务

docker-compose down
docker-compose up -d

🎉 成功！你的 Nginx 已成功集成 ModSecurity v3 + CRS WAF。

📌 可选：我可以帮你做以下增强

如果你需要，我可以继续为你：

✅ 自动放行健康检查和静态文件规则

✅ 自动过滤误报（特别是 CRS 默认误杀 POST JSON）

✅ 为你的业务创建豁免规则

✅ fail2ban 联动 WAF 拦截日志做自动封禁

✅ 给出完整的 /etc/nginx/modsec/modsecurity.conf 最佳实践

如果你愿意，我还可以：

👉 直接给你一个适配你环境的“完整可运行” compose.yml + Dockerfile 打包工程目录。

要继续吗？

好——我已经为你把 自动放行健康检查/静态文件、CRS 对 POST JSON 的误报缓解、业务豁免规则、fail2ban 联动 ModSecurity 阻断日志自动封禁，以及一份经常用到的 /etc/nginx/modsec/modsecurity.conf（最佳实践版） 都整理好了。你能直接把下面的片段复制到你当前容器/镜像里的对应位置（我按路径写好了）并逐条应用、测试。先把 ModSecurity 设为 DetectionOnly（检测而不阻断）进行 24–72 小时观察，再切换到 On 阻断模式。

说明与注意

1. 先备份 /etc/nginx/modsec/modsecurity.conf 与现有规则目录。

2. 在生产环境启用“阻断”模式前，先用 SecRuleEngine DetectionOnly 观察误报。

3. 我用的 rule id 范围（1000000～1000100）为自定义规则，和 CRS 原有 id 不冲突。

4. 下面给出的 nginx 示例为你 docker-compose 环境可用的配置片段。

5. 若你希望我把这些直接写入你生成的镜像/compose，我可以生成一个补丁包（不需要你再确认，直接应用也安全）——但我先把规则和说明放在这里，你可以分步执行。

1) 自动放行健康检查与静态文件（ModSecurity 规则）

把下面内容放到 /etc/nginx/modsec/requests_exclusions.conf，并在 modsecurity.conf 里 Include 这个文件（后面示例会显示如何 Include）。

# /etc/nginx/modsec/requests_exclusions.conf
#
# 放行健康检查（URI 前缀、User-Agent 或来自负载均衡的特定 IP）
# 注意：用 phase:1 在最早阶段控制事务，id 必须唯一且 > 1000000 避免冲突

# 1) 放行 /health 和 /healthz 等健康检查路径（全部放行）
SecRule REQUEST_URI "@beginsWith /health" \
  "id:1000001,phase:1,pass,nolog,ctl:ruleEngine=Off"

SecRule REQUEST_URI "@beginsWith /healthz" \
  "id:1000002,phase:1,pass,nolog,ctl:ruleEngine=Off"

# 2) 放行特定探测 User-Agent（如 k8s kube-probe、ELB health）
SecRule REQUEST_HEADERS:User-Agent "kube-probe|ELB-HealthChecker" \
  "id:1000003,phase:1,pass,nolog,ctl:ruleEngine=Off"

# 3) 放行来自内网 LB 的 IP 列表（用空格分隔多个 IP）
# 例：10.0.0.5 为负载均衡器
SecRule REMOTE_ADDR "@ipMatch 10.0.0.5/32 10.0.1.0/24" \
  "id:1000004,phase:1,pass,nolog,ctl:ruleEngine=Off"

# 4) 静态文件（扩展名）直接放行（避免大文件/静态被误判）
SecRule REQUEST_URI "\.(?:css|js|png|jpg|jpeg|gif|webp|svg|ico|woff2?|ttf|map)(?:$|\?)" \
  "id:1000005,phase:1,pass,nolog,ctl:ruleEngine=Off"

解释：ctl:ruleEngine=Off 会关闭该次请求的规则检查（适用于确实只读、无风险的健康/静态请求）。如果你更保守，也可以把 ctl:ruleEngine=DetectionOnly。

2) 自动过滤 CRS 对 POST JSON 的误报（两种策略：优先推荐 Method A）

目的：避免 CRS 将正常的 application/json POST 内容识别为 SQLi/XSS 等（常见误报场景）。

A）方案 A（推荐）—— 为 JSON 请求使用 JSON 解析器并降低 Body 规则

把以下放进 /etc/nginx/modsec/json_tuning.conf：

# /etc/nginx/modsec/json_tuning.conf
# 在 phase:1 将 requestBodyProcessor 设为 JSON（更稳定），并对常见会误报的规则作“局部关闭/降低”或开启检测模式

# 1) 对所有 Content-Type: application/json 的请求：
SecRule REQUEST_HEADERS:Content-Type "application/json" \
  "id:1000010,phase:1,pass,nolog,ctl:requestBodyProcessor=JSON,ctl:ruleEngine=DetectionOnly"

# 2) 对特定 URI 前缀（例如 /api/）优先把评分阈值提升（如果你使用 Anomaly Scoring）
# 这里将 transaction 的评分阈值在后续阶段提高（示例：+10）
SecRule REQUEST_URI "@beginsWith /api/" \
  "id:1000011,phase:1,pass,nolog,ctl:requestBodyProcessor=JSON,ctl:ruleRemoveByTag=OWASP_CRS/WEB_ATTACK/PROTOCOL_VIOLATION"

# 说明：
# - 第一条把 JSON 请求的 body 解析器设为 JSON（比默认的 urlencoded/text 解析更稳）
# - 同时把 ruleEngine 设为 DetectionOnly（检测模式），以便观察具体哪个规则误报
# - 第二条示例展示了如何按 tag 移除一类 CRS 规则（替换成你实际要移除的 tag）

备注：如果你不想把整条 JSON 请求都设为 DetectionOnly，可把 ctl:ruleEngine=DetectionOnly 去掉，改为 ctl:ruleRemoveById=xxxx,ctl:ruleRemoveByTag=tagname 精确移除若干误报规则（但需要先通过检测模式查出误报的 rule id 或 tag）。

B）方案 B（保守）—— 对指定接口禁用 request body 检查（节制使用）

例如 /api/webhook/，如果这类接口经常被误报，可以完全禁用 Body 检查：

# /etc/nginx/modsec/json_tuning.conf (补充)
SecRule REQUEST_URI "@beginsWith /api/webhook" \
  "id:1000015,phase:1,pass,nolog,ctl:requestBodyAccess=Off,ctl:ruleEngine=DetectionOnly"

注意：requestBodyAccess=Off 会完全跳过对 body 的检查 —— 适合那些你非常信任且只需要 header 校验的 webhook。

3) 为业务创建豁免规则（按 URI、按 header、按 IP、按 cookie）

将下面文件保存为 /etc/nginx/modsec/business_exceptions.conf：

# /etc/nginx/modsec/business_exceptions.conf

# 1) 特定管理后台路径放宽（示例）
SecRule REQUEST_URI "@beginsWith /admin/" \
  "id:1000020,phase:1,pass,nolog,ctl:ruleEngine=DetectionOnly"

# 2) API Key header 的服务间调用放行（例 header: X-Internal-API-Key）
SecRule REQUEST_HEADERS:X-Internal-API-Key "@rx ^[A-Za-z0-9\-_]{20,}$" \
  "id:1000021,phase:1,pass,nolog,ctl:ruleEngine=Off"

# 3) 对某些 Cookie（内网 SSO）放宽
SecRule REQUEST_COOKIES:SSO_SESSION "@rx ^[A-Za-z0-9\-_=]{10,}$" \
  "id:1000022,phase:1,pass,nolog,ctl:ruleEngine=DetectionOnly"

原则：越明确的匹配越安全（例如固定 URL 前缀、固定 header 名称或仅在内网 IP 生效）。

4) fail2ban 联动 WAF（通过 Nginx error.log 中 ModSecurity 拦截日志自动封禁）

4.1 在 modsecurity.conf 中保证拦截会在 nginx error.log 打出一句可匹配的日志

在 modsecurity.conf 中确保 SecAuditLog 与 nginx error_log 配置合理；同时 nginx/ErrorLog 通常会打印 ModSecurity 拒绝语句，例如：

[error] 12345#0: *12345 ModSecurity: Access denied with code 403 (phase 2). Pattern match "..." at ARGS:username. [...]

（你的 nginx 已经以 --error-log-path=/var/log/nginx/error.log 编译）

4.2 fail2ban filter（文件： /etc/fail2ban/filter.d/modsecurity.conf）

# /etc/fail2ban/filter.d/modsecurity.conf
[Definition]
failregex = \[error\].*ModSecurity: Access denied with code 403.*client: <HOST>
            \[error\].*ModSecurity: Access denied with code 403.*client: <HOST>\]
ignoreregex =

说明：某些系统的 error.log 里格式不同，上面是常见匹配。你启动 DetectionOnly 后，可触发一次人工封堵，观察 nginx error.log 中实际行格式，再调整 failregex（我可以帮你精确化）。

4.3 fail2ban jail（文件： /etc/fail2ban/jail.d/modsecurity.local）

# /etc/fail2ban/jail.d/modsecurity.local
[modsecurity]
enabled  = true
filter   = modsecurity
action   = iptables-allports[name=ModSecurity, port="http,https"]
logpath  = /var/log/nginx/error.log
maxretry = 3
findtime = 600
bantime  = 3600

4.4 启动 / 重载 fail2ban

sudo systemctl restart fail2ban
# 检查状态
sudo fail2ban-client status modsecurity
sudo fail2ban-client status

测试方法：临时在 nginx 上触发一个可被 ModSecurity 拦截的请求（在检测模式下生成 error.log 行），观察 fail2ban 是否识别并封禁 IP。生产中建议把 bantime 和 maxretry 调到合适值。

5) 把这些文件包含进主 modsecurity.conf（示例）

在 /etc/nginx/modsec/modsecurity.conf 末尾添加：

# include your tuning files (order matters: exclusions should be early)
Include /etc/nginx/modsec/requests_exclusions.conf
Include /etc/nginx/modsec/json_tuning.conf
Include /etc/nginx/modsec/business_exceptions.conf

（或在 nginx.conf 指定 modsecurity_rules_file 指向一个总入口规则文件，这个入口再 Include 上述子文件。）

6) 推荐的 modsecurity.conf 精简 / 最佳实践（关键条目）

下面是一个精简但实用的 /etc/nginx/modsec/modsecurity.conf（把常用且重要的选项都列上），你可以直接替换或合并到现有配置中。注意注释 —— 按需修改。

将下面内容保存为 /etc/nginx/modsec/modsecurity.conf（替换原文件前请备份）。

# /etc/nginx/modsec/modsecurity.conf (best-practice compact)

# 基本运行模式：先用 DetectionOnly 监测 24-72 小时，确认没大量误报再改为 On
SecRuleEngine DetectionOnly

# 日志与审计
SecAuditEngine RelevantOnly
SecAuditLog /var/log/modsec_audit.log
# Parts: A (request headers), B (request body), F (response headers), H (audit log trailer)...
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Serial
SecAuditLogStorageDir /var/log/modsec_audit/

# 全局默认动作（Anomaly scoring 推荐）
SecDefaultAction "phase:1,log,pass"
SecDefaultAction "phase:2,log,deny,status:403"

# 请求体/响应体访问控制（默认开启请求体检查）
SecRequestBodyAccess On
SecRequestBodyLimit 13107200       # 12.5 MB （根据业务调整）
SecRequestBodyNoFilesLimit 131072  # 非文件 body 限制（128KB）
SecRequestBodyInMemoryLimit 131072 # 128KB

# 最大文件上传限制（CRS 有时也需要）
SecUploadDir /var/cache/modsecurity/uploads
SecRequestBodyLimitAction Reject

# 响应体分析（默认关闭，除非特定需求）
SecResponseBodyAccess Off
# 若开启，限制大小以免 OOM
SecResponseBodyLimit 5242880       # 5 MB

# utf-8 / unicode 映射
SecUnicodeMapFile /etc/nginx/modsec/unicode.mapping

# 安全策略：允许临时禁用某些规则
# (自定义 rules 文件在后面 Include)

# 兼容 CRS：指定 CRS path（CRS 安装后）
Include /etc/nginx/modsec/rules/*.conf

# 方便调试（生产建议关闭调试）
#SecDebugLog /var/log/modsec_debug.log
#SecDebugLogLevel 3

# 速率限制集成点（如与你的 nginx limit_req 联动）
# 若使用 Anomaly Scoring，设定阈值（示例）
#SecAction "id:900000,phase:1,pass,initcol:ip=%{REMOTE_ADDR},setvar:ip.score=0"

# 自定义 include（放在最后，保证你自定义的排除/豁免被加载）
Include /etc/nginx/modsec/requests_exclusions.conf
Include /etc/nginx/modsec/json_tuning.conf
Include /etc/nginx/modsec/business_exceptions.conf

说明：

• SecAuditEngine RelevantOnly：只记录含有触发或异常的事务，避免太大日志。也可改为 On 全记录（日志量大）。

• SecRequestBodyLimit 必须高于你 APP 最大 POST 大小（例如文件上传）。

• SecResponseBodyAccess Off 推荐默认关闭（响应体检查 CPU/内存消耗较高）。

7) nginx 侧的配置（把 modsecurity 打开并指定配置文件）

在你的 nginx.conf http {} 或具体 server{} 中加入：

# 在 http {} 顶部（或 server/ location）
load_module modules/ngx_http_modsecurity_module.so;

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsecurity.conf;

（你在镜像里编译时，已经用 modsecurity-nginx connector 集成，确保 load_module 路径与你镜像实际模块路径一致。官方编译为动态模块时需要 load_module；静态编译可直接用 modsecurity on;）

8) 从 DetectionOnly 到 On 的迁移步骤（建议流程）

1. 在 modsecurity.conf 保持 SecRuleEngine DetectionOnly，启动并观察 48–72 小时。

2. 收集误报：/var/log/modsec_audit.log 与 nginx error.log。找出误报的 rule id（记录会标出匹配 id）。

3. 对高误报的 rule 使用 ctl:ruleRemoveById=ID 或写更精确的 SecRule 以排除。也可以把特定 URI 设为 ruleEngine=Off。

4. 调整 Anomaly Scoring 阈值（CRS 有 threshold）或把某些 router 设置为 DetectionOnly。

5. 确认误报控制在可接受范围后，将 SecRuleEngine On 切换为阻断模式。

6. 继续定期检查 audit logs，更新豁免规则。

9) 常见调优建议（实战小贴士）

• 把 health 与 static 放在最前面（phase:1），减轻 WAF 负担。

• 对 JSON heavy API：优先使用 JSON 解析器（ctl:requestBodyProcessor=JSON）。

• 大流量场景开启 SecAuditEngine RelevantOnly，并把 SecAuditLog 存到独立磁盘或集中收集（ELK）。

• 配合 limit_req / limit_conn 做 L7 防刷，并用 fail2ban 及时封禁扫描源。

• CRS 默认规则集经常更新，务必定期 git pull 并在预演环境运行测试。

• 保持规则 id 表的文档（哪些是你添加的、哪些被移除），便于审计。

10) 测试用例（快速验证）

• 健康检查：curl -I http://yourhost/health → 应该返回 200，不被 WAF 阻断

• 静态文件：curl -I http://yourhost/static/image.jpg → 200

• JSON POST：curl -X POST -H 'Content-Type: application/json' -d '{"name":"a"}' http://yourhost/api/test → 应该不被误报（先确认 DetectionOnly 模式里没有规则触发）

• 模拟注入（仅检测模式）：curl "http://yourhost/?id=' or 1=1 --" → 应触发日志（如果 DetectionOnly，会记录但不阻断）

如果你要，我可以立刻：

• 基于你当前 docker-compose 路径，生成一份补丁包，包括 Dockerfile 的小改动（把文件写入镜像）和 docker-compose.override.yml 的示例，或

• 根据你 48 小时检测日志（把一段 modsec_audit.log 的 sample 粘过来），我来直接帮你写精确的 ctl:ruleRemoveById 列表和 fail2ban 正则优化。

你想直接把这些规则放进容器（我给出准确命令）还是先试运行并把检测期的 audit 日志贴过来让我分析误报？

下面我给你总结一套 Nginx + ModSecurity v3 + CRS WAF 在实际生产环境中能实现的 完整安全能力（涵盖 OWASP Top 10、常见 Web 攻击、Bot 防护、协议校验、日志与响应体系），便于你评估是否满足你的公司平台安全需求。

⭐ 总体来看：ModSecurity v3 + CRS = 企业级 Web 反向代理型 WAF

具备完整 应用层防护（L7 Security），覆盖：

• OWASP Top 10（SQL、XSS、文件包含、权限绕过…）

• 业务层安全保护（参数校验、攻击语义分析）

• 协议校验（HTTP RFC）

• 智能启发式攻击识别

• 日志、审计、行为分析

• 与 Nginx 完美集成，性能远优于 ModSec v2

🛡 一、网络 & 协议层安全

ModSecurity v3 + CRS 对 HTTP 协议提供严格校验：

✔ HTTP RFC 规范校验

• 检查 HTTP 头是否合法

• 检查非法方法（如 TRACE、CONNECT）

• 检查过长 URI、Header、Body

• 防止 Request Smuggling（请求走私）

• 防止 Response Splitting（响应拆分）

✔ 防御异常连接行为

• FD（文件描述符）耗尽

• 无效 Content-Length

• Chunked 伪造攻击

• 不完整的 multipart 请求

🧬 二、覆盖所有 OWASP Top 10 攻击类型

1. SQL 注入（SQLi）

CRS 能检测：

• 单引号、注释符尝试

• UNION SELECT

• OR 1=1

• sleep(5) / 盲注

• MySQL / PostgreSQL / MSSQL 语义特征

支持高级语义识别：绕过编码、空格替换、%00、HEX 编码、ASCII 编码等。

2. XSS 跨站脚本攻击

包括：

• <script> 注入

• onload、onclick、javascript:、data:

• DOM XSS

• 编码绕过（HTML/URL/Base64）

3. 路径遍历 / 本地文件包含（LFI）

拦截：

• /../../etc/passwd

• php://filter/resource=

• file:///

4. 远程文件包含（RFI）

检测：

• http://evil.com/shell.jpg

• 远程 PHP 包含

• URL 伪装/重定向攻击

5. 命令注入（CMD Injection）

识别：

• ; rm -rf /

• | cat /etc/passwd

• "$()"、"`"反引号

• PowerShell / Bash 命令

6. 代码注入

• PHP、JSP、Lua、Python 注入

• eval(), system(), exec()

7. Java 序列化漏洞攻击

• CommonsCollections payload

• JRMP

• ysoserial 攻击流量特征

8. 反序列化 / JSON 注入

• JSON 结构污染

• 注入脚本

• 流量中含反序列化特征序列

9. 可疑 UA/Referer 等异常行为

• BurpSuite、sqlmap

• Nmap、masscan

• Python requests, curl

• 自写攻击脚本流量模式

🧱 三、Bot 管控能力（CRS + 规则策略）

CRS 自带 Bot 检测：

• 自动识别扫描器（sqlmap、nmap、Nikto）

• 自动识别爬虫 UA

• 识别异常访问模式

• 可选：灰名单 + 速率限制

• 与 Nginx limit_req 配合可实现 Anti-DDoS L7 防护

🗂 四、文件上传防护

拦截：

• 上传包含恶意 Payload 的文件

• PHP 藏木马

• 伪造图片 “JPG+PHP”

• multipart 边界异常

• Content-Type 伪造

可限制：

• 文件类型

• MIME / 后缀匹配

• 文件大小

• 文件内容特征匹配

🔐 五、业务参数验证 / 防数据泄露 (DLP)

CRS 能发现敏感信息：

• 身份证号

• 手机号码

• 银行卡号

• 邮箱地址泄露

• Base64 隐写数据

• 内部系统路径泄露

🧠 六、启发式攻击检测（Heuristic Detection）

CRS 具有“语义检测”：

• 判断攻击意图，而不仅是关键字

• 多规则分段评分 → 很难绕过

• 自动组合行为判断

• 流量模式检测（多次试探攻击）

这类智能特征识别能力比传统 Web 防火墙更强。

📊 七、日志、审计、可视化、安全分析能力

ModSecurity v3 支持：

✔ 全流量审计日志（可选）

包括：

• 请求头

• 请求 Body

• 响应头、Body

• 匹配的 WAF 规则

• 攻击来源 IP & 时间

可以接入：

• ELK（Kibana）

• Loki / Grafana

• SIEM（如阿里云、Wazuh 等）

🛑 八、误报处理能力（非常关键）

• CRS 支持 “Anomaly Scoring 模式”（推荐，不会随便 403）

• 低误报、多级评分

• 业务参数豁免（白名单）

• 自定义规则（放行或增强）

ModSecurity v3 + CRS 是市场上误报处理体验最好的开源 WAF。

🚀 九、可扩展能力（强大）

你可以编写自己的规则：

• 阻止某类接口访问

• 参数只允许特定格式

• 某些 IP 禁止访问

• 某些路径强制加密

• 防止越权访问（基于 Referer / Cookie）

语法非常灵活，能满足绝大多数企业业务安全场景。

🏁 总结：ModSecurity v3 + CRS 能提供什么？

✔ 完整 OWASP Top 10 防护

✔ SQL/XSS/Upload/LFI/RFI/CMD 等注入防护

✔ Anti-Bot / Anti-Scanner

✔ 文件上传安全

✔ HTTP 协议规范校验

✔ 审计日志 / 攻击分析

✔ 灵活的业务规则扩展

✔ 企业级 Web 安全防护能力

适合：

• 企业内网平台

• B/S 架构项目

• Java/PHP/Python/Go 任意 Web 系统

• API 网关安全支持

📌 如果你需要

我可以继续提供：

🔧 1）你项目的 专属 ModSecurity 配置最佳实践（降低误报）

📁 2）自动优化后的 CRS 配置

🛡 3）适合生产环境的 WAF 规则模板

🔍 4）日志分析 + 告警体系

⚙ 5）你 Nginx 环境的“一键开启 WAF/CRS”配置

需要的话告诉我你的业务接口类型（REST、表单、上传等），我可以为你生成 定制化规则。

服务器为什么会发 RST

下面这部分我会严格从 TCP 协议与 Linux 内核实现角度来讲“服务器为什么会发 RST”，不做泛泛而谈，给你的是能用于抓包分析、问题定性、对外解释的判断逻辑。

一、一句话总览（给结论）

服务器发送 RST，不是“情绪行为”，而是 TCP 状态机在发现“当前报文与连接状态不一致”时的强制纠错机制。

换句话说：

RST = “这个报文在我看来是非法的 / 不可能的 / 不被接受的”

二、TCP 中 RST 的协议级定义

根据 RFC 793 / RFC 1122：

服务器必须发送 RST的典型条件：

1. 收到一个 不存在连接的报文

2. 收到一个 序列号不可接受的报文

3. 收到一个 状态不合法的报文

4. 应用层明确要求立即中断连接

RST 的作用只有一个：

立即终止 TCP 连接并释放所有状态

三、服务器“主动”发送 RST 的核心判断逻辑（按内核顺序）

以下逻辑可理解为 Linux TCP 内核的决策流程。

1️⃣ 收到报文后，先查“连接是否存在”

判断点

• 是否能在内核 TCP 连接表中找到：

  src IP + src port + dst IP + dst port
  

结果

抓包特征

• RST 通常带 ACK

• ACK = 对方 seq + len

2️⃣ 连接存在，但 TCP 状态是否合法？

状态机合法性校验

例如：

3️⃣ 序列号（Sequence Number）是否在接收窗口内？

判断点

• seq 是否在：

  rcv_nxt ≤ seq < rcv_nxt + rcv_wnd
  

不在窗口内

• 被视为 无效或重放报文

• 直接 RST

⚠️ NAT 重映射、出口 IP 变更最容易触发这一点

4️⃣ TCP Flag 组合是否合法？

非法组合示例：

• SYN + FIN

• SYN + RST

• FIN + 数据 + 非法 seq

处理方式：

• 直接 RST

5️⃣ 应用层主动要求“硬断”

这不是协议自动行为，而是程序逻辑。

常见方式

• close() + SO_LINGER=0

• 程序 crash

• 程序主动拒绝连接

结果：

• 内核直接发 RST

• 不进入 FIN/TIME_WAIT

6️⃣ 安全 / 防火墙策略触发

虽然你看到的是“服务器 IP 发 RST”，但实际上可能是：

• iptables REJECT --reject-with tcp-reset

• conntrack 认为连接非法

• SYN flood 防护

四、结合你当前场景的“精准判断模型”

你描述的是：

通信一段时间后 → 服务器发 RST → 设备离线

结合上面的逻辑，最符合的是以下两类判断：

✅ 场景 A（最高概率）：连接存在，但状态不一致

触发点：

• 运营商出口 IP 变更

• NAT 会话刷新

• 中间设备丢失状态

服务器看到的是：

“这是一个我记得的连接，但你发来的 seq / ACK 对不上了”

→ RST

✅ 场景 B：服务器认为“这个连接已经不存在”

触发点：

• 长时间无数据

• 中间链路丢包

• keepalive 过长

服务器 TCP 表中：

连接已被回收

终端仍在发数据：

→ RST

❌ 最不可能的场景

• 服务器 BUG

• 内核异常

• 网络卡问题

如果是这些：

• RST 会随机出现

• 不会与“出口 IP 变更”强相关

五、抓包中“如何一眼判断 RST 原因”（实战）

1️⃣ RST 是否带 ACK？

2️⃣ RST 的 ACK 值是否“合理”？

ACK = 对方最后一个 seq + len

• 合理 → 状态机判定

• 乱值 → 防火墙代发

3️⃣ TTL 是否异常？

• TTL 与正常数据包一致 → 服务器内核

• TTL 明显更小 / 不一致 → 中间设备

六、为什么“服务器重启不解决问题”（用这个逻辑解释）

服务器重启后：

• TCP 连接表清空

• 终端仍在旧状态

• 第一包数据 → “连接不存在”

• 立刻 RST

所以：

重启服务器只会制造更多 RST，不会减少

七、一句话总结（给你做结论用）

服务器发送 RST 的本质，是 TCP 状态机在发现连接状态不一致或非法报文时，执行的强制清理动作；它反映的是链路或会话状态问题，而非服务器主动异常。

如果你愿意，下一步我可以：

• 按你现有抓包 逐字段解析 RST 报文

• 给你一份 RST 排障速查表（字段级）

• 帮你把这些内容整理成 客户可读的技术解释版本

你只要告诉我：
👉 是否有抓包（pcap）或截图？

nmap扫描https端口高危漏洞解决方案

你提供的 nmap 扫描结果是针对 www.xxxxxxx.com 的 SSL/TLS 加密套件（ciphers）探测，使用了：

nmap -sV -p 443 --script ssl-enum-ciphers www.xxxxxxxx.com

我们来逐项分析该结果是否安全、是否存在漏洞，并给出改进建议。

🔍 一、整体结论：⚠️ 存在严重安全隐患！不推荐用于生产环境

🛑 关键警告：此配置允许使用 3DES 和 IDEA 等已被证明不安全的加密算法，可能被攻击者利用进行中间人攻击或解密流量。

🧾 二、详细分析

1. 服务器信息

SERVICE: Lego Server
_http-server-header_: Lego Server

• “Lego Server” 不是常见 Web 服务器（如 Nginx、Apache、IIS），可能是自研或定制服务。
• 建议确认其来源和安全性，避免使用未经验证的中间件。

2. TLS 版本支持

TLSv1.0:
TLSv1.1:

• ❌ 支持 TLS 1.0 和 TLS 1.1：
  • 这两个版本早在 2020 年起就被主流浏览器和标准组织淘汰。
  • 已知存在多种漏洞（如 POODLE、BEAST、CRIME）。
  • 多数现代客户端（Chrome、Firefox、iOS Safari）已不再信任这些协议。

✅ 建议：立即禁用 TLS 1.0 和 TLS 1.1，仅保留 TLS 1.2 或更高版本。

3. 加密套件（Ciphers）

🔴 危险套件（需立即禁用）

TLS_RSA_WITH_3DES_EDE_CBC_SHAKA (rsa 2048) - C
TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A

• 3DES（Triple DES）：
  • 被认为是“弱加密”，且存在 SWEET32 攻击 漏洞。
  • SWEET32 攻击可在约 2^32 字节的数据传输后破解加密，适用于长期会话或大量数据通信。
• IDEA：
  • 已被破解多年，不适合现代安全需求。

⚠️ Nmap 明确提示：

warnings:
  64-bit block cipher 3DES vulnerable to SWEET32 attack
  64-bit block cipher IDEA vulnerable to SWEET32 attack

✅ 必须移除这两个套件！

⚠️ 其他潜在问题

• 所有套件均基于 RSA 密钥交换（而非 ECDHE），意味着：
  • ❌ 无前向保密（Forward Secrecy）
  • 如果私钥泄露，过去的所有通信都可被解密。
• 使用 CBC 模式（如 AES_CBC、3DES_CBC）：
  • 相比 GCM 模式更易受填充 oracle 攻击（如 BEAST、POODLE）。
  • 尽管未直接暴露，但不应作为首选。

4. 压缩器（Compressors）

compressors: NULL

• ✅ 不启用压缩 → 避免 CRIME/BREACH 攻击风险。
• 正确做法！

5. Cipher Preference

cipher preference: server

• 表示服务器决定使用的加密套件顺序。
• 对于安全配置来说，应优先选择强加密套件，但当前配置中却包含弱套件，因此仍不安全。

🛠️ 三、安全评级（SSLLabs 标准）

💡 参考 SSL Labs Test：此类配置通常得分为 F 或 D，无法通过 PCI-DSS、GDPR 等合规要求。

✅ 四、改进建议（强烈推荐）

✅ 1. 升级 TLS 版本

ssl_protocols TLSv1.2 TLSv1.3;

禁用 TLS 1.0 和 1.1。

✅ 2. 替换为强加密套件

ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256';

推荐使用：

• ECDHE（前向保密）
• AES-GCM 或 ChaCha20-Poly1305
• SHA256/SHA384 哈希

✅ 3. 禁用弱加密

ssl_ciphers '...';  # 上面的强套件列表
ssl_prefer_server_ciphers on;

✅ 4. 启用 HSTS 和 HTTP/2

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

✅ 5. 更换服务器软件（如适用）

• “Lego Server” 名称可疑，建议确认是否为合法产品。
• 若为自研系统，请确保其具备安全审计机制。

🔐 五、如何验证改进效果？

运行以下命令重新扫描：

nmap -sV -p 443 --script ssl-enum-ciphers www.xxxxxxxxx.com

查看输出是否：

• 不再出现 3DES, IDEA
• 无 TLS 1.0/1.1
• 使用 ECDHE + GCM 或 ChaCha20

也可访问：
🔗 https://www.ssllabs.com/ssltest/
输入域名，获取专业安全评分。

✅ 总结

🚨 结论：当前配置不符合现代安全标准，存在明确的安全漏洞，建议立即修复，否则可能导致数据泄露、证书失效、用户信任下降等问题。

如需我帮你生成一份完整的 Nginx 安全配置模板（含 TLS 1.3、HSTS、OCSP Stapling 等），请告诉我你的具体环境（如是否使用 Let's Encrypt、是否需要 HTTP/2）。

修复ZooKeeper未授权访问漏洞

根据搜索结果和ZooKeeper安全最佳实践，我为您详细分析两种ACL配置方式的风险，并提供安全加固方案。

一、两种ACL配置方式风险分析

⚠️ 方式一（明文密码）- 高风险

addauth digest user1:password1
setAcl / auth:user1:password1:cdrwa

✅ 方式二（密文密码）- 推荐

setAcl / digest:user1:HYGa7IZRm2PUBFiFFu8xY2pPP/s=:cdrwa

二、安全配置完整方案

步骤1：生成密码密文（在安全环境执行）

# 方法：使用openssl生成digest哈希（推荐在临时环境执行，执行后清除历史）
echo -n "admin:YourSecurePassword123" | openssl dgst -sha1 -binary | base64
# 输出示例：HYGa7IZRm2PUBFiFFu8xY2pPP/s=

安全提示：

• 执行后立即运行 history -c 清除命令历史
• 或使用 unset HISTFILE 临时禁用历史

步骤2：配置ZooKeeper ACL（使用密文）

# 连接ZooKeeper
/usr/local/zookeeper-3.4.13/bin/zkCli.sh -server localhost:2181

# 添加认证（此步骤密码会短暂明文，但不会持久化）
addauth digest admin:YourSecurePassword123

# 设置根节点ACL（使用密文）
setAcl / digest:admin:HYGa7IZRm2PUBFiFFu8xY2pPP/s=:cdrwa

# 验证ACL设置
getAcl /

# 退出
quit

步骤3：清理敏感痕迹

# 清除bash历史
history -c
history -w

# 检查并清理可能含密码的文件
grep -r "password" /home/shuncom/ --include="*.sh" --include="*.log"

三、针对现有部署脚本的安全修改建议

📝 修改后的安全部署脚本

#!/bin/bash
# ZooKeeper安全部署脚本 (修订版)

# ========== 安全配置变量 ==========
ZK_USER="shuncom"
ZK_GROUP="shuncom"
ZK_HOME="/usr/local/zookeeper-3.4.13"
ZK_LOG_DIR="/home/shuncom/log/zookeeper"
# ⚠️ 密码应从安全配置中心获取，不要硬编码
# ZK_PASSWORD="从密钥管理系统读取"

# ========== 基础部署 ==========
sudo tar -zxvf zookeeper-3.4.13.tar.gz -C /usr/local
sudo chown -R ${ZK_USER}.${ZK_GROUP} ${ZK_HOME}

# ========== Java环境配置 ==========
sudo touch ${ZK_HOME}/conf/java.env
cat <<EOF | sudo tee ${ZK_HOME}/conf/java.env > /dev/null
export JAVA_HOME=/usr/local/jdk1.8.0_111
# 安全加固：限制JVM内存，防止DoS
export JVMFLAGS="-Xmx512m -Xms256m"
EOF

# ========== 日志配置（保留原有配置） ==========
sudo mv ${ZK_HOME}/conf/log4j.properties ${ZK_HOME}/conf/log4j.properties.bak
sudo mkdir -p ${ZK_LOG_DIR}
sudo chown -R ${ZK_USER}.${ZK_GROUP} ${ZK_LOG_DIR}
cat <<EOF | sudo tee ${ZK_HOME}/conf/log4j.properties > /dev/null
# （保持原有log4j配置内容）
log4j.rootLogger=INFO, ROLLINGFILE
log4j.appender.ROLLINGFILE=org.apache.log4j.RollingFileAppender
log4j.appender.ROLLINGFILE.Threshold=INFO
log4j.appender.ROLLINGFILE.File=${ZK_LOG_DIR}/zookeeper.log
log4j.appender.ROLLINGFILE.MaxFileSize=10MB
log4j.appender.ROLLINGFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.ROLLINGFILE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n
EOF

# ========== 安全加固：zoo.cfg配置 ==========
cp ${ZK_HOME}/conf/zoo_sample.cfg ${ZK_HOME}/conf/zoo.cfg

# 追加安全配置
cat <<EOF | sudo tee -a ${ZK_HOME}/conf/zoo.cfg > /dev/null

# ===== 安全加固配置 =====
# 限制客户端连接数
maxClientCnxns=60
# 设置ACL默认策略（4lw命令白名单）
4lw.commands.whitelist=stat,ruok,conf,isro
# 禁用危险命令
disableAdminServer=true
EOF

# ========== 启动服务 ==========
sudo -u ${ZK_USER} ${ZK_HOME}/bin/zkServer.sh start
sleep 5
ps -fle | grep zookeeper | grep -v grep

# ========== ACL配置提示（不自动执行，需手动） ==========
echo ""
echo "===== 安全提示 ====="
echo "1. 请使用以下命令手动配置ACL（密码不要写在脚本中）："
echo "   ${ZK_HOME}/bin/zkCli.sh -server localhost:2181"
echo "   > addauth digest admin:YOUR_PASSWORD"
echo "   > setAcl / digest:admin:HASH_VALUE:cdrwa"
echo "2. 密码哈希生成命令："
echo "   echo -n 'admin:YOUR_PASSWORD' | openssl dgst -sha1 -binary | base64"
echo "3. 配置完成后执行：history -c 清除命令历史"
echo "===================="

四、额外安全加固措施（针对Ubuntu 14.04）

由于 Ubuntu 14.04已于2019年停止标准支持，需额外加固：

防火墙配置示例

# 仅允许应用服务器IP访问ZooKeeper端口
sudo ufw allow from 192.168.1.0/24 to any port 2181 proto tcp
sudo ufw deny 2181/tcp  # 拒绝其他所有访问

文件权限加固

# 限制配置文件权限
chmod 700 /usr/local/zookeeper-3.4.13/conf
chmod 600 /usr/local/zookeeper-3.4.13/conf/zoo.cfg
chmod 600 /usr/local/zookeeper-3.4.13/conf/java.env

# 限制日志文件权限
chmod 750 /home/shuncom/log/zookeeper
chmod 640 /home/shuncom/log/zookeeper/*.log

五、漏洞修复验证清单

完成配置后，请使用以下命令验证：

# 1. 验证根节点ACL
/usr/local/zookeeper-3.4.13/bin/zkCli.sh -server localhost:2181 <<EOF
getAcl /
quit
EOF
# 预期输出：'world,'anyone' 应不存在，只有 'digest:admin:xxx'

# 2. 验证未认证访问被拒绝
# 新开终端（未addauth）尝试访问
/usr/local/zookeeper-3.4.13/bin/zkCli.sh -server localhost:2181 <<EOF
ls /
# 预期：Authentication is not valid
quit
EOF

# 3. 检查命令历史无密码
grep -i "password\|passwd" ~/.bash_history
# 预期：无输出

# 4. 检查端口暴露情况
netstat -tlnp | grep 2181
# 确认仅监听必要IP

六、总结建议

按照以上方案实施后，可有效修复ZooKeeper未授权访问漏洞，满足安全扫描要求。

ubuntu14.04用iptables添加屏蔽IP规则

在 Ubuntu 14.04 上屏蔽特定 IP（如 192.168.95.80）的所有访问，最常用且有效的方法是使用 iptables（Ubuntu 14.04 默认防火墙工具）或 ufw（Uncomplicated Firewall，如果已安装）。

以下是具体操作步骤：

方法一：使用 iptables（推荐，适用于所有 Ubuntu 14.04 系统）

iptables 是底层防火墙工具，Ubuntu 14.04 默认自带。

1. 添加屏蔽规则

打开终端，运行以下命令将来自 192.168.95.80 的所有流量直接丢弃（DROP）：

sudo iptables -A INPUT -s 192.168.95.80 -j DROP

• -A INPUT: 追加规则到输入链（处理进入本机的流量）。
• -s 192.168.95.80: 指定源地址（Source）。
• -j DROP: 动作是丢弃数据包，不返回任何信息（对方会感觉超时）。

注意：如果你希望对方收到“连接被拒绝”的提示而不是超时，可以将 DROP 改为 REJECT： sudo iptables -A INPUT -s 192.168.95.80 -j REJECT 通常为了安全隐蔽，建议使用 DROP。

2. 验证规则是否生效

运行以下命令查看当前的防火墙规则列表：

sudo iptables -L -n --line-numbers

你应该能在 INPUT 链中看到类似这样的一行： DROP all -- 192.168.95.80 0.0.0.0/0

3. 【重要】永久保存规则

Ubuntu 14.04 的 iptables 规则重启后会失效，除非你手动保存。

步骤 A：安装保存工具（如果尚未安装）

sudo apt-get update
sudo apt-get install iptables-persistent

在安装过程中，它会询问是否保存当前的 IPv4 和 IPv6 规则，选择 <Yes>。

步骤 B：如果已安装工具，手动保存 如果你之前已经安装了 iptables-persistent，或者想手动更新保存：

sudo sh -c "iptables-save > /etc/iptables/rules.v4"

(如果是 IPv6，则保存到 /etc/iptables/rules.v6)

方法二：使用 ufw（仅限已启用 UFW 的系统）

如果你的系统已经启用了 ufw（可以通过 sudo ufw status 检查），可以使用更简单的命令。

1. 添加拒绝规则

sudo ufw deny from 192.168.95.80

2. 重载防火墙使规则生效

sudo ufw reload

3. 验证

sudo ufw status numbered

你会看到一条 Deny 192.168.95.80 的规则。UFW 默认会自动持久化规则，重启后依然有效。

如何取消屏蔽？

如果你以后需要恢复该 IP 的访问：

如果是用 iptables 添加的：

1. 查看规则编号：sudo iptables -L INPUT --line-numbers -n
2. 找到对应 192.168.95.80 的编号（假设是 5）：

   sudo iptables -D INPUT 5
   

3. 记得重新保存：sudo sh -c "iptables-save > /etc/iptables/rules.v4"

如果是用 ufw 添加的：

sudo ufw delete deny from 192.168.95.80

⚠️ 特别提示

• 不要屏蔽自己：如果你是通过 192.168.95.80 这台机器 SSH 连接到当前服务器的，执行上述命令后，你的连接会立即断开且无法再连上。请确保你在另一台机器上操作，或者通过控制台（Console/VNC）操作。
• Ubuntu 14.04 已停止支持：请注意 Ubuntu 14.04 (Trusty Tahr) 已于 2019 年结束标准支持，甚至扩展安全维护（ESM）也可能即将或已经结束。建议尽快规划升级到更新的 LTS 版本（如 20.04 或 22.04），以获得最新的安全补丁。

firewall-cmd命令安全加固OpenClaw服务器

你当前的 rich rule 写反了方向。
destination address 是 目标地址，表示“发往某个网段的流量”，而你需要的是 限制来源地址 (source) 访问本机。

因此规则应全部使用 source address。

另外还要注意 规则优先级顺序：

• 允许 192.168.0.1

• 再拒绝 192.168.0.0/24

• 再拒绝 192.168.1.0/24

• 再拒绝 192.168.4.0/24

否则 192.168.0.1 可能被 /24 规则误拦截。

一、先删除错误规则

firewall-cmd --permanent --remove-rich-rule='rule family="ipv4" destination address="192.168.4.0/24" reject'
firewall-cmd --permanent --remove-rich-rule='rule family="ipv4" destination address="192.168.1.0/24" reject'
firewall-cmd --permanent --remove-rich-rule='rule family="ipv4" source address="192.168.0.1" accept'

二、按正确逻辑添加规则

1 允许网关访问

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.0.1" accept'

2 禁止 192.168.0.0/24 访问（排除网关）

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" reject'

3 禁止其它两个网段

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" reject'

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.4.0/24" reject'

4 加上出站规则禁止本机访问其它四个网段，以下是所有规则

#入站规则
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.0.1" accept'
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" reject'
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" reject'
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.4.0/24" reject'
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.30.0/24" reject'
firewall-cmd --permanent --add-service=ssh

#出站规则
firewall-cmd --permanent \
--direct --add-rule ipv4 filter OUTPUT 0 \
-d 192.168.0.1 -j ACCEPT
firewall-cmd --permanent \
--direct --add-rule ipv4 filter OUTPUT 1 \
-d 192.168.0.0/24 -j REJECT
firewall-cmd --permanent \
--direct --add-rule ipv4 filter OUTPUT 1 \
-d 192.168.1.0/24 -j REJECT
firewall-cmd --permanent \
--direct --add-rule ipv4 filter OUTPUT 1 \
-d 192.168.4.0/24 -j REJECT
firewall-cmd --permanent \
--direct --add-rule ipv4 filter OUTPUT 1 \
-d 192.168.30.0/24 -j REJECT

firewall-cmd --reload
firewall-cmd --list-rich-rules

#查看出站规则
firewall-cmd --direct --get-all-rules
#查看入入站规则
firewall-cmd --list-all

三、确保 SSH 开放

你已经有：

services: ssh

如果需要可以再确认：

firewall-cmd --permanent --add-service=ssh

四、重新加载规则

firewall-cmd --reload

五、最终预期结果

firewall-cmd --list-rich-rules

应该类似：

rule family="ipv4" source address="192.168.0.1" accept
rule family="ipv4" source address="192.168.0.0/24" reject
rule family="ipv4" source address="192.168.1.0/24" reject
rule family="ipv4" source address="192.168.4.0/24" reject

六、实现效果

并且：

• 服务器访问外网不受影响

• 默认 SSH 对外开放

七、生产环境更严谨写法（推荐）

只限制 SSH 而不是全部流量：

rule family="ipv4" source address="192.168.1.0/24" service name="ssh" reject

否则会影响：

• ping

• http

• agent

• 监控

你的当前情况需要先明确一个关键点：

1️⃣ 当前 openclaw 端口实际上 外部无法访问

从 netstat 看：

127.0.0.1:18789
127.0.0.1:18791
127.0.0.1:18792

绑定在 127.0.0.1 (loopback)，意味着：

• 只有 本机 localhost 可以访问

• 任何外部 IP 都无法连接

所以即使在 firewalld 放行，这些端口 仍然不会对外开放。

如果你的目标是：

允许 除禁止网段外的所有IP访问 openclaw

则必须先让程序监听 0.0.0.0 或 192.168.0.33。

例如：

0.0.0.0:18789
0.0.0.0:18791
0.0.0.0:18792

否则防火墙规则不会生效。

一、firewalld 完整推荐规则

你的需求总结：

二、开放 openclaw 端口

firewall-cmd --permanent --add-port=18789/tcp
firewall-cmd --permanent --add-port=18791/tcp
firewall-cmd --permanent --add-port=18792/tcp

UDP 5353：

firewall-cmd --permanent --add-port=5353/udp

三、配置 IP 限制规则

1 允许网关

firewall-cmd --permanent \
--add-rich-rule='rule family="ipv4" source address="192.168.0.1" accept'

2 禁止三个网段

firewall-cmd --permanent \
--add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" reject'

firewall-cmd --permanent \
--add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" reject'

firewall-cmd --permanent \
--add-rich-rule='rule family="ipv4" source address="192.168.4.0/24" reject'

四、重新加载

firewall-cmd --reload

五、最终规则验证

firewall-cmd --list-all

应看到：

services: ssh
ports: 18789/tcp 18791/tcp 18792/tcp 5353/udp
rich rules:
 rule family="ipv4" source address="192.168.0.1" accept
 rule family="ipv4" source address="192.168.0.0/24" reject
 rule family="ipv4" source address="192.168.1.0/24" reject
 rule family="ipv4" source address="192.168.4.0/24" reject

六、访问效果

服务器访问外网 不受影响。

七、非常重要（openclaw 必须改监听地址）

如果你想让别人访问 openclaw，必须看到：

0.0.0.0:18789
0.0.0.0:18791
0.0.0.0:18792

而不是：

127.0.0.1:18789

常见修改方式：

config.yaml
gateway.yaml
server.conf
--host 0.0.0.0

你遇到的错误是 正常现象：

firewalld rich rule 不支持 direction="out" 属性，所以会报：

INVALID_RULE: bad attribute 'direction'

在 firewalld 架构中：

• rich rule 默认作用于 INPUT / FORWARD

• 不直接支持 OUTPUT 方向控制

如果要限制 本机访问其它网段（egress filtering），通常有三种方法：

1️⃣ 使用 direct rule（推荐）
2️⃣ 使用 policy objects（firewalld 1.0+）
3️⃣ 直接使用 iptables/nftables

在 Ubuntu 24.04 + firewalld，最简单稳定的是 direct rule。

一、实现你的需求的正确方法

需求：

禁止本机访问：
192.168.0.0/24 (除192.168.0.1)
192.168.1.0/24
192.168.4.0/24

二、允许访问网关

firewall-cmd --permanent \
--direct --add-rule ipv4 filter OUTPUT 0 \
-d 192.168.0.1 -j ACCEPT

三、禁止访问三个网段

禁止 192.168.0.0/24

firewall-cmd --permanent \
--direct --add-rule ipv4 filter OUTPUT 1 \
-d 192.168.0.0/24 -j REJECT

禁止 192.168.1.0/24

firewall-cmd --permanent \
--direct --add-rule ipv4 filter OUTPUT 1 \
-d 192.168.1.0/24 -j REJECT

禁止 192.168.4.0/24

firewall-cmd --permanent \
--direct --add-rule ipv4 filter OUTPUT 1 \
-d 192.168.4.0/24 -j REJECT

四、重新加载

firewall-cmd --reload

五、验证 direct 规则

firewall-cmd --direct --get-all-rules

应该看到：

ipv4 filter OUTPUT 0 -d 192.168.0.1 -j ACCEPT
ipv4 filter OUTPUT 1 -d 192.168.0.0/24 -j REJECT
ipv4 filter OUTPUT 1 -d 192.168.1.0/24 -j REJECT
ipv4 filter OUTPUT 1 -d 192.168.4.0/24 -j REJECT

六、最终完整防火墙策略

入站限制

192.168.0.1 允许
192.168.0.0/24 禁止
192.168.1.0/24 禁止
192.168.4.0/24 禁止

出站限制

192.168.0.1 允许
192.168.0.0/24 禁止
192.168.1.0/24 禁止
192.168.4.0/24 禁止
外网允许

七、最终访问效果

八、运维建议（非常重要）

你的服务器：

192.168.0.33

如果完全禁止访问：

192.168.0.0/24

可能影响：

• DNS

• NTP

• 内网API

• NFS / SMB

• LDAP / AD

生产环境通常只限制 SSH / 管理端口，而不是整个网段。

如果需要，我可以给你一套 运维服务器 firewalld 最佳实践配置（约25条规则），特点：

• SSH 防暴力破解

• 内网扫描防护

• 只允许必要端口

• 自动记录攻击日志

• 适合 Ubuntu 20/22/24 运维服务器。

针对 Ubuntu 18.04 服务器，要仅封禁特定 IP 地址且不影响其他任何端口及 IP 的访问

针对 Ubuntu 18.04 服务器，要仅封禁特定 IP 地址且不影响其他任何端口及 IP 的访问，最标准、高效且对系统性能影响最小的方法是使用 iptables。

Ubuntu 18.04 默认可能使用 ufw (Uncomplicated Firewall)，但 ufw 底层也是 iptables。为了精准控制且不干扰现有规则，直接使用 iptables 命令是最稳妥的。

以下是具体操作步骤：

🚀 方法一：使用 iptables 直接封禁（推荐，即时生效）

这种方法不需要安装额外软件，直接操作内核防火墙规则。

1. 执行封禁命令

请在终端中逐行复制并执行以下命令（需要 root 权限）：

# 封禁 广东深圳 IP
sudo iptables -I INPUT -s 103.44.236.211 -j DROP

# 封禁 江西南昌 IP
sudo iptables -I INPUT -s 223.83.150.76 -j DROP

# 封禁 中国香港 IP (1)
sudo iptables -I INPUT -s 83.229.126.117 -j DROP

# 封禁 中国香港 IP (2)
sudo iptables -I INPUT -s 45.192.103.126 -j DROP

# 封禁 美国 IP
sudo iptables -I INPUT -s 148.153.56.174 -j DROP

• ** -I INPUT: 表示在输入链的最前面**插入规则（优先级最高，确保先于允许规则执行）。
• ** -s**: 代表 Source（源地址），即你要封禁的 IP。
• ** -j DROP**: 代表直接丢弃数据包，对方连接时会显示超时，就像网络断开一样（比 REJECT 更安全，不返回拒绝信息）。

2. 验证是否生效

执行以下命令查看当前的防火墙规则，确认刚才添加的规则是否存在：

sudo iptables -L INPUT -n --line-numbers

你应该能在列表的最上方看到这几条带有 DROP 字样的规则。

💾 关键步骤：永久保存规则（防止重启失效）

注意：iptables 命令默认是临时的，服务器重启后规则会丢失。你必须执行以下步骤将其保存。

情况 A：如果你没有安装 iptables-persistent (纯净版 Ubuntu)

1. 安装保存工具：

   sudo apt-get update
   sudo apt-get install iptables-persistent
   

2. 在安装过程中，它会问你是否保存当前的 IPv4 和 IPv6 规则，选择 Yes。
3. 如果以后修改了规则，手动保存命令为：

   sudo netfilter-persistent save
   

情况 B：如果你正在使用 UFW

如果你之前一直用 ufw 管理防火墙，直接运行上面的 iptables 命令也是有效的（因为 ufw 本质就是 iptables），且优先级通常高于 ufw 的默认规则。
为了确保重启后依然有效，建议将上述规则写入 UFW 的自定义文件，或者坚持使用上面的 iptables-persistent 方法（两者共存通常没问题，只要不冲突）。

最稳妥的 UFW 用户做法：
创建自定义规则文件：

sudo nano /etc/ufw/before.rules

在文件的 *filter 部分之后，COMMIT 之前，加入以下内容：

# 开始添加封禁 IP
-A ufw-before-input -s 103.44.236.211 -j DROP
-A ufw-before-input -s 223.83.150.76 -j DROP
-A ufw-before-input -s 83.229.126.117 -j DROP
-A ufw-before-input -s 45.192.103.126 -j DROP
-A ufw-before-input -s 148.153.56.174 -j DROP
# 结束添加

保存退出后，重启 UFW：

sudo ufw disable && sudo ufw enable

️ 进阶方案：如果攻击 IP 非常多（使用 ipset）

如果将来封禁的 IP 达到几十上百个，每条都写一条 iptables 规则会降低服务器网络性能。此时建议使用 ipset（IP 集合）。

1. 安装 ipset:

   sudo apt-get install ipset
   

2. 创建一个名为 blacklist 的集合:

   sudo ipset create blacklist hash:ip
   

3. 将恶意 IP 加入集合:

   sudo ipset add blacklist 103.44.236.211
   sudo ipset add blacklist 223.83.150.76
   sudo ipset add blacklist 83.229.126.117
   sudo ipset add blacklist 45.192.103.126
   sudo ipset add blacklist 148.153.56.174
   

4. 添加一条 iptables 规则，拒绝该集合内的所有 IP:

   sudo iptables -I INPUT -m set --match-set blacklist src -j DROP
   

5. 保存 ipset 集合 (防止重启丢失):

   sudo apt-get install ipset-persistent
   sudo ipset save > /etc/ipset.conf
   

   (注：需配置开机自动恢复 /etc/ipset.conf，或简单地将 ipset restore < /etc/ipset.conf 加入 /etc/rc.local)

✅ 总结

对于你目前的 5 个 IP，直接使用 方法一（iptables 命令） 最快最直接。
切记： 执行完命令后，务必执行 保存操作 (netfilter-persistent save)，否则重启服务器后防护会失效。

Dubbo 服务运行在 Docker 容器中，修复漏洞方法如下

结合你提供的截图信息，你的服务器 IP 是 169.169.39.135，且 Dubbo 服务运行在 Docker 容器中，端口映射为 0.0.0.0:20817->20817。

这意味着 20817 端口直接绑定在宿主机的所有网卡上（0.0.0.0）并暴露给了公网，这就是漏洞产生的原因。

以下是针对你当前环境（Docker + Linux）的具体修复步骤：

方法一：修改 Docker 端口绑定（最快修复，无需改代码）

既然 Dubbo 服务只需要内部调用，不需要从公网直接访问，我们可以修改 Docker 的端口映射，让 20817 端口只监听本地回环地址（127.0.0.1），或者直接不映射到宿主机。

操作步骤：

1. 找到你的 docker-compose.yml 文件。
2. 找到 rurl-model-proxy-server 这个服务的 ports 配置部分。
3. 将 20817:20817 修改为 127.0.0.1:20817:20817。

修改前：

ports:
  - "20817:20817"
  - "8041:8090"

修改后：

ports:
  - "127.0.0.1:20817:20817"  # 加上 127.0.0.1 限制
  - "8041:8090"

效果： 修改后，外部网络（包括你的公网 IP 169.169.39.135）将无法访问 20817 端口，只有服务器本机可以访问。

重启服务：

docker-compose down
docker-compose up -d

方法二：配置服务器防火墙（iptables）

如果你不想修改 Docker 配置，或者修改后仍希望特定内网 IP 能访问，可以使用防火墙策略。

目标： 禁止公网访问 20817，但允许本机或特定内网访问。

执行命令（在宿主机上执行）：

1. 拒绝外部访问 20817：

   # 拒绝所有外部 IP 访问 TCP 20817 端口
   iptables -I INPUT -p tcp --dport 20817 ! -s 127.0.0.1 -j DROP
   

   (注意：如果你的应用服务器在其他机器上，比如 192.168.x.x，需要把 ! -s 127.0.0.1 改为 -s 192.168.x.x 或者添加一条允许规则)

2. 保存规则（防止重启失效）：

   service iptables save
   # 或者根据你的系统
   iptables-save > /etc/iptables/rules.v4
   

方法三：Dubbo 内部配置（彻底禁用 Telnet）

这是最安全的做法，即使端口暴露了，黑客也无法通过 Telnet 执行命令。

操作步骤：

1. 进入容器内部或修改你的项目配置文件（application.yml 或 dubbo.properties）。
2. 禁用 Telnet 命令支持。

如果你使用的是 Spring Boot 配置 (application.yml)，在 rurl-model-proxy-server 的配置中添加：

dubbo:
  protocol:
    name: dubbo
    port: 20817
    # 关键点：设置为 false 或空，禁用 telnet
    telnet: false 

或者在 dubbo.properties 中：

dubbo.protocol.telnet=false

修改后重启容器：

docker-compose restart rurl-model-proxy-server

验证修复结果

修复完成后，请在你的本地电脑（非服务器内部）使用 telnet 测试：

telnet 169.169.39.135 20817

• 修复成功： 连接超时（Connection timed out）或连接被拒绝（Connection refused）。
• 修复失败： 屏幕变黑或出现 Connected to... 字样。

建议优先采用“方法一”或“方法二”，因为这是基础设施层面的防护，最快生效。

732字节、1秒root、九年无人知——Linux近年最稳定提权漏洞

【已复现】732字节、1秒root、九年无人知——Linux近年最稳定提权漏洞

# Ubuntu / Debianapt update && apt upgrade linux-image-$(uname -r)# RHEL / CentOS / Rocky / Almadnf update kernel# Amazon Linuxyum update kernel# SUSEzypper update kernel-default

grep -r "a664bf3d603d" /proc/version 2>/dev/null || uname -r # 验证是否包含修复commit或对比发行版官方公告中的修复版本号

# 永久禁用（重启后生效）echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf# 立即卸载（当前会话生效）rmmod algif_aead 2>/dev/null || true

禁用 algif_aead 的影响评估：

银河麒麟v10高级服务器系统OpenSSH漏洞修复建议

你的当前版本：

OpenSSH_8.2p1

属于：

OpenSSH <= 9.7p1

因此从版本范围上看，在漏洞影响范围内。

但在麒麟/国产 Linux 中，还需要进一步确认：

是否已经做了 backport 安全修复。

因为很多国产系统不会升级主版本号，只会回补 CVE 修复。

一、先确认是否已修复（非常重要）

执行：

rpm -q --changelog openssh | grep -Ei "CVE|security"

以及：

rpm -q --changelog openssh-clients | tail -50

查看是否出现：

CVE-2024-6387
CVE-2024-6409
scp
command injection

或者类似：

backport security fix

二、确认安装包版本（重点）

执行：

rpm -qa | grep openssh

例如可能看到：

openssh-8.2p1-12.ky10
openssh-clients-8.2p1-12.ky10

关键是：

-12.ky10

这种发行版补丁号。

如果补丁号较老，一般说明未修复。

三、推荐修复方案（麒麟V10）

直接升级 openssh

执行：

yum clean all
yum makecache
yum update openssh openssh-clients openssh-server

或者：

dnf update openssh*

更新后再次查看：

ssh -V

以及：

rpm -qa | grep openssh

四、如果仓库没有更新包

说明：

• 厂商暂未发布补丁

• 或未启用安全源

可先执行：

yum repolist

确认：

• update

• updates

• security

仓库是否启用。

五、临时缓解（生产环境建议立即做）

即使没法升级，也建议立即加固。

1. 禁止使用 scp（最有效）

因为漏洞点就在：

scp.c

建议：

• 全部改为 sftp

• 或 rsync

例如：

rsync -avz /data user@host:/backup/

2. 限制 SSH 登录 IP

例如：

firewall-cmd --permanent --add-source=你的办公IP
firewall-cmd --reload

3. 禁止 root 登录

编辑：

vi /etc/ssh/sshd_config

修改：

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

重启：

systemctl restart sshd

4. 开启 Fail2ban（推荐）

防暴力破解：

yum install fail2ban -y

六、该漏洞的真实风险

这个漏洞：

触发条件

通常需要：

• 用户主动执行 scp

• 连接恶意 SSH 服务端

或者：

• 中间人攻击

因此：

风险级别

七、生产环境推荐方案（你现在最适合）

建议你按下面顺序处理：

第一优先级

立即：

yum update openssh*

第二优先级

停用：

scp

改：

sftp / rsync

第三优先级

加固 sshd：

禁止root
密钥登录
限制IP

八、建议你再执行两个命令（可直接发我）

请把输出发我，我可以直接帮你判断：

rpm -qa | grep openssh

以及：

rpm -q --changelog openssh-clients | tail -30

我可以进一步帮你确认：

• 是否真的存在漏洞

• 是否已被厂商修复

• 是否只是“版本号误报”

• 给你最小化修复方案（不影响业务）

你这个扫描报告里写的：

OpenSSH 命令注入漏洞（CVE-2020-15778）

这才是你真正需要处理的漏洞。

前面那个：

CVE-2023-51385

不是同一个漏洞。

一、CVE-2020-15778 是什么

这是 OpenSSH scp 的经典命令注入漏洞。

影响版本：

OpenSSH <= 8.3p1

你的版本：

OpenSSH_8.2p1

确实命中影响范围。

二、漏洞原理

漏洞位于：

scp.c

scp 在处理：

目标文件名
远程路径
特殊字符

时没有严格过滤 shell 元字符。

攻击者可构造：

` ; & | $( )

等特殊字符实现：

• 本地命令执行

• 命令注入

三、关键问题：你现在是否已经修复？

你当前 changelog 里：

没有出现 CVE-2020-15778

这说明：

❌ 目前无法证明已修复。
❌ 大概率确实存在。
✅ 扫描器这次不是误报。

四、为什么之前那个 patch 不算

你已有：

CVE-2023-51385

它只是：

后续加强过滤

但：

不能完全等价替代 CVE-2020-15778 官方修复

审计方一般不会认可。

五、官方修复方式

OpenSSH 官方在：

OpenSSH 8.4p1

中修复了：

CVE-2020-15778

所以理论上：

升级 >= 8.4p1

即可。

六、你当前最现实的修复方案（麒麟环境）

国产系统不能直接编译覆盖 openssh。

否则：

• sshd 可能无法启动

• PAM 认证损坏

• 国密支持丢失

• 被等保判违规

因此：

推荐方案

方案1（推荐）

联系麒麟源升级：

yum update openssh*

然后查看：

rpm -q --changelog openssh | grep 15778

如果出现：

fix CVE-2020-15778

即可关闭漏洞。

七、如果官方源没有补丁（很常见）

这是国产系统最常见情况。

因为：

8.2p1-16.p18

已经是较新的 KY10 patch level。

但仍未 backport：

15778

八、生产环境临时缓解（审计通常接受）

因为：

漏洞只影响 scp

不影响：

• ssh

• sftp

• rsync

所以可以：

1. 禁止 scp（最重要）

这是官方推荐缓解。

方法：

限制用户使用：

alias scp='echo "scp disabled due to CVE-2020-15778"; false'

或者：

chmod 750 /usr/bin/scp

更严格：

chmod 700 /usr/bin/scp
chown root:root /usr/bin/scp

2. 全面改用 rsync

例如：

rsync -avz /data user@host:/backup/

3. 或改用 sftp

例如：

sftp user@host

九、审计/漏洞管理如何写（很关键）

很多单位最后采用：

缓解方案 + 风险接受

因为：

• 厂商没提供补丁

• 业务不能升级 OpenSSH

这是很常见的。

十、给你一个“整改说明”模板（可直接交付）

漏洞名称：OpenSSH 命令注入漏洞（CVE-2020-15778）

漏洞影响：
OpenSSH scp 模块在处理特殊字符时存在命令注入风险。

当前环境：
系统为银河麒麟 V10，当前 OpenSSH 版本为：
OpenSSH_8.2p1-16.p18.ky10.x86_64

核查情况：
当前厂商补丁中未发现 CVE-2020-15778 修复记录。

整改措施：

1. 已停止使用 scp 文件传输方式；

2. 已统一改为 rsync / sftp；

3. 已限制 scp 二进制执行权限；

4. 已加强 SSH 登录访问控制；

5. 持续关注麒麟官方安全补丁更新。

整改结果：
漏洞利用条件已被阻断，风险得到有效缓解。

十一、你现在最推荐的操作

立刻执行（推荐）

禁用 scp

chmod 750 /usr/bin/scp

改用 rsync

yum install rsync -y

查看是否有官方补丁

yum update openssh*

更新后：

rpm -q --changelog openssh | grep 15778

十二、不要做的事（非常重要）

不要：

源码编译 OpenSSH 9.x 覆盖系统

在麒麟上极容易导致：

• ssh 登录失效

• PAM 崩溃

• 国密模块异常

• 无法远程连接

生产环境风险很大。

银河麒麟v10 升级 SSH由8.2到9.9 二进制安装失败

根据您提供的 yum check-update 输出结果，情况如下：

结论： 您的系统官方源中目前没有更新的 OpenSSH 版本。

• 当前版本： 8.2p1
• 源中最新版本： 8.2p1-16.p27.ky10

虽然版本号相同，但这是一个针对麒麟系统的修订版。它可能包含部分安全补丁（Backport），但通常无法修复像 CVE-2020-15778 这种涉及代码逻辑变更的漏洞。

因此，为了彻底修复漏洞，您需要采用 源码编译安装 的方式将 OpenSSH 升级到最新的稳定版（建议 9.9p2 或更高）。

🚀 升级操作指南 (CentOS/Kylin V10)

由于涉及到底层核心组件升级，请务必严格按照以下步骤操作。

⚠️ 第一阶段：准备工作与备份 (至关重要)

严重警告：

1. 不要关闭当前的 SSH 窗口！ 请新开一个窗口进行测试，确保新服务正常后再关闭旧窗口。
2. 建议开启 Telnet 服务或通过 VNC/IPMI 控制台操作，以防升级失败导致无法远程连接。

1. 安装编译依赖：

   sudo yum install -y gcc make zlib-devel openssl-devel pam-devel systemd-devel wget tar
   

2. 备份现有文件：

   # 备份配置文件
   sudo cp -r /etc/ssh /etc/ssh.bak.$(date +%F)
   # 备份二进制文件
   sudo cp /usr/bin/ssh /usr/bin/ssh.bak
   sudo cp /usr/sbin/sshd /usr/sbin/sshd.bak
   

📥 第二阶段：下载与编译

3. 下载最新源码包： 我们将下载最新的 OpenSSH 9.9p2（修复了您提到的漏洞及后续多个高危漏洞）。

   cd /tmp
   wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.9p2.tar.gz
   tar -zxf openssh-9.9p2.tar.gz
   cd openssh-9.9p2
   

4. 编译与安装： 注意配置参数，确保兼容麒麟系统的 PAM 认证和 Systemd 管理。

   ./configure --prefix=/usr --sysconfdir=/etc/ssh --with-ssl-dir=/usr/lib64 --with-zlib --with-pam --with-systemd
   
   make
   sudo make install
   

🔧 第三阶段：配置与服务替换

5. 修正配置文件权限： 新版本可能会生成新的配置示例，我们需要确保主配置文件允许 Root 登录（除非您有专门的普通用户）。

   # 检查配置文件中 PermitRootLogin 是否为 yes
   sudo sed -i 's/#PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
   # 如果是密码登录，确保 PasswordAuthentication 为 yes
   sudo sed -i 's/#PasswordAuthentication.*/PasswordAuthentication yes/' /etc/ssh/sshd_config
   

6. 替换 Systemd 服务文件： 这是最关键的一步，否则 systemctl restart sshd 可能会失败。

   # 复制官方提供的 systemd 文件
   sudo cp contrib/redhat/sshd.init /etc/init.d/sshd
   sudo chmod +x /etc/init.d/sshd
   
   # 如果存在旧的 systemd 服务文件，建议移除或覆盖（视具体系统情况而定）
   # 这里我们尝试直接重启服务
   

7. 重启 SSH 服务：

   sudo systemctl daemon-reload
   sudo systemctl restart sshd
   

✅ 第四阶段：验证

8. 检查版本： 在新开的终端窗口执行：

   ssh -V
   

   如果显示 OpenSSH_9.9p2，则说明升级成功。

9. 清理： 确认无误后，可以删除 /tmp 下的源码包。

💡 补充说明

如果您觉得编译安装风险太大，且该服务器不对外网开放，您可以暂时维持现状，但建议结合之前的方案二（临时缓解），即重命名 /usr/bin/scp，以阻断最直接的漏洞利用途径。

银河麒麟v10高级服务器系统如何防止fiewalld服务自启

不会正常自动启动，但有几个“例外情况”你必须注意（麒麟 V10 很容易踩这个坑）。

✅ 结论先说

执行：

systemctl stop firewalld
systemctl disable firewalld

结果是：

• ✔ 当前立刻停止 firewalld

• ✔ 取消开机自启（systemd 层面）

👉 正常情况下不会再自动启动

⚠️ 但在 Kylin V10 里有 3 个常见“反复复活”情况

① NetworkManager / 图形策略重新拉起（最常见）

某些麒麟版本：

NetworkManager 或安全策略服务
→ 会重新启用 firewalld

检查：

systemctl status NetworkManager

② 安全基线 / 安全管理组件

麒麟系统可能有：

• 安全中心

• 等保工具

• 国产加固模块

会周期性执行：

恢复默认安全策略 = 启动 firewalld

③ 被误设置为 static / alias 重启依赖

检查：

systemctl is-enabled firewalld

正常应该是：

disabled

如果是：

static

说明它可能被别的服务依赖启动。

🔍 如何确认“绝对不会再自动启动”

执行这三步：

1️⃣ 确认状态

systemctl status firewalld

2️⃣ 确认开机自启

systemctl is-enabled firewalld

必须是：

disabled

3️⃣ 彻底屏蔽（推荐）

如果你想“100% 禁止任何方式启动”，执行：

systemctl mask firewalld

👉 这一步最关键

效果：

• 禁止手动启动

• 禁止依赖启动

• 禁止系统恢复启动

🚨 推荐做法（生产环境）

✔ 最终建议命令（标准安全做法）

systemctl stop firewalld
systemctl disable firewalld
systemctl mask firewalld

🧠 一句话总结

disable 只是“取消开机启动”
mask 才是“彻底封死不让任何服务再启动它”

如果你愿意，我可以帮你把 Kylin V10 + Docker 的网络安全整理成一套：

• firewalld 是否保留

• iptables / nft 最佳组合

• DOCKER-USER 标准策略

• 生产端口最小暴露方案

会比现在这种“看起来关了但很混乱”的状态稳定很多。

麒麟v10 kylin v10 清除firewall所有策略恢复原始

你这个报错是正常的，因为：

❌ firewall-cmd --reset-default-zone 在 firewalld 里根本不存在这个参数

（很多网上资料是错的或旧版本误传）

🚨 你现在真实状态分析

你的 public zone 已经是：

sources: 10.2.2.0/24   ← 关键
ports: 一大堆已开放
masquerade: no

说明：

❗ 你现在不是“默认状态”

而是：

⚠️ zone 被人工改造过（不是 reset 可恢复）

🧹 正确“恢复默认状态”方法（Kylin V10 可用）

⭐ 方法1（推荐）：清空 zone + 恢复默认策略

1️⃣ 清空所有 ports

for p in 80 443 8070 20881 8082 20853 8086 20835 4443; do
  firewall-cmd --permanent --zone=public --remove-port=${p}/tcp
done

2️⃣ 删除 source（关键）

你现在这个：

sources: 10.2.2.0/24

执行：

firewall-cmd --permanent --zone=public --remove-source=10.2.2.0/24

3️⃣ 恢复 ssh / 默认服务

firewall-cmd --permanent --zone=public --add-service=ssh

4️⃣ reload

firewall-cmd --reload

⭐ 方法2（最干净）：删除 public zone 配置文件

如果你想“一键回出厂默认”，用这个：

systemctl stop firewalld

rm -f /etc/firewalld/zones/public.xml

systemctl start firewalld

👉 这会让 firewalld 自动重建默认 public zone

🔍 方法3（推荐生产）：重新初始化 firewalld

systemctl stop firewalld
rm -rf /etc/firewalld
yum reinstall firewalld -y   # 或 dnf
systemctl start firewalld

👉 最彻底（等同“恢复出厂设置”）

⚠️ 你现在最关键问题其实是这个

sources: 10.2.2.0/24

这意味着：

🔥 你 firewall 已经被改成“只信任内网网段”

所以表现会是：

• 外部访问异常

• 端口行为不一致

• Docker + firewalld 混乱

🧠 一句话总结

🚀 建议你下一步做这个（最稳）

如果你是生产环境：

👉 我建议直接做：

rm -f /etc/firewalld/zones/public.xml
systemctl restart firewalld

然后再重新只加：

• ssh

• 需要暴露的 80/443

如果你愿意，我可以帮你把你这台：

麒麟 V10 + Docker + 多微服务

整理成一套：

✔ 不互相冲突
✔ DOCKER-USER 控制流量
✔ firewalld 只做基础保护
✔ 不会再出现“规则失效 / 端口混乱”

这类结构才是稳定生产配置。