POSTED BY

POSTED ON

October 21, 2017

POSTED UNDER

Pensamentos

COMMENTS

Comments Off on OPNSense – A evolução lógica do Software Defined Networking

OPNSense – A evolução lógica do Software Defined Networking


Olá a todos,

Desde o ultimo post que tenho estado ocupado em migrar o meu firewall cluster de pfSense para um em opnSense.

Podem perguntar porque o fiz, tendo em conta que a pfSense é utilizada em larga escala em ambientes com software defined networking (logo tem muito mais documentação disponível na net), e a opnSense tem sido considerada como o underdog inicial desde que o projecto fez o seu fork em 2015.

A resposta até é bastante simples: A meu ver a pfSense está a tornar-se aos poucos uma solução mais voltada para a vertente comercial, e a afastar-se cada vez mais do sentido de comunidade.

Por enquanto continuam a disponibilizar a solução gratuitamente, com todas as features enabled, mas a probabilidade é que isto irá eventualmente desaparecer, da mesma forma que as novidades  do bacula foram sendo disponibilizadas apenas para utilizadores com subscrição paga, ficando a community edition varias versões e features atrás.

A somar a isto a com a postura dos developers nos fóruns do produto e nos fóruns do reddit em si (se um bug que descobriram afectar a direção comercial do produto, e o reportarem publicamente, o vosso post será apagados e o vosso utilizador banido) ditaram o destino do produto para mim.
Vários elementos da comunidade notaram igualmente esta tendência e como tal optaram por voltar a um modelo puramente opensource e free: a opnSense.

Na prática, e em showdown ambos os produtos tem as suas fraquezas e as suas vantagens:

pfSense:

+ Marca mais conhecida. Maior documentação de como fazer (howto) disponível na net.
+ A versão 2.4 já suporta ZFS, ou seja snapshot e restore muito mais rápido em caso de falha.
– Desenvolvimento bastante lento. Fechado apenas em alguns elementos da empresa.
– Falta de muitos avanços técnicos que a abertura da opnSense lhe permite.
– Comportamento extremamente beligerante em relação á comunidade.
– Roadmap técnico, e direção futura do produto totalmente opaco (o que leva a suspeita de em breve passar para um modelo de pay-for-goodies).
Edit: Existe um roadmap. Escrito em 2015.

opnSense:

+ Já baseada em FreeBSD 11.0 ao invés de um BSD altamente modificado da pfSense que acaba por trazer alguns problemas de compatibilidade quando o formato ou filosofia no BSD muda.
– O FreeBSD 11.0 tem o seu End of Life em October 26, 2017.
+ WebGUI mais em consonância com o formato atual das firewalls profissionais de mercado.
+ Utilização de tecnologias correntes (PHP 7, phalcon 3, …).
+ Software utilizado extremamente conhecido e mainstream (openvpn, squid, suricata, charon).
+ Mais security oriented que a pfSense em termos de filosofia do sistema operativo de suporte.
+ Parceria direta com o HardenedBSD (com o uso opcional of LibreSSL, SafeStack, …!)
+ Muitas linguagens de GUI suportadas.
+ Rodmaps públicos do produto e na sua filosofia.
+/- Por ser bastante mais aberto que o seu congênere, o ciclo de patching e resolução de problemas de segurança acaba por ser bastante mais rápido.
– (por agora) Bastante menos conhecido que o seu concorrente.
– (por agora) Problemas identificados no método de instalação por USB3 devido a bugs no BSD.
– Não ser possível instalar em ZFS, sendo necessário o habitual backup/restore via a webgui do produto.

Os developers da opnSense estão cientes dos issues, e das possibilidades que o seu produto abre á comunidade.
A expressão desta filosofia, levou eles a suportarem a migração direta entre pfSense e opnSense utilizando para tal  a ferramenta built-in de restore de configuração.

O processo embora nos auxilie em muito na migração é necessária alguma atenção, especialmente se utilizarem nas vossas regras caracteres latinos nas descrições, ou carácteres especiais.
Isto é particularmente visível se tiverem regras de autenticação em LDAP para as vossas VPN’s (por exemplo com instancias IPA).

Os issues com que eu deparei na migração foram:

a) A filosofia das vossas regras de traffic shapping tem de ser refeitas pois a filosofia do produto é diferente logo a metodologia é diferente.

b) O binding das vossas VPN’s – onde elas vão amarrar – parte fundamental para evitar flapping de acessos quando se utliza um cluster, está mal implementado na importação, ficando amarrado á primeira interface disponível na vossa firewall.
Terão de na vossa nova configuração, de associar a VPN ao VIP correto de firewall.
Aplica-se a IPSEC e a OPENVPN.

c) A importação de regras que originalmente na pfSense tenham QOS em zonas de rede (WAN, LAN, OPT, etc) não são importadas corretamente, tendo de ser apagadas e recriadas apenas na zona de traffic shapping (devido a mudança de paradigma).

d) Os caracteres especiais (&,(, á, à, ~) são mal interpretados e como tal são mal carregados. Isto é particularmente critico em configurações importadas para autenticação em serviços externos (LDAP, IPA, IDM, AD, etc).
Terão de validar se os caracteres estão corretos nas vossas extended querys de autenticação na secção de System, Access, Servers.
Em seguida  *testem* se conseguem aceder utilizando o tester no mesmo menu.

e) Configurações de NAT para transparent proxy:
A opnSense tem uma implementação muito mais “amiga” de configurações simples. Este tipo de filosofia estendeu-se ao webproxy.
Logo para transparent, ou proxy redirect, apenas terão de activar o pisco na interface pretendida, sem ser necessário de fazerem redirects ao nível de NAT o que nos obriga a tirar regras que tenhamos colocado para conseguir este efeito na pfSense.


f) Simplicidade na configuração do webproxy:
A opnSense ao contrário da pfSense procura implementar todas as configurações de ficheiros standard das aplicações ao invés de carregar as configurações desde um xml primário.
Isto acaba por conseguir que as nossas tradicionais configurações que tenhamos perdido tantas horas a apurar possam ser carregadas.
Os developers criaram dois ficheiros para tal e a sua invocação pode ser vista no ficheiro de configuração do squid:

# cat /usr/local/etc/squid/squid.conf| grep -I “*.conf”

include /usr/local/etc/squid/pre-auth/*.conf
include /usr/local/etc/squid/auth/*.conf
include /usr/local/etc/squid/post-auth/*.conf

g) O processo de importação das regras da pfsense para web proxy não leva em conta a autenticação em ficheiro através do método basic_ncsa_auth. As vossas contas terão de ser copiadas á mão desde o ficheiro original desde a vossa pfSense.

h) A importação de configurações de HAProxy/Load Balancer não são importadas. Toda a vossa reconfiguração terá de ser efetuada manualmente, ou com o ficheiro de haproxy.conf original ao lado para ser lida e re-carregada.
Existe já um bug report aberto sobre o tema no GITHUB dos developers do produto.

I) O IDS/IPS utilizado na opnSense é o Suricata ao invés do Snort que era rei na pfSense.
Existem várias vantagens nesta escolha, especialmente porque já implementa nativamente netmap o que permite que as regras de IDS sejam validadas *antes* do pacote chegar á fase de processamento de regra.
Ou seja, não existem hosts bloqueados em regra como na pfSense, mas quando uma regra é activada por uma condição existente, o pacote é automaticamente bloqueado.
A vantagem desta metodologia é o decréscimo AGRESSIVO no consumo de CPU da firewall quando sujeita a muito tráfego. Menos cpu para operações de IDS/IPS traduz-se em maior velocidade no tráfego que passa pela firewall.
O único problema é que nos irá obrigar a configuração de um novo software não podendo usar as regras anteriores.
No entanto não se preocupem. As vossas rulesets favoritas de detecção estão lá todas.

NOTA: A utilização de netmap irá obrigar que a vossa interface WAN (ou onde estará o IDS/IPS á escuta) não ser VIRTIO (em máquinas virtuais) por bug na implementação do netmap no driver.
Em alternativa podem utilizar interfaces virtuais e1000 que garantem 1GB de capacidade de trafego internet. Em caso de mais velocidade disponível, podem utilizar LACP com múltiplas interfaces e1000.
Em interfaces físicas desde que implementem corretamente a feature netmap não deverá haver problemas.
Existe uma lista no site da opnSense e da Suricata sobre quais as placas fisicas suportadas.

j) Após o import inicial, o unbound DNS irá funcionar mal, causando um aparente crash/hang no boot da firewall se não reconfigurado antes do primeiro reboot.
O motivo deve-se exactamente com a mesma razão que nos obriga a reconfiguração das VPNs e do seu bind: O unbound ficará agarrado á primeira interface disponibilizada no restore. Se for uma interface que não é física, por exemplo uma vpn que irá iniciar no boot na fase seguinte, irá ficar parado a espera que esta seja disponibilizada causando um hang.
Para corrigir atribuir a interface de serviço do unbound DNS a uma interface física especifica (por exemplo a LAN).

Em todo o restante, regras, configurações de openvpn e ipsec, gateway monitoring, dns reflection and redirection with view funcionaram perfeitamente bem.
Mesma coisa para os utilizadores, certificados e grupos de serviço.

Concluindo, o produto está extremamente promissor, e é um sério aviso ao domínio do mercado do SDN opensource que atualmente pende na direção da pfSense.

Quem me conhece sabe o empolgado que eu estou com ele, pois trata-se de um produto com uma filosofia muito mais aberta que o anterior, e com uma participação da comunidade muito mais activa que a pfSense.

Recomendo que testem o produto com mente aberta. Tem muito potencial na filosofia e na qualidade.

Pessoalmente, migrei o meu homelab nesta direção and so far, so good 🙂
Caso tenham duvidas ou necessitem de algum auxilio nos vossos testes e migrações já sabem onde me podem encontrar ou em alternativa enviem-me um email para nuno[at]nuneshiggs.com

Update 24.01.2018:

Surgiu hoje um artigo extremamente interessante no Reddit sobre este tema que transcrevo na integra:

A few months back I converted from pfSense to OPNSense. I took some notes on what differences I found. I had been using pfSense for years, but was new to OPNSense. Since a lot of people are looking to drop pfSense, I thought they may find this handy as I couldn’t find anything similar when I was searching. Corrections welcome as I’m sure I missed something.

  • pfSense documentation is behind paywall.
  • pfSense serial works all the way to boot. XXX Check OPNSense.
  • In OPNSense you can update all the packages at once.
  • In pfSense, you have to update packages individually.
  • OPNSense is friendly to the community.
  • OPNSense allows to select mirrors for updates.
  • pfSense has very slow update servers sometimes, and no selection.
  • OPNSense interface is much faster than pfSense.
  • OPNSense interface is much cleaner than pfSense.
  • OPNSense doesn’t throw legalese on install.
  • OPNSense doesn’t try to prevent resellers from using the system.
  • OPNSense has an “Audit” button for checking for vulns in package management.
  • Package manager lists licenses for packages.
  • OPNSense allows selection between using OpenSSL or LibreSSL system. Most packages get re-installed when switching from default OpenSSL to LibreSSL.
  • OPNSense dragging of widgets in Dashboard works much better and faster.
  • OPNSense: Prefer to use IPv4 even if IPv6 is available. (in both)
  • OPNSense: Lock: Prevent interface removal.
  • OPNSense: Hardware CRC/TSO/LRO default disabled (confirm pfSense?).
  • Check dnsmasq and wpa_supplicant security updates.
  • OPNSense dnsmasq update: Oct 05 2017.
  • OPNSense wpa_supplicant Oct 20 2017.
  • As of 21 Oct 2017, pfSense had no notice about dnsmasq or KRACK at: https://www.pfsense.org/security/advisories/
  • As of 21 Oct 2017, there was only 1 post at http://lists.pfsense.org/pipermail/security-announce/ for Status_Monitoring. Previous post was in July 2017.
  • OPNSense: IDS in default install. (Is it Suricata?)
  • OPNSense has OpenDNS service: Filter DNS requests using OpenDNS.
  • The highest-end pfSense Netgate firewalls don’t have dual power supplies.
  • OPNSense has 2 factor auth, pfSense doesn’t. It can be kludged via Radius on pfSense. https://wiki.opnsense.org/manual/how-tos/two_factor.html
  • OPNSense menu on left, pfSense menu on top.
  • OPNSense uses hardened kernel (pfSense?).
  • OPNSense, easily view system update changelogs.
  • OPNSense support plans vs. pfSense.
  • OPNSense web GUI framework (fast!): https://phalconphp.com/en/
  • XXX Reasons listed in OPNSense fork.
  • Is OPNSense docs on Github? Where is source to this, for instance? https://wiki.opnsense.org/intro.html
  • OPNSense has Tor built in (pfSense no, correct?). XXX
  • OPNSense has ZeroTier built in.
  • OPNSense Collectd settings with Graphite, etc. (in pfSense?) XXX
  • OPNSense has cleaner Let’s Encrypt integration, afaict.
  • Built in OpenDNS support.
  • Easy Netflow integration, with “Insight” graphs (this is using Netflow, ya?) XXX.
  • OPNSense: “Prevent interface removal”, may prevent pfSense USB LTE device booting issue.
  • OPNSense dashboard, under Gateways, doesn’t show the IP address of Monitor IP.
  • OPNSense, cannot modify dashboard traffic graph update rate.
  • OPNSense dashboard traffic graph groups traffic to In/Out, whereas pfSense has a graph for each interface.
  • OPNSense IPSec (not being used) appears in dashboard network graph.
  • OPNSense has API, and CLI management tools in Golang.
  • OPNSense has MVC plugin framework.
  • OPNSense can be installed from a fresh FreeBSD install, can pfSense? XXX
  • Juju — Provisioning system in Ubuntu, looks pretty nice. Also available as a snap application. https://jujucharms.com/

 

Abraço!
Nuno Higgs