Software-update: IPFire 2.27 - Core Update 171

IPFire logo (79 pix) IPFire is een opensourcefirewall voor i586-, x86_64- en ARM-systemen. Het bevat onder andere een intrusion detection/prevention system, deelt het netwerk op in zones, doet stateful packet inspection en biedt vpn-mogelijkheden. Voor meer informatie verwijzen we naar deze pagina. De ontwikkelaars hebben versie 2.27 Core Update 171 uitgebracht, een stabiele uitgave voor productiesystemen. De bijbehorende aantekeningen zien er als volgt uit:

IPFire 2.27 - Core Update 171 released [SECURITY ADVISORY]

Today, we release IPFire 2.27 - Core Update 171. It updates major parts of the distribution, such as the kernel and the IPS engine, and features bug fixes as well as stability and security improvements - most notably, upstream fixes against a strain of vulnerabilities in the kernel's WiFi components. Particularly IPFire users running WiFi networking hardware are advised to install this update as soon as possible, and reboot their systems afterwards.

Also, this Core Update initiates the deprecation of IPFire support for 32-bit ARM hardware, ultimately taking effect on February 28, 2023.

Modernizing system components

Several core parts of IPFire have been updated and modernized:

  • Suricata has been updated to the 6.x versioning branch, after a show-stopping issue (#12548) has been resolved upstream. IPFire users will benefit from more stable, secure, and versatile IPS functionality.
  • The Linux kernel has been updated to 5.15.71, providing IPFire users with hardware support improvements and security fixes.
    • Most notably, it resolves issues affecting ASIX USB3-to-LAN adapters using the ax88179-178a driver.
    • Upstream patches for fixing CVE-2022-41674 and CVE-2022-42719 to CVE-2022-42722 have been incorporated, plugging several security vulnerabilities in the kernel's WiFi components that could have lead to RCE and DoS attacks, simply by emitting crafted WiFi beacons.
    • To cut attack surface, some debugging functionalities have been removed, for which there is no legitimate use-case on an IPFire machine.
    • ARM installations will experience a security benefit thanks to seccomp support enabled. Doing so previously caused issues on some boards, hence it was enabled on x86 only.
    • Mathew McBride submitted patches to add support for the 64-bit ARM Traverse Ten64 board family.
Sunsetting 32-bit ARM support

Back in the glory days, the IPFire development team was optimistic about ARM becoming an affordable yet powerful alternative to the x86 architecture. Support was added in IPFire 2.11, 13 years ago. Soon, we finally would see some diversification among the hardware landscape, forcing competition and ultimately better products - or so we hoped.

Disappointment kicked in just two years later, when we realized hardware vendors were just dumping new SoCs on the marked without caring about proper operating system support at all. Existing boards disappeared quicker than the kernel developers could reverse engineer them and implement drivers. Very few of these boards actually met IPFire's demands, such as having at least two properly connected NICs.

Things did not improve afterwards, as we had to assess that there was no innovation on the market, and given the hardware specifications of the vast majority of 32-bit ARM boards, the architecture quickly became very much a legacy burden to us. Maintaining our own ARM kernel patchset started to eat into the spare time of IPFire's developers, while the amount of IPFire installations actually running on ARM never exceeded 10%. At some point, we decided not to support any additional SoCs without proper mainline kernel drivers, to prevent the situation from escalating to a DDoS against the people behind IPFire.

Today, despite significant efforts on our part, we are left with a patchy list of ARM boards supported, scanty upstream support (much like 32-bit x86), and a general disinterest in this architecture. Unsurprisingly, at the time of writing, only 0.86% of all IPFire installations out there run on 32-bit ARM.

Due to all these reasons, we decided to discontinue IPFire support for 32-bit ARM on February 28, 2023. Users are recommended to replace their hardware; after that date, IPFire won't provide updates for this architecture anymore.

64-bit ARM board support will continue, and while it is not a mainstream architecture to us (backing only 1.25% of all IPFire installations), supporting it is much less of a hassle, thanks to better upstream development and big server vendors and cloud providers rapidly shifting to 64-bit ARM. As to be expected, the boards available are much more powerful and suitable for firewalling purposes as well. We hope our decision will gain us resources to focus on more important work, such as the development of IPFire 3.

Miscellaneous
  • Perl, all its modules and related packages were updated to 5.36.0, resolving functional and security issues.
  • The toolchain, comprising of glibc, binutils and more, was modernized as well.
  • linux-firmware, the conglomerate of proprietary 3rd-party firmware files, has been updated as well. By removing some firmware files related to unsupported hardware, especially Bluetooth devices, we save a couple of megabytes.
  • Creating full-ISO backups is now possible again, resolving #12932.
  • libsodium is now shipped with the core system, required as a dependency to some add-ons (#12929).
  • Faulty links to IP blocklist source websites have been fixed (#12938).
  • Orphaned RRD graphs are now cleaned automatically on a weekly basis, saving disk space.
  • NUT logs can now be viewed in the web interface (#12921).
  • Connections to literal IPv6 addresses no longer crash IPFires' proxy (#12826).
  • IPFire's default domain is now used for DHCP leases where no domain can be determined, rather than defaulting to localdomain.
  • Updated packages: bind 9.16.33, binutils 2.39, curl 7.84.0, dhcp 4.4.3-P1, efibootmgr 18, efivar 38, expat 2.4.9, glibc 2.36, iproute2 5.19.0, kbd 2.5.1, libarchive 3.6.1, libhtp 0.5.41, linux-firmware 20220913, nettle 3.8.1, OpenVPN 2.5.7, Perl 5.36.0, sqlite 3390200, Squid 5.7, strongSwan 5.9.7, Suricata 6.0.8, udev 3.2.11, Unbound 1.16.3, util-linux 2.38.1, wireless-regdb 2022-08-12
  • Updated add-ons: elfutils 0.187, fetchmail 6.4.32, hplip 3.22.6, lcdproc 0e2ce9b, ncat 7.92, rsync 2.3.6, Tor 0.4.7.10

Versienummer 2.27 - Core Update 171
Releasestatus Final
Besturingssystemen Linux
Website IPFire
Download https://www.ipfire.org/download/ipfire-2.27-core171
Licentietype Voorwaarden (GNU/BSD/etc.)

Reacties (4)

4
4
1
0
0
2
Wijzig sortering
Zijn hier ook OpenWRT kenners?
Want ik vraag mij af in hoeverre OpenWRT x86 eigenlijk een goed alternatief voor IPfire is?
Ik stel mij voor dat de GUI van IPfire voor een beginner fijner is dan die van OpenWRT, maar heb met beide geen ervaring.
OpenWRT is router software.
IPfire is hoofdzakelijk een firewall met "neven functies".
Ze met elkaar vergelijken is niet relevant hier.
" Ze met elkaar vergelijken is niet relevant hier."
Waarom niet? :? 8)7

Beide zijn gebaseerd op Linux, kunnen routeren en hebben een firewall, NAT, en bieden traffic shaping aan. Traffic shaping met verschillende oplossingen, zelfs met CAKE SQM.

Beide hebben een package manager met "neven functies", om een aantal opties te noemen:

IPFire heeft TOR, Samba, NFS, CUPS, Avahi, Transmission, high availability met keepalived, virtualisatie en vele andere "neven functies.
OpenWRT heeft ook TOR, SAMBA, NFS, CUPS, Avahi, Transmission, high availability met keepalived, virtualisatie en vele andere "neven functies".

Het grote verschil tussen de twee is dat OpenWRT je ook de optie bied om het puur op een bridge aan te sluiten. Dat kan IPFire niet.

Er zijn vast nog veel meer details die anders zijn, maar over het algemeen lijkt mij de filosofie tussen de twee het grote verschil te zijn.

Zie mijn directe response op JaDatIsPeter :P
OpenWRT ondersteunt IPv6, IPFire schaalt IPv6 als veiligheidsrisico in (geen grap) en heeft ook geen optie daarvoor.
OpenWRT geeft ook een optie voor UPNP mocht je daar interesse aan hebben. IPfire heeft deze keuze voor je gemaakt.
IPfire is erg begrenst in de opties vergeleken met OpenWRT, pfSense e.d. met het maken van de interfaces. Je hebt vier kleuren en dat was het eigenlijk al.
Maakt het wel mooi overzichtelijk.
Maar naar mijn idee is dat ook gelijk een van de grotere tekortkomingen.

Ik heb recentelijk overwogen om IPFire te gebruiken ivm CAKE SQM, omdat ik OpenWRT updates vaker wel eens mis heb zien gaan (funkties die niet zo goed als eerst werken, packages die ontbreken?).
Maar in mijn ervaring is OpenWRT stukken beter dan IPFire.

CAKE SQM instellen was op beide OSes makkelijk, waarbij dat bij IPFire niet heel veel werk is maar bij OpenWRT+luci letterlijk een paar clicks is.

Hoe dan ook, aan het eind van de dag is het misschien het beste om een VM aan te maken en er zelf mee te spelen.

[Reactie gewijzigd door WeiserMaster op 25 juli 2024 13:23]

Op dit item kan niet meer gereageerd worden.