splunk / splunk-connect-for-syslog

Splunk Connect for Syslog
Apache License 2.0
152 stars 107 forks source link

Barracuda WAF issue #2091

Closed Mosstrow closed 1 year ago

Mosstrow commented 1 year ago

Hello Team,

The parsing solved here is not working: https://github.com/splunk/splunk-connect-for-syslog/issues/1689

The parsing is based on "waf-den" but this is the hostname of the appliance. Here is another payload: <134>Jul 5 14:24:53 LB01 2023-07-05 14:24:53.329 +0200 LB01 TR 4.4.4.4 443 8.8.8.8 21504 "-" "-" GET TLSv1.2 google.com HTTP/1.1 200 1275 431 SERVER DEFAULT PROTECTED VALID /themes/theme/js/javascript.js 8.8.8.8 21504 2

Could you please fix this ?

Thanks

Mosstrow commented 1 year ago

I've just had a closer look and according to the addon, "TR" is linked to sourcetype barracuda:web and "WF" to sourcetype barracuda:waf

By forcing the sourcetype "barracuda:web" all fields are well extracted

Addon: https://splunkbase.splunk.com/app/3776

[force_sourcetype_barracuda_waf]
DEST_KEY = MetaData:Sourcetype
REGEX = WF\s[A-Z]{4}
FORMAT = sourcetype::barracuda:waf

[force_sourcetype_barracuda_web]
DEST_KEY = MetaData:Sourcetype
REGEX = TR\s(?:\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})
FORMAT = sourcetype::barracuda:web
rjha-splunk commented 1 year ago

Great , kindly explain what help is expected from sc4s side?

Mosstrow commented 1 year ago

Hi Rjha,

Can you create the parsing of this log source by setting the sourcetype "barracuda:web" ?

Thanks

Mosstrow commented 1 year ago

Here is another payload but for sourcetype "barracuda:waf" <129>Jul 5 16:01:36 LB01 2023-07-05 16:01:36.992 +0200 LBC01 WF ALER CROSS_SITE_SCRIPTING_IN_URL 8.8.8.8 4163 4.4.4.4 443 DENY NONE [type\="cross-site-scripting-strict" pattern\="opening-html-tag" token\="%3cscript%3e"] GET google.com/%3Cscript%3Ealert(1)%3C/script%3E TLSv1.2 8.8.8.8 4163

mstopa-splunk commented 1 year ago

hi @Mosstrow thank you for reporting this bug. I noticed that there are doubled timestamps and hosts in your samples: Jul 5 16:01:36 LB01 2023-07-05 16:01:36.992 +0200 LBC01 instead of 2023-07-05 16:01:36.992 +0200 LBC01. I would rather fix the parser to process formats like in the docs: https://campus.barracuda.com/product/webapplicationfirewall/doc/92767349/exporting-log-formats/

Mosstrow commented 1 year ago

Hi @mstopa-splunk

Indeed, our logs did not correspond to what was in the doc concerning duplicate timestamp and hostname while we were using the default format and each parameter %t %un %lt... are identical to those in the documentation. I tried to remove %t %un and now we don't have duplicate anymore but the timestamp is still not in the correct format <129>Jul 28 11:38:16 LBC01 WF ...

I'll ask an upgrade of the device but you can already push the new parsing

Thank you very much

mstopa-splunk commented 1 year ago

Hi @Mosstrow after this push "<134>2023-07-05 14:24:53.329 +0200 LB01 TR 4.4.4.4 443 8.8.8.8 21504 "-" "-" GET TLSv1.2 google.com HTTP/1.1 200 1275 431 SERVER DEFAULT PROTECTED VALID /themes/theme/js/javascript.js 8.8.8.8 21504 2" is now properly parsed as barracuda:web and <129>2023-07-05 16:01:36.992 +0200 LBC01 WF ALER CROSS_SITE_SCRIPTING_IN_URL 8.8.8.8 4163 4.4.4.4 443 DENY NONE [type\="cross-si te-scripting-strict" pattern\="opening-html-tag" token\="%3cscript%3e"] GET google.com/% 3Cscript%3Ealert(1)%3C/script%3E TLSv1.2 8.8.8.8 4163 as barracuda:waf, please let us know in case of any further issues.