WEBVTT

1
00:00:00.120 --> 00:00:01.760
<v Speaker 1>Welcome to your custom deep dives.

2
00:00:01.800 --> 00:00:01.919
<v Speaker 2>Oh.

3
00:00:02.680 --> 00:00:07.080
<v Speaker 1>Today we're cracking open some choice sections from Mohamaj Kabir's

4
00:00:07.080 --> 00:00:11.199
<v Speaker 1>book Red Hat Linux Security and Optimization. Oh nice, ready

5
00:00:11.240 --> 00:00:14.960
<v Speaker 1>to yeah the chans dirty and make your Linux system

6
00:00:15.000 --> 00:00:17.920
<v Speaker 1>both a speed demon and a digital fortress.

7
00:00:18.440 --> 00:00:20.719
<v Speaker 2>Kabir packs a lot of wisdom into this book, so

8
00:00:20.760 --> 00:00:24.239
<v Speaker 2>I'm excited to you know, perfect help distill the most

9
00:00:24.280 --> 00:00:25.079
<v Speaker 2>important bits.

10
00:00:25.199 --> 00:00:28.879
<v Speaker 1>We'll start with the foundation. Yeah, making your red hat

11
00:00:28.920 --> 00:00:33.840
<v Speaker 1>system run like a well oiled machine. But here's a twist.

12
00:00:34.200 --> 00:00:37.840
<v Speaker 1>It's not just about speed. It's about ensuring your security

13
00:00:37.880 --> 00:00:41.000
<v Speaker 1>services run smoothly too, right. I never thought about it

14
00:00:41.039 --> 00:00:41.439
<v Speaker 1>that way.

15
00:00:41.560 --> 00:00:43.159
<v Speaker 2>It's like a real world fortress.

16
00:00:43.520 --> 00:00:43.840
<v Speaker 1>Okay.

17
00:00:44.159 --> 00:00:47.679
<v Speaker 2>If the guards are sluggish and the drawbridge takes forever

18
00:00:47.799 --> 00:00:50.640
<v Speaker 2>to raise, it doesn't matter how thick the walls are.

19
00:00:51.320 --> 00:00:54.479
<v Speaker 2>Performance is a key part of security.

20
00:00:54.679 --> 00:00:58.560
<v Speaker 1>That makes total sense. Yeah, okay, so how do we

21
00:00:58.640 --> 00:01:01.280
<v Speaker 1>even know if our system is performing well? I mean,

22
00:01:01.439 --> 00:01:02.799
<v Speaker 1>besides it feeling slow?

23
00:01:03.359 --> 00:01:05.920
<v Speaker 2>Kubut. It gives us a few command line tools to

24
00:01:06.040 --> 00:01:08.640
<v Speaker 2>act as our system's vital sign monitors.

25
00:01:08.719 --> 00:01:09.040
<v Speaker 1>Okay.

26
00:01:09.200 --> 00:01:12.159
<v Speaker 2>Knobs, for example, is like a quick glance under the hood. Okay,

27
00:01:12.239 --> 00:01:15.319
<v Speaker 2>it shows you the process is currently running. But if

28
00:01:15.319 --> 00:01:19.159
<v Speaker 2>you really want to see what's hogging resources, TOP is

29
00:01:19.200 --> 00:01:22.200
<v Speaker 2>your go to. Okay, it's like a live dashboard showing

30
00:01:22.239 --> 00:01:27.000
<v Speaker 2>you CPU usage, right, memory consumption, and which processes are

31
00:01:27.040 --> 00:01:28.079
<v Speaker 2>the greediest TOP.

32
00:01:28.280 --> 00:01:30.560
<v Speaker 1>That's what I use all the time. Yeah, but I

33
00:01:30.640 --> 00:01:32.400
<v Speaker 1>have to admit sometimes I'm not sure what all the

34
00:01:32.480 --> 00:01:34.680
<v Speaker 1>numbers mean. Right, What should I be looking for?

35
00:01:34.840 --> 00:01:38.840
<v Speaker 2>You want to watch out for any processes consistently using

36
00:01:38.920 --> 00:01:41.799
<v Speaker 2>a large percentage of CPU or memory. Okay, that's a

37
00:01:41.879 --> 00:01:46.159
<v Speaker 2>sign they might be bottlenecks slowing down your system. Kabir

38
00:01:46.200 --> 00:01:52.319
<v Speaker 2>also mentions vmstat, which goes even deeper into memory, input, output, operations,

39
00:01:52.400 --> 00:01:53.400
<v Speaker 2>and system load.

40
00:01:53.879 --> 00:01:56.760
<v Speaker 1>So vmstat is for when I need to do some

41
00:01:56.920 --> 00:02:01.000
<v Speaker 1>serious performance detective work exactly. But wouldn't be great to

42
00:02:01.040 --> 00:02:03.239
<v Speaker 1>see how performance changes over time?

43
00:02:03.799 --> 00:02:06.079
<v Speaker 2>Like is this slow down a new thing or has

44
00:02:06.079 --> 00:02:07.319
<v Speaker 2>it been brewing for a while?

45
00:02:07.640 --> 00:02:11.759
<v Speaker 1>Good point. Kaber mentions VTAD for that. Okay, it analyzes

46
00:02:11.919 --> 00:02:15.400
<v Speaker 1>historical performance data. Okay, think of it like your system's

47
00:02:15.479 --> 00:02:16.439
<v Speaker 1>performance journal.

48
00:02:16.520 --> 00:02:19.199
<v Speaker 2>Okay, I'm putting VTAT on my list to check out. Nice,

49
00:02:19.240 --> 00:02:21.879
<v Speaker 2>but let's shift gears a bit. Kabir talks about the

50
00:02:21.919 --> 00:02:26.280
<v Speaker 2>importance of a lean, mean kernel for performance.

51
00:02:26.400 --> 00:02:26.719
<v Speaker 1>Okay.

52
00:02:26.919 --> 00:02:29.400
<v Speaker 2>Now, I get that the kernel is the heart of

53
00:02:29.400 --> 00:02:32.280
<v Speaker 2>the operating system, right, but what does it actually mean

54
00:02:32.599 --> 00:02:33.400
<v Speaker 2>to make it lean?

55
00:02:33.840 --> 00:02:37.919
<v Speaker 1>It's all about customizing your kernel by compiling it yourself.

56
00:02:38.319 --> 00:02:40.840
<v Speaker 1>It's like building a race car. You only include the

57
00:02:40.840 --> 00:02:44.680
<v Speaker 1>components you need, stripping away any excess weight that would

58
00:02:44.680 --> 00:02:45.319
<v Speaker 1>slow you down.

59
00:02:45.759 --> 00:02:48.800
<v Speaker 2>So we're talking about a custom built kernel tailored to

60
00:02:48.840 --> 00:02:52.919
<v Speaker 2>my system's specific needs. That sounds a bit intimidating, to

61
00:02:52.919 --> 00:02:53.400
<v Speaker 2>be honest.

62
00:02:53.560 --> 00:02:56.319
<v Speaker 1>It's definitely more advanced than using a pre built kernel, okay,

63
00:02:56.560 --> 00:03:00.919
<v Speaker 1>But Kabir breaks the process down into manageable steps. First,

64
00:03:01.240 --> 00:03:03.120
<v Speaker 1>you choose your processor support. Right.

65
00:03:03.199 --> 00:03:05.639
<v Speaker 2>You can go for broad compatibility so your kernel works

66
00:03:05.639 --> 00:03:08.479
<v Speaker 2>on a wider range of hardware, or you can target

67
00:03:08.520 --> 00:03:11.439
<v Speaker 2>a specific processor for maximum performance on that hardware.

68
00:03:11.479 --> 00:03:14.680
<v Speaker 1>Got it. So it's a trade off, yeah, compatibility versus performance.

69
00:03:15.199 --> 00:03:18.240
<v Speaker 1>But let's say I'm ready to go for the performance boost. Okay,

70
00:03:18.360 --> 00:03:19.319
<v Speaker 1>what's next? Next?

71
00:03:19.439 --> 00:03:22.680
<v Speaker 2>Up file systems Okay, these are the building blocks of

72
00:03:22.719 --> 00:03:24.120
<v Speaker 2>how your system stores data.

73
00:03:24.319 --> 00:03:24.560
<v Speaker 1>Okay.

74
00:03:24.759 --> 00:03:28.919
<v Speaker 2>Enabling only the essential ones keeps things streamlined. Think X

75
00:03:28.960 --> 00:03:32.479
<v Speaker 2>two for your main system, ISO nine six sixty for

76
00:03:32.800 --> 00:03:36.639
<v Speaker 2>CDs okay, and proc for interacting with the kernel, and

77
00:03:36.680 --> 00:03:40.199
<v Speaker 2>if it's a desktop or laptop, okay, you'd enable settings

78
00:03:40.240 --> 00:03:42.400
<v Speaker 2>for things like printing and music playback.

79
00:03:42.479 --> 00:03:45.639
<v Speaker 1>It's all about keeping things tidy and removing anything that

80
00:03:45.719 --> 00:03:49.919
<v Speaker 1>could cause unnecessary drag. Yep, so less is more in

81
00:03:50.000 --> 00:03:56.360
<v Speaker 1>this case, exactly. But this compiling business, it sounds pretty involved.

82
00:03:56.520 --> 00:04:00.560
<v Speaker 2>It is a multi step process, involving checking dependents the

83
00:04:00.599 --> 00:04:04.439
<v Speaker 2>source code, compiling the kernel and modules, and then installing it.

84
00:04:04.479 --> 00:04:05.319
<v Speaker 1>All okay, but.

85
00:04:05.319 --> 00:04:09.599
<v Speaker 2>Trust me, for performance enthusiasts, it's a really rewarding endeavor.

86
00:04:09.639 --> 00:04:13.039
<v Speaker 1>Okay, you've convinced me, right, I'm adding compile a custom

87
00:04:13.199 --> 00:04:15.159
<v Speaker 1>kernel to my to do list.

88
00:04:15.319 --> 00:04:15.759
<v Speaker 2>Awesome.

89
00:04:16.000 --> 00:04:18.680
<v Speaker 1>Now we've optimized the kernel, but what about the file

90
00:04:18.720 --> 00:04:20.399
<v Speaker 1>systems themselves come faster too?

91
00:04:20.519 --> 00:04:21.079
<v Speaker 2>Absolutely?

92
00:04:21.120 --> 00:04:21.639
<v Speaker 1>Okay. Good.

93
00:04:22.040 --> 00:04:25.560
<v Speaker 2>Kaber goes deep on file system tuning, especially for the

94
00:04:25.720 --> 00:04:28.279
<v Speaker 2>X two two file system. Okay, But before we get there,

95
00:04:28.360 --> 00:04:32.240
<v Speaker 2>let's compare some hardware. He notes that while SCSI and

96
00:04:32.319 --> 00:04:37.240
<v Speaker 2>IDE are common hard disc types, se SI usually outperforms

97
00:04:37.279 --> 00:04:39.439
<v Speaker 2>IDE because of its advanced architecture.

98
00:04:39.560 --> 00:04:43.920
<v Speaker 1>Interesting, So, if I'm looking for the best possible disc performance,

99
00:04:44.480 --> 00:04:45.120
<v Speaker 1>s CSI is.

100
00:04:45.040 --> 00:04:48.399
<v Speaker 2>The way to get generally, Yes, Now back to X

101
00:04:48.399 --> 00:04:48.920
<v Speaker 2>two tuning.

102
00:04:49.600 --> 00:04:49.959
<v Speaker 1>Okay.

103
00:04:50.000 --> 00:04:53.920
<v Speaker 2>Kaber introduces the E two f S Brogus Utility, a

104
00:04:53.959 --> 00:04:56.319
<v Speaker 2>toolbox for managing X two file systems.

105
00:04:56.360 --> 00:04:56.600
<v Speaker 1>Right.

106
00:04:56.639 --> 00:04:59.199
<v Speaker 2>First, you need to compile and install it, but once

107
00:04:59.240 --> 00:05:02.240
<v Speaker 2>you do, you have a lot of power to tweak

108
00:05:02.279 --> 00:05:03.680
<v Speaker 2>and optimize your file system.

109
00:05:03.959 --> 00:05:07.480
<v Speaker 1>Okay, that's on my list. Now, compile and install E

110
00:05:07.600 --> 00:05:08.560
<v Speaker 1>two f sprogs.

111
00:05:09.439 --> 00:05:10.079
<v Speaker 2>Sounds good.

112
00:05:10.399 --> 00:05:11.959
<v Speaker 1>What kind of tweaks are we talking about.

113
00:05:12.120 --> 00:05:15.399
<v Speaker 2>One of the big ones is using a journaling file system.

114
00:05:15.680 --> 00:05:15.920
<v Speaker 1>Okay.

115
00:05:16.120 --> 00:05:18.120
<v Speaker 2>It's like a safety net for your data.

116
00:05:18.199 --> 00:05:18.439
<v Speaker 1>Okay.

117
00:05:18.560 --> 00:05:21.759
<v Speaker 2>It logs changes before actually writing them to disc which

118
00:05:21.800 --> 00:05:24.199
<v Speaker 2>can improve both speed and reliability.

119
00:05:24.360 --> 00:05:26.600
<v Speaker 1>So journaling sounds like a good thing. Yeah, but you

120
00:05:26.639 --> 00:05:29.480
<v Speaker 1>mentioned reliability. Are there any downsides?

121
00:05:29.879 --> 00:05:32.560
<v Speaker 2>There's a slight risk of data loss if something goes

122
00:05:32.600 --> 00:05:36.839
<v Speaker 2>wrong during the journaling process, though it's pretty rare. Kabir

123
00:05:36.920 --> 00:05:40.800
<v Speaker 2>also points out that journaling can have issues with bad media,

124
00:05:41.240 --> 00:05:44.560
<v Speaker 2>so make sure your discs are healthy. He highlights a

125
00:05:44.600 --> 00:05:48.519
<v Speaker 2>few specific journaling file systems. X three, a journaled version

126
00:05:48.560 --> 00:05:51.759
<v Speaker 2>of X two, and riser FS right, which can be

127
00:05:52.120 --> 00:05:54.439
<v Speaker 2>even faster than X two in certain situations.

128
00:05:54.480 --> 00:05:57.879
<v Speaker 1>So X three for good balance and riser FS if

129
00:05:57.879 --> 00:06:00.759
<v Speaker 1>I'm chasing the absolute best performance exact, got it?

130
00:06:01.079 --> 00:06:01.279
<v Speaker 2>Yep?

131
00:06:01.720 --> 00:06:03.600
<v Speaker 1>But is there anything we can do to make our

132
00:06:03.639 --> 00:06:07.040
<v Speaker 1>storage even more robust and easier to manage?

133
00:06:07.160 --> 00:06:08.120
<v Speaker 2>There? Absolutely is.

134
00:06:08.240 --> 00:06:08.800
<v Speaker 1>Good.

135
00:06:09.160 --> 00:06:13.240
<v Speaker 2>Let's talk about the Logical Volume Manager, or LVM. It's

136
00:06:13.279 --> 00:06:17.040
<v Speaker 2>like creating a virtual layer on top of your physical discs. Okay,

137
00:06:17.279 --> 00:06:21.439
<v Speaker 2>you can combine multiple discs into logical volumes, which gives

138
00:06:21.480 --> 00:06:25.000
<v Speaker 2>you a ton of flexibility and makes administration much easier.

139
00:06:25.240 --> 00:06:27.839
<v Speaker 1>LVM sounds like something every serious Linux user should know.

140
00:06:28.000 --> 00:06:32.399
<v Speaker 2>You're telling me, and Kabir emphasizes that LVM skills aren't

141
00:06:32.439 --> 00:06:35.680
<v Speaker 2>just for techies. They're a valuable asset in the job

142
00:06:35.759 --> 00:06:39.079
<v Speaker 2>market as more and more companies rely on Linux, especially

143
00:06:39.079 --> 00:06:40.720
<v Speaker 2>for their enterprise storage needs.

144
00:06:40.759 --> 00:06:43.360
<v Speaker 1>All right, LVM is officially going on my list of

145
00:06:43.439 --> 00:06:44.079
<v Speaker 1>things to learn.

146
00:06:44.199 --> 00:06:44.519
<v Speaker 2>Nice.

147
00:06:45.480 --> 00:06:47.279
<v Speaker 1>But let's zoom out for a minute and talk about

148
00:06:47.279 --> 00:06:50.000
<v Speaker 1>the network. Okay, we all know how frustrating a slow

149
00:06:50.079 --> 00:06:53.680
<v Speaker 1>network can be. How can we optimize network performance on

150
00:06:53.720 --> 00:06:55.040
<v Speaker 1>a red hat system.

151
00:06:55.319 --> 00:06:58.600
<v Speaker 2>It all starts with understanding your network traffic flow. Okay,

152
00:06:58.759 --> 00:07:03.879
<v Speaker 2>imagine three web servers, an NFS server for file sharing,

153
00:07:04.120 --> 00:07:07.720
<v Speaker 2>and a database server, all crammed onto the same network

154
00:07:07.800 --> 00:07:11.439
<v Speaker 2>segment and connected with a hub instead of a switch. Okay,

155
00:07:11.480 --> 00:07:12.399
<v Speaker 2>what do you think happens?

156
00:07:12.879 --> 00:07:14.879
<v Speaker 1>Ugh, it's only a recipe for disaster.

157
00:07:15.120 --> 00:07:15.560
<v Speaker 2>Exactly.

158
00:07:15.720 --> 00:07:17.879
<v Speaker 1>All that traffic trying to squeeze through one tiny pipe

159
00:07:17.920 --> 00:07:18.480
<v Speaker 1>at the same.

160
00:07:18.319 --> 00:07:22.560
<v Speaker 2>Time, you get congestion, collisions and everyone's performance suffers. The

161
00:07:22.600 --> 00:07:26.959
<v Speaker 2>solution is traffic control. We need to create dedicated lanes

162
00:07:27.360 --> 00:07:30.439
<v Speaker 2>on the network highway for different types of traffic.

163
00:07:30.560 --> 00:07:32.759
<v Speaker 1>I like that analogy, So how do we actually create

164
00:07:32.800 --> 00:07:33.360
<v Speaker 1>these lanes?

165
00:07:33.480 --> 00:07:36.439
<v Speaker 2>Could be your talks about a few techniques. You can

166
00:07:36.639 --> 00:07:42.360
<v Speaker 2>use network segmentation to physically separate different types of traffic.

167
00:07:43.079 --> 00:07:46.839
<v Speaker 2>You can prioritize certain types of traffic over others. And

168
00:07:46.879 --> 00:07:50.600
<v Speaker 2>you can even use a DNS server to balance the load,

169
00:07:51.199 --> 00:07:55.959
<v Speaker 2>distributing requests across multiple servers so no single server gets overwhelmed.

170
00:07:56.040 --> 00:07:59.199
<v Speaker 1>Okay, that makes sense. Now let's talk about something near

171
00:07:59.240 --> 00:08:03.120
<v Speaker 1>and dear to my heart. Web server performance. All right,

172
00:08:03.360 --> 00:08:06.839
<v Speaker 1>I'm a web development and I'm obsessed with making websites

173
00:08:06.920 --> 00:08:10.759
<v Speaker 1>load as fast as humanly possible. Where do we even

174
00:08:10.839 --> 00:08:13.519
<v Speaker 1>begin with optimizing Apache for speed?

175
00:08:13.800 --> 00:08:17.360
<v Speaker 2>Apache's modular architecture is our friend here. Instead of being

176
00:08:17.480 --> 00:08:21.360
<v Speaker 2>one monolithic program, it's built from individual modules.

177
00:08:21.519 --> 00:08:21.720
<v Speaker 1>Right.

178
00:08:22.240 --> 00:08:25.439
<v Speaker 2>This means you can customize your Apache server by choosing

179
00:08:25.480 --> 00:08:29.680
<v Speaker 2>only the modules you need. It's like decluttering your digital closet.

180
00:08:30.000 --> 00:08:32.000
<v Speaker 2>You get rid of the stuff you don't wear anymore,

181
00:08:32.519 --> 00:08:34.320
<v Speaker 2>leaving more space for the essentials.

182
00:08:34.559 --> 00:08:39.639
<v Speaker 1>So step one is identifying and removing any unnecessary modules.

183
00:08:39.879 --> 00:08:42.440
<v Speaker 1>Exactly how do I even know what's unnecessary?

184
00:08:42.799 --> 00:08:46.919
<v Speaker 2>Kud Beer suggests starting with the httpd dash l command.

185
00:08:47.559 --> 00:08:50.320
<v Speaker 2>This shows you all the modules compiled into your current

186
00:08:50.360 --> 00:08:53.600
<v Speaker 2>Apache setup. Once you've spotted the ones you don't need,

187
00:08:54.200 --> 00:08:57.440
<v Speaker 2>you can use the dot configure script with various options

188
00:08:57.480 --> 00:08:59.639
<v Speaker 2>to choose the essentials for your custom build.

189
00:09:00.279 --> 00:09:03.879
<v Speaker 1>So we've streamlined Apache by stripping away the excess baggage.

190
00:09:04.360 --> 00:09:06.039
<v Speaker 1>But is there anything else we can do to make

191
00:09:06.039 --> 00:09:06.919
<v Speaker 1>our web server a.

192
00:09:06.879 --> 00:09:11.840
<v Speaker 2>Speed demon There are a few key directives in apaches

193
00:09:11.879 --> 00:09:15.320
<v Speaker 2>configuration file that can make a big difference. For example,

194
00:09:15.440 --> 00:09:21.080
<v Speaker 2>keep alive allows for persistent TCP connections, which reduces the

195
00:09:21.120 --> 00:09:24.960
<v Speaker 2>overhead of establishing a new connection for every request your connection.

196
00:09:25.039 --> 00:09:29.200
<v Speaker 1>Yeah, less work for the server, faster page loads. Got it?

197
00:09:29.720 --> 00:09:30.480
<v Speaker 1>What else is there?

198
00:09:30.600 --> 00:09:34.799
<v Speaker 2>There's max clients, which limits the numbers of simultaneous connections

199
00:09:34.799 --> 00:09:38.480
<v Speaker 2>a patche can handle, preventing it from being overloaded. Then

200
00:09:38.519 --> 00:09:42.720
<v Speaker 2>we have our limit MEM and our limit MPROCA, which

201
00:09:42.799 --> 00:09:47.639
<v Speaker 2>control resource management, setting limits on memory usage okay, and

202
00:09:47.720 --> 00:09:50.039
<v Speaker 2>the number of processes a catchy can spawn.

203
00:09:50.360 --> 00:09:53.039
<v Speaker 1>So it's like setting boundaries for a patche to operate within,

204
00:09:53.519 --> 00:09:56.000
<v Speaker 1>ensuring it doesn't hog all the resources and slow down

205
00:09:56.000 --> 00:09:56.879
<v Speaker 1>the entire system.

206
00:09:57.000 --> 00:09:58.080
<v Speaker 2>Exactly smart.

207
00:09:58.159 --> 00:10:00.960
<v Speaker 1>Yeah, But what if I'm mainly serving stat content like

208
00:10:01.039 --> 00:10:05.480
<v Speaker 1>images or downloadable files? Right? Is there anything specific for that?

209
00:10:05.840 --> 00:10:10.960
<v Speaker 2>For static content? Kaber recommends considering cage tpd. Okay, a

210
00:10:11.039 --> 00:10:13.039
<v Speaker 2>kernel module that acts as a web server.

211
00:10:13.200 --> 00:10:13.519
<v Speaker 1>All right.

212
00:10:13.840 --> 00:10:17.080
<v Speaker 2>It operates directly within the kernel space, which gives it

213
00:10:17.159 --> 00:10:19.440
<v Speaker 2>super fast access to the network and files.

214
00:10:19.679 --> 00:10:24.200
<v Speaker 1>Well, a kernel level web server. That sounds seriously powerful.

215
00:10:24.320 --> 00:10:26.919
<v Speaker 1>It is, but I have to admit I'm a little

216
00:10:26.960 --> 00:10:29.480
<v Speaker 1>nervous about something running at such a low level. Okay,

217
00:10:29.600 --> 00:10:31.200
<v Speaker 1>are there any risks involved?

218
00:10:31.639 --> 00:10:35.159
<v Speaker 2>It's a trade off, okay. Kgtpd is super efficient for

219
00:10:35.320 --> 00:10:39.840
<v Speaker 2>dedicated static content serving, but it's not a replacement for

220
00:10:39.919 --> 00:10:42.000
<v Speaker 2>a full featured web server like apatche.

221
00:10:42.080 --> 00:10:42.440
<v Speaker 1>Okay.

222
00:10:42.480 --> 00:10:46.200
<v Speaker 2>It's best for specific use cases like image hosting or

223
00:10:46.279 --> 00:10:47.399
<v Speaker 2>serving large files.

224
00:10:47.600 --> 00:10:49.879
<v Speaker 1>Okay, I'll keep that in mind, and let's talk about

225
00:10:49.879 --> 00:10:53.799
<v Speaker 1>web applications. I know dynamic content can be more resource

226
00:10:53.840 --> 00:10:56.600
<v Speaker 1>intensive than static content. Right, what are some ways to

227
00:10:56.679 --> 00:10:58.240
<v Speaker 1>boost performance in that area?

228
00:10:58.360 --> 00:11:01.600
<v Speaker 2>Kaber discusses a few technique, each with its own pros

229
00:11:01.600 --> 00:11:05.320
<v Speaker 2>and cons. One option is mod Pearl, which embeds a

230
00:11:05.399 --> 00:11:08.159
<v Speaker 2>Pearl interpreter directly into Apache.

231
00:11:08.279 --> 00:11:11.600
<v Speaker 1>So instead of launching a separate Pearl process for each request,

232
00:11:12.360 --> 00:11:14.519
<v Speaker 1>the interpreter is already there, ready to go.

233
00:11:14.759 --> 00:11:18.639
<v Speaker 2>Exactly. That eliminates a lot of overhead and can significantly

234
00:11:18.679 --> 00:11:22.360
<v Speaker 2>speed up Pearl based web applications. Okay, but there's a

235
00:11:22.360 --> 00:11:26.960
<v Speaker 2>trade off. Your Pearl code now runs within apaches process space.

236
00:11:27.240 --> 00:11:27.519
<v Speaker 1>Right.

237
00:11:27.600 --> 00:11:30.279
<v Speaker 2>That means if there's a vulnerability in your Pearl code,

238
00:11:30.720 --> 00:11:33.679
<v Speaker 2>it could potentially compromise the entire web server.

239
00:11:34.240 --> 00:11:39.039
<v Speaker 1>Yikes. Yeah, so mod Pearl is powerful, but it's not

240
00:11:39.240 --> 00:11:40.519
<v Speaker 1>something to use lightly.

241
00:11:40.919 --> 00:11:41.200
<v Speaker 2>Right.

242
00:11:41.399 --> 00:11:45.759
<v Speaker 1>It sounds like it requires careful consideration of the security implications.

243
00:11:46.000 --> 00:11:46.399
<v Speaker 2>Exactly.

244
00:11:46.440 --> 00:11:48.399
<v Speaker 1>What about fast cgi you mentioned that earlier.

245
00:11:48.440 --> 00:11:51.440
<v Speaker 2>Fast cgi is a great option for scaling web applications.

246
00:11:51.840 --> 00:11:54.559
<v Speaker 2>It lets you run your application code in separate processes,

247
00:11:54.799 --> 00:12:00.000
<v Speaker 2>which improves isolation and potentially performance, And unlike mod Pearl,

248
00:12:00.159 --> 00:12:02.960
<v Speaker 2>it's not limited to just peerl Okay, you can use

249
00:12:03.000 --> 00:12:07.600
<v Speaker 2>fast cgi with various languages like CC plus plus and

250
00:12:07.639 --> 00:12:08.919
<v Speaker 2>even Java, so.

251
00:12:09.039 --> 00:12:12.480
<v Speaker 1>Fast CGI offers more flexibility. But speaking of Java, I

252
00:12:12.519 --> 00:12:15.879
<v Speaker 1>remember getting a bad rap for being slow in web applications.

253
00:12:16.240 --> 00:12:16.919
<v Speaker 1>Has that changed?

254
00:12:17.039 --> 00:12:17.399
<v Speaker 2>It has?

255
00:12:17.600 --> 00:12:17.919
<v Speaker 1>Okay?

256
00:12:18.200 --> 00:12:21.120
<v Speaker 2>While Java was once considered clunky for the web, it's

257
00:12:21.159 --> 00:12:25.399
<v Speaker 2>evolved into a powerhouse. Technologies like Java servlets and Java

258
00:12:25.399 --> 00:12:30.159
<v Speaker 2>server pages are highly scalable and robust, and Java's strength

259
00:12:30.279 --> 00:12:35.159
<v Speaker 2>in distributed applications makes it perfect for complex web systems.

260
00:12:35.200 --> 00:12:39.120
<v Speaker 1>Fascinating how technology changes, it is. Okay, we've covered a

261
00:12:39.159 --> 00:12:41.919
<v Speaker 1>lot of ground on performance, from the kernel to the

262
00:12:41.960 --> 00:12:45.720
<v Speaker 1>network to the web server itself. But let's shift gears

263
00:12:45.879 --> 00:12:51.519
<v Speaker 1>and talk about something equally important. Security. Okay, it's time

264
00:12:51.600 --> 00:12:55.879
<v Speaker 1>to turn our red hat system into an impenetrable digital fortress.

265
00:12:56.120 --> 00:12:56.720
<v Speaker 2>Let's do it.

266
00:12:57.000 --> 00:12:58.360
<v Speaker 1>But where do we even begin?

267
00:12:58.600 --> 00:12:58.879
<v Speaker 2>Yeah?

268
00:12:58.960 --> 00:13:01.960
<v Speaker 1>Security can feel like such a vast and complex topic.

269
00:13:02.240 --> 00:13:05.759
<v Speaker 2>Kaber starts with the foundation file and directory permissions.

270
00:13:05.919 --> 00:13:06.039
<v Speaker 1>Right.

271
00:13:06.320 --> 00:13:09.840
<v Speaker 2>These determine who can read, write, and execute files. Okay,

272
00:13:10.000 --> 00:13:13.240
<v Speaker 2>and they're absolutely crucial for preventing unauthorized access.

273
00:13:13.360 --> 00:13:16.720
<v Speaker 1>Right. I know about permissions, those strings of letters and dashes.

274
00:13:16.759 --> 00:13:21.000
<v Speaker 1>It always seems so cryptic, right, But honestly, I sometimes

275
00:13:21.000 --> 00:13:22.440
<v Speaker 1>wonder if I'm setting them correctly.

276
00:13:22.519 --> 00:13:22.759
<v Speaker 2>Sure?

277
00:13:22.759 --> 00:13:23.919
<v Speaker 1>Are they really that important?

278
00:13:24.039 --> 00:13:25.320
<v Speaker 2>They're absolutely critical?

279
00:13:25.480 --> 00:13:25.799
<v Speaker 1>Okay.

280
00:13:25.879 --> 00:13:30.720
<v Speaker 2>Kabar stresses that even a seemingly minor misconfiguration can open

281
00:13:30.799 --> 00:13:34.279
<v Speaker 2>up huge security holes right. For example, he gives a

282
00:13:34.360 --> 00:13:38.480
<v Speaker 2>chilling example of how a simple Perl script, if it's

283
00:13:38.559 --> 00:13:43.799
<v Speaker 2>mistakenly given SUID permissions, could be exploited to gain complete

284
00:13:43.799 --> 00:13:44.679
<v Speaker 2>control of the system.

285
00:13:44.759 --> 00:13:47.360
<v Speaker 1>Wait back up a second. What are SUID permissions?

286
00:13:47.960 --> 00:13:50.000
<v Speaker 2>SUID stands for set user ID.

287
00:13:50.399 --> 00:13:50.799
<v Speaker 1>Okay.

288
00:13:50.879 --> 00:13:53.399
<v Speaker 2>It's a special setting that allows a program to run

289
00:13:53.440 --> 00:13:56.320
<v Speaker 2>with the privileges of the file's owner, which is often

290
00:13:56.360 --> 00:13:57.039
<v Speaker 2>the route user.

291
00:13:57.080 --> 00:13:59.759
<v Speaker 1>Okay, Now I'm really spooked. We need to be incredibly

292
00:13:59.759 --> 00:14:03.320
<v Speaker 1>care full with SUID permissions. But are there any ways

293
00:14:03.360 --> 00:14:05.240
<v Speaker 1>to lock down our files even further?

294
00:14:05.399 --> 00:14:06.000
<v Speaker 2>Absolutely?

295
00:14:06.120 --> 00:14:06.399
<v Speaker 1>Okay?

296
00:14:06.559 --> 00:14:10.279
<v Speaker 2>Kabir introduces the chatcar command okay, which lets you make

297
00:14:10.320 --> 00:14:14.519
<v Speaker 2>files immutable. That means they can't be modified, deleted, or

298
00:14:14.600 --> 00:14:18.200
<v Speaker 2>even renamed, even by the root user. Wow, it's like

299
00:14:18.240 --> 00:14:22.480
<v Speaker 2>putting your most valuable files in an unbreakable vault.

300
00:14:23.039 --> 00:14:26.519
<v Speaker 1>Checked. Another one for the security toolbox. Yep, But what

301
00:14:26.600 --> 00:14:29.879
<v Speaker 1>if someone has already modified a file without us knowing?

302
00:14:30.840 --> 00:14:32.879
<v Speaker 1>How can we detect those sneaky changes.

303
00:14:32.960 --> 00:14:34.799
<v Speaker 2>That's where file integrity checkers come in.

304
00:14:34.879 --> 00:14:35.200
<v Speaker 1>Okay.

305
00:14:35.320 --> 00:14:40.559
<v Speaker 2>Kabir talks about three powerful tools, Tripwire, AID and ICU.

306
00:14:40.720 --> 00:14:43.080
<v Speaker 1>Okay, let's start with tripwire. What makes it so special?

307
00:14:43.360 --> 00:14:46.000
<v Speaker 2>Tripwire is like a watchdog for your files?

308
00:14:46.159 --> 00:14:46.519
<v Speaker 1>Okay.

309
00:14:46.600 --> 00:14:49.840
<v Speaker 2>It creates a database of checksums, which are like unique

310
00:14:49.840 --> 00:14:53.960
<v Speaker 2>fingerprints for each file. It then regularly scans your system

311
00:14:54.279 --> 00:14:58.000
<v Speaker 2>and compares the current checksums against the database. If there's

312
00:14:58.039 --> 00:15:01.159
<v Speaker 2>a mismatch, it means a file has altered, right, and

313
00:15:01.240 --> 00:15:02.759
<v Speaker 2>Tripwire will sound the alarm.

314
00:15:02.960 --> 00:15:05.519
<v Speaker 1>So it's constantly on the lookout for any unauthorized changes.

315
00:15:05.919 --> 00:15:08.759
<v Speaker 1>Sound pretty effective it is, But I'm curious about something.

316
00:15:08.879 --> 00:15:13.960
<v Speaker 1>Kaper mentions storing the trip r database on read only media. Right,

317
00:15:14.519 --> 00:15:15.559
<v Speaker 1>Why is that important?

318
00:15:15.759 --> 00:15:17.480
<v Speaker 2>It's all about preventing tampering.

319
00:15:17.759 --> 00:15:18.919
<v Speaker 1>Okay, think about it.

320
00:15:19.039 --> 00:15:23.399
<v Speaker 2>If an attacker compromises your system, they could potentially modify

321
00:15:23.480 --> 00:15:26.519
<v Speaker 2>the trip wire database itself to hide their tracks. Ye.

322
00:15:27.039 --> 00:15:29.960
<v Speaker 2>Storing it on read only media like a CD ROM

323
00:15:30.360 --> 00:15:33.200
<v Speaker 2>makes it much harder for attackers to mess with the system.

324
00:15:33.360 --> 00:15:36.159
<v Speaker 1>Ah, that's a clever security measure. Yeah, so it's like

325
00:15:36.200 --> 00:15:39.399
<v Speaker 1>a read only safeguard for the security tool itself. Exactly

326
00:15:39.480 --> 00:15:43.000
<v Speaker 1>what about those other file integrity checkers aid in ICUs Sure,

327
00:15:43.039 --> 00:15:43.960
<v Speaker 1>what are their strengths?

328
00:15:44.159 --> 00:15:48.720
<v Speaker 2>Aid is an alternative to tripwire, offering similar functionality okay.

329
00:15:49.240 --> 00:15:52.000
<v Speaker 2>Ice You, on the other hand, goes beyond simple file

330
00:15:52.039 --> 00:15:56.240
<v Speaker 2>integrity checks. It can automate various security tasks like password

331
00:15:56.240 --> 00:16:00.440
<v Speaker 2>aging enforcement and file permission checks, making it especially for

332
00:16:00.519 --> 00:16:02.360
<v Speaker 2>managing multiple Linux systems.

333
00:16:02.440 --> 00:16:06.279
<v Speaker 1>Docket eight is another watchdog option yes and ICU for

334
00:16:06.360 --> 00:16:11.679
<v Speaker 1>a more comprehensive security management approach exactly, but Kabir also

335
00:16:11.759 --> 00:16:15.440
<v Speaker 1>highlights some essential security tools right that don't directly relate

336
00:16:15.519 --> 00:16:18.120
<v Speaker 1>to file integrity. Tell me more about those.

337
00:16:18.360 --> 00:16:24.519
<v Speaker 2>He dives into two incredibly handy tools, elsoft and ENINGP.

338
00:16:24.960 --> 00:16:28.559
<v Speaker 1>Okay, let's start with ulsoft. What does it do and

339
00:16:28.639 --> 00:16:30.279
<v Speaker 1>how does it help us with security?

340
00:16:30.360 --> 00:16:32.799
<v Speaker 2>Belsoft stands for List Open Files.

341
00:16:32.879 --> 00:16:33.240
<v Speaker 1>Okay.

342
00:16:33.399 --> 00:16:35.559
<v Speaker 2>It gives you a detailed view of all the files

343
00:16:35.559 --> 00:16:38.679
<v Speaker 2>that are currently open on your system, including which processes

344
00:16:38.720 --> 00:16:39.240
<v Speaker 2>open to them.

345
00:16:39.360 --> 00:16:39.600
<v Speaker 1>Okay.

346
00:16:39.840 --> 00:16:44.440
<v Speaker 2>This can be incredibly helpful for security investigations. For instance,

347
00:16:44.480 --> 00:16:46.519
<v Speaker 2>it can help you uncover files that are opened by

348
00:16:46.559 --> 00:16:49.799
<v Speaker 2>a process that has been deleted but is still mysteriously

349
00:16:49.879 --> 00:16:54.600
<v Speaker 2>consuming disk space, a potential sign of malware, or it

350
00:16:54.639 --> 00:16:58.120
<v Speaker 2>can help you identify the process responsible for a remote

351
00:16:58.159 --> 00:17:01.639
<v Speaker 2>connection on a specific port, which could be useful for

352
00:17:01.759 --> 00:17:04.160
<v Speaker 2>tracking down unauthorized network activity.

353
00:17:04.440 --> 00:17:07.799
<v Speaker 1>So elsoff is like a detective tool for our system exactly,

354
00:17:07.839 --> 00:17:11.400
<v Speaker 1>helping us uncover hidden connections and suspicious processes. Yeah.

355
00:17:11.440 --> 00:17:14.640
<v Speaker 2>What about en rep end rep is a network packet

356
00:17:14.680 --> 00:17:19.599
<v Speaker 2>analyzer with incredibly powerful filtering capabilities. Okay, it's like TCP dump,

357
00:17:19.640 --> 00:17:21.799
<v Speaker 2>but it presents the captured data in a more user

358
00:17:21.799 --> 00:17:27.160
<v Speaker 2>friendly format, making it easier to troubleshoot network problems, monitor

359
00:17:27.240 --> 00:17:31.039
<v Speaker 2>traffic patterns, and even detect potential security threats.

360
00:17:31.400 --> 00:17:34.559
<v Speaker 1>Okay, these tools sound incredibly useful, but before we move on,

361
00:17:34.720 --> 00:17:37.759
<v Speaker 1>I want to circle back to something Kaber mentions in

362
00:17:37.799 --> 00:17:41.559
<v Speaker 1>his introduction. Okay, he talks about the concept of high

363
00:17:41.559 --> 00:17:45.880
<v Speaker 1>performance as it relates to security service delivery. Can you

364
00:17:45.960 --> 00:17:46.799
<v Speaker 1>unpack that for me?

365
00:17:46.960 --> 00:17:50.880
<v Speaker 2>It's a crucial point. Okay, think of your security services

366
00:17:50.960 --> 00:17:55.359
<v Speaker 2>as the guards protecting your system. If your system is sluggish,

367
00:17:56.319 --> 00:17:59.880
<v Speaker 2>those guards are going to be slow to react, make

368
00:18:00.160 --> 00:18:01.759
<v Speaker 2>you more vulnerable to attack.

369
00:18:01.960 --> 00:18:02.240
<v Speaker 1>Okay.

370
00:18:02.440 --> 00:18:06.240
<v Speaker 2>A high performance system ensures your security services can operate

371
00:18:06.279 --> 00:18:08.480
<v Speaker 2>at their peak, keeping your defenses strong.

372
00:18:08.720 --> 00:18:11.480
<v Speaker 1>That's a really important point. It's not enough to just

373
00:18:11.559 --> 00:18:14.799
<v Speaker 1>have security measures in place. They need to be able

374
00:18:14.839 --> 00:18:18.440
<v Speaker 1>to perform at their best to be truly effective. Exactly,

375
00:18:18.799 --> 00:18:23.480
<v Speaker 1>So optimizing performance is a key part of maximizing security

376
00:18:23.519 --> 00:18:23.880
<v Speaker 1>as well.

377
00:18:24.000 --> 00:18:25.920
<v Speaker 2>They go hand in hand, exactly.

378
00:18:26.640 --> 00:18:29.319
<v Speaker 1>All Right, I'm starting to feel like a Linux performance

379
00:18:29.400 --> 00:18:32.559
<v Speaker 1>in security guru. Nice, But I know we've only scratched

380
00:18:32.599 --> 00:18:35.440
<v Speaker 1>the surface of what Kabir covers in his book. What's

381
00:18:35.440 --> 00:18:36.079
<v Speaker 1>coming up next?

382
00:18:36.079 --> 00:18:38.039
<v Speaker 2>In this deep dive, We're about to level up our

383
00:18:38.079 --> 00:18:41.920
<v Speaker 2>security skills even further. Okay, Get ready to explore advanced

384
00:18:41.960 --> 00:18:46.319
<v Speaker 2>security measures, including the crucial role of firewalls and protecting

385
00:18:46.359 --> 00:18:48.440
<v Speaker 2>your Linux systems or stay tuned.

386
00:18:48.200 --> 00:18:48.960
<v Speaker 1>Looking forward to it.

387
00:18:49.079 --> 00:18:50.759
<v Speaker 2>Yeah, me too, all right, see.

388
00:18:50.559 --> 00:18:51.039
<v Speaker 1>You next time.

389
00:18:51.119 --> 00:18:54.119
<v Speaker 2>That's good. Okay, ready to dive back in definitely.

390
00:18:54.720 --> 00:18:57.920
<v Speaker 1>What other security secrets does Kabir have in store for us?

391
00:18:58.200 --> 00:19:01.720
<v Speaker 2>Let's delve into an other layer of security that often

392
00:19:01.759 --> 00:19:06.200
<v Speaker 2>gets overlooked. Shadow passwords, the shadow passwords. Okay, they're like

393
00:19:06.480 --> 00:19:09.880
<v Speaker 2>a secret vault for your user accounts passwords.

394
00:19:09.920 --> 00:19:13.519
<v Speaker 1>Okay, shadow passwords. That sounds intriguing. Yeah, why do we

395
00:19:13.559 --> 00:19:16.480
<v Speaker 1>need a separate vault for passwords? Right? Isn't storing them

396
00:19:16.519 --> 00:19:20.599
<v Speaker 1>in the usual etcetera pass wood file good enough, not really, okay.

397
00:19:20.759 --> 00:19:24.759
<v Speaker 2>The problem is that the etcetera password file is readable

398
00:19:24.839 --> 00:19:26.680
<v Speaker 2>by all users on the system.

399
00:19:27.119 --> 00:19:27.359
<v Speaker 1>Right.

400
00:19:27.400 --> 00:19:30.559
<v Speaker 2>That's a potential security risk, as anyone could snoop around

401
00:19:30.559 --> 00:19:31.680
<v Speaker 2>and see those passwords.

402
00:19:31.839 --> 00:19:34.519
<v Speaker 1>You're right, I never thought about it that way. Yeah,

403
00:19:34.640 --> 00:19:36.839
<v Speaker 1>that seems like a pretty big security hole it is.

404
00:19:37.319 --> 00:19:40.640
<v Speaker 2>Shadow passwords solve this problem by moving the passwords to

405
00:19:40.720 --> 00:19:44.480
<v Speaker 2>a separate file called etceter shadow okay, which is only

406
00:19:44.519 --> 00:19:48.039
<v Speaker 2>accessible by the root user. It's like having a lock

407
00:19:48.119 --> 00:19:50.640
<v Speaker 2>on the password file that only the system administrator has

408
00:19:50.640 --> 00:19:51.079
<v Speaker 2>the key to.

409
00:19:51.640 --> 00:19:54.480
<v Speaker 1>So shadow passwords are like a must have for any

410
00:19:54.640 --> 00:19:55.319
<v Speaker 1>Linux system.

411
00:19:55.400 --> 00:19:55.960
<v Speaker 2>Absolutely.

412
00:19:56.119 --> 00:19:57.880
<v Speaker 1>It takes security seriously.

413
00:19:57.480 --> 00:20:01.720
<v Speaker 2>And Kaveer walks us through how to enable shadow passwords

414
00:20:01.880 --> 00:20:04.960
<v Speaker 2>and manage them effectively. But shadow passwords are just one

415
00:20:05.039 --> 00:20:06.400
<v Speaker 2>piece of the security puzzle.

416
00:20:06.759 --> 00:20:08.200
<v Speaker 1>What else should we be thinking about?

417
00:20:08.519 --> 00:20:12.160
<v Speaker 2>Kad Beer covers a whole range of essential security measures, okay,

418
00:20:12.519 --> 00:20:18.799
<v Speaker 2>like checking password consistency, eliminating risky shell services, and this

419
00:20:18.920 --> 00:20:23.240
<v Speaker 2>is a big one. Using open ssh for secure remote.

420
00:20:22.880 --> 00:20:27.000
<v Speaker 1>Access open ssh I vaguely remember hearing about that it's

421
00:20:27.039 --> 00:20:29.799
<v Speaker 1>like a more secure replacement for telmet right exactly, But

422
00:20:29.799 --> 00:20:30.880
<v Speaker 1>why is Caulnut so bad.

423
00:20:31.279 --> 00:20:36.200
<v Speaker 2>Telnet sends all data, including passwords, in plain text. That

424
00:20:36.279 --> 00:20:40.039
<v Speaker 2>means anyone eavesdropping on the network can see everything you're typing.

425
00:20:40.680 --> 00:20:44.799
<v Speaker 2>Open Ssh, on the other hand, encrypts all communications, making

426
00:20:44.799 --> 00:20:48.440
<v Speaker 2>it much more secure for remotely managing your Linux system.

427
00:20:48.680 --> 00:20:51.480
<v Speaker 1>So open ssh is a no brainer if I'm connecting

428
00:20:51.519 --> 00:20:54.519
<v Speaker 1>to my server from a remote location. Definitely, But I

429
00:20:54.559 --> 00:20:58.000
<v Speaker 1>have a confession. Setting it up always seemed a bit

430
00:20:58.079 --> 00:20:58.720
<v Speaker 1>daunting to me.

431
00:20:58.920 --> 00:21:02.559
<v Speaker 2>I get it. Yeah, but Caber provides clear, step by

432
00:21:02.559 --> 00:21:06.480
<v Speaker 2>step instructions on how to get and install open ssh,

433
00:21:07.079 --> 00:21:10.559
<v Speaker 2>configure the service, and even connect to an open ssh

434
00:21:10.599 --> 00:21:13.880
<v Speaker 2>server from a client machine. He makes it much easier

435
00:21:13.920 --> 00:21:15.039
<v Speaker 2>than it might seem.

436
00:21:14.839 --> 00:21:18.079
<v Speaker 1>At first glance. Okay, that's reassuring. Yeah, so we've covered

437
00:21:18.200 --> 00:21:22.240
<v Speaker 1>securing remote access, but what about managing users who are

438
00:21:22.279 --> 00:21:26.480
<v Speaker 1>already on the system. Okay, sometimes you need to give

439
00:21:26.559 --> 00:21:30.799
<v Speaker 1>certain users more privileges for specific tasks without giving them

440
00:21:30.799 --> 00:21:31.720
<v Speaker 1>full root access.

441
00:21:32.440 --> 00:21:36.079
<v Speaker 2>You're thinking about the sue command, which allows a user

442
00:21:36.119 --> 00:21:41.319
<v Speaker 2>to temporarily switch to another user account, often the root account.

443
00:21:41.440 --> 00:21:44.039
<v Speaker 1>Sure for a switch user, right, exactly, But isn't that risky?

444
00:21:44.240 --> 00:21:48.200
<v Speaker 2>It can be. That's why Kaber recommends using pseudo instead.

445
00:21:48.440 --> 00:21:51.319
<v Speaker 1>Pseudo Okay, yeah, Pseudo rings a bell, but I'm a

446
00:21:51.319 --> 00:21:54.240
<v Speaker 1>bit fuzzy on the details. Remind me what it's all about.

447
00:21:54.480 --> 00:21:58.559
<v Speaker 2>Pseudo stands for super rouser do. It's a much more

448
00:21:58.599 --> 00:22:04.640
<v Speaker 2>controlled way to grant limited root privileges to specific users

449
00:22:05.079 --> 00:22:06.240
<v Speaker 2>for specific commands.

450
00:22:06.279 --> 00:22:09.880
<v Speaker 1>So instead of giving someone full root access, I can say, hey,

451
00:22:09.960 --> 00:22:13.160
<v Speaker 1>you can restart the Apache web server, but you can't

452
00:22:13.200 --> 00:22:14.799
<v Speaker 1>do anything else that requires.

453
00:22:14.480 --> 00:22:17.279
<v Speaker 2>Root privileges, exactly, And you configure all of this in

454
00:22:17.319 --> 00:22:20.519
<v Speaker 2>a file called etceter sue doers Okay. Kabir even shows

455
00:22:20.519 --> 00:22:23.400
<v Speaker 2>you how to use aliases to group users and commands

456
00:22:23.519 --> 00:22:26.400
<v Speaker 2>and making the configuration more readable and easier to manage.

457
00:22:26.480 --> 00:22:28.880
<v Speaker 2>It's a great way to give people just enough power

458
00:22:28.960 --> 00:22:32.039
<v Speaker 2>to do their jobs without compromising security.

459
00:22:32.519 --> 00:22:36.039
<v Speaker 1>I like it, security, readability, and ease of management all

460
00:22:36.039 --> 00:22:40.160
<v Speaker 1>in one package, exactly. But let's broaden our view for

461
00:22:40.160 --> 00:22:44.720
<v Speaker 1>a moment. We've talked about securing the system itself, but

462
00:22:44.799 --> 00:22:48.880
<v Speaker 1>what about all those network services running on our Linux machines.

463
00:22:48.960 --> 00:22:53.160
<v Speaker 1>I'm talking about web servers, email servers, file sharing services.

464
00:22:53.519 --> 00:22:56.519
<v Speaker 1>Each one has its own set of security challenges.

465
00:22:56.119 --> 00:23:01.359
<v Speaker 2>Right, You're absolutely right, Yeah, securing these services is crucial, okay,

466
00:23:01.519 --> 00:23:05.319
<v Speaker 2>and Kabir dives deep into best practices for hardening each

467
00:23:05.400 --> 00:23:08.839
<v Speaker 2>of them. Let's start with web servers. Since they're often

468
00:23:09.240 --> 00:23:11.119
<v Speaker 2>the most exposed to the outside world.

469
00:23:11.319 --> 00:23:14.440
<v Speaker 1>Web servers are like the front door to our online presence.

470
00:23:14.880 --> 00:23:17.960
<v Speaker 1>We need to make sure they're lockdown type definitely, Where

471
00:23:17.960 --> 00:23:18.720
<v Speaker 1>do we even begin?

472
00:23:19.000 --> 00:23:24.559
<v Speaker 2>Kaber advocates for a paranoid configuration. Okay, it sounds extreme, ye,

473
00:23:24.799 --> 00:23:27.720
<v Speaker 2>but the idea is to assume that every request hitting

474
00:23:27.759 --> 00:23:31.880
<v Speaker 2>your web server is potentially malicious. You need to take

475
00:23:31.960 --> 00:23:35.720
<v Speaker 2>steps to minimize what's known as the attack surface, the

476
00:23:35.799 --> 00:23:38.799
<v Speaker 2>number of ways an attacker could potentially compromise your system.

477
00:23:39.279 --> 00:23:44.240
<v Speaker 1>Okay, I'm intrigued. What does this paranoid configuration actually look like.

478
00:23:44.440 --> 00:23:47.519
<v Speaker 2>It involves things like running apatche with a dedicated user

479
00:23:47.599 --> 00:23:52.039
<v Speaker 2>and group, using a secure directory structure, and setting strict

480
00:23:52.119 --> 00:23:56.480
<v Speaker 2>file and directory permissions to restrict access to sensitive areas.

481
00:23:56.799 --> 00:23:59.039
<v Speaker 1>Makes sense. You don't want just anyone snooping around in

482
00:23:59.160 --> 00:24:00.960
<v Speaker 1>your web server's file e exactly.

483
00:24:01.440 --> 00:24:05.559
<v Speaker 2>Another thing Kaber emphasizes is managing CGI scripts carefully.

484
00:24:05.759 --> 00:24:05.920
<v Speaker 1>Right.

485
00:24:06.400 --> 00:24:09.880
<v Speaker 2>These little programs that run on the web server can

486
00:24:09.960 --> 00:24:13.839
<v Speaker 2>introduce vulnerabilities if they're not handled properly.

487
00:24:14.039 --> 00:24:16.759
<v Speaker 1>Yes, CGI scripts, Yeah, those bring back memories from my

488
00:24:16.799 --> 00:24:20.079
<v Speaker 1>early days of web development. But it can be pretty powerful. Yeah,

489
00:24:20.079 --> 00:24:22.680
<v Speaker 1>but also a bit tricky from a security standpoint.

490
00:24:22.720 --> 00:24:27.480
<v Speaker 2>You're spot on. Kaber recommends taking steps to prevent information leaks,

491
00:24:27.720 --> 00:24:31.839
<v Speaker 2>limit the execution environment of CGI scripts, and even use

492
00:24:31.920 --> 00:24:36.200
<v Speaker 2>a tool called suxec to run them with the permissions

493
00:24:36.200 --> 00:24:39.160
<v Speaker 2>of the script's owner rather than the web server user.

494
00:24:39.279 --> 00:24:43.319
<v Speaker 1>So SUICKC is another layer of protection making sure CGI

495
00:24:43.400 --> 00:24:46.160
<v Speaker 1>scripts don't have more power than they absolutely need.

496
00:24:46.440 --> 00:24:47.200
<v Speaker 2>Got it, yep?

497
00:24:48.680 --> 00:24:53.720
<v Speaker 1>But I remember another potential web server security headache, SSI risks.

498
00:24:53.960 --> 00:24:56.039
<v Speaker 2>You're talking about server side includes right?

499
00:24:56.119 --> 00:24:57.000
<v Speaker 1>Service side includes.

500
00:24:57.039 --> 00:25:01.079
<v Speaker 2>They can be convenient for adding dynamic elements to web pages,

501
00:25:01.400 --> 00:25:03.519
<v Speaker 2>but they also come with their own set of risks,

502
00:25:03.640 --> 00:25:08.440
<v Speaker 2>especially if you're running external applications using SSI commands like exact.

503
00:25:08.240 --> 00:25:09.640
<v Speaker 1>Right, that's a big no no. You don't want to

504
00:25:09.640 --> 00:25:13.079
<v Speaker 1>give attackers the ability to execute arbitrary commands on your server.

505
00:25:13.279 --> 00:25:16.559
<v Speaker 2>Kaber shows us how to disable those risky commands using

506
00:25:16.599 --> 00:25:18.279
<v Speaker 2>Apache's options directive.

507
00:25:18.480 --> 00:25:18.799
<v Speaker 1>Okay.

508
00:25:19.119 --> 00:25:23.559
<v Speaker 2>He also discusses techniques for controlling access to specific directories

509
00:25:24.039 --> 00:25:26.759
<v Speaker 2>based on the host name or IP address, adding an

510
00:25:26.839 --> 00:25:28.680
<v Speaker 2>extra layer of security, so we.

511
00:25:28.640 --> 00:25:32.599
<v Speaker 1>Can restrict access to certain parts of the website, like

512
00:25:32.640 --> 00:25:36.599
<v Speaker 1>the administration area, to only trusted users or networks.

513
00:25:37.079 --> 00:25:41.359
<v Speaker 2>That's smart, exactly. And we can't forget about those pesky

514
00:25:41.640 --> 00:25:45.799
<v Speaker 2>web robots and spiders. Oh yeah, the robots that constantly crawl.

515
00:25:45.519 --> 00:25:48.480
<v Speaker 1>The web, right, those automated programs that index websites for

516
00:25:48.519 --> 00:25:49.200
<v Speaker 1>search engines.

517
00:25:49.359 --> 00:25:49.880
<v Speaker 2>Exactly.

518
00:25:49.960 --> 00:25:53.400
<v Speaker 1>They can be useful, but they can also cause problems

519
00:25:53.519 --> 00:25:56.799
<v Speaker 1>if they access areas of our site that we don't

520
00:25:56.799 --> 00:25:58.079
<v Speaker 1>want publicly indexed.

521
00:25:58.200 --> 00:26:03.279
<v Speaker 2>Precisely explains how to use the robot's exclusion protocol. Okay,

522
00:26:03.440 --> 00:26:06.720
<v Speaker 2>It lets you create a robots dot txt file that

523
00:26:06.839 --> 00:26:10.720
<v Speaker 2>tells these bots right where they're allowed to go and

524
00:26:10.759 --> 00:26:12.559
<v Speaker 2>where they're not allowed to go on your website.

525
00:26:12.640 --> 00:26:13.000
<v Speaker 1>All right.

526
00:26:13.039 --> 00:26:16.079
<v Speaker 2>It's like setting up clear boundaries for those digital.

527
00:26:15.759 --> 00:26:21.400
<v Speaker 1>Crawlers, so no more robots snooping around where they shouldn't exactly. Okay,

528
00:26:21.440 --> 00:26:24.039
<v Speaker 1>we've covered a lot of ground on web server security, right,

529
00:26:24.279 --> 00:26:27.200
<v Speaker 1>but what about email servers? Ok there are another prime

530
00:26:27.279 --> 00:26:30.000
<v Speaker 1>target for attackers and spammers. What are some of the

531
00:26:30.079 --> 00:26:31.839
<v Speaker 1>key security considerations there?

532
00:26:31.920 --> 00:26:33.720
<v Speaker 2>You're right, email security is critical.

533
00:26:33.920 --> 00:26:34.319
<v Speaker 1>Yeah.

534
00:26:34.440 --> 00:26:38.079
<v Speaker 2>Kabir dives into the intricacies of DNS okay, and how

535
00:26:38.119 --> 00:26:43.200
<v Speaker 2>to configure your DNS server securely okay to prevent spoofing attacks.

536
00:26:43.559 --> 00:26:45.720
<v Speaker 1>Hold on a second, I thought DNS was just for

537
00:26:45.799 --> 00:26:49.559
<v Speaker 1>translating domain names into IP addresses, right, How can it

538
00:26:49.599 --> 00:26:51.440
<v Speaker 1>be exploited for malicious purposes?

539
00:26:51.680 --> 00:26:55.000
<v Speaker 2>It's more than just a simple lookup system, okay. Attackers

540
00:26:55.000 --> 00:26:59.759
<v Speaker 2>can use techniques like cash poisoning to redirect users to

541
00:27:00.079 --> 00:27:05.119
<v Speaker 2>malicious websites okay, or intercept sensitive information. Kabeer explains how

542
00:27:05.119 --> 00:27:08.759
<v Speaker 2>to mitigate these risks by keeping your DNS configurations secure

543
00:27:08.799 --> 00:27:11.000
<v Speaker 2>and up to date. It's like making sure your phone

544
00:27:11.000 --> 00:27:12.759
<v Speaker 2>book is accurate and trustworthy.

545
00:27:12.960 --> 00:27:13.240
<v Speaker 1>Okay.

546
00:27:13.319 --> 00:27:15.359
<v Speaker 2>You don't want people ending up at the wrong number

547
00:27:15.519 --> 00:27:17.640
<v Speaker 2>or getting tricked into giving away their information.

548
00:27:18.359 --> 00:27:21.960
<v Speaker 1>That makes sense. Yeah, okay, so we need to make

549
00:27:21.960 --> 00:27:25.079
<v Speaker 1>sure our DNS is rock solid exactly. Well, what about

550
00:27:25.160 --> 00:27:29.160
<v Speaker 1>preventing our email servers from being used as open mail relays.

551
00:27:29.359 --> 00:27:33.440
<v Speaker 2>That's a huge problem. Open mail relays can be hijacked

552
00:27:33.440 --> 00:27:37.400
<v Speaker 2>by spammers to send out massive amounts of junk mail.

553
00:27:38.160 --> 00:27:38.680
<v Speaker 1>Yeah.

554
00:27:38.720 --> 00:27:41.519
<v Speaker 2>It's like having your mailbox turn into a spam factory.

555
00:27:41.960 --> 00:27:42.200
<v Speaker 1>Yeah.

556
00:27:42.279 --> 00:27:45.599
<v Speaker 2>Kaber provides detailed instructions on how to configure both send

557
00:27:45.640 --> 00:27:49.799
<v Speaker 2>mail and postfix two popular email servers to prevent this

558
00:27:49.880 --> 00:27:50.599
<v Speaker 2>kind of abuse.

559
00:27:50.720 --> 00:27:53.519
<v Speaker 1>Okay, so we're locking down our email servers, yeah, to

560
00:27:53.559 --> 00:27:57.319
<v Speaker 1>prevent them from becoming spams ons. But what about protecting

561
00:27:57.359 --> 00:27:58.519
<v Speaker 1>the email itself?

562
00:27:58.680 --> 00:27:59.039
<v Speaker 2>Okay?

563
00:27:59.160 --> 00:28:02.680
<v Speaker 1>I mean can attackers intercept emails in transit? They can,

564
00:28:02.960 --> 00:28:04.440
<v Speaker 1>or attach malicious files.

565
00:28:04.480 --> 00:28:08.519
<v Speaker 2>Absolutely? Yeah, That's why Kabeer talks about techniques for sanitizing

566
00:28:08.599 --> 00:28:13.400
<v Speaker 2>incoming email, filtering out spam and viruses, and even scanning

567
00:28:13.400 --> 00:28:18.400
<v Speaker 2>attachments for potentially harmful content. He even provides scripts and

568
00:28:18.480 --> 00:28:22.039
<v Speaker 2>examples for setting up this kind of protection so you

569
00:28:22.039 --> 00:28:23.319
<v Speaker 2>don't have to start from scratch.

570
00:28:23.519 --> 00:28:26.519
<v Speaker 1>It's like having a security checkpoint for all incoming and

571
00:28:26.559 --> 00:28:30.599
<v Speaker 1>outgoing mail exactly. Sure nothing dangerous gets through. Now, what

572
00:28:30.640 --> 00:28:34.680
<v Speaker 1>about other network services like file sharing? Okay, I know

573
00:28:34.799 --> 00:28:39.319
<v Speaker 1>Samba and NFS are popular choices for Linux file servers. Yep, yeah,

574
00:28:39.359 --> 00:28:43.279
<v Speaker 1>do they have their own unique security considerations?

575
00:28:43.519 --> 00:28:46.880
<v Speaker 2>They certainly do, and Kabeer dedicates a whole chapter to

576
00:28:46.920 --> 00:28:50.920
<v Speaker 2>Samba and NFS server security. He discusses how to choose

577
00:28:51.039 --> 00:28:56.119
<v Speaker 2>appropriate security levels, manage user access, and even configure Samba

578
00:28:56.160 --> 00:28:59.599
<v Speaker 2>to use SSL for encrypted communications.

579
00:29:00.039 --> 00:29:05.319
<v Speaker 1>Tell the same technology that secures websites, but for file

580
00:29:05.359 --> 00:29:08.039
<v Speaker 1>sharing that sounds pretty serious. It is, Okay.

581
00:29:08.119 --> 00:29:10.440
<v Speaker 2>It adds an extra layer of protection, especially if you're

582
00:29:10.440 --> 00:29:12.480
<v Speaker 2>sharing sensitive files over the network.

583
00:29:12.559 --> 00:29:12.799
<v Speaker 1>Okay.

584
00:29:13.000 --> 00:29:17.119
<v Speaker 2>Kabir also emphasizes the importance of restricting root access on

585
00:29:17.319 --> 00:29:21.640
<v Speaker 2>NFS servers and using features like squashing to prevent users

586
00:29:21.680 --> 00:29:23.680
<v Speaker 2>from gaining unauthorized privileges.

587
00:29:23.799 --> 00:29:26.880
<v Speaker 1>Okay, So we're taking file sharing security just as seriously,

588
00:29:26.960 --> 00:29:29.920
<v Speaker 1>absolutely as we take web and email security. No weak

589
00:29:29.960 --> 00:29:33.799
<v Speaker 1>links in the chain. But I have a question. With

590
00:29:33.920 --> 00:29:36.839
<v Speaker 1>all these security measures in place, how do we know

591
00:29:36.880 --> 00:29:39.880
<v Speaker 1>if they're actually working? How do we know if our

592
00:29:39.920 --> 00:29:41.160
<v Speaker 1>system is truly secure.

593
00:29:41.319 --> 00:29:44.839
<v Speaker 2>That's where firewalls come in. They're like the gatekeepers of

594
00:29:44.880 --> 00:29:49.359
<v Speaker 2>your network, controlling what traffic is allowed in and out right.

595
00:29:49.519 --> 00:29:53.319
<v Speaker 2>Kabir devotes a whole section to firewalls, covering everything from

596
00:29:53.359 --> 00:29:56.200
<v Speaker 2>the basic concepts to advanced configurations.

597
00:29:56.240 --> 00:29:58.480
<v Speaker 1>Firewalls always seemed to have been intimidating to me. I'm

598
00:29:58.519 --> 00:30:02.359
<v Speaker 1>more of a software person, not a networking guru. Sure

599
00:30:02.599 --> 00:30:04.079
<v Speaker 1>is it really something I can handle?

600
00:30:04.319 --> 00:30:07.920
<v Speaker 2>Don't worry. Kabir explains it all in a very approachable way.

601
00:30:07.920 --> 00:30:12.359
<v Speaker 2>He starts with packet filtering firewalls, which operate at the

602
00:30:12.400 --> 00:30:17.000
<v Speaker 2>network layer, inspecting individual packets and deciding whether to allow

603
00:30:17.279 --> 00:30:19.880
<v Speaker 2>or block them based on predefined rules.

604
00:30:20.160 --> 00:30:22.720
<v Speaker 1>So they're like a bouncer at a club, exactly checking

605
00:30:22.759 --> 00:30:24.759
<v Speaker 1>IDs to make sure only the right people get in.

606
00:30:25.119 --> 00:30:29.279
<v Speaker 2>And Caber shows how to use the ipptable's command to

607
00:30:29.480 --> 00:30:34.400
<v Speaker 2>create and manage these firewall rules. He even provides a

608
00:30:34.440 --> 00:30:38.640
<v Speaker 2>complete example of a firewall script designed for a small

609
00:30:38.759 --> 00:30:41.279
<v Speaker 2>office or home network. You don't have to be a

610
00:30:41.279 --> 00:30:42.640
<v Speaker 2>network expert to get started.

611
00:30:42.759 --> 00:30:46.519
<v Speaker 1>Okay, that sounds manageable, but what about more advanced firewall techniques?

612
00:30:46.559 --> 00:30:48.200
<v Speaker 1>Are those only for the networking wizards?

613
00:30:48.680 --> 00:30:54.640
<v Speaker 2>Not necessarily? Kabir also discusses using Squid, the proxy caching

614
00:30:54.680 --> 00:30:58.680
<v Speaker 2>server we talked about earlier, as a firewall. It operates

615
00:30:58.680 --> 00:31:02.759
<v Speaker 2>at the application layer, right, giving you more granular control

616
00:31:02.880 --> 00:31:04.960
<v Speaker 2>over what web traffic is allowed through.

617
00:31:05.480 --> 00:31:10.519
<v Speaker 1>Interesting, so Squid can wear two hats. It can cashing

618
00:31:10.559 --> 00:31:13.960
<v Speaker 1>web content for better performance and filtering traffic for security.

619
00:31:14.119 --> 00:31:17.720
<v Speaker 1>Exactly what a multitasker it is. And for those who

620
00:31:17.960 --> 00:31:24.240
<v Speaker 1>need to create secure connections between networks, Couber introduces free swan,

621
00:31:25.319 --> 00:31:31.440
<v Speaker 1>a powerful ip SC implementation for Linux i'bsec that sounds

622
00:31:31.440 --> 00:31:32.079
<v Speaker 1>pretty serious.

623
00:31:32.279 --> 00:31:35.319
<v Speaker 2>It is a suite of protocols for securing network communications

624
00:31:35.319 --> 00:31:36.160
<v Speaker 2>at the IP layer.

625
00:31:36.319 --> 00:31:36.640
<v Speaker 1>Okay.

626
00:31:36.759 --> 00:31:40.480
<v Speaker 2>It provides authentication and encryption, ensuring that data transmitted between

627
00:31:40.519 --> 00:31:42.680
<v Speaker 2>networks remains confidential and tamper proof.

628
00:31:42.799 --> 00:31:45.680
<v Speaker 1>So it's like creating a virtual private network exactly, or

629
00:31:45.759 --> 00:31:49.119
<v Speaker 1>VPN over a public network like the Internet. I've used

630
00:31:49.160 --> 00:31:52.680
<v Speaker 1>VPNs before, okay, but I never really understood how they

631
00:31:52.720 --> 00:31:53.519
<v Speaker 1>worked into the hood.

632
00:31:53.720 --> 00:31:54.119
<v Speaker 2>Now you do.

633
00:31:54.400 --> 00:31:54.799
<v Speaker 1>Yeah.

634
00:31:55.000 --> 00:31:57.359
<v Speaker 2>Free swan allows you to set up this kind of

635
00:31:57.400 --> 00:32:04.400
<v Speaker 2>secure tunnel between your networks, protecting sensitive data from prying eyes.

636
00:32:04.799 --> 00:32:07.640
<v Speaker 1>All right, those are some serious firewall skills we're building

637
00:32:07.720 --> 00:32:11.200
<v Speaker 1>up here. But even with a rock solid firewall in place,

638
00:32:11.319 --> 00:32:14.799
<v Speaker 1>there's always a chance that something could slip through the cracks.

639
00:32:15.720 --> 00:32:19.960
<v Speaker 1>What about intrusion detection? Okay, how can we catch those

640
00:32:19.960 --> 00:32:23.079
<v Speaker 1>sneaky attacks that manage to bypass our defenses.

641
00:32:23.680 --> 00:32:26.480
<v Speaker 2>That's a great question, and Kabir doesn't leave us hang in.

642
00:32:26.759 --> 00:32:27.319
<v Speaker 1>Okay, good.

643
00:32:27.440 --> 00:32:31.519
<v Speaker 2>He dives into the world of intrusion detection systems or idss,

644
00:32:31.880 --> 00:32:35.400
<v Speaker 2>which act as a second line of defense. They constantly

645
00:32:35.559 --> 00:32:39.079
<v Speaker 2>monitor your network for suspicious activity and alert you to

646
00:32:39.160 --> 00:32:40.799
<v Speaker 2>potential attacks in progress.

647
00:32:41.359 --> 00:32:44.200
<v Speaker 1>So they're like a security camera system. Exactly that not

648
00:32:44.279 --> 00:32:48.920
<v Speaker 1>only records what's happening, but also analyzes the footage for

649
00:32:49.000 --> 00:32:49.920
<v Speaker 1>any signs of trouble.

650
00:32:50.119 --> 00:32:53.160
<v Speaker 2>That's a great analogy, right, and Kabir introduces us to

651
00:32:53.279 --> 00:32:59.759
<v Speaker 2>several powerful IDs tools, including Snart, Saint Okay, and Nessus.

652
00:33:00.240 --> 00:33:02.359
<v Speaker 1>Let's take a close to look at those. First up, Snort,

653
00:33:03.200 --> 00:33:04.240
<v Speaker 1>what's its claim to fame?

654
00:33:04.960 --> 00:33:10.200
<v Speaker 2>Snort is a network based IDs that analyzes network traffic

655
00:33:10.319 --> 00:33:15.400
<v Speaker 2>in real time, looking for patterns that match known attack signatures. Okay,

656
00:33:15.599 --> 00:33:18.839
<v Speaker 2>it's like having a team of security analysts constantly watching

657
00:33:18.880 --> 00:33:22.759
<v Speaker 2>your network traffic for any signs of malicious activity.

658
00:33:23.000 --> 00:33:26.319
<v Speaker 1>So Snort is constantly on the lookout yep for known

659
00:33:26.480 --> 00:33:28.640
<v Speaker 1>attack patterns. What about Saint?

660
00:33:29.240 --> 00:33:33.640
<v Speaker 2>Saint is a vulnerability assessment tool. It scans your systems

661
00:33:33.680 --> 00:33:37.319
<v Speaker 2>for potential weaknesses that attackers could exploit. It's like a

662
00:33:37.359 --> 00:33:40.119
<v Speaker 2>proactive security audit ca can you identify and fix those

663
00:33:40.160 --> 00:33:42.880
<v Speaker 2>holes before they can be used against you?

664
00:33:43.839 --> 00:33:47.720
<v Speaker 1>So Saint is all about prevention, finding and fixing those

665
00:33:47.759 --> 00:33:49.680
<v Speaker 1>weak spots before they become problems.

666
00:33:49.759 --> 00:33:50.279
<v Speaker 2>Exactly?

667
00:33:50.400 --> 00:33:52.400
<v Speaker 1>What about nessis what does it bring to the table.

668
00:33:52.799 --> 00:33:57.119
<v Speaker 2>Nessus is another vulnerability scanner known for its comprehensive checks

669
00:33:57.160 --> 00:34:01.119
<v Speaker 2>and detailed reports. It can assess the security of your

670
00:34:01.319 --> 00:34:06.519
<v Speaker 2>entire network, from servers and workstations to network devices and

671
00:34:06.559 --> 00:34:07.680
<v Speaker 2>web applications.

672
00:34:07.720 --> 00:34:08.000
<v Speaker 1>Wow.

673
00:34:08.159 --> 00:34:11.079
<v Speaker 2>It's a powerful tool for getting a complete picture of

674
00:34:11.119 --> 00:34:12.400
<v Speaker 2>your security posture.

675
00:34:12.679 --> 00:34:16.000
<v Speaker 1>Wow. So we've got SNORT for real time intrusion detection

676
00:34:16.920 --> 00:34:20.679
<v Speaker 1>and NESSUS for vulnerability scanning. Our security arsenal is starting

677
00:34:20.679 --> 00:34:21.559
<v Speaker 1>to look pretty impressive.

678
00:34:21.719 --> 00:34:22.159
<v Speaker 2>I know, right.

679
00:34:22.199 --> 00:34:24.679
<v Speaker 1>But Kabir mentions a few other tools that don't quite

680
00:34:24.719 --> 00:34:26.679
<v Speaker 1>fit into those categories. What are those?

681
00:34:26.800 --> 00:34:32.440
<v Speaker 2>He highlights some essential utilities for security administrators, including netcat,

682
00:34:33.079 --> 00:34:37.920
<v Speaker 2>TCP dump, LSOF and you guessed it makes another appearance.

683
00:34:37.960 --> 00:34:41.039
<v Speaker 1>Wait and rep again. I know, right, didn't we already

684
00:34:41.079 --> 00:34:41.599
<v Speaker 1>cover that one?

685
00:34:41.639 --> 00:34:42.039
<v Speaker 2>We did?

686
00:34:42.159 --> 00:34:43.440
<v Speaker 1>Why is it back for noncore?

687
00:34:43.760 --> 00:34:49.039
<v Speaker 2>Because it's just that versatile. It's fantastic for troubleshooting network issues,

688
00:34:49.480 --> 00:34:55.000
<v Speaker 2>but it's also incredibly powerful for security purposes like monitoring

689
00:34:55.000 --> 00:34:59.239
<v Speaker 2>for suspicious traffic patterns or even detecting intrusion attempts.

690
00:34:59.360 --> 00:35:02.360
<v Speaker 1>Ah, it's a multipurpose tool, it is. It can be

691
00:35:02.400 --> 00:35:07.199
<v Speaker 1>wielded for both performance and security investigations. No wonder it's

692
00:35:07.199 --> 00:35:10.599
<v Speaker 1>a favorite among Linux admins. But what about those other

693
00:35:10.639 --> 00:35:15.400
<v Speaker 1>tools you mentioned? Netcat, TCP dump, and LSOs tell me

694
00:35:15.400 --> 00:35:16.679
<v Speaker 1>more about their security uses.

695
00:35:17.000 --> 00:35:20.079
<v Speaker 2>Netcat is a powerful networking tool. You can use it

696
00:35:20.119 --> 00:35:25.119
<v Speaker 2>for everything from simple port scanning to creating backdoor connections.

697
00:35:25.480 --> 00:35:29.159
<v Speaker 2>It's a double edged sword, incredibly useful for security testing,

698
00:35:29.679 --> 00:35:32.360
<v Speaker 2>but also potentially dangerous in the wrong hands.

699
00:35:32.679 --> 00:35:37.760
<v Speaker 1>So nickcat is a tool that demands respect. It's powerful,

700
00:35:38.039 --> 00:35:40.599
<v Speaker 1>it is, but it needs to be used responsibly.

701
00:35:40.639 --> 00:35:41.159
<v Speaker 2>Absolutely.

702
00:35:41.199 --> 00:35:43.880
<v Speaker 1>What about TCP dump? Okay, what are its strengths?

703
00:35:44.199 --> 00:35:49.039
<v Speaker 2>TCP dump is a classic network packet analyzer. It's been

704
00:35:49.039 --> 00:35:53.400
<v Speaker 2>around for decades and is still widely used for capturing

705
00:35:53.440 --> 00:35:56.719
<v Speaker 2>and analyzing network traffic. It's a bit more low level

706
00:35:56.760 --> 00:35:59.679
<v Speaker 2>than INGP, but that can be an advantage if you

707
00:35:59.679 --> 00:36:02.599
<v Speaker 2>need to do some really detailed network forensics.

708
00:36:02.639 --> 00:36:05.840
<v Speaker 1>And LSOF I think we talked about that earlier contest

709
00:36:05.880 --> 00:36:06.400
<v Speaker 1>of security.

710
00:36:06.519 --> 00:36:11.360
<v Speaker 2>Right, You're right. LSOF is incredibly useful for identifying open

711
00:36:11.440 --> 00:36:14.480
<v Speaker 2>files on your system, which can be a gold mine

712
00:36:14.519 --> 00:36:18.679
<v Speaker 2>of information for security investigations. It can help you track

713
00:36:18.760 --> 00:36:24.159
<v Speaker 2>down suspicious processes, uncover hidden malware, and generally get a

714
00:36:24.159 --> 00:36:27.559
<v Speaker 2>better understanding of what's happening on your system. Kabir gives

715
00:36:27.599 --> 00:36:30.760
<v Speaker 2>some great examples of how to use LSOF effectively for

716
00:36:30.840 --> 00:36:31.920
<v Speaker 2>security analysis.

717
00:36:32.079 --> 00:36:34.280
<v Speaker 1>Okay, those are some seriously powerful tools.

718
00:36:34.320 --> 00:36:34.639
<v Speaker 2>They are.

719
00:36:35.159 --> 00:36:37.639
<v Speaker 1>But before we wrap up this deep dive, I want

720
00:36:37.679 --> 00:36:39.920
<v Speaker 1>to touch on one more thing that's been on my mind. Okay,

721
00:36:40.119 --> 00:36:44.719
<v Speaker 1>with technology evolving so rapidly, how can we possibly keep

722
00:36:44.800 --> 00:36:48.239
<v Speaker 1>up with all the latest threats and vulnerabilities? It feels

723
00:36:48.280 --> 00:36:50.280
<v Speaker 1>like a never ending race against the bad guys.

724
00:36:51.400 --> 00:36:55.199
<v Speaker 2>You're not wrong, and it's a question that Kaber addresses

725
00:36:55.320 --> 00:36:56.079
<v Speaker 2>head on in.

726
00:36:56.039 --> 00:36:56.920
<v Speaker 1>His book Okay.

727
00:36:57.079 --> 00:37:00.480
<v Speaker 2>He emphasizes the importance of continuous learning. You need to

728
00:37:00.480 --> 00:37:05.119
<v Speaker 2>stay informed about emerging s threats and adopt a proactive

729
00:37:05.440 --> 00:37:09.360
<v Speaker 2>approach to security. It's not a set it and forget it.

730
00:37:09.360 --> 00:37:11.079
<v Speaker 1>Kind of thing. So we can't just set up our

731
00:37:11.119 --> 00:37:14.280
<v Speaker 1>security measures and then pat ourselves on the back and

732
00:37:14.360 --> 00:37:15.000
<v Speaker 1>call it a day.

733
00:37:15.360 --> 00:37:16.960
<v Speaker 2>Not If you want to stay ahead of the curve.

734
00:37:17.159 --> 00:37:21.440
<v Speaker 2>Right the threat landscape is constantly shifting and new attack

735
00:37:21.559 --> 00:37:24.199
<v Speaker 2>techniques are being developed all the time. You need to

736
00:37:24.199 --> 00:37:29.840
<v Speaker 2>be vigilant, adapt your defenses and always be learning new

737
00:37:29.920 --> 00:37:32.440
<v Speaker 2>techniques to stay one step ahead.

738
00:37:32.760 --> 00:37:35.280
<v Speaker 1>That sounds like a lot of work, it is, but

739
00:37:35.440 --> 00:37:37.320
<v Speaker 1>I guess it's the price we pay for security.

740
00:37:37.480 --> 00:37:41.280
<v Speaker 2>It is digital age. But Kabir doesn't just lay out

741
00:37:41.320 --> 00:37:45.119
<v Speaker 2>the challenges. He also provides inspiration. He encourages readers to

742
00:37:45.239 --> 00:37:48.840
<v Speaker 2>explore furly, experiment with the techniques and tools he discusses,

743
00:37:49.480 --> 00:37:53.039
<v Speaker 2>and even contribute to the open source security community. It's

744
00:37:53.079 --> 00:37:56.159
<v Speaker 2>a call to action to become active participants in the

745
00:37:56.199 --> 00:37:59.920
<v Speaker 2>ongoing fight for a more secure digital world.

746
00:38:00.119 --> 00:38:03.159
<v Speaker 1>I love that message. It's not just about protecting ourselves,

747
00:38:03.480 --> 00:38:06.360
<v Speaker 1>it's about working together to make the entire Internet a

748
00:38:06.360 --> 00:38:07.039
<v Speaker 1>safer place.

749
00:38:07.119 --> 00:38:07.719
<v Speaker 2>Exactly.

750
00:38:08.760 --> 00:38:11.400
<v Speaker 1>Wow, we've covered a ton of ground in this deep

751
00:38:11.440 --> 00:38:15.360
<v Speaker 1>dive into red hat Linux performance and security, from the

752
00:38:15.440 --> 00:38:17.760
<v Speaker 1>nitty gritty of kernel tuning to the front lines of

753
00:38:17.840 --> 00:38:18.639
<v Speaker 1>network defense.

754
00:38:19.119 --> 00:38:21.519
<v Speaker 2>It's been quite a journey, it has been, hasn't it.

755
00:38:21.639 --> 00:38:23.360
<v Speaker 1>What are your key takeaways from all this?

756
00:38:25.360 --> 00:38:27.840
<v Speaker 2>One thing that really stands out for me is how

757
00:38:27.880 --> 00:38:31.239
<v Speaker 2>interconnected performance and security are in a Linux environment.

758
00:38:31.400 --> 00:38:31.519
<v Speaker 1>Ok.

759
00:38:31.840 --> 00:38:34.639
<v Speaker 2>Right, It's not just about speed our security. They work

760
00:38:34.719 --> 00:38:37.760
<v Speaker 2>together to create a robust and resilient system.

761
00:38:38.079 --> 00:38:41.159
<v Speaker 1>It's like you said earlier, even the strongest fortress is

762
00:38:41.239 --> 00:38:46.000
<v Speaker 1>vulnerable if the guards are slow and the defenses are sluggish.

763
00:38:46.079 --> 00:38:50.159
<v Speaker 1>Performance is a key enabler of effective security. It is,

764
00:38:50.960 --> 00:38:54.719
<v Speaker 1>but Kabir doesn't stop at the technical details. He also

765
00:38:54.800 --> 00:38:59.280
<v Speaker 1>encourages readers to adopt a certain mindset, a way of

766
00:38:59.360 --> 00:39:03.320
<v Speaker 1>approaching Linux performance and security. What would you say that

767
00:39:03.360 --> 00:39:04.000
<v Speaker 1>mindset is.

768
00:39:04.239 --> 00:39:10.280
<v Speaker 2>It's a mindset of proactivity, continuous learning, and constant vigilance. Okay,

769
00:39:10.440 --> 00:39:13.480
<v Speaker 2>the threat landscape is always changing, so we can't afford

770
00:39:13.559 --> 00:39:17.119
<v Speaker 2>to become complacent, right, We need to stay informed, ok,

771
00:39:17.360 --> 00:39:19.880
<v Speaker 2>adapt our defenses, and always be on the lookout for

772
00:39:19.960 --> 00:39:21.039
<v Speaker 2>new vulnerabilities.

773
00:39:21.239 --> 00:39:26.239
<v Speaker 1>It's almost like becoming a security detective. Yeah, exactly, always investigating, analyzing,

774
00:39:26.400 --> 00:39:29.440
<v Speaker 1>and looking for clues that could point to a potential breach.

775
00:39:30.519 --> 00:39:33.280
<v Speaker 1>But with so much information out there, right, it can

776
00:39:33.320 --> 00:39:35.760
<v Speaker 1>be overwhelming to know where to start.

777
00:39:36.000 --> 00:39:38.239
<v Speaker 2>What advice would you give to someone who wants to

778
00:39:38.239 --> 00:39:40.760
<v Speaker 2>become more proactive about their Linux security.

779
00:39:41.320 --> 00:39:44.719
<v Speaker 1>I'd say focus on the fundamentals first, master the basics

780
00:39:44.760 --> 00:39:48.119
<v Speaker 1>of file permissions, user management.

781
00:39:47.880 --> 00:39:53.760
<v Speaker 2>And secure remote access. Then start exploring the world of firewalls,

782
00:39:54.280 --> 00:39:59.039
<v Speaker 2>intrusion detection systems, and vulnerability scanning. There are tons of

783
00:39:59.079 --> 00:40:02.719
<v Speaker 2>great resources of available online, including the documentation for the

784
00:40:02.760 --> 00:40:03.519
<v Speaker 2>tools we've.

785
00:40:03.360 --> 00:40:06.559
<v Speaker 3>Discussed, and don't forget about Kabir's book. Yes, definitely, it's

786
00:40:06.559 --> 00:40:10.400
<v Speaker 3>a treasure trove of practical guidance and real world examples.

787
00:40:10.840 --> 00:40:14.239
<v Speaker 3>It's definitely earned a permanent spot on my bookshelf. Absolutely,

788
00:40:14.280 --> 00:40:17.599
<v Speaker 3>it's a great starting point, but the real learning comes

789
00:40:17.639 --> 00:40:19.280
<v Speaker 3>from hands on experience.

790
00:40:19.400 --> 00:40:19.840
<v Speaker 2>It does.

791
00:40:19.920 --> 00:40:23.159
<v Speaker 1>Experiment with the tools YEP, set up a test environment

792
00:40:23.559 --> 00:40:27.280
<v Speaker 1>and see what you can do to improve your system security.

793
00:40:26.599 --> 00:40:29.880
<v Speaker 2>Exactly, and don't be afraid to make mistakes. That's how

794
00:40:29.880 --> 00:40:33.760
<v Speaker 2>we learn, right. Set up a virtual machine, break things,

795
00:40:33.960 --> 00:40:37.079
<v Speaker 2>fix them, and repeat. It's the best way to build

796
00:40:37.079 --> 00:40:38.400
<v Speaker 2>your skills and confidence.

797
00:40:38.519 --> 00:40:40.159
<v Speaker 1>Okay, I'm feeling inspired.

798
00:40:40.400 --> 00:40:40.639
<v Speaker 2>Nice.

799
00:40:40.679 --> 00:40:42.840
<v Speaker 1>I'm ready to roll up my sleeves and start putting

800
00:40:42.840 --> 00:40:45.960
<v Speaker 1>all this knowledge into practice. But before we wrap up,

801
00:40:46.599 --> 00:40:48.760
<v Speaker 1>I want to leave our listeners with a final thought

802
00:40:48.800 --> 00:40:54.440
<v Speaker 1>provoking question to ponder. Given how rapidly technology evolves, what

803
00:40:54.559 --> 00:40:58.199
<v Speaker 1>new performance or security concerns might emerge in the near future.

804
00:40:58.480 --> 00:41:01.400
<v Speaker 2>That's a great question, it is, isn't it. It's hard

805
00:41:01.400 --> 00:41:05.760
<v Speaker 2>to predict the future with certainty, but I think one

806
00:41:05.840 --> 00:41:08.960
<v Speaker 2>area that will continue to present challenges is the growing

807
00:41:09.000 --> 00:41:14.039
<v Speaker 2>complexity of software and systems. As our applications and infrastructure

808
00:41:14.079 --> 00:41:18.559
<v Speaker 2>become more interconnected and reliant on third party components, the

809
00:41:18.599 --> 00:41:23.039
<v Speaker 2>attack surface expands and new vulnerabilities emerge, will need to

810
00:41:23.079 --> 00:41:27.039
<v Speaker 2>develop even more sophisticated security measures to keep pace.

811
00:41:27.280 --> 00:41:29.599
<v Speaker 1>It's like a never ending arms race. It is as

812
00:41:29.599 --> 00:41:34.440
<v Speaker 1>attackers develop new techniques, we need to develop new defenses exactly.

813
00:41:34.639 --> 00:41:37.239
<v Speaker 1>But it's not just about technology right now. I think

814
00:41:37.280 --> 00:41:39.800
<v Speaker 1>the human element will continue to play a crucial role

815
00:41:39.840 --> 00:41:40.920
<v Speaker 1>in security.

816
00:41:40.559 --> 00:41:45.880
<v Speaker 2>Absolutely no matter how advanced our technology becomes, human error

817
00:41:46.000 --> 00:41:50.760
<v Speaker 2>and social engineering will always be potential weak points. We

818
00:41:50.840 --> 00:41:55.480
<v Speaker 2>need to educate users about security best practices, promote a

819
00:41:55.559 --> 00:42:00.480
<v Speaker 2>culture of security or wellness, and develop strategies for midigating

820
00:42:00.559 --> 00:42:02.360
<v Speaker 2>the risks posed by human behavior.

821
00:42:02.480 --> 00:42:06.679
<v Speaker 1>So as a combination of technical expertise, vigilance, and a

822
00:42:06.840 --> 00:42:11.440
<v Speaker 1>deep understanding of human psychology that will be key to

823
00:42:11.559 --> 00:42:15.360
<v Speaker 1>navigating the future of security. But on a more hopeful note, okay,

824
00:42:15.519 --> 00:42:19.440
<v Speaker 1>I think advancements in artificial intelligence and machine learning could

825
00:42:19.440 --> 00:42:20.599
<v Speaker 1>also play a positive role.

826
00:42:20.719 --> 00:42:24.440
<v Speaker 2>I agree AI and mL have the potential to revolutionize

827
00:42:24.440 --> 00:42:30.159
<v Speaker 2>security by automating threat detection, identifying patterns that humans might miss,

828
00:42:30.599 --> 00:42:33.480
<v Speaker 2>and helping us respond to incidents more quickly and effectively.

829
00:42:33.920 --> 00:42:36.760
<v Speaker 2>But we need to be mindful of the potential risks

830
00:42:36.840 --> 00:42:39.760
<v Speaker 2>as well. AI itself can be a target for attackers

831
00:42:40.199 --> 00:42:42.840
<v Speaker 2>and we need to ensure that these powerful tools are

832
00:42:42.920 --> 00:42:44.719
<v Speaker 2>used responsibly and ethically.

833
00:42:45.119 --> 00:42:47.840
<v Speaker 1>So the future filled with both challenges and opportunities, it's

834
00:42:47.840 --> 00:42:49.840
<v Speaker 1>going to be an exciting ride. It certainly will be.

835
00:42:50.079 --> 00:42:55.000
<v Speaker 2>But if we stay informed, keep learning, and embrace a

836
00:42:55.119 --> 00:42:59.119
<v Speaker 2>proactive approach to security, I'm confident we can rise to

837
00:42:59.159 --> 00:42:59.800
<v Speaker 2>the occasion.

838
00:43:00.079 --> 00:43:00.559
<v Speaker 1>I agree.

839
00:43:00.719 --> 00:43:03.880
<v Speaker 2>I couldn't agree more. Well, this has been an incredible

840
00:43:03.920 --> 00:43:06.400
<v Speaker 2>deep dive into the world of red hat Linux performance

841
00:43:06.400 --> 00:43:09.599
<v Speaker 2>and security. It has been I've learned so much. Me too,

842
00:43:09.679 --> 00:43:10.960
<v Speaker 2>and I hope our listeners.

843
00:43:10.639 --> 00:43:11.519
<v Speaker 1>Have too, I hope.

844
00:43:11.559 --> 00:43:14.239
<v Speaker 2>So what's your final message to our audience?

845
00:43:14.719 --> 00:43:19.519
<v Speaker 1>Keep exploring, okay, keep experimenting, and keep pushing the boundaries

846
00:43:19.639 --> 00:43:22.719
<v Speaker 1>of what's possible with Linux. The journey is just beginning.

847
00:43:23.000 --> 00:43:29.320
<v Speaker 2>I love it. Happy hacking everyone, and until next time,

848
00:43:29.559 --> 00:43:32.360
<v Speaker 2>may your systems run smoothly and your data remain secure.

849
00:43:32.639 --> 00:43:33.239
<v Speaker 1>Sounds good.