How To Protect Your Linux Server From Hackers!
Do you have a linux server and do you know how to prevent getting hacked? In this video we will critically discuss a few best practices. The video can be summarized as: "a lot of fluff, not much use".
Prefer to read? Blog article version: liveoverflow.com/protect-linu...
Very scientific analysis: docs.google.com/spreadsheets/...
Other Opinions:
- Enable unattended updates: blog.filippo.io/psa-enable-au...
Chapters:
00:00 - Intro and Motivation
01:47 - 1. Disable SSH Password Login
03:47 - Detour: Password Login for Websites (https)
04:39 - Password Recommendations
05:33 - 2. Disable Direct root SSH Login
07:07 - Creating user and add to sudo
08:47 - 3. Change Default SSH Port
10:42 - 4. Disable IPv6 for SSH
13:40 - 5. Setup a Basic Firewall
15:43 - 6. Unattended Server Auto Upgrade
19:04 - Conclusion
=[ 🐕 Social ]=
→ Twitter: / liveoverflow
→ Website: liveoverflow.com/
→ Subreddit: / liveoverflow
→ Facebook: / liveoverflow
=[ 📄 P.S. ]=
All links with "*" are affiliate links.
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.
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 🤭
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.
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.
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.
"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.
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 :)
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.
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
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 hope that this becomes a series because it's really useful :D I would love to see a video like this for docker!
I guess LiveOverflow learnt how to secure his server to stop other youtubers taking over 👀😅
😂😂
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
You had me at "the paper firewall" excellent video as always. Lovin it!
This is a pretty great video. Getting people to think critically about why things are done, especially in security, is a great thing
Man I like your intro music. Your have one of the first quality channel I’ve been watching on KZhead. What’s up with the inspector Gordon look? :-p
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.
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!!!!
I have been a linux sysadmin for quite a while now and faithfully followed these "best practices". Thanks for this video!
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!
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.
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!
First video I've watched of yours. 0:38 was enough of a reason to subscribe! Great video!
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'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.
Your advertisements and placements are amazing
Excellent video, and the firewall illustration was hilarious.
We needed this, I needed this. But really if you're worth anything and are a InfoSec professional, you'd most likely follow security baselines/frameworks/best practices from a long vetted organization such as NIST, CIS, etc. If you implement every control in the highest levels of CIS for a Linux server, it'll be ultra secure beyond anything you can imagine.....except it also won't be able to do much. The end goal of course always being the trade off being security and practical job duties.
I have an unhackable device; a brick.
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
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.
Eyes opening topic and comments... I'll try these thinking process as soon as tomorrow at work, as we literraly juuuuuust had this one talk (who runs it? Who updates it? What automated update process / backup? What IP / Ports for security? Who makes software? Who makes reviews of code? How much price difference?, etc..) Thanks dude, you probably changed the outcome of my professionnal project, juuuuust because i know that if i drop your name and video url in the talk, they'll take it as an argument, just because they already know your style. Thanks again for you teaching, helped me to get my sans 601 ;)
"You feel cool, you did something with fire.." lol
Video for workstation security will be nice.
Great video! You should definitely do a serie of this!
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 root login vs sudo I think the advantage is that you know which user has logged in and is sudoing versus a root user logging in from outside where you might only have the remote IP address in the logs.
And attacker have to guess the username, not just use the default root.. still... i will keep using root with key.. lol
@@frumbert non-root users using sudo makes access management easier when you have multiple people who need to manage that system. When one person leaves the team, you shut down their account and you don't have to change passwords and distribute the new password to everyone who needs to know.
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.
You seem very intelligent. I really enjoyed the way you questioned and dismantled these widely accepted and parroted "truths". Thank you! Subscribed.
I'm glad that you still got cool video ideas. Awesome video
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 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
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!!
This is the most easily digestible content I have ever come across.... really really great content and aesthetics
And look at that! THey MAtch! lol
“You feel cool, you did something with fire, but it's useless XD” 15:10
I laughed at this too! That was soo funny
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.
What an interesting piece of explanatory video. This made me thought beyond boundaries. Nice POV.
Great video, and great advice. Informative as every one of your videos is!
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.
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
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.
Amazing video!!! Made me laugh at so many points. Especially the firewall illustration XD
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
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.
Nach diesem Video habe ich gesucht! Gerne ein weiteres mit Methoden die du gut findest. 👍
Thanks for your feedback, and your english subtitle, it is really useful.
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
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.
Thanks! Also loved the networking related videos!
Hello Liveoverflow, This comment is the my reply for your previous video. I saw that you have good knowledge from CTFs. I'd like to see those from your next few videos. I meant rev, stego, crypto, osint etc.. but by your perspective. 😊
just got notfication and I'm in
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).
Very nice video! Some time ago, when I wasn't so expert, I was looking to some tutorials like that, but I found out they were little more than garbage and so I studied more to get real security. I'll share your video to some IT student because is a really powerful example of IT snake oil.
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 lost it with the firewall papers 🤣🤣🤣🤣🤣🤣🤣🤣
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
This paper demonstration made me happy, thanks!
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.
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.
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
Every time I started to type a comment you mentioned why something was still important like sudo for logging lol. As a long time Linux sysadmin this video is pretty great.
OMG Thank you so much for the video. I learned so much and I actually got to secure my server.
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...
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).
Thit is a great video! Especially the firewall part :)
Thank you! This video needed to be done!
9:41 yeah they might be able to hack into my ssh server on port 42069, but they would have to scan all the ports first to find it while trying not to get detected by my router...
How? Do you have program that react to port scanning from one ip address?
@@astronomos826 yeah, most router firewalls have that feature...
@@zyansheep what about detecting the failed password attempts instead of wrong ports? :D
@@ChillerDragon well, i might type in my password wrong...
🤔 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
Awesome video! A better title would be "Debunking linux server security myths" imho, should result in more views and is also accurate.
Thank you for this! Very informative and interesting video.
Hey dude, will you ever come back to reverse engineering ?
+1 for using props 🤣
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.
Cooles Video, über manche Dinge habe ich auch schon nachgedacht aber gut dass du das nochmal aufgezählt hast. Manche Tipps von Webseiten sind schon echt unnötig und nutzlos in dem Kontext in der sie geschrieben sind
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
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.
This was really interesting! I've always been confused about those incredibly simple firewall rules. My understanding about ssh keys was that not entering your password as often limited the possibility of it being caught by an mim attack. But I guess they really are just more convenient
Keys are way more convenient than a really good strong password, and they are more secure provided you protect your Private key files properly.
i was sure a lot of these standard advice were nonsense in my situation, thanks for the video.
21 likes, 17 views, cant argue tbh
you are very perfect in explaining very best lots of means very lots of doubts has been cleared and got root level knowledge...
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 ...Too much knowledge to grasp :) have to watch it again :)
Thank you very much for your wonderful and educational videos.
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.
You speak so eloquently. I like it
Nice !! Thanks for the content !!!