[ossec-dev] various minor configuration suggestions

["Logan O'Sullivan Bruns" <logan@xxxxxxxxxxxx>]

First off thanks for the fine product.

For whatever they may be worth here is a list of configuration changes
to OSSEC 1.2 that I made to support my own environment. I think some
of them may be worth rolling into a future version of the default
configuration.

ossec.conf:
  <syscheck>
    <ignore>/etc/dumpdates</ignore>
    <ignore>/etc/svc/volatile</ignore>

The former is the dumpdates file that is updated on Solaris boxes
whenever a ufsdump based backup is performed. The latter is used by
the Solaris 10 service management framework.

sshd_rules.xml:

  <rule id="5710" level="5">
    <if_sid>5700</if_sid>
    <match>Illegal user|Invalid user</match>
    <description>Attempt to login using a non-existent user</description>
    <group>invalid_login,</group>
  </rule>

Note I capitalized the first letter of each phrase in the match
line. The matching appears to be case sensitive and making this change
made the corresponding events show up in my alerts log when they
hadn't before.

I use a sendmail milter called SMF-SAV:

  http://smfs.sourceforge.net/smf-sav.html

In a nutshell it tries to verify a sender's address before accepting
the mail they are sending. So yet another tool to cut down on
spam. Anyway, I took a stab at adding rules so that OSSEC will send
alerts and active responses based on SMF-SAV syslog messages.

decoder.xml:
  <!-- SMF-SAV Sendmail Milter decoder.
    - Will extract the srcip
    - Examples: 
    - smf-sav[513]: [ID 987462 mail.notice] sender check failed: <xkyjywqvophshu@xxxxxxxxxxxxxxxxxxx>, 125.133.22.112, [125.133.22.112], [00:00:01]
    - smf-sav[513]: [ID 407019 mail.info] sender check succeeded (cached): <asterisk-users-bounces@xxxxxxxxxxxxxxxx>, 216.207.245.17, lists.digium.com
    - smf-sav[513]: [ID 987894 mail.notice] sender check tempfailed: <31363****-org@xxxxxxxxxxxxxxxxx>, 69.8.190.101, smtp101.tramailer.info, [00:00:05]
   -->
  <decoder name="smf-sav-reject">
    <program_name>^smf-sav</program_name>
  </decoder>  

  <decoder name="smf-sav-reject-check-failed">
    <parent>smf-sav-reject</parent>
    <prematch>sender check failed: \S+, </prematch>
    <regex offset="after_prematch">^(\d+.\d+.\d+.\d+),</regex>
    <order>srcip</order>
  </decoder>

smf-sav_rules.xml:
  <group name="syslog,smf-sav,">
    <rule id="41100" level="0">
      <decoded_as>smf-sav-reject</decoded_as>
      <description>Grouping of the smf-sav sendmail milter rules.</description>
    </rule>

    <rule id="41101" level="6">
      <if_sid>41100</if_sid>
      <match>sender check failed</match>
      <description>SMF-SAV sendmail milter unable to verify address (REJECTED).</description>
      <group>spam,</group>
    </rule>
  </group> <!-- SYSLOG,SMF-SAV -->

Please forgive me if I've used the levels wrong or failed to respect
any existing id hierarchy. I didn't see the documentation on either of
those. Anyway, for your consideration.

One final comment. I don't have a good solution for how to integrate
this into your turnkey approach but another change I had to make was
to firewall-drop.sh to add the group number to the end of the dynamic
ipfilter rule. I suspect that a number of people who are using
ipfilter will need to do this. So you might put a warning in somewhere
or perhaps encourage people to verify that their ipfilter rules are
working. Perhaps suggest that they run something like this to check
for hits against the dynamic rules:

  # ipfstat -ih | grep "block in quick"
  0 block in quick from 124.10.89.38/32 to any group 100
  3 block in quick from 221.202.15.161/32 to any group 100
  0 block in quick from 72.184.61.130/32 to any group 100

I'd suggest looking for the tcpwrappers syslog messages except that
there seems to be a small window between when the two active response
scripts are executed. So sometimes you'll still see a tcpwrappers
message before the firewall change is made.

Again thanks for the fine product.

  - logan

p.s. I'm not on the mailing list so please make sure my address is on
any response.

-- 
PGP/GPG Key: http://www.gedanken.org/logan/pubkey.asc
Fingerprint: 320C E05B 4BFB A8C4 FC7A  C06C 88D7 B840 BD56 AF78