Do you have a linux server and do you know how to reduce acquiring hacked? In this movie we will critically focus on a couple finest practices. The video can be summarized as: “a lot of fluff, not considerably use”.
Participate in all around with Linux and get 100$ Credit history for Linode*:
Like to read? Blog site post edition:
Pretty scientific analysis:
Other Opinions:
– Empower unattended updates:
Chapters:
00:00 – Intro and Motivation
01:47 – 1. Disable SSH Password Login
03:47 – Detour: Password Login for Sites (https)
04:39 – Password Recommendations
05:33 – 2. Disable Direct root SSH Login
07:07 – Producing user and increase to sudo
08:47 – 3. Alter Default SSH Port
10:42 – 4. Disable IPv6 for SSH
13:40 – 5. Set up a Standard Firewall
15:43 – 6. Unattended Server Automobile Up grade
19:04 – Summary
-=[ 🐕 Social ]=-
→ Twitter:
→ Website:
→ Subreddit:
→ Fb:
-=[ 📄 P.S. ]=-
All one-way links with “*” are affiliate inbound links.
Little late but I stil thought to throw
In my 2 cents.
1. “Disable password login”, we do this for 2 reasons. Firstly a key is longer than most passwords, making bruteforcing harder to do.
Secondly, you can’t really “mistype” a key, making it easier to implement (temp) ban policies for sources using a wrong key (after for example 3 tries). We basically eliminated the human factor from the with proces as soon as the key is Send.
You are correct that it’s as secure as HTTPS.
But it does have a security angle.
2.”disable direct root login” the mean reason to disable this is for auditing and management. (It also removes 1 know user from the attack surface). This is part of security in layers. (So It has a security angle). Also a sudo root is almost the same as root, except for a few edge cases. The main difference to go with sudo is that it can easily by logged and audited.
3.”change ssh port” the only reason to do this is for less traffic on the ssh server. “Anything can be hacked” is mainly to realize there is no perfect security that keep everyone out but authorized people. You also are a little bit protected from unknown attacks on the ssh binary that could be used by anyone scanning the internet for vulnerable servers.
4.”Disable IPv6” is only useful in the rare case you will never use it… (not having something active you don’t use tightens the security ever so slightly. I don’t use this nor would I recommend it to anyone.
It’s a older recommendation to disable ipv6 from a time many end users could not use it without special setup. (Over 10 years ago)
4.”add Firewall” are a good thing. But there complex beasts. For most servers and people just starting out I would recommend “ConfigServer Security & Firewall (csf)” it has advanced features like watching logs file for failed logins and such. And it blocks most outbound connections just like inbound.
5.”auto update” on Linux are only for Security updates. If you want to do it for other updates you must configure this yourself.
I agree it’s hard (and getting harder) to learn why we do things in Security (or InfoSec). These sources you found for these recommendations indeed are striped of all reasoning and copy of each other (or use obsolete and outdated reasoning)
Just my 2 cents.
I do run my small home server with some non important files and I did find these tips useful. But I do have an excuse for running SSH in a different port than 22, since on port 22 I run EndleSSH, an small SSH tarpit, and some of those bots which have tried bruteforcing the login of my server have stopped attacking me after I implemented that tarpit, since they are too stupid to look for the other hidden SSH port. Maybe make a video about EndleSSH and see if it's either good or bad for a server.
I put SSH on high port – even with using keys only. Not for security but against annoyance. I don't get my log filled with false password attempts.
hold on. by blocking connections to all ports except the ones you want to run services under would block connections to a typical netcat remote shell launched on the server by some exploit. thats exactly the reason it makes sense, to mitigate userspace programs listening on ports and some nobody-process running a server. or you install some dependency and systemd decides you need an ntp server now suddenly your machine is taking part in reflection attacks ddosing for some botnet and racking up your server bills. and now you have to pay for some terabytes of traffic because some ubuntu-on-linode-sponsored-by-linode-yourube-expert told you blocking ports is useless because of some holes in some paper sheets.
stop this wrong and potentially harmful "you achieve nothing" bullshit.
8:46 He's so right. I'm going to change my SSH back to port 22, because I love to have my CPU cycles consumed and logs overflowed by brute-force attempts from Chinese IPs.
Disabling root login and using sudo forces an attacker to guess the username as well as password. Also use fail2ban to mitigate brute force attacks.
such nonesense…
NO NO NO NO, You honeypot your whole network. From routers to servers to phones to laptops. Make common mistake vulnerability into honeypot, not too easy not too hard. Proper Virtual Computer auditing monitoring software and BANG!!!!
Removing/Disabling root user eliminates a commonly brute forces account from eager intruders. Swapping to something more obscure that is unlikely to be brute forced is safer.
But you are correct, it doesnt magically make the server MORE secure. Just makes it less likely to be a target.
I always thought that you don't want root on ssh, because than it's harder to guess where to bruteforce or somth else. So just obscure things.
I paused, and I am sure I am like the 200th to mention that, but ssh keys are not just for convenience. They follow the security by design pattern. Meaning, the connection is technically not established when you fuck up security. Contrary to a password, where you could just choose a weak password. Granted, use RSA with <2048 bits, ED25519 <100 rounds or some of the outdated algorithm and this security by design falters, but hey, it was the original idea. I need to check if sshd allows me to limit the algorithms and key lengths allowed. Added to my TODO list…
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.
Finally someone has a brain and can use commonsense exposing the retardation in the IT community
With regards to SSH, maybe whitelisting only your IPs is a good idea? Granted, you'd need to have a static IP and not need to access the server remotely.
You can make the private key password protected, so you have to type a password the first time you are connecting after starting connection
I just wait to see news that trusted password managers used by millions are catched on stealing passwords for a year or longer
One thing about the Key vs Password debate is that it's easier to brute force a password when using a bot that scans IP Blocks for exposed port 22 and attempts to brute force!
There are two advantages to using sudo.
First, it is as much about being aware at a command level what privileges you have. As you clearly state, security depends on using the minimum security you need for any given situation. Even if you as a user may need some root privileges, it does not mean that every command you execute needs to be executed with root privileges, so it prevents a rogue command (e.g. an executable that has been compromised) from doing anything bad is that command does not actually need to to have root privileges.
Secondly, there are definitely things you may want to do on a server that does not need root privileges. It is true that you may want to start or stop a service, and that requires root privilege, but you may simply want to look through a log file, and this may not need root privilege.
I am so with you on the views on security best practices. I would even add, that following security recommendations without understanding what specific change solves or if it possibly opens some other weakness, is dangerous.
I love this video. Thnx!
You are right in that a lot of these don't mitigate the root cause, but one important thing to realize is that humans make mistakes. Setting up a firewall is useful if you didn't properly configure your system and have a few additional services running that shouldn't be listening. Disabling password login fixes an issue where you've leaked a re-used password. So on and so forth.
These techniques are mitigations for if you've already messed up elsewhere. Security in layers. Try to address the root security concerns, but understand that you aren't perfect and may have misconfigured things, so add a layer to mitigate that potential problem too.
your linode plug made me finally get a credit card, so gg I guess?
Achtung! 15:12 Firewall: Nichts für ungut aber besser da läuft eine Firewall wie dass durch eine Sicherheitslücke einer Applikation des Webservers Shell shoveling etc. ausgenutzt wird. Wenn der Systembenutzer des Webservers (privilegierte) Ports öffnen darf wird dir die Firewall dein Popschi retten da dieser Benutzer ganz gewiss keine Berechtigung hat um die Firewall zu verändern 😉
1. Why even give an attacker the ability to log in with a password? I think disabling it just adds another layer of security.
2. Yeah, getting rid of the root user login is pretty good too so the attackers dont know a valid login name.
3. Scanning the whole ip4 address space is fast, finding a random port in 65k possiblities for one user is slower.
4. nothing to add there lol
5. denying ports actually gives a different response if you try to ping it on 80 for example so it might even prevent a shitty script from finding your server
6. nothing to add here
thoughts?
No tech expert here, just starting my apprentice ship. Would love some insight because thats how I thought the stuff works.
I think like me, many self-taught web developers watch your channel. Unfortunately, 80% of your content seems unreachable without a CS degree or I do not know which kind of education. But I keep watching, maybe insisting I will understand better in the future all the tech things you bring on your hacking videos.
What browser or extension is he using for this kind of dark mode? I have noticed this recently in many youtube videos but can't seem to find it
This video is the exact reason why is to so long to set up my rig. Didn't trust some of the info I was getting. Pays to do your hw and be a little paranoid. Great video.
Private keys have another use: If not set properly (a.k.a. fail2ban etc.), password auth enables hackers to "bruteforce" your pass. They may not make it work, but they'll choke your bandwidth and/or resources (especially with the cheap $5 VPS options).