Provided by: ndpmon_1.4.0-2.1_i386 bug


       config_ndpmon.xml - Configuration file for ndpmon


       This  manual page documents briefly the various options for configuring

       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 root@localhost.


       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

       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, param_mtu

       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

       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"

       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)