How To Protect Your Linux Server From Hackers!

Do you have a linux server and do you know how to prevent getting hacked? In this video we will critically discuss a few best practices. The video can be summarized as: "a lot of fluff, not much use".

Other Opinions:

Chapters:
00:00 - Intro and Motivation
01:47 - 1. Disable SSH Password Login
03:47 - Detour: Password Login for Websites (https)
04:39 - Password Recommendations
05:33 - 2. Disable Direct root SSH Login
07:07 - Creating user and add to sudo
08:47 - 3. Change Default SSH Port
10:42 - 4. Disable IPv6 for SSH
13:40 - 5. Setup a Basic Firewall
15:43 - 6. Unattended Server Auto Upgrade
19:04 - Conclusion

-=[ 🐕 Social ]=-

-=[ 📄 P.S. ]=-

All links with "*" are affiliate links.

[spacewolfjr]

Better advice: turn your screen brightness waaaay down, hackers always wear sunglasses so they'll have a hard time reading your screen!!!! Also turn the heat up because you'll sweat them out of their hoodies.

[tanmay______]

I liked the advice- “Don’t take security advice as the unquestionable truth- always dig deeper to know why”

[NetworkChuck]

Great video 👍

On the firewall, I think using this as an extra protection mechanism is viable for some servers (especially lab servers). You may be installing new tools on the regular and you may forget (or don’t realize) a service is listening on a port. The firewall has your back.

[jasonw]

I could rant about this "security by obscurity" situation all day. Largely throughout infosec you'll find that security needs to be broken down into organizational risk. Obviously, changing the port number of an otherwise vulnerable service will not increase the security. However, the organization risk decreases a nontrivial amount because the service's exposure to attacks is lowered. If an 0day gets released and starts getting exploited in the while, I expect that person whose SSH service is listening on port 1352 will be one of the last to get hit, and that time differential could be the difference in whether or not your incident response plan initiated.

I will admit that as a security professional, you should not conflate decreased exposure with increased security, but rather decreased risk. I agree with the sentiment, and this is a good video with points that should not be taken lightly.

[skyracer-mkhg]

That firewall analogy was absolutely gorgeous haha.

[squelchedotter]

Yes, so glad you made this video! I've had to explain this to people so many times.
I would personally recommend enabling a firewall with default deny though, as it prevents accidentally exposing things through misconfiguration.

[rashidxd]

Not logging in as root as a practice has fewer things to do with security but more with auditing. If someone deletes something, you'd know who did that. Also, it's the best practice because running everything as root is dangerous. Using sudo gives you a bit of time to think about what you're doing as well.

[ssiannas]

You should turn this into a "Setting up a Linux server" series where you could also show how the basics are done while at the same time debunking common misconceptions like the ones in the video.

[ganzsichertobi]

The point with the firewall: It is sadly not that uncommon to misconfigure your server and expose things you shouldn't. (Because default settings are often to listen on all interfaces, and on several linux distros things start the moment they are installed)

So enabling the firewall, makes it a lot more intentional which services can be accessed, (I speak from experience here, I had a few emails from BSI addressing those issues over the years)

[DJRH]

As an IT-Systems Admin myself I can confirm => 'Dig deeper' is really the best advice you get when it comes to any IT related subject. Thanks for the great video!

[YandiBanyu]

"And look at that! They match!". I laughed so hard at that

[JohnHollowell]

Changing the port can help "protect" against scripts. While this is not a big security feature (they can easily nmap to find the new port), it can reduce bandwidth of automated attacks attempting to SSH into your servers. This isn't any more secure, but can lessen the DOS effect of some novice brute force attempts.

[NoNameBAM]

lmao at the IPv6 advice, I love not being able to access my server via SSH when my provider's IPv4 dies once in a while due to the whole DS-Lite mess

[poly_nerd]

Thanks! Also loved the networking related videos!

[VeinX]

I always understood SSH root login disabling as a way to make brute forcing even harder - if root login is enabled, then username is already known. If your username is different, then attackers also would have to guess it. And they're trying, look at your auth.log after you allow the connection from the web.

[_CryptoCat]

I guess LiveOverflow learnt how to secure his server to stop other youtubers taking over 👀😅

[NA-nrfb]

Point 3. Change default port address,
By changing we can avoid so much of unwanted traffic, that is just trying to bruteforce weak password. (literally there are thousands of request daily from botnets etc)

"Wouldn't that help in someway to avoid unwanted bandwidth withdrawal"

PS: I love your content <3 :)

[kaelchan]

Yes, best practices are written for dummies who never ask why. How you implement the tech is often what causes the most headaches. Thanks you for the video!

[Simon-qgqn]

I agree with almost all of this. Just 2 things:
- SSH keys introduce a second factor. You need the password for the key and the Key itself. So stealing the key form your computer doesn't help and brute forcing your passwort doesn't help. You need to steal the key, then brute force the password.
- Disable root access helps because it's a well known account name. A custom user ist basically another secret in addition to the password. An attacker has to guess your username and your password not just the password.

[SorFig]

I'm a self-taught programmer and after 5years of doing it professionally now, I whole-heartedly agree with a lot of what you've said. There's a lot of snake-oil and fear-mongering in security. You must always be security conscious, but many risks can be mitigated with very basic tools. Docker containers are an example of something that can also help boost security. Your services' ports aren't automatically exposed to the internet, and even if an attacker gets into a container they only have access to the volumes mounted in the container. You'll want a server with at least 1Gb of RAM to be on the safe side, though.