Provided by: ndpmon_1.4.0-2.1_i386 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)