firewall & pinguin: iptables where do thou go?

it is said that when using “ip-sets” iptables and nftables achieve almost same performance (amounts of ips possible to block, without server becoming slow/unresponsive)

Redhat and nftables on DDoS “so the only thing to fall back to is establishing a blacklist for all the different source IP addresses” (src) (which is exactly what iptables + cron + autoban.sh a simple bash script does)

concept#3

2018-02: “The Linux kernel currently supports two separate network packet-filtering mechanisms: iptables and nftables.
For the last few years, it has been generally assumed that nftables would eventually replace the older iptables implementation;
few people expected that the kernel developers would, instead, add a third packet filter.
But that would appear to be what is happening with the newly announced bpfilter mechanism.
Bpfilter may eventually replace both iptables and nftables, but there are a lot of questions that will need to be answered first.” (src: https://lwn.net/Articles/747551/)
even faster X-D https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-iptables/

and: will already established iptables scripts keep on working?

“We like iptables after all, this tool has been serving us (and will likely keep serving still for a while in many deployments) to filter out traffic on both per-packet and per-flow basis, log suspicious traffic activity, perform NAT and many other things.

It comes with more than a hundred of extensions that have been contributed along the last 15 years!.

Nevertheless, the iptables framework suffers from limitations that cannot be easily worked around:

  • Avoid code duplication and inconsistencies:
    • Many of the iptables extensions are protocol specific
    • so there is no a consolidated way to match packet fields
    • instead there is one extension for each protocol that it supports
    • this bloats the codebase with very similar code to perform a similar task: payload matching
  • Faster packet classification through enhanced generic set and map infrastructure
  • Simplified dual stack IPv4/IPv6 administration, through the new inet family that allows you to register base chains that see both IPv4 and IPv6 traffic
  • Better dynamic ruleset updates support
  • Provide a Netlink API for third party applications, just as other Linux Networking and Netfilter subsystem do
  • Address syntax inconsistencies and provide nicer and more compact syntax (aha aha X-D)

These, among other things not listed here, triggered the nftables development which was originally presented to the Netfilter community in the 6th Netfilter Workshop in Paris (2008, France).” (src: wiki.nftables.org)

https://wiki.nftables.org/wiki-nftables/index.php/Main_Page

iptables will be with us for a very long time, CentOS does install nftables per default and does some backward compatibility, if you want to uninstall nftables and install the “proper” iptables go here -> CentOS7 uninstall nftables install iptables.

also checkout: https://configserver.com/cp/csf.html

Why firewalld?

“firewalld is just a fancy state machine to iptables configuration” (source: firewalld annoyances)

… well that might be the case, as i understand it, but there is another thing going on: new firewall implementation called Nftables!

firewalld has support for nftables.

But fail2ban for example and other tools (still?) seem to make problems.

Why nftables? 2016:

code sanification: with ipv6 the iptables codebase was copied 4x times, not handleable.

What is nftables?

hostnamectl 
  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 4.15.X
      Architecture: x86-64

modinfo nf_tables
filename:       /lib/modules/4.15.X/kernel/net/netfilter/nf_tables.ko
alias:          nfnetlink-subsys-10
author:         Patrick McHardy @trash.net
license:        GPL
srcversion:     372A16FCA06ED674CF59C27
depends:        nfnetlink
retpoline:      Y
intree:         Y
name:           nf_tables
vermagic:       4.15.X SMP mod_unload modversions 

yum search nftables
libnftnl.i686 : Library for low-level interaction with nftables Netlink's API over libmnl
libnftnl.x86_64 : Library for low-level interaction with nftables Netlink's API over libmnl
nftables.x86_64

yum info nftables.x86_64

Name        : nftables
Arch        : x86_64
Epoch       : 1
Version     : 0.8
Release     : 10.el7
Size        : 185 k
Repo        : base/7/x86_64
Summary     : Netfilter Tables userspace utillites
URL         : http://netfilter.org/projects/nftables/
License     : GPLv2
Description : Netfilter Tables userspace utilities.

yum info libnftnl.x86_64

Available Packages
Name        : libnftnl
Arch        : x86_64
Version     : 1.0.8
Release     : 1.el7
Size        : 77 k
Repo        : base/7/x86_64
Summary     : Library for low-level interaction with nftables Netlink's API over libmnl
URL         : http://netfilter.org/projects/libnftnl/
License     : GPLv2+
Description : A library for low-level interaction with nftables Netlink's API over libmnl.

nftables replaces the popular {ip,ip6,arp,eb}tables. This software provides a new in-kernel packet classification framework that is based on a network-specific Virtual Machine (VM) and a new nft userspace command line tool. nftables reuses the existing Netfilter subsystems such as the existing hook infrastructure, the connection tracking system, NAT, userspace queueing and logging subsystem. (src: https://netfilter.org/projects/nftables/)

Firewalld, the default firewall management tool in Red Hat Enterprise Linux and Fedora, has gained long sought support for nftables.

This was announced in detail on firewalld’s project blog.

The feature landed in the firewalld 0.6.0 release as the new default firewall backend.

The benefits of nftables have been outlined on the Red Hat Developer Blog:

Confusing: the iptables command is still there, but it seems it does not work well, integration of tools such as fail2ban was not considered? So if fail2ban fails to block any ips… this might be the reason why.” (src: https://developers.redhat.com/blog/2018/08/10/firewalld-the-future-is-nftables/)

Why nftables?

history of iptables:

iptables is in development since 1998

“Netfilter and iptables were originally developed together, so there were overlaps in the previous development. See the Netfilter article.

Linux has a package filter as of Version 1.0. This was originally from BSD and was extended in Linux version 2.0 under the name ipfwadm. Rusty Russell reworked the packet filter and provided it as ipchains. It was integrated into Linux 2.2. Towards 1999, the Kernel and thus also ipchains was completely revised. Ipchains produced iptables, which has been included in the package since Kernel 2.4.

iptables maintains the original basic idea of ipfwadm: lists of rules each of which indicates what is checked in a package, and what is to be done with this package. ipchains introduced the concept of chains, and iptables expanded this to tables. One table is responsible for NAT, another for filtering. In addition, the three points where packets are filtered on their “journey” have been changed so that each packet only passes through a filter point.

To use this split allowed iptables, in turn, information obtained by the Connection-Tracking-Subsystem – this Information was previously tied to NAT. Thus, iptables has more possibilities than ipchains, since it can additionally monitor the state of a connection, redirect it, or stop and manipulate data packets based on the state, instead of doing so only by source or destination address. A Firewall such as iptables, which meets these requirements, is called stateful, while ipchains except in very limited exceptional cases was only stateless.” (auto translated from https://de.wikipedia.org/wiki/Iptables#Geschichte)

iptables vs nftables benchmark performance comparison, scalability when facing DDoS scenarios:

“iptables’ performance degrades as the number of rules increases”

…

“so the only thing to fall back to is establishing a blacklist for all the different source IP addresses.

And here’s also the connection to the previous setups:

Matching many unrelated IP addresses is likely to turn into large numbers of rules packets have to traverse.”

…

“created a stream of 100k packets per second using pktgen, which match the blacklist criteria.

Finally, here are the plotted results:”

“Conclusion”

“To me, the most prominent information to draw from this little experiment is that similar iptables and nftables setups are comparable in performance. Yes, nftables is usually a bit behind, but given that development focus at this point is still on functionality rather than performance, I’m sure this is subject to change in the near future.

Regarding scalability, ipset is a blessing to any iptables set up. Nftables follow the path with their native implementation of sets and take the concept to a higher level by extending the list of supported data types and allowing it to be used in further applications using (verdict) maps.

Although I am not fully convinced of my last test’s results, I think it still proves that there is no point in breaking a leg over implementing something in tc if the same is possible in netfilter. At least when it just results in a qdisc with many filters attached, the worst implementation in netfilter still outperforms it.”

(src: https://developers.redhat.com/blog/2017/04/11/benchmarking-nftables/)

back to topic: firewalld

“Firewalld provides a dynamically managed firewall with support for network/firewall zones that defines the trust level of network connections or interfaces.

(similar to Windows “Public / Business / Private Network” zones… that it tries to detect automatically (goes into “public” = almost complete lockdown of incoming connections if a prior unkown switch/connection is detected)

It has support for IPv4, IPv6 firewall settings, ethernet bridges and IP sets.

There is a separation of runtime and permanent configuration options.

It also provides an interface for services or applications to add firewall rules directly.

The former firewall model with system-config-firewall/lokkit was static and every change required a complete firewall restart.

This included also to unload the firewall netfilter kernel modules and to load the modules that are needed for the new configuration.

The unload of the modules was breaking stateful firewalling and established connections.

The firewall daemon on the other hand manages the firewall dynamically and applies changes without restarting the whole firewall.

Therefore there is no need to reload all firewall kernel modules.

But using a firewall daemon requires that all firewall modifications are done with that daemon to make sure that the state in the daemon and the firewall in kernel are in sync.

The firewall daemon can not parse firewall rules added by the iptables and ebtables command line tools.

The daemon provides information about the current active firewall settings via D-BUS and also accepts changes via D-BUS using PolicyKit authentication methods.

So, firewalld uses zones and services instead of chain and rules for performing the operations and it can manages rule(s) dynamically allowing updates & modification without breaking existing sessions and connections.

It has following features.

  • D-Bus API.
  • Timed firewall rules.
  • Rich Language for specific firewall rules.
  • IPv4 and IPv6 NAT support.
  • Firewall zones.
  • IP set support.
  • Simple log of denied packets.
  • Direct interface.
  • Lockdown: Whitelisting of applications that may modify the firewall.
  • Support for iptables, ip6tables, ebtables and ipset firewall backends.
  • Automatic loading of Linux kernel modules.
  • Integration with Puppet.

src: https://www.unixmen.com/iptables-vs-firewalld/

  • The iptables service stores configuration in /etc/sysconfig/iptables and /etc/sysconfig/ip6tables, while firewalld stores it in various XML files in /usr/lib/firewalld/ and /etc/firewalld/. Note that the /etc/sysconfig/iptables file does not exist as firewalld is installed by default on Red Hat Enterprise Linux.
  • With the iptables service, every single change means flushing all the old rules and reading all the new rules from /etc/sysconfig/iptables, while with firewalld there is no recreating of all the rules. Only the differences are applied. Consequently, firewalld can change the settings during runtime without existing connections being lost.
  • Both use iptables tool to talk to the kernel packet filter.

src: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-setting_and_controlling_ip_sets_using_iptables

check if it is up and running:

systemctl list-unit-files|grep firewall
firewalld.service enabled
# if not start it
systemctl start firewalld

check what ports are used on your system:

nmap localhost; # quick

Starting Nmap 6.40 ( http://nmap.org ) at 2018-08-23 08:42 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000029s latency).
Other addresses for localhost (not scanned): 127.0.0.1
rDNS record for 127.0.0.1: dwaves.org
Not shown: 993 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
80/tcp   open  http
143/tcp  open  imap
443/tcp  open  https
587/tcp  open  submission
...
nmap -v -A  localhost; # slow

lsof -i -P -n
COMMAND     PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
chronyd     564   chrony    1u  IPv4  14365      0t0  UDP 127.0.0.1:323 
chronyd     564   chrony    2u  IPv6  14366      0t0  UDP [::1]:323 
dhclient    804     root    6u  IPv4  14940      0t0  UDP *:68 
sshd        983     root    3u  IPv4  15912      0t0  TCP *:22 (LISTEN)
sshd        983     root    4u  IPv6  15914      0t0  TCP *:22 (LISTEN)

netstat -pantu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      983/sshd            
tcp        0    232 yy.yyy.yyy.yyy:22       xx.xxx.xx.xx:58344      ESTABLISHED 14973/sshd: user 

# check what program is using a specific port
netstat -pantu|grep 587
tcp6       0      0 :::587                  :::*                    LISTEN      3851/docker-proxy-c 
lsof -i -P -n|grep 587
docker-pr  3851     root    4u  IPv6 195557      0t0  TCP *:587 (LISTEN)
  • IMAP uses port 143, but implicit SSL/TLS encrypted IMAP uses port 993.
  • POP uses port 110, but implicit SSL/TLS encrypted POP uses port 995.
  • SMTP uses port 25, but implicit SSL/TLS encrypted SMTP uses port 465.

open a port, permanently:

# http webserver unencrypted
firewall-cmd --zone=public --add-port=80/tcp --permanent
# https webserver encrypted (Let's Encrypt SSL)
firewall-cmd --zone=public --add-port=443/tcp --permanent
# ssh
firewall-cmd --zone=public --add-port=22/tcp --permanent

# SMTP (Simple Mail Transfer Protocol)
firewall-cmd --zone=public --add-port=25/tcp --permanent

# IMAP (Internet Message Access Protocol)
firewall-cmd --zone=public --add-port=25/tcp --permanent

# imap over STARTLS/SSL
firewall-cmd --zone=public --add-port=143/tcp --permanent
# when done activate the rules by reload
firewall-cmd --reload

“The former firewall model with system-config-firewall/lokkit was static and every change required a complete firewall restart. This included also to unload the firewall netfilter kernel modules and to load the modules that are needed for the new configuration. The unload of the modules was breaking stateful firewalling and established connections.

The firewall daemon on the other hand manages the firewall dynamically and applies changes without restarting the whole firewall. Therefore there is no need to reload all firewall kernel modules. But using a firewall daemon requires that all firewall modifications are done with that daemon to make sure that the state in the daemon and the firewall in kernel are in sync. The firewall daemon can not parse firewall rules added by the ip\*tables and ebtables command line tools.

The daemon provides information about the current active firewall settings via D-BUS and also accepts changes via D-BUS using PolicyKit authentication methods.”

official homepage http://firewalld.org

src: https://fedoraproject.org/wiki/Firewalld?rd=FirewallD

How to block/ban a certain ip:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='xx.xxx.xx.xx' reject"
firewall-cmd --reload

liked this article?

  • only together we can create a truly free world
  • plz support dwaves to keep it up & running!
  • (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
  • really really hate advertisement
  • contribute: whenever a solution was found, blog about it for others to find!
  • talk about, recommend & link to this blog and articles
  • thanks to all who contribute!
admin