
TODO things for Snort in Debian
-------------------------------

- Provide support to avoid specifying the address range for multiple
  interfaces (or skip this if you have more than once and substitute
  by a note telling the admin to configure this in the snort.$IFACE.conf 
  file).  This could be done using 'ip addr show $IFACE' and extracting
  the value from the 'inet' component.

  Note: This should only be done if only *one interface is available

- Try to use the interface defined IP address to set the address range (and
  lower the questions priority
  This should also handle multiple interfaces.
  (see bug #248000)

- Add a note in the debconf propmt that users can use '\$eth0_ADDRESS'
  (or '\$eth1_ADDRESS' etc..) to use the interface's address regardless
  of the configured address. (Note that \$ or otherwise it will
  be expanded in the scripts)

  REVIEW: How does Snort use this to expand it in HOME_NET

  Note, this has been requested at least in 
  https://bugs.launchpad.net/ubuntu/+source/snort/+bug/566543

- Fix bugs related to an interface being used which is not available
  
  This seems to break when configuring the package:
  https://bugs.launchpad.net/ubuntu/+source/snort/+bug/655116

  

- snort-{mysql,pgsl}:
 Database configuration should ensure that only valid characters are included
 here. Since the information is written into a configuration file at least
 hashes should be prevented.  See:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567495

- snort-{mysql,pgsl}:
  Offer the user an option to automatically create the database since
  the schemas (at /usr/share/doc/snort*) stuff is not available on installation.

  This confuses users since they are asked for some information (network
  interface, IP address) but not the information related to database
  configuration.

  Use dbconfig-common for this. 

  Review what other packages (gnudip? horde? imp? sitebar? openwebmail?)
  have done and consider the use of the generic user for database
  administration.  Note that database permissions for the 'snort' 
  user need to be properly setup!
  Also see: http://lists.debian.org/debian-devel/2004/08/msg01104.html
  http://lists.debian.org/debian-devel/2004/10/msg00340.html
  and
  http://lists.debian.org/debian-devel/2004/10/msg00962.html

- Include Rpm improvements to the init.d file suchas :

   * The init.d file could use separate LOGDIR files per interface instead of
     one for all instances (bound to break) just like it's done in the RedHat
     init script. The check_logdir function should be called per possible LOGDIR
     definition. If the LOGDIR did not exist it should be created with proper
     permissions.

     Note: logrotate definitions will need to be changed if this is changed

   * stats option in the init.d file
   * Additional /etc/default/snort parameters similar to the RPM ones for
     compatibility

- Include ntop improvements to init.d script: check if interface is up

- Use LSB functions in Init.d script

- Break up the init.d script into reusable functions 
  Also: add a check in order to determine if the snort sensor started
  up properly or it did not.

- The check_log_dir check in the init.d script could best check if the
  LOGDIR directory is writable by the snort user. It might not be good
  (security-wise) to force it's owned by the snort user (since then
  it would be able to remove its own logs)

- Check if --enable-flexresp works with libnet 1.1.x

- The snort-common package currently does not check if you _accepted_ the
  config file provided, this is related to bug #247665 which is partially
  fixed by the snort-common Source-Version depends introduced in 2.2.0-2

- Add some common logcheck rules (see #222584, and #217175)

DONE


- Determine, if the interface is configured and up.
 (see bug #248000)

- Have a way in preinst to migragte from the old common.parameters to the
  new /etc/default/snort so that all users can benefit from it. 

- Provide an update script, as required in #191105
  Done: snort-rules-default currently recommends: 'oinkmaster' better
  that than maintaining a separate update script unmaintained upstream.


- Rewrite the "address range" question. It actually does not explain what
  it is actually used for (HOME_NET)

NOT REQUIRED

- Use ucf to integrate changes by the maintainer when upgrading. 

  Justification: The package has be changed to try to not make changes through
  scripts in the maintainer's file
