-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Review and improve the way the cloud modules send their output to the ossec.log #14535
Comments
Issue UpdateA meeting with the team has been set for 04/03 to discuss a common solution to standardize behavior throughout all modules. |
Issue Update.After reviewing with the team an epic based on this issue will be created. Next Step:
|
UpdateRebased the epic branch to 4.9.0, resolved conflicts and opened the pull request.
|
Update
|
UpdateRebased the epic branch to 4.9.0 after the changes in #16314, solved multiple conflicts and made some modifications to the said issue to accomodate with the new logging mechanism. |
Due to the changes planned for version 5.0, the analysis that is being carried out regarding the External integrations modules, and the current priorities, the team's efforts for improvements will be directed to the mentioned version, and for the |
Description
We should review and update the way we are capturing the output of our cloud modules (Azure, AWS y GCP) as well as the Docker-Listener module.
To better understand why this is necessary, first it is important to know how these modules are implemented. They are made of two different component:
The issue here is that the way the output is written and sent to the ossec.log is not consistent between modules. In addition to that, the output of the different modules will be ignored, even if there are warning or error messages, if the debug mode is not enabled, which is disabled by default.
Here is a detailed explanation on how every module works currently:
AWS
The python module runs and its output, which is written using
print
statements, is caught. However, for the output to be dumped to the ossec.log at least one of the following conditions must be met:1
the output will be written to ossec.log if theUnknown error
string was present.2
the output will be written to ossec.log if theaws.py: error:
string was present.3
or higher the output will be written to ossec.log as a WARNING, regardless of if it was an ERROR.0
or fails and returns a negative value the output will be written to the ossec.log only if debug mode is set to2
.GCP
The python module runs and its output, which is written using
logging
statements, is caught. However, for the output to be dumped to the ossec.log at least one of the following conditions must be met:This is done by looking for the
WARNING
,ERROR
,INFO
strings present in the output. If not present, the output is skipped.Azure
The azure module uses logging in a similar way to how the GCP was implemented. However, the C implementation is not expecting output from this module and it is not processing it, hence nothing will be written into the ossec.log at all. This is because the older implementation wrote its output directly to a custom file and now it is set to send it to the stdout but the core part must be updated to expect and catch this output.
Docker Listener
There is output written using
print
statements that will be shown only when running the module manually. The module sent his output to the analysis engine in the form of events.Proposed solution
We do not want to write directly on the
ossec.log
, as this task is the responsibility of modulesd, but we should keep the logic of determining when a message should be shown and when not depending on the debug level in the modules part. This logic currently already exists. The solution would be to just update the C part to just capture the output it receives as it is, without filtering it at all, and write it to the ossec.log.This solution involves updating the four modules as well as the core part and their unit testing.
Related Issues
Branch
The text was updated successfully, but these errors were encountered: