Latest version: 2.1.0

NDPMon in the press

Downloads

Documentation

Plugins

Training

Community

edit SideBar

Configuration

In this section, we will present and explain NDPMon's core configuration. Plugins configuration will be explained in their respective sections.

Generalities

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)

  1. sysctl -w net.ipv6.conf.all.autoconf=0
  2. sysctl -w net.ipv6.conf.all.use_tempaddr=0

Automatic configuration

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.

  1. [...]
  2. <probes>
  3.   <probe name="eth0" type="interface">
  4.     <routers/>
  5.   </probe>
  6. </probes>
  7. [...]

To launch this learning phase, as root, launch NDPMon with the -L option

  1. ndpmon -L

Manual Configuration

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.

  1. <?xml version="1.0" encoding="ISO-8859-1"?>
  2. <!DOCTYPE config_ndpmon SYSTEM "config_ndpmon.dtd">
  3. <?xml-stylesheet type="text/xsl" href="config.xsl" ?>
  4. <config_ndpmon>
  5. [...]
  6. </config_ndpmon>

Generic settings

The first configuration block, settings, permits to configure general parameters

  1. <settings>
  2.     <actions_high_priority sendmail="1" syslog="1" exec_pipe_program=""/>
  3.     <actions_low_priority sendmail="1" syslog="1" exec_pipe_program=""/>
  4.     <admin_mail>root@localhost</admin_mail>
  5.     <ignor_autoconf>1</ignor_autoconf>
  6.     <syslog_facility>LOG_LOCAL1</syslog_facility>
  7.     <use_reverse_hostlookups>0</use_reverse_hostlookups>
  8.   </settings>
  • actions_high_priority and actions_low_priority permit to configure the actions to do when such alerts are raised. Set sendmail and syslog attributes to 1 to enable them. The exec_pipe_program is a user script that can be called to perform custom actions
  • admin_mail is the destination mail address used for reports
  • ignor_autoconf is ingored at the moment
  • syslog_facility used logging into syslog, not very important as the filtering when enabling the plugin is performed on the messages themselves
  • use_reverse_hostlookups permits if enabled and AAA DNS records are available to perform name resolution

Probes

Then, we configure the probes. Each probe has its own definition in a probe block

  1. <probes>
  2.   <!-- Example remote probe -->
  3.   <probe name="somehost/eth0" type="remote" />
  4.   <!-- Local probe -->
  5.   <probe name="eth0" type="interface">
  6.     <routers/>
  7.   </probe>
  8. </probes>

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.

Routers

  1. <!--Example router definition -->
  2.     <router>
  3.       <mac>0:11:22:33:44:55</mac>
  4.       <lla>fe80::211:22ff:fe33:4455</lla>
  5.       <param_curhoplimit>64</param_curhoplimit>
  6.       <param_flags_reserved>0</param_flags_reserved>
  7.       <param_router_lifetime>10800</param_router_lifetime>
  8.       <param_reachable_timer>0</param_reachable_timer>
  9.       <param_retrans_timer>0</param_retrans_timer>
  10.       <param_mtu>0</param_mtu>
  11.       <params_volatile>1</params_volatile>
  12.       <addresses/>
  13.       <prefixes>
  14.         <prefix>
  15.           <address>2001:db8:1234:5678::</address>
  16.           <mask>64</mask>
  17.           <param_flags_reserved>224</param_flags_reserved>
  18.           <param_valid_time>2592000</param_valid_time>
  19.           <param_preferred_time>604800</param_preferred_time>
  20.         </prefix>
  21.       </prefixes>
  22.     </router>

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.

DNS options

RFC 6106 introduces 2 new options for transmitting DNS parameters in RA:

  • RDNSS option to advertise nameservers addresses and lifetimes
  • DNSSL option to advertise domain names for the search list

NDPMon supports learning and monitoring of these parameters via the following blocks:

  1. <router>
  2.     [...]
  3.     </prefixes>
  4.     <rdnss>
  5.         <nameserver lifetime="600">fd75:7c74:2274:1::53</nameserver>
  6.         <nameserver lifetime="900">fd75:7c74:2274:1::5353</nameserver>
  7.     </rdnss>
  8.     <dnssl>
  9.         <domain lifetime="1000">testbed.localdomain</domain>
  10.     </dnssl>
  11. </router>

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.

Route Information

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:

  1. <router>
  2.     [...]
  3.   </dnssl>
  4.   <routes>
  5.     <route>
  6.       <address>2001:db8:1:2::</address>
  7.       <mask>64</mask>
  8.       <param_pref_reserved>8</param_pref_reserved>
  9.       <lifetime>2592000</lifetime>
  10.     </route>
  11.   </routes>
  12. </router>

The param_pref_reserved tag can take 4 different values:

  • 24, standing for low priority
  • 0, the default, standing for medium priority
  • 8, standing for high priority
  • 16, standing for reserved priority, should never be sent and must be ignored by the hosts