Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some MS Log Events Not Showing Up #130

Closed
thirsi-guy opened this issue May 10, 2018 · 9 comments
Closed

Some MS Log Events Not Showing Up #130

thirsi-guy opened this issue May 10, 2018 · 9 comments
Assignees
Labels

Comments

@thirsi-guy
Copy link

I have two identical Wazuh 6.2.3 deployments on ELK 6.2.3. One of them (#1) allows for Windows Event ID 4624 to show up in searches, while the other (#2) doesn't. I was able to find a single instance of Event ID (data.id) 4624 in #2's data and it was related to an "Multiple authentication failures followed by a success." alarm. Are these events being suppressed and not send to the ELK stack? I'm needing them in the data so I can report on certain successful logon events.

@thirsi-guy
Copy link
Author

As an update on this, it's rule.id:18107 that is not getting shipped into Kibana. I've compared it with my other Wazuh instance and the rules are identical.

@SitoRBJ SitoRBJ assigned SitoRBJ and unassigned frgv Jun 25, 2018
@SitoRBJ
Copy link
Contributor

SitoRBJ commented Jun 26, 2018

Hello thirsi-guy,

First of all, we regret the delay. If I have understood correctly, just to make sure, in your environment you have two different managers (one per deployment). In one, you can view in Kibana the alerts produced by the rule with id = 18107 and the other not, right?

As I believe that is the case, we will see how to proceed to detect the root of the problem. The events follow a simple data flow, to try to find out where the problem that has arisen resides we will check if the alert is being generated whose rule has the ID = 18107.

In Wazuh's deployments with ELK, Kibana displays the alerts that appear in the alerts.json file on the manager side. To check if it's a Kibana or Wazuh problem we ask you to check if you have alerts with a rule ID = 18107 in that file: /var/ossec/logs/alerts/alerts.json (in manager server).

For example, you can check this by using one of these options:

cat /var/ossec/logs/alerts/alerts.json | grep '"id":"18107"'

With this command, you can see all alerts that have the rule id=18107.

cat /var/ossec/logs/alerts/alerts.json | grep '"id":"18107"' | wc -l

And with these, you can count directly how many times these alerts have been generated.

If the execution of those orders gives you results that indicate that the alerts have been generated, the problem would lie with Kibana, as it would not be taking the alerts correctly. On the other hand, if you don't get any results that indicate that these alerts have been generated, we should perform more checks, such as, for example, knowing if the events that generate these alerts are arriving correctly to the manager.

I hope we will find the problem soon so that you can have full functionality.

Kind regards,

Alfonso Ruiz-Bravo

@SitoRBJ
Copy link
Contributor

SitoRBJ commented Jun 26, 2018

Hello again,

If it's not too much trouble, could you show us how you're doing the alert searches with the rule id = 18107 in each of the Kibana instances, in the Kibana of the deploy 1 (where it is displayed) and in the Kibana of the deploy 2 (where it is not displayed)?

Kind regards,

Alfonso Ruiz-Bravo

@thirsi-guy
Copy link
Author

Correct, we have two separate managers, A & B. I checked the alerts.json on both managers and A shows many alerts for event 18107, whereas B shows zero event 18107's. In B's environment, I have verified the failed login attempts are in the windows logs for the ossec agent to read them.

For the alert searches, I'm simply using "rule.id:18107" from Kibana's Discover page.

From this, it appears the rules are not making into the alerts.json file in manager B.

@SitoRBJ
Copy link
Contributor

SitoRBJ commented Jun 26, 2018

Hello thirsi-guy,

Understood, one question for more information. Do you have alerts for other windows events, such as alerts with rule id = 18106/18130/..., corresponding to those failed login attempts events in the alerts.json file?

Kind regards,

Alfonso Ruiz-Bravo

@thirsi-guy
Copy link
Author

I do have many entries for 18130, but none for 18106.

@SitoRBJ
Copy link
Contributor

SitoRBJ commented Jun 27, 2018

Hello thirsi-guy,

This behavior is normal because rule 18130 comes from rule 18106. Basically, we have verified that alerts are being generated for windows events, but for events that generate alerts whose rule is 18107 we do not get results.

To discard another possible option, is it possible that you have raised the minimum alert level for storage in the log files (alerts.json and alerts.log)?

It may be that in the manager configuration file (/var/ossec/etc/ossec.conf) you have in the alerts section, in the <log_alert_level> field a value higher than 3 (rule 18107 alert level).

<ossec_config>
. . .
    <alerts>
         . . .
        <log_alert_level>3</log_alert_level>
         . . .
    </alerts>
. . .
</ossec_config>

Kind regards,

Alfonso Ruiz-Bravo

@thirsi-guy
Copy link
Author

You are absolutely correct. As soon as you mentioned the log_alert_level, I recalled I had changed it on our first Wazuh implementation. I've changed it on the second implementation and I'm now seeing the events. Thank you VERY MUCH for your assistance with this !!!

@SitoRBJ
Copy link
Contributor

SitoRBJ commented Jun 27, 2018

Hello thirsi-guy,

Thank you for your patience. We are very happy that the problem was solved, any questions you may have do not hesitate to report them. We will proceed to close the issue.

Kind regards,

Alfonso Ruiz-Bravo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants