You can’t really disable the root user. You can make it so they can’t login remotely, which is highly suggested.

You can’t really disable it anyway.

Hardening is mostly prevent root login from outside in case every other layer of authentication and access control broke, do not allow regular user to su/sudo into it for free, and have a tight grip on anything that’s executable and have a setuid bit set. I did not install a system from scratch in a long time but I believe this would be the default on most things that are not geared toward end-user devices, too.

I’m interested, how do you expose your services (on your PC I assume) to the internet through wireguard? Is it theough some VPN?

Endlessh and fail2ban are great to setup a ssh honeypot. There even is a Prometheus exporter version for some nice stats

Just expose endlessh on your public port 22 and if needed, configure your actual ssh on a different port. But generally: avoid exposing ssh if you don’t actually need it or at least disable root login and disable password authentication completely.

https://github.com/skeeto/endlessh https://github.com/shizunge/endlessh-go https://github.com/itskenny0/fail2ban-endlessh

If it is your single purpose to create a blocklist of suspect IP addresses, I guess this could be a honeypot strategy.

If it’s to secure your own servers, you’re only playing whack-a-mole using this method. For every IP you block, ten more will pop up.

Instead of blacklisting, it’s better to whitelist the IP addresses or ranges that have a legitimate reason to connect to your server, or alternatively use someting like geoip firewall rules to limit the scope of your exposure.

I disabled ssh on IPv4 and that reduced hacking attempts by 99%.

It’s on IPv6 port 22 with a DNS pointing to it. I can log into it remotely by hostname. Easy.

Since I’ve switched to using SSH keys for all auth Ive had no problems I’m aware of. Plus I don’t need to remember a bunch of passwords.

But then I’ve had no training in this area. What do I know

The other poster gave you a lot. If that’s too much at once, the really low hanging fruit you want to start with is:

• Choose an active, secure distro. There’s a lot of flavors of Linux out there and they can be fun to try but if you’re putting something up publicly it should be running on one that’s well maintained and known for security. CentOS and Debian are excellent easy choices for example.

• Similarly, pick well maintained software with a track record. Nginx and Apache have been around forever and have excellent track records, for example, both for being secure and fixing flaws quickly.

• If you use Docker, once again keep an eye out for things that are actively maintained. If you decide to use Nginx, there will be five million containers to choose from. DockerHub gives you the tools to make this determination: Download number is a decent proxy for “how many people are using this” and the list of updates tells you how often and how recently it’s being updated.

• Finally, definitely do look at the other poster’s notes about SSH. 5 seconds after you put up an SSH server, you’ll be getting hit with rogue login attempts.

• Definitely get a password manager, and it’s not just one password per server but one password per service. Your login password to the computer is different from your login to any other things your server is running.

The rest requires research, but these steps will protect you from the most common threats pretty effectively. The world is full of bots poking at every service they can find, so keeping them out is crucial. You won’t be protected from a dedicated, knowledgeable attacker until you do the rest of what the other poster said, and then some, so try not to make too many enemies.

Paranoid external security. I’m assuming you already have a domain name. I’m also assuming you have some ICANN anonymization setup.

This is your local reverse Proxy. You can manage all this with a container called nginx proxy manager, but it could benefit you to know it’s inner workings first. https://www.howtogeek.com/devops/what-is-a-reverse-proxy-and-how-does-it-work/

https://cloud9sc.com/nginx-proxy-manager-hardening/

https://github.com/NginxProxyManager/nginx-proxy-manager

Next you’ll want to proxy your IP address as you don’t want that pointing to your home address

https://developers.cloudflare.com/learning-paths/get-started-free/onboarding/proxy-dns-records/

Remote access is next. I would suggest setting up wireguard on a machine that’s not your webserver, but you can also set that up in a container as well. Either way you’ll need to punch another hole in your router to point to your wire guard bastion host on your local network. It has many clients for windows and linux and android and IOS

https://github.com/angristan/wireguard-install

https://www.wireguard.com/quickstart/

https://github.com/linuxserver/docker-wireguard

Now internally, I’m assuming you’re using Linux. In that case I’d suggest securing your ssh on all machines that you log into. On the machines you’re running you should also install fail2ban, UFW, git, and some monitoring if you have the overhead but the monitoring part is outside of the purview of this comment. If you’re using UFW your very first command should be sudo ufw allow ssh

https://www.howtogeek.com/443156/the-best-ways-to-secure-your-ssh-server/

https://github.com/fail2ban/fail2ban

https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands

Now for securing internal linux harden the kernel and remove root user. If you do this you should have a password manager setup. keepassx or bitwarden are ones I like. If those suck I’m sure someone will suggest something better. The password manager will have the root password for all of your Linux machines and they should be different passwords.

https://www.makeuseof.com/ways-improve-linux-user-account-security/

https://bitwarden.com/help/self-host-an-organization/

https://keepass.info/

Finally you can harden the kernel

https://codezup.com/the-ultimate-guide-to-hardening-your-linux-system-with-kernel-parameters/

TLDR: it takes research but a good place to start is here

https://www.digitalocean.com/community/tutorials/recommended-security-measures-to-protect-your-servers

I shared it because, out there, there is a junior engineer experiencing severe imposter syndrome. And here I am, someone who has successfully delivered applications with millions of users and advanced to leadership roles within the tech industry, who overlook basic security principles.

We all make mistakes!

questionable?

Do not allow username/password login for ssh

This is disabled by default for the root user.

$ man sshd_config

...
       PermitRootLogin
               Specifies whether root  can  log  in  using  ssh(1).   The  argument  must  be  yes,  prohibit-password,
               forced-commands-only, or no.  The default is prohibit-password.
...

Why though? If u have a strong password, it will take eternity to brute force

If it’s public facing, how about dont turn on ssh to the public, open it to select ips or ranges. Use a non standard port, use a cert or even a radius with TOTP like privacyIdea. How about a port knocker to open the non standard port as well. Autoban to lock out source ips.

That’s just off the top of my head.

There’s a lot you can do to harden a host.

Looking at ops other comment, weak password and no fail2ban

glad my root pass is toor and not something as obvious as password123

By allowing password login and using weak passwords or by reusing passwords that have been involved in a data breach somewhere.

That’s incredible, I’ve got the same combination on my luggage.

The one db I saw compromised at a previous employer was an AWS RDS with public Internet access open and default admin username/password. Luckily it was just full of test data, so when we noticed its contents had been replaced with a ransom message we just deleted the instance.

• The default ssh port moved if ssh has to be exposed to the Internet. No, this doesn’t make it “more secure” but damn, it reduces the script denials in my system logs, fight me.

Gosh I get unreasonably frustrated when someone says yeah but that’s just security through obscurity. Like yeah, we all know what nmap is, a persistent threat will just look at all 65535 and figure out where ssh is listening… But if you change your threat model and talk about bots? Logs are much cleaner and moving ports gets rid of a lot of traffic. Obviously so does enabling keys only.

Also does anyone still port knock these days?

Good point about a default deny approach to users and ssh, so random services don’t add insecure logins.

Lol! Honeypot or just bored?

I search commits for “removed env file” to hopefully catch people who don’t know how git works.