OK, so first off, the auditbeats install, one reference had me use the downloaded files ./auditbeat setup method, whereas the other had me install using yum.
The yum method didnt appear to install any dashboards and the command to do so wasnt present, and the other did but they are blank.
what am i missing on this? Are other components required that i didnt see in the reading?
The complete documentation for the siem install for testing this seems to have eluded me, can someone point me in the right direction so that i can evaluate the functionality of this?
Thanks
Hi @rconroy
If you are just getting started with security / SIEM perhaps start with this....
There is also a good video as well.
If you are looking for how to get the data ingested and there 2 approachs Beats and the New Agent (Beta)
To more answer your question specifically you will only need to run ./auditbeat setup once whether you install it on 1 server or 1000 servers.
Yes the package installers do not run setup ... you need to run it once manually.
Hope this helps
i had looked thru some of that previously but i will review again.
As far as the setup, the yum based install did not create the install file, so there were not dashboards or anything post install. i went back and did it the other way, which then created the dashboards accordingly, but there is no data coming in even with auditbeat installed to the localhost.
I guess ill go back thru it all and see what i apparently missed.
After you ran setup how did you start at auditbeat?
If everything is on localhost you shouldn't actually have to change any settings in auditbeat
I'm not really sure what that means..you might want to just test it first with the tar.gz all in one place and then try the installers.
I'm not as familiar with yum I use RPM and Deb
installed it as a service per this page:
Repositories for APT and YUM | Auditbeat Reference [7.10] | Elastic
This didnt create the files for ./auditbeat setup -e --strict.perms=false per this page,
SIEM on the Elastic Stack | Elastic Security | Elastic SIEM
So i then downloaded that as well and executed that after downloading it as well.
Everything is currently set to use local host, i plan to expose after after the initial test is done.
I feel like i missing something likely rather basic as this is my first attempt at doing this, but i cant quite figure what it is.
I am a bit confused....
setup does not create any files it just creates some settings and dashboards internal to elasticsearch / Kibana.
Did you then actually start auditbeat? Either by hand or as a service? setup does not actually start shipping data
Also if you want to simplify it just to test just download the tar.gz instead of trying to install through YUM
i think more likely im the one confused 
what installs to the elasticsearch server, versus what installs to the monitored host?
if the server is the intended monitored host, what all needs to be there?
also worth noting im doing the on prem downloaded version, not the cloud based, and it appears much of the terminology is very different.
Can the elasticsearch box not actually monitor itself in localhost mode?
There is a lot to unpack in these question.
First there will be different "architectures" for poc/dev/test vs production but I will assume we are just trying to POC at first.
Assuming you are trying to do the simplest POC often folks install elasticsearch and kibana on the same host using all the defaults. And as I think you noticed by default elasticsearch is bound to localhost by default for a number of reasons. Note this is not a production architecture.
Take a look at This post that I wrote up a while ago... this is one windows but the concepts are the same.
Beats are installed on any host you want to monitor and they ship data to elasticsearch, and yes for both a POC/Test/Dev and in Production installing beats on the elasticsearch host is totally valid but not required.
NOTE: So if elasticsearch is in localhost only mode, i.e. not on the network then audibeat (any beat) on another host will not be able to ship data to that elasticsearch, not until it is connected to the network interface.
Yes you can put, elasticsearch, kibana, and auditbeat all on the same host, change no setting and it will (should) all work OOTB.
One change you might want to make is in the kibana.yml set server.host: to the network ip to bind to, that way you could reach kibana from another box, not to be confused with the elasticsearch.hosts: which you should leave commented out in this localhost mode
Me, I tend to recommend install all 3 using the tar.gz / linux instruction just to get everything running once and see it. If that works, then trying installing via a package manager.
It appears that you have done some YUM installs, if you want to keep using those then those willl need to be started as service. Also I have seen a number of time when folks install by apt / yum etc... give up and then have other struggles because they did not remove them and more than one elasticsearch, kibana or audibeat tries to start.
With respect to on prem vs cloud and with respect to beats installation, configuration and running there is no difference except for the connection info.
Cloud (which is just a shorthand / all in one connection string
cloud.id: "staging:dXMtZWFzdC0xLmF3cy5mb3VuZC5pbyRjZWM2ZjI2MWE3NGJmMjRjZTMzYmI4ODExYjg0Mjk0ZiRjNmMyY2E2ZDA0MjI0OWFmMGNjN2Q3YTllOTYyNTc0Mw=="
cloud.auth: "auditbeat_setup:YOUR_PASSWORD"
On Prem (which you would not change if you are doing the localhost POC the defaults will work.
Note this is an example of a formal setup where auditbeat would have its own user / pw.
output.elasticsearch:
hosts: ["myEShost:9200"]
username: "auditbeat_internal"
password: "YOUR_PASSWORD"
...
setup.kibana:
host: "mykibanahost:5601"
username: "my_kibana_user"
password: "{pwd}"
Hope this helps you get a little further...
OK so first dumb question then is this, you mention putting them all on one box, which is what i have now, so for the moment lets focus on that as i now how to exposes it from past usage.
I should not this isnt my first time using elastic or kibana, just attempting to integrate beats and the "siem" components. so i know how to expose iot and all that once im done with the testing on localhost.
I currently have elastic, kibana, and auditbeats, installed to the same server which is a CentOS8 box. Yes all but beats were installed using yum packagess. i tried doing beats that way but as noted this doenst add the dashboards as the install script isnt present. So i did that one using the script.
All are set to use localhost, and all the dashboards under auditbeats are blank, suggesting it is ingesting no data from the local server.
This is where i am currently stuck.
I believe i understand the architecture in principle, im just unsure why mine are showing no data.
I have not made any adjustments you refer to in the yml files as it should i thought be using the default localhost:9200 string.
output.elasticsearch:
Array of hosts to connect to.
hosts: ["localhost:9200"]
I have not configured any security or passwords yet to connect to this.
Hi @rconroy
I am still confused what install script you are looking for this is no install script
To install the dashboards and setup in Kibana and create the correct confis in elasticsearch run
./auditbeat setup -e
This does not install anything in addition on the host just loads some data / settings into elasticsearch.
Perhaps you could try these exact commands just to test
curl -L -O https://artifacts.elastic.co/downloads/beats/auditbeat/auditbeat-7.10.1-linux-x86_64.tar.gz
tar xzvf auditbeat-7.10.1-linux-x86_64.tar.gz
cd auditbeat-7.10.1-linux-x86_64
./auditbeat setup -e
sudo chown root auditbeat.yml
sudo ./auditbeat -e
Let auditbeat startup
2nd In Dev Tools in Kibana run
GET _cat/indices/audit*?v
should look something like
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open auditbeat-7.10.0-2021.01.11-000001 76QldcSQTUC6MsZlz_otRQ 1 1 2382 0 1.4mb 1.4mb
Let's see if you have any data in the auditbeat-* indices
If so visit the [Auditbeat System] System Overview ECS dashboard
Just for a sanity check I just did all these step on local host on a linux / MacOS and it works not changing any settings, data it there Dashboards populated. I can try on CentOS if needed
3rd if you prefer not to use the method above for a quick check, please look at auditbeat logs and share them from startup. If you followed the method above and it did not work please share the logs.
1 Like
Here is the curl output, i did it thru http out opf familiarity:
As you can see the index is open and appears healthy, but there is no daata in it, this is where im stuck.
Also, oddly enough i am not finding any auditbeat logs. it does not seem to be creating one.
The dashboard is as shown:
I suspect it either pulling from the wrong index, or data is not going into the index, but even odder when i try to verify this or look at other indices under "Management", the "Index Patterns" are missing.
I should add im not fully familiar with this new version and its a crash course across the board so if thats been moved i havent found it.
1 Like
The audibeat index you see is post setup so that is good and I don't believe it is pulling from the wrong index I literally just ran this... we are close.
Data is not flowing from auditbeat to elasticsearch
If you start from the method I suggested with the NOTE FIXED ./auditbeat -e the logs will go to the console and we should see the issue. Capture that first 100 lines or so and post.
How are you starting?
otherwise logs should be in /var/log/auditbeat and probably owned by root
I just saw this... it should look like this.. .
The index pattern must be there because if not the dashboard would not load even as above it would be broken completely so the index pattern is there.
i used the command you suggested, the output is below. also regarding the log files there is no /var/log/auditbeat folder, at all.
2021-01-11T13:03:04.246-0500 INFO instance/beat.go:645 Home path: [/opt/auditbeat-7.10.1-linux-x86_64] Config path: [/opt/auditbeat-7.10.1-linux-x86_64] Data path: [/opt/auditbeat-7.10.1-linux-x86_64/data] Logs path: [/opt/auditbeat-7.10.1-linux-x86_64/logs]
2021-01-11T13:03:04.248-0500 INFO instance/beat.go:653 Beat ID: 2b16854a-e2d5-48b9-9a2b-9c47e5b0839b
2021-01-11T13:03:04.252-0500 INFO [beat] instance/beat.go:981 Beat info {"system_info": {"beat": {"path": {"config": "/opt/auditbeat-7.10.1-linux-x86_64", "data": "/opt/auditbeat-7.10.1-linux-x86_64/data", "home": "/opt/auditbeat-7.10.1-linux-x86_64", "logs": "/opt/auditbeat-7.10.1-linux-x86_64/logs"}, "type": "auditbeat", "uuid": "2b16854a-e2d5-48b9-9a2b-9c47e5b0839b"}}}
2021-01-11T13:03:04.252-0500 INFO [beat] instance/beat.go:990 Build info {"system_info": {"build": {"commit": "1da173a9e716715a7a54bb3ff4db05b5c24fc8ce", "libbeat": "7.10.1", "time": "2020-12-04T23:20:49.000Z", "version": "7.10.1"}}}
2021-01-11T13:03:04.252-0500 INFO [beat] instance/beat.go:993 Go runtime info {"system_info": {"go": {"os":"linux","arch":"amd64","max_procs":4,"version":"go1.14.12"}}}
2021-01-11T13:03:04.254-0500 INFO [beat] instance/beat.go:997 Host info {"system_info": {"host": {"architecture":"x86_64","boot_time":"2021-01-07T16:48:26-05:00","containerized":false,"name":"elksiem","ip":["127.0.0.1/8","::1/128","10.60.0.130/24","fe80::7095:3db2:1ce3:7f1e/64","192.168.122.1/24"],"kernel_version":"4.18.0-240.1.1.el8_3.x86_64","mac":["f0:db:30:60:3d:c0","52:54:00:85:5a:6d","52:54:00:85:5a:6d"],"os":{"family":"redhat","platform":"centos","name":"CentOS Linux","version":"8","major":8,"minor":3,"patch":2011},"timezone":"EST","timezone_offset_sec":-18000,"id":"8389b13baa66345ba57e05cb71b58c1e"}}}
2021-01-11T13:03:04.255-0500 INFO [beat] instance/beat.go:1026 Process info {"system_info": {"process": {"capabilities": {"inheritable":null,"permitted":["chown","dac_override","dac_read_search","fowner","fsetid","kill","setgid","setuid","setpcap","linux_immutable","net_bind_service","net_broadcast","net_admin","net_raw","ipc_lock","ipc_owner","sys_module","sys_rawio","sys_chroot","sys_ptrace","sys_pacct","sys_admin","sys_boot","sys_nice","sys_resource","sys_time","sys_tty_config","mknod","lease","audit_write","audit_control","setfcap","mac_override","mac_admin","syslog","wake_alarm","block_suspend","audit_read"],"effective":["chown","dac_override","dac_read_search","fowner","fsetid","kill","setgid","setuid","setpcap","linux_immutable","net_bind_service","net_broadcast","net_admin","net_raw","ipc_lock","ipc_owner","sys_module","sys_rawio","sys_chroot","sys_ptrace","sys_pacct","sys_admin","sys_boot","sys_nice","sys_resource","sys_time","sys_tty_config","mknod","lease","audit_write","audit_control","setfcap","mac_override","mac_admin","syslog","wake_alarm","block_suspend","audit_read"],"bounding":["chown","dac_override","dac_read_search","fowner","fsetid","kill","setgid","setuid","setpcap","linux_immutable","net_bind_service","net_broadcast","net_admin","net_raw","ipc_lock","ipc_owner","sys_module","sys_rawio","sys_chroot","sys_ptrace","sys_pacct","sys_admin","sys_boot","sys_nice","sys_resource","sys_time","sys_tty_config","mknod","lease","audit_write","audit_control","setfcap","mac_override","mac_admin","syslog","wake_alarm","block_suspend","audit_read"],"ambient":null}, "cwd": "/opt/auditbeat-7.10.1-linux-x86_64", "exe": "/opt/auditbeat-7.10.1-linux-x86_64/auditbeat", "name": "auditbeat", "pid": 98915, "ppid": 2210, "seccomp": {"mode":"disabled","no_new_privs":false}, "start_time": "2021-01-11T13:03:03.190-0500"}}}
2021-01-11T13:03:04.255-0500 INFO instance/beat.go:299 Setup Beat: auditbeat; Version: 7.10.1
2021-01-11T13:03:04.255-0500 INFO [index-management] idxmgmt/std.go:184 Set output.elasticsearch.index to 'auditbeat-7.10.1' as ILM is enabled.
2021-01-11T13:03:04.256-0500 INFO eslegclient/connection.go:99 elasticsearch url: http://localhost:9200
2021-01-11T13:03:04.256-0500 INFO [publisher] pipeline/module.go:113Beat name: elksiem
2021-01-11T13:03:04.256-0500 INFO eslegclient/connection.go:99 elasticsearch url: http://localhost:9200
2021-01-11T13:03:04.260-0500 INFO [esclientleg] eslegclient/connection.go:314 Attempting to connect to Elasticsearch version 7.10.1
2021-01-11T13:03:04.283-0500 INFO [index-management] idxmgmt/std.go:261 Auto ILM enable success.
2021-01-11T13:03:04.286-0500 INFO [index-management.ilm] ilm/std.go:139do not generate ilm policy: exists=true, overwrite=false
2021-01-11T13:03:04.286-0500 INFO [index-management] idxmgmt/std.go:274 ILM policy successfully loaded.
2021-01-11T13:03:04.286-0500 INFO [index-management] idxmgmt/std.go:407 Set setup.template.name to '{auditbeat-7.10.1 {now/d}-000001}' as ILM is enabled.
2021-01-11T13:03:04.287-0500 INFO [index-management] idxmgmt/std.go:412 Set setup.template.pattern to 'auditbeat-7.10.1-*' as ILM is enabled.
2021-01-11T13:03:04.287-0500 INFO [index-management] idxmgmt/std.go:446 Set settings.index.lifecycle.rollover_alias in template to {auditbeat-7.10.1 {now/d}-000001} as ILM is enabled.
2021-01-11T13:03:04.287-0500 INFO [index-management] idxmgmt/std.go:450 Set settings.index.lifecycle.name in template to {auditbeat {"policy":{"phases":{"hot":{"actions":{"rollover":{"max_age":"30d","max_size":"50gb"}}}}}}} as ILM is enabled.
2021-01-11T13:03:04.288-0500 INFO template/load.go:183 Existing template will be overwritten, as overwrite is enabled.
2021-01-11T13:03:04.410-0500 INFO template/load.go:117 Try loading template auditbeat-7.10.1 to Elasticsearch
2021-01-11T13:03:04.517-0500 INFO template/load.go:109 template with name 'auditbeat-7.10.1' loaded.
2021-01-11T13:03:04.517-0500 INFO [index-management] idxmgmt/std.go:298 Loaded index template.
2021-01-11T13:03:04.518-0500 INFO [index-management] idxmgmt/std.go:309 Write alias successfully generated.
2021-01-11T13:03:04.519-0500 INFO kibana/client.go:119 Kibana url: http://localhost:5601
2021-01-11T13:03:04.719-0500 INFO kibana/client.go:119 Kibana url: http://localhost:5601
2021-01-11T13:03:07.251-0500 INFO [add_cloud_metadata] add_cloud_metadata/add_cloud_metadata.go:89 add_cloud_metadata: hosting provider type not detected.
2021-01-11T13:03:15.963-0500 INFO instance/beat.go:815 Kibana dashboards successfully loaded.
Yes but it does not seem to be:
Click on Stack Management ... index patterns will be under that. There is a whole management section under that. I think you should do a little menu safari... click on them all Kibana has changed ALOT in the last year.
Also Please show the command you run when you provide logs.
That output is from (Apologies I put the setup command when I meant the run commans in that last post)
./auditbeat setup -e
Now run actual auditbeat and show the logs...
sudo chown root auditbeat.yml
sudo ./auditbeat -e
BTW When you run from the tar.gz it will put the logs under that dir
Logs path: [/opt/auditbeat-7.10.1-linux-x86_64/logs]
yes that output is from the command you listed copy pasted.. i actually tried to pipe it to text file for ease using > but the output on screen was not the same as what was captured in that file so i gave you the on screen output since that what you requested.
auditbeat.yml is listed as root/root 600
Yes i have observed it using that path from the tar files, i checked there, no /log folder exists.
Thanks for the redirection on the menu, it didnt align with what i got from my reading, quite the change. But i now see them there.
There wont be any logs when you run the command with -e if you take that off it will write logs.
So Now run actual auditbeat command without setup and show the logs...
sudo chown root auditbeat.yml
sudo ./auditbeat -e
or you can take of the -e and it will write logs.
ran command ./auditbeat
There was no output as this appears to be running in the foreground.
It did create a log file this time. I will paste the content below.
The dashboard does now have data.
I assume i can safely not expose this to the network to continue testing with remote hosts?
So im curious why did i have to manually start this in this way if it was installed and setup as a service at time of install? What is the difference here? How would you best suggest getting this to run back in the background as a service?
i feel like im missing something there. i installed this what i thought was twice, first using yum, then using the tar execution, and it seems like this came down to iot not actually running? I mean we havent changed anything conf wise so what was my roadblock?
i could not post the log as it was too large, gave me a charater error message
So it works... good / cool.
Initially Probably you never actually ran setup correctly that was the blocker ... I usually do it via the tar method and it only needs to be run once (1 time for 1/10/100... hosts not for each host). It can be run after installing with YUM / RPM / DEB but the command is a bit more complex.
Now back to running as a service...
So you installed as a service via YUM (I am not a yum expert but plenty people install that way) depending on your OS you will need to started
Whether that is via service or systemctl is OS dependent you will need to figure that out.
If it does not work, You will need to look at the logs or do a systemctl status etc ... It should log to the correct log path /var/log/auditbeat or perhaps your OS is setup to send those logs to syslog.
Sometime when you install as a service there can be some permissions issues (OS Dependent , How your OS is Configed) you will need to look in the logs... they are there.
As to exposing on the network this is clearly your decision.... however basic auth/auth and TLS is available to setup up... it will take a little work (certs are always fun). Of course in the long run the elastic stack can be fully secured and leverage enterprise SSO / SAML / AD etc.
Of course if you did a cloud trial .... the entire stack and all comms between beats and the stack would be TLS out of the box...
BTW I wrote a how to do single node security... it could be a little out of date but should be pretty good
Good Hunting...