 Hello everyone, welcome to open source submit and embedded Linux conference. Today I'm going to talk about monitoring Linux system using the carnals audit subsystem myself is one that I'm sorry. And the goal of this presentation is to cover the following topics on audit subsystem understand what is this audit subsystem why it is needed. And how is it helpful in from a security policy, what are the different components of this audit subsystem framework and how does it work and how it generates the events. And then how we can make sense of all the data that has been generated as such. So, before starting the session, let me introduce myself I'm one of us always been working with Linux system for more than 18 years. I am a Linux kind of professional and Linux trainer at Lex Foundation and co founder of plasma systems. I'm basically involved in product development and training some Linux Android system do is drivers and I've been working on any subsystems including various embedded device driver board bring ups network or device drivers DME and PCI management and some of the current security features. So let's get started with the topic on audit subsystem. So the audience system is used to raise the level of security in the Linux system. Basically, it does not offer any additional security policy, it is used to retrieve information on the system events that is happening. It provides a little information on system violations, which can be used to implement additional targeted security measures. So we're going to take a deeper look at this audit subsystem and this presentation. So the audit subsystem was first introduced in the Linux kernel to that six version as initial purpose was to track critical system events related to security to summarize these are some of the events that can be audited or tracked. Like while the process is created exerted haunted are during the couple completion of the processes application process, like reading and writing or changing the files at permissions and rights, and keeping track of for network connection initiating the network connections on the changes happening to the configuration. Even the field authorization items can be tracked down along with any changes happening to the user and group information. Along with that the execution of the various system calls can also be tracked with this audit subsystem. Linux audit subsystem helps us helps the system to become more secure by providing you with a means to analyze what is happening on your system in a greater detail by tracking actions performed on a system. The audit records that are being generated as part of audit auditing can be examined to determine whether any violations of any security policy has been committed. And in such case, by whom it has been committed like tracking the information of the process and the user. Also it helps you to associate the users with the process and review the particular audit events, and it provides the mechanism by which you can apply filters for for looking at the interest in events. And it provides a mechanism whereby the logs generated can be stored and there it is that the availability of the reports that have been generated. So let's look at the components of the audit subsystem. The audit subsystem is made about the kernel space audit framework and the user space audit framework. So the kernel space framework generates the events based on the rules that are being configured. And then those events are being transferred to the user space components. So you're in this diagram if you look at there are. Obviously that is the kernel kernel part of the audit subsystem and then there are a couple of tools, which are part of the user space audit framework like this. The main one of the main component is the audit general process which communicates with the current part of the audit subsystem and along with that there are set of tools that are used to collect and analyze the event records. So let's look at the kernel component of the audit subsystem. Linux audit events are cannot occur without the system called from the kernel. So basically, the tracking requires that the system calls to be intercepted. And that's what the current audit subsystem does. It intercepts the system calls that are coming from the application and then track down the information while executing the system call. So the kernel contains the database with rules to specify the events that must be recorded, like after receiving a call from an application in the user space if a certain event happens and the kernel decides as per the database rules that it must be audited the audit subsystem passes it through one of the following filters. Like there are the different filters that have been defined by the kernel audit subsystem and based on the order of execution like before, during and after the system call processing the filters are avoid and according to the filters are known as user task and exit. So you're in this, if you go back to the diagram, you say that these are the different filters that are a bit applied during the system call execution user task exit. And along with that there is another filter called as an exclude filter, like any system that falls under this exclude category they'll not be filtered. If these filter determine that the system call needs to be recorded, then the kernel component of the audit subsystem sends the information to the user space component of the audit system, particularly the audit demo process. And this information is sent between the kernel from the kernel space component to the user space with the help of this net link socket. And then audit demo process that is auditing collects the system call records, and then goes and writes to the log files. This is another diagram that helps to understand that these are the different filters that are being applied when the system call is intercepted like here the application whenever it makes any system call. The kernel component of the audit subsystem goes to check what are the different filters that are being available been applied for that particular rule. And based on that it takes the, it creates, it creates the event record as such. So user exit task and exclude these are the different filters. And eventually when the logs are being created, the event logs are created they are eventually been forwarded to the audit demo. The audit demo is used that can store the event messages in the log file for further inspections. The communication between the user line and the kernel line as we have seen that happens with help of this net link socket. And this is auditing process that has been listening on to this net link socket. The kernel and the user line parts of the audit mechanism are mutually dependent on each other. And the events that are being generated by the kernel component are being forwarded through this net link socket to the user component that is the audit demo process. So the kernel layout lets us let you effectively track any aspect of the operating system and in the event if the system is being compromised identify this suspicious events and determine the possible cause of this attack or the compromise that has happened. So now let's look at the user space component of the audit subsystem. Works by listening to the event reported by the kernel and logging down to the log file. Like the audit frame work is composed as we talked about like about one of the component of the audit the demo process, which is responsible for writing the audit messages that are being generated through the kernel audit kernel interface, and are triggered by the applications and they are eventually and the system active by triggered by the application and the system activity and eventually they are going to return on to the disk. The way audit demo is started is controlled by the system deep process. The audit system functions when started, they are being controlled by the configuration for it. That is basically the audit deep.conf file. So let's look at how this audit subsystem is set up, set up done on the system like the audit before we start to look at generating audit logs and processing them. So in case of an event you may systems, the set of the packages that has to be installed to get this audit subsystem working as these other packages that we need that is the audit D and the other set of for dispatch of plugins package packages are needed to be installed. In case of red hat or said OS this audit packages are are installed by as a standard. And as we are aware of that red hat is the main creator and the upstream maintainer of the audit subsystem. Now, once the packages are been installed the audit service can be started and unable on the system but the system control command as such. So we have to start it and unable the service and then we can use the same system control status. Come on to check the, the service that has been started or not. So, now let's look at the audit subsystem tools that also it provides a couple of functional tools to work with the audit subsystem. And as we have seen that the one of the main component is the audit determine itself. That is the process that handles all configuration and communication with the current. Now with the audit determine there is another set of there are other set of tools and one of the main tool that has been used basically for managing the audit determine is the audit control tool that is audit CTL. So this audit CTL does the work that it gives the information or the audit subsystems current status, and it has been also used to add and delete the audit rules like the rules that governs how the system has to be monitored. Then we are other set of tools like you trace is a tool utility for auditing events caused by the processes and as it behaves something similar to the s-rays utility. And another tool that is a search that is a tool utility for searching the events and the log files. The tool report is can be used for generating reports on the audit system. So now let's look at how this audit determine configuration can be done. And one of the main basic one of the main file that does this configuration for the audit determine is this audit data of compile it has been located basically been located into the PC audit directory. So if you go and look at the, let's go and look at the map page of this audit. It helps us to give the information of all the different parameters that can be specified in this file that each line contains one configuration keyword and it has the information how the audit table should be configured for your system. So basically the values depends on the size of your deploy deployment and some of the key components, the parameters that has to be defined in this audit of compile is the number of logs that has to be created what should be the maximum log file and the space related to space configuration for storing the log log files of the events that are being generated. Like if a disk space is a limited than in that case you would might want to reduce the number of log files to keep if they are to be rotated and also like you need to have information like you should get an early warning if the disk is running out of space. All those things can be configured and this audit.com file as such. So, if you look up contents of this that helps us to see that these are the different parameters that will define on the behavior of the audit dev process. And has to be taken by the space coming getting out of this space getting filled up and what to be done about the logs as such. And now let's look at how we can configure the different audit rules. This is the tool that we're going to use to control the behavior and use to add and delete the rules. Also, this is used to get the status of the audit date. What exactly it does is it controls the amount of auditing to perform on the system, like using audit rule it controls like which components of your system are subjected to audit and to what extent they are audited. Audit rules can be passed to the audit devon on using this audit control command line, or they can be composed, composed together into a rules file. And then we can ask the audit devon to process this rule files. So by default the audit devon is configured to check the rules into the from this file called as audit.tools. So this is a file that defines all the rules. So basically when the audit devon starts, it goes and checks if there are any rules in this file. If they are present, the audit devon rules loads those files. And once they are loaded, the kernel is aware that these are the rules that has to be applied by the auditing has been enabled. So let's look at how the rules can be created with this audit CTL command. We can add and configure the rules with using this command tool and the possible options we see is like if you want to print the existing list of the rules that we can use minus L. And then minus A is for adding the new rule and minus D is for existing, deleting the existing rules. Like suppose if you want to clear out all the existing rules, then just using minus capital D suffice the action needed. Now you're in this case. Let's try to say there are any rules currently currently I don't have any rules. That's why it says that the rules, there are no rules as such. Okay. So what I'm just for the sake of taking a look what we will do is we'll add some set of rules. So this is the way if the rules are being added. And if you go back and look again give the minus L option you see these are the rules that get added. And they are the columns or the subsystem will work on this source that whenever the application goes and behaves as per this rules that are being to attract the events will be generated. So to create a new rule we have to run the command with the following syntax like it takes a couple of a couple of parameters to add the rule that minus A is the option that we have to do when you want to add the rule after minus A we have to enter the list. So we have to manage to add the rules to like we have to add the filters like the one that we saw on scene previously like the task exit user exclude to then we enter the action to be both when the event are apples. And there are the two options that is always this enter the event in the law or never that don't enter the event. And that we specify the minus S option, where we have we can enter the name of the system called the event needs to be intercepted for like, for example, like the open or open close or full system calling case over process creation. So with minus S options we can specify more than one system called by specifying, specifying separately with minus S option. But the basic options we can also set additional filters with the minus option. For example, like if you want to audit references to files from the slash it is a directory, the rule could be something like this like audit CTL minus exit, and then you specify the option additional filter by using minus F, and then give the directory name. So in this case what we'll do it first remove the directory and then go step by step adding the rules for the demonstration purpose. So here you see that the rule has been added for the for to be tried for this directory, it is the directory. And other than that, we can also add the extra extra filters to the rules like you're in this case that we are adding the parameter with the permissions like with the minus F filter upon equals to we, which means that all attribute changes and rights happening in EDC directory needs to be tracked down. So whenever there is some entries being created or deleted, or some attributes are being changed for the files and EDC directory they will be tracked down and the event records will be created by the component of the audit system. And it will be sent down to the audit to be written in the log file. Okay, and we can also add the key name with the minus K option. There is nothing but the free form text string text string that you want to be inserted in the event to help identify the events. Now, how this audit rules can set up being done and on what kind of data can be tried for this audit rules. So, use audit rules to determine that which aspects of the system should be analyzed. You can see this includes like important databases and security, relevant configuration points. And if a broad analysis system is required every system calls needs to be analyzed, the audit rules needs to be added as per the control access profile combined environment. And the audit rules can be passed. The audit rules are then passed to audit them and using the audit CTL command line tool, as we've seen just now and another way is like composing the rules in the audit rules file, which is then further processed by the audit them when it started or like if you're making changes to this audit rules file, then you have to tell the audit them to reload this configure this audit rules fine by specifying minus our option to the audit control cannot. Okay, now what we will do is we go through set of the audit rules that are applied for the various system objects. So let's look at the root set, which can be basically divided into basic configurations. And then what is on audit or files and configuration files and monitoring operation on system file system objects monitoring security databases, monitoring the system calls and also looking at the different filtering system call arguments. So audit rules is the collection of audit control commands and every line in the file expands to the full audit control command. So, taking the look at the basic audit rules as this is something that this is what you will see at most of the system that has a audit system and oven. So the first parameter basically it is like minus D, which tells that before, before starting the audit system and just delete any pre existing rules before starting to define the rules how clean slate and then go on the rules then there is another option which is called minus D minus B, which is used to set the number of buffers to take the audit messages. And then we can also set the failure flag, various various states are there that set the failure flag to use when the corner needs to handle any critical errors as such like. The failure flag is zero silent than the current will silently ignore this critical errors. And if it is set to mark one then in that case it would print the failure messages to to finding the system on the system whenever there is any critical errors. And similarly, to know the current status of the audit them and we can use this minus S option. That gives you the information that the audit has been unable what is the flag status failure status, the BID related to the audit process. And then the image logging mechanism. What is the limit of the buffers that this can be used for logging the events. And this is the basic rules that are being specified in this rules, audit rules, audit dot rules file so minus D is delete all the rules and be sets the buffer number buffer, even buffers to be set aside for holding the audit events. Okay. So this is the file that the odd determine reads whenever the audit devils get started. So let's look at how we can add watches to the log and configuration files like adding watches on the configuration files are the log files themselves ensures that you are. You can track any attempt to tamper with the configuration files out and detect any attempts. Attempted access to the log file so to add the watches to the various file log file that we can we can use minus W option to the audit CGL cannot and then specify the path that has to be tracked down means it can either be a directory or file. So along with that we can specify the permissions permissions like you're in this case by misspecified by minus B option that is to track down the accesses that happening that is right access or attribute change access change access happening to the audit dot com for file as. Okay. So, let's see how we can add these rules. So you're in this case I will note it down on this text file, how we can add the rules, we using the audit control so you're in this case we're adding the rule for the various directories. This is the rules that can add it and whenever application any application makes access makes access or changes the any of the files that are being audited, then the eventual the corresponding event record will be created by the current part of the subsystem and it will be. It will be tracked tracked down and sent to the audit demo process. So you're in this case this is the log file that has been used by the audit demo process. And here if you look at these are the different audit events that are being generated by the system. So let's look at how the monitoring can be done for the system objects using the system calls like adding watches on system system objects to track your applications. How your application are using the system calls that are that are related to file manipulation or file content manipulation manipulation modification and whether that access that is happening is appropriate or not. Those kinds of accesses can be tracked down with the help of this system calls so you're in this example we see that the audit through that we can add by specifying the system calls here in this case. So this is the create system call open system called from gate system call and any system called that are going to modify the file content. So you're in this case any access that is going to happen on the system that will be tracked down whenever a particular system call is made inside the corner. So you're going to create the event record and then pass down the event record to the audit determine which goes and write into the log file audit dot log file. Similarly, you can enable the audit contacts for system calls related to related to changing the file ownership and permissions by tracking the system calls that those are like change mode, and the change owner and the corresponding equivalent system calls for doing the same operation changing ownership and the permissions. Similarly, you can enable the audit contacts for any directory operations such as creating the directory or removing the directory by adding the rules more that corresponds that makes the corresponding system call for creating and deleting the directories. And other than that, we can also enable the audit contacts for any linking operation by including the system calls such as unlinked, meaning blank or the symbolic links as such. Similarly to the system calls what we can do is we can monitor the security of the configuration files like tracking changes to the system configuration like the current services, such as timing recording that helps you spot any attempts of others to manipulate the functionality of your system. So according you can add the watches on the cron jobs configuration files like those that resides in this ADC directory cron dot daily or cron dot weekly. So like cron type file, and then track down for accesses that are being done like if someone is changing the cron job files or changing the attributes by specifying this permission like parameter less minus pain. Similarly, the changes that are done to the bank configuration should also be modern monitor in the secure environment, because changes in the authentication stat should not be made by anyone other than the administrator. And then, and that it should belong if some application is trying to modify any bank configuration. So in this case, we can add the watches for this configuration directory altogether with this minus minus W option as such. So you're in this case, let's do and go ahead and add some some of the things that we have just seen a check to add the watches on the system calls for files and directories we have this commands. As such, that adds the system calls for the file manipulation and the directory creation and the removal as such. And you're right now I'm just adding the rules and then we'll go and see if someone tries to temper along with this files that are being audited that the events are being gets created in the log files. So you will add the rules for watching for any watches on the front configuration of the system. So you will also add the and directory configuration directly. I'm saying that the monitoring can be done has to be done for the configuration for the logging as well as for the security configuration files like tracking and your right access to use a group or password or logging databases. That is that help that is helpful to identify any atoms that has been done to manipulate the systems user database. So accordingly we can add the watches to the to these databases and the files that correspond to database this login databases like the file that it is a group. It is a password or a shadow file other login definition files and they currently we can. We can add the rules with the added audit CTL command. Similarly, we can add the watches to configuration pilot is the network configuration file or SSH configuration. And along with that, one of the main one of the current functionality is about the time tracking if someone can hike around the system by changing the time timing parameters are timing altogether. So, we can add the watches on time tracking system calls as such what this thing with the commands. Now you're in this example you see that the along with other parameters minus key option has been specified to add the key to that rule as such. Now, once additional information can also be passed to this audit rules, like to try the application behavior to a higher degree, applying features the system calls helps to focus the audit on an area of primary interest to you, like, let's look at the access system form which checks whether a process could be allowed to read, write or test for the existing file existence of file or file system object than this additional parameter filter that filtering argument can be specified with this minus effort of life, which we can use to build the rules matching specific specific access calls in the format like minus F and then specify the argument. Like you're in this case a one is equal to access mode night home. There are the different. These are the year we are trying to specify add additional filter on the system calls input parameters input parameters so the audit audit the access system call for reading permission. And you're in this case, we permission that is the mode that has been specified as the second argument of the system call so you specify the a one represents the argument that is the second argument that is the more than the specified so you're like audit this access system call. And if the mode is equal to our party that is a read more recognition of the file. So, only then the access system call is being specified with the read more. In that case, the access the audit events will be created. Okay, so this is the so far we have looked at how the audit rules are to be added for the various activities as such and the various system object configurations and the law configuration security databases login databases as such. And then we can add additional filters to the filtering arguments. So basically how does that work. Like whenever a system call is being made, like system call is made the system call gets executed. So when it is executed in the kernel kernel, then it goes through this standard procedure of execution like here we can craze down if there is some unauthorized access item is happening to the fight like someone tries to open the slash atc shadow and which whereby it issues the open system call to the to the current open the file, then in the process the current on this component, which is part of this audit system detects that someone is trying to open this point. And if there is a rule that has been added for this it is the shadow, it will go and create the event record. Now eventually when the file permission and checks are being done as part of the open system call, like the SLNX and file permission checks will be performed and it checks whether the user particular user is allowed to open the file in the given permissions. And if the access is allowed, then the audit subsystem will log the event with the appropriate access that has been done and whatever the execution of the open system call all that information along with the user. And the other details, it will be it will create the event log and then it will send that event log to the audit demo where why the audit demo will go and log that even into this audit log file. Similarly, if the permission checks has denied the access that is denied to open the file, due to the permission checks. In that case, even will be created with appropriate information that it the user is not allowed it's not not given the permission it has access denied access has been denied equivalent audit event will be created and it will be logged into the audit log file. So eventually, by inspecting this log, you as a security person will be able to identify what kind of at times has been happened on this slash it is a shadow file on the system activity. So you're in this case like before going into the audit event like let's see that these are the different to let's go back and experiment with this different rules that we have already added as such. So you're in this case we have added the rules for the different audit configuration points itself and then there is we have added the rules for the BTC host file and it also we have added the rules to track down the system codes together and some rules for this login databases and then you can see host is already added. So you're in this case we have added the rules. Okay, so, as we have seen these are the this, this is the file that stores the law that are being generated. So as a man, the events are created this fall been incorporated into events. So you're in this case, what I will do is, here this is the one user that has been logged in on the system and here is another user I have so whatever you will go and open another session with the user. The user should be able to see that the event of logging the new user is also getting audited and it has been populated in the audit.log. So you see that these are the different events that get created when the user has logged in. Similarly, like here in this case we have added the different different rules so you're in case we have what we have done is we have added the log to the spam D file where the login database stores the information of the login so you're in this case. So if you if you look at these are the different events that are being getting created as such. What I will do is like from the on this application that I do from another user. So you're in this case you are trying to touch the file, the users does not have the formation and if you look on the record on the dot log while there are these are the events that got created as part of this activity. So if you look at this particular event, even here in this case, it is telling more the information about the, whether that system call that is the has been done whether it is successful or not as such. If you go back and copy these things so that they are able to analyze what does that means as such. So here in this case this is one such event that is being created where we are trying to execute this touch command that utility on this ETC password file. So here to help you understand this I have in the presentation another event record to tell the different fields that are part of this part, the different fields of this event record so basically the event record gives us a lot of information about what has been audited what has been tracked down. Like here in this case if you look at this event record, when you're in this case there are the information stored in the value type and the value there as such like here in this case if you see the first we see is the type type equal to syscall that indicates that the records are made after the system call. And then there are other fields like you're in this case message will contains the event time and you next time some format and along with it. It contains the unique identifier of the event of the event so this number 2427 24287 indicates the event identifier. Then we have another parameter architecture that tells the architecture tells the architecture of the system you're in this case this value represents the x86 64. And then there is another parameter that tells the syscall equal to two that indicates that it's open system call. And then a success equal to no in indicating if the system call was successfully processed or not so you're equal to no means that the system called it are completed successfully. There is another field that tells exit means the return value of the system call and the record event record also holds the information about the first four arguments of the system call that a zero to a three tells the what are the parameters that have been passed for this system call you're in this case it's the open system call. Other than that there are bad information about the process user and group like the process ID process ID than the user group user ID group ID gets effective user ID and group ID. So all that information is is been recorded as part of the event record and also it has other information like the TTY field that represents that refers to the terminal on which the application is initiated. Then they come in and then conflict stores the information or the application that appeared in the task list exit field tells the part of the program that was been involved as a subject is the field that refers to the security that's to be the process has been subjected and like if the key has been defined for the rules that is governing this event record that that information has also been seen in the record as such. So here if you go back to our event that we have stored here in this case the audit type is equal to system that we see this information gives the timestamp of the event. Similarly, then again the architecture gives the x8664 again the system call is open. Now you're in this system call did not suffice the suffice equal to no, then exit stores the return value that is minus two and this is zero to a three stores the information that represents the first four arguments of the system call. Then we see the different information for process related process ID per process ID and user and provided information. This is the TTY you saying that is the terminal on major process was executed. Then you see that that touches the command executed the binary corresponding to that the path is there and now we don't have the key. That's why it is shown as a now. This is all the information that comes as part of the event record that are that is that has been audited as such even. It contains the additional information such as like if there is an access to file file system entries file system objects that the information related to I know is and the device fields about the device and more fields are like the file access is happening. All that information is part of the event record. So now these there are like as per the number of the rules that are being added the events get generated and are based on the system load and the activity there will be like lots of givens that are generated. So how do you make sense of all this data on this event that are being generated. So what we do is the system on a system provides a set of tools to work along with this event logs that are being generated. So as we have seen that the logs generated they are saved in this very long audit directory in machine readable format. Now, they can be converted into a human readable format by making use of these tools that are part of the audit log. So, there are configuring and analyzing the audit logs can be done with using the audit report that is a you report tool like assembly scanning and analyzing the audit logs can be done scanning and searching the audit logs can be done with a you search tool, and also analyzing the processes can be done with the aim crest tool. So let's look at how each of these can be used. So to avoid having to dig through the raw audit logs to get an impression of what your system is currently doing. You can run the custom audit reports at a certain interval intervals like the audit report without arguments what it does is it gives you the general system status. And it will be printed on the console, like the number of system users general number of system calls that are being made them and open terminals and all this information like you without any parameter that gives the information they put on the terminals what are the different information and the changes that are happening to accounts groups and rules as such. So, and even if you want the information more on the system call then you can give the option minus s. And if you are want to get the information authentication that is happening to view information on the accounts to it will attempt that is done to enter the system that can be reported by using the minus in your option. So let's see like what the UK is here. So you're in this case we've seen the number of users that has been logged in. So we have the visa the user and the audit user that that was been logged along with the super user as such all this information they are being logged through the SED in front of the system. So this helps us to keep trying that what are logins are we have an entire user entering into the system. Similarly the scanning and searching of the events can be done with the help of this a user search tool. The a report tool helps you create the overall summaries of what is happening on the system. But if you're interested in the details of a particular event user is the tool to use you search allows you to search the audit logs using the special case and search phrases that relate to most of the slides that appear in the event messages. Like you can search the event logs by using the login ID or use ID, group ID or the process ID as such. And that is which will give you the information as for the option that you have specified. Again, if you're searching the logs, even logs by filing what are the access happening to vertical file in the names that can be specified with the filing option. So if you're in this case, if you want to search the event log related to audit user user ID that you can collect the logs like you can collect the logs as such and then go and look into the details of each of these logs corresponding to the audit user. So if you're in this case the EU ID being specified in 1003 then what are the different commands that has been executed by the audit user. What are the activities that has been happened for this audit user that can be tracked by specifying the options to do a use search. So we have the option of minus F for the filing, let's suppose, let's try it for password. So you're in this case this gives the other records referring to the ADC password file which all users and what our process has been accessing this ADC password file. So you can get all the records related to ADC password file with this minus F option. So there is another tool called as AU Trace tool for analyzing the processes. So in addition to monitoring your system using the rules you set up you can also perform dedicated audits of individual processes using the ADC AU Trace command. This works similar to the Astrace command but it gathers slightly different information like the output which is written into the audit.log file and it does not look any different from the standard audit records as such. But it provides the detailed information of the execution of that process and while doing it applies its own set of rules. Like that's why by performing an audit trace on a process we have to make sure that the existing rules should be posed from the queue to avoid that they are not clashing with the ones that are audit trace as itself. The example like suppose you want to if you run the audit trace on the date command then this is something you should be able to see. So here it has a trace the audit trace the date command and you can get the records, get the information about this command execution by as it gives the information of what was the PID that was executing when you launched this command. And this will generate the laws when this date command was being audited. Here in this case these are the different events that got created as part of this execution of the date system. This is like if you look at if you print false system call itself then it will help you to see like what all system calls was executed as part of this from the system when the date command was executed. So here you see that these are the system calls and then it gives the information of the execution of the system call that has happened. So you have to pay attention to the last line that it shows the command that can be used to even get the detailed information that's what we have seen currently. So this until now what we have done is we have looked at the various ways in which the system can be audited the different kind of foods can be applied to the configuration files, log files, directories, and also adding the different system calls that is can be audited as such. So there is another feature as part of this audit subsystem that that allows the external application to access and use the audit demo, and then real time, that is this feature is provided by the system called audit dispatcher, which allows for example, like the intrusion detection system to use the audit key to receive the enhanced detection information like audit dispatcher that is audit dispatch is the demo which controls this audit dispatcher. It is normally started by the oddity and it takes this audit events that are being generated and it distributes them to the programs which want to analyze them in a runtime. So basically this audit dispatcher, it runs as a child process of the audit demo process, and then it fetches the audit events from the oddity and then it can do, it can, it can further be distributed to other programs for analyzing them that is run on the runtime, in the runtime. And the configuration of this audit dispatcher is being stored into this file called as audit, this dot, and this d.conf file. So this comes to the end of our session on audit learning audit subsystem and how it can be used to audit the system and monitor the different activities on the system. And to summarize this, the presentation covered what we look at at the basic at the principle behind the audit system, the fundamental use of the audit, when it's on its system, and we look at how to write the rules, read the laws and use the auxiliary utilities and how to make sense of this events that are needed to analyze the threats and attempt on the system. So audit subsystem allows you to create and log these events and look at the logs to see, like, what are the successful attempts has been done, or who has modified those configuration to analyze or the important databases. And based on that, the system, whether the system security has been under threat, or has been comprised can be analyzed and eventually the security measures can be taken based on looking at this analysis of the logs. So this comes to the end of the session on audit, Linux audit subsystem. Thank you for listening this session.