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. 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) >
