Messages

[DESCRIÇÃO]

======================================================
===              OPNSENSE - SOBREVIVENDO NA LINHA DE COMANDOS                 ===
======            1 Temporada: EP III - Você disse "Counter Strike"?             ======
======================================================
Responsável: ludarkstar99
Data: 05/11/2024
Versão: 1.1
======================================================


DESCRIÇÃO

Então você instalou a solução Crowdsec em seu firewall OPNsense e sente uma certa sensação de segurança. Quem bom! Durma bem esta noite.  Mas não vai durar para sempre essa sensação, até você descobrir que além dos IPs maliciosos tentando invadir seu firewall, e que serão bloqueados, ainda há 20% ~ 40% que irão furar essa rede de vizinhos monitorados. Além disso, como você barra os IPs que nem estão nesta lista? E os IPs de VMs na  nuvem que foram recentemente ligadas só para tentar furar sua infraestrutura? Não quero lhe assustar, quero que durma bem após ler esta publicação, mas se continuar a leitura, está por sua própria conta.


DECRIÇÃO DO CROWDSEC

Provavelmente já deve ter ouvido falar de uma rede de vizinhos monitorados, é exatamente o que o crowdsec faz. É como aquele "motoquinha" que fica passando a noite no seu condomínio buzinando. Se ele ver uma atividade suspeita, vai ligar para a central e a central vai botar a galera pra ficar esperta - é exatamente o que o crowdsec faz - se atacarem o seu vizinho, você será notificado sobre a aparência do miliante, e vai evitar abrir a porta para estranhos, principalmente se parecerem com o informado pelo rádio.


HISTÓRIA DO CROWDSEC

Fundada por 3 membros, a ideia do crowdsec surgiu quando trabalhavam para um grande e-commerce, ai um belo dia descobriram que estavam sendo atacados por um ator malicioso com posse de 6.000 IPs. aí pensaram, e se pudesse compartilhar essa informação? não seria benéfico que pudéssemos evitar este problema e até mesmo compartilhar para outros evitarem? E se outra empresa já tivesse detectado esses problema, e tivesse compartilhado conosco estas informações de inteligência (threat intel), não estaríamos mais preparados para barrar essa ameaça?
Surgiu então a ideia de usar a inteligência coletiva.
O crowdsec é como uma rede de vizinhos monitorada, só que na internet.


INSTALAÇÃO

A este ponto você já deve conhecer. Acesse o menu System > Firmware > Plugins.
Procure pelo plugin os-crowdsec e instale-o.
Atualize a página (F5) para a configuração do plugin ficar disponível no menu.
*Alternativamente pode instalar o plugin pela linha de comandos, para não ser forçado a realizar o update do firewall antes.

Code Select Expand


pkg install -y os-crowdsec



CONFIGURAÇÃO

Acesse o menu Services > Crowdsec > Settings > Guia Settings.
Certifique-se de que as quatro caixinhas estão habilitadas:
> Enable Log Processor (IDS)
> Enable LAPI
> Enable Remediation Component (IPS)
> Enable log for rules
Clique em Apply

Aparecerá uma tarja azul indicando que o serviço está sendo configurado... aguarde.
Acesse o menu Firewall > Diagnostics > Aliases.
Acesse a tela Firewall > Rules > Floating
Expanda as regras automagicamente criadas (Automatically generated rules), deverá aparecer as duas regras abaixo na lista:
> IPv4 *   $crowdsec_blacklists   *   *   *   *   *   *   CrowdSec (IPv4)   
> IPv6 *   $crowdsec6_blacklists   *   *   *   *   *   *   CrowdSec (IPv6)

Acesse o menu Firewall > Diagnostics > Aliases.
Selecione o Alias crowdsec_blacklists e confirme que há diversos IPs dentro deste alias.

Acesse o menu Services > Crowdsec > Overview.

A guia machines vai exibir somente o localhost, que é o serviço agente crowsec instalado no próprio firewall;
A guia Bouncers vai exibir somente o localhost, pois é a API responsável por comunicar com o serviço do firewall e também tomar ações como aplicar bloqueios.
A guia Collections vai exibir de onde os logs estão sendo coletados (firewall, ssh, opnsense, opnsense-gui).
A guia Scenarios vai exibir os "cenários de ataque" no qual o crowdsec tem regras para monitorar, como por exemplo um ataque ssh "slow".
A guia Parsers vai exibir as regras para ler os logs e interpretar as mensagens afim de observar algum evento interessante.
A guia Postoverflows vai exibir as regras de whitelist tardias (depois que um IP "encheu o balde", ou, quando um IP foi detectado fazendo gracinha, ainda dá tempo de fazer whitelist dele dado algum critério, como IP de origem ou mesmo País de origem).
As guias Alertas e Decisões são auto-explicativas.

Por enquanto você só irá usar as guias Alertas e Decisões, pois será onde os alertas e bloqueios irão aparecer.


TESTANDO O BLOQUEIO DO CROWDSEC

Acesse o firewall via ssh, e bloqueia seu próprio IP por alguns instantes, ou outro se preferir.
* Você irá perder o acesso por 1 minuto ao firewall. Tente atualizar a página ou acessar via ssh durante estes 1 minutos, e após.

Code Select Expand


cscli decisions add --type ban --ip $REMOTEHOST --reason teste-luciano  --duration 1m


Caso perca o acesso momentâneo, o bloqueio entrou em vigor, e você está pronto para começar a brincadeira.


COMO FUNCIONA O CROWDSEC (INTERNAMENTE)

O crowsec parece mágica - e assim resumimos a tecnologia que ainda não dominamos. Mas veja bem, é simples (não confundir com fácil):
Logfile --> CrowSec Agent --> Parser --> Enriquecimento --> Deteção --> Alerta --> Bloqueio?
     1                    2                        3            4                      5                6                    7

Um dos serviços fica responsável por ler arquivos de logs, e a esta origem de dados (arquivo de log) chamados de Datasource. Logo então que este log entra, ele é tratado, e com este termo, quero dizer que esta informação (uma linha por vez) é quebrada em pequenas informações semânticas que fazem algum sentido. Veja por exemplo a linha abaixo:

Code Select Expand


2024-11-08 23:22T0300 pf[101]: user="ludarkstar99" action="reject-auth" message="user ludarkstar99 has denied access to this terminal. session expired"


A máquina irá interpretar uma linha completa. Mas você lendo, rapidamente vai dar foco em algumas informações, como por exemplo o usuário "ludarkstar99", ou a ação que foi rejeitar uma tentativa de autenticação e também vai saber que existe uma mensagem explanatório do motivo desta ação. Mas essa interpretação é sua como serumaninho. A máquina inicialmente vai ler tudo como uma linha cheia de caracteres. Graças ao bom CrowdSec, temos algumas inteligências de ler os campos de alguns logs por padrão. E graças a outros esquisitinhos da internet, você tem uma grande quantidade de "inteligências" para interpretar os logs disponíveis no GitHub.

Depois do log ter sido quebrado em pedacinhos que podem ser indexados e testados individualmente, a próxima etapa é enriquecer esta informação, e o exemplo mais simples que tenho, é adicionar o nome do país do IP de origem do acesso, como um campo adicional (metadado).

Depois de ter sido enriquecido (como urânio), o log passa pelo professor Xavier - quero dizer, pelo motor de cenários, que vai avaliar a toda a informação do evento enriquecido com contexto e vai bater o martelo se é malicioso ou não, se atingiu um comportamento muito exagerado (ou não). só então que é gerado um alerta sobre o evento detectado e então o endereço IP (ou range) é bloqueado.

Para que um IP seja bloqueado, existe na configuração o tempo padrão dos banimentos, que são 4 horas.


OBSERVAÇÕES IMPORTANTES

- O crowdsec por si só faz bastante coisa, mas não cobre 100% de seu ambiente.
- Se estiver usando nginx como proxy reverso, provavelmente vai querer instalar a detecções de nginx e naxsi

Code Select Expand


cscli collections install crowdsecurity/naxsi
cscli collections install crowdsecurity/base-http-scenarios


- Reinicie o serviço do crowdsec para aplicar as alterações.


COMO EU..?

Testo o que seria pego em um determinado log?
cscli explain --file /var/log/audit/latest.log --type syslog

Exploro a configuração do crowdsec?
*ver conteúdo da pasta /usr/local/etc/crowdsec, em especial
> acquis.d/
> parsers/
> profile.conf
> notifications/*
> scenarios/

Ver o log pelo terminal?
tail -f /var/log/crowdsec/*.log

Listar todos os IPs que já foram bloqueados?
cscli decisions list -a

Remover do Bloqueio um Determinado IP
cscli decisions remove --ip 106.75.67.32

Como adiciono um IP Interno/Externo como whitelist?
As exceções podem ser criadas em 2 momentos, 1o enquanto o log é enriquecido (etapa s02-enrich), 2o na etapa de postoverflow (nos últimos dos 45).
Mas aqui vou abordar apenas como realizar a whitelist dizendo qual ip/rede de origem jamais deve ser bloqueada. Como isso será feito na etapa 02-enrich, iremos criar o arquivo /usr/local/etc/crowdsec/parsers/s02-enrich/luciano-whitelist.yaml com o seguinte conteúdo:

Code Select Expand


name: darkstar/luciano
description: "nao bloqueia poh"
whitelist:
  reason: "home office tiolulu"
  cidr:
    - "200.200.200.0/24"
    - "189.89.21.0/21"
    - "10.0.10.0/24"


Como testar se minha whitelist está funcionando?
Substitua o IP que é a primeira informação do log abaixo e execute o comando inteiro no ssh.

Code Select Expand


echo '10.0.10.65 - - [09/Nov/2024:02:17:32 -0300] "GET /test/luciano HTTP/2.0" 404 92 "-" "Go-http-client/1.1" "177.70.23.45"' | cscli explain --type nginx -f-


deverá produzir a seguinte saída, denotando que o IP foi ignorado com sucesso.
line: 10.0.10.65 - - [09/Nov/2024:02:17:32 -0300] "GET /test/luciano HTTP/2.0" 404 92 "-" "Go-http-client/1.1" "177.70.23.45"
        ├ s00-raw
        |       ├ 🔴 crowdsecurity/syslog-logs
        |       └ 🟢 crowdsecurity/non-syslog (+5 ~8)
        ├ s01-parse
        |       ├ 🔴 crowdsecurity/luciano-teste
        |       └ 🟢 crowdsecurity/nginx-logs (+22 ~2)
        ├ s02-enrich
        |       ├ 🟢 crowdsecurity/dateparse-enrich (+2 ~2)
        |       ├ 🔴 crowdsecurity/geoip-enrich
        |       ├ 🟢 crowdsecurity/http-logs (+7)
        |       ├ 🔴 crowdsecurity/luciano-enrich
        |       ├ 🟢 darkstar/luciano (~2 [whitelisted])
        |       └ 🔴 crowdsecurity/naxsi-logs
        └-------- parser success, ignored by whitelist (home office tiolulu) 🟢

ignored by whitelist 0/ - conseguimos com sucesso aplicar a whitelist


Leituras obrigatórias:
- https://docs.crowdsec.net/docs/next/concepts
- https://docs.crowdsec.net/docs/next/data_sources/file
- https://docs.crowdsec.net/docs/next/parsers/create/
- https://docs.crowdsec.net/docs/next/scenarios/create/
- https://docs.crowdsec.net/u/getting_started/post_installation/whitelists/
- https://app.crowdsec.net/hub/author/crowdsecurity/configurations/whitelists
- https://docs.crowdsec.net/docs/next/whitelist/intro/
- https://docs.crowdsec.net/docs/cscli/cscli_collections_install/
- https://app.crowdsec.net/hub/author/crowdsecurity/collections/base-http-scenarios


That's all folks.

[DESCRIÇÃO DOS COMANDOS]

======================================================
===              OPNSENSE - SOBREVIVENDO NA LINHA DE COMANDOS                 ===
======        1 Temporada: EP II - Por trás dos bastidores (configctl)          ======
======================================================
Responsável: ludarkstar99
Data: 07/11/2024
Versão: 1.0
======================================================


DESCRIÇÃO DOS COMANDOS

configctl - utilitário para interagir com o backend (configd - aquele que você não vê, mas sabe que age de formas sobrenaturais), como solicitar a execução de ações em serviços como: reiniciar um serviço, reiniciar um túnel vpn, listar os túneis vpn conectados, invocar a função de atualização de listas de bloqueio (unbound), ou mesmo remover uma lease do serviço dhcp.

# Acessar o manual do configctl
$ configctl configd actions

# Listar as ações disponíveis
$ configctl configd actions

# Listar a tabela arp (e mostrar a saída formatada. Se tiver as manha no jq, pode usá-lo para filtrar a saída)
$ configctl dhcpd list arp | json_pp

# Recarregar todos os serviços (útil para quando edita manualmente o arquivo de configuração)
$ configctl service reload all

# Recarregar a webgui
$ configctl webgui restart

# Listar os túneis OpenVPN
$ configctl openvpn connections server | json_pp

# Reiniciar uma conexão OpenVPN (este número doidão é o id da vpn obtido pelo comando acima)
$ configctl openvpn restart 643d6cee-7900-4026-a4ab-c7e17a266838

# Listar todos os serviços
$ configctl service list | grep -iE 'name'

# Reiniciar o serviço do unbound
$ configctl service restart unbound

# Dump do cache do unbound
$ configctl unbound dumpcache

# Visualizar a lista de templates disponíveis
$ configctl template list

# Gerar novamente o arquivo final de configuração do Captive Portal
$ configctl template reload OPNsense/Captiveportal


DETALHES

E onde ficam as definições destas ações/comandos?
A definições ficam dentro de cada arquivo na pasta /usr/local/opnsense/service/conf/actions.d/
Vamos tomar como exemplo o arquivo actions_crowdsec.conf dentro da pasta acima. 

Code Select Expand


[status]
command:/usr/local/etc/rc.d/oscrowdsec status; exit 0
type: script_output
message: oscrowdsec status
[...]


A ação "status" (configctl crowdsec status) invoca por debaixo dos panos o comando "/usr/local/etc/rc.d/oscrowdsec status".
Se parar para analisar o arquivo, não tem nada de complicado nele. Para criar sua própria ação, basta copiar um existente e modificar de acordo com seu comando.


CRIANDO UMA AÇÃO PERSONALIZADA
que pode ser usada no cron, agendado na própria webgui

1. criar o arquivo /usr/local/opnsense/service/conf/actions.d/actions_darkstar.conf com o seguinte conteúdo:

Code Select Expand


[update]
command:sh -c 'curl ifconfig.me > /tmp/updated_address'
parameters:
type:script_output
message:Atualiza o ip externo do firewall no ddns
description:Realiza um teste de IP externo do firewall


2. Reiniciar o serviço do backend para ler nosso arquivo de ação fresquinho.
$ service configd restart

3. Acessar o cron: menu System > Settings > Cron.
4. Criar uma nova tarefa que vai executar a cada minuto (todos os campos do agendamento com *). No campo Command, selecione a tarefa "Atualiza o ip externo do firewall no ddns".
5. Após aplicar a tarefa, aguarde 1 ou 2 minutos.
6. Verifique se foi criado o arquivo /tmp/updated_address.
7. Pronto. Você agora já sabe como agendar comandos periódicos no firewall, de forma externa. Melhor que isso só colocando uma notificação que seu comando foi executado, ou gerar um registro nos logs.
8. Por quê não criar um script que testa o túnel principal da vpn site2site, e caso esteja off, ativa o segundo e desativa o primeiro?


CENAS PÓS CRÉDITOS

Para os universitários de plantão, o daemon do configd mostra uma receita de bolo de como executar um serviço em python (modules/daemonize).

# Inspecionar na integra o conteúdo do daemon configd
$ less /usr/local/opnsense/service/configd.py

[0. DESCRIÇÃO]

================================================================
===                                      OPNSENSE - INSTALAÇÃO NTOPNG                                              ===             
================================================================
Responsável: ludarkstar99
Data: 21/04/2024
Versão: 1.0
================================================================


0. DESCRIÇÃO

Este procedimento tem por objetivo guiar a instalação e configuração do NtopNG no firewall OPNsense.


1. INSTALAÇÃO

1.1. Realizar a instalação dos plugins Redis e NtopNG.
1.2. Opcionalmente, pode ser instalado pela linha de comandos:
     pkg install -y os-ntopng os-redis

1.3. Registrar para uma licença maxmind geolite db (banco de dados de geolocalização)
1.3.1. Acessar o site: https://www.maxmind.com/en/geolite2/signup
1.3.2. Preencher o formulário
1.3.3. Confirmar conta pelo e-mail
1.3.4. Gerar nova Licence key em: https://www.maxmind.com/en/accounts/current/license-key/

1.4. Configurar o redis no OPNsense.
1.4.1. Acesse o menu Services > Redis.
1.4.2. Marque a opção enable e clique em Apply.

1.5. Configurar a licença maxmind:
1.5.1. Acessar o firewall via SSH.
1.5.2. Criar o arquivo /usr/local/etc/GeoIP.conf com o seguinte conteúdo:

Code Select Expand


AccountID xxxxxx
LicenseKey xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country


Obs.: Localize no site do Maxmind sua *AccountID.

1.5.3. Realizar o download do geolite db com o comando: ntopng-geoip2update.sh

1.6. Configurar o NtopNG no OPNsense.
1.6.1. Acesse o menu Services > NTOPNG.
1.6.2. Marque a opção Enable e clique em Apply.

1.7.2. Verifique se o serviço inicializou (vai demorar um pouco na 1a inicialização).
1.7.3. caso o serviço não inicie, ver o log
       tail -f /var/log/system/latest.log

1.8. Acessar no navegador http://ip-do-firewall:3000/
*caso não consiga acessar o firewall externamente, fazer tunel ssh para acessar no localhost.
*configura também no live view do firewall (logs) se não está sendo bloqueado o acesso.

[DESCRIÇÃO]

======================================================
===         OPNSENSE - SOBREVIVENDO NA LINHA DE COMANDOS        ===
======                        1 Temporada: EP I - O início (pfctl)                          ======
======================================================
Responsável: ludarkstar99
Data: 05/11/2024
Versão: 1.1
Contribuição: juliocbc
======================================================


DESCRIÇÃO
Muitas vezes quando estamos lidando com troubleshoot, precisamos ir além das ferramentas gráficas que o sistema fornece (WebGui) para encontrar a causa e também resolver determinados problemas. Neste singelo guia, compartilho as ferramentas que uso no dia-a-dia e que me ajudam a resolver determinados problemas ou mesmo investigá-los.


DESCRIÇÃO DOS COMANDOS

pfctl - utilitário para interagir com o filtro de pacotes, seja para listar regras, nat e também states (conexões abertas).
Falando sobre regras, não é possível criá-las como se usava no "iptables", no pfctl você precisa primeiro criar um arquivo com a lista completa de regras para serem carregadas na memória e então imputar este arquivo no pfctl. Isso serve tanto para regras de acesso quanto para regras de nat (aqui chamamos de rdr).

COMANDOS ÚTEIS DO PFCTL

# Exibir a documentação do pfctl
$ man pfctl

# exibir a lista de regras da memória
$ pfctl -sr

# exibir a lista de nat (rdr)
$ pfctl -sn

# exibir a lista de states (conexões abertas)
$ pfctl -vv -ss

# Limpar todas as conexões abertas
$ pfctl -F states

# Limpar as conexões iniciadas pelo host 192.168.1.2
$ pfctl -k 192.168.1.2

# Limpar as conexões destinadas ao host 8.8.8.8
$ pfctl -k 0.0.0.0/0 -k 8.8.8.8

# Testar se há algum erro no conjunto de regras automaticamente geradas
$ pfctl -n -f /tmp/rules.debug

# Recarregar novamente as regras na memória
$ pfctl -f /tmp/rules.debug

# Listar quais IPs estão em um alias (ex.: alias de auto-bloqueio do nginx para bots)
$ pfctl -t nginx_autoblock -T show

# Exibir tudo (regras + nat + states + tables + outras informações)
$ pfctl -sa


Thats all, folks.

[DESCRIÇÃO]

======================================================
===              OPNSENSE - CONFIGURAR INSTÂNCIA NA ORACLE OCI                  ===
======================================================
Responsável: ludarkstar99
Data: 22/09/2024
Versão: 1.0
======================================================


DESCRIÇÃO

Este projeto visa documentar o processo de executar um firewall personalizado na nuvem OCI, de forma a permitir que este firewall seja o centralizador dos acessos, entre diferentes VCNs e também atue como firewall de borda / DMZ.


JUSTIFICATIVA

A atual demanda surgiu da necessidade de atender a um novo cliente, cuja necessidade eminente seria substituir um firewall (grande marca aqui) atualmente sendo usado na nuvem OCI para publicar acessos NAT e VPN, em favor de um firewall OPNsense que fornecesse nível adequado de proteção de suas aplicações.


RESUMO

Devido a muitos desafios para concluir este projeto com sucesso, optamos por documentar como realizá-lo novamente, pois acreditamos que cada vez mais empresas vão adotar a nuvem como solução definitiva de infraestrutura, tanto por performance quanto por segurança para rodar suas cargas de trabalho, seja executando totalmente em nuvem pública ou no formato híbrido.

O projeto consistiu basicamente das seguintes etapas:

1. Criar uma subrede tipo pública chamada "DMZ" que conterá a instância de computação do firewall;
2. Criar um novo bucket ou usar um existente para upload de imagens personalizadas;
3. Fazer o download do arquivo do opnsense (nano), extrair e fazer upload para o bucket acima ([link](https://mirror.ams1.nl.leaseweb.net/opnsense/releases/24.7/OPNsense-24.7-nano-amd64.img.bz2))
4. Registrar uma imagem personalizada na OCI, sendo importada a partir do bucket acima
5. Realizar a reserva de um endereço IP público
6. Provisionar uma instância de computação com a imagem personalizada do firewall OPNsense
7. Atribuir o Firewall na subrede pública (DMZ) durante a criação da instância, atribuindo a ele o IP Público (reservado ou não)
8. Atribuir o firewall na(s) subrede(s) privada(s), para que tenha acesso às cargas de trabalho internas (não é obrigatório inserir uma interface de rede do firewall em cada subnet, você pode ter somente 1 LAN no firewall e apontar todas as tabelas de roteamento internas para esta interface de rede do firewall. Usar uma interface para cada subrede assimila melhor uma rede local tradicional e facilita o entendimento - seu e de seu cliente ;D)
9. Acessar a instância do firewall via Console OCI para realizar os ajustes iniciais e atribuições de placas de rede
10. Usar no firewall preferencialmente o último endereço IP disponível na subrede (geralmente xx.xx.xx.254)
11a. Desabilitar manualmente no firewall (editar /config/config.xml) as opções nodnsrebindcheck e nohttpreferercheck para que consiga acesso a webgui via internet, da seguinte maneira:

Code Select Expand

<nodnsrebindcheck>1</nodnsrebindcheck>
<nohttpreferercheck>1</nohttpreferercheck>
11b. Reiniciar o firewall para aplicar a alteração, e acessá-lo pelo IP público.
11c. Certifique-se de ter liberado na SecurityList o acesso à porta 80/443 o firewall inicialmente.
12. Cada subrede deve ter sua própria tabela de roteamento, apontando a rota 0.0.0.0/0 para o IP privado do firewall naquela subnet
13. Configurar as policies/regras de acesso no próprio firewall
14. Configurar na instância do firewall (OCI) a isenção de verificação de origem/destino nas placas de rede (necessário para que a instância faça NAT)
15. Configurar regras stateless na SecurityList, passando tudo para o firewall quando externo → firewall ou interno → firewall
16. Criar no OPNsense os gateways para as redes internas (privadas/publicas) apontando para o gateway interno da própria OCI (geralmente o IP xx.xx.xx.001 de cada subnet).


OBSERVAÇÕES

- O endereço IP xx.xx.xx.001 sempre será usado para o gateway interno de cada subnet da OCI.
- Ex.: A instância interna Linux, aponta seu gateway para o ip xx.xx.xx.001, e este gateway usa o xx.xx.xx.254 (ip do firewall) como seu gateway, conforme definido na tabela de roteamento específica da subnet.
- O upload P/ a OCI não é lá grandes coisas. Mesmo sem o firewall fica entre 1~5 Mbps. Não se engane, o OPNsense não é o culpado do troughput baixo, e sim a Oracle.
- VPN Wireguard é mais estável site-a-site, se usada com roteamento dinâmico é melhor ainda para seu uptime.


INDICAÇÕES

- Habilitar GeoIP e fazer liberações somente para países dos quais se fazem negócios. Ex.: liberar NAT com origem apenas Brasil.
- Habilitar a proteção do Crowdsec
- Habilitar PING na WAN (ou não)
- Habilitar logs nas regras internas → internet ou internas → outras internas


LINKS ÚTEIS

- OCI Networking - https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/landing.htm
- OCI VCN e Subnets - https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/VCNs.htm
- OCI Virtual Network Interface Cards - https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/managingVNICs.htm
- OCI VCN Route Tables - https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/managingroutetables.htm#Overview_of_Routing_for_Your_VCN


That's all folks.

Olá Julio.
Não ficou claro se devo continuar criando novos tópicos e apenas colar o link no tópico fixo que criou,
ou se devo criar os howtos como mensagens do tópico fixo que criou.

[RESUMO]

================================================================
===                      OPNSENSE - GUIA GERAL PARA OTIMIZAÇÃO DO FIREWALL                           ===
===                                                        ~ TUNNING                                                              ===
================================================================
Responsável: ludarkstar99
Data: 04/11/2024
Versão: 1.0
================================================================


RESUMO
Este procedimento tem por objetivo habilitar/desabilitar funções no firewall OPNsense para otimizar a performance do processamento de forma geral.


DISCLAIMER
Use por sua própria conta em risco. O que funciona para mim, pode não refletir o seu cenário e o que irá funcionar para você.


ETAPAS

1. Desabilitar Mitigação Spectre e Meltdown
Acessar o menu: System > Settings > Tunables
    Alterar o valor (ou criar caso não exista): vm.pmap.pti para 0
    Alterar o valor (ou criar caso não exista): hw.ibrs_disable para 1


2. Onde não se usa o IDS/IPS, Habilitar o CRC e TSO, mas verificar a performance com IPERF3 para atestar que houve ganho real:
Acessar o menu: Interfaces > Settings
    desmarcar: Disable hardware checksum offload
    desmarcar: Disable hardware TCP segmentation offload


3.Habilitar o processamento de múltiplas filas na placa de rede INTEL (driver igb):
Acessar o menu: System > Settings > Tunables
    Criar o tunable hw.igb.rx_process_limit com valor -1
    Criar o tunable hw.igb.tx_process_limit com valor -1
    Criar o tunable legal.intel_igb.license_ack com valor 1


4. Por padrão o FreeBSD trabalha com uma única thread para interrupções de rede. O tunable abaixo permite 1 threat por núcleo:
Acessar o menu: System > Settings > Tunables
    Criar o tunable net.isr.maxthreads com valor -1


5. E o tunable abaixo força que cada thread seja atribuída em núcleos diferentes:
Acessar o menu: System > Settings > Tunables
    Criar o tunable net.isr.bindthreads com valor 1


6. O tunable abaixo otimiza de forma geral as interrupções de rede:
Acessar o menu: System > Settings > Tunables
    Criar o tunable net.isr.dispatch com valor deferred


7. Habilitando o RSS (receive side scaling) otimiza a performance para sistemas multi-cores:
Acessar o menu: System > Settings > Tunables
    Criar o tunable net.inet.rss.enabled com valor 1


8. Otimização de RSS de acordo com a qtde de cpus:
Acessar o menu: System > Settings > Tunables
    Criar o tunable net.inet.rss.bits com valor (qtde de núcleos / 4)



ANOTAÇÕES
Reinicie o firewall a cada alteração para aplicar imediatamente a função desejada.



REFERENCIAS:


https://notes.xeome.dev/notes/OPNSense-Tuning
https://teklager.se/en/knowledge-base/opnsense-performance-optimization/
https://medium.com/@truvis.thornton/opnsense-firewall-configuration-performance-tuning-for-multi-gigabit-internet-and-better-speeds-in-cfc80c49c544
https://calomel.org/network_performance.html
https://calomel.org/freebsd_network_tuning.html
https://binaryimpulse.com/2022/11/opnsense-performance-tuning-for-multi-gigabit-internet/


*Lembre-se, redes de computadores está mais para engenharia quanto um palhaço está para o circo.
That's all folks.

[SINTOMA:]

Olá você!

Este é um fix para quando o cliente VPN - OpenVPN Connect (aquele mais ˆbonitinhoˇ) apesar de enviar o IP de servidor dns para o cliente, este não consegue resolver nomes internos simples, como "intranet", "portalbi" ou mesmo "dashboards".

A recomendação é que se use nos clientes a versão Community do OpenVPN com o servidor OpenVPN usado no OPNsense. Entretanto, algumas pessoas usam a versão "Connect" do agente e se frustram com o problema acima descrito.


SINTOMA:
- É possível resolver nomes FQDN (intranet.empresa.local) mas não "intranet" somente.


RESOLUÇÃO SIMPLES:
- A mais óbvia: Remova o OpenVPN Connect do cliente e instale a versão community. Caso este caminho não seja viável (sabe-se lá Deus porque...), siga as etapas abaixo:


RESOLUÇÃO AVANÇADA:
- Se estiver usando o servidor OpenVPN no OPNsense como "Instance", altere para Servers [legacy] usando os mesmos parâmetros de conexão - desculpe, não tem um botão único que resolva o problema... Use o wizard para facilitar a vida.
- Certifique-se de que habilitou o DNS e preencheu o IP do servidor DNS (preferencialmente o próprio firewall ou servidor active directory na rede, caso aplicável).
- Nas opções avançadas, aquela caixinha de texto livre, preencha com o texto abaixo, substituindo o nome do domínio conforme seu cenário:

Code Select Expand


push "dhcp-option DOMAIN-SEARCH citrait.local"
push "dhcp-option ADAPTER_DOMAIN_SUFFIX citrait.local"


Conecte novamente pelo cliente, e tente resolver nomes internos (registrados no dns) sem a parte do domínio.


That's all folks.

======================================================
===              OPNSENSE - CONFIGURAR WIREGUARD SITE A SITE                      ===
======================================================
Responsável: ludarkstar99
Data: 02/11/2024
Versão: 1.0
======================================================



=== OBSERVAÇÃO
- Este procedimento guia a configuração de comunicação site-a-site (geralmente matriz <--> filial) usando VPN do tipo Wireguard.
- Este howto não cobre um ambiente de alta disponibilidade. Caso almeja este cenário, use o modo "roteado" do wireguard, fechando mais de um túnel por links diferentes e usando o bgp ou ospf para puxar as rotas dinamicamente.


=== PRÉ-REQUISITOS
a)_ Ao menos 1 dos lados (o lado servidor da VPN) deve ter um IP público, não necessariamente fixo, e com possibilidade de abertura de portas.
b)_ Na dúvida, consulte seu provedor se seu link permite a abertura de portas.
c)_ Caso esteja usando modem roteado, certificar de encaminhar a porta (ou dmz) para o IP de seu firewall na interface WAN.
d)_ Não deve haver redes iguais nas duas pontas, ou seja, a rede interna da matriz (ex.: 192.168.xx.xx/24) não pode ser igual a rede interna da filial (ex.: 192.168.xx.xx/24).


=== ETAPAS NA MATRIZ (Lado servidor da conexão, onde há o IP público)
1. Criado a regra de firewall para permitir conexão com o serviço de VPN
1.1. Acesse o menu Firewall > Rules > Wan
1.2. Crie uma regra de firewall da seguinte forma:
  Actin: Pass
  Protocol: UDP
  Source: Any
  Destination: Wan Address
  Port: (Other) 51820
  Log: *marcar
  Descrição: Libera wireguard
1.3. Salvar a regra e aplicar a configuração (botão laranja apply que aparece ao topo após salvar a regra).


2. Criar o túnel (instância) VPN na matriz
2.1. Acesse o menu VPN > Wireguard > Instances
2.2. Marcar a caixa "Enable Wireguard" e clicar em Apply
2.3. Clicar em adicionar (+) uma nova instância e preencher os seguintes dados:
  Name: Tunnel_Filial
  Public key: *clicar na engrenagem para gerar automaticamente
  Listen port: 51820
  Tunnel Address: 10.9.0.1/24
2.4. Clicar em Save e depois que fechar o dialogo modal, clicar em Apply novamente.


3. Criar o túnel (instância) VPN na filial
3.1. Acesse o menu VPN > Wireguard > Instances
3.2. Marcar a caixa "Enable Wireguard" e clicar em Apply
3.3. Clicar em adicionar (+) uma nova instância e preencher os seguintes dados:
  Name: Tunnel_Matriz
  Public key: *clicar na engrenagem para gerar automaticamente
  Tunnel Address: 10.9.0.2/32
  Clicar em Save e depois que fechar o dialogo modal, clicar em Apply novamente.


4. Registrar o peer da Matriz na Filial
4.1. Ainda na filial, acesse a guia Peers do wireguard.
4.2. Clique em adicionar um novo peer (+)
4.3. Preencha o formulário como se segue:
  Name: Matriz
  Public Key: **Volte na matriz, clique para editar a instância, copie o campo Public key. Voltei no firewall da filial e cole a Public Key copiada.
  Allowed IPs: Preencha com a rede do túnel, além das subredes da matriz na qual a filial terá acesso. ex.: 10.9.0.0/24 (túnel), 10.0.10.0/24 (lan matriz).
  Endpoint Address: *IP ou DNS Dinâmico ou nome fqdn que aponte para o IP público do firewall da matriz.
  Endpoint port: 51820 *conforme cadastramos na instância da matriz
  Instances: Selecione a instância Tunnel_Matriz
  Keep live: 25
4.4. Clicar em Save e depois em Apply


5. Liberar a entrada de tráfego da Matriz acessando a Filial
5.1. Ainda na filial, atualize a página (F5) e acesse o menu Firewall > Rules > Wireguard (Group)
5.2. Crie uma nova regra de firewall liberando todo o tráfego de entrada (inicialmente, depois você fecha como quiser)
  Action: Pass
  Potocol: Any
  Destination: Any
  Log: *Marcar
  Descrição: Libera tráfego vindo da matriz pela VPN
5.3. Clique em Save depois em apply changes para aplicar a regra


6. Registrar o peer da Filial na Matriz
6.1. Volte na Matriz, acesse a guia Peers do wireguard.
6.2. Clique em adicionar um novo peer (+)
6.3. Preencha o formulário como se segue:
  Name: Filial
  Public Key: **Volte na filial, clique para editar a instância, copie o campo Public key. Voltei no firewall da matriz e cole a Public Key copiada.
  Allowed IPs: Preencha com o endereço IP de túnel da Filial, 10.9.0.2/32 e também com as subredes da filial na qual a matriz terá acesso. ex.: 172.16.0.0/24.
  Instances: Selecione a instância Tunnel_Filial
  Keep live: 25
6.4. Clicar em Save e depois em Apply



7. Liberar a entrada de tráfego da Filial acessando a Matriz
7.1. Ainda na matriz, atualize a página (F5) e acesse o menu Firewall > Rules > Wireguard (Group)
7.2. Crie uma nova regra de firewall liberando todo o tráfego de entrada (inicialmente, depois você fecha como quiser)
  Action: Pass
  Potocol: Any
  Destination: Any
  Log: *Marcar
  Descrição: Libera tráfego vindo da filial pela VPN
7.3. Clique em Save depois em apply changes para aplicar a regra



8. Liberar a Passagem de Tráfego da LAN Matriz para LAN Filial sem forçar gateway
8.1. Ainda na matriz, acesse o menu Firewall > Rules > LAN
8.2. Crie uma nova regra de firewall liberando o tráfego da rede local LAN para a rede local (LAN) da filial
  Action: Pass
  Potocol: Any
  Source: Lan Net
  Destination: *Single Host or network. Preencher com a rede lan da filial ex.: 172.16.0.0/24
  Log: *Marcar
  Descrição: Libera Lan Local para Lan Filial
8.3. Clique em Save para salvar a regra
8.4. Suba com a regra recem criada para acima das regras com gateway.
8.5. Clique em apply changes para aplicar a regra. É importante que esta regra tenha prioridade (esteja acima) das outras, pois caso haja alguma outra regra que corresponda o tráfego e tenha gateway definido (load-balance ou failover) irá forçar a saída da conexão pela interface de rede que não o túnel VPN.


9. Liberar a Passagem de Tráfego da LAN Filial para LAN Matriz sem forçar gateway
9.1. Agora na Filial, acesse o menu Firewall > Rules > LAN
9.2. Crie uma nova regra de firewall liberando o tráfego da rede local LAN para a rede local (LAN) da Matriz
  Action: Pass
  Potocol: Any
  Source: Lan Net
  Destination: *Single Host or network. Preencher com a rede lan da matriz ex.: 10.0.10.0/24
  Log: *Marcar
  Descrição: Libera Lan Local para Lan Matriz
9.3. Clique em Save para salvar a regra
9.4. Suba com a regra recem criada para acima das regras com gateway.
9.5. Clique em apply changes para aplicar a regra. É importante que esta regra tenha prioridade (esteja acima) das outras, pois caso haja alguma outra regra que corresponda o tráfego e tenha gateway definido (load-balance ou failover) irá forçar a saída da conexão pela interface de rede que não o túnel VPN.



That's all folks.
Remember: Open source is Free as in Speech, not as in beer.

=============================================
===              OPNSENSE - CONFIGURAR BRIDGE PARA LAN           ===
=============================================
Responsável: ludarktar99
Data: 03/06/2024
Versão: 1.0
=============================================



=== OBSERVAÇÃO
Este procedimento foi criado para o cenário em que varias placas de redes são unidas para formar uma bridge (ponte), de forma que máquinas na rede A (192.168.0.0/24) conectadas na interface LAN-1 do firewall, possam   se comunicar com outras máquinas na mesma faixa de rede, mas conectadas em outra placa rede do firewall LAN-2. Assim, todo os pacotes de rede que o firewall receber na interface LAN-1 serão encaminhados para a interface LAN-2, e vice-versa - a bridge atua como um SWITCH SIMPLES / HUB.

Além disso, o procedimento abaixo vai fazer com que todo o controle de tráfego seja feito via regras atribuídas na interface BRIDGE (grupo), ao invés de ter que criar regras em cada interface membro da bridge em questão.


=== PRÉ-REQUISITOS
a)_ Acesso de administrador ao firewall OPNsense
b)_ Placa de rede adicional para não perder a comunicação durante o processo.
    O ideal é que se conecte via interface WAN ou OPTx que não irão fazer parte da bridge.
c)_ Disponibilidade para reiniciar o firewall para que as alterações entrem em vigor.
d)_ Mapeado as portas de rede do firewall no switch. Cuidado para não criar loop na rede.


=== ETAPAS
1. Criar a bridge através do menu Interfaces > Other Types > Bridge > Add (+) .
2. Na lista de interfaces membro, selecione todas as interfaces que participarão nesta bridge. Obs.: Clicar na opção "Show advanced options" e habilitar o RSTP para prevenir loop na rede.
3. Registre a bridge como uma interafce através do menu Interfaces > Assignments.
4. Acesse a interface registrada para a bridge, habilite-a, mas não atribua endereço IP.
5. Pelo menu Interfaces > Assignments, altere a associação da placa atual da LAN para a bridge.
6. Registrar a placa que era a lan anteriormente (vai estar desassociada).
7. Edite a interface bridge (interfaces > other types > bridge) e selecione também a placa da antiga LAN (agora disponível e sem uso) no grupo.
8. Reiniciar o serviço de dhcp (parar e iniciar ao invés de só apertar restart).
9. Editar os tunables e definir (menu system > settings > tunables):
  net.link.bridge.pfil_bridge = 1 (para liberar/bloquear pelas regras direto na interface bridge)
  net.link.bridge.pfil_member = 0 (para não filtrar o tráfego por cada interface separada, já que estamos aplicando as regras direto na bridge)
10. Reiniciar o firewall !!!
11. Verifique o funcionamento da bridge, testando a comunicação de uma maquina vinda de uma placa de rede
   com outra em outra placa de rede do firewall (mas dentro da mesma bridge). Ambas devem estar no mesmo range de rede ex.: 192.168.0.0/24.
12. Verifique se na interface que esta associada a placa bridge (LAN), se possui as regras de firewall adequadas (Firewall > Rules > LAN).
   Caso necessário use a captura de pacotes ou os logs (Live View) para validar a entrada/saída de pacotes.
   Lembre-se que o firewall do Windows pode bloquear as conexões de ping.
 



That's all folks.

[1. CONFIGURAÇÃO INICIAL DO MONIT]

Olá pessoal,
Estou compartilhando um guia para a configuração do MONIT alertar eventos importantes do próprio Firewall.
Este tutorial é útil para quem ainda não usa uma solução externa como o Zabbix para monitoramento.

=========================================================
=== OPNSENSE - CONFIGURAR MONIT EVENTOS IMPORTANTES                                ===
=========================================================
Responsável: ludarkstar99
Data: 01/11/2024
Validado para: OPNsense 24.7
Versão: 1.3 - removidos alertas que não funcionam mais (login webgui+ssh)
Versão: 1.2 - adição dos alertas de crowdsec e vpn
Versão: 1.1 - adição dos alertas de gateway offline
Versão: 1.0 - inicial, alertas de acesso ao firewall
=========================================================


PROCEDIMENTO: CONFIGURAR O MONIT NO OPNSENSE


1. CONFIGURAÇÃO INICIAL DO MONIT
1.1. Habilitar o Monit
Acessar o menu Services > Monit.
Marcar a opção Enable Monit.
Preencher o mail server, port, username, password e ssl connection de acordo com o seu provedor SMTP.
Clicar em Save

1.2. Definir o destinatário dos e-mails
Acessar a guia Alert Settings
Clonar o alerta padrão que vem desabilitado
Marcar Enable Alert
Preencher o campo Recipient com o e-mail de quem vai receber o alerta
No campo Mail Format, copiar e colar o texto abaixo, substituindo o FROM pelo seu e-mail remetente (conta usada para envio):

=== COPIAR ABAIXO DESTA LINHA ===

from: notifica@gmail.com
   subject: $SERVICE $EVENT at $DATE
   message: Descrição: $DESCRIPTION.
Host: $HOST
Serviço: $SERVICE
Ação Realizada: $ACTION

Este é um informe automático.

=== FIM DO TEXTO - NÃO COPIAR ESTA LINHA ===

Preencher a descrição (pode ser o email do destinatário)
clicar em Save
Clicar em Apply


2. CONFIGURAR PARA ALERTAR EM ALTERAÇÃO DE CONFIGURAÇÃO
2.1. Criar o teste Configuracao_Alterada
Acessar a tela Service Tests Settings
Clicar em adicionar um novo Test
Preencher o nome com Configuracao_Alterada
Preencher a condição com: content = "user .* changed configuration"
Selecionar a ação sendo: Alert
Clicar em Save

2.2. Criar o Service Alteracao_Config_Detectada
Acessar a tela Service Settings
Clicar em adicionar um novo Service
Marcar a caixa: Enable Service Checks
Preencher o nome com: Alteracao_Config_Detectada
Preencher o Tipo como: File
Preencher o path como: /var/log/audit/latest.log
Selecionar os testes criados anteriormente: Configuracao_Alterada
Preencher a descrição: Notifica alteração de config no firewall.
Clicar em Save



3. CONFIGURAR PARA ALERTAR NA FALHA DE GATEWAY
3.1. Criar o teste Gateway_Down
Acessar a tela Service Tests Settings
Clicar em adicionar um novo Test
Preencher o nome com Gateway_Down
Preencher a condição com: content = "loss -> down"
Selecionar a ação sendo: Alert
Clicar em Save

3.2. Criar o Service Gateway_Down_Detectado
Acessar a tela Service Settings
Clicar em adicionar um novo Service
Marcar a caixa: Enable Service Checks
Preencher o nome com: Gateway_Down_Detectado
Preencher o Tipo como: File
Preencher o path como: /var/log/gateways/latest.log
Selecionar os testes criados anteriormente: Gateway_Down
Preencher a descrição: Notifica gateway indisponível.
Clicar em Save



4. CONFIGURAR PARA ALERTAR SE VPN CAIR (E REINICIAR TAMBÉM)
4.1. Criar o teste Reinicia_VPN_SE_Falhar_Ping
Acessar a tela Service Tests Settings
Criar um novo Test
Preencher o Name como: Reinicia_VPN_SE_Falhar_Ping
Preencher condição como: failed ping
Selecionar a Ação como: Restart
Clicar em Save

4.2. Criar o Service Conectividade_VPN_Matriz
Acessar a guia Service Settings
Clicar em adicionar um novo Service
Marcar a caixa do campo: Enable service checks
Preencher Name como: Conectividade_VPN_Matriz
Preencher Type como: Remote Host
Preencher Address com o IP que será usado para receber pings na outra ponta da VPN: ex.: 10.0.0.1 (preferencialmente o IP de túnel da vpn do outro lado, ou da lan mesmo...)
Preencher Start: /bin/sh -c '/usr/local/sbin/pluginctl -s openvpn start'
Preencher Stop:  /bin/sh -c '/usr/local/sbin/pluginctl -s openvpn stop'
Selecionar Tests: Reinicia_VPN_SE_Falhar_Ping
Preencher  descrição como: Reinicia VPN se cessar comunicação com matriz.



5. CONFIGURAR PARA ALERTAR QUANDO O CROWDSEC BLOQUEAR IP INTERNO
5.1. Criar o Teste
Acessar a guia: Service Tests Settings
Clicar em adicionar um novo Test
Preencher o nome como: Crowdsec_Baniu_IP_Local
Preencher Condition como: content = 'ban.*(192\.168|10\.|172\.)'
Em Action selecionar Alert
Clicar em Save

5.2. Criar a verificação do teste (service)
Acessar a guia Service Settings
Criar um novo servisse
Marcar Enable service checks
Preencher o Name com Crowdsec_Baniu_IP_Local
Selecionar o Type como: File
Preencher o Path com: /var/log/crowdsec/crowdsec.log
Selecionar Tests: Crowdsec_Baniu_IP_Local
Preencher a descrição com: verifica se o crowdsec bloqueou pc local
Clicar em Save
Clicar em Apply

6. TESTAR
6.1. Testar a notificação do crowdsec
Para testar, acesse o shell e execute como administrador:
cscli decisions add --ip 192.168.100.101 # para banir um ip de lan qualquer
cscli decisions delete --ip 192.168.100.101 # para remover da lista de bloqueio


That's all folks.

EN
sorry about that. the github account was split from personal/business projects.
-----------------------------------------------------------------------------------------
PT
o repositório foi movido devido a divisão de projetos pessoais/da empresa.

https://github.com/sysadminbr/zabbix-templates

Actually, it was moved to
https://github.com/sysadminbr/migrate_pfsense

Was made in a raw attempt to read config.xml from pfsense and submitting it to opnsense forms.
i'm working into a recent version leveraging the proper api methods.

Regarding P1 not receiving any data, after i disconnect the tunnel that's expected behavior: P1 no data, P2 triggers a disconnection.
After reconnecting the tunnel, P1 starts receiving data again, and P2 shows connected (again).

Hi burghy, sorry for the delay.
I could not reproduce the problem, using ipsec instances or "old tunnel config".
In both configuration types i had the correct tunnel data (0 for tunnel connected), and 1 for disconnect.

Attach 1: data received for the item.
Attach 2: item data for fase2 disconnect.
Attach 3: after the tunnel gets offline the triggers screams.