-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Checkpoint Syslog Filebeat module #17682
Conversation
Pinging @elastic/siem (Team:SIEM) |
… conditional statement in pipeline to make it safer
This PR makes some changes to CEF module's custom mappings for Check Point devices to ensure compatibility with the upcoming checkpoint module. Check Point has its custom log format, for which a new module is being prepared. The idea behind this new module as well as CEF custom mappings for Check Point (this PR), is to use ECS whenever possible and map the rest under checkpoint.* using the original field name from Check Point. In the original PR for CEF, a few mistakes had been done in field names and types. Also taking the opportunity to change some ECS mappings. Related #16907 #17682
This PR makes some changes to CEF module's custom mappings for Check Point devices to ensure compatibility with the upcoming checkpoint module. Check Point has its custom log format, for which a new module is being prepared. The idea behind this new module as well as CEF custom mappings for Check Point (this PR), is to use ECS whenever possible and map the rest under checkpoint.* using the original field name from Check Point. In the original PR for CEF, a few mistakes had been done in field names and types. Also taking the opportunity to change some ECS mappings. Related elastic#16907 elastic#17682 (cherry picked from commit 4f6da4f)
This PR makes some changes to CEF module's custom mappings for Check Point devices to ensure compatibility with the upcoming checkpoint module. Check Point has its custom log format, for which a new module is being prepared. The idea behind this new module as well as CEF custom mappings for Check Point (this PR), is to use ECS whenever possible and map the rest under checkpoint.* using the original field name from Check Point. In the original PR for CEF, a few mistakes had been done in field names and types. Also taking the opportunity to change some ECS mappings. Related elastic#16907 elastic#17682 (cherry picked from commit 4f6da4f)
) This PR makes some changes to CEF module's custom mappings for Check Point devices to ensure compatibility with the upcoming checkpoint module. Check Point has its custom log format, for which a new module is being prepared. The idea behind this new module as well as CEF custom mappings for Check Point (this PR), is to use ECS whenever possible and map the rest under checkpoint.* using the original field name from Check Point. In the original PR for CEF, a few mistakes had been done in field names and types. Also taking the opportunity to change some ECS mappings. Related #16907 #17682 (cherry picked from commit 4f6da4f)
) This PR makes some changes to CEF module's custom mappings for Check Point devices to ensure compatibility with the upcoming checkpoint module. Check Point has its custom log format, for which a new module is being prepared. The idea behind this new module as well as CEF custom mappings for Check Point (this PR), is to use ECS whenever possible and map the rest under checkpoint.* using the original field name from Check Point. In the original PR for CEF, a few mistakes had been done in field names and types. Also taking the opportunity to change some ECS mappings. Related #16907 #17682 (cherry picked from commit 4f6da4f)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking really good. I've got a couple of suggestions for increased use of ECS.
- The related.ip, related.hash & related.user fields should be populated.
- event.category, any chance we can figure out when malware & intrusion_detection could be added?
- event.type in-line comments on allowed & denied could we also use sequence number for start?
All changes from comments has been applied, new expected.json generated, and nosetest has been run again. |
Co-Authored-By: Andrew Kroh <andrew.kroh@elastic.co>
…kpoint-module Adding changes from remote branch to Changelog
Added updated documentation changes as per @andrewkroh comments. Documentation from CEF to checkpoint module will be done in a separate PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. @leehinman do you want to take another look?
{ | ||
"@timestamp": "2020-03-29T13:19:20Z", | ||
"checkpoint.sys_message": ":\"The eth0 interface is not protected by the anti-spoofing feature. Your network may be at risk", | ||
"event.category": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like the format for checkpoint.sys_message is different than the rest during errors and alerts, will add a fix for this.
The issue is because that specific field has a weird value, this is the raw event coming directly from the device:
sys_message::"The eth0 interface is not protected by the anti-spoofing feature. Your network may be at risk"]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was commenting that it's good to see event.category as an array!
…a to ensure both correct and incorrect format is working
I have added a workaround for this issue, as its not in the parser itself but rather a bug on the Checkpoint side. I have updated the dataset to have at least 1 properly formatted and 1 incorrectly formatted message, to ensure the parser works for both. Re-ran nosetests afterwards. |
@P1llus really awesome to see this PR! |
This adds a CheckPoint Filebeat module. The difference between this module and the CEF checkpoint module is that this is utilizing the syslog output format instead of CEF. This syslog output format supports a much larger set of fields from Checkpoint. (cherry picked from commit afc3a49)
This adds a CheckPoint Filebeat module. The difference between this module and the CEF checkpoint module is that this is utilizing the syslog output format instead of CEF. This syslog output format supports a much larger set of fields from Checkpoint. (cherry picked from commit afc3a49) Co-authored-by: Marius Iversen <marius.iversen@elastic.co>
@P1llus / @tonymeehan : This seems to not include any - module: checkpoint
access:
input:
- type: syslog
protocol.tcp:
host: "0.0.0.0:8001"
tls:
..... |
… (elastic#17712) This PR makes some changes to CEF module's custom mappings for Check Point devices to ensure compatibility with the upcoming checkpoint module. Check Point has its custom log format, for which a new module is being prepared. The idea behind this new module as well as CEF custom mappings for Check Point (this PR), is to use ECS whenever possible and map the rest under checkpoint.* using the original field name from Check Point. In the original PR for CEF, a few mistakes had been done in field names and types. Also taking the opportunity to change some ECS mappings. Related elastic#16907 elastic#17682 (cherry picked from commit ddb92ca)
What does this PR do?
This PR adds checkpoint filebeat module.
The difference between this module and the CEF checkpoint module is that this is utilizing the syslog output format instead of CEF.
This output format supports a much larger set of fields from Checkpoint.
This is a collaboration work with @adriansr .
Why is it important?
Adding more supported products to the filebeat portfolio.
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Closes #16041
Nosetests run successfully:
INTEGRATION_TESTS=1 BEAT_STRICT_PERMS=false TESTING_FILEBEAT_MODULES=checkpoint nosetests -v -s tests/system/test_xpack_modules.py