Imperva logs
Alvaro Victoriano
Eva Lopez
Hello Alvaro,
As my colleague said in the previous messages there are a few rules and decoders to Imperva but not match with CEF format.
I have been reading a little bit about Imperva logs. The log files seem to have two parts, a header, and log events. I think you sent us the header instead of logs.
You can read more about it in the Imperva documentation: Logfile structure
https://docs.imperva.com/bundle/cloud-application-security/page/more/log-file-structure.htm
In addition, the log examples are shown in the link you sent seem to contain one line. If I’m right a decoder as follow can be useful for you:
<decoder name="imperva-dec">
<prematch>CEF:0|Incapsula|SIEMintegration</prematch>
</decoder>
<decoder name="imperva-dec-child">
<parent>imperva-dec</parent>
<regex>fileid=(\d+)</regex>
<order>fileid</order>
</decoder>
<decoder name="imperva-dec-child">
<parent>imperva-dec</parent>
<regex>sourceServiceName=(\S+)</regex>
<order>sourceServiceName</order>
</decoder>
<decoder name="imperva-dec-child">
<parent>imperva-dec</parent>
<regex>siteid=(\d+)</regex>
<order>siteid</order>
</decoder>
<decoder name="imperva-dec-child">
<parent>imperva-dec</parent>
<regex>suid=(\d+)</regex>
<order>suid</order>
</decoder>
And Logtest’s output should be as follow:
root@lopezziur:/var/ossec# bin/ossec-logtest
2020/03/03 10:08:03 ossec-testrule: INFO: Started (pid: 8976).
ossec-testrule: Type one log per line.
CEF:0|Incapsula|SIEMintegration|1|1|Illegal Resource Access|3| fileid=3412341160002518171 sourceServiceName=site123.abcd.info siteid=1509732 suid=50005477 requestClientApplication=Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 deviceFacility=mia cs2=true cs2Label=Javascript Support cs3=true cs3Label=CO Support ccode=IL tag=www.elvis.com cn1=200 in=54 xff=44.44.44.44 cs1=NOT_SUPPORTED cs1Label=Cap Support cs4=c2e72124-0e8a-4dd8-b13b-3da246af3ab2 cs4Label=VID cs5=de3c633ac428e0678f3aac20cf7f239431e54cbb8a17e8302f53653923305e1835a9cd871db32aa4fc7b8a9463366cc4 cs5Label=clappsig dproc=Browser cs6=Firefox cs6Label=clapp ccode=IL cicode=Rehovot cs7=31.8969 cs7Label=latitude cs8=34.8186 cs8Label=longitude Customer=CEFcustomer123 start=1453290121336 request=site123.abcd.info/ requestmethod=GET qstr=p\=%2fetc%2fpasswd app=HTTP act=REQ_CHALLENGE_CAPTCHA deviceExternalID=33411452762204224 cpt=443 src=12.12.12.12 ver=TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 end=1566300670892 additionalReqHeaders=[{"Accept":"*/*"},{"x-v":"1"},{"x-fapi-interaction-id":"10.10.10.10"}] additionalResHeaders=[{"Content-Type":"text/html; charset\=UTF-8"}] filetype=30037,1001, filepermission=2,1, cs9=Block Malicious User,High Risk Resources, cs9Label=Rule name cs11=,,[{"api_specification_violation_type":"INVALID_PARAM_NAME","parameter_name":"somename"}] cs11Label=Rule Additional Info
**Phase 1: Completed pre-decoding.
full event: 'CEF:0|Incapsula|SIEMintegration|1|1|Illegal Resource Access|3| fileid=3412341160002518171 sourceServiceName=site123.abcd.info siteid=1509732 suid=50005477 requestClientApplication=Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 deviceFacility=mia cs2=true cs2Label=Javascript Support cs3=true cs3Label=CO Support ccode=IL tag=www.elvis.com cn1=200 in=54 xff=44.44.44.44 cs1=NOT_SUPPORTED cs1Label=Cap Support cs4=c2e72124-0e8a-4dd8-b13b-3da246af3ab2 cs4Label=VID cs5=de3c633ac428e0678f3aac20cf7f239431e54cbb8a17e8302f53653923305e1835a9cd871db32aa4fc7b8a9463366cc4 cs5Label=clappsig dproc=Browser cs6=Firefox cs6Label=clapp ccode=IL cicode=Rehovot cs7=31.8969 cs7Label=latitude cs8=34.8186 cs8Label=longitude Customer=CEFcustomer123 start=1453290121336 request=site123.abcd.info/ requestmethod=GET qstr=p\=%2fetc%2fpasswd app=HTTP act=REQ_CHALLENGE_CAPTCHA deviceExternalID=33411452762204224 cpt=443 src=12.12.12.12 ver=TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 end=1566300670892 additionalReqHeaders=[{"Accept":"*/*"},{"x-v":"1"},{"x-fapi-interaction-id":"10.10.10.10"}] additionalResHeaders=[{"Content-Type":"text/html; charset\=UTF-8"}] filetype=30037,1001, filepermission=2,1, cs9=Block Malicious User,High Risk Resources, cs9Label=Rule name cs11=,,[{"api_specification_violation_type":"INVALID_PARAM_NAME","parameter_name":"somename"}] cs11Label=Rule Additional Info'
timestamp: '(null)'
hostname: 'lopezziur'
program_name: '(null)'
log: 'CEF:0|Incapsula|SIEMintegration|1|1|Illegal Resource Access|3| fileid=3412341160002518171 sourceServiceName=site123.abcd.info siteid=1509732 suid=50005477 requestClientApplication=Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 deviceFacility=mia cs2=true cs2Label=Javascript Support cs3=true cs3Label=CO Support ccode=IL tag=www.elvis.com cn1=200 in=54 xff=44.44.44.44 cs1=NOT_SUPPORTED cs1Label=Cap Support cs4=c2e72124-0e8a-4dd8-b13b-3da246af3ab2 cs4Label=VID cs5=de3c633ac428e0678f3aac20cf7f239431e54cbb8a17e8302f53653923305e1835a9cd871db32aa4fc7b8a9463366cc4 cs5Label=clappsig dproc=Browser cs6=Firefox cs6Label=clapp ccode=IL cicode=Rehovot cs7=31.8969 cs7Label=latitude cs8=34.8186 cs8Label=longitude Customer=CEFcustomer123 start=1453290121336 request=site123.abcd.info/ requestmethod=GET qstr=p\=%2fetc%2fpasswd app=HTTP act=REQ_CHALLENGE_CAPTCHA deviceExternalID=33411452762204224 cpt=443 src=12.12.12.12 ver=TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 end=1566300670892 additionalReqHeaders=[{"Accept":"*/*"},{"x-v":"1"},{"x-fapi-interaction-id":"10.10.10.10"}] additionalResHeaders=[{"Content-Type":"text/html; charset\=UTF-8"}] filetype=30037,1001, filepermission=2,1, cs9=Block Malicious User,High Risk Resources, cs9Label=Rule name cs11=,,[{"api_specification_violation_type":"INVALID_PARAM_NAME","parameter_name":"somename"}] cs11Label=Rule Additional Info'
**Phase 2: Completed decoding.
decoder: 'imperva-dec'
fileid: '3412341160002518171'
sourceServiceName: 'site123.abcd.info'
siteid: '1509732'
suid: '50005477'
If I’m wrong and it isn’t possible to know the log’s lines. Create rules and decoders to them will be difficult.
Could you send me an Imperva log file?
Best regards,
Eva
Eva Lopez
Hello Alvaro,
The correct configuration to monitor this file is:
<localfile>
<log_format>syslog</log_format>
<location>path_to_imperva/*.log</location>
</localfile>
Note there is only one log per line (and there are two logs).
Logcollector searches new files in the Imperva directory every 64 seconds, reads them, and positions the file descriptor to the end. Logs that appear after it will be reported.
I think Imperva writes its logs before Wazuh reads the files. It causes Wazuh doesn’t report logs.
To check it, you can enable the logall option in ossec.conf.
logall option lets Analysisd write all logs it processes in /var/ossec/log/archives/archives.log
If I am right, you won’t see any Imperva log there.
You can change the Logcollector internal configuration to try to solve it. You can decrease the time of logcollector.vcheck_files
Follow the link to read more about it: Logcollector internal configuration
Please, confirm if I am right for research this use case for next develops.
Best regards,
Eva
Alvaro Victoriano
Hello Eva,You are completely right, I did the test and didnt appear any alert.After 24 hours of yesterday configurations, I could see the alerts.Today, I edited, logcollector.vcheck_files=(0-30), and I couldnt see the alerts in real time, even when i rest the configurations to the default also i didtn recieve alerts, i dont know what is the idea of recieveing the alerts before two days, and it lates a lot.
Eva Lopez
Hello Alvaro,
You are welcome!
I am glad I was helpful.
Regarding your question about decoders, if Logcollector catches this header, Analysisd treats these lines, and you can create decoders for them.
The issue is the lines must be processed individually, you will obtain one alert per line. If you decide to obtain header as one log using a multi-line format, Logcollector won’t treat Imperva logs correctly. Remember that it’s the header file, and there is one line per log after string |==|.
If you decide to process header per line, I think rules and decoders as the following may work:
<decoder name="imperva-accountId">
<prematch>accountId:</prematch>
<regex>accountId:(\d+)</regex>
<order>accountId</order>
</decoder>
<decoder name="imperva-configId">
<prematch>configId:</prematch>
<regex>configId:(\d+)</regex>
<order>configId</order>
</decoder>
<decoder name="imperva-checksum">
<prematch>checksum:</prematch>
<regex>checksum:(\S+)</regex>
<order>checksum</order>
</decoder>
<group name="Imperva,">
<rule id="100000" level="3">
<decoded_as>imperva-accountId</decoded_as>
<description>New Imperva file with accountId: $(accountId)</description>
</rule>
<rule id="100001" level="3">
<decoded_as>imperva-configId</decoded_as>
<description>New Imperva file with configId: $(configId)</description>
</rule>
<rule id="100002" level="3">
<decoded_as>imperva-checksum</decoded_as>
<description>New Imperva file with checksum: $(checksum)</description>
</rule>
</group>
I hope it helps you.
Best regards,
Eva
Eva Lopez
Hello again!
I forgot to mention we have an issue in Github which explain your use case.
Wazuh may lose some Imperva logs.
It has been reported by some users. We will enhance Logcollector as soon as possible.
Greetings,
Eva
Eva Lopez
I am glad I was useful.
Regards,
Eva