volatility3.plugins.linux.netfilter module

class AbstractNetfilter(context, kernel_module_name)[source]

Bases: ABC

Netfilter Abstract Base Classes handling details across various Netfilter implementations, including constants, helpers, and common routines.

NF_MAX_HOOKS = 8
PROTO_HOOKS = (Proto(name='UNSPEC', hooks=()), Proto(name='INET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='IPV4', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='ARP', hooks=('IN', 'OUT', 'FORWARD')), Proto(name='UNSPEC', hooks=()), Proto(name='NETDEV', hooks=('INGRESS', 'EGRESS')), Proto(name='UNSPEC', hooks=()), Proto(name='BRIDGE', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='UNSPEC', hooks=()), Proto(name='IPV6', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='DECNET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING', 'HELLO', 'ROUTE')))
build_nf_hook_ops_array(nf_hook_entries)[source]

Function helper to build the nf_hook_ops array when it is not part of the struct ‘nf_hook_entries’ definition.

nf_hook_ops was stored adjacent in memory to the nf_hook_entry array, in the new struct ‘nf_hook_entries’. However, this ‘nf_hooks_ops’ array ‘orig_ops’ is not part of the ‘nf_hook_entries’ struct. So, we need to calculate the offset.

struct nf_hook_entries {

u16 num_hook_entries; /* plus padding */ struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[];

}

get_hook_ops(hook_container, proto_idx, hook_idx)[source]

Given the hook_container obtained from get_hooks_container(), it returns an iterable of ‘nf_hook_ops’ elements for a corresponding protocol and hook type.

This is the most variable/unstable part of all Netfilter hook designs, it changes almost in every single implementation.

get_hooks_container(net, proto_name, hook_name)[source]

Returns the data structure used in a specific kernel implementation to store the hooks for a respective namespace and protocol.

Except for kernels < 4.3, all the implementations use network namespaces. Also the data structure which contains the hooks, even though it changes its implementation and/or data type, it is always in this location.

static get_member_type(vol_type, member_name)[source]

Returns a list of types/subtypes belonging to the given type member.

Parameters:
Returns:

A list of types/subtypes

Return type:

list

get_module_name_for_address(addr)[source]

Helper to obtain the module and symbol name in the format needed for the output of this plugin.

Return type:

str

get_net_namespaces()[source]

Common function to retrieve the different namespaces. From 4.3 on, all the implementations use network namespaces.

get_symbol_fullname(symbol_basename)[source]

Given a short symbol or type name, it returns its full name

Return type:

str

classmethod run_all(context, kernel_module_name)[source]

It calls each subclass symtab_checks() to test the required conditions to that specific kernel implementation.

Parameters:

  • context (ContextInterface) – The volatility3 context on which to operate

  • kernel_module_name (str) – The name of the table containing the kernel symbols

Yields:

The kmsg records. Same as _run()

Return type:

Iterator[Tuple[int, str, str, int, int, str, bool]]

subscribed_protocols()[source]

Allows to select which PROTO_HOOKS protocols will be processed by the Netfiler subclass.

Return type:

Tuple[str]

abstract classmethod symtab_checks(vmlinux)[source]

This method on each sublasss will be called to evaluate if the kernel being analyzed fulfill the type & symbols requirements for the implementation. The first class returning True will be instantiated and called via the run() method.

Returns:

True if the kernel being analyzed fulfill the class requirements.

Return type:

bool

class AbstractNetfilterNetDev(context, kernel_module_name)[source]

Bases: AbstractNetfilter

Base class to handle the Netfilter NetDev hooks. It won’t be executed. It has some common functions to all Netfilter NetDev hook implementions.

Netfilter NetDev hooks are set per network device which belongs to a network namespace.

NF_MAX_HOOKS = 8
PROTO_HOOKS = (Proto(name='UNSPEC', hooks=()), Proto(name='INET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='IPV4', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='ARP', hooks=('IN', 'OUT', 'FORWARD')), Proto(name='UNSPEC', hooks=()), Proto(name='NETDEV', hooks=('INGRESS', 'EGRESS')), Proto(name='UNSPEC', hooks=()), Proto(name='BRIDGE', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='UNSPEC', hooks=()), Proto(name='IPV6', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='DECNET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING', 'HELLO', 'ROUTE')))
build_nf_hook_ops_array(nf_hook_entries)

Function helper to build the nf_hook_ops array when it is not part of the struct ‘nf_hook_entries’ definition.

nf_hook_ops was stored adjacent in memory to the nf_hook_entry array, in the new struct ‘nf_hook_entries’. However, this ‘nf_hooks_ops’ array ‘orig_ops’ is not part of the ‘nf_hook_entries’ struct. So, we need to calculate the offset.

struct nf_hook_entries {

u16 num_hook_entries; /* plus padding */ struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[];

}

get_hook_ops(hook_container, proto_idx, hook_idx)

Given the hook_container obtained from get_hooks_container(), it returns an iterable of ‘nf_hook_ops’ elements for a corresponding protocol and hook type.

This is the most variable/unstable part of all Netfilter hook designs, it changes almost in every single implementation.

get_hooks_container(net, proto_name, hook_name)[source]

Returns the data structure used in a specific kernel implementation to store the hooks for a respective namespace and protocol.

Except for kernels < 4.3, all the implementations use network namespaces. Also the data structure which contains the hooks, even though it changes its implementation and/or data type, it is always in this location.

static get_member_type(vol_type, member_name)

Returns a list of types/subtypes belonging to the given type member.

Parameters:
Returns:

A list of types/subtypes

Return type:

list

get_module_name_for_address(addr)

Helper to obtain the module and symbol name in the format needed for the output of this plugin.

Return type:

str

get_net_namespaces()

Common function to retrieve the different namespaces. From 4.3 on, all the implementations use network namespaces.

get_symbol_fullname(symbol_basename)

Given a short symbol or type name, it returns its full name

Return type:

str

classmethod run_all(context, kernel_module_name)

It calls each subclass symtab_checks() to test the required conditions to that specific kernel implementation.

Parameters:

  • context (ContextInterface) – The volatility3 context on which to operate

  • kernel_module_name (str) – The name of the table containing the kernel symbols

Yields:

The kmsg records. Same as _run()

Return type:

Iterator[Tuple[int, str, str, int, int, str, bool]]

subscribed_protocols()[source]

Allows to select which PROTO_HOOKS protocols will be processed by the Netfiler subclass.

classmethod symtab_checks(vmlinux)[source]

This method on each sublasss will be called to evaluate if the kernel being analyzed fulfill the type & symbols requirements for the implementation. The first class returning True will be instantiated and called via the run() method.

Returns:

True if the kernel being analyzed fulfill the class requirements.

Return type:

bool

class Netfilter(context, config_path, progress_callback=None)[source]

Bases: PluginInterface

Lists Netfilter hooks.

Parameters:

  • context (ContextInterface) – The context that the plugin will operate within

  • config_path (str) – The path to configuration data within the context configuration data

  • progress_callback (Optional[Callable[[float, str], None]]) – A callable that can provide feedback at progress points

build_configuration()

Constructs a HierarchicalDictionary of all the options required to build this component in the current context.

Ensures that if the class has been created, it can be recreated using the configuration built Inheriting classes must override this to ensure any dependent classes update their configurations too

Return type:

HierarchicalDict

property config: HierarchicalDict

The Hierarchical configuration Dictionary for this Configurable object.

property config_path: str

The configuration path on which this configurable lives.

property context: ContextInterface

The context object that this configurable belongs to/configuration is stored in.

classmethod get_requirements()[source]

Returns a list of Requirement objects for this plugin.

Return type:

List[RequirementInterface]

classmethod make_subconfig(context, base_config_path, **kwargs)

Convenience function to allow constructing a new randomly generated sub-configuration path, containing each element from kwargs.

Parameters:

  • context (ContextInterface) – The context in which to store the new configuration

  • base_config_path (str) – The base configuration path on which to build the new configuration

  • kwargs – Keyword arguments that are used to populate the new configuration path

Returns:

The newly generated full configuration path

Return type:

str

property open

Returns a context manager and thus can be called like open

run()[source]

Executes the functionality of the code.

Note

This method expects self.validate to have been called to ensure all necessary options have been provided

Returns:

A TreeGrid object that can then be passed to a Renderer.

set_open_method(handler)

Sets the file handler to be used by this plugin.

Return type:

None

classmethod unsatisfied(context, config_path)

Returns a list of the names of all unsatisfied requirements.

Since a satisfied set of requirements will return [], it can be used in tests as follows:

unmet = configurable.unsatisfied(context, config_path)
if unmet:
    raise RuntimeError("Unsatisfied requirements: {}".format(unmet)
Return type:

Dict[str, RequirementInterface]

version = (1, 1, 0)
class NetfilterImp_4_14_to_4_16(context, kernel_module_name)[source]

Bases: AbstractNetfilter

‘nf_hook_ops’ was removed from struct ‘nf_hook_entry’. Instead, it was stored adjacent in memory to the ‘nf_hook_entry’ array, in the new struct ‘nf_hook_entries’ However, ‘orig_ops’ is not part of the ‘nf_hook_entries’ struct definition. So, we have to craft it by hand.

struct net { … struct netns_nf nf; … } struct netns_nf {

struct nf_hook_entries *hooks[NFPROTO_NUMPROTO][NF_MAX_HOOKS]; … }

struct nf_hook_entries {

u16 num_hook_entries; /* plus padding */ struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[]; }

struct nf_hook_entry {

nf_hookfn *hook; void *priv; }

(*) Even though the hook address is in the struct ‘nf_hook_entry’, we use the original ‘nf_hook_ops’ hook address value, the one which was filled by the user, to make it uniform to all the implementations.

NF_MAX_HOOKS = 8
PROTO_HOOKS = (Proto(name='UNSPEC', hooks=()), Proto(name='INET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='IPV4', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='ARP', hooks=('IN', 'OUT', 'FORWARD')), Proto(name='UNSPEC', hooks=()), Proto(name='NETDEV', hooks=('INGRESS', 'EGRESS')), Proto(name='UNSPEC', hooks=()), Proto(name='BRIDGE', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='UNSPEC', hooks=()), Proto(name='IPV6', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='DECNET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING', 'HELLO', 'ROUTE')))
build_nf_hook_ops_array(nf_hook_entries)

Function helper to build the nf_hook_ops array when it is not part of the struct ‘nf_hook_entries’ definition.

nf_hook_ops was stored adjacent in memory to the nf_hook_entry array, in the new struct ‘nf_hook_entries’. However, this ‘nf_hooks_ops’ array ‘orig_ops’ is not part of the ‘nf_hook_entries’ struct. So, we need to calculate the offset.

struct nf_hook_entries {

u16 num_hook_entries; /* plus padding */ struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[];

}

get_hook_ops(hook_container, proto_idx, hook_idx)[source]

Given the hook_container obtained from get_hooks_container(), it returns an iterable of ‘nf_hook_ops’ elements for a corresponding protocol and hook type.

This is the most variable/unstable part of all Netfilter hook designs, it changes almost in every single implementation.

get_hooks_container(net, proto_name, hook_name)

Returns the data structure used in a specific kernel implementation to store the hooks for a respective namespace and protocol.

Except for kernels < 4.3, all the implementations use network namespaces. Also the data structure which contains the hooks, even though it changes its implementation and/or data type, it is always in this location.

static get_member_type(vol_type, member_name)

Returns a list of types/subtypes belonging to the given type member.

Parameters:
Returns:

A list of types/subtypes

Return type:

list

get_module_name_for_address(addr)

Helper to obtain the module and symbol name in the format needed for the output of this plugin.

Return type:

str

get_net_namespaces()

Common function to retrieve the different namespaces. From 4.3 on, all the implementations use network namespaces.

get_nf_hook_entries(nf_hooks_addr, proto_idx, hook_idx)[source]

This allows to support different hook array implementations from this version on. For instance, in kernels >= 4.16 this multi-dimensional array is split in one-dimensional array of pointers to ‘nf_hooks_entries’ per each protocol.

get_symbol_fullname(symbol_basename)

Given a short symbol or type name, it returns its full name

Return type:

str

classmethod run_all(context, kernel_module_name)

It calls each subclass symtab_checks() to test the required conditions to that specific kernel implementation.

Parameters:

  • context (ContextInterface) – The volatility3 context on which to operate

  • kernel_module_name (str) – The name of the table containing the kernel symbols

Yields:

The kmsg records. Same as _run()

Return type:

Iterator[Tuple[int, str, str, int, int, str, bool]]

subscribed_protocols()

Allows to select which PROTO_HOOKS protocols will be processed by the Netfiler subclass.

Return type:

Tuple[str]

classmethod symtab_checks(vmlinux)[source]

This method on each sublasss will be called to evaluate if the kernel being analyzed fulfill the type & symbols requirements for the implementation. The first class returning True will be instantiated and called via the run() method.

Returns:

True if the kernel being analyzed fulfill the class requirements.

Return type:

bool

class NetfilterImp_4_16_to_latest(context, kernel_module_name)[source]

Bases: NetfilterImp_4_14_to_4_16

The multidimensional array of nf_hook_entries was split in a one-dimensional array per each protocol.

struct net {

struct netns_nf nf; … }

struct netns_nf {

struct nf_hook_entries * hooks_ipv4[NF_INET_NUMHOOKS]; struct nf_hook_entries * hooks_ipv6[NF_INET_NUMHOOKS]; struct nf_hook_entries * hooks_arp[NF_ARP_NUMHOOKS]; struct nf_hook_entries * hooks_bridge[NF_INET_NUMHOOKS]; struct nf_hook_entries * hooks_decnet[NF_DN_NUMHOOKS]; … }

struct nf_hook_entries {

u16 num_hook_entries; /* plus padding */ struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[]; }

struct nf_hook_entry {
nf_hookfn *hook;

void *priv; }

(*) Even though the hook address is in the struct nf_hook_entry, we use the original nf_hook_ops hook address value, the one which was filled by the user, to make it uniform to all the implementations.

NF_MAX_HOOKS = 8
PROTO_HOOKS = (Proto(name='UNSPEC', hooks=()), Proto(name='INET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='IPV4', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='ARP', hooks=('IN', 'OUT', 'FORWARD')), Proto(name='UNSPEC', hooks=()), Proto(name='NETDEV', hooks=('INGRESS', 'EGRESS')), Proto(name='UNSPEC', hooks=()), Proto(name='BRIDGE', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='UNSPEC', hooks=()), Proto(name='IPV6', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='DECNET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING', 'HELLO', 'ROUTE')))
build_nf_hook_ops_array(nf_hook_entries)

Function helper to build the nf_hook_ops array when it is not part of the struct ‘nf_hook_entries’ definition.

nf_hook_ops was stored adjacent in memory to the nf_hook_entry array, in the new struct ‘nf_hook_entries’. However, this ‘nf_hooks_ops’ array ‘orig_ops’ is not part of the ‘nf_hook_entries’ struct. So, we need to calculate the offset.

struct nf_hook_entries {

u16 num_hook_entries; /* plus padding */ struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[];

}

get_hook_ops(hook_container, proto_idx, hook_idx)

Given the hook_container obtained from get_hooks_container(), it returns an iterable of ‘nf_hook_ops’ elements for a corresponding protocol and hook type.

This is the most variable/unstable part of all Netfilter hook designs, it changes almost in every single implementation.

get_hooks_container(net, proto_name, hook_name)[source]

Returns the data structure used in a specific kernel implementation to store the hooks for a respective namespace and protocol.

Except for kernels < 4.3, all the implementations use network namespaces. Also the data structure which contains the hooks, even though it changes its implementation and/or data type, it is always in this location.

static get_member_type(vol_type, member_name)

Returns a list of types/subtypes belonging to the given type member.

Parameters:
Returns:

A list of types/subtypes

Return type:

list

get_module_name_for_address(addr)

Helper to obtain the module and symbol name in the format needed for the output of this plugin.

Return type:

str

get_net_namespaces()

Common function to retrieve the different namespaces. From 4.3 on, all the implementations use network namespaces.

get_nf_hook_entries(nf_hooks_addr, proto_idx, hook_idx)[source]

This allows to support different hook array implementations from this version on. For instance, in kernels >= 4.16 this multi-dimensional array is split in one-dimensional array of pointers to ‘nf_hooks_entries’ per each protocol.

get_symbol_fullname(symbol_basename)

Given a short symbol or type name, it returns its full name

Return type:

str

classmethod run_all(context, kernel_module_name)

It calls each subclass symtab_checks() to test the required conditions to that specific kernel implementation.

Parameters:

  • context (ContextInterface) – The volatility3 context on which to operate

  • kernel_module_name (str) – The name of the table containing the kernel symbols

Yields:

The kmsg records. Same as _run()

Return type:

Iterator[Tuple[int, str, str, int, int, str, bool]]

subscribed_protocols()

Allows to select which PROTO_HOOKS protocols will be processed by the Netfiler subclass.

Return type:

Tuple[str]

classmethod symtab_checks(vmlinux)[source]

This method on each sublasss will be called to evaluate if the kernel being analyzed fulfill the type & symbols requirements for the implementation. The first class returning True will be instantiated and called via the run() method.

Returns:

True if the kernel being analyzed fulfill the class requirements.

Return type:

bool

class NetfilterImp_4_3_to_4_9(context, kernel_module_name)[source]

Bases: AbstractNetfilter

Netfilter hooks were added to network namepaces in 4.3. It is still implemented as a linked list of ‘struct nf_hook_ops’ type but inside a network namespace. One linked list per protocol per hook type.

struct net { … struct netns_nf nf; … } struct netns_nf { …

struct list_head hooks[NFPROTO_NUMPROTO][NF_MAX_HOOKS]; … }

NF_MAX_HOOKS = 8
PROTO_HOOKS = (Proto(name='UNSPEC', hooks=()), Proto(name='INET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='IPV4', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='ARP', hooks=('IN', 'OUT', 'FORWARD')), Proto(name='UNSPEC', hooks=()), Proto(name='NETDEV', hooks=('INGRESS', 'EGRESS')), Proto(name='UNSPEC', hooks=()), Proto(name='BRIDGE', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='UNSPEC', hooks=()), Proto(name='IPV6', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='DECNET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING', 'HELLO', 'ROUTE')))
build_nf_hook_ops_array(nf_hook_entries)

Function helper to build the nf_hook_ops array when it is not part of the struct ‘nf_hook_entries’ definition.

nf_hook_ops was stored adjacent in memory to the nf_hook_entry array, in the new struct ‘nf_hook_entries’. However, this ‘nf_hooks_ops’ array ‘orig_ops’ is not part of the ‘nf_hook_entries’ struct. So, we need to calculate the offset.

struct nf_hook_entries {

u16 num_hook_entries; /* plus padding */ struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[];

}

get_hook_ops(hook_container, proto_idx, hook_idx)[source]

Given the hook_container obtained from get_hooks_container(), it returns an iterable of ‘nf_hook_ops’ elements for a corresponding protocol and hook type.

This is the most variable/unstable part of all Netfilter hook designs, it changes almost in every single implementation.

get_hooks_container(net, proto_name, hook_name)

Returns the data structure used in a specific kernel implementation to store the hooks for a respective namespace and protocol.

Except for kernels < 4.3, all the implementations use network namespaces. Also the data structure which contains the hooks, even though it changes its implementation and/or data type, it is always in this location.

static get_member_type(vol_type, member_name)

Returns a list of types/subtypes belonging to the given type member.

Parameters:
Returns:

A list of types/subtypes

Return type:

list

get_module_name_for_address(addr)

Helper to obtain the module and symbol name in the format needed for the output of this plugin.

Return type:

str

get_net_namespaces()

Common function to retrieve the different namespaces. From 4.3 on, all the implementations use network namespaces.

get_symbol_fullname(symbol_basename)

Given a short symbol or type name, it returns its full name

Return type:

str

classmethod run_all(context, kernel_module_name)

It calls each subclass symtab_checks() to test the required conditions to that specific kernel implementation.

Parameters:

  • context (ContextInterface) – The volatility3 context on which to operate

  • kernel_module_name (str) – The name of the table containing the kernel symbols

Yields:

The kmsg records. Same as _run()

Return type:

Iterator[Tuple[int, str, str, int, int, str, bool]]

subscribed_protocols()

Allows to select which PROTO_HOOKS protocols will be processed by the Netfiler subclass.

Return type:

Tuple[str]

classmethod symtab_checks(vmlinux)[source]

This method on each sublasss will be called to evaluate if the kernel being analyzed fulfill the type & symbols requirements for the implementation. The first class returning True will be instantiated and called via the run() method.

Returns:

True if the kernel being analyzed fulfill the class requirements.

Return type:

bool

class NetfilterImp_4_9_to_4_14(context, kernel_module_name)[source]

Bases: AbstractNetfilter

In this range of kernel versions, the doubly-linked lists of netfilter hooks were replaced by an array of arrays of ‘nf_hook_entry’ pointers in a singly-linked lists.

struct net { … struct netns_nf nf; … } struct netns_nf { ..

struct nf_hook_entry __rcu *hooks[NFPROTO_NUMPROTO][NF_MAX_HOOKS]; … }

Also in v4.10 the struct nf_hook_entry changed, a hook function pointer was added to it. However, for simplicity of this design, we will still take the hook address from the ‘nf_hook_ops’. As per v5.0-rc2, the hook address is duplicated in both sides. - v4.9:

struct nf_hook_entry {

struct nf_hook_entry *next; struct nf_hook_ops ops; const struct nf_hook_ops *orig_ops; };

  • v4.10:
    struct nf_hook_entry {

    struct nf_hook_entry *next; nf_hookfn *hook; void *priv; const struct nf_hook_ops *orig_ops; };

(*) Even though the hook address is in the struct ‘nf_hook_entry’, we use the original ‘nf_hook_ops’ hook address value, the one which was filled by the user, to make it uniform to all the implementations.

NF_MAX_HOOKS = 8
PROTO_HOOKS = (Proto(name='UNSPEC', hooks=()), Proto(name='INET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='IPV4', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='ARP', hooks=('IN', 'OUT', 'FORWARD')), Proto(name='UNSPEC', hooks=()), Proto(name='NETDEV', hooks=('INGRESS', 'EGRESS')), Proto(name='UNSPEC', hooks=()), Proto(name='BRIDGE', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='UNSPEC', hooks=()), Proto(name='IPV6', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='DECNET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING', 'HELLO', 'ROUTE')))
build_nf_hook_ops_array(nf_hook_entries)

Function helper to build the nf_hook_ops array when it is not part of the struct ‘nf_hook_entries’ definition.

nf_hook_ops was stored adjacent in memory to the nf_hook_entry array, in the new struct ‘nf_hook_entries’. However, this ‘nf_hooks_ops’ array ‘orig_ops’ is not part of the ‘nf_hook_entries’ struct. So, we need to calculate the offset.

struct nf_hook_entries {

u16 num_hook_entries; /* plus padding */ struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[];

}

get_hook_ops(hook_container, proto_idx, hook_idx)[source]

Given the hook_container obtained from get_hooks_container(), it returns an iterable of ‘nf_hook_ops’ elements for a corresponding protocol and hook type.

This is the most variable/unstable part of all Netfilter hook designs, it changes almost in every single implementation.

get_hooks_container(net, proto_name, hook_name)

Returns the data structure used in a specific kernel implementation to store the hooks for a respective namespace and protocol.

Except for kernels < 4.3, all the implementations use network namespaces. Also the data structure which contains the hooks, even though it changes its implementation and/or data type, it is always in this location.

static get_member_type(vol_type, member_name)

Returns a list of types/subtypes belonging to the given type member.

Parameters:
Returns:

A list of types/subtypes

Return type:

list

get_module_name_for_address(addr)

Helper to obtain the module and symbol name in the format needed for the output of this plugin.

Return type:

str

get_net_namespaces()

Common function to retrieve the different namespaces. From 4.3 on, all the implementations use network namespaces.

get_symbol_fullname(symbol_basename)

Given a short symbol or type name, it returns its full name

Return type:

str

classmethod run_all(context, kernel_module_name)

It calls each subclass symtab_checks() to test the required conditions to that specific kernel implementation.

Parameters:

  • context (ContextInterface) – The volatility3 context on which to operate

  • kernel_module_name (str) – The name of the table containing the kernel symbols

Yields:

The kmsg records. Same as _run()

Return type:

Iterator[Tuple[int, str, str, int, int, str, bool]]

subscribed_protocols()

Allows to select which PROTO_HOOKS protocols will be processed by the Netfiler subclass.

Return type:

Tuple[str]

classmethod symtab_checks(vmlinux)[source]

This method on each sublasss will be called to evaluate if the kernel being analyzed fulfill the type & symbols requirements for the implementation. The first class returning True will be instantiated and called via the run() method.

Returns:

True if the kernel being analyzed fulfill the class requirements.

Return type:

bool

class NetfilterImp_to_4_3(context, kernel_module_name)[source]

Bases: AbstractNetfilter

At this point, Netfilter hooks were implemented as a linked list of struct ‘nf_hook_ops’ type. One linked list per protocol per hook type. It was like that until 4.2.8.

struct list_head nf_hooks[NFPROTO_NUMPROTO][NF_MAX_HOOKS];

NF_MAX_HOOKS = 8
PROTO_HOOKS = (Proto(name='UNSPEC', hooks=()), Proto(name='INET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='IPV4', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='ARP', hooks=('IN', 'OUT', 'FORWARD')), Proto(name='UNSPEC', hooks=()), Proto(name='NETDEV', hooks=('INGRESS', 'EGRESS')), Proto(name='UNSPEC', hooks=()), Proto(name='BRIDGE', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='UNSPEC', hooks=()), Proto(name='IPV6', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='DECNET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING', 'HELLO', 'ROUTE')))
build_nf_hook_ops_array(nf_hook_entries)

Function helper to build the nf_hook_ops array when it is not part of the struct ‘nf_hook_entries’ definition.

nf_hook_ops was stored adjacent in memory to the nf_hook_entry array, in the new struct ‘nf_hook_entries’. However, this ‘nf_hooks_ops’ array ‘orig_ops’ is not part of the ‘nf_hook_entries’ struct. So, we need to calculate the offset.

struct nf_hook_entries {

u16 num_hook_entries; /* plus padding */ struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[];

}

get_hook_ops(hook_container, proto_idx, hook_idx)[source]

Given the hook_container obtained from get_hooks_container(), it returns an iterable of ‘nf_hook_ops’ elements for a corresponding protocol and hook type.

This is the most variable/unstable part of all Netfilter hook designs, it changes almost in every single implementation.

get_hooks_container(net, proto_name, hook_name)[source]

Returns the data structure used in a specific kernel implementation to store the hooks for a respective namespace and protocol.

Except for kernels < 4.3, all the implementations use network namespaces. Also the data structure which contains the hooks, even though it changes its implementation and/or data type, it is always in this location.

static get_member_type(vol_type, member_name)

Returns a list of types/subtypes belonging to the given type member.

Parameters:
Returns:

A list of types/subtypes

Return type:

list

get_module_name_for_address(addr)

Helper to obtain the module and symbol name in the format needed for the output of this plugin.

Return type:

str

get_net_namespaces()[source]

Common function to retrieve the different namespaces. From 4.3 on, all the implementations use network namespaces.

get_symbol_fullname(symbol_basename)

Given a short symbol or type name, it returns its full name

Return type:

str

classmethod run_all(context, kernel_module_name)

It calls each subclass symtab_checks() to test the required conditions to that specific kernel implementation.

Parameters:

  • context (ContextInterface) – The volatility3 context on which to operate

  • kernel_module_name (str) – The name of the table containing the kernel symbols

Yields:

The kmsg records. Same as _run()

Return type:

Iterator[Tuple[int, str, str, int, int, str, bool]]

subscribed_protocols()

Allows to select which PROTO_HOOKS protocols will be processed by the Netfiler subclass.

Return type:

Tuple[str]

classmethod symtab_checks(vmlinux)[source]

This method on each sublasss will be called to evaluate if the kernel being analyzed fulfill the type & symbols requirements for the implementation. The first class returning True will be instantiated and called via the run() method.

Returns:

True if the kernel being analyzed fulfill the class requirements.

Return type:

bool

class NetfilterNetDevImp_4_14_to_latest(context, kernel_module_name)[source]

Bases: AbstractNetfilterNetDev

In 4.14 the hook list was converted to an array of pointers inside the struct ‘nf_hook_entries’: struct nf_hook_entries * nf_hooks_ingress; struct nf_hook_entries {

u16 num_hook_entries; struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[]; }

NF_MAX_HOOKS = 8
PROTO_HOOKS = (Proto(name='UNSPEC', hooks=()), Proto(name='INET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='IPV4', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='ARP', hooks=('IN', 'OUT', 'FORWARD')), Proto(name='UNSPEC', hooks=()), Proto(name='NETDEV', hooks=('INGRESS', 'EGRESS')), Proto(name='UNSPEC', hooks=()), Proto(name='BRIDGE', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='UNSPEC', hooks=()), Proto(name='IPV6', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='DECNET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING', 'HELLO', 'ROUTE')))
build_nf_hook_ops_array(nf_hook_entries)

Function helper to build the nf_hook_ops array when it is not part of the struct ‘nf_hook_entries’ definition.

nf_hook_ops was stored adjacent in memory to the nf_hook_entry array, in the new struct ‘nf_hook_entries’. However, this ‘nf_hooks_ops’ array ‘orig_ops’ is not part of the ‘nf_hook_entries’ struct. So, we need to calculate the offset.

struct nf_hook_entries {

u16 num_hook_entries; /* plus padding */ struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[];

}

get_hook_ops(hook_container, proto_idx, hook_idx)[source]

Given the hook_container obtained from get_hooks_container(), it returns an iterable of ‘nf_hook_ops’ elements for a corresponding protocol and hook type.

This is the most variable/unstable part of all Netfilter hook designs, it changes almost in every single implementation.

get_hooks_container(net, proto_name, hook_name)

Returns the data structure used in a specific kernel implementation to store the hooks for a respective namespace and protocol.

Except for kernels < 4.3, all the implementations use network namespaces. Also the data structure which contains the hooks, even though it changes its implementation and/or data type, it is always in this location.

static get_member_type(vol_type, member_name)

Returns a list of types/subtypes belonging to the given type member.

Parameters:
Returns:

A list of types/subtypes

Return type:

list

get_module_name_for_address(addr)

Helper to obtain the module and symbol name in the format needed for the output of this plugin.

Return type:

str

get_net_namespaces()

Common function to retrieve the different namespaces. From 4.3 on, all the implementations use network namespaces.

get_symbol_fullname(symbol_basename)

Given a short symbol or type name, it returns its full name

Return type:

str

classmethod run_all(context, kernel_module_name)

It calls each subclass symtab_checks() to test the required conditions to that specific kernel implementation.

Parameters:

  • context (ContextInterface) – The volatility3 context on which to operate

  • kernel_module_name (str) – The name of the table containing the kernel symbols

Yields:

The kmsg records. Same as _run()

Return type:

Iterator[Tuple[int, str, str, int, int, str, bool]]

subscribed_protocols()

Allows to select which PROTO_HOOKS protocols will be processed by the Netfiler subclass.

classmethod symtab_checks(vmlinux)[source]

This method on each sublasss will be called to evaluate if the kernel being analyzed fulfill the type & symbols requirements for the implementation. The first class returning True will be instantiated and called via the run() method.

Returns:

True if the kernel being analyzed fulfill the class requirements.

Return type:

bool

class NetfilterNetDevImp_4_2_to_4_9(context, kernel_module_name)[source]

Bases: AbstractNetfilterNetDev

This is the first version of Netfilter Ingress hooks which was implemented using a doubly-linked list of ‘nf_hook_ops’.

struct list_head nf_hooks_ingress;

NF_MAX_HOOKS = 8
PROTO_HOOKS = (Proto(name='UNSPEC', hooks=()), Proto(name='INET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='IPV4', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='ARP', hooks=('IN', 'OUT', 'FORWARD')), Proto(name='UNSPEC', hooks=()), Proto(name='NETDEV', hooks=('INGRESS', 'EGRESS')), Proto(name='UNSPEC', hooks=()), Proto(name='BRIDGE', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='UNSPEC', hooks=()), Proto(name='IPV6', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='DECNET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING', 'HELLO', 'ROUTE')))
build_nf_hook_ops_array(nf_hook_entries)

Function helper to build the nf_hook_ops array when it is not part of the struct ‘nf_hook_entries’ definition.

nf_hook_ops was stored adjacent in memory to the nf_hook_entry array, in the new struct ‘nf_hook_entries’. However, this ‘nf_hooks_ops’ array ‘orig_ops’ is not part of the ‘nf_hook_entries’ struct. So, we need to calculate the offset.

struct nf_hook_entries {

u16 num_hook_entries; /* plus padding */ struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[];

}

get_hook_ops(hook_container, proto_idx, hook_idx)[source]

Given the hook_container obtained from get_hooks_container(), it returns an iterable of ‘nf_hook_ops’ elements for a corresponding protocol and hook type.

This is the most variable/unstable part of all Netfilter hook designs, it changes almost in every single implementation.

get_hooks_container(net, proto_name, hook_name)

Returns the data structure used in a specific kernel implementation to store the hooks for a respective namespace and protocol.

Except for kernels < 4.3, all the implementations use network namespaces. Also the data structure which contains the hooks, even though it changes its implementation and/or data type, it is always in this location.

static get_member_type(vol_type, member_name)

Returns a list of types/subtypes belonging to the given type member.

Parameters:
Returns:

A list of types/subtypes

Return type:

list

get_module_name_for_address(addr)

Helper to obtain the module and symbol name in the format needed for the output of this plugin.

Return type:

str

get_net_namespaces()

Common function to retrieve the different namespaces. From 4.3 on, all the implementations use network namespaces.

get_symbol_fullname(symbol_basename)

Given a short symbol or type name, it returns its full name

Return type:

str

classmethod run_all(context, kernel_module_name)

It calls each subclass symtab_checks() to test the required conditions to that specific kernel implementation.

Parameters:

  • context (ContextInterface) – The volatility3 context on which to operate

  • kernel_module_name (str) – The name of the table containing the kernel symbols

Yields:

The kmsg records. Same as _run()

Return type:

Iterator[Tuple[int, str, str, int, int, str, bool]]

subscribed_protocols()

Allows to select which PROTO_HOOKS protocols will be processed by the Netfiler subclass.

classmethod symtab_checks(vmlinux)[source]

This method on each sublasss will be called to evaluate if the kernel being analyzed fulfill the type & symbols requirements for the implementation. The first class returning True will be instantiated and called via the run() method.

Returns:

True if the kernel being analyzed fulfill the class requirements.

Return type:

bool

class NetfilterNetDevImp_4_9_to_4_14(context, kernel_module_name)[source]

Bases: AbstractNetfilterNetDev

In 4.9 it was changed to a simple singly-linked list. struct nf_hook_entry * nf_hooks_ingress;

NF_MAX_HOOKS = 8
PROTO_HOOKS = (Proto(name='UNSPEC', hooks=()), Proto(name='INET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='IPV4', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='ARP', hooks=('IN', 'OUT', 'FORWARD')), Proto(name='UNSPEC', hooks=()), Proto(name='NETDEV', hooks=('INGRESS', 'EGRESS')), Proto(name='UNSPEC', hooks=()), Proto(name='BRIDGE', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='UNSPEC', hooks=()), Proto(name='IPV6', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING')), Proto(name='UNSPEC', hooks=()), Proto(name='DECNET', hooks=('PRE_ROUTING', 'LOCAL_IN', 'FORWARD', 'LOCAL_OUT', 'POST_ROUTING', 'HELLO', 'ROUTE')))
build_nf_hook_ops_array(nf_hook_entries)

Function helper to build the nf_hook_ops array when it is not part of the struct ‘nf_hook_entries’ definition.

nf_hook_ops was stored adjacent in memory to the nf_hook_entry array, in the new struct ‘nf_hook_entries’. However, this ‘nf_hooks_ops’ array ‘orig_ops’ is not part of the ‘nf_hook_entries’ struct. So, we need to calculate the offset.

struct nf_hook_entries {

u16 num_hook_entries; /* plus padding */ struct nf_hook_entry hooks[]; //const struct nf_hook_ops *orig_ops[];

}

get_hook_ops(hook_container, proto_idx, hook_idx)[source]

Given the hook_container obtained from get_hooks_container(), it returns an iterable of ‘nf_hook_ops’ elements for a corresponding protocol and hook type.

This is the most variable/unstable part of all Netfilter hook designs, it changes almost in every single implementation.

get_hooks_container(net, proto_name, hook_name)

Returns the data structure used in a specific kernel implementation to store the hooks for a respective namespace and protocol.

Except for kernels < 4.3, all the implementations use network namespaces. Also the data structure which contains the hooks, even though it changes its implementation and/or data type, it is always in this location.

static get_member_type(vol_type, member_name)

Returns a list of types/subtypes belonging to the given type member.

Parameters:
Returns:

A list of types/subtypes

Return type:

list

get_module_name_for_address(addr)

Helper to obtain the module and symbol name in the format needed for the output of this plugin.

Return type:

str

get_net_namespaces()

Common function to retrieve the different namespaces. From 4.3 on, all the implementations use network namespaces.

get_symbol_fullname(symbol_basename)

Given a short symbol or type name, it returns its full name

Return type:

str

classmethod run_all(context, kernel_module_name)

It calls each subclass symtab_checks() to test the required conditions to that specific kernel implementation.

Parameters:

  • context (ContextInterface) – The volatility3 context on which to operate

  • kernel_module_name (str) – The name of the table containing the kernel symbols

Yields:

The kmsg records. Same as _run()

Return type:

Iterator[Tuple[int, str, str, int, int, str, bool]]

subscribed_protocols()

Allows to select which PROTO_HOOKS protocols will be processed by the Netfiler subclass.

classmethod symtab_checks(vmlinux)[source]

This method on each sublasss will be called to evaluate if the kernel being analyzed fulfill the type & symbols requirements for the implementation. The first class returning True will be instantiated and called via the run() method.

Returns:

True if the kernel being analyzed fulfill the class requirements.

Return type:

bool

class Proto(name, hooks=<factory>)[source]

Bases: object

hooks: Tuple[str]
name: str