Thanks for the replies guys, I really appreciate the help.

The reason I was trying the test decoder was because I am trying to
write a checkpoint NGX R65 decoder which works with my setup. For some
reason (rsyslog??, checkpoint syslog??) my syslog lines do not
identify "Checkpoint" as the program name so I have had to alter the
examples in the distribution. My "local_decoder.xml" contains the
following;

<decoder name="checkpoint-syslog">
  <prematch>^Checkpoint \d\d:\d\d:\d\d\s+</prematch>
</decoder>

<decoder name="checkpoint-syslog-fw">
  <parent>checkpoint-syslog</parent>
  <use_own_name>true</use_own_name>
  <prematch offset="after_parent">^drop|^accept|^reject</prematch>
  <regex offset="after_parent">^(\w+)\s+</regex>
  <regex>src: (\d+.\d+.\d+.\d+); dst: (\d+.\d+.\d+.\d+); proto: (\S
+);</regex>
  <order>action,srcip,dstip,protocol</order>
</decoder>

<decoder name="checkpoint-syslog-vpn">
  <parent>checkpoint-syslog</parent>
  <use_own_name>true</use_own_name>
  <prematch offset="after_parent">^encrypt|^decrypt</prematch>
  <regex offset="after_parent">^(\w+)\s+</regex>
  <regex>src: (\d+.\d+.\d+.\d+); dst: (\d+.\d+.\d+.\d+); proto: (\S
+);</regex>
  <order>action,srcip,dstip,protocol</order>
</decoder>


My "local_rules.xml" contains the following;

  <rule id="100103" level="1">
    <decoded_as>checkpoint-syslog</decoded_as>
    <description>Checkpoint rules grouped.</description>
  </rule>
  <rule id="100104" level="5">
    <decoded_as>checkpoint-syslog-fw</decoded_as>
    <action>drop</action>
    <description>Checkpoint drop event.</description>
  </rule>
  <rule id="100105" level="5">
    <decoded_as>checkpoint-syslog-fw</decoded_as>
    <action>accept</action>
    <description>Checkpoint accept event.</description>
  </rule>
  <rule id="100106" level="10" frequency="16" timeframe="45"
ignore="240">
    <if_matched_sid>100104</if_matched_sid>
    <same_source_ip />
    <description>Multiple Checkpoint drop events from same source.</
description>
    <group>multiple_drops,</group>
  </rule>
  <rule id="100107" level="5">
    <decoded_as>checkpoint-syslog-vpn</decoded_as>
    <action>encrypt</action>
    <description>Checkpoint encrypt VPN event.</description>
  </rule>
  <rule id="100108" level="5">
    <decoded_as>checkpoint-syslog-vpn</decoded_as>
    <action>decrypt</action>
    <description>Checkpoint decrypt VPN event.</description>
  </rule>


Finally, here are 4 example sanitised loglines which are
representative of what ossec will be seeing;

Sep 30 10:44:45 cp2 Checkpoint 10:44:43 drop   10.10.10.10 >Internal
rule: 21; rule_uid: {A62A7B21-8972-44D7-A152-16C6711C5486}; rule_name:
Cleanup Rule; SmartDefense profile: Default_Protection; src:
10.11.11.11; dst: 255.255.255.255; proto: udp; product: VPN-1 &
FireWall-1; service: 67; s_port: 68;

Sep 30 10:00:01 cp1 Checkpoint 10:00:01 accept 10.10.10.10 <Internal
session_id: 46081; dns_query: 192.168.0.198 ; dns_type: PTR;
SmartDefense profile: Default_Protection; service_id: domain-udp; src:
10.11.11.11; dst: 10.12.12.12; proto: udp; rule: 0; message_info:
Implied rule; product: VPN-1 & FireWall-1; service: 53; s_port: 52948;

Sep 30 10:42:37 cp1 Checkpoint 10:42:34 decrypt 10.10.10.10 >External
rule: 16; rule_uid: {E12E535B-9886-47DE-B0E7-504129D6DB7E}; rule_name:
Remote VPN; SmartDefense profile: Default_Protection; service_id:
https; src: 10.11.11.11; dst: 10.12.12.12; proto: tcp; xlatedst:
10.13.13.13; NAT_rulenum: 2; NAT_addtnl_rulenum: 0; scheme: IKE;
methods: ESP: 3DES + SHA1; peer gateway: 10.14.14.14; community:
RemoteAccess; user: CN=dummy,OU=users,O=blahblahblah; fw_subproduct:
VPN-1; vpn_feature_name: VPN; product: VPN-1 & FireWall-1; service:
443; s_port: 44771;

Sep 30 10:43:01 cp2 Checkpoint 10:42:59 encrypt 10.10.10.10 <External
SmartDefense profile: Default_Protection; service_id: tunnel_test;
src: 10.11.11.11; dst: 10.12.12.12; proto: udp; xlatesrc: 10.13.13.13;
NAT_rulenum: 0; NAT_addtnl_rulenum: 0; rule: 0; message_info: Implied
rule; scheme: IKE; methods: ESP: AES-128 + MD5; peer gateway:
10.14.14.14; community: customer1_VPN; fw_subproduct: VPN-1;
vpn_feature_name: VPN; product: VPN-1 & FireWall-1; service: 18234;
s_port: 53138; xlatesport: 26013;

Yet when I run logtest all the examples give the same result,

2009/09/30 11:38:55 ossec-testrule: INFO: Started (pid: 13332).
ossec-testrule: Type one log per line.

Sep 30 10:44:45 cp2 Checkpoint 10:44:43 drop   10.10.10.10 >Internal
rule: 21; rule_uid: {A62A7B21-8972-44D7-A152-16C6711C5486}; rule_name:
Cleanup Rule; SmartDefense profile: Default_Protection; src:
10.11.11.11; dst: 255.255.255.255; proto: udp; product: VPN-1 &
FireWall-1; service: 67; s_port: 68;


**Phase 1: Completed pre-decoding.
       full event: 'Sep 30 10:44:45 cp2 Checkpoint 10:44:43 drop
10.10.10.10 >Internal rule: 21; rule_uid: {A62A7B21-8972-44D7-
A152-16C6711C5486}; rule_name: Cleanup Rule; SmartDefense profile:
Default_Protection; src: 10.11.11.11; dst: 255.255.255.255; proto:
udp; product: VPN-1 & FireWall-1; service: 67; s_port: 68;'
       hostname: 'cp2'
       program_name: '(null)'
       log: 'Checkpoint 10:44:43 drop   10.10.10.10 >Internal rule:
21; rule_uid: {A62A7B21-8972-44D7-A152-16C6711C5486}; rule_name:
Cleanup Rule; SmartDefense profile: Default_Protection; src:
10.11.11.11; dst: 255.255.255.255; proto: udp; product: VPN-1 &
FireWall-1; service: 67; s_port: 68;'

**Phase 2: Completed decoding.
       decoder: 'checkpoint-syslog'

**Phase 3: Completed filtering (rules).
       Rule id: '100103'
       Level: '1'
       Description: 'Checkpoint rules grouped.'
**Alert to be generated.

Sep 30 10:00:01 cp1 Checkpoint 10:00:01 accept 10.10.10.10 <Internal
session_id: 46081; dns_query: 192.168.0.198 ; dns_type: PTR;
SmartDefense profile: Default_Protection; service_id: domain-udp; src:
10.11.11.11; dst: 10.12.12.12; proto: udp; rule: 0; message_info:
Implied rule; product: VPN-1 & FireWall-1; service: 53; s_port: 52948;


**Phase 1: Completed pre-decoding.
       full event: 'Sep 30 10:00:01 cp1 Checkpoint 10:00:01 accept
10.10.10.10 <Internal session_id: 46081; dns_query: 192.168.0.198 ;
dns_type: PTR; SmartDefense profile: Default_Protection; service_id:
domain-udp; src: 10.11.11.11; dst: 10.12.12.12; proto: udp; rule: 0;
message_info: Implied rule; product: VPN-1 & FireWall-1; service: 53;
s_port: 52948;'
       hostname: 'cp1'
       program_name: '(null)'
       log: 'Checkpoint 10:00:01 accept 10.10.10.10 <Internal
session_id: 46081; dns_query: 192.168.0.198 ; dns_type: PTR;
SmartDefense profile: Default_Protection; service_id: domain-udp; src:
10.11.11.11; dst: 10.12.12.12; proto: udp; rule: 0; message_info:
Implied rule; product: VPN-1 & FireWall-1; service: 53; s_port:
52948;'

**Phase 2: Completed decoding.
       decoder: 'checkpoint-syslog'

**Phase 3: Completed filtering (rules).
       Rule id: '100103'
       Level: '1'
       Description: 'Checkpoint rules grouped.'
**Alert to be generated.

Sep 30 10:42:37 cp1 Checkpoint 10:42:34 decrypt 10.10.10.10 >External
rule: 16; rule_uid: {E12E535B-9886-47DE-B0E7-504129D6DB7E}; rule_name:
Remote VPN; SmartDefense profile: Default_Protection; service_id:
https; src: 10.11.11.11; dst: 10.12.12.12; proto: tcp; xlatedst:
10.13.13.13; NAT_rulenum: 2; NAT_addtnl_rulenum: 0; scheme: IKE;
methods: ESP: 3DES + SHA1; peer gateway: 10.14.14.14; community:
RemoteAccess; user: CN=dummy,OU=users,O=blahblahblah; fw_subproduct:
VPN-1; vpn_feature_name: VPN; product: VPN-1 & FireWall-1; service:
443; s_port: 44771;


**Phase 1: Completed pre-decoding.
       full event: 'Sep 30 10:42:37 cp1 Checkpoint 10:42:34 decrypt
10.10.10.10 >External rule: 16; rule_uid: {E12E535B-9886-47DE-
B0E7-504129D6DB7E}; rule_name: Remote VPN; SmartDefense profile:
Default_Protection; service_id: https; src: 10.11.11.11; dst:
10.12.12.12; proto: tcp; xlatedst: 10.13.13.13; NAT_rulenum: 2;
NAT_addtnl_rulenum: 0; scheme: IKE; methods: ESP: 3DES + SHA1; peer
gateway: 10.14.14.14; community: RemoteAccess; user:
CN=dummy,OU=users,O=blahblahblah; fw_subproduct: VPN-1;
vpn_feature_name: VPN; product: VPN-1 & FireWall-1; service: 443;
s_port: 44771;'
       hostname: 'cp1'
       program_name: '(null)'
       log: 'Checkpoint 10:42:34 decrypt 10.10.10.10 >External rule:
16; rule_uid: {E12E535B-9886-47DE-B0E7-504129D6DB7E}; rule_name:
Remote VPN; SmartDefense profile: Default_Protection; service_id:
https; src: 10.11.11.11; dst: 10.12.12.12; proto: tcp; xlatedst:
10.13.13.13; NAT_rulenum: 2; NAT_addtnl_rulenum: 0; scheme: IKE;
methods: ESP: 3DES + SHA1; peer gateway: 10.14.14.14; community:
RemoteAccess; user: CN=dummy,OU=users,O=blahblahblah; fw_subproduct:
VPN-1; vpn_feature_name: VPN; product: VPN-1 & FireWall-1; service:
443; s_port: 44771;'

**Phase 2: Completed decoding.
       decoder: 'checkpoint-syslog'

**Phase 3: Completed filtering (rules).
       Rule id: '100103'
       Level: '1'
       Description: 'Checkpoint rules grouped.'
**Alert to be generated.

Sep 30 10:43:01 cp2 Checkpoint 10:42:59 encrypt 10.10.10.10 <External
SmartDefense profile: Default_Protection; service_id: tunnel_test;
src: 10.11.11.11; dst: 10.12.12.12; proto: udp; xlatesrc: 10.13.13.13;
NAT_rulenum: 0; NAT_addtnl_rulenum: 0; rule: 0; message_info: Implied
rule; scheme: IKE; methods: ESP: AES-128 + MD5; peer gateway:
10.14.14.14; community: customer1_VPN; fw_subproduct: VPN-1;
vpn_feature_name: VPN; product: VPN-1 & FireWall-1; service: 18234;
s_port: 53138; xlatesport: 26013;


**Phase 1: Completed pre-decoding.
       full event: 'Sep 30 10:43:01 cp2 Checkpoint 10:42:59 encrypt
10.10.10.10 <External SmartDefense profile: Default_Protection;
service_id: tunnel_test; src: 10.11.11.11; dst: 10.12.12.12; proto:
udp; xlatesrc: 10.13.13.13; NAT_rulenum: 0; NAT_addtnl_rulenum: 0;
rule: 0; message_info: Implied rule; scheme: IKE; methods: ESP:
AES-128 + MD5; peer gateway: 10.14.14.14; community: customer1_VPN;
fw_subproduct: VPN-1; vpn_feature_name: VPN; product: VPN-1 &
FireWall-1; service: 18234; s_port: 53138; xlatesport: 26013;'
       hostname: 'cp2'
       program_name: '(null)'
       log: 'Checkpoint 10:42:59 encrypt 10.10.10.10 <External
SmartDefense profile: Default_Protection; service_id: tunnel_test;
src: 10.11.11.11; dst: 10.12.12.12; proto: udp; xlatesrc: 10.13.13.13;
NAT_rulenum: 0; NAT_addtnl_rulenum: 0; rule: 0; message_info: Implied
rule; scheme: IKE; methods: ESP: AES-128 + MD5; peer gateway:
10.14.14.14; community: customer1_VPN; fw_subproduct: VPN-1;
vpn_feature_name: VPN; product: VPN-1 & FireWall-1; service: 18234;
s_port: 53138; xlatesport: 26013;'

**Phase 2: Completed decoding.
       decoder: 'checkpoint-syslog'

**Phase 3: Completed filtering (rules).
       Rule id: '100103'
       Level: '1'
       Description: 'Checkpoint rules grouped.'
**Alert to be generated.

Can anybody shed any light on this?

TIA and sorry for the long post.

Cheers,

Dan.




On 29 Sep, 21:17, Daniel Cid <[email protected]> wrote:
> The <use_own_name> will just update the pointer internally to be used
> by the rules,
> but the name will not show up on ossec-logtest...  I will make sure to fix it.
>
> Thanks,
>
> --
> Daniel B. Cid
> dcid ( at ) ossec.net
>
> On Tue, Sep 29, 2009 at 2:57 PM, ddp <[email protected]> wrote:
>
> > Summary: On my setup the ossec-logtest application does not show the
> > child decoder's name either.
> > To me this would appear to be an omission in the logtest program, but
> > I can't say for sure. Maybe a "child decoder" entry could be added to
> > the output.
>
> > Ramble: It appears that using the <use_own_name> option will allow
> > rules to fire on the child decoder's name. In my quick tests, I was
> > able to get the <extra_data> information in my test child decoder
> > through logtest, but it still appeared under the parent decoder's
> > name.
> > I was also able to write rules with the name of the child decoder
> > (again using the use_own_name) option, including using the extra_data
> > information. Without the use_own_name option these rules did not work.
>
> > On Tue, Sep 29, 2009 at 8:50 AM, dthfoo <[email protected]> wrote:
>
> >> Hey!
>
> >> I am trying to write a custom decoder for our checkpoint logs and am
> >> running into difficulty trying to get parent->child decoders working.
>
> >> I have ended up writing a test decoder as follows;
>
> >> <decoder name="test-syslog">
> >>  <prematch>^test</prematch>
> >> </decoder>
>
> >> <decoder name="test-syslog-remainder">
> >>  <parent>test-syslog</parent>
> >>  <use_own_name>true</use_own_name>
> >>  <prematch offset="after_parent">\.*</prematch>
> >> </decoder>
>
> >> Then I used "logtest" to test the following 2 inputs;
> >> "test"
> >> "test test"
>
> >> I expected that the first input would be matched to the parent decoder
> >> and the second input to the child. Instead I get the following;
>
> >> 2009/09/29 13:41:55 ossec-testrule: INFO: Started (pid: 31027).
> >> ossec-testrule: Type one log per line.
>
> >> test
>
> >> **Phase 1: Completed pre-decoding.
> >>       full event: 'test'
> >>       hostname: 'plukinfra1'
> >>       program_name: '(null)'
> >>       log: 'test'
>
> >> **Phase 2: Completed decoding.
> >>       decoder: 'test-syslog'
> >> test test
>
> >> **Phase 1: Completed pre-decoding.
> >>       full event: 'test test'
> >>       hostname: 'plukinfra1'
> >>       program_name: '(null)'
> >>       log: 'test test'
>
> >> **Phase 2: Completed decoding.
> >>       decoder: 'test-syslog'
>
> >> Is my thinking faulty or does the problem lie somewhere else?
>
> >> Cheers,
>
> >> Dan.

Reply via email to