Software-update: pfsense 2.3.5-p1 / 2.4.2-p1

Er zijn updates voor versies 2.3.5 en 2.4.2 van pfSense 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:

pfSense 2.4.2-RELEASE-p1 and 2.3.5-RELEASE-p1 now available

We are excited to announce the release of pfSense software versions 2.4.2-p1 and 2.3.5-p1, now available for upgrades!pfSense software versions 2.4.2-p1 and 2.3.5-p1 are maintenance releases bringing security patches and stability fixes for issues present in the pfSense 2.4.2 and 2.3.5 releases.

This release includes several important security patches:

• Updated OpenSSL for CVE-2017-3737 and CVE-2017-3738 / FreeBSD-SA-17:12.openssl (2.4.x and 2.3.x)
• Fixed a potential authenticated command execution issue in certificate data handling #8153 / pfSense-SA-17_10.webgui.asc (2.4.x and 2.3.x)
• Fixed a potential XSS issue in status_filter_reload.php #8143 / pfSense-SA-17_11.webgui.asc (2.4.x and 2.3.x)
• Fixed a potential clickjacking issue in the CSRF error page (2.3.x only, this fix was included in 2.4.2-RELEASE)

Aside from security updates, the new versions include a handful of beneficial bug fixes for various minor issues.

For a complete list of changes, see the 2.4.2-p1 Release Notes and 2.3.5-p1 Release Notes.

Versienummer	2.3.5-p1 / 2.4.2-p1
Releasestatus	Final
Besturingssystemen	BSD
Website	pfSense
Download	https://www.pfsense.org/download/
Licentietype	GPL

Reacties (37)

[ds65ag5g5as78a]

Kan je dit ook prima in een vm draaien om te testen? (totaal geen ervaring met pfsense)
Edit: ik lees van wel, dus ik ga er mee aan de slag.

[Reactie gewijzigd door ds65ag5g5as78a op 24 juli 2024 02:16]

[RedPixel]

Tip: mocht je gaan NATten krijg je random TCP retransmissions en komen TCP pakketjes niet meer aan. Om dat te fixen moet je TX Offloading uitzetten in de settings. (Heeft mij best lang gekost om achter te komen, meermaals)

Meer info:
https://forum.pfsense.org/index.php?topic=88467.0

[CH4OS]

Ik heb gisteren toevallig OPNsense geinstalleerd en ook pfSense overwogen, daarbij vond ik binnen 5 minuten dat TX offloading uitgeschakeld moet worden (met screenshots erbij), ik geloof dat het bij een van de twee zelfs op de download pagina vermeld staat. Verbaasd mij eigenlijk een beetje dat een ander daar meermaals moeite mee heeft om te vinden.

En @ds65ag5g5as78a, niet vergeten om als je het gaat virtualiseren, om ook de client van de hypervisor te installeren. Voor VMWare is dat geloof ik os-vmware, zo uit mijn hoofd. Kan zijn dat het binnen pfSense anders heet.

[Reactie gewijzigd door CH4OS op 24 juli 2024 02:16]

[RedPixel]

De grootste moeite zit in doorhebben dat je netwerkproblemen veroorzaakt worden door de virtualisatie. Dat het vervolgens zo lang duurde kwam vooral omdat ik op een lokatie zonder internet zat

[ExIT]

De laatste maanden ben ik hier onderzoek naar aan het doen.

Simpel gezegd: ja, het is mogelijk.

Maar!

Het is een firewall. Veiligheid is meestal je nummer 1 reden om dit pakket te gebruiken. Een firewall virtualiseren is per definitie een potentieel gevaar.

Dit zit als volgt; een firewall bepaald wat mag en wat niet mag. Hoe complexer je omgeving, hoe meer risico dat er iets mis kan gaan. Dit begint in geval van VM’s met de VM-software. Is die 100% veilig? Één exploit en men kan uit de VM breken en dus om je firewall heen.

VM software is rederlijkewijs veilig. Maar theoretisch gezien, waarom het risico lopen?

De VM software draait op een host OS. Bijvoorbeeld VMWare onder Windows. Is Windows veilig? Rederlijkewijs wel. Maar wil je het risico lopen? Een exploit in je host OS is een potentieel gevaar.

Dan kun je nog een hypervisor afwegen. Dit is niet echt een OS, maar fungeert ongeveer zo. Het laat toe dat je een afzonderlijke systemen draait. De hypervisor zelf is vaak klein, alleen het broodnodige en daarom minder kans op exploits. Maar een gat in je hypervisor en je beveiliging is in theorie opnieuw in gevaar.

Dus pfSense op een dedicated stuk hardware draaien, met twee fysieke netwerkkaarten (intern netwerk en richting ISP) is in theorie het beste. Zelfs VLAN’s brengen immers risico met zich mee.

Zo beperk je risico tot exploits in je hardware (Intel ME anyone?), het FreeBSD OS waar pfSense op draait én pfSense zelf.

Net als met verzekeren is beveiligen een kwestie van risico afwegen en gepaste acties ondernemen. Weeg voor jezelf af of jouw idee veilig genoeg is voor jouw doeleind.

[PostHEX]

Dan kun je nog een hypervisor afwegen. Dit is niet echt een OS, maar fungeert ongeveer zo. Het laat toe dat je een afzonderlijke systemen draait. De hypervisor zelf is vaak klein, alleen het broodnodige en daarom minder kans op exploits. Maar een gat in je hypervisor en je beveiliging is in theorie opnieuw in gevaar.

Ik denk niet dat je snapt wat een hypervisor en een VM werkelijk zijn. Een VM kan uitsluitend op een hypervisor draaien. Dat is de definitie van een hypervisor. Wat jij bedoelt is een onderscheid tussen een type 1 en een type 2 hypervisor.

Een type 1 hypervisor heeft directe toegang tot de hardware van de fysieke machine (omdat het op een eigen OS draait, of alleen een kernel), en wordt daarom ook een baremetal hypervisor genoemd.
Een type 2 hypervisor heeft geen directe toegang tot de hardware van de fysieke machine (omdat het op een niet-eigen host OS draait).

Een type 1 hypervisor is bijvoorbeeld VMware ESXi of Hyper-V (ondanks dat je mogelijk zou verwachten dat Hyper-V dat niet is, omdat het op Windows draait, maar het is wel degelijk een baremetal hypervisor, vanwege de integratie in Windows en heeft dus directe toegang tot de hardware van de fysieke machine).
Een Type 2 hypervisor is bijvoorbeeld VMware Workstation of Oracle Virtualbox.

Edit: Hyper-V is type 1 niet vanwege wat ik dacht de integratie met Windows, maar wanneer je Hyper-V activeert in je Windows, je Windows install als VM wordt omgezet en Hyper-V zich als hypervisor dus onder je Windows plaatst. Al is dit alleen maar mogelijk door de native samenwerking tussen Hyper-V en Windows, en is Hyper-V dus een uitzonderlijk geval in hypervisor land.

[Reactie gewijzigd door PostHEX op 24 juli 2024 02:16]

[ExIT]

Je hebt ook gelijk. In mijn vak probeer ik een uitleg vaak beknopt en eenvoudig te houden. Uiteraard komt er veel meer bij kijken.

[Question Mark]

Het hele idee van een firewall is scheiding aanbrengen in netwerkzones. Zolang je de managementinterfaces van je hosts (fysiek) scheidt is er weinig aan de hand met het draaien van een firewall op een virtualisatieplatform.

Voor praktisch elk groot securityprodukt is ook wel een een virtuele editie van te vinden. (zie bv. https://f5.com/products/deployment-methods/virtual-editions)

[ExIT]

Met alle respect deel ik die visie niet. Uit mijn onderzoek haal ik voor het gemak even twee bronnen als voorbeeld:

https://support.microsoft.com/en-gb/kb/3135456

https://insinuator.net/20...-of-hypervisor-breakouts/

[latka]

Het risico wordt al een stuk minder als je een Nic via passthrough aan 1 vm toekent en, zoals altijd, geen extra tools in de vm installeren (vmware tools oid). Ja, met een vm oplossing is de attack surface groter dan zonder, alhoewel met Intel AMT je je dit sterk kunt afvragen.

[Sandor_Clegane]

Ik heb een hardware NIC aan de VM gegeven. Voor het host systeem is deze nagenoeg onzichtbaar.

[ExIT]

Dat is een interessant idee. De zwakte van een VM firewall kan zijn dat de NIC ook het host OS blootgeeft. Bijvoorbeeld tijdens het starten, waarbij de host de kaart bestuurt en de VM nog niet geladen is.

Ik kan me voorstellen dat je het host OS geen driver geeft voor de NIC. Mits juist uitgevoerd kan dat iets zijn. Ga ik ook testen, goed idee. Dit kan bij sommige kernels werken.

Resteert wel het risico van de VM software zelf nog. Maar nogmaals, het gaat om risico afwegen tegen de situatie.

[Sandor_Clegane]

Op Linux werkt dit erg goed. Zo heeft een andere VM een complete USB controller van het moederbord voor zichzelf voor de TV Tuner die eraan hangt.

Met PCI-Stub en VFIO kun je ze nog verder afzonderen.

[Sandor_Clegane]

Yep, heb hem draaien op KVM.

[mjl]

Werkt ook in VMware workstation.

[Ik&www]

Of op Proxmox VE. Wel de WAN NIC alleen aan de VM koppelen.

[EverLast2002]

Kun je dit nader toelichten?

[Ik&www]

Jawel, maaaar internet kan het veel beter :-).
http://mattcarey.me/2016/03/08/running-pfsense-proxmox-vm/
Hier word echter gebruik gemaakt van 3 NIC's, wat in mijn ogen een beetje too much is voor thuis (de LAN NIC zitten immers op het zelfde interne netwerk).
Ik ben geen ICT'er (wel industriele programeur, plc's enzo) maar volgens mij is het belangrijkste dat het ingaande draaidje (WAN) eerst via de PFSENSE moet gaan. Maar misschien heb ik het wel mis.

[rickdtop]

yup, hij draait prima binnen KVM. Dat is met slechts 1 core, 1GB ram en 10GB disk.
Performance is dan nog vlekkeloos binnen redelijke omgevingen.

[Starck]

En op HyperV ook geen probleem.

[Uberprutser]

Draai pfSense al jaren in een VM naast een sloot andere VMs

[Peran]

Jep, Hyper-V

[Polderdijk]

Draai hier ook als test thuis op 2 hyper-v met carp. Werkt perfect. Vanuit ziggo een apart vlan naar dedicated NIC's en een apart VLAN voor CARP verkeer.
Snelheid gewoon netjes max (500/50 down/up) en mooi redundant.
Master draait op een echte server en slave op een goedkope/zuinige nuc.

[kr4t0s]

Helaas nog niet verkrijgbaar voor Raspberry Pi. Dat zou erg handig voor thuis zijn.

[Uberprutser]

Raspberry heeft niet echt voldoende power om goed te performen. Ook zou je met Vlans moeten werken omdat je maar 1 eth interface hebt en wifi slecht wordt ondersteund in pfSense.

[kr4t0s]

Las dat het qua power moet kunnen. Maar omdat freebsd ARM support niet goed genoeg zou zijn willen ze geen officiële release maken. Er zijn wat hobby bob dingetjes op Github te vinden.
Wi-Fi heb ik niet nodig. Vlan support is er voor de PI. Of 2de netwerkkaart via USB

[Reactie gewijzigd door kr4t0s op 24 juli 2024 02:16]

[Ventieldopje]

Niet wat overkill voor een 100mbit/s NIC? Laat staan via USB

[kzin]

Ik heb hem draaien op een APU2C4 bordje van ca 10x10 cm. Kan zonder fan draaien in een passende behuizing. Wel iets duurder dan een raspberry (€129). Het bordje heeft 3 netwerk aanslutingen, dus WAN, LAN en een vrije keuze.
Op community.ziggo.nl heb ik mijn ervaring beschreven met het in gebruik nemen.

[EverLast2002]

Ik heb hier dezelfde APU appliance liggen (niet in gebruik). Leuk om die artikelen van je door te lezen.
De tip over Configserver Firewall vond ik ook interessant.

[noskill]

Bijgevoegde screens kloppen overigens niet meer helemaal, de interface heeft vanaf 2.4(.1?) een nieuw logo gekregen.

[trebor.ed]

Ik ben erg tevreden over de laatste releases van pfsense. Er is een hoop werk verricht door de ontwikkelaars en dat is (aan de voor en achterkant van pfsense) goed merkbaar. Zeer stabiel en snel !

[opa uche]

Ah, dan nog maar een keertje updaten op die Checkpoint 4200, ging zo makkelijk
Leuk die ouwe meuk, en handig dat opensource

[mjl]

Zo jammer dat dit meteen een hele Linux distributie moet zijn, zou mooi zijn als dit ook via apt-get / curl / yum package managers zou kunnen worden geïnstalleerd.. ik heb al wat services draaien op centos bijv, maar daar krijg je dit dan weer niet op geinstallleerd...

[Nindustries]

Dit is BSD by the way
Maar een schil rond standaard utilities zoals pf, openvpn en dergelijke.

[Reactie gewijzigd door Nindustries op 24 juli 2024 02:16]

[mjl]

Ben geen Unix kenner, rommel maar wat aan 😋

[pbeer]

Het is een hele FreeBSD distributie, geen Linux distributie.

Moest één of enkele van die services die je al draaiende hebt een kwetsbaarheid bevatten, dan zou die gebruikt kunnen worden om andere zaken op dat systeem (incl firewall) te besturen. Vandaar dat een firewall op een apart systeem voor mij toch de voorkeur zou hebben. Zo is de firewall zelf minder kwetsbaar.

[rbr320]

Dat komt omdat het helemaal niet is gebaseerd op Linux maar op FreeBSD, zoals het artikel ook vermeld. pf is de standaard firewall op BSD zoals iptables dat is op Linux. Over het algemeen wordt pfSense geroemd omdat het eenvoudig te configureren is ondanks dat het veel opties heeft.

[Reactie gewijzigd door rbr320 op 24 juli 2024 02:16]