- Moving ssh to a nonstandard port probably isn't worth the hassle. I need to do some actual statistics on this, but I think that if you disable remote password login, and set up fail2ban or equivalent for port 22, that's more than good enough, unless you're a hyperscaler, in which case you probably have a separate control-plane network interface anyway.
Discussion
Loading...
Discussion
- Turn off memory overcommit.
- Moving ssh to a nonstandard port probably isn't worth the hassle. I need to do some actual statistics on this, but I think that if you disable remote password login, and set up fail2ban or equivalent for port 22, that's more than good enough, unless you're a hyperscaler, in which case you probably have a separate control-plane network interface anyway.
- fail2ban is most definitely worth it, but other firewalling has a good chance of being more trouble than it's worth. In particular, I wouldn't bother with dropping instead of rejecting SYNs to closed ports, and I'm dubious about firewalling by port number. (About the only thing that's good for, IMO, is putting an extra speed bump in front of an adversary who already has remote execution and wants to persist it.)
- The biggest single thing you can do to protect yourself against privilege escalation into the kernel is to use a monolithic kernel. (There are a bunch of other places that you need to tweak if you want to be really sure no one can ever inject code into supervisor mode, but without CONFIG_MODULES=n or equivalent they're all pointless.) It's a damn shame that current Linux distros make this so hard.
- Closely related to 7: The sheer complexity of Linux's various "mandatory access control" modules - SELinux, AppArmor, etc - leads me to believe that most people are better off not only not using them, but configuring them out of the kernel.
I don't know what the *BSD equivalents are, or if they even have any, but if they do I suspect they're equally complex, because the people who want this feature have complex needs.
- Don't bother with "secure boot" or with encrypted disks. The only threats these protect against, that are relevant to normal people, are the "malicious hotel staff" and/or "laptop thief" attacks, which are moot for a server. And the risk of bricking the system is very real.
bonfire.cafe
A space for Bonfire maintainers and contributors to communicate
Automatic federation enabled