Hi (again) Jesus! Big thanks for your time and effort! Greatly appreciated!
I tried your example below, to better understand why each decoder should have a prematch. I haven't quite figured out yet, but I see (obviously) that different results are produced. What would be a good prematch in my example? Just so I got that part right. Giving two sections the same <decoder-name>Checkpoint-alert</decoder> in essence means that it is one decoder, but defined in two sections? Your recommendation not to use \. where alternatives are viable is this due to performance, or implications coming with being too wide (as opposed to narrow) in matching a string? Best regards, Fredrik On Thursday, March 3, 2016 at 12:51:19 PM UTC+1, Jesus Linares wrote: > > Hi, > > I would add a *prematch *tag: > > <decoder name="Checkpoint-alert"> > <parent>Checkpoint</parent> > *<prematch>XXXXXXXX</prematch>* > <regex offset="after_parent">(\w+) \p\w+ \w+ > src:\s(\d+.\d+.\d+.\d+);\sdst:\s(\d+.\d+.\d+.\d+)</regex> > <order>action,srcip,dstip</order> > </decoder> > > <decoder name="Checkpoint-alert"> > <parent>Checkpoint</parent> > <regex offset="after_regex">\.*resource: (\.*);\.*product: (\.*); > </regex> > <order>url,extra_data</order> > </decoder> > > > Each decoder must have a *prematch* tag. Try this example without *prematch > *and see what happens. > > <!-- > Mar 3 12:15:24 LinMV TestDecoder[1963]: TypeA value1: hi; value2: bye; > value3: seeyou > Mar 3 12:15:24 LinMV TestDecoder[1963]: TypeB field1: hi; value2: bye; > value3: seeyou > --> > <decoder name="TestDecoder"> > <program_name>TestDecoder</program_name> > </decoder> > > > <decoder name="TestDecoder-1"> > <parent>TestDecoder</parent> > <prematch>TypeA</prematch> > <regex offset="after_parent">value1: hi; value2: (\S+)</regex> > <order>id</order> > </decoder> > > > <decoder name="TestDecoder-1"> > <parent>TestDecoder</parent> > <regex offset="after_regex">value3: (\S+)</regex> > <order>extra_data</order> > </decoder> > > > <decoder name="TestDecoder-2"> > <parent>TestDecoder</parent> > <prematch>TypeB</prematch> > <regex offset="after_parent">field1: hi; value2: (\S+)</regex> > <order>id</order> > </decoder> > > > Also, when it is possible, try to don't use the character "\.". Maybe you > can do it whit \S+. > > Regards, > Jesus Linares. > > On Thursday, March 3, 2016 at 10:05:16 AM UTC+1, Pedro S wrote: >> >> Hi Fredrik, >> >> I don't think OSSEC allow regex to work backwards, from end to beginning, >> I know that can be specify on other languages with some flags, but I am not >> sure if we can do that here. >> >> Regarding to your decoder, we have two options, include the extraction of >> "resource" and product" fields on the same decoder: >> >> FULL DECODER >> >> <decoder name="Checkpoint-alert"> >> <parent>Checkpoint</parent> >> <regex offset="after_parent">(\w+) \p\w+ \w+ >> src:\s(\d+.\d+.\d+.\d+);\sdst:\s(\d+.\d+.\d+.\d+)\.*resource: >> (\.*);\.*product: (\.*);</regex> >> <order>action,srcip,dstip,url,extra_data</order> >> </decoder> >> >> Or in a better way, separate the extraction in two different decoders, so >> we can be sure that in case of "resource" and "product" fields do not >> exists, our decoder still will parse and work. >> >> SPLIT DECODERS: >> >> <decoder name="Checkpoint-alert"> >> <parent>Checkpoint</parent> >> <regex offset="after_parent">(\w+) \p\w+ \w+ >> src:\s(\d+.\d+.\d+.\d+);\sdst:\s(\d+.\d+.\d+.\d+)</regex> >> <order>action,srcip,dstip</order> >> </decoder> >> >> >> <decoder name="Checkpoint-alert"> >> <parent>Checkpoint</parent> >> <regex offset="after_regex">\.*resource: (\.*);\.*product: (\.*); >> </regex> >> <order>url,extra_data</order> >> </decoder> >> >> >> >> LOGTEST OUTPUT >> **Phase 1: Completed pre-decoding. >> full event: 'Jan 27 09:41:01 127.0.0.1 Jan 27 9:32:28 >> st4600fw01n1 allow <eth1 mail src: 192.168.1.15; dst: 89.208.212.2; proto: >> tcp; appi_name: ******; app_desc: ******; app_id: 10063753; app_category: >> ******; matched_category: ******; app_properties: ******; app_risk: ******; >> app_rule_id: ******; app_rule_name: ******; web_client_type: Chrome; >> web_server_type: Microsoft-IIS; app_sig_id: 10063753:5; resource: >> http://www.aliveproxy.com/; proxy_src_ip: 192.168.1.15 product: >> Application Control; service: http; s_port: 58579; product_family: Network;' >> hostname: '127.0.0.1' >> program_name: '(null)' >> log: 'Jan 27 9:32:28 st4600fw01n1 allow <eth1 mail src: >> 192.168.1.15; dst: 89.208.212.2; proto: tcp; appi_name: ******; app_desc: >> ******; app_id: 10063753; app_category: ******; matched_category: ******; >> app_properties: ******; app_risk: ******; app_rule_id: ******; >> app_rule_name: ******; web_client_type: Chrome; web_server_type: >> Microsoft-IIS; app_sig_id: 10063753:5; resource: >> http://www.aliveproxy.com/; proxy_src_ip: 192.168.1.15 product: >> Application Control; service: http; s_port: 58579; product_family: Network;' >> >> >> **Phase 2: Completed decoding. >> decoder: 'Checkpoint' >> action: 'allow' >> srcip: '192.168.1.15' >> dstip: '89.208.212.2' >> * url* >> *: 'http://www.aliveproxy.com/ <http://www.aliveproxy.com/>' >> extra_data: 'Application Control'* >> >> >> **Phase 3: Completed filtering (rules). >> Rule id: '4100' >> Level: '0' >> Description: 'Firewall rules grouped.' >> >> >> In both decoders, I am using wildcards *.* *and expecting always " >> *resource*" before "*product*", either way won't work. >> >> You asked about using another "regex" line in the same decoder, it will >> work too, like this: >> >> <decoder name="Checkpoint-alert"> >> <parent>Checkpoint</parent> >> <regex offset="after_parent">(\w+) \p\w+ \w+ >> src:\s(\d+.\d+.\d+.\d+);\sdst:\s(\d+.\d+.\d+.\d+)</regex> >> *<regex>\.*resource: (\.*);\.*product: (\.*);</regex>* >> <order>action,srcip,dstip, url, extra_data</order> >> </decoder> >> >> >> >> Best regards, >> >> Pedro S. >> >> >> >> On Wednesday, March 2, 2016 at 11:03:08 AM UTC+1, Fredrik wrote: >>> >>> Hi All, >>> >>> >>> Came across this where I think I would be helped by extracting fields >>> both in forward (from beginning) and in reverse (from end) order of >>> messages!? Is this possible, if so, is it stupid given that there are other >>> (better) ways to accomplish the same thing :/ ? >>> >>> In addition to the fields my current decoder extracts, I was hoping to >>> extract the resource (http://www.aliveproxy.com/) and also the product >>> (Application >>> Control;). My idea was to add a secondary statement, before the <order> >>> statement, something in the lines of: >>> <regex>$/p\w+\s [...] and work my way backward so that I can extract >>> Application Control and resource . How would you suggest I do this?! >>> >>> Thanks again for all the great help - hope my threads (and questions) >>> can be useful for other newstarters outhere trying to get there feet off >>> the ground ;) >>> >>> Best regards, >>> Fredrik >>> >>> LOG-MESSAGE >>> >>> *Jan 27 09:41:01 127.0.0.1 Jan 27 9:32:28 st4600fw01n1 *allow <eth1 >>> mail src: 192.168.1.15; dst: 89.208.212.2; proto: tcp; appi_name: >>> ******; app_desc: ******; app_id: 10063753; app_category: ******; >>> matched_category: ******; app_properties: ******; app_risk: ******; >>> app_rule_id: ******; app_rule_name: ******; web_client_type: Chrome; >>> web_server_type: Microsoft-IIS; app_sig_id: 10063753:5; resource: http: >>> //www.aliveproxy.com/; proxy_src_ip: 192.168.1.15 product: Application >>> Control; service: http; s_port: 58579; product_family: Network; >>> >>> MY CURRENT DECODER >>> >>> <decoder name="Checkpoint"> >>> <prematch>^\w+ \d+ \d+:\d+:\d+ st4600fw01n\d</prematch> >>> <type>firewall</type> >>> </decoder> >>> >>> <decoder name="Checkpoint-alert"> >>> <parent>Checkpoint</parent> >>> <regex offset="after_parent">(\w+) \p\w+ \w+ >>> src:\s(\d+.\d+.\d+.\d+);\sdst:\s(\d+.\d+.\d+.\d+)</regex> >>> <order>action,srcip,dstip</order> >>> </decoder> >>> >>> LOGTEST OUTPUT >>> >>> >>> **Phase 1: Completed pre-decoding. >>> full event: 'Jan 27 09:41:01 127.0.0.1 Jan 27 9:32:28 >>> st4600fw01n1 allow <eth1 mail src: 192.168.1.15 dst: 89.208.212.2; proto: >>> tcp; appi_name: ******; app_desc: ******; app_id: 10063753; app_category: >>> ******; matched_category: ******; app_properties: ******; app_risk: ******; >>> app_rule_id: ******; app_rule_name: ******; web_client_type: Chrome; >>> web_server_type: Microsoft-IIS; app_sig_id: 10063753:5; resource: >>> http://www.aliveproxy.com/; proxy_src_ip: 192.168.1.15; product: >>> Application Control; service: http; s_port: 58579; product_family: Network;' >>> hostname: '127.0.0.1' >>> program_name: '(null)' >>> log: 'Jan 27 9:32:28 st4600fw01n1 allow <eth1 mail src: >>> 192.168.1.15; dst: 89.208.212.2; proto: tcp; appi_name: ******; app_desc: >>> ******; app_id: 10063753; app_category: ******; matched_category: ******; >>> app_properties: ******; app_risk: ******; app_rule_id: ******; >>> app_rule_name: ******; web_client_type: Chrome; web_server_type: >>> Microsoft-IIS; app_sig_id: 10063753:5; resource: >>> http://www.aliveproxy.com/; proxy_src_ip: 192.168.1.15; product: >>> Application Control; service: http; s_port: 58579; product_family: Network;' >>> >>> **Phase 2: Completed decoding. >>> decoder: 'Checkpoint' >>> action: 'allow' >>> srcip: '192.168.1.15' >>> dstip: '89.208.212.2' >>> >>> **Phase 3: Completed filtering (rules). >>> Rule id: '4100' >>> Level: '0' >>> Description: 'Firewall rules grouped.' >>> >>> -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
