Provided by: ndpmon_1.4.0-2.1build1_amd64 bug

NAME

       config_ndpmon.xml - Configuration file for ndpmon

DESCRIPTION

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

       NDPMon uses two configuration files, whose locations are:
       /etc/ndpmon/config_ndpmon.xml
       /var/lib/ndpmon/neighbor_list.xml

       DTDs have been written for these two files:
       config_ndpmon.dtd
       neighbor_list.dtd

       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">
       <config_ndpmon>
          <ignor_autoconf>1</ignor_autoconf>
          <syslog_facility>LOG_LOCAL1</syslog_facility>
          <admin_mail>frederic.beck@loria.fr</admin_mail>
          <actions_low_pri>
             <sendmail>1</sendmail>
             <syslog>1</syslog>
             <exec_pipe_program>/usr/lib/ndpmon/demopipeprogram.pl</exec_pipe_program>
          </actions_low_pri>
          <actions_high_pri>
             <sendmail>1</sendmail>
             <syslog>1</syslog>
             <exec_pipe_program>/usr/lib/ndpmon/demopipeprogram.pl</exec_pipe_program>
          </actions_high_pri>
          <use_reverse_hostlookups>1</use_reverse_hostlookups>
          <routers>
             <router>
                <mac>00:13:72:14:C4:58</mac>
                <lla>fe80:213:72ff:fe14:c458</lla>
                <prefixes>
                   <prefix>
                      <address>2001:660:4501:32:</address>
                      <mask>64</mask>
                   </prefix>
                </prefixes>
                <addresses>
                   <address>2001:660:4501:32::1</address>
                </addresses>
             </router>
          </routers>
       </config_ndpmon>

       ignor_autoconf

       /proc/sys/net/ipv6/conf/all/autoconf
       /proc/sys/net/ipv6/conf/all/accept_ra
       /proc/sys/net/ipv6/conf/all/accept_ra_defrtr
       /proc/sys/net/ipv6/conf/all/ra_pinfo
       /proc/sys/net/ipv6/conf/all/accept-ra_redirects

       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.

       syslog_facility

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

       admin_mail

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

       actions_low_pri/actions_high_pri

       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 demopipeprogram.pl
                    in the source code)

       routers

       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:

            <router>
               <mac>00:11:22:33:44:55</mac>
               <lla>fe80:0:0:0:211:22ff:fe33:4455</lla>
               <param_curhoplimit>64</param_curhoplimit>
               <param_flags_reserved>0</param_flags_reserved>
               <param_router_lifetime>10800</param_router_lifetime>
               <param_reachable_timer>0</param_reachable_timer>
               <param_retrans_timer>0</param)retrans_timer>
               <param_mtu>0</param_mtu>
               <params_volatile>0</params_volatile>
               <prefixes>
                  <prefix>
                     <address>2001:db8:1234:5678:0:0:0:0</address>
                     <mask>64</mask>
                     <param_flags_reserved>224</param_flags_reserved>
                     <param_valid_time>2592000</param_valid_time>
                     <param_preferred_time>604800</param_preferred_time>
                  </prefix>
               </prefixes>
               <addresses/>
            </router>

       params_volatile

       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.

       param_flags_reserved

       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 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.

            <countermeasures>
               <kill_illegitimate_router>RESPOND</kill_illegitimate_router>
               <kill_wrong_prefix>LAUNCH AFTER 10</kill_wrong_prefix>
               <propagate_router_params>CEASE AFTER 10</propagate_router_params>
               <indicate_ndpmon_presence>SUPPRESS</indicate_ndpmon_presence>
            </countermeasures>

       SUPPRESS

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

       RESPOND

       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.

AUTHOR

       ndpmon was written by Thibault Cholez.

       This       manual      page      was      copied      from      the      configuration      web      page
       (http://ndpmon.sourceforge.net/configuration.html) by John R. Baskwill <jrb28@psu.edu>,  for  the  Debian
       project (and may be used by others).

                                                  July 31, 2011                             CONFIG_NDPMON.XML(8)