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.
I think this could be generalized to advice in general "Don't take advice as the unquestionable truth -- always dig deep to know why... but listen to your Mom"
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.
I was about to write the same thing: it really comes down to how one uses a server and how consistent they are with getting configuration right. On one hand a firewall can definitely help protect from misconfigured services, but, on the other hand, it can lead to an admin being lazy because "I have a firewall". If there is nothing running, there is nothing to break and/or attack.
In the machine i use for www and dns i have a toon of stuff and it is binded to 0.0.0.0 so is good for me, and is the ssh keys a good idea to not force the use of them?
@@raxxer1234 I get it what you're saying, but the example was about "securing a Linux server", i.e. one machine with firewall and server software on it. In that case, if one is careful about what they install and how they configure it, then having a firewall or not makes little difference in terms of actual security (as demonstrated by holes in the two paper sheets): in order to provide the (publicly accessible) services, one would have to open the same ports on the firewall anyways. When a firewall comes in handy is when it is run separately (like you were mentioning) or if one wants to test lots of software without caring about proper configuration (but I'd say that that's not a good way to do things on a publicly accessible machine).
@@tHe0nLyNeXuS I definitely agree. While I wouldn't go as far as to say that closing ports on a firewall is "snake oil," I would say that its often advertised as something you "must do." I think of it more as a safety net when you're walking a tightrope--I'm glad its there, but I really really really don't want to have to test the effectiveness of the safety net.
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.
The best example of security by obscurity that I can think of is GSM. That too is being broken piece by piece by open source initiative such as osmocomm
Exactly. Especially if you know you have a disproportionate number of skids targeting your site, changing as many ports as possible away from default can help a lot. Plus, doesn't it just feel nice to have the page for your IP on shodan be as short as possible?
@@bruhdabones that’s why you perform a threat assessment BEFORE building, who is targeting you, what are the more common TTP’s they use and how can you mitigate those to reduce risk.
I do use the "security by obscurity" thing, since I did find it to be successful overall with SSH bots. On port 22 I run EndleSSH, which for the ones who don't know it's an SSH tarpit. Before running EndleSSH, i did have my SSH server on port 22 and I remember in the system log that every 30 minutes, some random bot would try to bruteforce the login. I kinda got tired of seeing that, so I decided to add EndleSSH on port 22 and then hide my SSH port, and so far, none of the bots have even tried looking for that hidden SSH port.
@@patrickgrady7505 how would it? The SSH port would have to be open for you to connect there anyways. People change the ssh port to avoid automated exploits against ssh or password brute forcing.
@@skyracer-mk8hg sorry I am new to this because I am trying to make a web server from my raspberry pi. Say I change the ssh port and use the firewall analogy, would the holes still match? Appreciate your feedback btw. I am probably just overly paranoid about protecting my stuff.
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.
Disabling direct root login does add an extra layer of security. It basically doesn't allow an external attacker to directly attack the root account via brute force or key compromise. In order to achieve root access, attacker would first have to compromise a normal user and then target root access. So I think there is definitely some aspect of security to it.
When running commands as a normal user without sudo, it will tell you that you don't have the privilege to run that command. That is an alert and another chance for you to revise your command. Even when you type sudo ahead of time, just it being there means you're running something as "root" which creates a little bit of awareness in you. Also, running sudo will be always logged and you can view who ran commands as "root".
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)
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.
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.
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!
I'm a sysadmin as well and totally agree. Hate working with people who just do something without thinking why they're doing it or why it's done that way, even if they're doing everything correctly!
What do you recommend I dig deeper in if I want to make a server really secure. My background is not IT but rather hardware and software engineering, nevertheless, I'm really interested in knowing how to run my own home server. I don't need military-grade security but I definitely like to learn how to make it very secure. Particularly, if setting an user and giving it root privileges doesn't do anything, what's the best way of accessing my server?
@@m4l490n I'd start on the basic security of the web site itself, as that is rather easy to do and if you're a software programmer, probably also easier in itself. Parameterized queries takes away any attack surface through user inputs on SQL for example.
@@m4l490n Start out by using external hosting first and let them take care of server security, then focus mainly on the web site security (and do a lot of logging). When you're confident, you can move on to setting up your own server.
It's not the same though. You get different output in port scanners when scanning a blocked port or an open port just with no service listening on it. A server without any firewall may be more interesting for those "automated" scanners and script kiddies and hobby hackers and else. I mean, I did laugh hard as well though. Not wanna imply questioning "assumed best practices" is a bad thing and yes, from a pure security perspective, there is no real difference within the security of that port, whether a firewall is blocking "nothing" or the port listening on "nothing". My point is, often it's not only about direct security issues. The appearance of a server may also be factor. If you knock on someones door, the way how the door is build may make it more or less attractive to kick the door open ;)
@@ko-Daegu Not sure if I get your point. "if you later opened something by installing an app that does that " - by installing an app that does that? Does what? You mean installing an app you don't know and that app likes to phone home without you knowing about this "phoning home" feature?
@@rantanplan178 No I mean the module I’m using opens or uses Venetian ports I would like to stay alerted 24/7 by firewall and I control what port the app opens Instead of assuming that my app only work with certain port maybe my app does but some liberate module or other integrated app doesn’t or have the capability that can be leveraged My English is shit never mind
@@ko-Daegu Nah your english is fine. As long as we understand each other, it's good enough. What is a "venetian port"? I don't think I've heard this term before. Anyways, I think we were both talking about the same thing. You talk about software you aren't sure what network activities it may execute. Well, in general I'd say don't use software you aren't sure what it's doing, especially not in production environments. However, there is our beloved Windoze or other proprietary software and you may not want to give them your entire network to play with. Therefore yes, using a whitelisting strategy on your network filters is certainly a good idea.
@@spacewolfjr It's the thing providers do nowadays to assign you a shared IPv4. But sadly, port forwarding is not possible through it, and sometimes it just randomly doesn't work. IPv6, on the other hand, is redirected directly to the outside internet. No need to forward ports, your machine is directly accessible.
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.
The same also goes for disabling password authentication on SSH in my opinion - almost nobody is out there brute forcing SSH keys, they rather focus on passwords
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.
I use a firewall to make sure that if I messed up a config of some internal service, it doesn't end up exposed to the internet. So basically, a last line of defense for wrong configuration.
@@fr0mage it's only his opinion, a couple hours of research won't make any youtuber a security expert lol. He completely ignored any risk assessment. The so called "snake oil" practice will protect your server from nearly all 0day bugs from automated attacks and so on.
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
Agreed, some time ago I had an SSH server exposed on the default port (was a temporary thing because i'm lazy) and sshd logs were full of failed requests, probably in the thousands of requests each day
I think it is a good reason to do so. The whole point of the video is : "Think about why you do it". For a hacker who tries manually, changing port does not close the attack window. Of course it allows blocking bot requests and script kiddies, and reduce unwanted bandwidth use.
Well using firewall to block ports except 80/443/22 is, if for some reason an attacker is able to start a process and bind it to a port via using vulnerability in a webapp, it prevents any further action on that port Also fail2ban is a very effective way to mitigate attacks, choosing the ban criteria carefully
I recently rented my first cloud ser er to play with hosting websites and some miscellaneous stuff, and was very anxious since I was totally unfamiliar with stuff and how to configure things securely And this video kinda quenched that anxiety a little ^^ I think a video series covering basic server setup stuff like this and maybe addresses common concerns and misinformation around it would be nice
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!
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.
Couldn’t agree more. I‘ve been doing what these guides suggest when I was like 15, but over some years I naturally questioned these tips and moved away from them. Except for SSH keys and no password auth, for the same reason you mentioned.
I came upon this video after watching a few others, and a lot of questions came to my mind watching those. after watching this video, i realized i was right asking those questions, and this video actually answered a lot of them. thanks
Even better, stick the private key on an external air-gapped device like a smartcard, or use U2F-based authentication for SSH, like YubiKey. The trouble with using SSH private keys that are stored on your main work device is that _that_ device may become compromised without you knowing, and then you're back to square one.
@@JivanPal But then we go to physical hacking where basically all bets are off right, someone could take your drives or installs a key logger. It's about someone somewhere trying to remote in where you don't have cameras and a guard dog.
@@Stoney_Eagle, not sure how you come to that conclusion. If your private key is on your laptop, malware from the internet is a threat. If your key is on a smartcard or you use U2F via YubiKey or similar, there is no threat unless someone takes that external device. In the first scenario, a _file_ is your second factor. In the second scenario, a _physical object_ is your second factor. The whole point of 2FA is that the second factor ought to be something you physically possess, not something that can be acquired remotely.
just a minor hint, cause i got it wrong for a long time as well: dist-upgrade is just a slightly differenty upgrade, it does something different in managing dependencies, but to upgrade to a new distro version, there exist special commands, e.g. sudo do-release-upgrade for ubuntu
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.
1. SSH Keys aren't 2FA, Yes you can password protect them but it is not required. 2. anybody can cat /etc/passwd and see all the user accounts that exist. As Liveoverflow mentioned, somebody can always just modify the bashrc file to execute whatever malicious command they want as root.
SSH on port 22 on a public server is a great idea if you like reading access logs. Changing SSH port and banning/blocking port scanning IPs is a good thing. A lot of arguments in this video felt pretty shallow, for somebody who wants to ”look deeper”.
Video was framed as John Doe renting a VPS for the first time. Chances they look at the access log? I would say close to 0. If someone got onto your Linux box, the logs would be the first thing to go in cleanup. Then you get into log aggregator territory and suddenly it is a network.
This is why Chuck is one of the best out there. He's a dedicated learner. I'm subscribed to both channels and I learn a ton every time I open their videos.
For the firewall, I stopped midway so you might mention it later in the video. Something a firewall can do that just opening or closing a port can't is you can set it so it checks the connection source. So you can set it up so it'll only allow a connection to a given port from a given ip addresss like for example the local network, or even a specific ip on the local network. That's not really useful for a remote server unless you have a static ip at home or wherever you're accessing it from that you can restrict it to.
I would still recommend these „best practices“ to anyone playing around with servers at home, just because of crawlers and script-kiddies… Just to cut unnecessary load and bandwidth. The chance of someone having an eye on you and want to hack you is low, they rather go for companys, where they can get money
@@AnonYmous-spyonmepls Fail2Ban normaly only bans the IP Address from where the login attempts were made, you can still just login and ues your server normally.
@@AnonYmous-spyonmepls you'd have to try use invalid SSH keys or Passwords to get locked out/banned. if a attacker attacks your server HIS ip address will be banned, not yours.
It might be possible to use fail2ban to redirect the attacker ip to a tarpit on a different port after a number of failed attempts. That would be fun...
I think this was a good run down on the security aspect of hosting servers. I work in IT and one of the most important things is keeping an exposed program isolated to a specific user, and keeping that user from running other programs it's not supposed to. One method of securing systems I've been pretty fond of lately is using podman to host game servers and things like ftp servers. It's a docker alternative that leverages cgroups to run as a user on a per container basis. So in contrast, docker runs in the background as root, where podman runs only when you ask it to as a restricted user without root access. It's great for systems not using SELinux and you want to restrict the access. Ubuntu comes with AppArmor but I think this is more effective, and a lot of programs don't come with AppArmor profiles.
Disabling IPv6 is hilarious, I wish all ISPs would finally start supporting v6 so that you can disable v4 and get rid of bots scanning v4 addresses. Speaking of, changing SSH port is useful to reduce noise in ssh logs, and if you drop a honeypot/tarpit on port 22 you could instantly ban all the IPs from accessing the real port :) if for some reason you can't setup a whitelist on that port, anyway.
Wow just what I needed, I have been working on a project in my local network and wanted to deploy it. I have tried to search for advice on security, but as you said in the beginning never found anything good. This saves me!!!!
Putting the SSH on a high port is generally still a good idea IMO to filter out all the botnet traffic from the logs and to see if more sophisticated attackers or botnets are actually attacking your server, since most of the botnets only blindly hammer away on port 22, so IMO putting it on a high port IS still a security improvement, since your logs will be a lot clearer and will have a lot less junk traffic logged, meaning you can go through them with much more ease and possibly identify real attacks a lot easier. Sure enough, if someone is specifically targeting your server it'll act as security from obscurity, but you as a server owner will be able to identify these targeted attacks a lot easier from the logs this way.
You can filter out this patterns from logs, when it is not just passing by botnets and when, for example, somebody trying each password only once and then filter out groups of IP. But i think you need this information only if you have some kind of honeypot, i don't know why you need this if you just want working server :)
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.
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.
TBH if your server is running on HDDs I'd say changing the ssh port/using fail2ban is great. The amount of logs that need to be saved to disk is so huge and as we know HDDs have a very low number of IO ops. So I count leaving the default ssh port as DDOSing your own server LOL
Because every line of log is written immediately with no caching in place, as everyone surely knows. fail2ban is good, but not because of io operations.
I would say I somewhat disagree with your statement about changing default SSH port being snake oil. Changing the default SSH port won't give you extra protection, we can agree on that. But the reduced amount of requests to the port will make threat hunting and log processing a much more manageable task. You will in essence get much less "scanner" noise in your logs.
This video actually made me check what services are running on my server. And it actually made me install a firewall (ufw). I noticed that there is a mail service that I did not know about but apparently it's needed for some error message communication. Thanks to ufw, I don't need to figure out how to configure it to stop listening to external traffic. I simply allowed everything that I knew about in ufw.
Great content. Totally agree, as a cloud engineer who writes code to production directly in VPS through VScode ssh tunneling, ssh password is very convenient feature.
I think changing the SSH port and disabling root login are not unreasonable, given how little they cost to do, I mean they are essentially free. If you open an SSH server to the Internet on the default port, you quickly see a flood of login attempts from bots banging on the root user and possibly other common usernames. Changing the port reduces the bot traffic.
A firewall rule to limit the rate at which they can try passwords is a good thing to shut the bots up. I use a rule that allows only four connection attempts from an IP address in any one minute period and that seems to deter them quite effectively. I also use PKI and have disabled the root user and if they never even get an option to enter a password, that slows them down very effectively.
@@dingokidneys But basically, all of that trouble goes away when you just change ports. I never had any "1 million log-in attempts made since last time you logged in" since I started changing ports. I don't relly on it as some security measure, it's just annoyance removing measure.
7:06 Yes, it's different. When you log in as root, you only need one key/password. But when you have key auth and the user is sudo you NEED TO know both the key and the user's/root's password. Also you can only allow certain privileges, not the access to the whole system.
I love this video, man great explanation of SSH and passwords!! I am working on my domain server at home and working through all of the permissions and how to set things up is quite a task, but anyways love the video great job!!!
Quite frankly, I use ssh keys, no root and fail2ban because it reduces the attack surface and I'm unlikely to lock myself out. I had a VPS running for 2 weeks with standard config (strong root pw) cause I wanted to learn, but havent gotten around to setting it up completely. I found it with about 100MB just in logs from all the chinese bruteforce login attempts. I set up fail2ban but managed to lock myself out, cause typing passwords is hard. Then just switched to ssh keys for convenience. Tbf this is for my private playing around with server stuff nothing like production. But I still don't wanna be part of a botnet anytime soon lol
@12:00 - I've set up an entire scalable cloud by hand without using ready made AWS tooling. So to say that people who like to keep an ear to the ground about security ideas "aren't ready to set up a network" is just crass. If the person doesn't KNOW if they're ready, then they aren't. Nothing is ever 100% secure, that's true, but building things is how you get good. I'm still learning even after over 20 years of engineering.
But if you combine SSH keys and use sudo instead of root directly, then in order for an attacker to get root access they need to hack through two separate steps. Defence in depth.
Yes but no. If you set a strong password or use a SSH key, chances are they got in through a service. This would still require the password to be discovered or for priv esc to occur which is fairly trivial.
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.
Sudo actually have sudoers file, which allows you to execute special commands not all commands as root. Root allows you do everything sudoers limits this a lot and audit as you already mentioned Just to add love your videos very big fan
Is it just me or did the videos/examples become a bit more sarcastic lately? I really laughed at the firewall example :D While I am at it: Thank you very much for your great and educational content! I have learned a lot through the years just watching your videos and experimenting and got a much broader understanding of how things work "under the hood", which is just fascinating. It also led to me developing safer software in my day job and raising security awareness in my team. :)
Bruh this is like the 5th time I heard people pronounced it *"Odays"* instead of *"0days"* this week. What's happening? Have I've been pronounced it wrong all this time or what?
@@niter43 nah, apparently you can call it whatever you want, really. Some even says it "ohdays". ¯\_(ツ)_/¯ Many official publications from the reputable sources though still calls it Zero-day (0day).
I agree with you totally about using a different port. It is not a security measure. I forward port 443 on my router to port 22 on my server but my reason for doing so is that I can't get to port 22 from behind my work firewall. I can however get to port 443. As for not permitting 'root' ssh access, I agree totally with that as 'root' is a well known user and hence low hanging fruit for brute force attacks. I disable 'root' ssh access and actually disable the root account itself. That way all use of root like authorities and the user who made use of them is logged and I can check to see that no use was made of root permissions when they shouldn't be. Where you have multiple non-root users on the system, if you are breached, it gives you a clue as to the access point. I always disable ssh password access and use only keys because a) as you said they are quick and easy to use, and b) the key fingerprint is logged so I can detect if something weird is happening. The second is also why I set up a new key for each device that I connect from. IPv6 I'd agree is snake oil but I've disabled it on my router primarily because I don't know enough about it to manage it intelligently. That's some learning I have yet to do. I believe that default 'unattended-update' on Debian and Ubuntu will only apply security updates. That's the way they seem to work on my systems. I still have to go in and apply any functionality type upgrades if I want them. I've extended the default config to update my primary web browser so that I'm always using the latest and greatest available. As for firewalls, I've not used firewalls on my end-point systems for over 20 years. My NAT router manages access for me just fine. The only exposed port is forwarded to my hardened ssh server (keys only, no root access) and this has worked fine even though my logs show mass probing and frequent ssh login attempts. I did however recently add a couple of iptables rules to deter brute force attacks and DOS attempts. Probably not essential but makes me feel better.
I have to disagree on your first argument, because you made an important assumption, that the ssh-server is in the known hosts. But for new connections this is not the case, so if I make my first connection to the server on my machine, and someone would composmise my server by MITM or compromising my domain, he would gain access to my password. For the public key authentication, I do think the assumptions made in the documentation are very reasonable, as compomising the servers private key seems way more unlikely than someone MITM your connection. EDIT: Also your comparison to HTTPS is flawed, due to there being a certificate authority.
Keys are very convenient. But keeping backups of them offsite (say, Google Drive) and you'll likely be using an encrypted archive for them. Which is why having a few strong keyphrases for password managers, etc. are always good to have and remember. That way you can keep backups of the password database as well and it be secure. Yes, changing SSH port and tools like fail2ban are there for one reason: keep logs shorter.
On the topic of SSH, I would say it's much harder for an attacker to brute force a SSH key than it is to brute force a SSH password. I'd find someplace in the middle, like a password on your client's SSH private key (see ssh-keygen man page).
* Disable password logins to make sure users don’t reuse passwords between services (something an admin has no way of verfiying). This also protects against keylogger on user’s machine when they type password to unlock their private key. * Disable root login to make sure there’s only one way to get super user privileges. Chances are that a server will have sudo enabled for some users already so it’s better to have just one possible attack vector (sudo) than two (sudo or ssh). Also, auditing is not a convince feature, it’s a security feature. * Security through obscurity doesn’t work in the sense that it must not be relied upon. It does, however, increase cost of attack. Changing port won’t protect against directed attacks, but it may very well help if password logins are enabled and one of user’s password leaked and got added to password database used by some automated scanners. Less log noise and network traffic on SSH is added bonus of changing the port. * I don’t follow your argument about firewall. You first criticize it and then present exact scenario for which firewalls are useful. The feature of firewall is that you prevent mistakes in configuration of your services (which were supposed to listen on Unix domain socket only) exposing those services to the Internet.
OMG finally someone who doesn't just reiterate all the "common phases". I have asked my friends and colleagues lots of times why ssh keys are "per se" more secure than passwords (given a secure pw). Or why the heck everyone suggests a "firewall" even if I'm behind a NAT, which made never sense to me. Also this sudo and root user stuff I was wrecking my head about recently because with no root access by ssh, how I am supposed to execute root commands myself? Thank you!
To address that "password" vs. "ssh key" question: Even your "secure" password: is it more than a thousand characters long? And are those characters random-looking and unguessable? Your ssh private key is. Yes, sure, your key might get lost when your private machine gets compromised. But when your password gets more than a hundred characters long, you will write it down in some file, and there you are again at the same problem.
I believe he has a video or two where he said something like 'steganography is fun but in a CTF challenge it does not add any value in terms of real-life learning experience'. Figuring out a stegano-hidden payload or flag is - in my opinion - comes down to: - solvable with one of the two most common tools because the technique is among the several 'known' or popular ones; - impossible if the method is well-designed; - doable by finding the code that does the steganography (hide or unhide part), but, in this case, it is a reverse engineering challenge really - which is fun on its own.
Finally people! He is saying what we are all thinking! Interesting that none of these best practices resources talk about setting up alerts or monitoring logs of any kind.
You are correct, each of these measures by themselves won't make your server more secure. However cybersecurity is about layers. All of those measures combined will make your server more secure. Emphasis on the more, as the only way to setup fully safe and secure server is to disconnect it from the Internet.
Firewalls are very helpful for mitigating accidents. When setting up a new service, I might run the program with incorrect settings, or I might run the wrong program altogether. With a firewall, those accidents aren't visible to the outside world yet. Holes are coming and going on your back piece of paper, and having the front piece of paper gives me the opportunity to deal with that. They also help mitigate some attacks. Consider if an exploit gives an attacker an unprivileged shell. They could, for example, run netcat and have it bind to an unprivileged port. A firewall can prevent that from being useful to the attacker. Related: using a nonstandard port can help with resource usage. Untargeted spam connections are much more likely to use the standard port, and it's cheaper to have the packets dropped or connection closed by the kernel (either from firewall or lack of listener) than to have the SSH server set up a connection and check a bogus password.
You mean installing services without knowing what are you doing? Because that's how you inadvertedly open ports. Firewall is useful, but not because of that. Useful, because you may have multiple networks, eg. VPN access, multiple physical subnets, etc. and you want to control which service should be available from where. But securing a server is not magically happen by putting a firewall in front of it. You don't have to secure "the server", you have to secure the SERVICES! All of them! Read their manuals, thoroughly examine and understand their configuration files, etc. It may sound a phylosofical nitpicking, but it is not. When you configure your services securely, all of them rely on some sort of authentication and encryption, then even when you inadvertedly have it opened in firewall, it still remains secure. The firewall just adds additional protection. On the other hand, when you just hide your sketchy services with gaping holes in them with a firewall, then as soon as someone manages to get into the "insider" network somehow, through some weak point (eg. a workstation), then everything is fucked.
Thank you! Finally someone said it! So tired of listening infra guys selling unprivileged user as a "security" thing. If I use a password, what does it matter if it is root or behind sudo? No one is going to audit my development server...
I think the point behind creating a new user and giving it sudo group is to disable root login so it's not a target of attacks... I hear your point but it does add a micro thin layer, when added with other layers it does complicate the compromising of a system. Also - love the video and mindset approaching these things. You played with fire and it was cool - all time best analogy ever!!!!!!!!!!!!!!!!
Great video for explaining the why part. As someone who runs Linux servers for several years. Here is some of my thoughts. A big part of the reason those are called best practices are in fact for convenience, since security is complicated and most people don't have time to learn all the details themselves. While I do agree some of "best practices" covered in this video are completely garbage, some of them are useful and deserve the credit for making hackers more inconvenient and reducing the consequences of getting hacked. To this point, **I don't believe any system in this world is secure enough to stop a skilled hacker who is determined to hacked the system**. The only thing we can do is to increase the cost of attack. For this reason, making it inconvenient for hackers does help the security. Several things that I have done to my servers in the past. 1. Use SSH key to login (this prevent you from being lazy and use weak password to be brute forced against, of course, nothing will help if your computer get compromised) 2. Fail2ban (making brute force attack for SSH password more difficult, of course, if attacker has millions of IP addresses, there is nothing you can do about it) 3. Open only ports you use (I typically only do this when the vendor provide this by default, such as on GCE, because it's inconvenient to setup. the minor security benefit is that it prevent attackers from opening ports on your server if they only controlled a low privilege user account, making it inconvenient for them to create a remote access backdoors or leaking data (and prevent you from making configuration mistakes that expose internal servers to the public). Of course, a skilled attacker can just use existing ports or even setup a reverse proxy (such as FRP) to defeat your NAT) 4. Not using SSH at all (if your vendor provides you the webshell over HTTPS, you don't have to use ssh at all, this reduces the attack surface. Or if you really want to hide your port, you can use something like this (github.com/EtherDream/toh/blob/master/toh), which essentially tunnel any TCP connection over websocket (that is you will need an HTTPS server). Since you can use arbitrary URL as endpoint, it's pretty much impossible for hackers to find out your websocket SSH endpoint without compromise your computer. Of course, this approach does make your own access slightly inconvenient)
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.
Excellent video. I hate the fear mongering as well. Bottom line, - you need a knowledgeable IT staff to run and maintain your server. They can thoughtfully balance the level of security needed for a particular situation. Keep preaching thoughtful IT!
I would caveat the advice about auto-updating. In general, if you're just playing around, then leave the auto-update on. Keep yourself out of trouble, and set it to reboot during a time when you're not actively using it. But if you're providing a service to end users, then you're probably taking other steps about maintaining availability, and have factored in planned downtime for patching into that. For example: You provide a web service through a load balancer, and the backend web servers can be patched/rebooted whenever because the load balancer knows to route around them when they're down. And you'd configure them to stagger their updates to avoid having too many down at once, and only after testing your patches in your test environment before pushing them to production! :)
Iptable firewall has two benefit. If you have misconfigured the fw itself, your servers is secure but unusable.... The second one is, if you misconfigured any software that you only need locally to be wide open to the web, the explicit fw-opened ports won't allow any outside access.
![[UA] Eternal Fire проти NAVI | EPL Season 20 Malta](http://i.ytimg.com/vi/chvlsDygrZM/mqdefault.jpg)
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.
Another good one ia to make the oxygen really sparse. Since hackers wear masks aswell, you're gonna make it really hard for them to breathe
@@airdog46x *laughs in covid*
Create a speech-to-text daemon that logs every time it hears the words "mainframe" or "I'm in"
lol
There is thermo-underwear for girls ...
no one can guess that you are invulnerable in the 850nm spectrum from far away!
I liked the advice- “Don’t take security advice as the unquestionable truth- always dig deeper to know why”
It's the security variant of: "do not blindly copy&paste code from stackoverflow"
I think this could be generalized to advice in general "Don't take advice as the unquestionable truth -- always dig deep to know why... but listen to your Mom"
The same advice can be applied to anything in life
I feel like I need to dig deeper to know why you liked the advice...
But why should I follow that advice? ;)
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.
I was about to write the same thing: it really comes down to how one uses a server and how consistent they are with getting configuration right.
On one hand a firewall can definitely help protect from misconfigured services, but, on the other hand, it can lead to an admin being lazy because "I have a firewall". If there is nothing running, there is nothing to break and/or attack.
In the machine i use for www and dns i have a toon of stuff and it is binded to 0.0.0.0 so is good for me, and is the ssh keys a good idea to not force the use of them?
@@raxxer1234 I get it what you're saying, but the example was about "securing a Linux server", i.e. one machine with firewall and server software on it.
In that case, if one is careful about what they install and how they configure it, then having a firewall or not makes little difference in terms of actual security (as demonstrated by holes in the two paper sheets): in order to provide the (publicly accessible) services, one would have to open the same ports on the firewall anyways.
When a firewall comes in handy is when it is run separately (like you were mentioning) or if one wants to test lots of software without caring about proper configuration (but I'd say that that's not a good way to do things on a publicly accessible machine).
Please fix your discord
@@tHe0nLyNeXuS I definitely agree. While I wouldn't go as far as to say that closing ports on a firewall is "snake oil," I would say that its often advertised as something you "must do." I think of it more as a safety net when you're walking a tightrope--I'm glad its there, but I really really really don't want to have to test the effectiveness of the safety net.
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.
The best example of security by obscurity that I can think of is GSM. That too is being broken piece by piece by open source initiative such as osmocomm
Exactly. Especially if you know you have a disproportionate number of skids targeting your site, changing as many ports as possible away from default can help a lot. Plus, doesn't it just feel nice to have the page for your IP on shodan be as short as possible?
30 years in tech, 15+ in infosec, it is in fact “security through absurdity”.
Why are we in security? To reduce risk. It’s not all that complex.
@@bruhdabones that’s why you perform a threat assessment BEFORE building, who is targeting you, what are the more common TTP’s they use and how can you mitigate those to reduce risk.
I do use the "security by obscurity" thing, since I did find it to be successful overall with SSH bots. On port 22 I run EndleSSH, which for the ones who don't know it's an SSH tarpit.
Before running EndleSSH, i did have my SSH server on port 22 and I remember in the system log that every 30 minutes, some random bot would try to bruteforce the login.
I kinda got tired of seeing that, so I decided to add EndleSSH on port 22 and then hide my SSH port, and so far, none of the bots have even tried looking for that hidden SSH port.
That firewall analogy was absolutely gorgeous haha.
Look at THAT! They MATCH! lol
I am curious. Doesn't that firewall analogy counter the argument of not changing SSH port?
@@patrickgrady7505 how would it? The SSH port would have to be open for you to connect there anyways. People change the ssh port to avoid automated exploits against ssh or password brute forcing.
@@skyracer-mk8hg sorry I am new to this because I am trying to make a web server from my raspberry pi. Say I change the ssh port and use the firewall analogy, would the holes still match? Appreciate your feedback btw. I am probably just overly paranoid about protecting my stuff.
@@blankeyezero certain meme materials 🤭
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.
Disabling direct root login does add an extra layer of security. It basically doesn't allow an external attacker to directly attack the root account via brute force or key compromise. In order to achieve root access, attacker would first have to compromise a normal user and then target root access. So I think there is definitely some aspect of security to it.
"Using sudo gives you a bit of time to think about what you're doing as well." - Not if you sudo'd already within your last timeout period.
@@ThisIsTheInternet or if you run sudo -i then you basically just have a root shell and will never be prompted for a password again until you exit it
When running commands as a normal user without sudo, it will tell you that you don't have the privilege to run that command. That is an alert and another chance for you to revise your command.
Even when you type sudo ahead of time, just it being there means you're running something as "root" which creates a little bit of awareness in you.
Also, running sudo will be always logged and you can view who ran commands as "root".
If you're not a complete moron, you should have no issues running as root (with SSH keys of course)
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)
Yep. This guy seems to have basically no clue about the concept of defense in depth.
Lol. Why is the BSI mailing you ?
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.
This one should always be a recommendation. Deny by default and operate on a minimal trust model. You reduce your attack surface substantially
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.
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!
I'm a sysadmin as well and totally agree. Hate working with people who just do something without thinking why they're doing it or why it's done that way, even if they're doing everything correctly!
What do you recommend I dig deeper in if I want to make a server really secure. My background is not IT but rather hardware and software engineering, nevertheless, I'm really interested in knowing how to run my own home server.
I don't need military-grade security but I definitely like to learn how to make it very secure.
Particularly, if setting an user and giving it root privileges doesn't do anything, what's the best way of accessing my server?
More like every subject
@@m4l490n I'd start on the basic security of the web site itself, as that is rather easy to do and if you're a software programmer, probably also easier in itself. Parameterized queries takes away any attack surface through user inputs on SQL for example.
@@m4l490n Start out by using external hosting first and let them take care of server security, then focus mainly on the web site security (and do a lot of logging). When you're confident, you can move on to setting up your own server.
"And look at that! They match!". I laughed so hard at that
It's not the same though. You get different output in port scanners when scanning a blocked port or an open port just with no service listening on it. A server without any firewall may be more interesting for those "automated" scanners and script kiddies and hobby hackers and else.
I mean, I did laugh hard as well though. Not wanna imply questioning "assumed best practices" is a bad thing and yes, from a pure security perspective, there is no real difference within the security of that port, whether a firewall is blocking "nothing" or the port listening on "nothing".
My point is, often it's not only about direct security issues. The appearance of a server may also be factor. If you knock on someones door, the way how the door is build may make it more or less attractive to kick the door open ;)
@@rantanplan178 also don’t forget if you later opened something by installing an app that does that
Hence you would love to mange a firewall
@@ko-Daegu Not sure if I get your point. "if you later opened something by installing an app that does that " - by installing an app that does that? Does what?
You mean installing an app you don't know and that app likes to phone home without you knowing about this "phoning home" feature?
@@rantanplan178
No I mean the module I’m using opens or uses Venetian ports I would like to stay alerted 24/7 by firewall and I control what port the app opens
Instead of assuming that my app only work with certain port maybe my app does but some liberate module or other integrated app doesn’t or have the capability that can be leveraged
My English is shit never mind
@@ko-Daegu Nah your english is fine. As long as we understand each other, it's good enough.
What is a "venetian port"? I don't think I've heard this term before.
Anyways, I think we were both talking about the same thing. You talk about software you aren't sure what network activities it may execute. Well, in general I'd say don't use software you aren't sure what it's doing, especially not in production environments. However, there is our beloved Windoze or other proprietary software and you may not want to give them your entire network to play with. Therefore yes, using a whitelisting strategy on your network filters is certainly a good idea.
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
What's DS-Lite?
@@spacewolfjr It's the thing providers do nowadays to assign you a shared IPv4. But sadly, port forwarding is not possible through it, and sometimes it just randomly doesn't work. IPv6, on the other hand, is redirected directly to the outside internet. No need to forward ports, your machine is directly accessible.
@@NoNameBAM Ahh, interesting, I luckily don't have that issue with my ISP... yet
My home ISP assigns me both ipv4 and ipv6. Pretty sure NAT is still possible, even if you are ipv6 only.
@@NoNameBAM that's strongly abridged.
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.
Yeah that is what I though as well. Makes them guess 2 values instead of 1. And then the adding that user to sudo doesn't feel so strange.
The same also goes for disabling password authentication on SSH in my opinion - almost nobody is out there brute forcing SSH keys, they rather focus on passwords
That's mostly irrelevant if you have a strong password. If your password somehow leaks, your username most likely will too
@@kinibini2133 that's the whole purpose of keys. Making brute force harder or practically impossible
I was looking if someone made this comment as I was thinking the same thing.
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.
Also helps to keep the logs cleaner if you kept auth logs enabled :)
I use a firewall to make sure that if I messed up a config of some internal service, it doesn't end up exposed to the internet.
So basically, a last line of defense for wrong configuration.
Well, technically that would be a "first line" of defense ;)
I feel this video discredits the principle of defense in depth in some ways.
Couldn't agree more!
@@fr0mage it's only his opinion, a couple hours of research won't make any youtuber a security expert lol. He completely ignored any risk assessment. The so called "snake oil" practice will protect your server from nearly all 0day bugs from automated attacks and so on.
What do you call it when your first line of defense is your last line of defence? Other than vulnerable to salami tactics
I guess LiveOverflow learnt how to secure his server to stop other youtubers taking over 👀😅
😂😂
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
Agreed, some time ago I had an SSH server exposed on the default port (was a temporary thing because i'm lazy) and sshd logs were full of failed requests, probably in the thousands of requests each day
Yeah that's the only reason I do this.
I think it is a good reason to do so. The whole point of the video is : "Think about why you do it". For a hacker who tries manually, changing port does not close the attack window. Of course it allows blocking bot requests and script kiddies, and reduce unwanted bandwidth use.
Or, better yet, just drop traffic from unknown addresses :) ips does wonders kids
@@GlutesEnjoyer or better use ipv6 like he mentioned in video 😂 lol
Well using firewall to block ports except 80/443/22 is, if for some reason an attacker is able to start a process and bind it to a port via using vulnerability in a webapp, it prevents any further action on that port
Also fail2ban is a very effective way to mitigate attacks, choosing the ban criteria carefully
Yes fail2ban is effective specially if configured manually and perfectly but the problem most of the time due to its memory consumption issue.
I recently rented my first cloud ser er to play with hosting websites and some miscellaneous stuff, and was very anxious since I was totally unfamiliar with stuff and how to configure things securely
And this video kinda quenched that anxiety a little ^^
I think a video series covering basic server setup stuff like this and maybe addresses common concerns and misinformation around it would be nice
Imagine what would happen of your server provider would give you an insecure by default server 🙃
@@LiveOverflow It wouldn't be yours for long!
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!
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.
Couldn’t agree more.
I‘ve been doing what these guides suggest when I was like 15, but over some years I naturally questioned these tips and moved away from them. Except for SSH keys and no password auth, for the same reason you mentioned.
"You feel cool, you did something with fire.." lol
I came upon this video after watching a few others, and a lot of questions came to my mind watching those. after watching this video, i realized i was right asking those questions, and this video actually answered a lot of them. thanks
An ssh key is a 2fa by design, it's the key you have and the password you know to use the key.
Even better, stick the private key on an external air-gapped device like a smartcard, or use U2F-based authentication for SSH, like YubiKey. The trouble with using SSH private keys that are stored on your main work device is that _that_ device may become compromised without you knowing, and then you're back to square one.
@@JivanPal But then we go to physical hacking where basically all bets are off right, someone could take your drives or installs a key logger. It's about someone somewhere trying to remote in where you don't have cameras and a guard dog.
@@Stoney_Eagle, not sure how you come to that conclusion. If your private key is on your laptop, malware from the internet is a threat. If your key is on a smartcard or you use U2F via YubiKey or similar, there is no threat unless someone takes that external device.
In the first scenario, a _file_ is your second factor. In the second scenario, a _physical object_ is your second factor. The whole point of 2FA is that the second factor ought to be something you physically possess, not something that can be acquired remotely.
@@Stoney_Eagle "all bets are off" - i guess physical security isn't a thing?
Fun fact:
Ssh keys can have a password
Soo it is semi-auto authentication
just a minor hint, cause i got it wrong for a long time as well:
dist-upgrade is just a slightly differenty upgrade, it does something different in managing dependencies, but to upgrade to a new distro version, there exist special commands, e.g. sudo do-release-upgrade for ubuntu
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.
1. SSH Keys aren't 2FA, Yes you can password protect them but it is not required.
2. anybody can cat /etc/passwd and see all the user accounts that exist. As Liveoverflow mentioned, somebody can always just modify the bashrc file to execute whatever malicious command they want as root.
Awesome video! A better title would be "Debunking linux server security myths" imho, should result in more views and is also accurate.
SSH on port 22 on a public server is a great idea if you like reading access logs.
Changing SSH port and banning/blocking port scanning IPs is a good thing.
A lot of arguments in this video felt pretty shallow, for somebody who wants to ”look deeper”.
Video was framed as John Doe renting a VPS for the first time.
Chances they look at the access log? I would say close to 0.
If someone got onto your Linux box, the logs would be the first thing to go in cleanup. Then you get into log aggregator territory and suddenly it is a network.
This is why Chuck is one of the best out there. He's a dedicated learner. I'm subscribed to both channels and I learn a ton every time I open their videos.
“You feel cool, you did something with fire, but it's useless XD” 15:10
I laughed at this too! That was soo funny
For the firewall, I stopped midway so you might mention it later in the video. Something a firewall can do that just opening or closing a port can't is you can set it so it checks the connection source. So you can set it up so it'll only allow a connection to a given port from a given ip addresss like for example the local network, or even a specific ip on the local network. That's not really useful for a remote server unless you have a static ip at home or wherever you're accessing it from that you can restrict it to.
I would still recommend these „best practices“ to anyone playing around with servers at home, just because of crawlers and script-kiddies… Just to cut unnecessary load and bandwidth. The chance of someone having an eye on you and want to hack you is low, they rather go for companys, where they can get money
You seem very intelligent. I really enjoyed the way you questioned and dismantled these widely accepted and parroted "truths". Thank you! Subscribed.
Password auth can be bruteforced. Pki cannot (feasibly)
Fail2ban with permanent block. Good luck bruteforcing.
@@ChadReitsma but then how does the user login what if a bot locks them out 100 times a day it just doesn’t work
@@AnonYmous-spyonmepls Fail2Ban normaly only bans the IP Address from where the login attempts were made, you can still just login and ues your server normally.
@@alexandramiller4011 then build in a script that switches between VPNs after you get locked out still doesn’t solve anything tbh
@@AnonYmous-spyonmepls you'd have to try use invalid SSH keys or Passwords to get locked out/banned.
if a attacker attacks your server HIS ip address will be banned, not yours.
I have been a linux sysadmin for quite a while now and faithfully followed these "best practices". Thanks for this video!
The only valid reason to change the default SSH port away from 22 is so you free up port 22 to run a SSH tarpit :D
It might be possible to use fail2ban to redirect the attacker ip to a tarpit on a different port after a number of failed attempts. That would be fun...
I think this was a good run down on the security aspect of hosting servers. I work in IT and one of the most important things is keeping an exposed program isolated to a specific user, and keeping that user from running other programs it's not supposed to. One method of securing systems I've been pretty fond of lately is using podman to host game servers and things like ftp servers. It's a docker alternative that leverages cgroups to run as a user on a per container basis. So in contrast, docker runs in the background as root, where podman runs only when you ask it to as a restricted user without root access. It's great for systems not using SELinux and you want to restrict the access. Ubuntu comes with AppArmor but I think this is more effective, and a lot of programs don't come with AppArmor profiles.
You got any good resources on this? I'd love to try this out.
Disabling IPv6 is hilarious, I wish all ISPs would finally start supporting v6 so that you can disable v4 and get rid of bots scanning v4 addresses. Speaking of, changing SSH port is useful to reduce noise in ssh logs, and if you drop a honeypot/tarpit on port 22 you could instantly ban all the IPs from accessing the real port :) if for some reason you can't setup a whitelist on that port, anyway.
Wow just what I needed, I have been working on a project in my local network and wanted to deploy it. I have tried to search for advice on security, but as you said in the beginning never found anything good. This saves me!!!!
Putting the SSH on a high port is generally still a good idea IMO to filter out all the botnet traffic from the logs and to see if more sophisticated attackers or botnets are actually attacking your server, since most of the botnets only blindly hammer away on port 22, so IMO putting it on a high port IS still a security improvement, since your logs will be a lot clearer and will have a lot less junk traffic logged, meaning you can go through them with much more ease and possibly identify real attacks a lot easier. Sure enough, if someone is specifically targeting your server it'll act as security from obscurity, but you as a server owner will be able to identify these targeted attacks a lot easier from the logs this way.
You can filter out this patterns from logs, when it is not just passing by botnets and when, for example, somebody trying each password only once and then filter out groups of IP. But i think you need this information only if you have some kind of honeypot, i don't know why you need this if you just want working server :)
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.
Man I like your intro music. Your have one of the first quality channel I’ve been watching on UA-cam. What’s up with the inspector Gordon look? :-p
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.
TBH if your server is running on HDDs I'd say changing the ssh port/using fail2ban is great. The amount of logs that need to be saved to disk is so huge and as we know HDDs have a very low number of IO ops. So I count leaving the default ssh port as DDOSing your own server LOL
Because every line of log is written immediately with no caching in place, as everyone surely knows. fail2ban is good, but not because of io operations.
@@TheBrassn Yup, forgot to mention that logs need to be written without caching. Also I didn't say it's the only reason to use fail2ban
After listening liveoverfolw video.. "Bro unplugged all devices, we want private network". Amazing video of "Best practice"
I would say I somewhat disagree with your statement about changing default SSH port being snake oil. Changing the default SSH port won't give you extra protection, we can agree on that. But the reduced amount of requests to the port will make threat hunting and log processing a much more manageable task. You will in essence get much less "scanner" noise in your logs.
But this doesn’t add extra security in any means. That’s the scope of the video
Excellent video, and the firewall illustration was hilarious.
Video for workstation security will be nice.
This video actually made me check what services are running on my server. And it actually made me install a firewall (ufw). I noticed that there is a mail service that I did not know about but apparently it's needed for some error message communication. Thanks to ufw, I don't need to figure out how to configure it to stop listening to external traffic. I simply allowed everything that I knew about in ufw.
I lost it with the firewall papers 🤣🤣🤣🤣🤣🤣🤣🤣
Great content. Totally agree, as a cloud engineer who writes code to production directly in VPS through VScode ssh tunneling, ssh password is very convenient feature.
I think changing the SSH port and disabling root login are not unreasonable, given how little they cost to do, I mean they are essentially free. If you open an SSH server to the Internet on the default port, you quickly see a flood of login attempts from bots banging on the root user and possibly other common usernames. Changing the port reduces the bot traffic.
A firewall rule to limit the rate at which they can try passwords is a good thing to shut the bots up. I use a rule that allows only four connection attempts from an IP address in any one minute period and that seems to deter them quite effectively. I also use PKI and have disabled the root user and if they never even get an option to enter a password, that slows them down very effectively.
@@dingokidneys But basically, all of that trouble goes away when you just change ports. I never had any "1 million log-in attempts made since last time you logged in" since I started changing ports. I don't relly on it as some security measure, it's just annoyance removing measure.
Thanks! Also loved the networking related videos!
7:06 Yes, it's different. When you log in as root, you only need one key/password. But when you have key auth and the user is sudo you NEED TO know both the key and the user's/root's password. Also you can only allow certain privileges, not the access to the whole system.
just got notfication and I'm in
I love this video, man great explanation of SSH and passwords!! I am working on my domain server at home and working through all of the permissions and how to set things up is quite a task, but anyways love the video great job!!!
And I am now a subscriber!!
Quite frankly, I use ssh keys, no root and fail2ban because it reduces the attack surface and I'm unlikely to lock myself out. I had a VPS running for 2 weeks with standard config (strong root pw) cause I wanted to learn, but havent gotten around to setting it up completely. I found it with about 100MB just in logs from all the chinese bruteforce login attempts. I set up fail2ban but managed to lock myself out, cause typing passwords is hard. Then just switched to ssh keys for convenience. Tbf this is for my private playing around with server stuff nothing like production. But I still don't wanna be part of a botnet anytime soon lol
@12:00 - I've set up an entire scalable cloud by hand without using ready made AWS tooling. So to say that people who like to keep an ear to the ground about security ideas "aren't ready to set up a network" is just crass.
If the person doesn't KNOW if they're ready, then they aren't. Nothing is ever 100% secure, that's true, but building things is how you get good. I'm still learning even after over 20 years of engineering.
But if you combine SSH keys and use sudo instead of root directly, then in order for an attacker to get root access they need to hack through two separate steps. Defence in depth.
He showed you in the video one way you can bypass the sudo password requirement for an exploit.
Yes but no.
If you set a strong password or use a SSH key, chances are they got in through a service. This would still require the password to be discovered or for priv esc to occur which is fairly trivial.
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.
Sudo actually have sudoers file, which allows you to execute special commands not all commands as root. Root allows you do everything sudoers limits this a lot and audit as you already mentioned
Just to add love your videos very big fan
Is it just me or did the videos/examples become a bit more sarcastic lately? I really laughed at the firewall example :D
While I am at it: Thank you very much for your great and educational content! I have learned a lot through the years just watching your videos and experimenting and got a much broader understanding of how things work "under the hood", which is just fascinating. It also led to me developing safer software in my day job and raising security awareness in my team. :)
Bruh this is like the 5th time I heard people pronounced it *"Odays"* instead of *"0days"* this week. What's happening? Have I've been pronounced it wrong all this time or what?
Most likely just preference? Zero can be pronounced as "ou" (not specific to this context) and I guess it just flows better in speech that way.
@@niter43 nah, apparently you can call it whatever you want, really. Some even says it "ohdays". ¯\_(ツ)_/¯
Many official publications from the reputable sources though still calls it Zero-day (0day).
I agree with you totally about using a different port. It is not a security measure. I forward port 443 on my router to port 22 on my server but my reason for doing so is that I can't get to port 22 from behind my work firewall. I can however get to port 443.
As for not permitting 'root' ssh access, I agree totally with that as 'root' is a well known user and hence low hanging fruit for brute force attacks. I disable 'root' ssh access and actually disable the root account itself. That way all use of root like authorities and the user who made use of them is logged and I can check to see that no use was made of root permissions when they shouldn't be. Where you have multiple non-root users on the system, if you are breached, it gives you a clue as to the access point.
I always disable ssh password access and use only keys because a) as you said they are quick and easy to use, and b) the key fingerprint is logged so I can detect if something weird is happening. The second is also why I set up a new key for each device that I connect from.
IPv6 I'd agree is snake oil but I've disabled it on my router primarily because I don't know enough about it to manage it intelligently. That's some learning I have yet to do.
I believe that default 'unattended-update' on Debian and Ubuntu will only apply security updates. That's the way they seem to work on my systems. I still have to go in and apply any functionality type upgrades if I want them. I've extended the default config to update my primary web browser so that I'm always using the latest and greatest available.
As for firewalls, I've not used firewalls on my end-point systems for over 20 years. My NAT router manages access for me just fine. The only exposed port is forwarded to my hardened ssh server (keys only, no root access) and this has worked fine even though my logs show mass probing and frequent ssh login attempts. I did however recently add a couple of iptables rules to deter brute force attacks and DOS attempts. Probably not essential but makes me feel better.
I have to disagree on your first argument, because you made an important assumption, that the ssh-server is in the known hosts. But for new connections this is not the case, so if I make my first connection to the server on my machine, and someone would composmise my server by MITM or compromising my domain, he would gain access to my password. For the public key authentication, I do think the assumptions made in the documentation are very reasonable, as compomising the servers private key seems way more unlikely than someone MITM your connection.
EDIT: Also your comparison to HTTPS is flawed, due to there being a certificate authority.
I hope that this becomes a series because it's really useful :D I would love to see a video like this for docker!
Changing ports has some benefits; you can run a fake ssh server to halt those skids' script
It doesn't really apply for SSH only, though
i created fake sql errors on my site xD
Keys are very convenient. But keeping backups of them offsite (say, Google Drive) and you'll likely be using an encrypted archive for them. Which is why having a few strong keyphrases for password managers, etc. are always good to have and remember. That way you can keep backups of the password database as well and it be secure.
Yes, changing SSH port and tools like fail2ban are there for one reason: keep logs shorter.
So, can we create a petition to rename firewalls to paperwalls now? Great video!
On the topic of SSH, I would say it's much harder for an attacker to brute force a SSH key than it is to brute force a SSH password. I'd find someplace in the middle, like a password on your client's SSH private key (see ssh-keygen man page).
* Disable password logins to make sure users don’t reuse passwords between services (something an admin has no way of verfiying). This also protects against keylogger on user’s machine when they type password to unlock their private key.
* Disable root login to make sure there’s only one way to get super user privileges. Chances are that a server will have sudo enabled for some users already so it’s better to have just one possible attack vector (sudo) than two (sudo or ssh). Also, auditing is not a convince feature, it’s a security feature.
* Security through obscurity doesn’t work in the sense that it must not be relied upon. It does, however, increase cost of attack. Changing port won’t protect against directed attacks, but it may very well help if password logins are enabled and one of user’s password leaked and got added to password database used by some automated scanners. Less log noise and network traffic on SSH is added bonus of changing the port.
* I don’t follow your argument about firewall. You first criticize it and then present exact scenario for which firewalls are useful. The feature of firewall is that you prevent mistakes in configuration of your services (which were supposed to listen on Unix domain socket only) exposing those services to the Internet.
OMG finally someone who doesn't just reiterate all the "common phases". I have asked my friends and colleagues lots of times why ssh keys are "per se" more secure than passwords (given a secure pw). Or why the heck everyone suggests a "firewall" even if I'm behind a NAT, which made never sense to me. Also this sudo and root user stuff I was wrecking my head about recently because with no root access by ssh, how I am supposed to execute root commands myself? Thank you!
To address that "password" vs. "ssh key" question:
Even your "secure" password: is it more than a thousand characters long? And are those characters random-looking and unguessable?
Your ssh private key is.
Yes, sure, your key might get lost when your private machine gets compromised. But when your password gets more than a hundred characters long, you will write it down in some file, and there you are again at the same problem.
Hey! Could you do a video series on Stegonagraphic challenges?
I believe he has a video or two where he said something like 'steganography is fun but in a CTF challenge it does not add any value in terms of real-life learning experience'. Figuring out a stegano-hidden payload or flag is - in my opinion - comes down to:
- solvable with one of the two most common tools because the technique is among the several 'known' or popular ones;
- impossible if the method is well-designed;
- doable by finding the code that does the steganography (hide or unhide part), but, in this case, it is a reverse engineering challenge really - which is fun on its own.
This is a pretty great video. Getting people to think critically about why things are done, especially in security, is a great thing
🤔 blocking certain ports sounds like the default is to keep all the ports open 😅
but then what would even happen when u connect to them..
@@LiEnby everything blows up
Finally people! He is saying what we are all thinking! Interesting that none of these best practices resources talk about setting up alerts or monitoring logs of any kind.
Linux guide is confusing and inconsistent 😭
You are correct, each of these measures by themselves won't make your server more secure. However cybersecurity is about layers. All of those measures combined will make your server more secure. Emphasis on the more, as the only way to setup fully safe and secure server is to disconnect it from the Internet.
Hey dude, will you ever come back to reverse engineering ?
Thanks for your feedback, and your english subtitle, it is really useful.
English: twenty two
+ German: zwei und zwanzig (two and twenty)
= ssh port number, according to LiveOverflow: twenty twenty
:)
Great video otherwise!
The confusion could also be related to jesus age
First video I've watched of yours. 0:38 was enough of a reason to subscribe! Great video!
21 likes, 17 views, cant argue tbh
You had me at "the paper firewall" excellent video as always. Lovin it!
+1 for using props 🤣
Firewalls are very helpful for mitigating accidents. When setting up a new service, I might run the program with incorrect settings, or I might run the wrong program altogether. With a firewall, those accidents aren't visible to the outside world yet. Holes are coming and going on your back piece of paper, and having the front piece of paper gives me the opportunity to deal with that.
They also help mitigate some attacks. Consider if an exploit gives an attacker an unprivileged shell. They could, for example, run netcat and have it bind to an unprivileged port. A firewall can prevent that from being useful to the attacker.
Related: using a nonstandard port can help with resource usage. Untargeted spam connections are much more likely to use the standard port, and it's cheaper to have the packets dropped or connection closed by the kernel (either from firewall or lack of listener) than to have the SSH server set up a connection and check a bogus password.
15:05 I also can not agree, using a firewall can prevent you from opening ports inadvertent
You mean installing services without knowing what are you doing? Because that's how you inadvertedly open ports.
Firewall is useful, but not because of that.
Useful, because you may have multiple networks, eg. VPN access, multiple physical subnets, etc. and you want to control which service should be available from where.
But securing a server is not magically happen by putting a firewall in front of it. You don't have to secure "the server", you have to secure the SERVICES! All of them! Read their manuals, thoroughly examine and understand their configuration files, etc.
It may sound a phylosofical nitpicking, but it is not. When you configure your services securely, all of them rely on some sort of authentication and encryption, then even when you inadvertedly have it opened in firewall, it still remains secure. The firewall just adds additional protection.
On the other hand, when you just hide your sketchy services with gaping holes in them with a firewall, then as soon as someone manages to get into the "insider" network somehow, through some weak point (eg. a workstation), then everything is fucked.
Thank you! Finally someone said it! So tired of listening infra guys selling unprivileged user as a "security" thing. If I use a password, what does it matter if it is root or behind sudo? No one is going to audit my development server...
"you did something with FIRE!" .. my favorite quote from this...
I think the point behind creating a new user and giving it sudo group is to disable root login so it's not a target of attacks... I hear your point but it does add a micro thin layer, when added with other layers it does complicate the compromising of a system. Also - love the video and mindset approaching these things. You played with fire and it was cool - all time best analogy ever!!!!!!!!!!!!!!!!
Great video for explaining the why part. As someone who runs Linux servers for several years. Here is some of my thoughts.
A big part of the reason those are called best practices are in fact for convenience, since security is complicated and most people don't have time to learn all the details themselves. While I do agree some of "best practices" covered in this video are completely garbage, some of them are useful and deserve the credit for making hackers more inconvenient and reducing the consequences of getting hacked. To this point, **I don't believe any system in this world is secure enough to stop a skilled hacker who is determined to hacked the system**. The only thing we can do is to increase the cost of attack. For this reason, making it inconvenient for hackers does help the security.
Several things that I have done to my servers in the past.
1. Use SSH key to login (this prevent you from being lazy and use weak password to be brute forced against, of course, nothing will help if your computer get compromised)
2. Fail2ban (making brute force attack for SSH password more difficult, of course, if attacker has millions of IP addresses, there is nothing you can do about it)
3. Open only ports you use (I typically only do this when the vendor provide this by default, such as on GCE, because it's inconvenient to setup. the minor security benefit is that it prevent attackers from opening ports on your server if they only controlled a low privilege user account, making it inconvenient for them to create a remote access backdoors or leaking data (and prevent you from making configuration mistakes that expose internal servers to the public). Of course, a skilled attacker can just use existing ports or even setup a reverse proxy (such as FRP) to defeat your NAT)
4. Not using SSH at all (if your vendor provides you the webshell over HTTPS, you don't have to use ssh at all, this reduces the attack surface. Or if you really want to hide your port, you can use something like this (github.com/EtherDream/toh/blob/master/toh), which essentially tunnel any TCP connection over websocket (that is you will need an HTTPS server). Since you can use arbitrary URL as endpoint, it's pretty much impossible for hackers to find out your websocket SSH endpoint without compromise your computer. Of course, this approach does make your own access slightly inconvenient)
Thank you very much for your wonderful and educational videos.
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.
Excellent video. I hate the fear mongering as well. Bottom line, - you need a knowledgeable IT staff to run and maintain your server. They can thoughtfully balance the level of security needed for a particular situation. Keep preaching thoughtful IT!
I would caveat the advice about auto-updating.
In general, if you're just playing around, then leave the auto-update on. Keep yourself out of trouble, and set it to reboot during a time when you're not actively using it. But if you're providing a service to end users, then you're probably taking other steps about maintaining availability, and have factored in planned downtime for patching into that.
For example: You provide a web service through a load balancer, and the backend web servers can be patched/rebooted whenever because the load balancer knows to route around them when they're down. And you'd configure them to stagger their updates to avoid having too many down at once, and only after testing your patches in your test environment before pushing them to production! :)
I just want to add that changing the port to port 69 proves you are an intellectual, and will intimidate hackers.
you are very perfect in explaining very best lots of means very lots of doubts has been cleared and got root level knowledge...
Hallelujah, an advocate for critical thinking...Kudos!
Iptable firewall has two benefit. If you have misconfigured the fw itself, your servers is secure but unusable.... The second one is, if you misconfigured any software that you only need locally to be wide open to the web, the explicit fw-opened ports won't allow any outside access.