分类： 网事-网摘

启用Imperva CDN情况下，使用Fail2Ban屏蔽恶意访问

针对 Debian 系统，以及 Imperva CDN 环境，使用“Fail2Ban + Nginx Deny” 的方案。

获取真实IP

使用Imperva时，nginx日志中只有CDN的IP地址，所以首先要获取真实IP。 配置文件在/etc/nginx/conf.d中加入配置文件：

继续阅读启用Imperva CDN情况下，使用Fail2Ban屏蔽恶意访问

Cloudflare Tunnel链接错误排查

一大早Cloudflare Tunnel忽然坏掉了。 修复结论：除了检查QUIC协议是否被屏蔽之外，也查一下本机时间同步。

T00:33:53Z INF Retrying connection in up to 1m4s connIndex=0 event=0 ip=198.18.0.134 
2026-01-06T00:33:54Z WRN If this log occurs persistently, and cloudflared is unable to connect to Cloudflare Network with `quic` protocol, then most likely your machine/network is getting its egress UDP to port 7844 (or others) blocked or dropped. Make sure to allow egress connectivity as per https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/ports-and-ips/ If you are using private routing to this Tunnel, then ICMP, UDP (and Private DNS Resolution) will not work unless your cloudflared can connect with Cloudflare Network with `quic`. connIndex=0 event=0 ip=198.18.0.134 
2026-01-06T00:33:54Z INF Switching to fallback protocol http2 connIndex=0 event=0 ip=198.18.0.134 
2026-01-06T00:35:52Z ERR Serve tunnel error error="TLS handshake with edge error: EOF" connIndex=0 event=0 ip=198.18.0.134 2026-01-06T00:35:52Z INF Retrying connection in up to 1m4s connIndex=0 event=0 ip=198.18.0.134 2026-01-06T00:36:17Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: EOF" connIndex=0 event=0 ip=198.18.4.32 2026-01-06T00:36:17Z ERR Serve tunnel error error="TLS handshake with edge error: EOF" 
connIndex=0 event=0 ip=198.18.4.32 2026-01-06T00:36:17Z INF Retrying connection in up to 1m4s connIndex=0 event=0 ip=198.18.4.32

最先想到的是服务商突然屏蔽了QUIC 协议（基于 UDP 端口 7844），准备开始查资料看能否代理。 后来检查中，发现windows时间同步是三天前，手工同步time.windows.com一直失败。 再后来，发现是之前一次代理规则调整不当，造成了时间同步失败。之后本地时间不准确，造成TLS handshake失败。

查看日志处理Synology Drive Client文章同步失败

同步客户端里，有文件一直是preparing，准备中的状态。但是在窗口里看不到这个文件的具体路径。

第一步：找到这些文件的具体路径

既然文件名很普通，无法通过全盘搜索定位，需要通过 Synology Drive Client 的日志查找

  1. 按下 Win + R 键，打开运行窗口。
  2. 输入 %localappdata%\SynologyDrive\log 并回车。
  3. 你会看到一堆日志文件。找到 daemon.log （或者 service.log，通常是 daemon.log 记录同步核心进程）。
  4. 用记事本或 VS Code 打开它。
  5. 使用查找功能（Ctrl+F），搜索你在界面上看到的那个文件名。
  6. 你应该能搜到类似 [ERROR] worker.cpp... /Volume/Path/To/File.jpg 这样的记录，这里面就会包含完整的绝对路径。

继续阅读查看日志处理Synology Drive Client文章同步失败

修复React2Shell漏洞导致服务器权限泄露 之二

参考这篇分析报告，重新做一轮检查修复 https://www.huntress.com/blog/peerblight-linux-backdoor-exploits-react2shell

核心相似点：

  1. 伪装系统文件： 文章提到恶意软件会将自己伪装成看似合法的系统进程。你遇到的 /bin/systemd-daemon 正是这种典型手段（真正的 systemd 不在这个位置，也不叫这个名字）。
  2. 持久化机制： 利用 Systemd 服务（Service）进行驻留，确保杀不死、重启自愈。
  3. 行为模式： 作为“加载器（Dropper）”，定期从 C2 服务器（你的案例中是 185.196.9.41）下载并执行新的恶意脚本（um2）。

既然暂时不能重装系统，我们需要制定一个“外科手术式” 的深度清理方案。请务必按照以下步骤，一次性、连贯地执行，不要中断，以防病毒利用时间差复活。

继续阅读修复React2Shell漏洞导致服务器权限泄露 之二