Software-update: pfSense 2.4.4

Versie 2.4.4 van pfSense is uitgekomen. Dit pakket is gebaseerd op het besturingssysteem FreeBSD en richt zich op router- en firewalltaken. Het is in 2004 begonnen als een afsplitsing van m0n0wall vanwege verschillende visies bij de ontwikkelaars en in de loop van de jaren uitgegroeid tot een router- en firewallpakket dat in zowel kleine als zeer grote omgevingen kan worden ingezet. Voor meer informatie verwijzen we naar deze pagina. De hoogtepunten voor deze uitgave zien er als volgt uit:

Free pfSense Gold Content

With the release of pfSense 2.4.4, all former pfSense Gold content is now free for all!

• AutoConfigBackup is integrated into pfSense version 2.4.4 and free for all to use. It is no longer an add-on package. It is now located under Services > Auto Config Backup.
• All hangout videos are available free on YouTube, and future hangouts are being broadcast using YouTube Live.
• The pfSense Book is now available free on the Netgate website.

New Features

2.4.4 includes a number of significant new features:

• OS Upgrade: Base Operating System upgraded to FreeBSD 11.2-RELEASE-p3. As a part of moving to FreeBSD 11.2, support is included for C3000-based hardware.
• PHP 7.2: PHP upgraded to version 7.2, which required numerous changes to syntax throughout the source code and packages.
• Routed IPsec (VTI): Routed IPsec is now possible using using FreeBSD if_ipsec(4) Virtual Tunnel Interfaces (VTI).
• IPsec Speed Improvements: The new Asynchronous Cryptography option under the IPsec Advanced Settings tab can dramatically improve IPsec performance on multi-core hardware.
• Default Gateway Group: The default gateway may now be configured using a Gateway Group setup for failover, which replaces Default Gateway Switching.
• Limiter AQM/Queue Schedulers: Limiters now include support for several Active Queue Management (AQM) methods and Queue Scheduler configurations such as FQ_CODEL.
• Certificate Subject Requirements: The Certificate Manager and OpenVPN wizard now only require the Common Name to be set, and all other fields are optional.
• DNS over TLS: The DNS Resolver now includes support for DNS over TLS as both a client and a server, including for domain overrides.
• Captive Portal Authentication: Captive Portal authentication is now integrated with the User Manager system. Captive Portal instances may now use RADIUS, LDAP, or Local Authentication like other integrated services.
• Captive Portal HTML Design and Usability: The default Captive Portal page has been redesigned. Controls have also been added which allow the logo and background images and Terms of Service text to be customized without editing and uploading custom HTML code.
• Integrated Switch Improvements: Netgate devices with integrated switches such as the SG-3100 and XG-7100 can now configure per-port speed and duplex settings, discrete port configuration interfaces can now be tied to switch ports for up/down status, and LAGG support is also now available (Load Balance mode only)
• New Hardware: Support has been added for the new SG-5100.
• … and more!

Security

This release includes several important security patches:

• FreeBSD SA for CVE-2018-6922: Resource exhaustion in TCP reassembly FreeBSD-SA-18:08.tcp
• FreeBSD SA for CVE-2018-3620, CVE-2018-3646: L1 Terminal Fault (L1TF) Kernel Information Disclosure FreeBSD-SA-18:09.l1tf
• FreeBSD SA for CVE-2018-6923: Resource exhaustion in IP fragment reassembly FreeBSD-SA-18:10.ip
• FreeBSD SA for CVE-2018-14526: Unauthenticated EAPOL-Key Decryption Vulnerability FreeBSD-SA-18:11.hostapd
• FreeBSD SA for CVE-2018-6924: Improper ELF header parsing FreeBSD-SA-18:12.elf
• FreeBSD errata notice for LazyFPU remediation causing potential data corruption FreeBSD-EN-18:08.lazyfpu
• Fixed two potential XSS vectors and an authenticated command execution issue.
• Upgraded several binary packages in the base system to address upstream vulnerabilities, including strongSwan CVE-2018-5388, OpenSSH CVE-2018-15473, and cURL CVE 2018-14618
• Updated default cryptographic settings for OpenVPN, IPsec, and Certificates
• Changed the included DH groups to those defined in RFC 7919
• Added stronger IPsec Pre-Shared Key usage warnings, and a button to generate a secure PSK
• Changed from sshlockout_pf to sshguard for monitoring failed logins and locking out offenders, this allows the lockout to work on IPv4 and IPv6 and also terminates states when adding offenders to the block list

• Disabled OpenVPN compression by default on new instances for security reasons due to VORACLE

  • Users are strongly urged to disable compression on OpenVPN instances if they pass unencrypted data such as HTTP to arbitrary Internet sites.

Notable Bug Fixes

In addition to security fixes, pfSense software version 2.4.4 also includes important bug fixes.

• Fixed an issue with ARM hardware not completely halting when shut down (SG-3100 and SG-1000)
• Fixed HDMI hotplug issues on Minnowboard Turbot hardware (MBT-2220 and MBT-4220)
• Fixed SG-1000 autonegotiation for 10baseT speed and duplex
• … and many more!

Versienummer	2.4.4
Releasestatus	Final
Besturingssystemen	BSD
Website	pfSense
Download	https://www.pfsense.org/download/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (15)

[ScoeS]

Let op; dit is waarschijnlijk een van de laatste update die zal werken op oudere cpu’s. Vanaf versie 2.5 is AES-NI ondersteuning vereist.

https://www.netgate.com/blog/pfsense-2-5-and-aes-ni.html

[terradrone]

En daarmee neemt de ontwikkeling van pfsense een ronduit belachelijke wending. Waar het uit m0n0wall geforkte project veel gebruikt werd door liefhebbers op "oudere" hardware, waaronder de watchguard firebox, en diverse andere repurposed hardware, is het met de aes-ni verplichting ineens onmogelijk om al die mooie "oudere" hardware te gebruiken. Voor iedereen die dit leest en zelf tegen deze beperking aanloopt: kijk eens naar opnsense ( https://opnsense.org/ ). Dit is op zijn beurt weer een fork van pfsense, is door de ontwikkelaar van het oorspronkelijke m0n0wall als juiste opvolger van m0n0wall aangewezen en werkt nog steeds op "oudere" hardware, zowel 32bit apparaten als devices met cpu's zonder aes-ni.

[ppl]

Zoals al eens aangegeven door o.a. OpenBSD en FreeBSD (dit vormt de basis voor m0n0wall, pfSense en OPNSense) is het grote probleem van 32-bit hardware de beschikbaarheid daarvan. Het wordt niet zoveel meer gebruikt waardoor heel veel zaken ook niet meer op die hardware getest wordt. Dat betekent dat vulnerabilities ook minder snel aan het licht kunnen komen en dat is een security risk. Men weet alleen niet hoe groot die exact is. Hoe dan ook, FreeBSD zelf geeft ook de voorkeur aan AMD64 ipv i386.
Verder mis je natuurlijk ook belangrijke security features die 64-bit met zich meebrengt (denk aan ASLR).

Daarbij komt dat oude hardware ook een ander issue kent: de spectre en meltdown vulnerabilities die niet gefikst worden omdat de hardware verouderd is (lees: niet meer ondersteund).

Voor een security appliance als een firewall zijn dit soort zaken nou niet bepaald handig. Ik zou het niet-ondersteunen van hardware dat known security issues bevat dan ook zeer zeker niet als "belachelijk" bestempelen. Laat staan het feit dat je beperkt bent tot 4GB want nou niet bepaald handig is wanneer je de echt leuke dingen in pfSense/OPNSense wilt gebruiken. Die 32-bit support is vooral een leuke geste naar de community.

Overigens zijn pfSense en OPNSense vooral handig voor wie meer wil dan alleen maar firewalling en routing. Met name zaken als OpenVPN, Letsencrypt certificates, proxies en pfBlocker worden vaak gebruikt. Zoek je alleen firewalling en routing dan is wellicht iets als Vyos een geschikter systeem. Kun je ook nog eens opnemen in je Infrastructure as Code (bijv. middels Ansible, Terraform, etc.), iets wat niet kan met pfSense en OPNSense (feitelijk zit je aan de webgui vast en moet je alles bij elkaar klikken; via cli kan het met wat omwegen maar niet met alles en je hebt geen enkele garanties).

Een leuk artikel over security en de BSD varianten is de volgende: Are the BSDs dying? Some security researchers think so. Bottomline daar is te weinig mankracht om naar security issues te kijken. Niet handig als je dan ook nog eens diverse ports (als in platformen) moet onderhouden.

[Reactie gewijzigd door ppl op 22 juli 2024 13:34]

[terradrone]

Een redelijk gekleurde blik op het geheel als je het mij vraagt: zoals gezegd is er nog véél (!) 32bit hardware in omloop. Niet als nieuwe producten natuurlijk, en uiteraard daarmee ook niet interessant voor zakelijke toepassingen. Het punt wat ik probeer te maken is dat er veel liefhebbers zijn, in bezit van mooie gebruikte hardware, veel nog 32bit, die icm een bsd based router gewoon een ontzettend mooi product hebben. Wat betreft je relaas over vulnerabilities: spectre en meltdown zijn inderdaad een probleem echter, het is een illusie dat op een 64bit platform je helemaal gevrijwaard bent van dit soort problemen. Wat te denken van intel amt wat zo lek als een mandje blijkt, of de problemen rondom wpa2 (KRACK), die ben je met je 64bit distro echt niet kwijt.

Wat betreft je 4gb limit, het is onjuist te denken dat je met 32bit software hiertoe beperkt bent. De techniek heet PAE en ik draai dan ook vrolijk een 32bit appliance met 8gb memory met opnsense.

[ppl]

Wat betreft je relaas over vulnerabilities: spectre en meltdown zijn inderdaad een probleem echter, het is een illusie dat op een 64bit platform je helemaal gevrijwaard bent van dit soort problemen.

Dan heb je het hele punt niet begrepen. Wat je hier zegt is niveau "captain obvious" want er is bewijs te over dat geen enkel platform gevrijwaard is van security problemen. Dat is om exact die reden dan ook totaal niet mijn punt. Waar het hier nou juist omgaat is dat door gebrekkige aandacht voor de 32-bit hardware men daar niet zo snel security problemen vindt en oplost. De aandacht is allemaal gericht op 64-bit.

Of er nou veel of weinig 32-bit hardware in omloop is boeit totaal niet. Waar het hier om gaat is de support die de projecten waar men bij pfSense/OPNSense van gebruik maken leveren op die platformen.

Als je het mij vraagt is jouw blik zeer gekleurd (en wel roze). De werkelijkheid binnen de BSD wereld is anders. Het zijn geen grote projecten met een onuitputtelijke hoeveelheid mankracht en daar maken kennelijk sommige mensen zorgen over (zie eerder geposte link).

[Reactie gewijzigd door ppl op 22 juli 2024 13:34]

[Jerie]

Kap 'ns met "32-bit" en "64-bit". Er is meer dan AMD64 en x86-32.

4 GB RAM is tegenwoordig niet meer genoeg voor een router? Mijn router, MIPS64, heeft 512 MB RAM. Ik doe er zat leuke dingen mee (ja idd VyOS).

De spectre en meltdown vulns worden ook gepatched door distributies. Maar dan heb je meer overhead.

Als je betere VPN performance wilt, dan kun je ipv OpenVPN beter IPsec of WireGuard nemen.

Sterker nog als je een zusje van de router hebt die ik heb, dan heb je een MIPS32 met IIRC 256 MB RAM. En die heeft diverse specifieke optimalisaties voor WireGuard welke de MIPS64 versie niet heeft.

Ongeacht PAE, er is geen enkele logische reden om x86-32 ondersteuning te stoppen. Je kunt prima PFsense of OPNsense draaien op 4 GB of minder. Heck, ik draaide het op een x86-32 met 512 MB RAM (een Soekris). OPNsense draaide daar ook gewoon op, die vereist IIRC 512 MB RAM. Dat is 1/8 van 4 GB (PAE nogmaals nog even buiten beschouwing).

Het nadeel van een zwakkere machine is dat je minder met je router kunt. Het is echter maar de vraag of je dat alles ook daadwerkelijk nodig hebt; anders kocht je wel een nieuwe. De enige logische reden waarom NetGate stopt met x86-32 is omdat ze hun hardware appliances willen verkopen. Dat doen ze door oude hardware -welke nog prima veilig werkt (itt wat jij denkt te weten)- obsolete te maken dmv het niet meer te ondersteunen.

[ppl]

Kap 'ns met "32-bit" en "64-bit". Er is meer dan AMD64 en x86-32.

Kap nou eens met denken dat 32-bit en 64-bit alleen maar slaat op AMD64 en i386 (zoals ze in BSD wereld de 32 bit versie van Intel x86 aanduiden). Ik heb het niet voor niets over 32/64-bit

4 GB RAM is tegenwoordig niet meer genoeg voor een router? Mijn router, MIPS64, heeft 512 MB RAM. Ik doe er zat leuke dingen mee (ja idd VyOS).

Met zo'n vraag lijkt het me verstandig om even onderzoek te doen wat pfSense/OPNSense nou daadwerkelijk zijn. Routing is namelijk maar een heel klein deel van het verhaal. pfSense/OPNSense zijn security appliances waarbij je heel ver kunt gaan. Bij zaken als Suricate, Snort heb je meer geheugen nodig. Dit staat ook keurig netjes in de requirements vermeld van beide stukken software.

De spectre en meltdown vulns worden ook gepatched door distributies. Maar dan heb je meer overhead.

Distributies zijn hier niet van toepassing, dat is een Linux ding terwijl we het hier over systemen hebben die draaien op FreeBSD. De BSD wereld kent geen distributies en FreeBSD is een totaal ander OS.

Als je betere VPN performance wilt, dan kun je ipv OpenVPN beter IPsec of WireGuard nemen.

Definieer beter Als de eindgebruiker door firewalling moet die hij niet onder beheer heeft dan is een OpenVPN connectie heel wat beter dan IPSec. Draait diegene op iets anders dan Linux dan is WireGuard al niet eens een optie. Vergeet ook niet dat WireGuard nog een WIP is en ze duidelijk aangeven dat je het niet voor productie moet gebruiken.

Ongeacht PAE, er is geen enkele logische reden om x86-32 ondersteuning te stoppen.

Die zijn er wel: gebrek aan kennis, gebrek aan mankracht. We hebben het hier over community projecten die niet zo heel erg groot zijn en die heel erg afhankelijk zijn van donaties van derden (van zowel hardware als geld als mankracht). Daar loopt het op mis.

Je kunt prima PFsense of OPNsense draaien op 4 GB of minder.

Zoals ik al zei ligt dat dus geheel aan wat je van pfSense/OPNSense gebruikt. Dat staat nota bene op hun eigen websites!

De enige logische reden waarom NetGate stopt met x86-32 is omdat ze hun hardware appliances willen verkopen.

Fout! Netgate heeft hier helemaal niet zoveel van doen. Zowel pfSense als OPNSense is niet meer dan software bovenop FreeBSD. Netgate stopt dan ook niet met i386 support (de oude versies zijn er nog gewoon; je kunt alleen niet naar 2.4.x), FreeBSD ook niet en dat is ook niet wat er in mijn reactie staat. Wat er wel staat is dat het FreeBSD project een probleem heeft met beschikbare resources om aan hun projecten te werken. Dan moeten ze keuzes maken en Netgate daardoor ook. Aangezien AMD64 nou eenmaal veel meer wordt gebruikt dan i386 zal bij het maken van keuzes er eerder voor AMD64 worden gekozen. Het had heel veel geholpen wanneer je mijn post daadwerkelijk had gelezen inclusief de link die er in staat. Die link stipt namelijk het gebrek aan mankracht in de BSD wereld aan en laat per BSD variant zien wat voor impact ze denken dat dit zal gaan hebben.

Btw, houdt er rekening mee dat zowel pfSense als OPNSense bezig zijn om zichzelf om te turnen tot een FreeBSD port. In de toekomst zijn ze dan ook niet anders dan bijv. Firefox: een applicatie die je installeert op een bestaande FreeBSD installatie.

[Reactie gewijzigd door ppl op 22 juli 2024 13:34]

[ShadowBumble]

Thanks ! Die had ik nog niet voorbij zien komen en dat zal waarschijnlijk erin resulteren dat ik niet ga upgrade naar 2.5, en in potentie helemaal zal afstappen van pfSense.

Ik heb namelijk AES-NI helemaal niet nodig en mijn hardware heeft nog ruim voldoende capaciteit voor mijn wensen.

[terradrone]

Probeer opnsense eens. Ook bsd based, maar zonder de belachelijke eisen. En inderdaad, voor velen is aes-ni totaal onnodig. En dan te bedenken dat veel verkochte atom c2000 appliances (de "profi" atom met aes-ni) slechte cpu's hebben die vaak niet of beperkt worden omgeruild door fabrikanten: https://www.theregister.c...t_warning_to_faulty_chip/

[Reactie gewijzigd door terradrone op 22 juli 2024 13:34]

[aileron]

Ga je nou pfsense afvallen om een bug in Intel hardware? Maar laten we vooral weer de discussie opnsense pfsense voeren

Pfsense eist dit, deal with it

[imqqmi]

Damn, had ik afgelopen jaar mijn oude pc geupgrade naar een pentium 64 bit vanwege het laten vallen van 32 bit. Is het eenvoudig om naar opnsense te side graden? Of moet de gehele configuratie opnieuw ingesteld worden?

[ScoeS]

Dat geef ik een hele kleine kans. De config is een XML als export, die zal specifiek zijn.

Niet geschoten...

[imqqmi]

Na wat zoekwerk kunnen specifieke delen die overeenkomen apart geïmporteerd worden maar niet op een makkelijke manier. Ik denk dat het handiger is om het opnieuw te configureren. Dat wordt een toekomstig vakantie projectje

[aileron]

Nou, ik steun pfsense in hun besluit om vanaf 2.5 AES-NI verplicht te stellen. Het zal pfsense alleen maar veiliger maken. Legacy meuk eruit en software optimaliseren voor nieuwere hardware.

Wil je een top firewall, dan moet je ook de hardware er voor hebben. Altijd maar voor een dubbeltje op de eerste rang willen zitten...

[ppl]

Ik vraag me af hoeveel mensen dit zullen gaan merken. pfSense wordt namelijk heel veel in een vm gedraaid en niet op bare metal. Degenen die dat wel doen hebben ofwel een officiële appliance (want bedrijf of geen zin om zelf te kloten met hardware) of, en deze groep lijkt klein, hun eigen ding samengesteld (en dat gaat meestal om oude hardware die ze bij elkaar hebben gesprokkeld). Die laatste groep is de hobbyist en die hebben alternatieven zoals OPNSense. Laat die nou een fork van pfSense zijn...al dat geschreeuw en moeilijk doen is dan ook helemaal nergens voor nodig.

Wat veel belangrijker is, is dit: https://www.netgate.com/b...e-2-3-x-eol-reminder.html
De 2.3.x is eind oktober maand EoL dus je hebt nog een maand de tijd om te upgraden naar 2.4.x.