Provided by: ndpmon_1.4.0-2.1build1_amd64 bug


       config_ndpmon.xml - Configuration file for ndpmon


       This manual page documents briefly the various options for configuring ndpmon.

       NDPMon uses two configuration files, whose locations are:

       DTDs have been written for these two files:

       The  Neighbor  List  is  filled  by the program itself, while running or during a learning
       period.  The configuration file itself has to be filled in by the administrator.

       Basic configuration example

       Here is an example of a configuration file for NDPMON:

       <?xml version="1.0" encoding="ISO-8859-1"?>
       <!DOCTYPE config_ndpmon SYSTEM "/etc/ndpmon/config_ndpmon.dtd">



       By setting this parameter to 0, the host will ignore all Router Advertisements  or  ICMPv6
       Redirects,  and  will thus not be sensitive to attacks on these messages, but should still
       be able to send the alerts to the monitoring station.  Caution: the administrator must  be
       aware  that  this  will  disable  the  possibility  for  the  host  to  use  IPv6  Address
       Autoconfiguration, which could cause trouble in case of a renumbering or a modification in
       the network's topology.


       This  parameter  sets the facility Syslog will use for logging.  To redirect messages to a
       dedicated log file, reconfigure the syslog daemon itself.


       The email address to which the ndpmon daemon will send  alerts.  The  default  is  set  to


       Enable or disable the alerts
            sendmail: send an email to the administrator email address
            syslog: syslog the message
            exec_pipe_program:  the  program  to  call  to  capture  the reports and           do
       whatever you want with it (see
                 in the source code)


       A router is defined with its MAC and Link Local addresses.  It also contains the  list  of
       prefixes  advertised  by  this  router,  and  eventually  the  global addresses set on its
       interfaces.  This new definition makes possible to check the tuple (MAC, LLA,  PREFIX)  in
       the received Router Advertisements, instead of checking them separately in version 0.1.

       In  version  1.4.0,  additional  tags  were introduced to check the parameters of a Router
       Advertisement.  For details see below.

       Configuring the Router Advertisement parameter check

       In version 1.4.0, further checks for Router Advertisements  (RAs)  were  introduced  which
       assume that the RA parameters do not change during operation.  Those values may be learned
       during the learning phase of NDPMon or they may be configured manually.  This behavior  is
       optional.  If you do not include the additional parameters, no checks will be performed.

       Below you will find an example of a more complex router definition:



       Indicates  if  the  router  params  may  change during operation.  A value of 0 means that
       values do not change, a non-zero values means parameters may change.  If this tag  is  not
       present,  its  value  is  assumed  to  be  non-zer0  (1).   If you want NDPMon to check RA
       parameters for this router, include the tag  param_voltile  with  a  value  of  zero.   If
       param_volatile is set to zero, you should at least include the router param_flags_reserved
       tag and the param_tags for each prefix.


       The flags of a RA or a RA prefix information option, stored as an  unsigned  integer.   If
       this  tag is not present, it does not indicate that this is unspecified, but that no flags
       are set!

       param_curhoplimit,  param_router_lifetime,   param_reachable_timer,   param_retrans_timer,

       Contains the values of the corresponding RA fields (or the MTU option).  If those tags are
       not present, this indicates that they are not specified, and the corresponding value of  a
       RA will not be checked.

       prefix: param_flags_reserved, param_valid_time, param_preferred_time

       The  parameters  of  prefixes advertised.  These tags should be present for each prefix if
       parameters are checked, because prefix parameters cannot be unspecified.  If they are  not
       present,  their  value  is  assumed to be zero (which is, concerning the prefix lifetimes,
       usually not desired).

       Configuring the countermeasures plugin

       Below you will find an example configuration for the countermeasures plugin.  If  the  tag
       countermeasures is not present, all countermeasures are suppressed.

               <kill_wrong_prefix>LAUNCH AFTER 10</kill_wrong_prefix>
               <propagate_router_params>CEASE AFTER 10</propagate_router_params>


       The countermeasure is turned off (default value for each configuration tag not present).


       Each call to this countermeasure result in a reaction.

       CEASE AFTER max

       For  max  calls, each call to this countermeasure results in a reaction.  After the max'th
       call, the countermeasure is suppressed.  max may be a number up to 255.  This may be  used
       to  precent  NDPMon  from contributing to a Denial of Service attack, but to have a "first
       response" countermeasure.

       LAUNCH AFTER min

       For min calls, this countermeasure is suppressed.  After the min'th call, each call to the
       countermeasure results in a reaction.  min may be a number up to 255.


       ndpmon was written by Thibault Cholez.

       This     manual     page     was     copied    from    the    configuration    web    page
       ( by John  R.  Baskwill  <>,
       for the Debian project (and may be used by others).

                                          July 31, 2011                      CONFIG_NDPMON.XML(8)