Decoder and rules for Apache Wamp hosted web access logs

[M.Ali]

Hi everyone,

We host an internal website for our office branches on Apache. We forward the user access logs to wazuh by adding following configuration.

  <localfile>

    <log_format>syslog</log_format>

    <location>c:\wamp\www\logs\%y_%m_user_access.log</location>

  </localfile>

NOW, We want to view these logs and generate alert against user successful login, failed login, unauthorized login attempts and any changes made by user on web panel. For that we need Wazuh Decoders and Rules.

Some test log files are attached please help me for this. 

Thanks in advance.

Regards, 

M.ali

[Daniel Moreno]

Hello,

The default Wazuh ruleset doesn't have rules to handle Apache access logs yet.

However, custom rules and decoders may be created by looking at the logs. 

You may get further information about it in our documentation.

Please find attached to this post two files containing the rules and decoders you asked us.

These decoders have been created by using sibling decoders, you may find further information about it here.

You may notice that some of the rules have level 0 or 2, these rules won't generate an alert, they are used to trigger its child rules and generate an alert depending on the information decoded.

Don't hesitate to ask us again.

Regards.

[M.Ali]

Thank you very much. 

Now, I just have to upload these files or it need to copy it in costume rule file? 

[Daniel Moreno]

You may place them within the folders:

/var/ossec/etc/rules/
/var/ossec/etc/decoders/

You will need to restart the manager then and they will start to be applied to the incoming events.

Regards.

[M.Ali]

Hi @Daniel Moreno,

I copy the decoder and rules through Kibana no error appeared (restart the Wazuh) then check the agent ossec log also show no error about log file. then go to the website and try some failed attempts but no apache logs appeared on Kibana's discover tab.   

[Daniel Moreno]

Respuesta mail list:

Hello,

 

In order to ensure the events are reaching the manager, follow these steps:

1. Edit the manager's /var/ossec/etc/ossec.conf file and set the <logall_json> option to yes.

2. Restart the manager.

3. Execute the following command --> tailf /var/ossec/logs/archives/archives.json | grep "User login: successful"

4. Generate the events in the agent. In this case, login successfully against the apache server.

You should be able to see events showing up in the terminal where you executed the tailf command. Please set the <logall_json> option to no again to avoid storing every event coming from the agents.

 

In case the events are reaching the manager the rules and decoders aren't working as expected, is necessary to check out the events received and compare them against the decoders and rules.

 

In case the events aren't reaching the manager the agent is not properly configured. Please check you’ve set the <localfile> correctly and there are new events in the monitored file.

 

I hope it helps you.
Regards.

[Daniel Moreno]

Please don't pay attention to the first line.

It was a typo from my part.

Regards

[M.Ali]

Hello Daniel,

Thank you for the help.

I enable the <logall_json>.

Restart the manager and create some new logs and got the alerts it working now. thank you very much

[Daniel Moreno]

I'm glad to hear you got it working!

Keep in mind you probably want to disable the <logall_json> option at the end in order to avoid your server to get flooded by events.

You will continue getting the alerts with the option disabled.

Regards.

[M.Ali]

Thanks again, I set <logall_json>no</logall_json>now but I have a problem 

Rules alerts are taking too much time to appear on kibana any solution for that ?

they are taking more then an hour.

[M.Ali]

hi,

There are some problem with successful login alerts this rule is only picking admin account user logs.

Can you please help me to create some of following alerts :

1. Alert for brute force attack
2. User try to login from different IPs in a specific time period
3. Different User accounts try to login from same IP

Thanks in advance.

Regards,

M.Ali

[Daniel Moreno]

Hello,

Regarding the time taken to the alert to appear in Kibana, this issue may be related to:

1. High CPU load or memory consumption in the Wazuh manager’s machine. Please check out the CPU and memory usage to ensure your Wazuh manager can handle the number of events he is receiving. It is possible to reduce the load by using a Wazuh manager cluster. You may get further information about Wazuh manager clusters here.
   
2. High CPU load or memory consumption in the Elasticsearch’s machine. It is possible to either tune Elasticsearch to increase the indexing speed or create an Elasticsearch cluster to balance the load.
3. The inconsistent or slow connection between the Wazuh manager and the Elasticsearch. Please check there are no connection issues and the network you are using is not saturated.

Regarding the rules issues and new rules assistant:

The logs provided contain admin and test1 user logins and the rules work for them, so it is possible that different user names are not working as expected.

Please take a look at the logs containing the logins for the user that’s not working properly and adapt the decoders and rules to work for those cases.

It possible you will need to modify the following decoder:

<decoder name="apache-access-logs">
  <parent>apache-access-logs</parent>
  <regex>Username: "(\.*)"|[\d+](\w+) - </regex>
  <order>Username</order>
</decoder>

In case the username can contain a space you will need to change that decoder to:

<decoder name="apache-access-logs">
  <parent>apache-access-logs</parent>
  <regex>Username: "(\.*)"|[\d+](\.+) - </regex>
  <order>Username</order>
</decoder>

In case you have any questions while modifying them please ask us and we will assist you.

To alert on brute force attack you may use the frequency option, for example, the following rule:

  <rule id="100008" level="6" frequency="3" timeframe="10">
    <if_matched_sid>100003</if_matched_sid>
    <description>Brute force attack detected.</description>
  </rule>

Will get triggered if 3 unsuccessful login attempts are performed in ten seconds.

For creating the rules to alarm on different IPs and different user account with the same IP you will need to create new rules by using the frequency option and probably not_same_field and same_field options. You may get examples of how to use them here.

For example for the user login with different IP it could be used something like:

  <rule id="100009" level="6" frequency="2" timeframe="60">
    <if_matched_sid>100004</if_matched_sid>
    <same_field>Username</same_field>
    <not_same_field>server_ip</not_same_field>
    <description>different ip.</description>
  </rule>

It will alarm you when the same username has been used with two different IPs in sixty seconds.

I’ve noticed the field I called server_ip is probably the IP from the user so you probably want to rename it to srcip.

I hope it helps you, let us know if you need further assistant.

Regards.