我查看了访问日志中的攻击

常规互联网扫描与攻击模式

• 日志里的大多数“攻击”都是低技术含量、完全自动化的扫描，针对每个可路由 IP 逐个尝试，常带着针对旧 CVE 的固定载荷（.env 泄露、Shellshock、Wordpress/PHP 路径等）。
• 许多工具只是不断轰炸服务器，并不检查响应；有时还会从相同的静态 IP 或地址段重复发起。
• 一些人得出的结论是：如果你遵循基本安全实践，这些探测无关紧要；如果你没遵循，它们也无关紧要，因为你本来就已经脆弱了。

---

Fail2ban、SSH 与基础主机加固

• Fail2ban 主要用于减少日志噪音和降低暴力破解尝试；也有人说它已经过时、资源消耗大，而且对 IP 轮换无效。
• 常见的 SSH 建议：禁用密码认证，仅使用密钥；可选地把服务移出 22 端口；限制来源 IP；或者把 SSH 放在 VPN、堡垒机/“黑洞”式访问后面。
• 有些人改用 iptables/nftables 的速率限制或 port knocking，而不是 fail2ban；仅允许 IPv6 SSH、同时用防火墙封掉 IPv4，也是另一种策略。

---

WAF、Cloudflare 与权衡

• 有人建议使用 AWS WAF、Azure WAF（OWASP 规则）或 Cloudflare 的免费 WAF，来过滤明显攻击并满足合规要求。
• 强烈警告：默认规则经常会破坏合法流量（阻止某些请求体、缺少 User-Agent、带元数据的文件上传、过长 URL）。最佳实践是先用“计数模式”，再逐步开启阻断。
• 批评者认为 WAF 会制造虚假的安全感、可被绕过、增加延迟，并可能拦截研究人员或 Tor 用户；支持者则认为它们是有用的权宜之计，但不能替代安全的应用程序。
• 有人担心将流量集中到 Cloudflare 这类大型提供商之后会带来集中化问题，但也有人指出还有替代方案，而且锁定效应相对较低。

---

自托管策略与网络暴露

• 核心缓解措施：保持系统更新（通常通过无人值守的安全升级），使用容器/虚拟机/沙箱进行隔离，并避免不必要地暴露服务。
• 许多自托管者现在把所有内容都放在 VPN 或零信任式覆盖网络之后（Wireguard、Tailscale、ZeroTier、Cloudflare Tunnels，以及类似工具），有时再叠加 mTLS 或 HTTP 基本认证作为额外一层。
• 建议还包括不提供 dotfile、将管理面板限制在不显眼的路径下，以及把日志发送到主机外以便取证。

---

凭证填充与认证加固

• 大规模凭证填充活动可能涉及 10 万以上的 IP，这使得按单个 IP 封禁变得无效。
• 报告中的缓解措施包括：
  • 按 IP、用户名和密码进行速率限制。
  • 主动识别并重置泄露的密码，并封禁常见的已泄露密码。
  • 让认证检查成本低且可扩展；对明显攻击流量快速截断，但计时行为要尽量接近正常请求。
  • 在遭受攻击时动态启用额外的认证要求。

---

证书透明度与发现

• 多个报告指出，在获取 Let’s Encrypt 证书后不久扫描量会激增，这意味着攻击者在监视 CT 日志寻找新域名/子域名。
• 一些人的缓解方式是：在暴露前先加固、使用通配符证书或内部/自签名证书，或者将内部证书与面向公网的代理分离。
• 文中提到 crt.sh、certstream 和各种 CT 查询工具，可用于监控自己的外部足迹。

---

安全哲学与“通过隐蔽实现安全”

• 普遍共识是：先快速修补并遵循最佳实践；日志更适合事后分析，而不是过度纠结每一次探测。
• 强烈支持纵深防御：防火墙/VPN、隔离、WAF、监控和良好的认证，以及公网系统与内部系统之间的分段。
• “通过隐蔽实现安全” 仍有争论：单靠它会被否定，但许多人认为隐蔽性（非标准端口/路径、隐藏服务）作为次级层次很有价值，可以减少路过式噪音。