Fantastic! Thank you so much! Makes sense what you wrote about my suggested (mis)use of regex to try and get it start reading backwards. I should have realised that wildcard (*) was the way to go, without having to match the full string with the expressions available. I guess Jesus' recommendation not to use \. where alternatives are viable is due to performance? (Feel free to chime in Jesus :)) . Anyway, thanks alot. I learned a great deal from your suggestions, that should come in handy as write more decoders :)
/f 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.
