Linux: Linux Security and Administration - podcast episode cover

Linux: Linux Security and Administration

Oct 07, 202522 min
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

Focusing on the installation, security, and administration of the Linux operating system. It covers setting up Linux on virtual machines, exploring various distributions, and managing user account security by detailing practices like avoiding root logins, implementing password policies, and restricting SSH access. The text also explains server security through firewalls and regular updates, along with various encryption methods and tools for files and partitions. Finally, it addresses penetration testing stages and network scanning techniques to identify and mitigate vulnerabilities within a Linux environment.

You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary

Get the Book now from Amazon:
https://www.amazon.com/Linux-Security-Administration-Andy-Vickler-ebook/dp/B08ZSVY6SL?&linkCode=ll1&tag=cvthunderx-20&linkId=0ccda3361a4f7bc94b882c4d87b039e5&language=en_US&ref_=as_li_ss_tl

Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy

Transcript

Speaker 1

Welcome back to the deep dive. We sort through well all the noise to bring you insights that really help you get properly informed. Today we're taking a journey into the world of Linux. Maybe you've heard about it, seen it around, maybe even you know tinkered a bit yourself. But have you ever thought about how to not just use it, but how to really secure it, like build an ironclad digital fortress. That's what we're diving into today.

Speaker 2

It's a really vital question actually, and it unlocks I think, the true potential of Linux. I mean, it's incredibly adaptable, very powerful, but because it's so open, you have to understand its security. It's not optional. Really. The source material we're looking at is pretty comprehensive, a great guide. It takes us right from the first boot up through to some quiet advanced stuff.

Speaker 1

It's a good roadmap for us absolutely. So the plan for you, the learner listening in, it's kind of three stages. First, we'll look at the safest way to even get started with Linux, no risks. Then we'll dig into the basic security stuff you absolutely need to know keep thinks safe. And finally we'll get a little peak behind the curtain. See how the pros, the security experts actually test these systems, look for weaknesses, goals for you to leave with some clear,

actionable ideas. Feel confident you know, ready for your Linux adventure. Okay, let's unpack this first bit. Then imagine your Linux curious, right, you want to try it, maybe a specific version or just experiment, but you definitely don't want to mess up your Windows machine or your Mac, your daily driver. Understandable. This is exactly where virtual machines vms they become your best friend. Think of a VM as like a whole separate computer, but it runs inside your actual computer like

a digital sandbox, exactly a sandbox. You can play, experiment, break things even, and your main system is totally untouched. The only real limit as well your actual hardware. You can't give the VM more memory than your PC physically has.

Speaker 2

Right, Right, And that's the beauty of using vms for trying Linux. It's safe, it's easy. You totally avoid dealing with dual booting, which, let's be honest, can be a real pain, especially for newcomers. Sometimes it can even mess things up. There are tools like VMware workstation Player. It's free for personal use, really accessible, pretty much. The only thing you need is a CPU, a processor that supports virtualization. Most modern ones do. Usually it's on by default.

Speaker 1

Okay, so you've got your virtual sandbox all set up, easy enough, but then you hit this wall of choice Linux distributions or distribus. It feels like there are hundreds, not just one Linux.

Speaker 2

No, there are many hundreds.

Speaker 1

Yeah, and for someone new, it's like looking at this huge menu. Right, everything looks interesting, but you've no idea what to order. So how do you choose, especially if you're just starting out. What's the secret?

Speaker 2

That's a great question, and it really just comes down to what do you want to do. Think of distros as different flavors, maybe different car models. Each one's tuned for something specific. You've got Ubuntu, which is kind of the reliable all rounder, good for general use, pretty easy to get started.

Speaker 1

With, Okay, like in Toyota Cari of Linux.

Speaker 2

Oh yeah that. Then if you're a gamer, maybe steam Os makes sense. It's built for that. Got the laptop you want to revive? Linux Light is super lightweight. Then you get into the specialists Qubes, I mean that's for extreme security. Nuts creates totally separate boxes for everything you do.

Speaker 1

Right.

Speaker 2

And for folks interested in security itself, like testing and whatnot, there's Collie Linux. It's like a digital Swiss Army knife packed with security tools.

Speaker 1

There hundreds of them apparently, yeah, over.

Speaker 2

Four hundred last I checked. So the key is figure out your goal, is it gaming, battery life, learning, security? And pick a distro that fits just a one small note. Some distros, like the ones for tiny computers like the Raspberry Pie, they use different processor types arm Usually those won't run easily on your typical laptop.

Speaker 1

VM, gotcha, pick the right tool for the job. Yeah, makes sense. Okay, so you've picked your distro, it's running in the VM. Now we hit like the first real security thing. Yeah, user accounts for building this digital fortress. Who gets the master key? Right? Who's in charge?

Speaker 2

Precisely? And this brings us straight to probably the single most important rule in Linux security. Never ever log in as the root user for your normal day to day stuff.

Speaker 1

Just don't. Okay, why is it so bad? I mean Windows has administrator.

Speaker 2

Accounts, it's different. The root user in Linux is well, it's god mode absolute power. Windows has that User account control UAC, that little pop up asking are you sure before big changes, annoying, pop up annoying maybe, but it's a safety net. Root in Linux by default doesn't have that. If you're logged in as root and you make one typo or run some dodgy script by accident, it can wipe your entire system, no questions asked. It has complete total control.

Speaker 1

Hikes. Okay, that is a big difference, a potential disaster. Like you said, so if root is this like loaded weapon, what's the safe way? How do we actually do admin things without risking blowing everything up.

Speaker 2

The safe way, and honestly, the standard way is using pseudo accounts. Think of pseudo it stands for super rousers do think of it as a very controlled loan of the master key in lots of distress. Now, like Abuntu, the actual root account is locked by default. You can't even log into it directly.

Speaker 1

Oh really okay?

Speaker 2

Yeah. Instead you have your normal user account, and when you need to do something administrative like install software or change a setting, you just type pseudo before the command pseudo app get update or whatever. It asks for your user password, not the root password. If you get it right, it grants you root powers, but only for that one single command. Then it takes the power away again.

Speaker 1

Ah okay, so it's like you borrow the master key for one specific lock, use it, and immediately end it.

Speaker 2

Back exactly that. It's temporary specific elevation of privileges.

Speaker 1

Which means if I accidentally run something nasty or make that typo.

Speaker 2

The damage is limited. It can only mess with things your normal user account has access to, like your own files and your home folder.

Speaker 1

It couldn't say, delete the entire operating.

Speaker 2

System, not unless you specifically told it to. With Pseudo, but yeah, a random malicious script running as your user such less dangerous than if it ran as root and modern Linux it takes us even further. There are systems like policy Kit. If Pseudo is borrowing the master key for a command, policy Kit is even more specific. It's like giving a mechanic a key that only starts the engine diagnostics, not the whole car.

Speaker 1

Okay, more fine grained.

Speaker 2

Very fine grained. It lets specific applications, or even just parts of applications get the permissions they need only when they need them, minimizes the risk even more so. Building on that, there are a few key user management things you absolutely should do first. Adding users is simple. It's usually a doucer username, then password username to set their password.

Speaker 1

Basic stuff. Okay, but here's.

Speaker 2

Where the security really kicks in remote access. If you're allowing people to log in over the network using SSH, you must disable root log in via SSH. Absolutely critical.

Speaker 1

Why is that so critical?

Speaker 2

Think about it. Every attacker on the planet knows a user named root exists on Linux systems.

Speaker 1

It's a default. Ah, right, Half the puzzle already solved for them.

Speaker 2

Exactly. They only need to guess the password. But if you disable root log in, they have to guess a valid user name A and D the password much much harder. You do this in the SSH canfig file usually etceter shyest config. Just find the line permit root log in and set it to now.

Speaker 1

Simple change, big impact. Okay, what about the passwords themselves? People are terrible.

Speaker 2

At passwords, terribly predictable. Yeah, which is why you need strong password policies. Linux uses something called PAM pluggable authentication modules. Think of PAM as the rulebook for logging in. And there's a module pam cracklib that lets you enforce password.

Speaker 1

Rules like length and complexity Exactly.

Speaker 2

You can force a minimum length, say eight characters, are more require uppercase, lowercase numbers, symbols. You can even stop people reusing their last few passwords. That's good. Yeah, you can figure it, and the system just won't accept weak passwords anymore. It forces users to be more secure. And one more SSH s trick. You can restrict SSH access

to specific groups. So instead of letting any user on the system try to SSH in, you create a group, say schuizers, add only the people who need remote access.

Speaker 1

To that group, and tell SSH to only allow logins from that group precisely.

Speaker 2

Yeah, in the shotcunfig file again, you add a line like allow groups, Soelzers boom. Anyone else trying to log in remotely gets rejected instantly cuts down massively on brute force attempts.

Speaker 1

Wow. Okay, So taking all this together, what does it really mean for someone managing the Linux box, whether it's just their laptop or.

Speaker 2

A whole server means These aren't just you know, technical tweaks. They're fundamental. It's about accountability, knowing who did what. It's about limiting the blast radius if something goes wrong accidentally or maliciously. It makes the whole system way more robust, much harder to compromise. It's like building that fortress with a trusted crew and making sure everyone only has the keys they absolutely need, right, A.

Speaker 1

Trusted crew, limited keys. I like that. Okay, so we've got our crew sorted, keys managed. But even the best crew needs like a strong outer wall.

Speaker 3

Right.

Speaker 1

Let's talk firewalls. Server. Firewalls the gatekeeper for network traffic crucial air. So I think of it like the security checkpoint at a border crossing. It checks everything coming in that's ingress traffic and everything going out egress. Good analogy, And when we talk firewalls, we always hear about ports. These aren't physical things like USB ports, right, They're more like numbered lanes.

Speaker 2

Or docks exactly. They're virtual pathways in the operating system, different lanes for different types of traffic, like web traffic. Standard HTTP usually expects to arrive on port eighty. Secure web traffic HGTPS uses port four four to.

Speaker 1

Three, and SSH you mentioned is port twenty two.

Speaker 2

Right, So if you try to send, say, web traffic to port seventy nine, the system's just like, nope, nothing here for that. There's no service listening on that port number.

Speaker 1

Okay, So the firewall manages which of these lanes are open or closed.

Speaker 2

Precisely, and on many modern Linux systems, firewall cmd is the tool you use to talk to the firewall. The absolute core principle, the Golden rule is block everything by default. Start with all lanes closed, everything incoming.

Speaker 1

Yeah.

Speaker 2

Then you very deliberately open only the specific lanes the ports that you absolutely need for your services to work.

Speaker 1

Okay, So you minimize the attack surface right from the start exactly.

Speaker 2

Less open doors, less chance for unwanted guests. Firewalls also often use zones. Think of them as preset rule collections, like public, work, Home. Each zone has different default rules. Public is usually very restrictive. Home might be more trusting. You apply a zone to your network connection so you can.

Speaker 1

Quickly switch between security levels depending.

Speaker 2

On where you are kind of yeah, or just apply the right level of strictness from the start, and practically speaking, adding rules is straightforward. You might do ad service HTTP permanent to allow web traffic through. The permanent makes the change stick after a reboot.

Speaker 1

Or if you have a custom application, you can open.

Speaker 2

A specific port number like adport once into two to two TCP permanent if your app uses TCP ports. In teen twenty two. The power is in being explicit about what you allow in. You make conscious choices.

Speaker 1

And it sounds like firewall CND gives you a lot of control. You mentioned zones, services, specific ports. Can you get even more granular?

Speaker 2

Oh? Yeah, you can get really specific. You can block things like ICMP echo requests. That's the PIN command uses if you want.

Speaker 1

To be stuff, make the server invisible to basic scams.

Speaker 2

Sort of yeah. Or you can set up rules to only allow traffic from specific trusted IP addresses, like saying, only allow SSH connections from this specific office network.

Speaker 1

Okay, that's powerful. It's like having a security guard who not only checks IDs, but has a very specific guest list and knows who's definitely not allowed in exactly.

Speaker 2

It's about layers of control. Okay, So moving beyond that immediate network gate the firewall, we need to think about hardening the server itself and also protecting the data with encryption. These are the deeper foundations, maybe the internal vaults in our fortress analogy.

Speaker 1

Right, This stuff inside the walls first.

Speaker 2

And this sounds basic, but it's so important. Regular updates keep your system patched. That simple app get update and an app get upgrade command or whatever your district uses.

Speaker 1

The an F update on fedor sent to S.

Speaker 2

Right, it's not just about new features. It's mainly about fixing security holes that attackers are actively looking for. You have to keep it updated, non negotiable.

Speaker 1

Okay, what else you mentioned SSH earlier?

Speaker 2

Yes, for logins, SSH keys are way more secure than passwords. Instead of typing a password that could be guessed or cracked, you use a pair of cryptographic keys, one private kept secret on your machine, one public copied to the server.

Speaker 1

How do you set that up?

Speaker 2

Usually have stitsch again to create the keys, then stretch copy aid to securely copy the public key over. Once it's set up, you can log in without a password, but it's based on proving you possess the private key.

Speaker 1

Much stronger, nice, passwordless, but more secure. I like it? And what about adding another layer?

Speaker 2

Two factor authentication to FA Absolutely Even if someone somehow steals you your sshkey or your password, they still need that second factor, usually a code from an app on your phone, like Google Authenticator or offee. There are PAM modules for this too, like limpam Google Authenticator that make it relatively easy to add two FA to SSH logins on Linux.

Speaker 1

Extra hoop for attackers to jump through. Good.

Speaker 2

Then there's something called Sylinic Security Enhanced Linux or a PARMER, which is similar. This is well, it's a powerful deeper layer. It uses Mandatory Access Control MC.

Speaker 1

Mandatory access control.

Speaker 2

So standard Linux security is discretionary access control DAC user's own files and can decide who gets access MC is different. Sylinics applies system wide security policies that even the root user can't easily override. It watches every process and file access and enforces strict rules about what's allowed to interact with what like an.

Speaker 1

Internal affairs division for the operating system huh yeah, kind of.

Speaker 2

It has modes like permissive where it just logs violations and enforcing, where it actively blocks things that the rules. It can be complex to manage, but it adds a huge amount of security if configured properly.

Speaker 1

Okay, sounds heavy duty.

Speaker 2

It is then something a bit more practical for dealing with those log in attempts we talked about fail to ban. This is a great little tool. It watches system logs like your SSH log in attempts. If it sees the same IP address failing to log in multiple times within a short period.

Speaker 1

It assumes it's a brute force attack.

Speaker 2

Exactly, and it automatically updates your firewall rules to just block that IP address entirely for set amount.

Speaker 1

Of time, so it slams the door shut on them automatically.

Speaker 2

Pretty much. You can configure how many tries they get max retree and how long they get banned ban time. Very effective against noisy, persistent attackers.

Speaker 1

Okay, wow, updates keys two fa Sylenix failed to ban. That's quite a list for hardening. What about the absolute last resort? If everything fails?

Speaker 2

Backups? You absolutely must have a solid backup strategy. The gold standard is the three to two to one backup rule.

Speaker 1

Three two to one.

Speaker 2

What's that Three copies of your important data on at least two different types of storage media, and critically, at least one of those copies must be off site, off.

Speaker 1

Site like physically somewhere else or in the cloud.

Speaker 2

Either physically separate is best against things like fire or theft. Cloud works too. The point is, if your main location is compromised or destroyed, you still have a recoverable copy elsewhere. It's your ultimate safety net.

Speaker 1

Makes total sense. Okay, so that covers hardening the server but what about the actual data sitting on the hard drives inside those vaults. How do we protect that if someone, say, steals the server or pulls the drive.

Speaker 2

Yeah, good question. That's where encryption comes in, specifically encryption at rest. Linux supports various ways to encrypt things. Passwords stored by the system are hashed using strong algorithms. Communications can be secured with things like pgp SSLTLS for websites, and SSH itself encrypts the connection right data in transit exactly. But for data at rest, the files sitting on the disc, you need tools like gm MPG for encrypting individual files

or very crypt for creating encrypted containers or drives. But the real standard for Linux disc encryption is crypt setup, usually using the LAKS standard Linux Unified.

Speaker 1

Key Setup LUKS. Okay, what does that do?

Speaker 2

LUKS lets you encrypt entire hard drive partitions or even the swap space where temporary data might be stored. When the system boots, you have to enter a passphrase to unlock the encrypted volume. Without that passphrase, the data on the drive is just complete gibberish, unreadable.

Speaker 1

So even if someone physically steals the.

Speaker 2

Hard drive, the data is useless. To them without the key. It's a critical layer for protecting sensitive information. If the physical hardware is compromised, it turns your data into an indecipherable block.

Speaker 1

Wow. Okay, that's incredibly important. Encryption at rest with luks.

Speaker 2

Got it all? Right? So we've spent a lot of time talking about building this really impressive digital fortress, right user accounts, firewalls, hardening the server itself, encrypting the data. But how do you know? How do you know if all that work actually holds up against someone trying to get in? Ah?

Speaker 1

The million dollar question.

Speaker 2

This brings us to the flip side, the world of penetration testing or pen.

Speaker 1

Testing offensive security, and the go to tool for this.

Speaker 2

The district you mentioned earlier is Collie Linux. This specialized toolkit.

Speaker 1

That's the one it comes pre loaded with. Yeah, hundreds of tools designed specifically for testing security, finding vulnerabilities.

Speaker 2

So how do the pros actually use this stuff? Is it just randomly trying tools? Oh? No, not at all. There's a methodology, a structure. It's often called the penetration testing life cycle, usually described in five stages. You can think of it like a military operation, almost scouting and then engaging a target.

Speaker 1

Okay, lay it out for us. Stage one.

Speaker 2

Stage one is reconnaissance. Recon just like scouting enemy territory. You're gathering information about your target anything you can find publicly, websites, employee names, technologies they use, maybe even some non public info if you can get it ethically. It's about understanding the landscape, building intel.

Speaker 1

Okay. Stage two.

Speaker 2

Stage two is scanning. Now you start actively probing the target, using tools to find out which computers are actually online, what ports are open on those machines, what services are running on those ports, maybe even what operating system they're using.

Speaker 1

Like that scout reporting back with a detailed map of the enemy camp. There's a guard tower here, barracks there.

Speaker 2

Exactly like that. You're building a technical blueprint.

Speaker 1

Of their defenses. Got it? Stage three.

Speaker 2

Stage three is exploitation or gaining access. This is where you take the information from scanning and try to actually use a vulnerability to get inside. Maybe there's an old unpatched service running, or a week password you discovered. You try to leverage that weakness to gain unauthorized access.

Speaker 1

Finding the open door, climbing the weak wall right.

Speaker 2

Stage four is maintaining access once you're in You often want to make sure you can get back in later, so you might install some kind of persistent backdoor or create another user account.

Speaker 1

The goals to maintain your foothold, and the final stage.

Speaker 2

Stage five reporting. This is absolutely critical, especially for professional pent testers. You have to document everything you did, how you got in, what vulnerabilities you used, what data you could access, the potential impact, and crucially you provide recommendations on how to fix the weaknesses you found. It's the debriefing after the mission, telling the defenders how to strengthen their walls.

Speaker 1

That makes perfect sense, a structured approach. And just to give people a taste that scanning stage stage two where you're building the blueprint. What were some common tools used there besides Collie itself?

Speaker 2

Sure, well, the simplest is probably PA just sends a little packet to see if a machine replies, is it even online? Basic check?

Speaker 1

Okay, simple but useful. Then there's trace route or tracert on Windows. This maps out the network path between you and the target. It shows you all the routers, the hops your data goes through to get there, gives you an idea of the network layout.

Speaker 2

Like following the roads on a map.

Speaker 1

Exactly. But the real powerhouse, the king of network scanner is NMP Network.

Speaker 2

Mapper ah n MAP heard of that one.

Speaker 1

It's incredibly versatile. It can do way more than just PA and D. It can scan a whole range of IP addresses, find all the open ports on each live host, tell you what service it thinks is running on each port, like web server, SSH database, and it can even make a pretty good guess at the operating system the target is running. It uses various techniques to figure this out.

Speaker 2

Wow, So it's like x ray vision for the network pretty much.

Speaker 1

Yeah.

Speaker 2

It can even adjust how noisy or sneaky it is. There are timing options like Mattish T zero for paranoid, which is super slow and stealthy, up to natash T five for insane, which is really fast but very obvious.

Speaker 1

So knowing these tools isn't just for attackers, right. Defenders need to know what they look like from the outside.

Speaker 2

Absolutely. You run these scans against your own systems to see what an attacker would see. It's part of validating your defenses. So you see, we've kind of covered the whole spectrum today, haven't. We started with just safely getting Linux running in a VM, then move through locking down users, building firewalls, hardening the server, encrypting data, and then finally looking at how those defenses are actually tested using these

pen testing techniques. The real power here, I think, is that Lenux gives you this incredible adaptability and all these tools to build and manage really secure systems yourself.

Speaker 1

Yeah.

Speaker 3

Absolutely, it's clear. It's not just one thing. Is that, it's layers understanding who can log in, what traffic gets through the firewall, how the data itself is protected, and then crucially knowing how to text all that it all works together as a strategy. It's definitely not just about having one strong lock on the front door. It's the whole system. So here's maybe a thought to leave you with today as you go about your digital life in this world is getting more complex online all the time.

Knowing how to build security and how to test it isn't really just for the IT pros anymore, is it. So think about this, What vulnerability might you know unknowingly be exposing right now? Could be something simple like a week password on an important account, or maybe an open port on your home router you didn't know, And based on what we've talked about today. What's maybe the simplest, most impactful first step you could take to start shoring that up. Just one thing to make yourself a little

bit safer we're thinking about anyway. Thank you for joining us on this deep dive into Linux security. Hope you found it useful and we invite you to keep learning

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android