Skip to content

Netfilter

Overview

  • Vendor:
  • Supported environment:
  • Version compatibility:
  • Detection based on: Telemetry
  • Supported application or feature:

Netfilter is a framework provided by the Linux kernel that offers various functions and operations for packet filtering, network address translation, and port translation.

The firewall ruleset might be configured by using several user-space tools such as Iptables or Nftables or even with high level configuration tools such as firewalld, UFW or ferm. The framework also provides several ways to log events (LOG, NFLOG, ULOG, etc.).

The only requirement from Sekoia.io’s perspective is that your logs uses the following prefix: IPTABLES: XXX (XXX is user configurable and represents the action, could be dropped or accept for example).

Configure

As of now, the main solution to send Netfilter events to Sekoia.io is to use a Rsyslog concentrator. Please share your experiences with other recipes by editing this documentation.

Rsyslog

Please consult the Rsyslog Transport documentation to forward these logs to Sekoia.io

Configure Netfilter using Iptables

The first step is to configure Netfilter to log the awaited trafic. For example, if you want to only allow HTTP and HTTPS trafic and log everything else, you could use the following iptables commands:

# Create a chain that logs packets and then drops them.
$ iptables -N DROP_LOGGING
$ iptables -A DROP_LOGGING -m limit --limit 60/min -j LOG --log-prefix "IPTables: Dropped: " --log-level 4
$ iptables -A DROP_LOGGING -j DROP

# Allow established communications.
$ iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow HTTP communications.
$ iptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

# Log and drop everything else.
$ iptables -A INPUT -j DROP_LOGGING

Configure Netfilter using Nftables

Nftables is often installed by default as a replacement for iptables on the latest linux distributions. To log events with Nftables the first step is to install ulogd2. Use the following command to install it : 

sudo apt install ulogd2

You can then verify that the service is running with that command : 

sudo systemctl status ulogd2.service

You can now configure the file /etc/nftables.conf to log what you want. For instance, if you want to log all the new UDP and TCP traffic that go outside your network, you can use this configuration :

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
        chain input {
                type filter hook input priority 0;
        }
        chain forward {
                type filter hook forward priority 0;
        }
        chain output {
                type filter hook output priority 0; policy accept;

                # Log all the new TCP connections
                ct state new tcp dport 0-65535 log prefix "IPTABLES: ACCEPT " level info accept;
                # Log all the new UDP traffic
                ct state new udp dport 0-65535 log prefix "IPTABLES: ACCEPT " level info accept;
        }
}

Finally, ensure that Nftables is running and the service is enabled : 

sudo systemctl start nftables && sudo systemctl enable nftables

Further Reading

Raw Events Samples

In this section, you will find examples of raw logs as generated natively by the source. These examples are provided to help integrators understand the data format before ingestion into Sekoia.io. It is crucial for setting up the correct parsing stages and ensuring that all relevant information is captured.

DA->FEDERATEUR ACCEPT IN=enp4s0f0.82 OUT=enp4s0f1 MAC=14:58:d0:b4:65:b8:02:01:c0:a8:e0:26:08:00 SRC=192.168.224.43 DST=192.168.100.230 LEN=52 TOS=08 PREC=0x00 TTL=126 ID=0 DF PROTO=TCP SPT=44606 DPT=80 SEQ=2504400626 ACK=0 WINDOW=64612 SYN URGP=0 MARK=0

INPUT DFLT DROP IN=enp4s0f0.82 OUT=enp4s0f1 MAC=14:58:d0:b4:65:b8:02:01:c0:a8:e0:26:08:00 SRC=192.168.224.43 DST=192.168.100.230 LEN=52 TOS=08 PREC=0x00 TTL=126 ID=0 DF PROTO=TCP SPT=44606 DPT=80 SEQ=2504400626 ACK=0 WINDOW=64612 SYN URGP=0 MARK=0

INTERNET SPOOFING DROP  IN=enp4s0f1 OUT=enp5s0f1 MAC=14:58:d0:b4:65:bc:d8:67:d9:0f:85:41:08:00 SRC=10.16.123.245 DST=192.168.1.47 LEN=132 TOS=00 PREC=0x00 TTL=126 ID=26580 PROTO=UDP SPT=61829 DPT=65267 LEN=112 MARK=0

IPTABLES IN=net0 OUT=docker0 MAC=00:e0:4c:68:00:64:70:df:2f:d0:8c:a7:08:00 SRC=172.217.22.142 DST=172.17.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=54 ID=0 PROTO=ICMP TYPE=0 CODE=0 ID=20 SEQ=

IPTABLES IN=net0 OUT=docker0 MAC=00:e0:4c:68:00:64:70:df:2f:d0:8c:a7:08:00 SRC=216.58.213.163 DST=172.17.0.2 LEN=60 TOS=0x00 PREC=0x00 TTL=120 ID=51233 PROTO=TCP SPT=80 DPT=51212 WINDOW=60192 RES=0x00 ACK SYN URGP=0

Detection section

The following section provides information for those who wish to learn more about the detection capabilities enabled by collecting this intake. It includes details about the built-in rule catalog, event categories, and ECS fields extracted from raw events. This is essential for users aiming to create custom detection rules, perform hunting activities, or pivot in the events page.

The following Sekoia.io built-in rules match the intake Netfilter. This documentation is updated automatically and is based solely on the fields used by the intake which are checked against our rules. This means that some rules will be listed but might not be relevant with the intake.

SEKOIA.IO x Netfilter on ATT&CK Navigator

Cryptomining

Detection of domain names potentially related to cryptomining activities.

  • Effort: master
Dynamic DNS Contacted

Detect communication with dynamic dns domain. This kind of domain is often used by attackers. This rule can trigger false positive in non-controlled environment because dynamic dns is not always malicious.

  • Effort: master
Exfiltration Domain

Detects traffic toward a domain flagged as a possible exfiltration vector.

  • Effort: master
Internet Scanner

Detects known scanner IP addresses. Alert is only raised when the scan hits an opened port, on TCP or UDP. This could be a very noisy rule, so be careful to check your detection perimeter before activation.

  • Effort: master
Internet Scanner Target

Detects known scanner IP addresses. Alert is only raised when the scan hits an opened port, on TCP or UDP and group by target address. This could be a very noisy rule, so be careful to check your detection perimeter before activation.

  • Effort: master
Remote Access Tool Domain

Detects traffic toward a domain flagged as a Remote Administration Tool (RAT).

  • Effort: master
SEKOIA.IO Intelligence Feed

Detect threats based on indicators of compromise (IOCs) collected by SEKOIA's Threat and Detection Research team.

  • Effort: elementary
Sekoia.io EICAR Detection

Detects observables in Sekoia.io CTI tagged as EICAR, which are fake samples meant to test detection.

  • Effort: master
TOR Usage

Detects TOR usage, based on the IP address and the destination port (filtered on NTP). TOR is short for The Onion Router, and it gets its name from how it works. TOR intercepts the network traffic from one or more apps on user’s computer, usually the user web browser, and shuffles it through a number of randomly-chosen computers before passing it on to its destination. This disguises user location, and makes it harder for servers to pick him/her out on repeat visits, or to tie together separate visits to different sites, this making tracking and surveillance more difficult. Before a network packet starts its journey, user’s computer chooses a random list of relays and repeatedly encrypts the data in multiple layers, like an onion. Each relay knows only enough to strip off the outermost layer of encryption, before passing what’s left on to the next relay in the list.

  • Effort: master
TOR Usage Generic Rule

Detects TOR usage globally, whether the IP is a destination or source. TOR is short for The Onion Router, and it gets its name from how it works. TOR intercepts the network traffic from one or more apps on user’s computer, usually the user web browser, and shuffles it through a number of randomly-chosen computers before passing it on to its destination. This disguises user location, and makes it harder for servers to pick him/her out on repeat visits, or to tie together separate visits to different sites, this making tracking and surveillance more difficult. Before a network packet starts its journey, user’s computer chooses a random list of relays and repeatedly encrypts the data in multiple layers, like an onion. Each relay knows only enough to strip off the outermost layer of encryption, before passing what’s left on to the next relay in the list.

  • Effort: master

Event Categories

The following table lists the data source offered by this integration.

Data Source Description
Network device logs Traffic events flowing through are recorded by netfilter
Network protocol analysis Netfilter does traffic analysis at physical/data/transport layers

Transformed Events Samples after Ingestion

This section demonstrates how the raw logs will be transformed by our parsers. It shows the extracted fields that will be available for use in the built-in detection rules and hunting activities in the events page. Understanding these transformations is essential for analysts to create effective detection mechanisms with custom detection rules and to leverage the full potential of the collected data.

{
    "message": "DA->FEDERATEUR ACCEPT IN=enp4s0f0.82 OUT=enp4s0f1 MAC=14:58:d0:b4:65:b8:02:01:c0:a8:e0:26:08:00 SRC=192.168.224.43 DST=192.168.100.230 LEN=52 TOS=08 PREC=0x00 TTL=126 ID=0 DF PROTO=TCP SPT=44606 DPT=80 SEQ=2504400626 ACK=0 WINDOW=64612 SYN URGP=0 MARK=0",
    "event": {
        "outcome": "success"
    },
    "action": {
        "name": "accept",
        "outcome": "success"
    },
    "destination": {
        "address": "192.168.100.230",
        "ip": "192.168.100.230",
        "mac": "14:58:d0:b4:65:b8",
        "port": 80
    },
    "network": {
        "transport": "tcp"
    },
    "related": {
        "ip": [
            "192.168.100.230",
            "192.168.224.43"
        ]
    },
    "source": {
        "address": "192.168.224.43",
        "bytes": 52,
        "ip": "192.168.224.43",
        "mac": "02:01:c0:a8:e0:26",
        "port": 44606
    }
}

{
    "message": "INPUT DFLT DROP IN=enp4s0f0.82 OUT=enp4s0f1 MAC=14:58:d0:b4:65:b8:02:01:c0:a8:e0:26:08:00 SRC=192.168.224.43 DST=192.168.100.230 LEN=52 TOS=08 PREC=0x00 TTL=126 ID=0 DF PROTO=TCP SPT=44606 DPT=80 SEQ=2504400626 ACK=0 WINDOW=64612 SYN URGP=0 MARK=0",
    "event": {
        "outcome": "success"
    },
    "action": {
        "name": "drop",
        "outcome": "success"
    },
    "destination": {
        "address": "192.168.100.230",
        "ip": "192.168.100.230",
        "mac": "14:58:d0:b4:65:b8",
        "port": 80
    },
    "network": {
        "transport": "tcp"
    },
    "related": {
        "ip": [
            "192.168.100.230",
            "192.168.224.43"
        ]
    },
    "source": {
        "address": "192.168.224.43",
        "bytes": 52,
        "ip": "192.168.224.43",
        "mac": "02:01:c0:a8:e0:26",
        "port": 44606
    }
}

{
    "message": "INTERNET SPOOFING DROP  IN=enp4s0f1 OUT=enp5s0f1 MAC=14:58:d0:b4:65:bc:d8:67:d9:0f:85:41:08:00 SRC=10.16.123.245 DST=192.168.1.47 LEN=132 TOS=00 PREC=0x00 TTL=126 ID=26580 PROTO=UDP SPT=61829 DPT=65267 LEN=112 MARK=0",
    "event": {
        "outcome": "success"
    },
    "action": {
        "name": "drop",
        "outcome": "success"
    },
    "destination": {
        "address": "192.168.1.47",
        "ip": "192.168.1.47",
        "mac": "14:58:d0:b4:65:bc",
        "port": 65267
    },
    "network": {
        "transport": "udp"
    },
    "related": {
        "ip": [
            "10.16.123.245",
            "192.168.1.47"
        ]
    },
    "source": {
        "address": "10.16.123.245",
        "bytes": 132,
        "ip": "10.16.123.245",
        "mac": "d8:67:d9:0f:85:41",
        "port": 61829
    }
}

{
    "message": "IPTABLES IN=net0 OUT=docker0 MAC=00:e0:4c:68:00:64:70:df:2f:d0:8c:a7:08:00 SRC=172.217.22.142 DST=172.17.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=54 ID=0 PROTO=ICMP TYPE=0 CODE=0 ID=20 SEQ=",
    "destination": {
        "address": "172.17.0.2",
        "ip": "172.17.0.2",
        "mac": "00:e0:4c:68:00:64"
    },
    "network": {
        "transport": "icmp"
    },
    "related": {
        "ip": [
            "172.17.0.2",
            "172.217.22.142"
        ]
    },
    "source": {
        "address": "172.217.22.142",
        "bytes": 84,
        "ip": "172.217.22.142",
        "mac": "70:df:2f:d0:8c:a7"
    }
}

{
    "message": "IPTABLES IN=net0 OUT=docker0 MAC=00:e0:4c:68:00:64:70:df:2f:d0:8c:a7:08:00 SRC=216.58.213.163 DST=172.17.0.2 LEN=60 TOS=0x00 PREC=0x00 TTL=120 ID=51233 PROTO=TCP SPT=80 DPT=51212 WINDOW=60192 RES=0x00 ACK SYN URGP=0",
    "destination": {
        "address": "172.17.0.2",
        "ip": "172.17.0.2",
        "mac": "00:e0:4c:68:00:64",
        "port": 51212
    },
    "network": {
        "transport": "tcp"
    },
    "related": {
        "ip": [
            "172.17.0.2",
            "216.58.213.163"
        ]
    },
    "source": {
        "address": "216.58.213.163",
        "bytes": 60,
        "ip": "216.58.213.163",
        "mac": "70:df:2f:d0:8c:a7",
        "port": 80
    }
}

Extracted Fields

The following table lists the fields that are extracted, normalized under the ECS format, analyzed and indexed by the parser. It should be noted that infered fields are not listed.

Name Type Description
destination.address keyword Destination network address.
destination.ip ip IP address of the destination.
destination.mac keyword MAC address of the destination.
destination.port long Port of the destination.
network.transport keyword Protocol Name corresponding to the field iana_number.
source.address keyword Source network address.
source.bytes long Bytes sent from the source to the destination.
source.ip ip IP address of the source.
source.mac keyword MAC address of the source.
source.port long Port of the source.

For more information on the Intake Format, please find the code of the Parser, Smart Descriptions, and Supported Events here.