giannidaprile/wip-ossec-rules

Automatically exported from code.google.com/p/wip-ossec-rules

wip-ossec-rules's Issues

There are extra <group> tags in some of the sshd rules

  <rule id="5732" level="2">      <if_sid>5700</if_sid>      <match>error: connect_to </match>      <description>Possible port forwarding failure.</description>      <group>sshd,</group>    </rule>      <rule id="5733" level="2">      <if_sid>5700</if_sid>      <match>Invalid credentials</match>      <description>User entered incorrect password.</description>      <group>sshd,ldap,pam,authentication_failures,</group>    </rule>      <rule id="5734" level="1">      <if_sid>5700</if_sid>      <match>Could not load host key</match>      <description>sshd could not load one or more host keys.</description>      <info>This may be related to an upgrade to OpenSSH.</info>      <group>sshd,sysadmin,</group>    </rule>      <rule id="5735" level="2">      <if_sid>5700</if_sid>      <match>Write failed: Broken pipe</match>      <description>Failed write due to one host disappearing.</description>      <group>sshd,</group>    </rule>  

Original issue reported on code.google.com by [email protected] on 23 Oct 2010 at 1:17

Remove rules/local_rules.xml

This isn't needed since it's default, and the risk of overwriting someone's 
local_rules.xml is too big.

Original issue reported on code.google.com by [email protected] on 19 Oct 2010 at 6:56

the ftpd-mac-failure decoder has a funny regex

<!-- Modifications from blacklight [email protected] -->  
<decoder name="ftpd-mac-failure">
    <parent>ftpd</parent>
    <prematch>^Failed authentication from: \S+ |</prematch>
    <prematch>^repeated login failures from </prematch>
    <regex offset="after_prematch">(\S+)</regex>
    <order>srcip</order>
</decoder>

There are a few different possibilities for logs. Searching google for examples 
of different formats, and I should have something by the end of the week.

Attached is a txt file of samples found so far. Putting it here for (hopefully) 
easier access.

Original issue reported on code.google.com by [email protected] on 1 Nov 2010 at 7:45

Attachments:

• samples.txt

Portsentry support - completely untested

Nov  1 19:28:58 testserver portsentry[1620]: adminalert: Going into
listen mode on UDP port: 31337
Nov  1 19:28:58 testserver portsentry[1620]: adminalert: Going into
listen mode on UDP port: 54321
Nov  1 19:28:58 testserver portsentry[1620]: adminalert: PortSentry is
now active and listening.
Nov  1 19:31:33 testserver portsentry[1616]: attackalert: Connect from
host: 192.168.45.1/192.168.45.1 to TCP port: 1
Nov  1 19:31:33 testserver portsentry[1616]: attackalert: Ignoring TCP
response per configuration file setting.
Nov  1 19:31:33 testserver portsentry[1616]: attackalert: Connect from
host: 192.168.45.1/192.168.45.1 to TCP port: 79
Nov  1 19:31:33 testserver portsentry[1616]: attackalert: Host:
192.168.45.1 is already blocked. Ignoring
Nov  1 19:31:33 testserver portsentry[1616]: attackalert: Connect from
host: 192.168.45.1/192.168.45.1 to TCP port: 111
Nov  1 19:31:33 testserver portsentry[1616]: attackalert: Host:
192.168.45.1 is already blocked. Ignoring
Nov  1 19:31:33 testserver portsentry[1616]: attackalert: Connect from
host: 192.168.45.1/192.168.45.1 to TCP port: 119
Nov  1 19:31:33 testserver portsentry[1616]: attackalert: Host:
192.168.45.1 is already blocked. Ignoring
Nov  1 19:31:33 testserver portsentry[1616]: attackalert: Connect from
host: 192.168.45.1/192.168.45.1 to TCP port: 143
Nov  1 19:31:33 testserver portsentry[1616]: attackalert: Host:
192.168.45.1 is already blocked. Ignoring
Nov  1 19:31:33 testserver portsentry[1616]: attackalert: Connect from
host: 192.168.45.1/192.168.45.1 to TCP port: 1080



<decoder name="portsentry">
 <program_name>portsentry</program_name>
</decoder>

<decoder name="portsentry-attackalert">
 <parent>portsentry</parent>
 <prematch>attackalert: Connect from </prematch>
 <regex offset="after_prematch">ost: (\S)/\S+ to \S+ port: (\d+)$</regex>
 <order>srcip, dstport</order>
</decoder>

<decoder name="portsentry-blocked">
 <parent>portsentry</parent>
 <prematch>is already blocked. Ignoring$</prematch>
 <regex>Host: (\S+) is</regex>
 <order>srcip</order>
</decoder>

Original issue reported on code.google.com by [email protected] on 2 Nov 2010 at 2:24

There are extra <group> tags in some of the sshd rules

  <rule id="5732" level="2">      <if_sid>5700</if_sid>      <match>error: connect_to </match>      <description>Possible port forwarding failure.</description>      <group>sshd,</group>    </rule>      <rule id="5733" level="2">      <if_sid>5700</if_sid>      <match>Invalid credentials</match>      <description>User entered incorrect password.</description>      <group>sshd,ldap,pam,authentication_failures,</group>    </rule>      <rule id="5734" level="1">      <if_sid>5700</if_sid>      <match>Could not load host key</match>      <description>sshd could not load one or more host keys.</description>      <info>This may be related to an upgrade to OpenSSH.</info>      <group>sshd,sysadmin,</group>    </rule>      <rule id="5735" level="2">      <if_sid>5700</if_sid>      <match>Write failed: Broken pipe</match>      <description>Failed write due to one host disappearing.</description>      <group>sshd,</group>    </rule>  

Original issue reported on code.google.com by [email protected] on 23 Oct 2010 at 1:17

• Merged into: #3

Different sshd brute force rules use different options

Examples:

<rule id="5720" level="10" frequency="6">
  <if_matched_sid>5716</if_matched_sid>
  <same_source_ip />
  <description>Multiple SSHD authentication failures.</description>
  <group>authentication_failures,</group>
</rule> 

<rule id="5712" level="10" frequency="6" timeframe="120" ignore="60">
  <if_matched_sid>5710</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>

Why does 5720 not have a timeframe and ignore while 5712 does? Which way should 
they both go?

Original issue reported on code.google.com by [email protected] on 23 Oct 2010 at 1:35

Rule 5719 should be in the authentication_failure or authentication_failed group

  <rule id="5719" level="10" frequency="6" timeframe="120" ignore="60">
  <if_matched_sid>5718</if_matched_sid>
  <description>Multiple access attempts using a denied user.</description>
</rule>  

Original issue reported on code.google.com by [email protected] on 19 Oct 2010 at 6:49