I looked through attacks in my access logs

Routine Internet Scanning and Attack Patterns

• Most “attacks” in logs are low-skill, fully automated scans hitting every routable IP, often with canned payloads for old CVEs (.env leaks, Shellshock, Wordpress/PHP paths, etc.).
• Many tools simply hammer servers without checking responses; sometimes repeated from the same static IPs or ranges.
• Several people conclude that if you follow basic security practices, these probes don’t matter; if you don’t, they also don’t matter because you’re already vulnerable.

---

Fail2ban, SSH, and Basic Host Hardening

• Fail2ban is used mainly to cut log noise and reduce brute-force attempts; others say it’s outdated, resource-heavy, and ineffective against IP rotation.
• Common SSH advice: disable password auth, use keys only, optionally move off port 22, limit source IPs, or put SSH behind VPN/bastions/“dark” access.
• Some rely on iptables/nftables rate limiting or port knocking instead of fail2ban; IPv6-only SSH with IPv4 firewalled is another tactic.

---

WAFs, Cloudflare, and Trade-offs

• Some recommend AWS WAF, Azure WAF (OWASP rules), or Cloudflare’s free WAF to filter obvious attacks and meet compliance.
• Strong warnings: default rules often break legitimate traffic (blocking certain request bodies, missing User-Agent, file uploads with metadata, long URLs). Best practice is “count mode” first, then gradual blocking.
• Critics argue WAFs give a false sense of security, are bypassable, add latency, and can block researchers or Tor users; supporters see them as a useful band-aid, not a substitute for secure apps.
• Concerns are raised about centralizing traffic behind large providers like Cloudflare, but others note alternatives and relatively low lock-in.

---

Self‑Hosting Strategies and Network Exposure

• Core mitigations: keep systems updated (often via unattended security upgrades), use containers/VMs/jails for isolation, and avoid exposing services unnecessarily.
• Many self-hosters now put everything behind VPNs or zero-trust-style overlays (Wireguard, Tailscale, ZeroTier, Cloudflare Tunnels, similar tools), sometimes with mTLS or HTTP basic auth as an extra layer.
• Suggestions include not serving dotfiles, restricting admin panels to obscure paths, and shipping logs off-host for forensics.

---

Credential Stuffing and Authentication Hardening

• Large-scale credential stuffing campaigns can involve 100k+ IPs, making per-IP blocking ineffective.
• Reported mitigations:
  • Rate-limit by IP, username, and password.
  • Proactively identify and reset leaked passwords and ban common leaked ones.
  • Make auth checks low-cost and scalable; short-circuit obvious attack traffic but mimic normal timing.
  • Enable extra auth requirements dynamically under attack.

---

Certificate Transparency and Discovery

• Multiple reports that scanning spikes shortly after obtaining Let’s Encrypt certificates, implying attackers watch CT logs for new domains/subdomains.
• Some mitigate this by: hardening before exposure, using wildcard or internal/self-signed certs, or separating internal certs from public-facing proxies.
• Tools like crt.sh, certstream, and various CT query tools are mentioned for monitoring your own footprint.

---

Security Philosophy and “Security Through Obscurity”

• Consensus: patch fast and follow best practices first; logs are more useful for post-incident analysis than for obsessing over every probe.
• Strong support for defense in depth: firewalls/VPNs, isolation, WAFs, monitoring, and good auth, plus segmentation between public and internal systems.
• “Security through obscurity” is debated: relying on it alone is condemned, but many see obscurity (nonstandard ports/paths, hidden services) as a valuable secondary layer to reduce drive-by noise.