Hi Jesus,
Got sidetracked with other projects, and finally getting back to my questions about handling different messages from the same device (firewall). Also, Jesus your suggestion about placing a prematch in the suggested decoder in this thread - what would be a good prematch here? Should I add an OR to the parent decoder to do the first match and then use different subdecoders to extract the useful information from the other type of message? How do you deal with these type of scenarios? 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? Please find the two message-types below for reference. MESSAGE1: 1Mar2016 15:17:09 redirect st4600fw01n1 <eth1 alert web_client_type: Chrome; resource: http://sc1.checkpoint.com/za/images/threatwiki/pages/TestAntiBotBlade.html; src: 192.168.1.15; dst: 23.8.4.103; proto: tcp; session_id: {0x56d5a2de,0x4,0xc50d2e0a,0xc0000001}; Protection name: Check Point - Testing Bot; malware_family: Check Point; Source OS: Windows; Confidence Level: 5; severity: 2; malware_action: Communication with C&C site; rule_uid: {9AF67731-0D35-4117-AF2B-9A47F9396D26}; Protection Type: URL reputation; malware_rule_id: {000000CE-00A4-0046-9658-621EA5468654}; protection_id: 00233CFEE; log_id: 2; proxy_src_ip: 192.168.1.15; scope: 10.46.5.133; product: Anti Malware; service: http; s_port: 61834; MESSAGE2: 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; On Monday, March 7, 2016 at 12:11:21 PM UTC+1, Jesus Linares wrote: > Hi Fredrik, > > The expression "\.+" matches for anything. Usually, it is not a good idea > because is slow and maybe you capture something that you don't want. So, > *when > it is possible*, it is better to use something specific. > > When you have different decoders (different name) with the same parent, > you should use a prematch. If you don't use prematch, it is fired the first > rule. In the previous example: > > Log: > Mar 3 12:15:24 LinMV TestDecoder[1963]: TypeB field1: hi; value2: bye; > value3: seeyou > > Without prematch: > **Phase 2: Completed decoding. > decoder: 'TestDecoder' > extra_data: 'seeyou' > > With prematch: > **Phase 2: Completed decoding. > decoder: 'TestDecoder' > id: 'bye;' > > > Without prematch, the decoder is TestDecoder-1, but it should be > TestDecoder2 (because it has the string "field1". In my view, it is a good > practice use prematch, but sometimes it is no necessary. > > Regarding your last question, could you use the same log format in your > firewall and in the blade?. Paste here two logs of each one (firewall and > blade) and your decoders, and we will take a look ;) > > Regards. > Jesus Linares > > On Friday, March 4, 2016 at 9:08:34 PM UTC+1, Fredrik wrote: >> >> Hi All, >> >> >> In this context and with your great response. What would you PROs suggest >> I do when decoding another type of message from the same firewall - but a >> different blade (i.e. module). Turns out that the messages look somewhat >> different. This is a sample from the other module and it won't match with >> the current decoder. Should I add an OR to the parent decoder to do the >> first match and then use different subdecoders to extract the useful >> information from the other type of message? How do you deal with these type >> of scenarios? >> >> MESSAGE: >> 1Mar2016 15:17:09 redirect st4600fw01n1 <eth1 alert web_client_type: >> Chrome; resource: http:// >> sc1.checkpoint.com/za/images/threatwiki/pages/TestAntiBotBlade.html; >> src: 192.168.1.15; dst: 23.8.4.103; proto: tcp; session_id: >> {0x56d5a2de,0x4,0xc50d2e0a,0xc0000001}; Protection name: Check Point - >> Testing Bot; malware_family: Check Point; Source OS: Windows; Confidence >> Level: 5; severity: 2; malware_action: Communication with C&C site; >> rule_uid: {9AF67731-0D35-4117-AF2B-9A47F9396D26}; Protection Type: URL >> reputation; malware_rule_id: {000000CE-00A4-0046-9658-621EA5468654}; >> protection_id: 00233CFEE; log_id: 2; proxy_src_ip: 192.168.1.15; scope: >> 10.46.5.133; product: Anti Malware; service: http; s_port: 61834; >> >> Best regards, >> Fredrik >> >> >> 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.
