I call this "not dead yet." They're in the source repository, and will
be included in the next release. ;)
https://bitbucket.org/dcid/ossec-hids/src/43e8b41a8195/etc/rules/sshd_rules.xml

On Thu, Mar 3, 2011 at 5:59 PM, jplee3 <[email protected]> wrote:
> Really? Were those two new rules that were introduced? I don't see
> them when I grep for them in all files under the rules dir.
>
> Just in case I added a "0" after the 5 :)
>
> On Mar 3, 2:27 pm, "dan (ddp)" <[email protected]> wrote:
>> Be careful using rule IDs in OSSEC ranges. 5722 and 5723 are already
>> being used. ;)
>>
>> On Thu, Mar 3, 2011 at 5:06 PM, jplee3 <[email protected]> wrote:
>> > Whitelisting the scanner doesn't solve the problem, because someone
>> > else might inadvertently scan one system and cause AR to fire on a
>> > completely different system where it shouldn't have fired.
>>
>> > I basically just want AR to fire for a specific group of machines
>> > whenever a certain alert gets tripped on only those machines.
>>
>> > I think I figured it out either way though. This appears to do the
>> > job:
>>
>> >  <rule id="5722" level="5">
>> >    <if_sid>5710</if_sid>
>> >    <hostname>ssh1|ssh2<hostname>
>> >    <match>illegal user|invalid user</match>
>> >    <description>Attempt to login using a non-existent user</
>> > description>
>> >    <group>invalid_login,authentication_failed,</group>
>> >  </rule>
>>
>> >  <rule id="5723" level="10" frequency="10" timeframe="120">
>> >    <if_matched_sid>5722</if_matched_sid>
>> >    <description>SSHD brute force trying to get access to </
>> > description>
>> >    <description>the system.</description>
>> >    <same_source_ip />
>> >    <group>authentication_failures,</group>
>> >  </rule>
>>
>> > On Mar 3, 1:32 pm, satish patel <[email protected]> wrote:
>> >> I'd say use whitelist.  and add your scannser IP in whitelist
>>
>> >> I have same issue and and i guess that is only option we have.
>>
>> >> On Thu, Mar 3, 2011 at 4:21 PM, jplee3 <[email protected]> wrote:
>> >> > Hey guys,
>>
>> >> > So I noticed this while running an internal Nessus scan on the
>> >> > network. Apparently AR kicked in because certain rules fired (5712 to
>> >> > be exact) which are not host-specific and ended up null-routing the
>> >> > Nessus scanner machine on the defined-agents I have setup for AR.
>>
>> >> > Anyway, I just came across this 
>> >> > -http://www.ossec.net/wiki/Know_How:Ignore_Rules
>>
>> >> > Can I add multiple hostnames delimited by "," or "|" so that the rules
>> >> > (and subsequently the ARs) will fire only on the hosts of origin?
>>
>> >> > I would use "local" but I want AR to occur on a subset of my agents
>> >> > (not all of them).
>>
>> >> > Unless there's another way to do this.
>>
>> >> > Any ideas?
>>
>>

Reply via email to