Issues with ingesting Syslog into Wazuh

[AltStorm]

Hello Team,

I've been following this documentation to set up Syslog ingestion on the Wazuh server.

However, I am unable to see the Syslogs get ingested into the SIEM.

Here's some information regarding the current setup:

Syslog Client: 10.10.10.10 

Wazuh server: 10.20.20.20

This is my current ossec.conf configuration:

In the logs, Wazuh seems to be listening on port 514/UDP.

The syslog client is sending the logs correctly, as the network Firewall shows outgoing traffic, but Wazuh isn't accepting these connections, and I am unable to see them get ingested into the SIEM.

Scanning the 514 port using NMAP reveals that it's filtered even though Wazuh has it open locally.

Could anyone help me out?

Thank you in advance

Kind regards,

Alt

[Anthony Faruna]

Hello AltStorm,

Thank you for using Wazuh

Please can you explain what you mean by Wazuh is not accepting the connection? Are you seeing error messages suggesting the connections are refused by Wazuh?

When a log/event is forwarded from an endpoint to the Wazuh manager the Wazuh manager compares the log against its rules and if the logs trip a rule and trigger alerts, the alerts are saved in alerts.log. Wazuh does not save any raw logs that are forwarded from the endpoints.When the archive log is enabled, wazuh archives store all events received by the Wazuh server, whether or not they trip a rule. By default, Wazuh archives are disabled because they store a large number of logs on the Wazuh server.Let's enable the archive log and test if those syslog from the network devices are there.For this, You can try the following steps:
Activate the 'logall' option within the manager's ossec.conf file, as outlined in our Documentation:Wazuh Documentation | logall
This option will allow you to see all the events being monitored by your manager in the /var/ossec/logs/archives/archives.log file. You will then be able to observe the incoming log generated by your endpoint. After setting this option, restart the manager and check the archives.log file.Note: Don't forget to disable the logall parameter once you have finished troubleshooting. Leaving it enabled could lead to high disk space consumption.Look for if there are any logs inside the relevant archive log. Use grep parameters related to the log.
cat /var/ossec/logs/archives/archives.log | grep KeywoardTest those logs using log-test to find out if logs are decoded by decodes and rules.

Check this document to get help with the logtest tool.
https://documentation.wazuh.com/current/user-manual/ruleset/testing.html

Based on the findings of your logtest write custom decoders and rules.
https://documentation.wazuh.com/current/user-manual/ruleset/custom.htmlLet me know if you need any further assistance.

Best Regards

--
You received this message because you are subscribed to the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/dbe190e9-a440-4a80-bd4f-b026d89f1e29n%40googlegroups.com.

[AltStorm]

Hello Anthony,

Thank you for the quick answer, I apologize for the slowness on my end, it's been really busy lately.

Thank you for the clarification regarding the logs being discarded when they don't trigger any alert / rule, I was unaware of this, the logs are indeed being received by Wazuh, just not parsed.

The documentation you provided has been very helpful on setting up a decoder and attempting to decode the logs.

I have a question though, I'm currently setting up the rules and I would like to trigger a rule based on a few criteria:

• A brute force rule has been triggered in the last 2 minutes
• There's been a successful login from the same srcip or srcuser that triggered the brute force rule

The decorder works, as do the other rules.

Currently these are the rules in play:

   <rule id="110005" level="10" frequency="6" timeframe="120">

        <if_matched_sid>110001</if_matched_sid>

        <decoded_as>synology-connection</decoded_as>

        <program_name>Connection</program_name>

        <status>fail</status>

        <same_srcip/>

        <description>Synology brute force attack recipient via [SAME SOURCE IP].</description>

        <mitre>

            <id>T1110</id>

        </mitre>

    </rule>  

    <rule id="110007" level="11" timeframe="120">

        <if_sid>110005</if_sid>

        <decoded_as>synology-connection</decoded_as>

        <program_name>Connection</program_name>

        <status>success</status>

        <description>Synology successful brute force attack.</description>

        <mitre>

            <id>T1110</id>

        </mitre>

    </rule>  

My reasoning being that if there was a succesful login after a brute force attack, it may be because of the attack. The idea was to try and match the previous rule and trigger the second one if there was a successful login within 120 seconds of the previous rule firing.

I've read through the documentation but haven't been able to figure out how to do this, I've also referred to this discussion but the answer provided wasn't working when I tried it  .

[Anthony Faruna]

Hello AltStorm

I'm glad to know the documentation was helpful and you discovered the logs were getting to Wazuh.

Are you getting alerts for the first rule you created? The timeframe option is intended to be used with the frequency option hence why the second rule is not triggering. 

I will be expecting your response shortly.

Best Regards

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/2b4dfe2d-94fc-4b6a-bc33-1cdff307d9een%40googlegroups.com.

[AltStorm]

Hello Anthony,

The first rule is creating the alerts with no issue (I've modified the rule description a bit):

And I see, the documentation also stated that. However, the minimum value for frequency would be 2 according to the docs, which is why I had hoped to omit it and trigger the second rule if:

• The first rule triggered, signaling a possible brute force attempt.
• There was a successful login from the same srcip within 2 minutes.

Is there another way of accomplishing this?

Thanks for your help so far.

Kind regards

[Anthony Faruna]

Hello,

You are correct. The second rule won't trigger because the brute force rule checks for failed attempts.

I tested using CDB lists, but the bottleneck remains the same. It isn't easy to correlate a log with failed attempts with a log with successful attempts. Any source IP flagged for a brute force attack should be subject to further investigation by the security teams, which can help correlate with any successful login attempt. 

Also, you can look at our blog post on Building IoC files for threat intelligence with Wazuh XDR as a guide to extract the source IP to a cdb list and then create a rule to trigger a successful login.

I looked through the rules and decoders you created. Thank you for the job well done.

Please let me know if you have any questions.

Best Regards

On Thu, May 16, 2024 at 8:47 AM Stormcrow <alt.st...@gmail.com> wrote:

Good morning Anthony!

The timeframe was arbitrary and just as an example. The idea is that the succesful brute force rule triggers if there's been a login after the previous brute force rule triggered.

However, I can't really use <if_sid> as (how I understand it) from the documentation, this would immediately run the alert, check if the log's status is "success", which would never trigger since the brute force rule checks for failed attempts.

I have also tried with <if_matched_sid> as from the documentation  , it mentions that it would trigger if the matched sid triggered in a certain amount of time. But this runs into the same issue I mentioned before of frequency having to be at a minimum, a 2, which would mean 2 brute force attacks would need to happen before this rule triggered.

Brute force rule:

    <rule id="110005" level="10" frequency="6" timeframe="120">
        <if_matched_sid>110001</if_matched_sid>
        <decoded_as>synology-connection</decoded_as>
        <program_name>Connection</program_name>
        <status>fail</status>
        <same_srcip/>

        <description>[$(hostname)]: Synology brute force attack recipient via the same IP: $(srcip).</description>

        <mitre>
            <id>T1110</id>
        </mitre>
    </rule>  

"Successful" brute force rule:

    <rule id="110007" level="12" timeframe="45">
        <if_matched_sid>110005</if_matched_sid>

        <decoded_as>synology-connection</decoded_as>
        <program_name>Connection</program_name>

        <status>success</status>
        <description>[$(hostname)]: Synology successful brute force attack.</description>

        <mitre>
            <id>T1110</id>
        </mitre>
    </rule>

Example log sequence for a brute force attack:

Apr 19 14:13:02 FILESERVER Connection: User [some.admin] from [10.20.30.40] failed to sign in to [DSM] via [password] due to authorization failure.
Apr 19 14:13:03 FILESERVER Connection: User [some.admin] from [10.20.30.40] failed to sign in to [DSM] via [password] due to authorization failure.

Apr 19 14:13:04 FILESERVER Connection: User [some.admin] from [10.20.30.40] failed to sign in to [DSM] via [password] due to authorization failure.

Apr 19 14:13:05 FILESERVER Connection: User [some.admin] from [10.20.30.40] failed to sign in to [DSM] via [password] due to authorization failure.

Apr 19 14:13:06 FILESERVER Connection: User [some.admin] from [10.20.30.40] failed to sign in to [DSM] via [password] due to authorization failure.

Apr 19 14:13:07 FILESERVER Connection: User [some.admin] from [10.20.30.40] failed to sign in to [DSM] via [password] due to authorization failure.
Apr 19 14:13:20 FILESERVER Connection: User [some.admin] from [10.20.30.40] signed in to [DSM] successfully via [password].

I've also published the decoder and the ruleset (minus the successful brute force one we're discussing here) on github , if you want to have a look at the rest of the rules and the decoder, and also anyone if they find use for it!! :)

Regards

On Wed, May 15, 2024 at 1:09 PM Anthony Faruna <anthony...@wazuh.com> wrote:

Hello AltStorm

Thank you for your feedback and patience.

Please let me know why you want to put a timeframe of 2 minutes, considering the initial rule already indicates a potential brute-force attack.

Based on my understanding, triggering a rule based on the initial rule that detects the brute force attack is sufficient.

Please let me know if this helps.

Regards

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/79050f14-5c62-4c81-96c5-260d7b9b0219n%40googlegroups.com.