Using RFC8520 (MUD) to Enforce Hosts Traffic Policies in ntopng

Posted · Add Comment

RFC8520 (Manufacturer Usage Description) specifies what is the intended (from the manufacturer standpoint) network behaviour of a network device. Being it defined in JSON format by the device manufacturer, it can be used for simple single-task devices such as a printer or an access-point where the device communications are simple and well defined. Typically a device specifies in DHCP requests the URL of a MUD file [image below courtesy of osMUD]


that is defined by the manufacturer specifying what IP/ports the device can access. The URL is passed to an additional network component named MUD manager that downloads the URL and reports to the local policer (typically the network firewall) what is the allowed policy for the device so that unexpected communications are now allowed. As you can see this model can work only with simple devices where the behaviour can be mapped easily, but it falls short with general purpose devices such as a tablet or a PC where it is not possible for the manufacturer to decide what is the allowed device policy by restricting communications to specific sites and services.

Despite all these limitations, the MUD is a good starting point for representing device behaviour onto a simple JSON file that can be exchanged across hosts to enforce device network policies. In ntopng we have recently enhanced the alarming system to track misbehaving traffic flows, and with MUD we can bring this to the next level by using it to track unwanted communications (in passive monitoring mode) or block them (in inline mode). Prior to do this we have to enhance MUD to make sure it works not just for single-task devices but also for general purpose devices. The solution we have adopted is to observe device behaviour for some time (e.g. one day) in a sort of “training mode” and past this time use the known behaviour to match network traffic flows. To make this effective we have enhanced the MUD specification by adding extra information fields that make it suitable also for generic devices. In particular we have replaced for non-local traffic flows IP/ports with nDPI information, and used fingerprints (JA3 and HASSH recently implemented in nDPI) to further characterise network traffic. A typical MUD block now looks like

{
   "matches":{
     "ja3":{
       "source-fingerprint":"d3e1de2ca313c6c0a639f69cc3e924a4"
     },
     "ipv4":{
       "protocol":6
     },
     "ndpi_l7":{
       "application":"tls"
     }
   },
   "actions":{
     "forwarding":"accept"
   },
   "name":"from-ipv4-pc-ntop-64"
 }

If you update to the latest ntopng build you will see (for local hosts) a new preference under the host page that allow you to tell ntopng to start monitoring host traffic in order to learn device network behaviour and thus create a host MUD specification.

After you enable MUD recording you will see two new icons that allow you to download the MUD file or to trash the known MUD host information and start over. This is work in progress as we currently generate only MUD without using it. In particular the items under development include

  • Ability to import an existing MUD file instead of learning it.
  • Trigger traffic alerts based on the known MUD behaviour.
  • As ntopng is able to discover network assets and thus map them to categories, we need to automate MUD generation by removing the drop-down menu where a network admin is asked for device type (either generic or single-task device) as this information can be inferred looking at network traffic.
  • Enable MUD auto-learn mode so that whenever a local device appears on the network MUD generation is triggered.

While we develop MUD support in ntopng, we would be glad if you could tell us more about the current plan and thus send us ideas and comments.

 

Enjoy!