Latest version: 2.1.0

NDPMon in the press

Downloads

Documentation

Plugins

Training

Community

edit SideBar

Countermeasures

Forged NDP messages are sent to deprecated rogue RAs and NAs using custom ICMPv6 messages generation library based on standard structures and functions.

Available CounterMeasures

Note: Counter measures on the link

The plugin keeps track of the countermeasures sent to decide if incoming captured packets shall be dropped or not. This is required to prevent counter-counter-...measures because a NDPMon instance listening on an interface captures normal NDP traiffc as well as its own countermeasures sent on this interface. As the counter- measures are also faked advertisements, they would otherwise trigger other countermeasures.

However, the plugin does not store the whole packet content but only a SHA-1 hash of the packet content in order to reduce memory consumption, and to deal with a constant size data type.

Build

To build it, simply enable it in the configure script

  1. ./configure --enable-countermeasures

Configuration

Countermeasures politic

This politic is implemented via countermeasures guards. The guards are used to decide if a call to a countermeasure function does actually result in a counter advertisement or if it is ignored. The decision is made according to a strategy which is set in the configuration. Currently the following strategies are implemented:

  • SUPPRESS: The countermeasure is turned off.
  • RESPOND: Each call to this countermeasure results 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 prevent NDPMon from contributing to Denial of Service, 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.

This politic is defined as follow in the configuration file:

  1. <config_ndpmon>
  2.   [...]
  3.   <countermeasures>
  4.     <kill_illegitimate_router>RESPOND</kill_illegitimate_router>
  5.     <kill_wrong_prefix>RESPOND</kill_wrong_prefix>
  6.     <propagate_router_params>RESPOND</propagate_router_params>
  7.     <propagate_router_dns>RESPOND</propagate_router_dns>
  8.     <propagate_router_routes>RESPOND</propagate_router_routes>
  9.     <propagate_neighbor_mac>RESPOND</propagate_neighbor_mac>
  10.     <indicate_ndpmon_presence>SUPPRESS</indicate_ndpmon_presence>
  11.   </countermeasures>
  12. </config_ndpmon>

The indicate_ndpmon_presence countermeasure is only necessary when several instances of NDPMon are running on the same link to avoid these multiple instances to send countermeasures against each other. By default, setting a value of SUPPRESS is correct.

Per probe flag

Not every administrator may welcome a monitoring tool that autonomously responds to events on the network. Thus, a flag permits to enable or disable these countermeasures.

For example, to enable it on eth1:

  1. <config_ndpmon>
  2.   [...]
  3.   <probes>
  4.     <probe name="eth1" type="interface">
  5.       <countermeasures_enabled>1</countermeasures_enabled>
  6.       [...]
  7.     </probe>
  8.   </probe>
  9.   [...]
  10. </config_ndpmon>

Steps to implement a new counter measure

  1. Implement the cm_(counter measure name) function
  2. Add a new guard for this counter measure in counter_measure.c
  3. Extends the function cm_guard_init_all() and cm_guard_all_to_representation() for the new guard.
  4. Extend parser.c to parse and write the configuration for the new guard.
  5. Plug the counter measure into the appropriate monitoring file, remember to put IFDEFs to test for _COUNTERMEASURES_.