Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Netfilter all kernels #577

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

gcmoreira
Copy link
Contributor

@gcmoreira gcmoreira commented Jan 18, 2019

Netfilter plugin improvements:

  • Added support for every single Netfilter implementation in every single kernel version so far:
    • Supported Netfilter hooks implementations:
      • v2.6ish to v4.2.8
      • v4.3 to v4.8.17
      • v4.9 to 4.13.16
      • v4.14 to v4.15.18
      • v4.16 to latest
    • Supported Netfilter Ingress hooks implementations:
      • v4.2 to 4.8.17
      • v4.9 to 4.13.16
      • v4.14 to latest
  • It gathers Netfilter hook information for all existing protocol families, IPV4, IPv6, ARP, BRIDGE, DECNET and INGRESS hooks.
  • Two new columns were added to the output report, the network namespace id and the module name or symbol name to which the hook address belongs to, allowing us to easily identify suspicious kernel modules using network hooks.
  • If a module is part of the kernel text, it also resolves the symbol to that specific address which is showed between square brackets, ie: [selinux_ipv4_forward]
  • Added function to the Linux common API to find LKM module addresses, similar to the one in mac implementation but it also resolve kernel symbols.
  • Tested using Linux Kernels 3.10, 4.4.0, 4.10.0, 4.15.0 and 4.18.0.

Old Netfilter plugin output
New Netfilter plugin output

 * Added LKM lookup, showing the kernel module name to which the hook belongs to.
 * If the module is part of the kernel text, it also resolves the symbol to that specific address. It is showed between square brackets, ie: [selinux_ipv4_forward]
 * All kernel exisiting protocols were added (unless until kernel v4.20). It now allows to identify for instance IPv6, ARP, BRIDGE (ebtables), etc.
 * Fixed wrong number of hooks and protos. Removed hardcoded sizes.
 * Added function to the Linux common API to find LKM module addresses, similar to the one in mac implementation but it also resolve kernel symbols.
- Added support for every single Netfilter implementation in every single kernel version so far (v2.6ish to v5.0-rc2).
- It gathers Netfilter hook information for all existing protocol families: IPV4, IPv6, ARP, BRIDGE, DECNET and INGRESS hooks.
- Two new columns were added to the output report, the network namespace id and the module name or symbol name to which the hook address belongs to, allowing us to easily identify suspicious kernel modules using network hooks.
- If a module is part of the kernel text, it also resolves the symbol to that specific address which is showed between square brackets, ie: [selinux_ipv4_forward]
- Added function to the Linux common API to find LKM module addresses, similar to the one in mac implementation but it also resolve kernel symbols.
    - Converted unnecesary class methods to instance methods.
    - Improved docstrings documentation for some of the class methods plus an explanation how the callbacks work.
…d it could be calculated at that point using the protocol index.

- Using the same argument name for "hook_container" in get_hook_ops method. It's reassigned to a more meanful variable name in every callback.
Instead, the specific pointer to nf_hook_entries is calculated.
@atcuno
Copy link
Contributor

atcuno commented Jul 13, 2020

@gcmoreira

My apologies for not getting to this sooner. This is very nice work.

Is this something you would consider porting to Volatility 3? If so, you should consider our plugin contest that is currently running: https://volatility-labs.blogspot.com/2020/05/the-8th-annual-volatility-plugin-contest.html

I also plan to your code integrated in Volatility 2 soon.

@gcmoreira
Copy link
Contributor Author

gcmoreira commented Jul 16, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants