Software-update: OPNsense 18.1

Het pakket OPNsense is een firewall met uitgebreide mogelijkheden. Het is gebaseerd op het besturingssysteem FreeBSD en is oorspronkelijk een fork van m0n0wall en pfSense. Het pakket kan volledig via een webinterface worden ingesteld en heeft onder andere ondersteuning voor 2fa, openvpn, ipsec, carp en captive portal. Daarnaast kan het packet filtering toepassen en beschikt het over een traffic shaper. De ontwikkelaars hebben OPNsense 18.1 uitgebracht met de volgende aankondiging:

OPNsense 18.1 Released

Hello good folks of the Internet,

For more than 3 years now, OPNsense is driving innovation through modularising and hardening the open source firewall, with simple and reliable firmware upgrades, multi-language support, HardenedBSD security, fast adoption of upstream software updates as well as clear and stable 2-Clause BSD licensing.

We humbly present to you the sum of another major iteration of the OPNsense firewall. Over the second half of 2017 well over 500 changes have made it into this release, nicknamed "Groovy Gecko". Most notably, the firewall NAT rules have been reworked to be more flexible and usable via plugins, which is going to pave the way for subsequent API works on the core firewall functionality. For more details please find the attached list of changes below.

The upgrade track from 17.7 will be available later today. Please be patient. 🙂

Meltdown and Spectre patches are currently being worked on in FreeBSD, but there is no reliable timeline. We will keep you up to date through the usual channels as more news become available. Hang in there!

These are the most prominent changes since version 17.7:

• FreeBSD 11.1, PHP 7.1 and jQuery 3 migration
• Realtek vendor NIC driver version 1.94
• Portable NAT before IPsec support
• Local group restriction feature in OpenVPN and IPsec
• OpenVPN multi-remote support for clients
• Strict interface binding for SSH and web GUI
• Improved MVC tabs and general page layout
• Shared forwarding now works on IPv6, in conjunction with "try-forwarding" and improved reply-to multi-WAN behaviour
• Easy-to-use update cache support for Linux and Windows in web proxy
• Intrusion detection alert improvements and plugin support for new rulesets (ET Pro, Snort VRT)
• Revamped HAProxy plugin with introduction pages
• Moved interface selection to menu and quick search for firewall rules, DHCP and wireless status
• Alias backend rewrite for future extensibility
• Plugin-capable firewall NAT rules
• Migration of system routes UI and backend to MVC (also available via API)
• Reverse DNS support for insight reporting (also available via API)
• Fully rewritten firewall live log in MVC (also available via API)
• New plugins: zerotier, mdns-repeater, collectd, telegraf, clamav, c-icap, tor, siproxd, web-proxy-sso, web-proxy-useracl, postfix, rspamd, redis, iperf, arp-scan, zabbix-proxy, frr, node_exporter

Versienummer	18.1
Releasestatus	Final
Besturingssystemen	BSD
Website	OPNsense
Download	https://opnsense.org/download
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (14)

[webside007]

Kan iemand me eens uitleggen op welke hardware dit draait?
Ik heb een 250Mbit lijn (down).
Kan men ook https inspection doen? En zakt de snelheid van je lijn dan niet?

[FREAKJAM]

Je kunt het ook prima virtueel draaien. Zie hier de hardware sizing. Informatie over IPS vind je hier. Heck, lees de docs eens zou ik zeggen

on-topic:
Zelf draai ik al jaren pfSense, maar ik zou toch graag eens deze fork willen proberen. Vanavond maar eens mee spelen in VMWare.

[jurroen]

Ik kan je OPNsense van harte aanbevelen. pfSense heeft, in mijn ogen, flink wat steken laten vallen. Ze implementeren LibreSSL niet omdat de lead dev "de ontwikkelaar van OpenSSL kent en vertrouwt". Genoeg redenen te bedenken om zo'n keuze bewust niet te maken, maar dit is slechter dan slecht.

Daarnaast is OPNsense leading geweest met enkele fijne changes waarvan pfSense die voor een deel heeft overgenomen. Scheiding tussen webinterface en systeem (ipv alles als UID 0 draaien), HardenedBSD ipv FreeBSD, Suricata ipv Snort, etc.

Vind de webinterface ook fijner, maar dat is heel erg persoonlijk uiteraard.

[ppl]

Ik kan je OPNsense van harte aanbevelen. pfSense heeft, in mijn ogen, flink wat steken laten vallen. Ze implementeren LibreSSL niet omdat de lead dev "de ontwikkelaar van OpenSSL kent en vertrouwt". Genoeg redenen te bedenken om zo'n keuze bewust niet te maken, maar dit is slechter dan slecht.

Beetje lullige reden zou je denken maar je vergeet hier dat een ontwikkelaar er zelf ook vertrouwen in moet hebben en dat is kennelijk met OpenSSL beter dan met LibreSSL. Flut reden of niet, persoonlijke voorkeur en ervaring zal altijd meespelen bij het maken van keuzes. Het zal echter niet de enige reden zijn waarom ze voor OpenSSL hebben gekozen. Er is nou eenmaal heel wat meer ondersteuning voor OpenSSL dan voor LibreSSL. Vergeet niet dat ze destijds behoorlijk hebben lopen snijden in OpenSSL om er LibreSSL van te maken.

Daarnaast is OPNsense leading geweest met enkele fijne changes waarvan pfSense die voor een deel heeft overgenomen. Scheiding tussen webinterface en systeem (ipv alles als UID 0 draaien), HardenedBSD ipv FreeBSD, Suricata ipv Snort, etc.

Dat willen sommige OPNsense mensen graag geloven. In werkelijkheid wordt er volop met modder naar elkaar gegooid en is de kans dat een uitspraak uit 1 van de kampen daadwerkelijk klopt nagenoeg nihil. Als je rond zoekt zul je genoeg informatie vinden dat beide projecten gelijktijdig met de door jou genoemde zaken bezig zijn gegaan; je kunt daar geen "die is het eerste" uit destilleren. Bovendien waren pfSense en OPNsense niet de enige FreeBSD based projecten die voor scheiding van webinterface en systeem en de omzet naar het zijn van een simpele meta package in FreeBSD hebben ingezet. Verder is het ook totaal niet interessant wie er nou het eerste is. Liever een gezonde concurrentie op features en techniek.

Ik heb liever dat men eens aan die houding ging werken dan aan de features van de software zelf. Dit is gewoon zwaar onprofessioneel en reden te meer om heel OPNsense en pfSense links te laten liggen. Als je er toch voor gaat dan kun je beter de support ook bij de dealer regelen, die zijn namelijk wel professioneel. Heel jammer want zowel pfSense als OPNsense zijn prima stukken software die nauwelijks voor elkaar onder doen. Test ze dan ook vooral beiden, dat geeft je een veel beter idee dan de "documentatie" op de websites en de meningen van mensen uit de community. Op YouTube en blogs is overigens ook genoeg informatie te vinden zonder steeds tegen al dat moddergegooi aan te lopen.

Btw, pfSense geeft je zowel snort als suricata.

Ik vraag me af wat de redenen zijn geweest om dan voor HardenedBSD te gaan ipv OpenBSD (als je dan toch een OS zoekt met het oog op security...). Het grote voordeel van FreeBSD is dat je dit ook op ARM kunt draaien terwijl HardenedBSD (en dus ook OPNsense) weer x86 (32/64 bit) only is. Of dat nou zo'n goed idee is gezien het gestuntel van Intel de laatste tijd... Daarnaast is FreeBSD ook officieel ondersteund op VMware ESXi en Microsofts Hyper-V. Het is even de vraag in hoeverre HardenedBSD dat nog is. Alles heeft zo zijn voor- en nadelen.

[Reactie gewijzigd door ppl op 23 juli 2024 21:04]

[job_h]

https://opnsense.org/download

Select you systems architecture, supported are i386 (32bit) and amd64 (64bit).

Het is een firewall en routing platform gebaseerd op FreeBSD. Dus misschien dat het, net als FreeBSD, in de toekomst meer platformen gaat ondersteunen. pfSens ondersteund sinds kort ARM. OPNsense is een fork van pfSense, wat weer een fork was van m0n0wall.

Ik vind https inspection een beetje vies... Als je https inspection wilt doen zonder actief software te draaien op de gebruikers apparaten, moet je een eigen certificaat autority instellen en het root certificate installeren op de gebruikers apparaten en in principe een man-in-the-middle attack uitvoeren. De https traffic wordt op je firewall ontsleuteld, gecheckt, weer versleutelt met je eigen certificaat en naar het apparaat gestuurd die het opgevraagd had. Op de apparaten van je gebruikers zullen https websites dus altijd het certificaat van je https inspector hebben.

Dit is precies de reden waarom ik bij mijn virusscanner SSL website scanning uit heb staan. Ik wil niet dat mijn browser bij iedere website zegt dat hij een SSL certificate heeft van BitDefender. Ik vind het veel veiliger om te zien dat de Rabobank een certificaat van DigiCert heeft en de ING van Entrust, zodat ik weet dat er iets mis is als er opeens een certificaat van Diginotar zou staan.

Maar om je vraag te beantwoorden, het kan wel: https://docs.opnsense.org...tos/proxytransparent.html

[Reactie gewijzigd door job_h op 23 juli 2024 21:04]

[YoeriOppelaar]

Waarom is SSL / TLS inspectie vies? Natuurlijk kun je er ook kwaad mee en geeft het je misschien iets minder inzicht in welk certificaat er gebruikt wordt en of deze nog valide is.

Nu heb ik zelf geen ervaring met OPNSenses versie van HTTPS Inspectie, maar van commerciële oplossingen als Cisco ASA/Firepower is mijn ervaring dat je kunt aangeven welke type sites je inspectie op wilt toepassen,of, welke juist niet.

Waardoor je wel inspectie op regulier traffic toepast, maar niet op je bank verkeer.

[job_h]

Waarom is SSL / TLS inspectie vies? Natuurlijk kun je er ook kwaad mee en geeft het je misschien iets minder inzicht in welk certificaat er gebruikt wordt en of deze nog valide is.

Je geeft hier zelf al antwoord op je vraag

Er zijn natuurlijk redenen om het te gebruiken en ik zeg ook niet dat je het nooit moet doen. Echter, hoe je het ook wendt of keert, het is in essentie een goed bedoelde man-in-the-middle aanval. En hoe goed bedoeld het ook is, ik krijg er een beetje de kriebels van.

[freshy98]

Die kriebels heb ik ook. man-in-the-middle is en blijft evil.

[YoeriOppelaar]

Als het wordt toegepast in je eigen omgeving, die je zelf in beheert, zou ik er geen kriebels van krijgen.
Als het buiten eigen netwerk gebeurd, vind ik een ander verhaal.

[jurroen]

Ik ben het daar niet helemaal mee eens. Voor mij is het afhankelijk van het threat model. Vertrouw je alles blindelings in je netwerk? Ik niet namelijk.

Stel dat, worst case, je OPNsense box gecompromitteerd zou worden, kan de aanvallende partij op vrijwel elk denkbare verkeer je webverkeer manipuleren. Inclusief hetgeen wat veilig hoort te zijn. Hoewel ik mijn firewall meerdere keren per week zelf naloop, zit ik er niet dagelijks in of op.

In zo'n worst case scenario zouden ze bij mij in een goed geval enkele dagen aan verkeer buit kunnen maken. Transactionele gegevens (internetbankieren), medische gegevens (een "mijn" ziekenhuis, mail met dokter of online omgeving zorgaanbieder), maar ook mails etcetera.

Ik zit daarentegen wel elke dag achter/op mijn werkpaard, waar ik eerst de beveiliging naloop alvorens vertrouwelijke informatie uit te wisselen. Ja, daarbii ga ik verder dan even snel anti-malware app openen om te zien of ie een groen of rood balkje heeft.

Dat gezegd hebbende, ik vertrouw OPNsense meer dan ik Windows ooit zal vertrouwen, of welke andere firewall-met-grafische-schil dan ook. OPNsense gebruikt HardenedBSD (basically, FreeBSD met betere exploit mitigation), ondersteund 2FA, {H/N}IPS, inzicht in traffic, etc. En ze zijn snel met het fixen van vulnerabilities.

[Rataplan_]

https inspection kan je zover ik weet alleen doen wanneer je opnsense als proxy gebruikt (squid?). Wanneer een client in je netwerk namelijk een eigen (genatte / gerouteerde) verbinding met een https server heeft opgezet, kan opnsense daar niet meer in kijken. opnsense zal dus de verbinding moeten termineren en opnieuw opzetten. Als je aan de binnenkant dan alsnog https verkeer wil hebben zal je het met een eigen certificaat moet signen, wat maakt dat bv rabobank.nl niet meer het Rabobank certificaat gebruikt, maar een eigen certificaat. Dat laat dan bij de wat slimmere gebruiker weer bellen afgaan.
En ja, natuurlijk maakt dat je verbinding marginaal trager, maar op een beetje fatsoenlijke hardware ga je er weinig van merken.

[CH4OS]

Ik heb eens geprobeerd om OPNsense te gaan draaien voor RADIUS + OpenVPN (met eventueel een captive portal voor een guest wifi), maar tot op heden was mij dat helaas nog niet gelukt. Ik lees wel dat het zou moeten kunnen, maar welke uitleg ik ook probeerde, uiteindelijk werkte het niet. Kan ik ergens kort en bondig hierover lezen? Met Google wordt ik ook niet veel wijzer.

[Reactie gewijzigd door CH4OS op 22 juli 2024 16:23]

[freshy98]

Probeer je vraag eens te plaatsen op het forum van OPNsense.
https://forum.opnsense.org

[GeroldM]

OpenVPN heb ik volgens de wiki op de OPNSense website ingesteld, maar nog nooit een verbinding tussen mijn thuis computer en de plek waar ik deze OPNSense server heb draaien op kunnen zetten.

Draai meerdere websites, WebDAV, RIOT video conferencing server en eigen mail server op de plek van de OPNSense server en dat werkt uitstekend. De OpenVPN client software, gegeneerd op de OPNSense server, installeert prima op mijn Windows doos thuis, inloggen lukt ook, maar daadwerkelijk contact krijgen met machines aan de andere kant, dat dan weer niet.

Sinds 17.1 heb je de beschikking over twee alternatieve VPN oplossingen. Tinc moet ik nog gaan proberen maar het andere alternatief heeft hetzelfde probleem als OpenVPN. Ook nu weer de wiki instructies van OPNSense gevolgd en opnieuw gaat alles goed behalve het daadwerkelijk contact krijgen met de ingestelde computer(s). Met Tinc verwacht ik hetzelfde resultaat, dus daar ga ik nog well eens een keertje mee spelen als ik niks beters te doen heb.

Zelfde gezeur had ik ook met pfSense (in combinatie met OpenVPN), welke ervoor zorgde dat ik naar alternatieven voor pfSense begon te zoeken en bij OPNSense terechtkwam.

OPNSense vind ik persoonlijk prettiger in de omgang dan pfSense, maar beide producten/omgevingen zijn goed in wat ze doen. Ter verduidelijking, beide producten heb ik gebruikt op meerdere dedicated PCs. Dat wil zeggen, de oudste, nog redelijk werkende PC in het computerpark word ingezet als vervanger van de huidige router.

De baas geeft liever geld uit aan een nieuw systeem voor een werknemer (goed voor moraal) wanneer de router het opgeeft. De vrijgekomen PC kan dan weer gemakkelijk ingezet worden als nieuwe router. Vaak is dat gewoon een kwestie van de hard disk en NICs overzetten van de oude router in de nieuwe en eventueel de interfaces opnieuw in te stellen. En dat trucje werkt ook gewoon als je tussen Intel (x86/x64) en AMD (x86/x64) machines wisselt.