Hi,
first, I would use the same format for both messages. Two options:
- Change log format in each device.
- Choose one:
- 1Mar2016 15:17:09 redirect st4600fw01n1
- Jan 27 09:41:01 127.0.0.1 Jan 27 9:32:28 st4600fw01n1
- This part could be your parent decoder (using regular expressions)
- Change the log received with rsyslog, for example, add a string:
- *MyFirewall *1Mar2016 15:17:09 redirect st4600fw01n1
- So, the parent decoder will be <prematch*>^**MyFirewall </prematch>*
The prematch of each sub-decoder (child decoder) could be the type of log,
maybe "web_client_type" or "mail".
What firewall are you using? Version?.
Paste here more logs.
Regards,
Jesus Linares
On Thursday, March 24, 2016 at 9:47:28 PM UTC+1, Fredrik wrote:
>
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
