All posts for the month July, 2019

I encountered a problem where certain messages being sent to our Graylog instance had fields that were larger than ElasticSearch / Lucene limit of 32kb, thus failing to be indexed because of that one field. Kind of wished that Graylog had more intelligent way to handle these… There are bunch of people that encounter problems like these, just search for any part of this error and you’ll see many complaints.

{"type":"illegal_argument_exception","reason":"Document contains at least one immense term in field=\"Field_name\" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. Please correct the analyzer to not produce such terms. The prefix of the first immense term is: '[...]...', original message: bytes can be at most 32766 in length; got 32773","caused_by":{"type":"max_bytes_length_exceeded_exception","reason":"max_bytes_length_exceeded_exception: bytes can be at most 32766 in length; got 32773"}}

After a while of searching for a solution, there was none. Not a ready to use solution at least. Graylog support suggested splitting the field on several forum posts without specific instructions. So, I spent some amount of time and figured one way to do it using substring function (described here).

The rule I’ve created will first check if the fields you want to deal with even exist, no need to process the rule and waste CPU cycles if the field is absent. Then the rule will generate additional fields for any data beyond 32KB and named them “_continued_X” up to 3 new fields each of 32KB. Totaling 4 fields in total for a maximum of 128KB. Any fields smaller than 32KB will also be processed, but the field name and content will effectively stay the same.

Before you begin, make sure the field you are trying to split is properly parsed by Graylog (i.e. you have appropriately configured input and/or extractors). Then create a new pipeline or add to existing.

Create a new pipeline rule based on the following code, link the rule to proper streams and stages.

rule "Split_a_field_larger_than_32kb"
let any_var_name = to_string($message.your_field_name);
set_field("your_field_name", substring(any_var_name, 0, 32766));
set_field("your_field_name_continued_1", substring(any_var_name, 32766, 65532));
set_field("your_field_name_continued_2", substring(any_var_name, 65532, 98298));
set_field("your_field_name_continued_3", substring(any_var_name, 98298, 131064));

Obviously, modify the rule to suite your environment, primarily the filed name. Variable name can be anything.
Amount of fields can also be reduced/increased the way you want.

I hope that this will save time for you.

Recently I’ve encountered a challenge of deploying Wazuh agent to bunch of Windows servers. Wazuh agent MSI package takes several parameters, and if given enough information it is able to register the agent, perform basic configuration and add itself to appropriate groups – all unattended. Generally this would be quite straightforward if old school startup scripts worked properly on Windows 2012. Unfortunately, they didn’t work for me.

After short amount of research I realized that simplest way to add parameters to a GPO based MSI installation is to use MSI transformations (MST files) that you can create with Orca.

Download Windows SDK (can be found here). During the setup process you can select MSI tools only, if you don’t need the rest of the tools. It will make for a quicker download.

This will only download Orca, you need to install it manually. I had to search through program files to realize that – I should have seen that this provides the “Download” button, not install. Anyway, Orca installer will be located at “C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86” (note that path might not be exact since I would assume the build version will only change in the future). Simply run Orca-x86_en-us.msi to install it. After that you should see Orca-esque icon in “C:\Program Files (x86)\Orca”.

Orca.exe will provide a handy graphical interface where you can edit a bunch of attributes of MSI files and generate MST that we need. Open up Wazuh agent MSI in Orca, and select new Transform.

Navigate to “Propery” table and right click whitespace, then select “Add Row”

Add all the properties that you need for your Wazuh Agent installation by repeating this process.
Make sure you use the correct names for the parameters. More information about deployment variables can be found on the official docs pages of Wazuh.

Generally, I would recommend testing the installation parameters manually before trying to create the MST. Simply run the Wazuh Agent MSI from the command line with all the parameters you plan to use. After you have successfully registered the server from the command line (without graphical interface), use the same parameters in Orca.

After you’ve added all the values simply click on “Generate Transform” from the “Transform” drop-down menu and save the MST file.

At this point you have everything you need to create custom GPO software deployment. Generate a new policy, or even add to existing. Click on “New” “Package” under “Computer Configuration” -> “Policies” -> “Software installation”.
Theoretically you can also use the “User Configuration” but for something like FIM you would want agent deployment to happen irregardless of the users.

This will prompt you to select the MSI file. Here you need to select the original Wazuh Agent MSI that is store on the network shared location (it needs to be accessible by computer objects that will receive the package)

Choose Advanced, so we can add the MST.

On the next screen you can make sure that default values are fine for your environment.

Then the crucial part is to add the MST file under “Modifications” tab. Keep in mind that MST file also needs to be accessible by the computer object.

Then apply the GPO to appropriate OU that contains your servers. You’ll probably have to reboot the servers for the actual deployment to occur.

This approach should be applicable to majority of MSI files, but your mileage may vary.