Hacker News Reader

Comment by leeoniya | Hacker News Reader

it cuts down the drive-by noise by 97%. which lets you not overlook anomalies in the remaining 3%.

we also had a bunch of scanners probing for common php scripts on the http server (we don't run php). simply returning a 404 header and disabling logging in nginx for \.php$ uris cut down a bunch of garbage (mostly from China). additionally, using ngx_http_limit_req_module reduced the effects of numerous DoS-type scanners.

so far, this + iptables for only 80/443/ssh has been a superior solution to instaling fail2ban that continually scans bloated log files and performs constant iptables banning/unbanning foo.

clean logs are essential, not just nice to haves.

View on HN

Well said.

"Log noise" is a legitimate security concern all by itself. It is actually disappointing how rarely it is discussed, and how in this world of "AI everywhere" there's no great smart AI log analysers to reduce the signal:noise.

Moving the SSH port might "only" reduce noise, but that's a legitimate security goal in its own right.

> "Log noise" is a legitimate security concern all by itself. It is actually disappointing how rarely it is discussed, and how in this world of "AI everywhere" there's no great smart AI log analysers to reduce the signal:noise.

That's because after many people learn about not using "security through obscurity" they apply the rule without thinking as if obscurity never has any benefit for anything.

That's because people can't agree on what is or isn't valuable.

For instance, if I (or my software anyway) see a bunch of sshd login attempts from some IP, and then that IP decides to try imap ... yeah, that's getting insta-blocked.

And that's hard to do if you decide to just ignore the sshd attempts.

Could additional honey pot on 22 help? Run sshd on non-standard port and honey pot on 22. Then automatically ban all the hosts that would connect to it. There could be a concern for a mistake, so then ban for limited time at first or something.

Nothing externally accessible should allow password login at all.

SSH key-based logins are so much more secure and convenient as heck once you invest the time to learn how they work.

For PCI you still need two factor. Its overkill, but we kept password logins even after having keys.

A smartcard is still fairly convenient and allows you to tick the two-factor box (card + pin)

What about tarpitting known spurious attacks? Possibly proxying/forwarding to a different host?

Reply on news.ycombinator.com