We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Scale Your Auditing Events

00:00

Formale Metadaten

Titel
Scale Your Auditing Events
Serientitel
Anzahl der Teile
561
Autor
Lizenz
CC-Namensnennung 2.0 Belgien:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
The Linux Audit daemon is responsible for writing audit records to the disk, which you can then access with ausearch and aureport. However, it turned out that parsing and centralizing these records is not as easy as you would hope. Elastic's new Auditbeat fixes this by keeping the original configuration, but ships them to a centralized location where you can easily visualize all events. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. This talk shows you what can you do to discover changes, events, and potential security breaches as soon as possible on interactive dashboards. Additionally, we are combining Auditd events with logs, which are security relevant.
10
58
80
111
137
Vorschaubild
15:21
159
Vorschaubild
18:51
168
Vorschaubild
26:18
213
221
Vorschaubild
15:22
234
Vorschaubild
49:51
248
Vorschaubild
23:06
256
268
283
Vorschaubild
28:38
313
Vorschaubild
1:00:10
318
Vorschaubild
21:35
343
345
Vorschaubild
36:13
353
Vorschaubild
18:44
369
370
373
Vorschaubild
44:37
396
Vorschaubild
28:21
413
Vorschaubild
16:24
439
455
Vorschaubild
25:10
529
Vorschaubild
15:36
535
Vorschaubild
28:04
552
MaßstabEreignishorizontZentrische StreckungRechenschieberEreignishorizontComputeranimation
KonfigurationsraumZahlenbereichGruppenoperationAuthentifikationEreignishorizontProzess <Informatik>EindringerkennungElektronische PublikationExogene VariableKonsistenz <Informatik>SchlüsselverwaltungWurzel <Mathematik>ComputerspielRechenschieberMultiplikationsoperatorEreignishorizontPhysikalisches SystemEindringerkennungIdentifizierbarkeitComputersicherheitTypentheoriePoisson-KlammerGeradeDifferenteCloud ComputingMotion CapturingPunktMetadatenAggregatzustandSchlussregelVerkehrsinformationRaum-ZeitKonfigurationsraumBitRohdatenZeitstempelElektronische PublikationProzess <Informatik>Elastische DeformationGruppenoperationLoginZweiKernel <Informatik>SchwebungAuthentifikationProgramm/QuellcodeComputeranimation
GruppenoperationZählenKonvexe HülleEreignishorizontSchwebungKonfigurationsraumComputersicherheitElektronische PublikationMusterspracheMultiplikationsoperatorNetzadresseBimodulGruppenoperationNichtlinearer Operatorsinc-FunktionSchreib-Lese-KopfSyntaktische AnalyseBitDefaultNetzbetriebssystemUmwandlungsenthalpieFortsetzung <Mathematik>Computeranimation
Inverser LimesMessage-PassingEreignishorizontElektronische PublikationKonfigurationsraumDateiformatATMParametersystemSchlussregelInverser LimesBimodulGruppenoperationAttributierte GrammatikMini-DiscBitrateSoftwareentwicklerSchreib-Lese-KopfSchwebungHecke-OperatorSystem FComputeranimation
MultiplikationsoperatorEinfach zusammenhängender RaumPunktwolkeSchreib-Lese-KopfSoftwareschwachstelleComputersicherheitBitEreignishorizontUmwandlungsenthalpieInformationInstantiierungMetadatenPhysikalisches SystemFigurierte ZahlVersionsverwaltungProzess <Informatik>Elektronische PublikationOffene MengeBildgebendes VerfahrenFokalpunktNamensraumCloud ComputingMereologieComputeranimation
LoginWurzel <Mathematik>MenütechnikElastische DeformationPasswortDämon <Informatik>QuaderMomentenproblemComputersicherheitPasswortWeg <Topologie>Computeranimation
ZählenPhysikalisches SystemRahmenproblemPasswortMultiplikationsoperatorElementargeometrieNetzadresseLoginBestimmtheitsmaßForcingInstantiierungSystemverwaltungAutorisierungComputeranimation
PasswortElastische DeformationComputersicherheitPhysikalisches SystemLoginPatch <Software>Gibbs-VerteilungKernel <Informatik>OrdnungsreduktionComputerunterstützte ÜbersetzungEreignishorizontElektronische PublikationSchlussregelComputeranimation
QuellcodeBitEreignishorizontSchlussregelEinsHilfesystemComputeranimation
LoginElastische DeformationElektronische PublikationDateiformatBimodulFahne <Mathematik>VerzeichnisdienstDigitalfilterBitNichtlinearer OperatorLesen <Datenverarbeitung>SoftwareentwicklerProzess <Informatik>SchlussregelElektronische PublikationPhysikalisches SystemWeg <Topologie>SensitivitätsanalyseInformationBitrateEindringerkennungComputeranimation
Elektronische PublikationDateiformatBimodulFahne <Mathematik>VerzeichnisdienstAuthentifikationIdentitätsverwaltungPasswortZählenPasswortDienst <Informatik>SystemverwaltungElastische DeformationGruppenoperationMailing-ListePhysikalisches SystemProzess <Informatik>SchwebungComputeranimation
AuthentifikationIdentitätsverwaltungPasswortLoginPatch <Software>Gibbs-VerteilungComputersicherheitPhysikalisches SystemKernel <Informatik>OrdnungsreduktionElastische DeformationKonvexe HülleEreignishorizontSystemverwaltungElastische DeformationElektronische PublikationSchlussregelTypentheorieWurzel <Mathematik>VerzeichnisdienstComputeranimation
DigitalfilterQuellcodeMenütechnikSystemaufrufSchlussregelLeistung <Physik>EreignishorizontBeweistheorie
PasswortElastische DeformationTelnetMaskierung <Informatik>ComputervirusPhysikalisches SystemProzess <Informatik>SocketPlasmabildschirmModul <Datentyp>BimodulSocket-SchnittstelleKonfigurationsraumPhysikalisches SystemDateiformatBrennen <Datenverarbeitung>TelnetInstantiierungProzess <Informatik>BitBildschirmmaskeInzidenzalgebraComputeranimation
QuellcodePunktwolkeDreizehnQuellcodeProzess <Informatik>EreignishorizontMinimumSocketInstantiierungKontrollstrukturElektronische Publikation
ComputervirusElastische DeformationPasswortMenütechnikDateiverwaltungAutomatische IndexierungElektronische PublikationInhalt <Mathematik>MultiplikationsoperatorWeb SiteBenutzerbeteiligungIntegralHash-AlgorithmusGruppenoperationGeradeWeb-SeiteMathematikVerzeichnisdienstComputeranimation
Web-SeiteVererbungshierarchieComputeranimation
Explosion <Stochastik>Total <Mathematik>EreignishorizontFormation <Mathematik>IntegralElektronische PublikationEreignishorizontMathematikRechenschieberMusterspracheBimodulDateiverwaltungWurzel <Mathematik>Computeranimation
GruppenoperationEreignishorizontLoginSchlussregelMultiplikationsoperatorPhysikalisches SystemPasswortWurzel <Mathematik>InformationsüberlastungKonfigurationsraumVererbungshierarchieProzess <Informatik>Virtuelle MaschineProzessautomationOrdinalzahlZeitreihenanalyseCoxeter-GruppeAlgorithmische LerntheorieMusterspracheRechenschieberCloud ComputingSchwebungTermInstantiierungAusreißer <Statistik>Inklusion <Mathematik>Keller <Informatik>Maßerweiterung
Physikalisches SystemComputeranimation
Transkript: Englisch(automatisch erzeugt)
OK, I think. Hello, everyone. Let's welcome our next speaker, Philip Grant, with the talk,
Scale Your Auditing Events. Thank you. Hi, everyone. I do have a couple of slides. But since we only have 25 minutes, these are the slides. You've seen them, they're online.
We'll forget the slides, we'll do stuff live. Otherwise, we're just wasting too much time. So who is using auditd? OK, that's very few. So just to give you a quick idea of what auditd is, it's something that lives in the user space, can capture kernel events. Basically, you can have configuration rules
of things that come from user space and that you want to capture. It could be like system processes, it can be user actions, it can be file events. Those you can capture and then work with auditd. And you have something that looks like this. You have our report. It just gives you an overview of what has been happening
or what is the state of your system. So you can see this has been running just very shortly on my system, just a few seconds, basically. But you can still see logins, failed logins, authentications, users. So this just gives you an overview of what is happening in your system. But obviously, this has raw events in the background as well.
So that would be all search. And then if you add dash raw, it would just give you a lot of raw events. And these are basically the raw events that are happening in your system. Every line starts with a type. You have lots of different types. So for example, a user started something,
then you have in a bracket that is a Unix timestamp, and after the colon, there is a unique identifier. If one event is causing multiple things that you want to capture, you can have duplicate timestamps and IDs. And then you have a lot of meta information depending on what is happening in your system. So for example here,
you can see something was ended in success, and I opened a session with a specific user and a process ID, and we can capture all of these. And that is audit D, basically. The one thing that you can already see here a bit is that this line looks very different than this. And while this is nice to capture a lot of events,
it is a pain in the ass to capture that in a central fashion. You can try to parse it, but it's kind of semi-nice. So just to give you a quick idea, also, why am I talking about that? I work for Elastic, the company behind Elasticsearch, Logstash, Kibana, Beats,
and we have a cloud service as well. And we kind of had this need at some point that we wanted to audit security events for our own cloud service. And then we looked at, how can we capture security events in general? And the first thing we did is we wanted to capture this file and then basically parse it. So that's something, no, not slack.
If you've never seen Kibana, this is Kibana. We'll head over to a pre-built dashboard. We have so-called Filebeat modules. They're basically configured, and they know, I want to, let's head over to the Filebeat modules. You can see here that we have various Filebeat modules
that can collect specific log files. The one I'm interested in here is we have one for auditing events. And basically, we know on my operating system, Ubuntu 18.04, that log file is under that specific path. And by default, the pattern of that file has a specific layout.
And then we can just parse that and collect all the data. We can do that for NGINX, Apache, MySQL, Postgres, Kafka, lots of others. And we can do that for auditing events. So what we get out of these auditing events, and since I've only been running that yesterday for a short while, you can see here which users were doing which kinds of actions.
We could filter down on those. You can see we don't have any top-executed commands, but you can see here we were running this and we had a lot of events in a short amount of time. You can also see, this was probably me doing something yesterday. And I had a Belgian IP address probably. We could zoom into that to see where I was actually coming from.
And then you can see the actual commands and what we have captured on those. However, parsing all of this was still a pain and we didn't really want to do that. So we were thinking like, how can we make this easier? And basically, what we then did is we took what Auditee is doing and we packaged that in another beat. And we called that the Auditee beat.
So it's just a beat to collect security events. And this is using the same configuration like maybe you could say arcane configuration for Auditee. Just to give you a quick idea of what we have here. So like every other beat, it's living in ECT, whatever beat name you have.
So we have Auditee beat here. We have Auditee beat YAML. So we have the YAML file here. You see we have the Auditee module that we are running here. These are some configuration parameters that you might know that how failure modes should be handled, how many backlog items do you want to capture, if you want to rate limit this,
if this is capturing or generating too many events. And then here, I've written myself some notes because I always forget how these filter rules actually work. They define like how this is working. And for example here, I'm saying like watch, we're watching a file, ETC pass WD
with the actions read, write, execute or change any attribute. And we tag this event with pass WD access. This is one rule for example. Or here, we have a slightly more complicated definition where I say always on exit, follow the file etcpen.conf when somebody reads the file
but only this uses in the group 1001 and tag that, K is always tagged that with developers PAM read that specific file. So these are just some configuration files. And basically what we've done is we've kept the same configuration format. We've just wrapped it into audit bead
and audit bead rather than writing it out to disk and then you try to parse it back, sends it as a structured format directly into Elasticsearch. And then you can just visualize that and see what is going on. So to show you, let's head over to this one here. We have some pre-built dashboards for those as well.
Let's head to the audit D overview. Maybe the last 24 hours are a bit too much. Let's say we just figure on the last or focus on the last 15 minutes. You can see we had for example, 22 open file events or connections to or that somebody executed the process and you can see over time how they developed,
where those were coming from. For example, that somebody tried to log in and further down you can see the actual events. And we capture a lot of metadata. Something that might be nice for you to see is for example, you can see we have a host information. So we know on what kind of host this is running and what operating system. If you're running in a cloud provider on some cloud,
you can see this is running on AWS and we enriched that with all the information so you know it's just one specific instance that has a problem for example, security wise. Or you could filter down to say like, oh I know only Ubuntu has a specific vulnerability in one specific version and then I'm only interested in those hosts. So you could filter down to those.
If you're running in Docker or Kubernetes, you could enrich that with the same metadata here so then you could filter down to a specific part or name space or a specific base image if you know that there is a security issue to look into that. So this is what we have running here. So let's see if we can actually find something.
So I will quickly head out here, leave this user, let's say we want to log in with an elastic user. Well, what happens if we forget the password? That would not be good.
But that would be kind of a nice opportunity to actually figure out if anybody is trying to SSH into my box. Since this is a security track, did anybody try to SSH into my box? Otherwise we'll see in a moment. So let's see, I always try to throw that in. So let's see what has been happening in SSH. Well, maybe not just the last 15 minutes
but let's say the last 24 hours. And then we can see how many people tried to log in. This time we were lucky. It's not even that many login attempts. And you could see like public key password. You can see where they're coming from, which users. So these are me probably, admin is not me. We could filter down to the last 15 minutes, for example,
just to see, okay, something didn't work here. You can see, okay, this is too small. This time the IP is coming from somewhere else. Anybody has any idea where this might be coming from and why? Okay, somebody, that's surprising,
somebody from Norway or so is trying to log in. The other one is from Vienna. That's where I'm from. I'm using my phone because people are doing funny stuff with the wifi. And if you're roaming with your phone, you will always get an IP address from home. And then it looks as if with a geo IP lookup, as if that was coming from home. But this is just a coincidence.
This was me trying to log in. Then down here you could see the actual failed login attempts. And if you zoom out and make the timeframe large enough, you would normally have either Russia or China trying to brute force into your instances or probably you now. Ruth me, yeah?
So let's see, where are you coming from? You can see five from here, 10 from here. And we seem to be doing better than China and Russia today. Or India is also trying to catch up. But you just get the idea of where stuff is coming from. But this is just the auth log and it's still educational to see what people are trying to accomplish here. So let's actually log in with our user
and do something useful. So for example, I've shown you the rule when somebody's trying to access ETC-passwd. So let's say my user, bless you, bless you again.
We're just running a cat on ETC-passwd. We're showing the file because this is something we're trying to capture. So let's see if we actually found that. So I'm heading over to the raw events. These are not the ones I want. And you see in the last 24 hours,
we didn't have just 31 events, but this will be, yeah, we had 600,000 events. But we set this nice little tag. And with this tag, we can filter down and say like, I think it's called ETC-passwd-access. You could filter down on that one and instead of 600,000 events, you just have 131
because this is run very frequently. So this is still not helping you too much. You can still see which user is calling it and what command and was it successful or not successful. But this is still a bit wide. So the first rule that we set was maybe not super helpful. The other one that we set for the pem conf
was a bit more limited because it was just bound to that specific user and just a read operation. So let's see if we switch down that filter to that one if we find something more meaningful. And we have developers pem read. So only the developer user is trying to read that file.
If you drill into that, you can see, this was just me now. If we open that one, you can actually see we were running bincat on that file. You can see which users, which operating system. You can see the exact process information, user IDs, et cetera.
Obviously, this makes sense if you have some sensitive files or something that you want to keep track of very well that you configure your rules accordingly for that. Like, you can see pem conf is not making much sense here, but it's just to show you the general approach of what you could do. Something else you could do, for example, is if I run to restart nginx,
so we have nginx running here. So I say service nginx restart. I pick my Elastic Admin user because I know the password for that one. We would be capturing those as well. So for example, you would have multiple places where you could find those. But for example, we have a dashboard
for process executions in audit beat. We have the process executions. Here you can see, for example, this is the stuff that is being run. Let's just filter down on the Elastic user, whatever that user is up to. Then down here in that list you can see here, this was actually restarting nginx.
This was one of the actions that the user has been up to. And that way you could just fit, like if somebody broke into your system with a specific user, you could just see what have they been running and what have they been up to to follow along, whatever stuff they tried out. You could also do some other fun stuff. So let's log out from that user and let's say we're an admin user.
And the admin user is kind of curious. And the admin user tries to look in what do we have in our home directory. And then he sees like, oh, we have an Elastic user. Well, let's see what the Elastic user is up to.
And the Elastic user has a file secret txt. And obviously our admin cannot resist looking at the file. So let's take a look. Oops, there's not where we want to go. Elastic user, secret, will this work?
Yes, no, maybe? No, we need sudo. We can run this with sudo, if I type correctly, to secure. And you can see my secret.
So this was collected. You can, by the way, we have set up a rule to collect those events. So we said like, if somebody who has root permissions looks into the home directory of a non-root user, we want to log that event. And that is something we have in the raw events as well. So if I add my filter rule here,
I think I called it privilege or elevated, oh no, sorry, not elevated briefs. It is called elevated briefs. Oh yeah, sorry, power abuse, yes. This is the one I'm looking for. But elevated briefs will capture this as well since we ran it with sudo.
Elevated briefs is just, in my example, anything that you run with sudo, we are capturing here as well. So we might probably find the elevated briefs here if we open that one. So you can see we have a syscall and you can still see this, but this was only found now because it was run with sudo,
but we're still capturing any sudo event. But yes, power abuse is the proper one if I remembered my own tags. And with power abuse, if we scroll down to those, you see, okay, this was tagged with power abuse, and you can see this was as well the command that we have been running.
So you find out what somebody is up to. Something else that you might be doing is that, let's say, anybody wants to talk to me, but I think the Wi-Fi here is filtering that out. But generally, if I connect by telnet
to my instance on that port and I write hello, it will arrive here. And anybody who wants to can just chat, but I think the Wi-Fi might be filtering this out, so you might need to reuse your phone. How would we find out that somebody has opened a port and is doing stuff now? For that, we have slightly extended
our configuration format, because I said initially the ODD format is a bit crude. And in the very latest release of the stack that came out this week, we added another way to configure things like that, which might be slightly nicer to look at. So here, if I scroll down a bit,
no, not so far. This is the one I want. Here, for example, we have a so-called system module that is looking for processes and sockets every second and is capturing those. And then you could just say which processes have been run by a user or which sockets have been opened, which also might be interesting
if somebody opens weird sockets on your system. And to show you what that might look like is, let's throw all of this away, and let's assume somebody opened something on port 1025. I'm just randomly searching for that. You can see we found a bunch of events,
and you can see, okay, somebody opened an outbound socket. You could just open that event and then see, okay, this is the destination IP. The process has now exited. But this was the specific thing that happened on your instance. You could also see which source port was hit. You could see we would also have a process.
So somewhere you would find the netcat command that we have been running, depending on which event we're looking at right now. I'm just capturing this in various ways to show you the multiple ways that you could see that. For example, here you can see, okay, netcat was stopped, but we opened that port,
and this was the command that we had been running, and this was also what opened the port. So you could just figure out like why are suddenly new ports listening, and which user was that, what has been compromised, or where is stuff happening and breaking. One final thing that we have at the bottom here is we can check the file integrity. In the file integrity,
basically we can just monitor a folder or a file, hash it, and then every time the file changes, we will compare the hash and see that somebody changed the file. Which can also be interesting if suddenly your website is starting to serve some weird content. You might want to figure out when was it changed, and maybe which user changed it, or what were the actual actions they did on the file system.
So I'm watching my web directory, and to actually see something, we'll need to change that. So let's say, no, var, var lib, oh, var lib, HTML, index HTML.
Let's say, no, this is the wrong line. Undo, undo, undo. Let's say we're adding something here, so what this looks like is,
right now, it's just a welcome page. Not super fancy, but let's say somebody wants to add an emoji. This should work. Ah, crap.
And now, when you reload your page, ah, did it, okay, doesn't look that professional anymore,
but we do have another dashboard to actually figure out what happened here. So let's say, audit bit, audit bit, and we have a file integrity module. Let's say we just want to change this in the last 15 minutes. And then you can see here, we moved files,
and we created files. This is because VI's are having this weird replacement pattern. If you used nano or ed or something like that, you would just see a changed file. And if you scroll down, you can see which file's changed, and you can see the actual events where the file was created and replaced, et cetera.
So you can see all the changes on the file system for that as well. And I think that's pretty much it. You did very well on the slides. If you want to try it out yourself, I'm not giving you the root user, but you can use the other user. It's the elastic user and the password is secret.
And you cannot create or change anything on the dashboards, but you can look at all the existing dashboards and just filter down on them if you want to play around with that. I let that run for another day or so, then I'll just throw it away. Please don't start sending spam or anything else. Just do some proper research. If you want to get all the configurations,
I have those on GitHub. You can just look at the configurations and set it up. It's just Terraform and Ansible to set up my instance automatically, and I will just destroy it tomorrow again with that. Yeah, there are some similar solutions. Look at those if you're interested, or look at Auditbeat. That's what we are trying to do and put in our stack.
And with that, we have two minutes for questions. Any questions? Okay, while the microphone is on the way to you, is anybody using Auditbeat already, just out of curiosity? Okay, not that many, not yet.
Hi, thank you for the slides and a great presentation. What are the next steps? So we have collected a lot of audit events, and are there automations or some further stuff that you reach automatically? So it's a kind of a manual stuff until,
so we have to get into Kibana, and let's try to find some events. Yes, so there are two things. However, they are how my salary is being paid. So those are commercial features, so you get them on our cloud service included. We have something called alerting, where you just specify rules, and it will send you Slack, SMS,
Pager, YouTube, whatever. The other thing that is very helpful in that regard probably is we have something called machine learning, but machine learning is a super overloaded term. It's anomaly detection of time series. So it basically learns what is normal. That could be like logins or failed logins per user, or started processes, or which ports are open. And it just learns that over time it knows, for example,
during the week you have like a regular curve, and on the weekend it's much lower. And then if you have an outlier, for example, if a Saturday looks like a weekday, it would just alert you because it knows what the pattern is that it is expecting. So for example, if you have normally very few login attempts over the weekend because you're kind of in cooperation and nobody's working on the weekend, it could just alert you and tell you,
somebody is trying to do as many logins as during the week, which might otherwise with strict alerting rules be very hard to find. So we have these commercial add-ons, but admittedly they're commercial because that is how we finance the rest of the stack. But to get the events, that is all free
and you can just go crazy with that. All the stuff I've shown you is Apache 2 licensed. Thank you. Cool, I think we have one more minute. If anybody else wants to, okay. I was wondering, so you have very nice rules you can give.
Sorry, yeah. Now if you end up with quite an extensive rule set, how heavy would that be for your system? I mean, it would not be the first time that all the thing or mounting would like take down the system.
Obviously if you have too many rules it could take down your system.