.TH CONFIG_NDPMON.XML 8 "July 31, 2011"
.\" Please adjust this date whenever revising the manpage.
.SH NAME
config_ndpmon.xml \- Configuration file for ndpmon
.br
.sp
.SH DESCRIPTION
This manual page documents briefly the various options for configuring
ndpmon.
.br
.sp
NDPMon uses two configuration files, whose locations are:
.br
.I	/etc/ndpmon/config_ndpmon.xml
.br
.I	/var/lib/ndpmon/neighbor_list.xml
.br
.sp
DTDs have been written for these two files:
.br
.I	config_ndpmon.dtd
.br	
.I	neighbor_list.dtd
.br
.sp
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.
.br
.sp
.B Basic configuration example
.br
.sp
Here is an example of a configuration file for NDPMON:
.br
.sp
.nf
<?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>
.br
.sp
.fi
.B ignor_autoconf
.br
.sp
.I	/proc/sys/net/ipv6/conf/all/autoconf
.br
.I	/proc/sys/net/ipv6/conf/all/accept_ra
.br
.I	/proc/sys/net/ipv6/conf/all/accept_ra_defrtr
.br
.I	/proc/sys/net/ipv6/conf/all/ra_pinfo
.br
.I	/proc/sys/net/ipv6/conf/all/accept-ra_redirects
.br
.sp
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.
.br
.sp
.B syslog_facility
.br
.sp
This parameter sets the facility Syslog will use for logging.  To redirect messages to a dedicated log file, reconfigure the syslog daemon itself.
.br
.sp
.B admin_mail
.br
.sp
The email address to which the ndpmon daemon will send alerts. The default is set to root@localhost.
.br
.sp
.B actions_low_pri/actions_high_pri
.br
.sp
Enable or disable the alerts
.br
	sendmail: send an email to the administrator email address
.br
	syslog: syslog the message
.br	
	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)
.br
.sp
.B routers
.br
.sp
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.
.br
.sp
In version 1.4.0, additional tags were introduced to check the parameters of a Router Advertisement.  For details see below.
.br
.sp
.B Configuring the Router Advertisement parameter check
.br
.sp
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.
.br
.sp
Below you will find an example of a more complex router definition:
.br
.sp
.nf
	<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>
.fi
.br
.sp
.B params_volatile
.br
.sp
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.
.br
.sp
.B param_flags_reserved
.br
.sp
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!
.br
.sp
.B param_curhoplimit, param_router_lifetime, param_reachable_timer,
.B param_retrans_timer, param_mtu
.br
.sp
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.
.br
.sp
.B prefix: param_flags_reserved, param_valid_time, param_preferred_time
.br
.sp
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).
.br
.sp
.sp
.B Configuring the countermeasures plugin
.br
.sp
Below you will find an example configuration for the countermeasures plugin.  If the tag countermeasures is not present, all countermeasures are suppressed.
.br
.sp
.nf
	<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>
.fi
.br
.sp
.B SUPPRESS
.br
.sp
The countermeasure is turned off (default value for each configuration tag not present).
.br
.sp
.B RESPOND
.br
.sp
Each call to this countermeasure result in a reaction.
.br
.sp
.B CEASE AFTER max
.br
.sp
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.
.br
.sp
.B LAUNCH AFTER min
.br
.sp
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.

.SH AUTHOR
ndpmon was written by Thibault Cholez.
.PP
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).