Compiling WLB with hardcoded ElasticSearch Host URL

[bcable (Benjamin Cable)]

So I have my GO env up and running great. Compiling winlogbeat.exe flawlessly. I found that you can bake in ElasticSearch credentials into /libbeat/outputs/elasticsearch/config.go

My Question: How can I bake in ElasticSearchs host URL/IP address into winlogbeat.exe? Also, is there reference material that will show me all the places Winlogbeat pulls default config info from? (the .go files and params...)

I eventually want to include (hardcode) all event IDs into the EXE (get rid of winlogbeat.yml altogether). I'm guessing that someone has already done this and was wondering if anybody can point me in the right direction.

Thanks,
Ben

[bcable (Benjamin Cable)]

So for anyone going down the same path as me, let me save you some time. I never figured out weather or not we're suppose to be able to hardcode Elastic node IP/URLs into WLB or not but, I did figure a couple things out. In order for WLB to run without output specified in the YML file, you're going to need to comment out some code in libbeat/publisher/publish.go

 if !publisher.disabled {
 		if len(publisher.Output) == 0 {
 			logp.Info("No outputs are defined. Please define one under the output section.")
 			return errors.New("No outputs are defined. Please define one under the output section.")
 		}
 	}

I also found some references to Elasticsearch in /libbeat/outputs/elasticsearch/url.go and libbeat/scripts/makefile.

You can help me be going through and grepping for "9200" while in the beats directory.

grep -r "9200"

It will show multiple files with references to 9200 (Change a setting like host url, then compile, test, and retry until you find it). Maybe if I have time this weekend, I'll test it out.

Thanks,
Ben

[andrewkroh]

@bcable

I never figured out weather or not we're suppose to be able to hardcode Elastic node IP/URLs into WLB or not

You are definitely not supposed to hardcode config into Winlogbeat. Winlogbeat (and all Beats) strictly separate config from code and you should too. It's a good practice to follow (for example, see the 12-factor manifesto about config).

[bcable (Benjamin Cable)]

Thanks for the reply man! From my perspective it makes sense because there are no variables that will ever have to change. Also, it stops regular people from just looking at the config file and most people wouldn't reverse engineer it anyways. Hard-coding + SSL + regular windows user can't read admin privileged files = secure and clean (Some people have admin and I don't want them to see it either). Clean being the key factor.

Now, if I was using multiple beats with multiple settings I probably wouldn't hard-code anything but you brought up a good point which I didn't think about.

Also, compiling your own exe is fun and I might have taken this overboard.

thanks,
Ben