Latest version: 2.1.0
In this section, we will present and explain NDPMon's core configuration. Plugins configuration will be explained in their respective sections.
It is recommended to disable stateless autoconfiguration and the usage of privacy extensions, and set manually a global address on the host running NDPMon (if necessary)
If run in learning mode, NDPMon will listen to NDP messages while making the assumption that no attacks or misconfiguration is currently happening. Thus, no alerts will be raised during this phase, and all caches and configuration files will be populated with the current network information.
Just make sure to edit manually the configuration file config_ndpmon.xml and set the probes and the interfaces on which they will listen. By default, a single probe listening on eth0 is configured.
To launch this learning phase, as root, launch NDPMon with the -L option
In this section, we will detail all sections from NDPMon's configuration file, config_ndpmon.xml.
Note: It is recommended to generate the configuration file via the learning phase, and then edit it manually if required.
This XML file follows the DTD config_ndpmon.dtd.
The main block of this configuration file is the following.
The first configuration block, settings, permits to configure general parameters
Then, we configure the probes. Each probe has its own definition in a probe block
Probes can be remote when distributed monitoring is enabled, or local (type=interface) when it is listening on a local interface (identified by the probe name). There are no limitations in the probes number, may they be local or remote. However local probes have to define the legitimate routers on the given interface.
A router is identified by its MAC and LLA parameters.
All NDP parameters concerning that router can be set. A value of 0 means that the parameter is either not specified in the NDP message, or should be 0. Setting param_mtu to 0 means that the option is not expected in the RA. To enable parameters checks when receiving NDP messages, the params_volatile tag must be set to 0 (a value of 1 means that we allow these parameters to change, which may be the case for example during an IPv6 renumbering procedure).
Under the tag addresses are listed the IPv6 global addresses of the router. This is not required for the tool to work properly, but can be useful is the router send NA messages for its global addresses (to avoid raising NA router flag alerts).
Finally, the IPv6 network prefixes advertised by the router are listed. Once again, parameters are checked as well, unless thay have a value of 0.
RFC 6106 introduces 2 new options for transmitting DNS parameters in RA:
NDPMon supports learning and monitoring of these parameters via the following blocks:
No boundaries are set for the number of domains or nameservers advertised by the router, but a search domain can not be longer than 256 characters. resolv.conf(5) says that the implementation limits to 3 nameservers and 6 search domains, it is recommended to follow these constraints when setting up RFC6106 options in a network.
RFC 4191 introduces the Route Information option which permits to advertise more-specific routes from routers to hosts.
NDPMon supports learning and monitoring of these parameters via the following block:
The param_pref_reserved tag can take 4 different values: