Show HN: A proactive way of securing your Linux server

Re:Show HN: A proactive way of securing your Linux server by netsectoday on Friday September 04, 2020 @12:27AM (#24371700)

Collecting bans isn't a good thing today with the scale of background noise malicious behavior. You will very quickly collect thousands of IP addresses doing this and need to implement ipset - an iptables plugin that allows O(log n) lookup time on a list of IP addresses.

Another issue; the overlap between SSH scanners also running HTTP/S attacks is negligible.

From experience; what makes sense is shifting your SSH port away from 22, disabling password based authentication, whitelisting your IP address from your cloud provider's firewall, and still aggressively auto-banning incorrect logins with fail2ban.

Then, for good measure, implement a WAF to protect your HTTP/S traffic as well.

Do not turn your production system into a honeypot. Only do this with a separate system that contains no valuable data.

[ Parent | on HN ]

Re:Show HN: A proactive way of securing your Linux server by appletrotter on Friday September 04, 2020 @01:28AM (#24371972)

Why can't there be an O(1) iptable? Just a hashmap?

[ Parent | on HN ]

Re:Show HN: A proactive way of securing your Linux server by wokkel on Friday September 04, 2020 @05:23AM (#24373250)

For IPv4 it can be done, but it would take at least 512Mb of kernel memory. A hashmap would be inefficient in that case, just use a bit-array. For IPv6 however, you run out of memory with a bit-array. Using a dynamically allocated hashmap in the kernel in that would help the initial allocation, but then you can easily be DOS'ed by having a lot's of banned access and running out of kernel memory.

[ Parent | on HN ]