Accelerating Linux Security with eBPF iptables

Matteo Bertrone, Sebastiano Miano, Fulvio Risso, Massimo Tumolo

Department of Control and Computer Engineering, Politecnico di Torino, Italy
CCS CONCEPTS Iptables
Netfilter hooks
PREROUTING INPUT FORWARD OUTPUT POSTROUTING

TC hooks FILTER
Local Routing

• Networks → Firewalls; Programmable networks; Packet XDP hooks

Process Decision

classification; NAT
Routing
Decision FILTER
FILTER

KEYWORDS port
NAT
Routing
NAT
port
(e.g., eth0) Decision (e.g., eth1)

eBPF, iptables, Linux, XDP

ACM Reference Format: Figure 1: Netfilter vs eBPF hooks
Matteo Bertrone, Sebastiano Miano, Fulvio Risso, Massimo Tumolo.
Connection tracking
2018. Accelerating Linux Security with eBPF iptables. In SIGCOMM
INGRESS
TC/XDP Ingress hook Label Packet Store session
Posters and Demos ’18: ACM SIGCOMM 2018 Conference Posters and Ingress Chain
CHAIN
To Linux
Forwarder Stack
Demos, August 20–25, 2018, Budapest, Hungary. ACM, New York, port Label Packet
FORWARD
Store session
CHAIN
NY, USA, 3 pages. https://doi.org/10.1145/3234200.3234228 (e.g., eth0) port
(e.g., eth1)
Egress Chain Local src OUTPUT
Label Packet Store session
Forwarder CHAIN
TC Egress hook Remote src
1 INTRODUCTION
Nowadays, the traditional security features of a Linux sys- Figure 2: Overall data plane structure
tem are centered on iptables, which has been the most
used packet filtering mechanism in the Linux kernel for al- emulates the iptables filtering semantic and exploits a more
most 20+ years. However, the increase in network speed and efficient matching algorithm. Finally, we evaluate our proto-
the transformation of the type of applications running in a type comparing it with the current implementation of ipta-
Linux server has led to the consciousness that the current bles, showing how this allows obtaining a notable advantage
implementation may not be able to cope with the modern re- in terms of performance particularly when a high number
quirements particularly in terms of scalability, as the number of rules is involved, without requiring custom kernels or
of rules is dramatically increasing [2]. invasive software frameworks (e.g., DPDK) that could not be
In recent years, the extended BPF (eBPF) subsystem has allowed in some scenarios (e.g., servers in large datacenters).
been added to the Linux kernel, offering the possibility to exe-
cute (almost) arbitrary code when a packet is received or sent,
2 BPF-IPTABLES DESIGN
including stateful processing. Notably, this does not require The design of bpf-iptables includes two orthogonal as-
any additional kernel module and offers the possibility to pects: (i) the strategy adopted to preserve the semantic of
compile and inject this code dynamically, hence facilitating the iptables firewall policies, and (ii) the data plane archi-
over-the-air updates. The above characteristics make eBPF tecture, which is driven by the algorithm used for packet
a perfect candidate to build an iptables clone such as [1], matching. We leave the detailed techniques and implemen-
which can be considered more an initial proof-of-concept tations to a future paper and focus here on the key design of
that filters traffic based on IP addresses than a full iptables the bpf-iptables architecture.
replacement. This paper starts from the above activities and Iptables filtering semantics. Iptables filters packets either
presents a first eBPF-based prototype, bpf-iptables, which in the INPUT, FORWARD and OUTPUT chains of the Linux Net-
filter [5] framework, which are located in a different position
Permission to make digital or hard copies of all or part of this work for
compared to eBPF hooks (Figure 1). In particular, the XDP
personal or classroom use is granted without fee provided that copies are not
made or distributed for profit or commercial advantage and that copies bear hook, available only for incoming traffic, is located at the
this notice and the full citation on the first page. Copyrights for components earliest point in the networking stack. Instead, the Traffic
of this work owned by others than ACM must be honored. Abstracting with Control (TC) hook, available for both incoming and out-
credit is permitted. To copy otherwise, or republish, to post on servers or to going traffic, is executed either before the PREROUTING or
redistribute to lists, requires prior specific permission and/or a fee. Request
after the POSTROUTING hook. The different position of the
permissions from permissions@acm.org.
SIGCOMM Posters and Demos ’18, August 20–25, 2018, Budapest, Hungary
filtering hooks in Netfilter and eBPF poses non-negligible
© 2018 Association for Computing Machinery. challenges in preserving the semantic of the iptables rules,
ACM ISBN 978-1-4503-5915-3/18/08. . . $15.00 which, when enforced in an eBPF program, operate on a dif-
https://doi.org/10.1145/3234200.3234228 ferent set of traffic compared to the one that would cross the

108
SIGCOMM Posters and Demos ’18, August 20–25, 2018, Budapest, Hungary M. Bertone et al.

chain they are attached to. As an example, a rule “iptables Rule #0: iptables –A INPUT –p tcp --dport 80 –j ACCEPT
Rule #1: iptables –A INPUT --dport 80 –j ACCEPT
-A INPUT -j DROP” drops all the incoming traffic directed to Rule #2: iptables –A INPUT –p udp --dport 53 –j ACCEPT
the current host, but it does not affect the traffic that is being Rule #3: iptables –A INPUT –p tcp --dport 53 –j ACCEPT
Rule #4: iptables –A INPUT –d 10.0.0.0/8 –j ACCEPT
forwarded by the host itself. A similar “drop all” rule, applied Dest. IP Protocol Dest. port
in the ingress XDP/TC eBPF hook will instead drop all the Values
Matched
Value
Matched
Value
Matched
rules rules rules
incoming traffic, also the one that would be forwarded by * 00001
0/0 11110 * 01001
the host itself. bpf-iptables adds an XDP/TC Ingress Chain ... ...
10.0.0.0/8 11111 TCP 11011 80 11001
Forwarder and a TC Egress Chain Forwarder eBPF program UDP 01101 53 00111

(Figure 2) to recognize the actual path of each packet and Input: to 10.1.0.1, TCP, port 80  11111 & 11011 & 11001 = 11001  Rule #0

emulate the iptables filtering behavior, redirecting the packet Figure 3: Example of the LBVS classification pipeline
to the proper filtering (INPUT or FORWARD) chain.
Matching algorithm. Improving the existing linear search 1.2
iptables
9
8 iptables

Throughput (Mpps)

Throughput (Gbps)
bpf-iptables bpf-iptables
of iptables does not appear so difficult. However, many of 1 7
6
0.8
the existing matching algorithms (e.g., cross-product, decision- 0.6
5
4

tree approaches) require either sophisticated data structures 0.4 3

2
0.2 1
that are not available for eBPF programs [4] or an unbounded 0
100 500 1000 2000 4000 7000
0
100 500 1000 2000 4000 7000

amount of memory, which is not desirable for a kernel pro- # of rules # of rules

gram. bpf-iptables uses the Linear Bit Vector Search [3], (a) UDP throughput (forward) (b) TCP throughput (input)
which proved to be reasonably fast while being feasible with Figure 4: bpf-/iptables performance comparison
current Linux kernels (and available eBPF maps).
The algorithm consists in creating a specific bi-dimensional
associates a state to each packet, so that all subsequent chain
table for each field on which packets may match, such as IP
rules can be correctly applied. When the packet leaves the
addresses, TCP/UDP ports, and more. Each table contains the
chains, as result of an ALLOW action, it passes through a sec-
list of unique values for that field present in the given ruleset,
ond conntrack module that saves the state of the session in
plus a wildcard. Each value in the table is associated to a
its internal eBPF map; depending on the chain, the packet is
bitvector of length N , equal to the number of rules, which
then delivered to the Linux stack or forwarded to the output
keeps the list of rules matching that field. Finally, a bitwise
port. On the other side, when a local application sends a
AND of the intermediate bitvectors returns the list of matched
packet out to a netdevice, it will trigger the Egress Chain
rules; the one with the highest priority (corresponding to the
Forwarder program attached to the TC egress hook that,
first rule with 1 in the bitvector) is returned. Each map can
looking at the source IP of the packet decides to forward it
be implemented in a different way, based on the field char-
directly to the output port (because the FORWARD chain has
acteristics (e.g., longest prefix match in case of IP addresses
already processed it) or to jump to the OUTPUT chain where
and ranges; hash tables for TCP/UDP ports). Per-CPU maps
the classification algorithm will be applied.
are used whenever possible to avoid cache pollution among
different CPU cores and increase the effectiveness of paral-
lel processing of multiple packets on different CPU cores. 3 EVALUATION
Thanks to the dynamic code injection of eBPF, we created a We evaluated bpf-iptables by attaching it to both the TC
matching pipeline that contains the minimum number of pro- ingress and egress hook of the host interfaces and compared
cessing blocks required to handle exactly the fields required its performance against iptables in two different cases. In
by the current ruleset, avoiding unnecessary processing for the first test, shown in Figure 4(a), we added an increasing
unused fields. New processing blocks can be added at run- number of rules to the FORWARD chain of the firewall and we
time if the matching against a new field is required, always generated a unidirectional stream of 64B UDP packets. In
keeping the optimal number of programs. the second, shown in Figure 4(b), we added an increasing
Data plane architecture. Figure 2 shows the overall data number of rules to the INGRESS chain to protect locally run-
plane architecture of bpf-iptables. When a packet reaches ning applications, and then we calculated the resulting TCP
a given port, it triggers the Ingress Chain Forwarder program throughput. In both tests, we generated traffic so that only
attached to the TC or XDP hook; depending on whether one CPU core is involved in the processing. Results confirm
the packet is directed to a local application, it jumps to ei- that bpf-iptables outperforms iptables by an order of
ther the INGRESS or FORWARD chain, which implement the magnitude when a high number of rules is used, thanks to
corresponding matching pipeline. Before entering the respec- its improved algorithm and the different optimizations on
tive chains, the packet passes from a first connection tracking the classification pipeline that are allowed by the dynamic
module (implemented as an additional eBPF program), which code injection of eBPF, with a vanilla Linux kernel.

109
Accelerating Linux Security with eBPF iptables SIGCOMM Posters and Demos ’18, August 20–25, 2018, Budapest, Hungary

REFERENCES
[1] D. Borkmann. 2018. net: add bpfilter. (feb 2018). https://lwn.net/Articles/
747504/
[2] T. Graf. 2018. Why is the kernel community replacing ipta-
bles with BPF? (apr 2018). https://cilium.io/blog/2018/04/17/
why-is-the-kernel-community-replacing-iptables
[3] T.V. Lakshman and D. Stiliadis. 1998. High-speed policy-based packet
forwarding using efficient multi-dimensional range matching. In ACM
SIGCOMM Computer Communication Review, Vol. 28. ACM, 203–214.
[4] S. Miano, M. Bertrone, F. Risso, M. Vásquez Bernal, and M. Tumolo. 2018.
Creating Complex Network Service with eBPF: Experience and Lessons
Learned. In High Performance Switching and Routing (HPSR). IEEE.
[5] P. Russell. 1998. The netfilter.org project. (1998). https://netfilter.org/

110