WEBVTT

1
00:00:00.080 --> 00:00:03.200
<v Speaker 1>Okay, let's unpack this Linux thing. I mean, it's absolutely everywhere,

2
00:00:03.200 --> 00:00:03.600
<v Speaker 1>isn't it.

3
00:00:03.600 --> 00:00:04.559
<v Speaker 2>It really is your.

4
00:00:04.480 --> 00:00:09.000
<v Speaker 1>Phone, those huge data centers basically running the Internet. It's

5
00:00:09.080 --> 00:00:12.359
<v Speaker 1>kind of the silent backbone, the workhorse. But yeah, with

6
00:00:12.439 --> 00:00:16.800
<v Speaker 1>that power comes responsibility and well, vulnerability if you're not careful,

7
00:00:16.839 --> 00:00:19.800
<v Speaker 1>right exactly, So today we're taking a deep dive. We're

8
00:00:19.800 --> 00:00:22.519
<v Speaker 1>getting into Linux security and hardening.

9
00:00:22.640 --> 00:00:25.239
<v Speaker 2>We are, and you know, there's this common idea, maybe

10
00:00:25.280 --> 00:00:28.120
<v Speaker 2>a bit dangerous, that Linux is just secure out of

11
00:00:28.120 --> 00:00:30.199
<v Speaker 2>the box. Yeah, I had that a lot, but it's

12
00:00:30.760 --> 00:00:34.759
<v Speaker 2>it's really a misconception. An untouched Linux system often not

13
00:00:34.880 --> 00:00:38.320
<v Speaker 2>secure enough for the real world. Our guide today is

14
00:00:38.359 --> 00:00:42.000
<v Speaker 2>mostly from Mastering Linux Security and Hardening, second edition by

15
00:00:42.079 --> 00:00:46.280
<v Speaker 2>Donald da Tavault. It's pretty comprehensive its source definitely, and

16
00:00:46.359 --> 00:00:48.439
<v Speaker 2>our mission here is to pull out those key bits

17
00:00:48.439 --> 00:00:50.799
<v Speaker 2>of knowledge. We want you to get not just what

18
00:00:50.880 --> 00:00:53.359
<v Speaker 2>makes Linux secure, but why it matters and you know

19
00:00:53.399 --> 00:00:54.640
<v Speaker 2>how you can actually do it.

20
00:00:54.880 --> 00:00:57.520
<v Speaker 1>Think of this as your shortcut, maybe getting you up

21
00:00:57.560 --> 00:01:01.759
<v Speaker 1>to speed on something super critical with hopefully some surprising

22
00:01:01.799 --> 00:01:03.159
<v Speaker 1>facts and useful takeaways.

23
00:01:03.359 --> 00:01:04.359
<v Speaker 2>Let's get into it.

24
00:01:04.359 --> 00:01:09.159
<v Speaker 1>Okay, So first things first, security breaches on Linux. We

25
00:01:09.200 --> 00:01:13.680
<v Speaker 1>often picture like these super skilled hackers in dark rooms, right,

26
00:01:14.120 --> 00:01:16.439
<v Speaker 1>but it's not always like that. Why do they happen?

27
00:01:16.560 --> 00:01:19.920
<v Speaker 2>Yeah, you've hit on a really key point there. Sure

28
00:01:19.959 --> 00:01:25.200
<v Speaker 2>sophisticated attacks exist, but honestly a lot of breaches, maybe

29
00:01:25.239 --> 00:01:29.439
<v Speaker 2>even most boiled down to stuff that's preventable, like what well,

30
00:01:29.519 --> 00:01:31.879
<v Speaker 2>security bugs in the OS, or apps that just haven't

31
00:01:31.920 --> 00:01:35.439
<v Speaker 2>been patched, or and this is huge, admin's just not

32
00:01:35.519 --> 00:01:37.000
<v Speaker 2>applying updates quickly enough.

33
00:01:37.079 --> 00:01:39.959
<v Speaker 1>Ah, procrastination the enemy of security.

34
00:01:39.680 --> 00:01:43.040
<v Speaker 2>It can be. But another massive one, often overlooked, is

35
00:01:43.079 --> 00:01:47.560
<v Speaker 2>just poorly configured servers. You know, standard install often pretty

36
00:01:47.560 --> 00:01:50.760
<v Speaker 2>insecure by default, really out of the box. Yeah, and

37
00:01:50.799 --> 00:01:53.760
<v Speaker 2>this isn't just servers anymore. Think about IoT devices, so

38
00:01:53.879 --> 00:01:56.959
<v Speaker 2>many red Linux and they get deployed without proper security checks.

39
00:01:56.959 --> 00:01:59.239
<v Speaker 2>It's creating a huge attack surface.

40
00:01:59.319 --> 00:02:02.640
<v Speaker 1>Wow, poor configured servers, that's a big takeaway right there.

41
00:02:02.640 --> 00:02:04.680
<v Speaker 1>It's not just about fighting off attackers, but building the

42
00:02:04.719 --> 00:02:05.760
<v Speaker 1>defenses right from the.

43
00:02:05.719 --> 00:02:07.640
<v Speaker 2>Start, exactly the fundamentals.

44
00:02:07.879 --> 00:02:11.800
<v Speaker 1>So if they're often insecure initially, how do we even

45
00:02:11.879 --> 00:02:15.000
<v Speaker 1>start practicing hardening? I mean, you don't want to experiment

46
00:02:15.039 --> 00:02:16.680
<v Speaker 1>on a live server, right? That sounds bad?

47
00:02:16.879 --> 00:02:18.680
<v Speaker 2>Oh? You definitely don't want to do that, and that

48
00:02:18.759 --> 00:02:21.840
<v Speaker 2>means is a super important question. How do you practice safely?

49
00:02:22.240 --> 00:02:22.520
<v Speaker 1>Yeah?

50
00:02:22.599 --> 00:02:26.719
<v Speaker 2>Virtual machines vms are absolutely fantastic for this. Tools like

51
00:02:27.400 --> 00:02:30.280
<v Speaker 2>virtual Box. They let you run a whole Linux sous

52
00:02:30.319 --> 00:02:34.080
<v Speaker 2>inside your current one. It's a sandbox, fullly isolated, totally isolated.

53
00:02:34.159 --> 00:02:36.400
<v Speaker 2>If you mess it up, if you completely trash it

54
00:02:36.439 --> 00:02:39.560
<v Speaker 2>while learning, yeah, no harm done, just delete it start again. Yeah,

55
00:02:39.599 --> 00:02:43.080
<v Speaker 2>and it lets you simulate different setups too. Physical virtual

56
00:02:43.280 --> 00:02:45.960
<v Speaker 2>cloud each has slightly different security things to think about.

57
00:02:46.120 --> 00:02:49.199
<v Speaker 1>Builds that muscle memory without the risk. Okay, good tip.

58
00:02:49.800 --> 00:02:53.159
<v Speaker 1>And related to that, maybe the most basic thing but

59
00:02:53.280 --> 00:02:57.199
<v Speaker 1>often missed. Staying updated seems like a no brainer.

60
00:02:57.319 --> 00:02:59.960
<v Speaker 2>It does seem obvious, doesn't it. But timely updates are

61
00:03:00.000 --> 00:03:02.319
<v Speaker 2>absolutely critical. It's often your very first line of defense

62
00:03:02.360 --> 00:03:03.479
<v Speaker 2>against known exploits.

63
00:03:03.560 --> 00:03:05.039
<v Speaker 1>So how do we handle that on Linux?

64
00:03:05.240 --> 00:03:07.919
<v Speaker 2>Well, for Aubuntu, you can set up automatic updates. For

65
00:03:08.039 --> 00:03:10.960
<v Speaker 2>red Hat CentOS, there's D and F automatic does a

66
00:03:11.000 --> 00:03:14.319
<v Speaker 2>similar job. Easy enough, but there's a catch. It's a

67
00:03:14.319 --> 00:03:17.039
<v Speaker 2>bit of a balancing act. Automatic updates are convenient, sure,

68
00:03:17.439 --> 00:03:20.360
<v Speaker 2>but often you need a reboot for the changes, especially

69
00:03:20.479 --> 00:03:25.039
<v Speaker 2>kernel updates, to actually take effect the dreaded reboot exactly.

70
00:03:25.360 --> 00:03:27.240
<v Speaker 2>So you need to decide what works for your setup.

71
00:03:27.360 --> 00:03:31.400
<v Speaker 2>A home lab reboot, whenever a critical production server. You

72
00:03:31.400 --> 00:03:34.360
<v Speaker 2>need to plan that carefully. Just remember that saying, you know,

73
00:03:34.439 --> 00:03:36.639
<v Speaker 2>the only one hundred percent secure system is one that's

74
00:03:36.639 --> 00:03:39.759
<v Speaker 2>turned off and unplugged. Updates get you closer while keeping

75
00:03:39.759 --> 00:03:40.400
<v Speaker 2>the lights.

76
00:03:40.159 --> 00:03:43.719
<v Speaker 1>On right, manage the risk. Okay, so system patched, we're

77
00:03:43.719 --> 00:03:48.080
<v Speaker 1>practicing safely. What's next? Who gets in user accounts, especially

78
00:03:48.120 --> 00:03:51.199
<v Speaker 1>that all powerful route user. What's the deal there? Bad

79
00:03:51.240 --> 00:03:52.439
<v Speaker 1>idea to use it all the time?

80
00:03:52.639 --> 00:03:56.280
<v Speaker 2>Oh? Absolutely bad idea. Logging in is root for everyday stuff.

81
00:03:56.520 --> 00:03:59.560
<v Speaker 2>You're basically doing half the attacker's job for them. How so,

82
00:04:00.280 --> 00:04:03.240
<v Speaker 2>because if that account gets compromised, they instantly have full control.

83
00:04:03.360 --> 00:04:06.479
<v Speaker 2>Game over. Okay, that's why Pseudo is so essential. It's

84
00:04:06.520 --> 00:04:11.039
<v Speaker 2>incredibly powerful. It lets specific users run admin tasks using

85
00:04:11.039 --> 00:04:11.879
<v Speaker 2>their own password.

86
00:04:12.120 --> 00:04:14.120
<v Speaker 1>Ah, so you don't share the root.

87
00:04:13.919 --> 00:04:18.079
<v Speaker 2>Password exactly, keep that root password locked down. Plus, Pseudo

88
00:04:18.120 --> 00:04:21.519
<v Speaker 2>gives you much better auditing. Every command run with Pseudo

89
00:04:21.560 --> 00:04:25.000
<v Speaker 2>gets logged. You know who did what when with root?

90
00:04:25.399 --> 00:04:26.600
<v Speaker 2>Much harder to track.

91
00:04:26.480 --> 00:04:29.120
<v Speaker 1>Makes sense. So Pseudo isn't just like on or off.

92
00:04:29.319 --> 00:04:30.879
<v Speaker 1>You can fine tune the permissions.

93
00:04:30.879 --> 00:04:33.959
<v Speaker 2>Oh definitely, that's its real strength, granularity.

94
00:04:34.120 --> 00:04:36.560
<v Speaker 1>But are there common ways people mess it up, like

95
00:04:36.839 --> 00:04:39.120
<v Speaker 1>trying to be secure but creating a loophole.

96
00:04:39.279 --> 00:04:43.160
<v Speaker 2>That's a great question. Yes, the powers and the details,

97
00:04:43.240 --> 00:04:46.120
<v Speaker 2>and so are the risks. Pseudo policies let you give

98
00:04:46.199 --> 00:04:49.040
<v Speaker 2>users only the specific commands they need. You can create

99
00:04:49.079 --> 00:04:52.560
<v Speaker 2>aliases like in software alias. Maybe let someone run RPM

100
00:04:52.639 --> 00:04:56.199
<v Speaker 2>or Yum's root but nothing else but pitfalls. Oh yeah,

101
00:04:56.240 --> 00:04:59.240
<v Speaker 2>being careless with shell escapes. That's when a user finds

102
00:04:59.240 --> 00:05:01.040
<v Speaker 2>a clever way to break out of the allowed command

103
00:05:01.079 --> 00:05:04.160
<v Speaker 2>and run arbitrary stuff anyway, kind of bypasses your rules.

104
00:05:04.160 --> 00:05:07.279
<v Speaker 2>Sneaky or letting users run their own scripts with pseudo.

105
00:05:07.720 --> 00:05:10.720
<v Speaker 2>That script could contain anything. A key fix is to

106
00:05:10.759 --> 00:05:14.240
<v Speaker 2>move necessary scripts to secure directories owned by root where

107
00:05:14.279 --> 00:05:15.920
<v Speaker 2>regular users can't just edit them.

108
00:05:16.199 --> 00:05:21.240
<v Speaker 1>Got it control the scripts. So beyond pseudo, what about

109
00:05:21.240 --> 00:05:24.319
<v Speaker 1>the password itself? We always hear you strong passwords? Yea,

110
00:05:24.439 --> 00:05:26.120
<v Speaker 1>how do you actually enforce that on Linux?

111
00:05:26.279 --> 00:05:28.600
<v Speaker 2>Right? The p PLUW quality package that's your go to.

112
00:05:28.680 --> 00:05:31.079
<v Speaker 2>It's more than just length, okay, goople Quality lets you

113
00:05:31.079 --> 00:05:34.800
<v Speaker 2>set detailed rules like minimum length. Sure, but also needing

114
00:05:34.879 --> 00:05:39.680
<v Speaker 2>characters from different classes. You know, uppercase, lowercase numbers. Symbols

115
00:05:40.000 --> 00:05:42.120
<v Speaker 2>can even check against dictionaries.

116
00:05:41.600 --> 00:05:44.040
<v Speaker 1>Prevent password one, two, three exactly.

117
00:05:44.319 --> 00:05:48.759
<v Speaker 2>And here's something that kind of flips the script on passwords, passphrases.

118
00:05:48.800 --> 00:05:50.879
<v Speaker 1>Passphrases like multiple words.

119
00:05:50.639 --> 00:05:53.360
<v Speaker 2>Yeah, they can actually be way more secure and easier

120
00:05:53.360 --> 00:05:57.079
<v Speaker 2>to remember than complex gibberish. Think about P two or dollars.

121
00:05:57.639 --> 00:06:01.920
<v Speaker 2>Looks complex, but computers guess those substitutions easily. Now. A

122
00:06:01.959 --> 00:06:05.240
<v Speaker 2>phrase like I don't know, I really like green apples

123
00:06:05.240 --> 00:06:08.160
<v Speaker 2>simple for you, right, But the length gives it massive

124
00:06:08.439 --> 00:06:12.040
<v Speaker 2>entropy unpredictability, much much harder for an attacker to root

125
00:06:12.120 --> 00:06:16.079
<v Speaker 2>force compared to a shorter, complex password. Those space account.

126
00:06:15.680 --> 00:06:19.560
<v Speaker 1>Too, huh. Longer is better than just complex sometimes often yes.

127
00:06:20.399 --> 00:06:23.720
<v Speaker 2>And one more practical thing, don't forget account and password expiration.

128
00:06:24.319 --> 00:06:27.519
<v Speaker 2>Use tools like change user ad user mod make sure

129
00:06:27.639 --> 00:06:30.920
<v Speaker 2>old unused accounts don't just sit there waiting to become backdoors.

130
00:06:31.279 --> 00:06:34.399
<v Speaker 1>Good hygiene. Okay, so we've locked down the user the password,

131
00:06:34.519 --> 00:06:38.839
<v Speaker 1>but the server's still facing the internet, right that digital perimeter. Firewalls,

132
00:06:39.600 --> 00:06:41.000
<v Speaker 1>what's the Linux story there?

133
00:06:41.199 --> 00:06:45.360
<v Speaker 2>Firewalls are absolutely fundamental non negotiable. Part of that security

134
00:06:45.399 --> 00:06:49.759
<v Speaker 2>in depth idea layers. On Linux, the deep down engine

135
00:06:49.839 --> 00:06:53.759
<v Speaker 2>is net filter, but you don't usually poke net filter directly.

136
00:06:54.079 --> 00:06:56.720
<v Speaker 2>You use tools to manage its rules, like what like

137
00:06:56.759 --> 00:07:00.279
<v Speaker 2>the older iptables or newer things like firewalled. You've has

138
00:07:00.319 --> 00:07:03.240
<v Speaker 2>the uncomplicated firewall good Name or NF tables. Think of

139
00:07:03.279 --> 00:07:05.199
<v Speaker 2>netfilter as the engine. These are the dashboards.

140
00:07:05.240 --> 00:07:05.560
<v Speaker 1>Okay.

141
00:07:05.639 --> 00:07:08.399
<v Speaker 2>Firell is pretty neat uses zones, so you can easily

142
00:07:08.399 --> 00:07:11.319
<v Speaker 2>say this network card faces the scary internet, apply the

143
00:07:11.319 --> 00:07:14.680
<v Speaker 2>public zone rules, this one faces my safe internal network.

144
00:07:14.920 --> 00:07:17.839
<v Speaker 2>Use the trusted zone rules. Makes it much simpler and

145
00:07:17.959 --> 00:07:23.519
<v Speaker 2>has this cool feature panic mode. Firewall CMD panic on

146
00:07:23.800 --> 00:07:27.399
<v Speaker 2>BAM blocks all traffic instantly. Great if you think you're

147
00:07:27.439 --> 00:07:28.560
<v Speaker 2>under serious attack, a.

148
00:07:28.560 --> 00:07:29.240
<v Speaker 1>Big red button.

149
00:07:29.279 --> 00:07:30.199
<v Speaker 2>I like it exactly.

150
00:07:30.319 --> 00:07:32.959
<v Speaker 1>Okay, so the firewall, let's some traffic in. How do

151
00:07:33.040 --> 00:07:35.519
<v Speaker 1>we protect that traffic? Make sure it's private. Hasn't been

152
00:07:35.560 --> 00:07:36.800
<v Speaker 1>messed with? Encryption right?

153
00:07:37.000 --> 00:07:42.160
<v Speaker 2>Absolutely? Encryption is just fundamental today for single files, messages, GPG,

154
00:07:42.879 --> 00:07:44.800
<v Speaker 2>GNU privacy guard is fantastic.

155
00:07:44.839 --> 00:07:45.480
<v Speaker 1>How's that work?

156
00:07:45.600 --> 00:07:48.319
<v Speaker 2>Public private keys? You give out your public key freely.

157
00:07:48.639 --> 00:07:51.279
<v Speaker 2>Someone encrypts a message to you using that public key.

158
00:07:51.639 --> 00:07:54.519
<v Speaker 2>But only you with your secret private key can decrypt it.

159
00:07:54.600 --> 00:07:55.839
<v Speaker 2>No shared passwords needed.

160
00:07:55.920 --> 00:07:56.199
<v Speaker 1>Clever.

161
00:07:56.360 --> 00:07:58.759
<v Speaker 2>You can also digitally sign files with your private key,

162
00:07:59.160 --> 00:08:01.680
<v Speaker 2>proves it came from you and wasn't tampered with, like

163
00:08:01.720 --> 00:08:04.680
<v Speaker 2>the source mentioned signing a message for Frank the cat.

164
00:08:04.920 --> 00:08:06.600
<v Speaker 2>It's about trust and integrity.

165
00:08:06.680 --> 00:08:09.319
<v Speaker 1>Okay, so that's files. What about like the whole hard

166
00:08:09.399 --> 00:08:11.720
<v Speaker 1>drive or sensitive folders?

167
00:08:11.879 --> 00:08:15.959
<v Speaker 2>Right for encrypting the entire disc? Luks Linux unified key

168
00:08:16.040 --> 00:08:18.519
<v Speaker 2>setup is pretty much the standard on Linux. Someone steals

169
00:08:18.519 --> 00:08:21.199
<v Speaker 2>the laptop data is useless without the passphrase. For just

170
00:08:21.279 --> 00:08:24.199
<v Speaker 2>specific directories, maybe your home folder. Ecrypts is an option

171
00:08:24.759 --> 00:08:28.079
<v Speaker 2>and really important. If you're not doing full disc encryption,

172
00:08:28.480 --> 00:08:32.840
<v Speaker 2>you absolutely must encrypt your swamp partition. Why swap because

173
00:08:33.120 --> 00:08:36.919
<v Speaker 2>sensitive data like passwords or keys might temporarily get written

174
00:08:36.919 --> 00:08:40.000
<v Speaker 2>from RAM to the swap space on disc. If swamp

175
00:08:40.039 --> 00:08:42.440
<v Speaker 2>isn't encrypted, that data could be recovered later.

176
00:08:42.480 --> 00:08:44.440
<v Speaker 1>It's a sneaky leak ah Okay.

177
00:08:44.559 --> 00:08:47.200
<v Speaker 2>And if you need encrypted containers you can share across

178
00:08:47.200 --> 00:08:50.639
<v Speaker 2>different operating systems. Very crypt is still a very solid choice.

179
00:08:50.799 --> 00:08:55.279
<v Speaker 1>Gotcha and quickly Web security all those little padlock icons,

180
00:08:55.440 --> 00:08:57.159
<v Speaker 1>SSLTLS certificate.

181
00:08:56.840 --> 00:09:00.679
<v Speaker 2>Yeah, crucial point it's TLS now. Transport Layer security SSL

182
00:09:00.759 --> 00:09:04.159
<v Speaker 2>is old news. Insecure TLS is what secures your web

183
00:09:04.200 --> 00:09:06.840
<v Speaker 2>traffic and the certificates they prove the server is who

184
00:09:06.879 --> 00:09:09.240
<v Speaker 2>it claims to be, so you know you're really talking

185
00:09:09.279 --> 00:09:11.519
<v Speaker 2>to your bank, not a fake site. You have different

186
00:09:11.600 --> 00:09:14.799
<v Speaker 2>levels like EED certificates that require more validation. Supposed it

187
00:09:14.799 --> 00:09:17.399
<v Speaker 2>gives you that green bar in the browser. Well, studies

188
00:09:17.399 --> 00:09:20.240
<v Speaker 2>show users often don't even notice the green bar, and

189
00:09:20.320 --> 00:09:23.600
<v Speaker 2>sometimes they get issued incorrectly. On the flip side, free

190
00:09:23.639 --> 00:09:27.240
<v Speaker 2>services like let's encrypt have been amazing for getting everyone encrypted.

191
00:09:27.399 --> 00:09:31.000
<v Speaker 2>Huge win. But criminals use let's encrypt too. They get

192
00:09:31.039 --> 00:09:34.279
<v Speaker 2>free certificates for their fishing sites. So the site looks

193
00:09:34.360 --> 00:09:37.480
<v Speaker 2>legit has the padlock, but it's still malicious.

194
00:09:37.600 --> 00:09:40.840
<v Speaker 1>So encrypted doesn't automatically mean safe exactly.

195
00:09:41.000 --> 00:09:43.600
<v Speaker 2>It means the connection is private, but the site itself

196
00:09:43.639 --> 00:09:46.080
<v Speaker 2>might still be trying to scam you. Big difference.

197
00:09:46.240 --> 00:09:50.879
<v Speaker 1>Okay, let's shift to getting into the server remotely SSH

198
00:09:51.399 --> 00:09:54.320
<v Speaker 1>Secure shell. Most of us use it, but it feels

199
00:09:54.320 --> 00:09:56.120
<v Speaker 1>like a prime target if not set up right.

200
00:09:56.159 --> 00:10:00.519
<v Speaker 2>Oh, it absolutely is. Default SSH settings often way too permissive.

201
00:10:00.559 --> 00:10:03.360
<v Speaker 1>So what's the number gen hardening tip for sshke.

202
00:10:03.039 --> 00:10:06.759
<v Speaker 2>Based authentication, ditch passwords completely. If you can use.

203
00:10:06.679 --> 00:10:08.559
<v Speaker 1>SSH keys, Why is that so much better?

204
00:10:08.759 --> 00:10:11.159
<v Speaker 2>Because brute forcing a password computers are good at that,

205
00:10:11.279 --> 00:10:14.360
<v Speaker 2>trying millions of guesses per second. But to break in

206
00:10:14.399 --> 00:10:17.320
<v Speaker 2>with key off, the attacker needs your private key file

207
00:10:17.519 --> 00:10:20.879
<v Speaker 2>and his passphrase way way harder. Make simple broote force

208
00:10:20.919 --> 00:10:22.440
<v Speaker 2>attacks almost impossible.

209
00:10:22.679 --> 00:10:24.559
<v Speaker 1>Makes sense? What else? For SSH?

210
00:10:24.720 --> 00:10:28.279
<v Speaker 2>Definitely disabled direct route log in always, we should never

211
00:10:28.320 --> 00:10:30.799
<v Speaker 2>log in over SSH log in as a regular user,

212
00:10:30.840 --> 00:10:34.360
<v Speaker 2>then use pseudo okay, and there are tools like stand

213
00:10:34.399 --> 00:10:38.320
<v Speaker 2>that check your configuration for weaknesses. On red hat systems,

214
00:10:38.440 --> 00:10:41.720
<v Speaker 2>you can use system wide crypto policies to easily enforce

215
00:10:41.960 --> 00:10:44.759
<v Speaker 2>strong encryption algorithms for SSH and other services.

216
00:10:44.799 --> 00:10:47.000
<v Speaker 1>Takes out some guesswork, right, simplify.

217
00:10:46.600 --> 00:10:48.519
<v Speaker 2>Where you can. So, okay, we've hardened the way in.

218
00:10:49.000 --> 00:10:52.279
<v Speaker 2>But let's say someone still gets in worst case? How

219
00:10:52.320 --> 00:10:54.960
<v Speaker 2>do we limit the damage they can do inside on

220
00:10:55.000 --> 00:10:55.720
<v Speaker 2>the file system?

221
00:10:55.759 --> 00:10:58.279
<v Speaker 1>Okay? Now we're talking action control on the system itself.

222
00:10:58.399 --> 00:10:59.200
<v Speaker 1>Two main types.

223
00:11:01.039 --> 00:11:04.120
<v Speaker 2>The ac UMSI is discretionary access control. That's your basic

224
00:11:04.200 --> 00:11:08.240
<v Speaker 2>Lennux permissions. Shimode chanund who owns the file? They read it,

225
00:11:08.399 --> 00:11:11.559
<v Speaker 2>write it, execute it. The numbers like chamode seventy five

226
00:11:11.639 --> 00:11:14.080
<v Speaker 2>five or six forty four. Let you set this precisely

227
00:11:14.200 --> 00:11:18.799
<v Speaker 2>standard stuff standard but with a potential bombshell. SUID and sgid.

228
00:11:18.519 --> 00:11:20.919
<v Speaker 1>Bits you mentioned those sound risky.

229
00:11:21.000 --> 00:11:24.559
<v Speaker 2>They are if misused. SUID means set user ID. When

230
00:11:24.559 --> 00:11:27.039
<v Speaker 2>you run a program with the SUID bit, it runs

231
00:11:27.039 --> 00:11:29.000
<v Speaker 2>not as you, but it's in the owner of the file.

232
00:11:29.480 --> 00:11:31.240
<v Speaker 2>SUID is similar, but for the group.

233
00:11:31.480 --> 00:11:32.559
<v Speaker 1>Why would you ever need that?

234
00:11:33.000 --> 00:11:35.679
<v Speaker 2>The classic example is the password command you need to

235
00:11:35.720 --> 00:11:39.360
<v Speaker 2>change your password, which modifies a system file only Root

236
00:11:39.440 --> 00:11:43.759
<v Speaker 2>can write to. So password runs with Root privileges temporarily

237
00:11:44.080 --> 00:11:46.519
<v Speaker 2>just for that task thanks to SUID. Ah.

238
00:11:46.559 --> 00:11:51.559
<v Speaker 1>Okay, necessary evil, sometimes necessary, but dangerous if applied incorrectly.

239
00:11:52.039 --> 00:11:55.279
<v Speaker 2>Imagine a script owned by Root with the SUID bit

240
00:11:55.519 --> 00:11:58.440
<v Speaker 2>set that a regular user can run. If that script

241
00:11:58.440 --> 00:12:01.320
<v Speaker 2>has a flaw or just let you run command ends, boom,

242
00:12:01.440 --> 00:12:03.879
<v Speaker 2>the user gets Root access through that script.

243
00:12:04.080 --> 00:12:04.519
<v Speaker 1>Yikes.

244
00:12:04.720 --> 00:12:07.200
<v Speaker 2>That's why it's absolutely critical to use the noseue bount

245
00:12:07.240 --> 00:12:10.480
<v Speaker 2>option on partitions where users can write files like home

246
00:12:10.559 --> 00:12:14.000
<v Speaker 2>or THAJ prevents them from creating their own SUID programs.

247
00:12:14.039 --> 00:12:16.840
<v Speaker 1>Got it block that loophole. So if DASH, even with

248
00:12:16.960 --> 00:12:21.080
<v Speaker 1>no suit isn't enough, we get MAC Mandatory access control

249
00:12:21.320 --> 00:12:21.879
<v Speaker 1>sounds stricter.

250
00:12:22.039 --> 00:12:24.799
<v Speaker 2>It is stricter. MC systems like Celinix or a Parmer

251
00:12:25.000 --> 00:12:26.320
<v Speaker 2>add another layer entirely.

252
00:12:26.360 --> 00:12:27.639
<v Speaker 1>How's it different from DA?

253
00:12:27.799 --> 00:12:31.080
<v Speaker 2>With DA, you controlled the permissions on your files. With IMS,

254
00:12:31.159 --> 00:12:34.519
<v Speaker 2>the system policy dictates what processes can do, regardless of

255
00:12:34.559 --> 00:12:37.799
<v Speaker 2>who owns the file or which one says. It's centrally managed.

256
00:12:38.080 --> 00:12:40.799
<v Speaker 1>Mandatory control, so even root might be restricted.

257
00:12:40.919 --> 00:12:45.639
<v Speaker 2>Potentially yes. Selens used to have this reputation for being

258
00:12:45.720 --> 00:12:48.759
<v Speaker 2>incredibly complex and breaking things, so people just turned it off.

259
00:12:48.879 --> 00:12:50.320
<v Speaker 1>I've heard the horror stories.

260
00:12:50.399 --> 00:12:55.039
<v Speaker 2>It's gotten much better. It works by labeling everything, files, processes,

261
00:12:55.159 --> 00:12:59.960
<v Speaker 2>ports with security contexts. Then policies define how labels can interact,

262
00:13:00.200 --> 00:13:03.679
<v Speaker 2>like this web server process label can only read files

263
00:13:03.679 --> 00:13:04.919
<v Speaker 2>with the web content label.

264
00:13:05.080 --> 00:13:05.440
<v Speaker 1>Okay.

265
00:13:05.519 --> 00:13:09.399
<v Speaker 2>Labels and rules and tools like said troubleshoot help translate

266
00:13:09.440 --> 00:13:13.279
<v Speaker 2>this sometimes cryptic denial messages into plain English, often telling

267
00:13:13.279 --> 00:13:15.960
<v Speaker 2>you exactly how to fix it. That's helpful, hugely helpful,

268
00:13:16.200 --> 00:13:19.519
<v Speaker 2>and it's super relevant for containers. Now Celinux can stop

269
00:13:19.559 --> 00:13:23.039
<v Speaker 2>a compromised Docker container from escaping and attacking the host system.

270
00:13:23.200 --> 00:13:24.759
<v Speaker 2>That's a massive security.

271
00:13:24.360 --> 00:13:27.240
<v Speaker 1>Win right containing the container makes sense. Okay, so we've

272
00:13:27.279 --> 00:13:33.519
<v Speaker 1>locked down users, firewalls, encryption, access control. But security isn't static, right,

273
00:13:33.679 --> 00:13:35.240
<v Speaker 1>it's not set it and forget it. How do we

274
00:13:35.279 --> 00:13:35.679
<v Speaker 1>keep watching?

275
00:13:35.720 --> 00:13:36.120
<v Speaker 2>Absolutely?

276
00:13:36.200 --> 00:13:36.320
<v Speaker 1>Right?

277
00:13:36.360 --> 00:13:39.279
<v Speaker 2>Continuous monitoring is vital. You need visibility.

278
00:13:39.399 --> 00:13:40.519
<v Speaker 1>What tools help there?

279
00:13:40.840 --> 00:13:44.440
<v Speaker 2>The Linux auditing system Audit is incredibly powerful for this.

280
00:13:44.679 --> 00:13:47.519
<v Speaker 2>You can set up very specific rules to log exactly

281
00:13:47.559 --> 00:13:50.279
<v Speaker 2>what you care about. Uh, like log every time any

282
00:13:50.399 --> 00:13:52.679
<v Speaker 2>user twice to open or create a file. That's the

283
00:13:52.799 --> 00:13:56.159
<v Speaker 2>THIAS open it rule. Or you can use predefined rule sets,

284
00:13:56.159 --> 00:14:00.840
<v Speaker 2>maybe for compliance like PCIDSS that already cover common critical events.

285
00:14:00.519 --> 00:14:02.840
<v Speaker 1>So you get a detailed log of who's doing what

286
00:14:03.000 --> 00:14:03.360
<v Speaker 1>you do.

287
00:14:04.039 --> 00:14:07.600
<v Speaker 2>The challenge then is managing all those logs, maybe feeding

288
00:14:07.600 --> 00:14:10.679
<v Speaker 2>them into a central system. But having the raw data

289
00:14:11.000 --> 00:14:11.639
<v Speaker 2>is crucial.

290
00:14:11.840 --> 00:14:14.879
<v Speaker 1>Okay, logging tells us what happened. What about finding weaknesses

291
00:14:14.960 --> 00:14:17.320
<v Speaker 1>before they're exploited? Proactive searching?

292
00:14:17.440 --> 00:14:21.320
<v Speaker 2>Right? Vulnerability scanning? Essential tools like Linus are great for

293
00:14:21.360 --> 00:14:24.200
<v Speaker 2>host based scanning. Host based Yeah, you run Linus on

294
00:14:24.240 --> 00:14:27.120
<v Speaker 2>the Linux system itself. It digs deep into the configuration,

295
00:14:27.279 --> 00:14:31.279
<v Speaker 2>kernel settings, software versions and give you specific hardening advice.

296
00:14:32.039 --> 00:14:33.080
<v Speaker 2>Really thorough cool.

297
00:14:33.279 --> 00:14:35.600
<v Speaker 1>What about scanning from the outside.

298
00:14:35.080 --> 00:14:40.399
<v Speaker 2>For network scanning. OpenVAS is a powerful open source vulnerability scanner.

299
00:14:40.679 --> 00:14:43.840
<v Speaker 2>It checks for thousands of known vulnerabilities across your network

300
00:14:44.080 --> 00:14:47.480
<v Speaker 2>and for webservers specifically, nick Go is excellent. It looks

301
00:14:47.480 --> 00:14:53.559
<v Speaker 2>for common webserver misconfigurations, dangerous files left behind, risky HTDP methods.

302
00:14:53.240 --> 00:14:58.200
<v Speaker 1>Enabled, like finding a forgotten pass wd dot txt file.

303
00:14:58.039 --> 00:15:00.440
<v Speaker 2>Exactly that kind of thing. These scanners act like automated

304
00:15:00.480 --> 00:15:03.759
<v Speaker 2>penetration testers, finding the low hanging food before attackers do.

305
00:15:03.919 --> 00:15:08.759
<v Speaker 1>Okay, now, malware viruses the eternal question does Linux need

306
00:15:08.799 --> 00:15:10.759
<v Speaker 1>anti virus People say it's immune.

307
00:15:10.919 --> 00:15:14.000
<v Speaker 2>Immune is too strong a word. Highly resistant to traditional

308
00:15:14.000 --> 00:15:16.960
<v Speaker 2>Windows viruses yes, but totally immune to all.

309
00:15:16.799 --> 00:15:19.360
<v Speaker 1>Malware no, So run AV or not well.

310
00:15:19.399 --> 00:15:22.080
<v Speaker 2>The main reason people run av like ClamAV or Linux

311
00:15:22.080 --> 00:15:24.679
<v Speaker 2>Malware Detect l and D on Linux servers often isn't

312
00:15:24.720 --> 00:15:27.360
<v Speaker 2>to protect Linux itself. It's to stop the Linux server

313
00:15:27.440 --> 00:15:30.879
<v Speaker 2>from accidentally storing or sharing Windows viruses with other machines

314
00:15:30.919 --> 00:15:32.240
<v Speaker 2>on the network, like in a file.

315
00:15:32.039 --> 00:15:34.559
<v Speaker 1>Share, protecting the neighbors exactly.

316
00:15:35.200 --> 00:15:37.360
<v Speaker 2>Lm D is also pretty good at finding specific Linux

317
00:15:37.360 --> 00:15:40.720
<v Speaker 2>threats like webshells or rootkits, and if you find a

318
00:15:40.759 --> 00:15:44.360
<v Speaker 2>weird file services like virus total let you upload it

319
00:15:44.399 --> 00:15:47.559
<v Speaker 2>and scan it with dozens of av engines. Useful, very

320
00:15:47.879 --> 00:15:51.519
<v Speaker 2>but big caveat. Never upload sensitive or confidential fis to

321
00:15:51.600 --> 00:15:55.000
<v Speaker 2>virus Total or similar public services. Once it's up there,

322
00:15:55.240 --> 00:15:57.559
<v Speaker 2>it might become public use caution.

323
00:15:58.000 --> 00:16:02.840
<v Speaker 1>Good warning. Okay, gear slightly physical security. If someone can

324
00:16:02.879 --> 00:16:04.559
<v Speaker 1>just walk up to the machine.

325
00:16:04.159 --> 00:16:07.600
<v Speaker 2>Then all bets are off. Potentially physical access trump's almost

326
00:16:07.600 --> 00:16:08.919
<v Speaker 2>everything else it's off and overlooked.

327
00:16:08.919 --> 00:16:11.320
<v Speaker 1>So what can we do, especially for laptops or servers,

328
00:16:11.399 --> 00:16:13.000
<v Speaker 1>maybe not in a locked data center.

329
00:16:13.080 --> 00:16:17.200
<v Speaker 2>Password protect your bootloader GRUB. This stop someone from easily

330
00:16:17.240 --> 00:16:19.840
<v Speaker 2>booting into single user mode to reset the root password

331
00:16:20.240 --> 00:16:22.039
<v Speaker 2>or adding weird kernel parameters.

332
00:16:22.080 --> 00:16:24.480
<v Speaker 1>Does that stop them booting from a USB stick?

333
00:16:24.679 --> 00:16:27.639
<v Speaker 2>No, it doesn't stop that entirely, but it's an important

334
00:16:27.679 --> 00:16:30.799
<v Speaker 2>layer against casual attacks or someone trying to quickly bypass

335
00:16:30.879 --> 00:16:33.720
<v Speaker 2>log in. You also need to lock down the BIOS

336
00:16:33.799 --> 00:16:37.279
<v Speaker 2>or UAFS settings, set a firmware password, disable booting from

337
00:16:37.320 --> 00:16:41.080
<v Speaker 2>external devices if possible, make physical access as difficult as

338
00:16:41.120 --> 00:16:41.600
<v Speaker 2>you can.

339
00:16:41.799 --> 00:16:46.279
<v Speaker 1>Layer upon layer. Voice okay, Finally, just knowing what's running,

340
00:16:46.399 --> 00:16:48.759
<v Speaker 1>what services are listening, who's connected.

341
00:16:49.120 --> 00:16:52.600
<v Speaker 2>Basic visibility absolutely Fundamentally, you can't secure what you don't

342
00:16:52.600 --> 00:16:57.200
<v Speaker 2>know you have. Simple commands are your friends here? Netstat LBOEPN,

343
00:16:57.360 --> 00:17:01.720
<v Speaker 2>what's that do? Shows you all listening work ports, the

344
00:17:01.799 --> 00:17:05.640
<v Speaker 2>port numbers stand and the process using each port instantly

345
00:17:05.680 --> 00:17:07.920
<v Speaker 2>reveals any unexpected services running.

346
00:17:08.119 --> 00:17:11.039
<v Speaker 1>Find that rogue web server someone installed exactly?

347
00:17:11.279 --> 00:17:14.960
<v Speaker 2>And netstet day NP shows active connections. Who is your

348
00:17:15.160 --> 00:17:19.640
<v Speaker 2>machine talking to right now? What foreign addresses? Useful for spotting,

349
00:17:19.680 --> 00:17:21.279
<v Speaker 2>weird outbound traffic.

350
00:17:21.079 --> 00:17:22.920
<v Speaker 1>And for a broader networkview.

351
00:17:23.279 --> 00:17:26.200
<v Speaker 2>In map, the gold standard for network mapping, it can

352
00:17:26.240 --> 00:17:28.680
<v Speaker 2>scan your systems, tell you which ports are opened, closed,

353
00:17:28.759 --> 00:17:31.160
<v Speaker 2>or filtered by a firewall. It can often guess the

354
00:17:31.200 --> 00:17:33.839
<v Speaker 2>service running out of port and even the operating system.

355
00:17:34.240 --> 00:17:37.599
<v Speaker 2>Understanding your own attack surface from an external perspective is critical.

356
00:17:37.720 --> 00:17:40.400
<v Speaker 1>Wow, okay, that was quite the journey. We really covered

357
00:17:40.400 --> 00:17:41.119
<v Speaker 1>a lot of ground there.

358
00:17:41.160 --> 00:17:42.279
<v Speaker 2>We did, from.

359
00:17:42.200 --> 00:17:47.480
<v Speaker 1>Why breaches even happen through users, passwords, firewalls, encryption, fancy

360
00:17:47.519 --> 00:17:53.920
<v Speaker 1>access controls like MC monitoring, scanning. It's a lot.

361
00:17:54.079 --> 00:17:57.359
<v Speaker 2>It really underscores that layered approach, doesn't it. There's no

362
00:17:57.559 --> 00:17:58.599
<v Speaker 2>single silver bullet.

363
00:17:58.960 --> 00:18:02.400
<v Speaker 1>You need defence in debt and constant vigilance using tools

364
00:18:02.440 --> 00:18:06.839
<v Speaker 1>like audit to watch lenus open vas nikto to proactively.

365
00:18:06.240 --> 00:18:10.000
<v Speaker 2>Check, and never assuming the defaults are good enough. Yeah,

366
00:18:10.119 --> 00:18:14.519
<v Speaker 2>always be questioning, always be hardening, building resilient systems.

367
00:18:14.759 --> 00:18:16.680
<v Speaker 1>Yeah, it's definitely a lot to take in, but I

368
00:18:16.720 --> 00:18:19.279
<v Speaker 1>feel like it's really empowering knowledge. Now you can look

369
00:18:19.279 --> 00:18:21.839
<v Speaker 1>at a Linux system and think with that security mindset first.

370
00:18:22.039 --> 00:18:22.599
<v Speaker 2>That's the goal.

371
00:18:22.960 --> 00:18:25.400
<v Speaker 1>It's not just about stopping attacks, right, It's about building

372
00:18:25.440 --> 00:18:27.519
<v Speaker 1>systems you can actually trust exactly.

373
00:18:27.720 --> 00:18:30.240
<v Speaker 2>So maybe here's a final thought for everyone listening to

374
00:18:30.839 --> 00:18:33.680
<v Speaker 2>chew one. Okay, even if you build the most perfectly

375
00:18:33.720 --> 00:18:37.359
<v Speaker 2>hardened Linux system imaginable, how do you know it stays

376
00:18:37.400 --> 00:18:40.599
<v Speaker 2>that way? How do you plan to continuously monitor your

377
00:18:40.599 --> 00:18:44.480
<v Speaker 2>systems verify their integrity against threats that are constantly changing,

378
00:18:44.559 --> 00:18:45.640
<v Speaker 2>constantly evolving.

379
00:18:45.759 --> 00:18:49.559
<v Speaker 1>Hmm, good question. Keeping secure isn't a one time job,

380
00:18:49.680 --> 00:18:53.400
<v Speaker 1>never is. Well, keep learning, keep exploring, keep asking those questions,

381
00:18:53.400 --> 00:18:55.880
<v Speaker 1>and definitely keep securing those systems. We'll catch you on

382
00:18:55.920 --> 00:18:57.160
<v Speaker 1>the next deep dive.