wazuh-ruleset
wazuh-ruleset copied to clipboard
wazuh
correction on 0380-windows_decoders.xml, the parsing of the GET and POST methods of the IIS
in the line. 94, where have:
we have to make:
the parsing before, is the problem
Received From: (agent) 1.2.3.4->\Logs\W3SVC2\u_ex200530.log Rule: 31151 fired (level 10) -> "Multiple web server 400 error codes from same source ip." Src IP: 1.2.3.4 Portion of the log(s):
2020-05-30 22:33:20 1.2.3.4 GET /url/ - 80 url/url 1.2.3.4 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+Zoom+3.6.0) http://server/url/url466 200 0 0 38 user_agent: Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+Zoom+3.6.0)
Hello @r4phl
Thank you for your input. It seems the decoder didn't parser well your log. It is expected id field is equal to 200 but 466 is received, right?
**Phase 2: Completed decoding.
decoder: 'windows-date-format'
action: 'GET'
url: '/url/ -'
srcport: '80'
srcip: '1.2.3.4'
user_agent: 'Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+Zoom+3.6.0)'
id: '466'
**Phase 3: Completed filtering (rules).
Rule id: '31101'
Level: '5'
Description: 'Web server 400 error code.'
**Alert to be generated.
We can modify the line 94 as you explained but logs from other versions can be affected as IIS 7.5:
2015-07-28 15:07:26 1.2.3.4 GET /QOsa/Browser/Default.aspx UISessionId=SN1234123&DeviceId=SN12312232SHARP+MX-4111N 80 - 31.3.3.7 OpenSystems/1.0;+product-family="85";+product-version="123ER123" 302 0 0 624
However, a first idea could be to join the two options:
<regex offset="after_parent">^\S+ (\w+) (\S+ \S+) (\S+) \S+ (\S+) (\S+) \.* (\d\d\d) |^\S+ (\w+) (\S+ \S+) (\S+) \S+ (\S+) (\S+) \.*(\d\d\d) </regex>
I will investigate more about that.
If you need to modify the decoder, you can follow the steps registered in the documentation.
Regards, Daniel
Don't worry, I have already modified it, and it turned out well, although I would like to know your opinion.
to let it leave it as I have modified it.
El mar., 9 de jun. de 2020 a la(s) 05:12, Daniel Melgarejo ( [email protected]) escribió:
Hello @r4phl https://github.com/r4phl
Thank you for your input. It seems the decoder didn't parser well your log. It is expected id field is equal to 200 but 466 is received, right?
**Phase 2: Completed decoding. decoder: 'windows-date-format' action: 'GET' url: '/url/ -' srcport: '80' srcip: '1.2.3.4' srcgeoip: 'RU' user_agent: 'Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+Zoom+3.6.0)' id: '466'
**Phase 3: Completed filtering (rules). Rule id: '31101' Level: '5' Description: 'Web server 400 error code.' **Alert to be generated.
We can modify the line 94 as you explained but logs from other versions can be affected as IIS 7.5:
2015-07-28 15:07:26 1.2.3.4 GET /QOsa/Browser/Default.aspx UISessionId=SN1234123&DeviceId=SN12312232SHARP+MX-4111N 80 - 31.3.3.7 OpenSystems/1.0;+product-family="85";+product-version="123ER123" 302 0 0 624
However, a first idea could be to join the two options:
^\S+ (\w+) (\S+ \S+) (\S+) \S+ (\S+) (\S+) .* (\d\d\d) |^\S+ (\w+) (\S+ \S+) (\S+) \S+ (\S+) (\S+) .*(\d\d\d) I will investigate more about that.
If you need to modify the decoder, you can follow the steps registered in the documentation https://documentation.wazuh.com/current/user-manual/ruleset/custom.html#changing-an-existing-decoder .
Regards, Daniel
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wazuh/wazuh-ruleset/issues/688#issuecomment-641188055, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTGBRZHPSYQS5VD5K6ZMIDRVYDIXANCNFSM4NPJJJJQ .
thx
El mar., 9 de jun. de 2020 a la(s) 08:20, Rafael Antonio Rodriguez Otero ( [email protected]) escribió:
Don't worry, I have already modified it, and it turned out well, although I would like to know your opinion.
to let it leave it as I have modified it.
El mar., 9 de jun. de 2020 a la(s) 05:12, Daniel Melgarejo ( [email protected]) escribió:
Hello @r4phl https://github.com/r4phl
Thank you for your input. It seems the decoder didn't parser well your log. It is expected id field is equal to 200 but 466 is received, right?
**Phase 2: Completed decoding. decoder: 'windows-date-format' action: 'GET' url: '/url/ -' srcport: '80' srcip: '1.2.3.4' srcgeoip: 'RU' user_agent: 'Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+Zoom+3.6.0)' id: '466'
**Phase 3: Completed filtering (rules). Rule id: '31101' Level: '5' Description: 'Web server 400 error code.' **Alert to be generated.
We can modify the line 94 as you explained but logs from other versions can be affected as IIS 7.5:
2015-07-28 15:07:26 1.2.3.4 GET /QOsa/Browser/Default.aspx UISessionId=SN1234123&DeviceId=SN12312232SHARP+MX-4111N 80 - 31.3.3.7 OpenSystems/1.0;+product-family="85";+product-version="123ER123" 302 0 0 624
However, a first idea could be to join the two options:
^\S+ (\w+) (\S+ \S+) (\S+) \S+ (\S+) (\S+) .* (\d\d\d) |^\S+ (\w+) (\S+ \S+) (\S+) \S+ (\S+) (\S+) .*(\d\d\d) I will investigate more about that.
If you need to modify the decoder, you can follow the steps registered in the documentation https://documentation.wazuh.com/current/user-manual/ruleset/custom.html#changing-an-existing-decoder .
Regards, Daniel
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wazuh/wazuh-ruleset/issues/688#issuecomment-641188055, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTGBRZHPSYQS5VD5K6ZMIDRVYDIXANCNFSM4NPJJJJQ .
The version of IIS that I have works well for me with this decoder, I just wanted to be taken into account. really thank you very much.
El mar., 9 de jun. de 2020 a la(s) 08:20, Rafael Antonio Rodriguez Otero ( [email protected]) escribió:
thx
El mar., 9 de jun. de 2020 a la(s) 08:20, Rafael Antonio Rodriguez Otero ( [email protected]) escribió:
Don't worry, I have already modified it, and it turned out well, although I would like to know your opinion.
to let it leave it as I have modified it.
El mar., 9 de jun. de 2020 a la(s) 05:12, Daniel Melgarejo ( [email protected]) escribió:
Hello @r4phl https://github.com/r4phl
Thank you for your input. It seems the decoder didn't parser well your log. It is expected id field is equal to 200 but 466 is received, right?
**Phase 2: Completed decoding. decoder: 'windows-date-format' action: 'GET' url: '/url/ -' srcport: '80' srcip: '1.2.3.4' srcgeoip: 'RU' user_agent: 'Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+Zoom+3.6.0)' id: '466'
**Phase 3: Completed filtering (rules). Rule id: '31101' Level: '5' Description: 'Web server 400 error code.' **Alert to be generated.
We can modify the line 94 as you explained but logs from other versions can be affected as IIS 7.5:
2015-07-28 15:07:26 1.2.3.4 GET /QOsa/Browser/Default.aspx UISessionId=SN1234123&DeviceId=SN12312232SHARP+MX-4111N 80 - 31.3.3.7 OpenSystems/1.0;+product-family="85";+product-version="123ER123" 302 0 0 624
However, a first idea could be to join the two options:
^\S+ (\w+) (\S+ \S+) (\S+) \S+ (\S+) (\S+) .* (\d\d\d) |^\S+ (\w+) (\S+ \S+) (\S+) \S+ (\S+) (\S+) .*(\d\d\d) I will investigate more about that.
If you need to modify the decoder, you can follow the steps registered in the documentation https://documentation.wazuh.com/current/user-manual/ruleset/custom.html#changing-an-existing-decoder .
Regards, Daniel
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wazuh/wazuh-ruleset/issues/688#issuecomment-641188055, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTGBRZHPSYQS5VD5K6ZMIDRVYDIXANCNFSM4NPJJJJQ .
Hello, look, how can I contribute to you with a more relevant improvement? I don't know if I'm wrong, but I understand that this application cannot detect DDoS. this is correct?
El mar., 9 de jun. de 2020 a la(s) 08:29, Rafael Antonio Rodriguez Otero ( [email protected]) escribió:
The version of IIS that I have works well for me with this decoder, I just wanted to be taken into account. really thank you very much.
El mar., 9 de jun. de 2020 a la(s) 08:20, Rafael Antonio Rodriguez Otero ( [email protected]) escribió:
thx
El mar., 9 de jun. de 2020 a la(s) 08:20, Rafael Antonio Rodriguez Otero ( [email protected]) escribió:
Don't worry, I have already modified it, and it turned out well, although I would like to know your opinion.
to let it leave it as I have modified it.
El mar., 9 de jun. de 2020 a la(s) 05:12, Daniel Melgarejo ( [email protected]) escribió:
Hello @r4phl https://github.com/r4phl
Thank you for your input. It seems the decoder didn't parser well your log. It is expected id field is equal to 200 but 466 is received, right?
**Phase 2: Completed decoding. decoder: 'windows-date-format' action: 'GET' url: '/url/ -' srcport: '80' srcip: '1.2.3.4' srcgeoip: 'RU' user_agent: 'Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+Zoom+3.6.0)' id: '466'
**Phase 3: Completed filtering (rules). Rule id: '31101' Level: '5' Description: 'Web server 400 error code.' **Alert to be generated.
We can modify the line 94 as you explained but logs from other versions can be affected as IIS 7.5:
2015-07-28 15:07:26 1.2.3.4 GET /QOsa/Browser/Default.aspx UISessionId=SN1234123&DeviceId=SN12312232SHARP+MX-4111N 80 - 31.3.3.7 OpenSystems/1.0;+product-family="85";+product-version="123ER123" 302 0 0 624
However, a first idea could be to join the two options:
^\S+ (\w+) (\S+ \S+) (\S+) \S+ (\S+) (\S+) .* (\d\d\d) |^\S+ (\w+) (\S+ \S+) (\S+) \S+ (\S+) (\S+) .*(\d\d\d) I will investigate more about that.
If you need to modify the decoder, you can follow the steps registered in the documentation https://documentation.wazuh.com/current/user-manual/ruleset/custom.html#changing-an-existing-decoder .
Regards, Daniel
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wazuh/wazuh-ruleset/issues/688#issuecomment-641188055, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTGBRZHPSYQS5VD5K6ZMIDRVYDIXANCNFSM4NPJJJJQ .
Hello,
The most common way of contributing consists in cloning or forking the repository, creating a new branch, make the desired changes and submit a pull request.
You can find our open source public projects here. If you want to contribute to any of our projects please don't hesitate to send a pull request.
Most of our open-source public projects have a CONTRIBUTING file. For more details about how to contribute to a specific Wazuh project take a look at it.
If I am not wrong, there is nothing configured for this in Wazuh. This does not mean that we cannot configure certain options to interpret this type of attack and act if possible.
well, i was thinking of using a mix of various things to solve this problem, wazuh agent or wazuh server has to be improved, somehow it has to be integrated with fail2ban or iptables skills, to detect by time and amount of events these time of attacks. I was thinking of a simple solution, with fail2ban, on the wazuh server.
1.) fail2ban is installed on wazuh server 2.) The log archive.log is activated 3.) create a rule in fail2ban to read the logs from /var/ossec/log/archives/archive.log. 4.) An exit with fail2ban is created to send a signal to the server logs. 5.) A decoder and a rule are created to send the notification.
Note, in the fail2ban rule process, you must preserve the data where the attack comes from, which is the name of the agents that will perform the logs.
That may be a method to solve the problem, do you think it is viable?
El mar., 9 de jun. de 2020 a la(s) 10:55, Daniel Melgarejo ( [email protected]) escribió:
Hello,
The most common way of contributing consists in cloning or forking the repository, creating a new branch, make the desired changes and submit a pull request.
You can find our open source public projects here https://github.com/wazuh/. If you want to contribute to any of our projects please don't hesitate to send a pull request.
Most of our open-source public projects have a CONTRIBUTING file. For more details about how to contribute to a specific Wazuh project take a look at it.
If I am not wrong, there is nothing configured for this in Wazuh. This does not mean that we cannot configure certain options to interpret this type of attack and act if possible.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wazuh/wazuh-ruleset/issues/688#issuecomment-641397054, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTGBRYSMH7QMVYRY77UAPLRVZLO5ANCNFSM4NPJJJJQ .
sorry if my english is not very good. I'm using google translator.
This could also be done in the agents, it would be more efficient. somehow integrate iptables skills with agents.
El mar., 9 de jun. de 2020 a la(s) 11:09, Rafael Antonio Rodriguez Otero ( [email protected]) escribió:
well, i was thinking of using a mix of various things to solve this problem, wazuh agent or wazuh server has to be improved, somehow it has to be integrated with fail2ban or iptables skills, to detect by time and amount of events these time of attacks. I was thinking of a simple solution, with fail2ban, on the wazuh server.
1.) fail2ban is installed on wazuh server 2.) The log archive.log is activated 3.) create a rule in fail2ban to read the logs from /var/ossec/log/archives/archive.log. 4.) An exit with fail2ban is created to send a signal to the server logs. 5.) A decoder and a rule are created to send the notification.
Note, in the fail2ban rule process, you must preserve the data where the attack comes from, which is the name of the agents that will perform the logs.
That may be a method to solve the problem, do you think it is viable?
El mar., 9 de jun. de 2020 a la(s) 10:55, Daniel Melgarejo ( [email protected]) escribió:
Hello,
The most common way of contributing consists in cloning or forking the repository, creating a new branch, make the desired changes and submit a pull request.
You can find our open source public projects here https://github.com/wazuh/. If you want to contribute to any of our projects please don't hesitate to send a pull request.
Most of our open-source public projects have a CONTRIBUTING file. For more details about how to contribute to a specific Wazuh project take a look at it.
If I am not wrong, there is nothing configured for this in Wazuh. This does not mean that we cannot configure certain options to interpret this type of attack and act if possible.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wazuh/wazuh-ruleset/issues/688#issuecomment-641397054, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTGBRYSMH7QMVYRY77UAPLRVZLO5ANCNFSM4NPJJJJQ .
Hello,
Thank you for the information. It seems fail2ban is a good tool for that type of attack.
Wazuh can be configured to work similarly. For example, an Apache webserver obtains logs of each request. We could create a rule that detects if an event recorded by the Apache webserver (a request) happens repeatedly. For that, we can use the options frequency and timeframe. For example:
<rule id="100002" level="10" frequency="50" timeframe="120">
...
...
</rule>
If the rule is matched, a script can be executed automatically using Active response to block the ports/network.
The fail2ban tool may be faster or more efficient but Wazuh can be a good alternative. Nevertheless, we will take your information into account.
Hello, really thank you very much for the information.
I am going to do some tests with the rule you gave me, and I will tell you my results, this has not really been solved, another thing to take into account is that these methods to solve the detection of DDoS by GET, POST methods, or what that is, they are only originated by the service logs, for example, access.log error.log, but what happens with SYN DDoS Attacks? or ACK DDoS Attacks? Those attacks will not be detected by the agent, or is there some way to achieve it? May I suggest using the "iptables" capabilities to mess with the agent, there are rules to detect these events by iptables.
https://juncotic.com/ddos-mitigando-denegacion-iptables/
I would believe that somehow iptables achieves this by its libraries, or application programming, it can be used for these same purposes, not to block, but to notify, really thank you very much for answering emails. Regards.
El mié., 10 de jun. de 2020 a la(s) 06:30, Daniel Melgarejo ( [email protected]) escribió:
Hello,
Thank you for the information. It seems fail2ban is a good tool for that type of attack.
Wazuh can be configured to work similarly. For example, an Apache webserver obtains logs of each request. We could create a rule that detects if an event recorded by the Apache webserver (a request) happens repeatedly. For that, we can use the options frequency and timeframe https://documentation.wazuh.com/3.12/user-manual/ruleset/ruleset-xml-syntax/rules.html#rule. For example:
... ... If the rule is matched, a script can be executed automatically using Active response https://documentation.wazuh.com/current/user-manual/capabilities/active-response/ to block the ports/network.
The fail2ban tool may be faster or more efficient but Wazuh can be a good alternative. Nevertheless, we will take your information into account.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wazuh/wazuh-ruleset/issues/688#issuecomment-641941015, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTGBR4N4E6XIO5TWGCDE53RV5VDXANCNFSM4NPJJJJQ .
to solve SYN or ACK attack problem? By DDoS, in linux I could solve it, installing iptables on the server, create these rules and send a log to a file, when the SYN or ACK event is generated in DDoS, create a decoder and a rule, and it could be observed, but When it is in windows, I don't know how to solve it. because i can't install iptables in windows and perform the same operation.
Well really, the iptables counterpart, I don't think I will perform this operation, but it would be spectacular to solve it.
El mié., 10 de jun. de 2020 a la(s) 08:56, Rafael Antonio Rodriguez Otero ( [email protected]) escribió:
Hello, really thank you very much for the information.
I am going to do some tests with the rule you gave me, and I will tell you my results, this has not really been solved, another thing to take into account is that these methods to solve the detection of DDoS by GET, POST methods, or what that is, they are only originated by the service logs, for example, access.log error.log, but what happens with SYN DDoS Attacks? or ACK DDoS Attacks? Those attacks will not be detected by the agent, or is there some way to achieve it? May I suggest using the "iptables" capabilities to mess with the agent, there are rules to detect these events by iptables.
https://juncotic.com/ddos-mitigando-denegacion-iptables/
I would believe that somehow iptables achieves this by its libraries, or application programming, it can be used for these same purposes, not to block, but to notify, really thank you very much for answering emails. Regards.
El mié., 10 de jun. de 2020 a la(s) 06:30, Daniel Melgarejo ( [email protected]) escribió:
Hello,
Thank you for the information. It seems fail2ban is a good tool for that type of attack.
Wazuh can be configured to work similarly. For example, an Apache webserver obtains logs of each request. We could create a rule that detects if an event recorded by the Apache webserver (a request) happens repeatedly. For that, we can use the options frequency and timeframe https://documentation.wazuh.com/3.12/user-manual/ruleset/ruleset-xml-syntax/rules.html#rule. For example:
... ... If the rule is matched, a script can be executed automatically using Active response https://documentation.wazuh.com/current/user-manual/capabilities/active-response/ to block the ports/network.
The fail2ban tool may be faster or more efficient but Wazuh can be a good alternative. Nevertheless, we will take your information into account.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wazuh/wazuh-ruleset/issues/688#issuecomment-641941015, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTGBR4N4E6XIO5TWGCDE53RV5VDXANCNFSM4NPJJJJQ .
Hello,
Effectively, those attacks are related to the network and Wazuh is not able to monitor it but there are some tools to detect threats on the network as Suricata does.
Suricata is one such NIDS solution, which is open source and can be quickly deployed either on dedicated hardware for monitoring one or more transit points on your network, or directly on existing Unix-like hosts to monitor just their own network traffic. Because Suricata is capable of generating JSON logs of NIDS events, it integrates beautifully with Wazuh.
Maybe Suricata and Wazuh can detect SYN/ACK DDoS attacks. Example of configuration: https://documentation.wazuh.com/3.12/learning-wazuh/suricata.html
The option to use iptables is very interesting and it is very possible it can work well. Maybe it can be used with scheduling remote commands for Wazuh agents. There is a tutorial that explains more about it: https://wazuh.com/blog/scheduling-remote-commands-for-wazuh-agents/
Yes, Windows has that inconvenience. Maybe there is another way to monitor in that OS.
Regards, Daniel
Hello, I wanted to know one last thing, since you are a reliable source of project information, in compliance with wazuh it has the NIST 800-53, this version is updated to the NIST version 800-53 r4 ???
El jue., 11 de jun. de 2020 a la(s) 06:50, Daniel Melgarejo ( [email protected]) escribió:
Hello,
Effectively, those attacks are related to the network and Wazuh is not able to monitor it but there are some tools to detect threats on the network as Suricata does.
Suricata is one such NIDS solution, which is open source and can be quickly deployed either on dedicated hardware for monitoring one or more transit points on your network, or directly on existing Unix-like hosts to monitor just their own network traffic. Because Suricata is capable of generating JSON logs of NIDS events, it integrates beautifully with Wazuh.
Maybe Suricata and Wazuh can detect SYN/ACK DDoS attacks. Example of configuration: https://documentation.wazuh.com/3.12/learning-wazuh/suricata.html
The option to use iptables is very interesting and it is very possible it can work well. Maybe it can be used with scheduling remote commands for Wazuh agents. There is a tutorial that explains more about it: https://wazuh.com/blog/scheduling-remote-commands-for-wazuh-agents/
Yes, Windows has that inconvenience. Maybe there is another way to monitor in that OS.
Regards, Daniel
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wazuh/wazuh-ruleset/issues/688#issuecomment-642592805, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTGBR34JND4CKQ2BOSWTR3RWDAH7ANCNFSM4NPJJJJQ .