1 00:00:00,000 --> 00:00:09,680 In this video, we'll talk about auditing. 2 00:00:09,680 --> 00:00:14,960 So logging is what is used for writing messages that were generated by specific events to 3 00:00:14,960 --> 00:00:16,900 log files. 4 00:00:16,900 --> 00:00:20,280 Logging is typically initiated by services. 5 00:00:20,280 --> 00:00:22,240 Auditing is much more detailed. 6 00:00:22,240 --> 00:00:27,280 It's a system feature that works at the kernel level and you can use it to do a deep investigation 7 00:00:27,280 --> 00:00:30,000 of what is happening on a system. 8 00:00:30,000 --> 00:00:33,939 To use auditing, the AuditD service must be operational. 9 00:00:33,939 --> 00:00:39,360 And that's not always the case by default, so check in SystemD if it is running. 10 00:00:39,360 --> 00:00:44,040 And the AuditCTL command can be used to write specific rules about events that should be 11 00:00:44,040 --> 00:00:45,040 audited. 12 00:00:45,040 --> 00:00:50,360 So you can tweak for yourself and determine what you want to be audited and what not. 13 00:00:50,360 --> 00:00:53,119 In order to do so, you need to understand what to audit. 14 00:00:53,119 --> 00:00:58,320 Well, audit for simple activity using permissions is what you can do. 15 00:00:58,320 --> 00:01:03,980 So there is read and write and execute and attribute change and all of these can be monitored. 16 00:01:03,980 --> 00:01:08,239 You can also do more advanced auditing to have a look at system calls. 17 00:01:08,239 --> 00:01:13,080 Use the minus uppercase S option with AuditCTL to do so. 18 00:01:13,080 --> 00:01:16,720 Now when you audit system calls, it's a bit more complex because you must specify the 19 00:01:16,720 --> 00:01:19,379 target architecture. 20 00:01:19,379 --> 00:01:24,940 Now if you write your audit messages, it's always a good idea to use the option minus 21 00:01:24,940 --> 00:01:27,339 K followed by a key. 22 00:01:27,339 --> 00:01:29,580 And this key is an identifier. 23 00:01:29,580 --> 00:01:35,459 Because next in the audit log, you can use this key to figure out what has been logged. 24 00:01:35,459 --> 00:01:39,879 When you are auditing, you need to take care of the user IDs that are used. 25 00:01:39,879 --> 00:01:43,720 Because all the user IDs work a little bit differently. 26 00:01:43,720 --> 00:01:47,019 In auditing, you will find the AUID. 27 00:01:47,019 --> 00:01:48,660 That is the audit UID. 28 00:01:48,660 --> 00:01:52,980 And that is the UID that the user originally logged in with. 29 00:01:52,980 --> 00:01:58,900 So regardless of what you do using SU or SUDO, you will always see the underlying UID in 30 00:01:58,900 --> 00:01:59,900 the AUID. 31 00:01:59,900 --> 00:02:03,419 EUID is the effective user ID. 32 00:02:03,419 --> 00:02:07,300 And that's the user ID that was used to perform the operation. 33 00:02:07,300 --> 00:02:15,139 So if you are in an SU shell, your EUID will be the user that you SU'd into. 34 00:02:15,139 --> 00:02:18,220 OUID is the object user ID. 35 00:02:18,220 --> 00:02:21,940 And that is the user ID that is used by the target process. 36 00:02:21,940 --> 00:02:28,300 And now we have the UID, which is the real ID of the user that started the process. 37 00:02:28,300 --> 00:02:32,979 To add audit rules, audit CTL is the command to use. 38 00:02:32,979 --> 00:02:38,020 Use for instance audit CTL minus W, etcmotd. 39 00:02:38,020 --> 00:02:39,199 So that is a watch. 40 00:02:39,199 --> 00:02:42,279 We will watch the etcmotd file. 41 00:02:42,279 --> 00:02:44,339 Minus P, rwxa. 42 00:02:44,339 --> 00:02:49,419 So we are watching for permissions read, write, execute, and attribute change. 43 00:02:49,419 --> 00:02:52,380 So anything that happens to this cell will be audited. 44 00:02:52,380 --> 00:02:59,300 A minus k test audit is going to write the label test audit. 45 00:02:59,300 --> 00:03:03,860 Now if you want to monitor the output of audit CTL, you are going to watch the audit log. 46 00:03:03,860 --> 00:03:06,139 We'll talk about it shortly. 47 00:03:06,139 --> 00:03:09,220 Now anything you type with audit CTL is here and now only. 48 00:03:09,220 --> 00:03:10,720 It's not persistent. 49 00:03:10,720 --> 00:03:17,639 If you want to make it persistent, you need to write to etcauditrules.d audit.rules. 50 00:03:17,639 --> 00:03:18,880 It's pretty easy. 51 00:03:18,880 --> 00:03:23,639 It's the same command without audit CTL in front of it. 52 00:03:23,639 --> 00:03:29,479 And you can also make the current rules immutable by adding minus E2 to the end of the audit.rules 53 00:03:29,479 --> 00:03:30,479 cell. 54 00:03:30,479 --> 00:03:35,820 Auditing is a security feature, and by adding minus E2, you prevent that an intruder is 55 00:03:35,820 --> 00:03:40,399 going to disable all of your audit rules. 56 00:03:41,080 --> 00:03:46,039 To investigate the audited events, you can read the audit log directly. 57 00:03:46,039 --> 00:03:48,199 Some people think it's not very readable. 58 00:03:48,199 --> 00:03:52,119 I think you just need to practice a little bit to get used to it. 59 00:03:52,119 --> 00:03:56,600 But because some people think it's not very readable, there are specialized utilities 60 00:03:56,600 --> 00:04:00,960 like au-search, which helps you to search for specific events. 61 00:04:00,960 --> 00:04:07,479 Use for instance au-search minus k admin underscore access to show all events that have the admin 62 00:04:07,479 --> 00:04:09,479 underscore access label. 63 00:04:09,559 --> 00:04:14,000 Hey, you know, au-search is just a fancy way of doing a grep. 64 00:04:14,000 --> 00:04:20,079 If you do a grep admin underscore access in audit.log, you see the same result. 65 00:04:20,079 --> 00:04:23,760 But au-search is frequently used. 66 00:04:23,760 --> 00:04:27,839 So another example is au-search minus mavc. 67 00:04:27,839 --> 00:04:32,480 That will show you all messages that have been logged with the message avc, and that 68 00:04:32,480 --> 00:04:33,880 is SE Linux related. 69 00:04:33,880 --> 00:04:35,959 We'll talk about that later. 70 00:04:36,200 --> 00:04:43,239 Au-search minus mavc minus ts today will do the same, but only for messages that have 71 00:04:43,239 --> 00:04:46,320 the timestamp of today. 72 00:04:46,320 --> 00:04:54,079 And au-search minus mavc minus ts today minus chtpd will further fine tune and only show 73 00:04:54,079 --> 00:04:57,839 messages related to the httpd service. 74 00:04:57,839 --> 00:05:01,000 Let me show you a couple of useful examples. 75 00:05:01,000 --> 00:05:11,440 So to start with, audit ctl minus l is showing that no rules are available. 76 00:05:11,440 --> 00:05:26,000 Then I'm going to use audit ctl minus w etc pass wd minus p wa minus k pass wd changes. 77 00:05:26,000 --> 00:05:29,799 I like to put my keys in updates. 78 00:05:29,799 --> 00:05:34,640 For the line about old-style watch rules, the rule is still working, and this is the 79 00:05:34,640 --> 00:05:37,839 kind of information you need to know about for your exam. 80 00:05:37,839 --> 00:05:38,839 Good. 81 00:05:38,839 --> 00:05:43,040 I'm going to use user at Anna. 82 00:05:43,040 --> 00:05:44,040 Already exists. 83 00:05:44,040 --> 00:05:45,040 Oh, boy. 84 00:05:45,040 --> 00:05:47,320 User at Bia. 85 00:05:47,320 --> 00:05:59,359 And now I'm going to do a grep of pass wd underscore changes in var log audit, audit.log. 86 00:05:59,920 --> 00:06:01,399 And there we can see what has been logged. 87 00:06:01,399 --> 00:06:05,559 So we can see the actual line, a system call. 88 00:06:05,559 --> 00:06:10,279 On architecture, this system call number, we don't care about the system call number 89 00:06:10,279 --> 00:06:11,279 too much. 90 00:06:11,279 --> 00:06:16,279 What we care about is that PID 4125. 91 00:06:16,279 --> 00:06:17,779 That might be interesting. 92 00:06:17,779 --> 00:06:21,959 So PID 4125, AUID 1000. 93 00:06:21,959 --> 00:06:26,640 So the audit user ID, that's the original user, is user 1000. 94 00:06:26,640 --> 00:06:27,880 The UID is zero. 95 00:06:27,880 --> 00:06:34,239 So we can see it has happened from sudo minus I or something environment, which is confirmed 96 00:06:34,239 --> 00:06:36,660 by the EUID. 97 00:06:36,660 --> 00:06:39,320 And there we can see what has happened. 98 00:06:39,320 --> 00:06:44,480 User has been user at, and the key is password changes. 99 00:06:44,480 --> 00:06:47,000 So a user has been added. 100 00:06:47,000 --> 00:06:48,600 Now you might be wondering when. 101 00:06:48,600 --> 00:06:50,720 Well, that is a funny one. 102 00:06:50,720 --> 00:06:52,880 You can see the when right here. 103 00:06:52,880 --> 00:06:54,459 This is the time. 104 00:06:54,459 --> 00:07:00,019 Now the thing is that this time is not very readable, but if you use date, minus D, and 105 00:07:00,019 --> 00:07:06,660 then you use an at sign followed by this timestamp, which is an epoch, you get a nicely translated 106 00:07:06,660 --> 00:07:12,100 timestamp to find out when exactly the password change has happened. 107 00:07:12,100 --> 00:07:13,980 Now let's do another example. 108 00:07:13,980 --> 00:07:28,700 With CTL, minus A, always, comma, exit, minus S, ABJ, time X, minus S, set time of day. 109 00:07:28,700 --> 00:07:31,339 This minus S is referring to system calls. 110 00:07:31,339 --> 00:07:33,700 These are low-level system operations. 111 00:07:33,700 --> 00:07:41,420 And if they happen, I want to log something with the key time change. 112 00:07:41,420 --> 00:07:45,579 So any time a time change is going to happen, it will be logged. 113 00:07:45,579 --> 00:07:46,579 Now do we have it? 114 00:07:46,579 --> 00:07:54,980 Rep on time change on var log audit, audit dot log. 115 00:07:54,980 --> 00:07:55,980 And look at that. 116 00:07:55,980 --> 00:07:56,980 We can see something. 117 00:07:56,980 --> 00:07:57,980 Well, do we? 118 00:07:57,980 --> 00:07:58,980 No. 119 00:07:58,980 --> 00:07:59,980 The type is config change. 120 00:07:59,980 --> 00:08:02,940 Config change identifies the rule that has been added. 121 00:08:02,940 --> 00:08:05,779 We now need to wait until something is changing the time. 122 00:08:05,779 --> 00:08:11,820 Honestly, I don't want to change the time, because time synchronization is used here. 123 00:08:11,820 --> 00:08:20,940 But if you want to, time minus S, 13, colon, 20, and then we grab it again, and, oh, it's 124 00:08:20,940 --> 00:08:21,940 not yet there. 125 00:08:21,940 --> 00:08:23,820 Well, it will get there eventually. 126 00:08:23,820 --> 00:08:26,820 Let's have a look at another one, which is very interesting. 127 00:08:26,820 --> 00:08:31,019 Audit CTL, minus A, always, comma, exit. 128 00:08:31,019 --> 00:08:34,940 This minus A is identifying when you want to do the audit. 129 00:08:34,979 --> 00:08:40,580 And here, the always exit means that we always do the audit at the exit of the system call 130 00:08:40,580 --> 00:08:42,700 that we are monitoring. 131 00:08:42,700 --> 00:08:43,940 Now what do I want to do? 132 00:08:43,940 --> 00:08:48,820 I want to filter on there is slash home. 133 00:08:48,820 --> 00:08:52,739 So we are filtering activity in the slash home directory. 134 00:08:52,739 --> 00:08:55,340 Min F, UID is zero. 135 00:08:55,340 --> 00:08:58,460 So the effective user ID is zero. 136 00:08:58,460 --> 00:09:07,659 But min C, AUID, non equals object UID. 137 00:09:07,659 --> 00:09:11,340 The AUID is the user ID of the original user. 138 00:09:11,340 --> 00:09:16,979 The object user ID, that is the user ID of the object that is accessed. 139 00:09:16,979 --> 00:09:20,059 So that will be the user home directory. 140 00:09:20,059 --> 00:09:23,260 And then we are going to log spying. 141 00:09:23,260 --> 00:09:24,739 And why do we do this? 142 00:09:24,739 --> 00:09:29,900 Because this rule makes sure that if anybody from an SU shell is accessing a home directory 143 00:09:29,900 --> 00:09:33,539 that doesn't correspond to the home directory of their original user, 144 00:09:33,539 --> 00:09:35,539 well, then the message will be logged.