In this video,
you'll learn how to audit your Lennox host using logging and audit D.
Our plan is to explore authentication, auditing and logging on your Lennox host.
You'll use the audit D application to create a file system rule to track
security events.
You learn how to search logs with security information on your host.
When looking at potential security issues,
you can use an application called Audit D to track events on a host.
Audit D is an application that writes events from the Linux auditing system in
the kernel to a log. In our case, that log is audit dot log.
The audit application is made up of four different tools.
Audit D is the Damon that runs in the background audit.
CTL can make changes to the kernel audit system.
We will use this command when we're setting up our rule.
AU search allows you to search for security events in the audit log.
And au report creates a report based on the audit log entries.
Rules are created either from the command line or they can be kept in the audit.
D rules, D directory security logging.
So system D logs information into one convenience spot.
This part of System D is called Journal Before System D services wrote to many
different files using different log formats.
You could search logs and journal by using the journal CTL command.
We will do that a bit later.
Security events are captured in secure dot log information like logins
via console and ssh.
Pseudo and SU commands user and group creation are all written to this secured
out log file. Okay, let's get started.
Okay, so the first thing we're gonna do is set up a rule on audit D.
Audit D should already be installed on your Amazon Lenux host, but if it's not,
you can just do the pseudo yum install audit D.
And don't forget you have to, it's installed.
You'll have to make sure it is started using the system D CTL command.
I was thinking to keep it,
the theme with the rest of these videos is that we create a file system rule
that watches for any new files inside the user local engineering directory when
a new file is created or change is made to it and Audit D should created an
event for it.
So we're gonna need pseudo elevated privileges to do anything we want to do with
audit. Since the audit log is actually, um,
you need elevated permissions to look at it and to interact with any of
the uh, kernel audit system as well. Okay,
so I am gonna cut and paste this command here and then we can talk about it.
Okay,
so you could see here that we're calling the audit CTL command and the
lowercase W is for watching a filer directory.
And in this case we're gonna watch the user local engineering directory
recreated earlier on in the series. The dash P is for.
So there's the read, write and then access and execute here.
These are not like the standard permissions we learned about earlier when we
looked at, when we were talking about users and groups,
but these are kernel level system calls.
So here we're using the W and the A.
So we're basically looking for any type of writing to a file.
And then the A is for any type of modifications or may I modifying the
attributes of that file or directory in this case. K we're using here.
Is this an easy identifier that we can find in our events and logs and it allows
us to search for it when we use a Aus search later. Okay,
so let's go ahead and hit enter and there's no error come back,
which is good. If there was any problem with it,
the application would give us an error. So with that being said, let's go ahead.
We're gonna create a file in user local engineering called
malicious dot text.
And so by, remember by using the, the touch command, if the file does not exist,
it'll create it for us. Okay?
So it is now in aside the user local engineering directory,
these events should now be captured inside our off log.
So instead of searching this log by hand, which you could do,
we're gonna go ahead and use the AU search command. And there's,
there's multiple ways you could do this.
We could search by our engineering dash modify keyword here
or we could search by a file or directory. So let's do this first.
I'm gonna clear the screen and then we're gonna use au search.
And then I'm gonna use dash F for the file and we'll say engineering
directory malicious txt file. Okay.
Okay. So there is a lot of structured output here and this is so,
um, if you want to pipe this into your monitoring system,
in case you wanna get alerted on some type of events, which you should do,
you can parse this file. There's a specific format and obviously, um,
we're not gonna go into how to parse it here,
but there's a few things that I want you to pay attention to the most.
So here it tells us right here that there is a user local file.
You can see the I node of when it got created, the mode of the file.
You can see go down here, we could see another item here,
which is the directory, the eye note of the directory,
stuff along those lines. Then here, if you come here on this type,
this is the SIS call cuz you have different types here.
So this was the create type, um, this was actually creating the file,
right here's the path, this is the type path,
this is type current working directory. And this is where I made the call from,
which was home EC two user. And here's the system call,
the kernel level system call that was actually used to create this file.
And as you could see here, it says success. Yes.
So obviously if we were monitoring this, looking for this,
we would be looking for some sort of malicious type of activity where it was
successful. I mean,
maybe you want something that was not successful too to give you a heads up or a
warning that somebody's trying stuff. But I feel like that might be, um,
a lot of information you'd be getting.
You could see the command that was used here,
which was touch and what we executed the executable,
which was under user bin touch. And here's our key that we made.
So if we wanted to search by the key, we absolutely could do that.
And I will show you how to do that really quick. So if we get rid of,
you can do dash k and then we say engineering
modify.
So you can see here that we have two outputs now and the
first output is that there was a config change that we added a rule,
we added the key. So we, you can safely ignore that,
that was just us running our uh, command.
But you can see is here we have the exact same output and rule that we did
before. So those are two ways of you being able to
add a rule and be able to search for it.
Obviously searching for it is not good enough.
You definitely wanna pipe this into your monitoring system so you can get
alerted if somebody's doing something malicious, uh, any bad actor.
So there's other things that you can, um, do as well.
Not just file systems for audit.
You can say if this pseudo command gets run or say you have a very special
sensitive command that only a few people get to be able to run it and you want
to be able to watch that command, you can set up audit,
you can set a rule for audit D to manage that as well. Um,
you can manage certain system calls like um,
create user or something along those lines and you wanna watch those,
that type of activity you have all that thing I just showed you the simple file
system one just to get you get your feet wet in the, uh,
so you can start a foundation learn.
Obviously there's a lot more you can do with audit d
I'm gonna clear the screen here.
The other command that you can use is AU report and
what you can do, this will basically run a summary of everything in that log.
So the output's gonna be a lot because I'm, I'm not limiting it to anything,
but I'll go ahead and run it.
You do pseudo AE report and here it's gonna run from February to
March. So there's a lot of information.
You can tell how many failed login attempts and we'll actually look at those in
a second. How many logins, um,
different host names that are in that log from people. How many try, uh,
fail failed CIS calls.
That's probably something I did by not putting pseudo in front of it that needed
to be done. Um, but anyway, you get the idea and this would be like a good,
um,
a good plan to email yourself like this once a week or whatever the frequency
you need to get an idea of what's going on.
And then maybe you could map trends to this.
Okay, let's pivot away from audit D right now and let's learn how to do general
authentication and security searching using the journal CTL command.
So Journal CTL is a a very large application.
There are a lot of flags,
but so we're only gonna focus on a couple ones here and we're gonna base it more
to looking at s SSH authentication and like system D, login D.
So there are three main flags that we're gonna use when searching for these
logs. We're gonna use the dash U, which tells it what unit to search.
Our case would be S S H D. Um,
there's an R which shows reverse showing the newest logs first and then we're
gonna do a dash dash since, cuz we, we don't wanna search for all time.
We're only gonna search starting from yesterday.
So I'm gonna go ahead and paste the command in and you'll,
it'll make a little bit more sense. Okay,
so here we have the journal CTL command. Obviously, um,
the reason why we're using pseudo is because some logs are not owned by the
e C two user and you would need pseudo to be able to look at 'em.
Journal CTL will kind of quietly just not read those logs if it doesn't have
permission and not warn you. So it's a pretty good habit when you're searching,
uh, a bunch of different logs, especially secure logs which are, um,
more protected than you should preface it with pseudo. Okay,
so here we're using the dash U to say what unit,
what unit are we going to get logs from? And in this case the s SSH server.
So we also have the system D, login D
and the system D login D is responsible for managing user logins for the system
D system. It keeps track of user sessions amongst other things.
So we wanna look in both of those.
And then we are using the dash R here and that is to show all the newest logs
first. And then here we're gonna do dash,
dash since we're gonna say since yesterday. Okay,
so I'm gonna go ahead and return. There's gonna be a lot of output.
It's gonna drop us into a page where you hit space bar to keep paging,
but let's go ahead and see what that looks like. Okay,
so as you can see one thing, there's a specific format.
You get the date, the host,
these are the different columns. And then the, the service unit,
which is S S H D here. And then the log entry.
So couple things here.
Journal does not try to fit it all onto the screen.
Instead what it does is it lets you scroll to the right to see more. Um,
so if you hit the right arrow,
you could see that we now get more of the, um,
the remainder of what is not in the logs that you can't see on the,
at the screen. Um, I,
I'm gonna leave it here cause I think it's just a little bit better view,
especially with the blown up for the recording. Um,
but let's just go over a couple things that you're seeing here.
So you're seeing these connection close by, um, these, uh, IP addresses.
You see these pre-ops invalid user support.
So you can see here that this is basically bad actors trying to break
into, uh, my e c two instance. Um,
somebody was doing a port scan and found this instance was running s ssh and now
they are just looking and trying to brute force their way in with a user,
all the different users and any kind of passwords they're finding in rainbow
tables or or password hash dumps. And so if we just go down,
you could see that all these invalid user ll um,
during pre-op. So these are all unsuccessful attempts,
but as you could see,
this box is being hammered constantly with people trying to get in. Um,
if you look at these timestamps, I mean it's literally every,
every like every few minutes, um,
there's multiple attempts and this is because somebody's scripting this.
They're uh, they're automating this. Um, and so they're trying to get in.
And the next video, we're actually gonna make some tweaks here to try to, uh,
help fix this. So you see here we have reverse mapping where this,
the number that they're trying to connect from Dou, which is Russia,
does not actually resolve to the IP address they're coming from.
They're trying to spoof it. You have,
Ali has a user here and so they're just going through all the different things.
So nothing to really worry about there except that we're to know that you're
always under attack and having understanding that someone's watching these logs
and looking for these things knows because what you don't wanna see is a
successful session being created for one of these, uh,
users that is not you or somebody that you want in the system.
I'll scroll down a little bit. You can see it just goes on and on and on.
There is, there'll be, uh, system D log event, the system D login, uh,
login D events. What they will show, um, when you get to them,
they'll just show that a new session was created for this user.
And so if you saw new session, so like we can just do new.
So as you can see, we have a new session for this user. This is from a,
from a login for me, what you would want want to see is that,
that happen on a user that you did not expect,
uh, to be logging into your system. Okay,
I'm gonna hit Q to get out of this journal.
I'm gonna clear the screen. Okay,
so another handy thing that you could do in with journal CTLs,
if you wanna look for errors, obviously, you know,
different services logged is this standard out standard error, stand it in. Um,
and so this, any law,
any errors that are being logged as a error log journal CTL can find as well.
So we'll get rid of the dash since,
and then what we're gonna do is we're gonna do a dash P for priority and there's
different, the differing logging priorities here.
The number three means errors and that's all we'll just focus on right here.
And as you can see here we go maximum authentication attempts.
So these people trying to log in are reaching the default SS h
max authentication attempts, which I believe is six by default.
And so these people are trying six different times before, uh,
with the same user before they are telling you've re or you've reached the
maximum attempts. No more tries with that. So as you can see,
like there is an obscene amount of 'em here,
you see people trying to log in its route and like I said in the next video when
we talk about hardening ssh, we'll look at that as well. Okay,
I'm gonna hit Q to get out of this as well.
I think you get the idea and then clear the screen. Okay,
so we've covered audit D here. We've made a simple file system rule,
we know where to look for logs. Um,
we know how to look at those event logs in the audit log.
We also learned some basics here on, uh, journal ctl. So let's go over for, uh,
go back over and let's do a full recap on what we did in this video.
Okay, so let's talk about what we did in this video.
So you learn about auditing and authentication logging on your Lennox host.
You used the audit CTL command and created a rule to watch for right access and
change events. For the engineering directory,
you used the AU search and journal CTL commands to find file system events,
login attempts, and s SSH sessions. In the next video,
you'll learn how to harden your SS h server. See you soon.