no IP firewalling in effect

Here is a part of my journalctl after reboot. Are the white-highlighted lines just an unimportant info message or something that should be taken care of?

Mai 30 07:50:04 DietPi kernel: smsc95xx 1-1.1:1.0 eth0: register ‘smsc95xx’ at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:06:19:ab
Mai 30 07:50:04 DietPi kernel: NET: Registered protocol family 10
Mai 30 07:50:04 DietPi kernel: Segment Routing with IPv6
Mai 30 07:50:04 DietPi kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Mai 30 07:50:04 DietPi systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4
Mai 30 07:50:04 DietPi systemd[1]: Detected architecture arm.
Mai 30 07:50:04 DietPi systemd[1]: Set hostname to .
Mai 30 07:50:04 DietPi systemd[1]: File /lib/systemd/system/systemd-journald.service:12 configures an IP firewall (IPAddressDeny=any), but the local system does not support BP
Mai 30 07:50:04 DietPi systemd[1]: Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)
Mai 30 07:50:04 DietPi kernel: random: systemd: uninitialized urandom read (16 bytes read)
Mai 30 07:50:04 DietPi kernel: random: systemd: uninitialized urandom read (16 bytes read)
Mai 30 07:50:04 DietPi systemd[1]: Listening on udev Control Socket.
Mai 30 07:50:04 DietPi systemd[1]: Condition check resulted in Journal Audit Socket being skipped.
Mai 30 07:50:04 DietPi kernel: random: systemd: uninitialized urandom read (16 bytes read)
Mai 30 07:50:04 DietPi systemd[1]: Created slice system-systemd\x2dfsck.slice.
Mai 30 07:50:04 DietPi systemd[1]: Reached target Remote File Systems.
Mai 30 07:50:04 DietPi systemd[1]: Started Forward Password Requests to Wall Directory Watch.
Mai 30 07:50:04 DietPi systemd-journald[94]: Journal started

huidbui25
Many thanks for your report.

Did you observe this on a Stretch or Buster image? I only have the related IPAddressDeny directive inside the systemd-journald.service of my Buster systems, but not the Stretch ones (where I guess the systemd version does not yet has it): https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#IPAddressAllow=ADDRESS[/PREFIXLENGTH]…

The related eBPF/bpfilter is an in-kernel firewall implementation that needs to be enabled for the kernel on compile time. Raspberry Pi’s seem to not have the required kernel option (CONFIG_BPF_SYSCALL) enabled for the kernels they ship: https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/configs/bcmrpi_defconfig

There is nothing we can do about it and you can safely ignore the warning. The directive would disallow any remote access to your system logger sockets (systemd-journald), but if you do not somehow enable this actively, e.g. sharing your whole rootfs as network share (NFS/Samba or such) and accessing/configuring it as root user, this has no effect anyway.


Just read a bid more about bpfilter: http://www.oddments.org/2018/10/18/linux-kernel-4-18-lighter-more-secured-code/
Seems to be quite new and as introduced with Linux 4.18 (if enabled on compile time) it cannot be supported for many SBCs (many of them ship older kernels). But performance- and security-wise it seems to be a great successor/replacement for iptables and nftables. I was already thinking to replace all our iptables usage/implementation with nftables (its successor), but probably it makes sense to skip that and use bpfilter directly :thinking:. However can not be done until all SBCs support it. Even nftables was just enabled 10 days ago in the testing branch of the RPi kernel: https://github.com/raspberrypi/linux/issues/2177

Thank you very much for the answer. So I’ll not bother with this error log entry any longer.

To answer your question: Originally a Stretch image, then updated inline by means of apt-get to Buster testing which is where the said error message occurs.

Ah jep, this makes sense then. Since obviously many SBC kernels come without support for this (many even have no chance since lower than 4.18), we might file a bugreport to ask degrading this warning to an info, or the other way round (then it’s a task for systemd) using a fallback to either nftables or even netfilter. Better have an outdated IP firewall than none, if a package maintainer wants it (by adding this directive to the systemd unit).