October 7, 2025 • 22 mins
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
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
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
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
(00:20):
an ironclad digital fortress. That's what we're diving into today.
Speaker 2 (00:24):
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
(00:44):
some quiet advanced stuff.
Speaker 1 (00:45):
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,
(01:07):
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.
(01:30):
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 (01:51):
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.
(02:14):
Most modern ones do. Usually it's on by default.
Speaker 1 (02:17):
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 (02:29):
No, there are many hundreds.
Speaker 1 (02:30):
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 (02:42):
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 (02:56):
With, Okay, like in Toyota Cari of Linux.
Speaker 2 (02:59):
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 (03:15):
Right.
Speaker 2 (03:15):
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 (03:24):
There hundreds of them apparently, yeah, over.
Speaker 2 (03:26):
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 (03:46):
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 (04:00):
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 (04:11):
Just don't. Okay, why is it so bad? I mean
Windows has administrator.
Speaker 2 (04:14):
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
(04:35):
wipe your entire system, no questions asked. It has complete
total control.
Speaker 1 (04:39):
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 (04:50):
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 (05:07):
Oh really okay?
Speaker 2 (05:08):
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 (05:31):
Ah okay, so it's like you borrow the master key
for one specific lock, use it, and immediately end it.
Speaker 2 (05:36):
Back exactly that. It's temporary specific elevation of privileges.
Speaker 1 (05:40):
Which means if I accidentally run something nasty or make
that typo.
Speaker 2 (05:44):
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 (05:51):
It couldn't say, delete the entire operating.
Speaker 2 (05:53):
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
(06:14):
engine diagnostics, not the whole car.
Speaker 1 (06:18):
Okay, more fine grained.
Speaker 2 (06:19):
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 (06:39):
Basic stuff. Okay, but here's.
Speaker 2 (06:41):
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 (06:52):
Why is that so critical?
Speaker 2 (06:53):
Think about it. Every attacker on the planet knows a
user named root exists on Linux systems.
Speaker 1 (06:58):
It's a default. Ah, right, Half the puzzle already solved
for them.
Speaker 2 (07:01):
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 (07:18):
Simple change, big impact. Okay, what about the passwords themselves?
People are terrible.
Speaker 2 (07:23):
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 (07:38):
Rules like length and complexity Exactly.
Speaker 2 (07:40):
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
(08:01):
the system try to SSH in, you create a group,
say schuizers, add only the people who need remote access.
Speaker 1 (08:07):
To that group, and tell SSH to only allow logins
from that group precisely.
Speaker 2 (08:12):
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 (08:22):
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 (08:28):
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
(08:50):
keys they absolutely need, right, A.
Speaker 1 (08:51):
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 (09:00):
Right.
Speaker 1 (09:00):
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
(09:22):
like numbered lanes.
Speaker 2 (09:24):
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 (09:39):
Three, and SSH you mentioned is port twenty two.
Speaker 2 (09:41):
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 (09:49):
Okay, So the firewall manages which of these lanes are
open or closed.
Speaker 2 (09:53):
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 (10:06):
Yeah.
Speaker 2 (10:07):
Then you very deliberately open only the specific lanes the
ports that you absolutely need for your services to work.
Speaker 1 (10:14):
Okay, So you minimize the attack surface right from the
start exactly.
Speaker 2 (10:17):
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 (10:36):
Quickly switch between security levels depending.
Speaker 2 (10:38):
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 (10:52):
Or if you have a custom application, you can open.
Speaker 2 (10:54):
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 (11:04):
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 (11:12):
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 (11:20):
To be stuff, make the server invisible to basic scams.
Speaker 2 (11:23):
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 (11:33):
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 (11:42):
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 (11:57):
Right, This stuff inside the walls first.
Speaker 2 (11:59):
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 (12:08):
The an F update on fedor sent to S.
Speaker 2 (12:10):
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 (12:19):
Okay, what else you mentioned SSH earlier?
Speaker 2 (12:22):
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 (12:37):
How do you set that up?
Speaker 2 (12:38):
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 (12:49):
Much stronger, nice, passwordless, but more secure. I like it?
And what about adding another layer?
Speaker 2 (12:55):
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 (13:14):
Extra hoop for attackers to jump through. Good.
Speaker 2 (13:17):
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 (13:28):
Mandatory access control.
Speaker 2 (13:29):
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
(13:49):
with what like an.
Speaker 1 (13:50):
Internal affairs division for the operating system huh yeah, kind of.
Speaker 2 (13:54):
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 (14:05):
Okay, sounds heavy duty.
Speaker 2 (14:06):
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 (14:21):
It assumes it's a brute force attack.
Speaker 2 (14:23):
Exactly, and it automatically updates your firewall rules to just
block that IP address entirely for set amount.
Speaker 1 (14:29):
Of time, so it slams the door shut on them automatically.
Speaker 2 (14:31):
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 (14:39):
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 (14:50):
Backups? You absolutely must have a solid backup strategy. The
gold standard is the three to two to one backup rule.
Speaker 1 (14:56):
Three two to one.
Speaker 2 (14:57):
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 (15:06):
Site like physically somewhere else or in the cloud.
Speaker 2 (15:09):
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 (15:21):
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 (15:33):
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.
(15:54):
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 (16:10):
Key Setup LUKS. Okay, what does that do?
Speaker 2 (16:12):
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 (16:26):
So even if someone physically steals the.
Speaker 2 (16:28):
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 (16:40):
Wow. Okay, that's incredibly important. Encryption at rest with luks.
Speaker 2 (16:47):
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 (17:04):
The million dollar question.
Speaker 2 (17:05):
This brings us to the flip side, the world of
penetration testing or pen.
Speaker 1 (17:10):
Testing offensive security, and the go to tool for this.
Speaker 2 (17:13):
The district you mentioned earlier is Collie Linux. This specialized toolkit.
Speaker 1 (17:17):
That's the one it comes pre loaded with. Yeah, hundreds
of tools designed specifically for testing security, finding vulnerabilities.
Speaker 2 (17:23):
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 (17:41):
Okay, lay it out for us. Stage one.
Speaker 2 (17:43):
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 (18:01):
Okay. Stage two.
Speaker 2 (18:03):
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 (18:16):
Like that scout reporting back with a detailed map of
the enemy camp. There's a guard tower here, barracks there.
Speaker 2 (18:22):
Exactly like that. You're building a technical blueprint.
Speaker 1 (18:24):
Of their defenses. Got it? Stage three.
Speaker 2 (18:27):
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 (18:46):
Finding the open door, climbing the weak wall right.
Speaker 2 (18:49):
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 (18:58):
The goals to maintain your foothold, and the final stage.
Speaker 2 (19:02):
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 (19:21):
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 (19:33):
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 (19:40):
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 (19:54):
Like following the roads on a map.
Speaker 1 (19:56):
Exactly. But the real powerhouse, the king of network scanner
is NMP Network.
Speaker 2 (20:02):
Mapper ah n MAP heard of that one.
Speaker 1 (20:05):
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 (20:24):
Wow, So it's like x ray vision for the network
pretty much.
Speaker 1 (20:27):
Yeah.
Speaker 2 (20:27):
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 (20:40):
So knowing these tools isn't just for attackers, right. Defenders
need to know what they look like from the outside.
Speaker 2 (20:45):
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
(21:08):
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 (21:17):
Yeah.
Speaker 3 (21:18):
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
(21:40):
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
(22:01):
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
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
(00:20):
an ironclad digital fortress. That's what we're diving into today.
Speaker 2 (00:24):
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
(00:44):
some quiet advanced stuff.
Speaker 1 (00:45):
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,
(01:07):
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.
(01:30):
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 (01:51):
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.
(02:14):
Most modern ones do. Usually it's on by default.
Speaker 1 (02:17):
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 (02:29):
No, there are many hundreds.
Speaker 1 (02:30):
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 (02:42):
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 (02:56):
With, Okay, like in Toyota Cari of Linux.
Speaker 2 (02:59):
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 (03:15):
Right.
Speaker 2 (03:15):
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 (03:24):
There hundreds of them apparently, yeah, over.
Speaker 2 (03:26):
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 (03:46):
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 (04:00):
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 (04:11):
Just don't. Okay, why is it so bad? I mean
Windows has administrator.
Speaker 2 (04:14):
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
(04:35):
wipe your entire system, no questions asked. It has complete
total control.
Speaker 1 (04:39):
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 (04:50):
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 (05:07):
Oh really okay?
Speaker 2 (05:08):
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 (05:31):
Ah okay, so it's like you borrow the master key
for one specific lock, use it, and immediately end it.
Speaker 2 (05:36):
Back exactly that. It's temporary specific elevation of privileges.
Speaker 1 (05:40):
Which means if I accidentally run something nasty or make
that typo.
Speaker 2 (05:44):
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 (05:51):
It couldn't say, delete the entire operating.
Speaker 2 (05:53):
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
(06:14):
engine diagnostics, not the whole car.
Speaker 1 (06:18):
Okay, more fine grained.
Speaker 2 (06:19):
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 (06:39):
Basic stuff. Okay, but here's.
Speaker 2 (06:41):
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 (06:52):
Why is that so critical?
Speaker 2 (06:53):
Think about it. Every attacker on the planet knows a
user named root exists on Linux systems.
Speaker 1 (06:58):
It's a default. Ah, right, Half the puzzle already solved
for them.
Speaker 2 (07:01):
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 (07:18):
Simple change, big impact. Okay, what about the passwords themselves?
People are terrible.
Speaker 2 (07:23):
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 (07:38):
Rules like length and complexity Exactly.
Speaker 2 (07:40):
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
(08:01):
the system try to SSH in, you create a group,
say schuizers, add only the people who need remote access.
Speaker 1 (08:07):
To that group, and tell SSH to only allow logins
from that group precisely.
Speaker 2 (08:12):
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 (08:22):
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 (08:28):
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
(08:50):
keys they absolutely need, right, A.
Speaker 1 (08:51):
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 (09:00):
Right.
Speaker 1 (09:00):
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
(09:22):
like numbered lanes.
Speaker 2 (09:24):
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 (09:39):
Three, and SSH you mentioned is port twenty two.
Speaker 2 (09:41):
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 (09:49):
Okay, So the firewall manages which of these lanes are
open or closed.
Speaker 2 (09:53):
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 (10:06):
Yeah.
Speaker 2 (10:07):
Then you very deliberately open only the specific lanes the
ports that you absolutely need for your services to work.
Speaker 1 (10:14):
Okay, So you minimize the attack surface right from the
start exactly.
Speaker 2 (10:17):
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 (10:36):
Quickly switch between security levels depending.
Speaker 2 (10:38):
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 (10:52):
Or if you have a custom application, you can open.
Speaker 2 (10:54):
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 (11:04):
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 (11:12):
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 (11:20):
To be stuff, make the server invisible to basic scams.
Speaker 2 (11:23):
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 (11:33):
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 (11:42):
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 (11:57):
Right, This stuff inside the walls first.
Speaker 2 (11:59):
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 (12:08):
The an F update on fedor sent to S.
Speaker 2 (12:10):
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 (12:19):
Okay, what else you mentioned SSH earlier?
Speaker 2 (12:22):
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 (12:37):
How do you set that up?
Speaker 2 (12:38):
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 (12:49):
Much stronger, nice, passwordless, but more secure. I like it?
And what about adding another layer?
Speaker 2 (12:55):
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 (13:14):
Extra hoop for attackers to jump through. Good.
Speaker 2 (13:17):
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 (13:28):
Mandatory access control.
Speaker 2 (13:29):
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
(13:49):
with what like an.
Speaker 1 (13:50):
Internal affairs division for the operating system huh yeah, kind of.
Speaker 2 (13:54):
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 (14:05):
Okay, sounds heavy duty.
Speaker 2 (14:06):
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 (14:21):
It assumes it's a brute force attack.
Speaker 2 (14:23):
Exactly, and it automatically updates your firewall rules to just
block that IP address entirely for set amount.
Speaker 1 (14:29):
Of time, so it slams the door shut on them automatically.
Speaker 2 (14:31):
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 (14:39):
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 (14:50):
Backups? You absolutely must have a solid backup strategy. The
gold standard is the three to two to one backup rule.
Speaker 1 (14:56):
Three two to one.
Speaker 2 (14:57):
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 (15:06):
Site like physically somewhere else or in the cloud.
Speaker 2 (15:09):
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 (15:21):
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 (15:33):
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.
(15:54):
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 (16:10):
Key Setup LUKS. Okay, what does that do?
Speaker 2 (16:12):
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 (16:26):
So even if someone physically steals the.
Speaker 2 (16:28):
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 (16:40):
Wow. Okay, that's incredibly important. Encryption at rest with luks.
Speaker 2 (16:47):
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 (17:04):
The million dollar question.
Speaker 2 (17:05):
This brings us to the flip side, the world of
penetration testing or pen.
Speaker 1 (17:10):
Testing offensive security, and the go to tool for this.
Speaker 2 (17:13):
The district you mentioned earlier is Collie Linux. This specialized toolkit.
Speaker 1 (17:17):
That's the one it comes pre loaded with. Yeah, hundreds
of tools designed specifically for testing security, finding vulnerabilities.
Speaker 2 (17:23):
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 (17:41):
Okay, lay it out for us. Stage one.
Speaker 2 (17:43):
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 (18:01):
Okay. Stage two.
Speaker 2 (18:03):
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 (18:16):
Like that scout reporting back with a detailed map of
the enemy camp. There's a guard tower here, barracks there.
Speaker 2 (18:22):
Exactly like that. You're building a technical blueprint.
Speaker 1 (18:24):
Of their defenses. Got it? Stage three.
Speaker 2 (18:27):
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 (18:46):
Finding the open door, climbing the weak wall right.
Speaker 2 (18:49):
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 (18:58):
The goals to maintain your foothold, and the final stage.
Speaker 2 (19:02):
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 (19:21):
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 (19:33):
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 (19:40):
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 (19:54):
Like following the roads on a map.
Speaker 1 (19:56):
Exactly. But the real powerhouse, the king of network scanner
is NMP Network.
Speaker 2 (20:02):
Mapper ah n MAP heard of that one.
Speaker 1 (20:05):
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 (20:24):
Wow, So it's like x ray vision for the network
pretty much.
Speaker 1 (20:27):
Yeah.
Speaker 2 (20:27):
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 (20:40):
So knowing these tools isn't just for attackers, right. Defenders
need to know what they look like from the outside.
Speaker 2 (20:45):
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
(21:08):
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 (21:17):
Yeah.
Speaker 3 (21:18):
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
(21:40):
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
(22:01):
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
Popular Podcasts
My Favorite Murder with Karen Kilgariff and Georgia Hardstark
My Favorite Murder is a true crime comedy podcast hosted by Karen Kilgariff and Georgia Hardstark. Each week, Karen and Georgia share compelling true crimes and hometown stories from friends and listeners. Since MFM launched in January of 2016, Karen and Georgia have shared their lifelong interest in true crime and have covered stories of infamous serial killers like the Night Stalker, mysterious cold cases, captivating cults, incredible survivor stories and important events from history like the Tulsa race massacre of 1921. My Favorite Murder is part of the Exactly Right podcast network that provides a platform for bold, creative voices to bring to life provocative, entertaining and relatable stories for audiences everywhere. The Exactly Right roster of podcasts covers a variety of topics including historic true crime, comedic interviews and news, science, pop culture and more. Podcasts on the network include Buried Bones with Kate Winkler Dawson and Paul Holes, That's Messed Up: An SVU Podcast, This Podcast Will Kill You, Bananas and more.
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com