On Fri, Jul 27, 2012 at 3:37 PM, JamesH <[email protected]> wrote:
> Oh, that's disappointing. But, thank you kindly for looking into that for
> me.
> I didn't think to check the code, I just kept assuming i was doing something
> wrong.
>
> The documentation doesn't state anywhere that this feature is under
> construction. Something stating that might would be save some people from
> banging their heads.
>

The documentation minion will be flogged.

>
> On Tuesday, July 17, 2012 9:32:38 AM UTC-4, dan (ddpbsd) wrote:
>>
>> On Tue, Jul 17, 2012 at 9:16 AM, dan (ddp) <[email protected]> wrote:
>> > On Mon, Jul 16, 2012 at 5:15 PM, JamesH <[email protected]> wrote:
>> >> nullocks,
>> >> Did you ever get this to work? I'm having the same problem. "match_key"
>> >> will
>> >> work fine, but if I make it "match_key_value" and use check_value, I
>> >> get
>> >> nothin'.
>> >>
>> >>
>> >
>> > I can't get it to work either. match_key works fine, but adding the
>> > value doesn't seem to work for me.
>> >
>>
>> I'm not sure it's supposed to work now:
>>
>>         case LR_STRING_MATCH_VALUE:
>>             //debug1("LR_STRING_MATCH_VALUE");
>>             // XXX TODO
>>             return 0;
>>             break;
>>
>>
>> >
>> > <rule id="100088" level="7">
>> >   <if_sid>5715</if_sid>
>> >   <list field="user" lookup="match_key_value" check_value="banned"
>> >>lists/userlist.txt</list>
>> >   <description>Banned user</description>
>> > </rule>
>> >
>> > # grep ddpa /var/ossec/lists/banneduser.txt
>> > ddpa:banned
>> >
>> >
>> > # /var/ossec/bin/ossec-logtest
>> > 2012/07/17 09:16:14 ossec-testrule: INFO: Reading decoder file
>> > etc/decoder.xml.
>> > 2012/07/17 09:16:14 ossec-testrule: INFO: Reading decoder file
>> > etc/local_decoder.xml.
>> > 2012/07/17 09:16:14 ossec-testrule: INFO: Reading decoder file
>> > etc/wip/nsd_decoder.xml.
>> > 2012/07/17 09:16:14 ossec-testrule: INFO: Reading loading the lists
>> > file: 'lists/blocked.txt.cdb'
>> > 2012/07/17 09:16:14 ossec-testrule: INFO: Reading loading the lists
>> > file: 'lists/userlist.txt.cdb'
>> > 2012/07/17 09:16:14 ossec-testrule: INFO: Reading loading the lists
>> > file: 'lists/banneduser.txt.cdb'
>> > 2012/07/17 09:16:14 ossec-testrule: INFO: Started (pid: 17128).
>> > ossec-testrule: Type one log per line.
>> >
>> > Jul 17 05:00:09 ix sshd[6947]: Accepted publickey for ddpa from
>> > 192.168.17.17 port 16324 ssh2
>> >
>> >
>> > **Phase 1: Completed pre-decoding.
>> >        full event: 'Jul 17 05:00:09 ix sshd[6947]: Accepted publickey
>> > for ddpa from 192.168.17.17 port 16324 ssh2'
>> >        hostname: 'ix'
>> >        program_name: 'sshd'
>> >        log: 'Accepted publickey for ddpa from 192.168.17.17 port 16324
>> > ssh2'
>> >
>> > **Phase 2: Completed decoding.
>> >        decoder: 'sshd'
>> >        dstuser: 'ddpa'
>> >        srcip: '192.168.17.17'
>> >
>> > **Phase 3: Completed filtering (rules).
>> >        Rule id: '10100'
>> >        Level: '4'
>> >        Description: 'First time user logged in.'
>> > **Alert to be generated.
>> >
>> >
>> > Jul 17 05:00:09 ix sshd[6947]: Accepted publickey for ddpa from
>> > 192.168.17.17 port 16324 ssh2
>> >
>> >
>> > **Phase 1: Completed pre-decoding.
>> >        full event: 'Jul 17 05:00:09 ix sshd[6947]: Accepted publickey
>> > for ddpa from 192.168.17.17 port 16324 ssh2'
>> >        hostname: 'ix'
>> >        program_name: 'sshd'
>> >        log: 'Accepted publickey for ddpa from 192.168.17.17 port 16324
>> > ssh2'
>> >
>> > **Phase 2: Completed decoding.
>> >        decoder: 'sshd'
>> >        dstuser: 'ddpa'
>> >        srcip: '192.168.17.17'
>> >
>> > **Phase 3: Completed filtering (rules).
>> >        Rule id: '5715'
>> >        Level: '3'
>> >        Description: 'SSHD authentication success.'
>> > **Alert to be generated.
>> >
>> >
>> >> On Wednesday, October 27, 2010 9:22:48 AM UTC-4, nullocks wrote:
>> >>>
>> >>> Is anyone currently using the address_match_key_value CDB lookup? I am
>> >>> trying to use the following:
>> >>>
>> >>>  <rule id="110102" level="6">
>> >>>     <if_sid>110100</if_sid>
>> >>>     <list field="srcip" lookup="address_match_key_value"
>> >>> check_value="^sslvpn">lists/bcexclusions</list>
>> >>>     <description>Host in SSLVPN subnet is bypassing
>> >>> WebProxy</description>
>> >>>   </rule>
>> >>>
>> >>> In the list, I have:
>> >>> 10.17.1.:sslvpn
>> >>>
>> >>> And the log decodes:
>> >>>        decoder: 'pix'
>> >>>        id: '6-106100'
>> >>>        action: 'permitted'
>> >>>        proto: 'tcp'
>> >>>        srcip: '10.17.1.12'
>> >>>        srcport: '2175'
>> >>>        dstip: '66.235.138.59'
>> >>>        dstport: '80'
>> >>>
>> >>> So given all that, the lookup should run and generate an alert since
>> >>> the srcip from the log is in the list with a value of sslvpn. Or am I
>> >>> missing something?
>> >>>
>> >>>
>> >>> Brooks Garrett
>> >>> E: [email protected]
>> >>> P: 912.225.4097
>> >>> K: 0x13FC3821 (keyserver.ubuntu.com)

Reply via email to