Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - ludarkstar99

Pages: [1] 2

Portuguese - Português / HOWTO - VPN IPsec Usuários/Certificado

« on: November 20, 2024, 10:34:38 pm »

================================================================
=== OPNSENSE - VPN IPSEC USER/CERTIFICATE ===
================================================================
Responsável: ludarkstar99
Data: 20/11/2024
Versão: 1.0
OPNsense: 24.7
================================================================

OPNSENSE - CONFIGURAR IPSEC USUÁRIO->SITE COM AUTENTICAÇÃO VIA CERTIFICADO

RESUMO

Este procedimento foi criado para permitir que você configure uma vpn baseada em IPsec para que o usuário final possa se conectar de maneira segura nos recursos internos da empresa, estando ele fora dela. A este tipo de setup também chamamos de Road-Warrior ("guerreiro na estrada". não sei pq o guerreiro, mas se tiver wi-fi na estrada já tá valendo).

OBSERVAÇÕES

IPsec por si só é uma besta-fera, domá-lo tem me tomado alguns anos de estudo, e quando você acha que sabe de alguma coisa, vem o grandioso lá de cima e te coloca pra trabalhar com uma caixa de firewall diferente com sua própria implementação de IPsec. RFC's são uma chance de você não ficar boiando, mas vai por mim, é mais fácil pular de bote e seguir o fluxo natural do rio, do que tentar nadar de braçada contra ele. Ninguém domina o IPsec, mas você pode orar pra ele, oferecendo alguma coisa em troca e eventualmente ele vai atender ao seu ike proposal. Geralmente antes de fechar algum túnel, eu abaixo a tela do notebook e faço a seguinte oração:

```
Trap Nosso que estais no Kernel,
criptografado seja o vosso Tráfego,
venha a nós o vosso Selector,
seja instalada a vossa política
assim na ike_sa como no child_sa.
O rekey nosso de cada dia nos dai hoje,
perdoai-nos as nossas misconfigs
assim como nós reiniciamos
o túnel que nos tem ofendido,
e não nos deixeis cair em Retransmissão,
mas livrai-nos do Fragmento.
```

PREMISSAS

- Será configurado o IPsec para conexões Mobile (user to site / road warrior / usuário de "rômioffice")
- Apenas foi validado o acesso por cliente windows (11).
- O firewall pode estar atrás de NAT (não confundir com CGNAT) desde que aponte para ele a DMZ e valide com o provedor que é possível "publicar" portas.
- O cliente pode estar atrás de NAT
- A conexão vpn no PC do usuário será do tipo Split-Tunnel, em que apenas o tráfego pré-definido será `roteado` pelo túnel. o restante sai pela internet local mesmo.
- A autenticação do usúario será automática, baseado em certificado - ou seja, não vai pedir login+senha, vai conectar direto.
- Preste atenção no item acima! Se você quer autenticar o usuário a partir do Radius/Ldap (geralmente active directory), a forma de autenticação é outra e não está coberta neste procedimento. Mas se for espertinho, vai saber quais campos trocar.
- Wireguard é mais estável devido a sua natureza e simplicidade criptográfica. IPsec é como organizar o campeonato brasileiro, wireguard é como reunir os amigos e ir pra quadra jogar.

ILUSTRAÇÃO

MATRIZ
IP da LAN: 192.168.10.1/24
WAN: IP PRIVADO RECEBENDO DMZ

USUÁRIO
IP da LAN: 192.168.0.101/24 (internet residencial)

MATRIZ USUÁRIO
ꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷ
-------------------------------TÚNEL IPSEC--------------------------------------------
ꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷꟷ
192.168.10.0/24 LAN < --- 192.168.0.101/24 LAN
---> Firewall < --- Modem/Wi-fi
---> Modem roteado com DMZ ---> INTERNET

ETAPAS

NO FIREWALL DA MATRIZ
1.1. Criando os certificados.

1.1.1. Acessar o menu System > Trust > Authorities
1.1.2. Criar uma nova autoridade da seguinte forma:
Method: Create an internal certificate authority
     Description: CA-VPN-ACESSO-REMOTO
     Lifetime: 3650 (10 anos)
     Country: Brazil
     City: Manaus
     Organization: TiTanium Tecnologia
     OrganizationalUnit: Tecnologia da Informação
     Email address: suporte@titanium.com.br
     CommonName: ca.empresa.com.br
     Salvar
1.1.3. Acesse o menu System > Trust > Certificates
1.1.4. Crie um novo certificado (para o serviço vpn no firewall):
Method: Create an internal certificate
     Decription: CERT-SERVER-VPN-ACESSO-REMOTO
     Type: Server Certificate
     Issuer: CA-VPN-ACESSO-REMOTO
     Lifetime: 3650 (10 anos)
     [os outros campos devem estar preenchido conforme a CA criada anteriormente]
     CommonName: vpn.empresa.com.br (use um domínio registrado e que aponte para o IP público do firewall).
     *Expandir Alternative Names
     Preencher o DNS Domain Names com o mesmo nome do CommonName
     IP Addresses: Preencher caso use diretamente endereços IPs na configuração dos clientes discar a vpn ao invés de nomes de domínio.
     Save.
1.1.5. Crie um novo certificado (dessa vez o do usuário):
Method: Create an internal certificate
     Decription: CERT-USER-VPN-LUCIANO
     Type: Client Certificate
     Issuer: CA-VPN-ACESSO-REMOTO
     Lifetime: 3650 (10 anos)
     [os outros campos devem estar preenchido conforme a CA criada anteriormente]
     CommonName: ludarkstar99 (este será o nome do usuário no log quando conectado. geralmente nome.sobrenome é uma boa escolha).
     *Expanda o campo Alternative Names e em DNS domain names, insira o mesmo common name "ludarkstar99"
     Save.
1.1.6. Na medida que precisar conectar mais usuários, crie outros certificados de usuário como na etapa 1.1.5.


2.1. Criando o túnel na matriz

2.1.1. Acesse o menu VPN > IPsec > Mobile clients.
2.1.2. Sob a área IKE Extensions, selecione a caixinha Enable IPsec Mobile Client Support.
2.1.3. Ao aparecer as opções abaixo, marque a opção Provide a virtual IPv4 address to clients e preencha com uma rede que ainda não esteja em uso como 10.10.0.0/24, que será usada para atribuir endereços aos clientes de vpn.
2.1.4. Marque a opção Network List - Provide a list of accessible networks to clients.
2.1.5. Marque DNS Default Domain e forneça o domínio interno da rede, caso aplicável.
2.1.6. Marque a opção DNS Servers - provide a dns server list to clientes, e insira os servidores dns internos da rede corporativa, ou o endereço do próprio firewall caso queira usá-lo como dns para os clientes.
2.1.7. Clique em Save.
2.1.8. Aparecerá uma tarja azul com o botão "Create Phase1". Clique neste botão.
2.1.9. Selecione a interface caso deseje atribuir apenas uma, ou deixe como Any caso queira receber a conexão por mais de um link de internet.
2.1.10. Dê uma descrição para o túnel.
2.1.11. No método de autenticação selecione RSA (local) + EAP-TLS (remote)
2.1.12. Em my certificate, selecione o certificado do tipo servidor que você criou anteriormente (CERT-SERVER-VPN-ACESSO-REMOTO).
2.1.13. No proposal da Fase 1 selecione 3DES, SHA1 e DHkey group 2 (1024bits). Eu sei... é simples, mas é funcional! Vai por mim, você não está com a NSA atrás de você.
2.1.14. Marque a opção Disable Rekey (windows tem um problema conhecido com isso).
2.1.15. Defina o lifetime como 28800 (windows tem esse direto em seu código).
2.1.16. Salve.
2.1.17. Sobre a linha da fase1, clique no ícone de [ + ] para adicionar uma fase2 a esse túnel.
2.1.18. Ajuste o Local Network de acordo com o que deseja que os usuários desse túnel tenha acesso.
2.1.19. Defina o proposal da fase como AES128, SHA1.
2.1.20. Defina o lifetime como 3600.
2.1.21. Clique em Save.
2.1.22. Clique no canto inferior esquerdo da tela em Enable IPsec.
2.1.23. CLique em Apply Changes.

3.1. Criar as regras de Firewall para permitir entrada da conexão IPsec (isakmp).

3.1.1. Acesse o menu Firewall > Aliases.
3.1.2. Crie um alias com nome SVC_IPSEC_ISAKMP do tipo Port com as portas 500 e 4500.
3.1.3. Acesse o menu Firewall > Rules > Floating.
3.1.4. Crie uma nova regra para liberar o tráfego vpn, selecionando as interfaces de internet, protocolo UDP, origem Any, destino o próprio firewall (this firewall / self) e em porta destino selecione o alias SVC_IPSEC_ISAKMP. Aplique a regra após ter salvo.
3.1.5. Acesse o menu Firewall > Rules > IPsec e crie uma regra de firewall na interface do IPsec liberando todo o tráfego origem/destino/protocolo. Depois que tiver validado, você volta e cria apenas as regras de acessos específicos, mas por enquanto vamos deixar aberto mesmo.

4.1. Instalar o certificado na máquina do usuário

NO FIREWALL
4.1.1. Acesse o menu Trust > Authorities e clique para realizar o download da authority CA-VPN-ACESSO-REMOTO (ícone de nuvem). Após o download, renomeie o arquivo de .pem para .crt.
4.1.2. Acesse o menu Trust > Certificates e clique para realizar o download (PKCS #12) do certificado de usuário criado (CERT-USER-VPN-LUCIANO). É obrigatório definir uma senha para download do certificado.

NA MÁQUINA DO USUÁRIO
4.1.3. Instale o certificado da autoridade na pasta de autoridades raiz confiáveis de certificados da máquina. *Botão direito (mostrar mais opções), instalar certificado, máquina, raiz confiáveis. vrau!
4.1.5. Instale o certificado do usuário na pasta de certificados pessoais do usuário. *Botão direito (mostrar mais opções), instalar PFX, usuário, senha, pessoal. vrau!
4.1.6. Crie a conexão vpn do windows usando o powershell com os comandos abaixo:

Code: [Select]


$eap_tls_config = [xml]@"
<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig"><EapMethod><Type xmlns="http://www.microsoft.com/provisioning/EapCommon">13</Type><VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId><VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType><AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId></EapMethod><Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig"><Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1"><Type>13</Type><EapType xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV1"><CredentialsSource><CertificateStore><SimpleCertSelection>true</SimpleCertSelection></CertificateStore></CredentialsSource><ServerValidation><DisableUserPromptForServerValidation>false</DisableUserPromptForServerValidation><ServerNames></ServerNames></ServerValidation><DifferentUsername>false</DifferentUsername><PerformServerValidation xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">true</PerformServerValidation><AcceptServerName xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">true</AcceptServerName></EapType></Eap></Config></EapHostConfig>
"@

Add-VpnConnection -Name VPN-EMPRESA -ServerAddress vpn.empresa.com.br -TunnelType Ikev2 -AuthenticationMethod Eap `
	-SplitTunneling -EncryptionLevel Optional -EapConfigXmlStream $eap_tls_config

*Troque o parâmetro -ServerAddress vpn.empresa.com.br para o endereço que você está publicando a VPN. Aconselho que registre um nome DNS apontando para o IP público dos links do firewall.

5.1. Testar

5.1.1. Do computador do usuário, disque a vpn.

- 0800, 70, 70, 70... se não der, cêtenta de novo

6.1. Troubleshoot

- Faça uma captura de pacotes para garantir que o firewall está recebendo pacotes na(s) porta(s) 500/4500 UDP.

- Verifique os logs em busca de alguma configuração desalinhada.

- Force o NAT traversal (vpn -> ipsec -> tunnel settings(legacy) -> editar o túnel fase1 -> Definir o NAT Traversal como Force.

- Sempre reinicie o serviço depois de aplicar a configuração. Ao aplicar a configuração apenas é feito um reload dos túneis e pode não carregar tudo que precisa, como novos plugins (o caso do eap-identity para autenticar usuários via certificados).

- Caso apareça nos logs a mensagem "no trusted certificate found for 'ludarkstar99' to verify TLS peer", edite o certificado do usuário no firewall, espanda o campo Alternative Names e em DNS domain names, insira o mesmo common name "ludarkstar99". Nos próximos certificados que criar, insira a identificaçao do usuário tanto no common name quanto no DNS domain names. É necessário baixar e instalar o certificado do usuário novamente. Exclua o certificado antigo para não ficar duplicado.

Portuguese - Português / Re: HOWTO - Sobrevivendo na Linha de Comandos

« on: November 15, 2024, 06:17:46 am »

======================================================
=== OPNSENSE - SOBREVIVENDO NA LINHA DE COMANDOS ===
====== 1 Temporada: EP IV - Escolha bem seu caminho ======
======================================================
Responsável: ludarkstar99
Data: 14/11/2024
Versão: 1.0
======================================================

DESCRIÇÃO

Todo homem é igual perante Deus. E talvez por isso possuímos um instinto natural de ficar perdido sem o GPS. Sabe quando você precisa chegar a um lugar de carro, não lembra o caminho de cabeça, mas é só ir dirigindo que você sabe que vai chegar lá? Pois bem, eu tive uma namoradinha na minha adolescência que, sempre que podíamos, arrumávamos uma desculpa para ir para a casa dela buscar ela e dar um rolê nos bares do Bueno Franco. Éramos alguns amigos, e eu era um dos que tinha carro na época. Eu nunca memorizei o trajeto até lá, mas era só pegar a estrada e de alguma forma chegávamos até lá. Talvez a vontade de vê-la fosse tanta que, instintivamente, a cabeça de baixo guiava o trajeto, como o pica-pau que vai atrás do frango flutuando pelo cheiro... Há diversos caminhos; alguns que não levam a lugar nenhum, alguns que estão lá só por comodidade, alguns que você nem sabia que dava para chegar lá, e outros que não têm como errar. Fato é: alguns caminhos, depois que você passa por eles, não têm mais volta.

DO INÍCIO

Há algumas pessoas que a chamam de Shell, outros de terminal, fulano chama de prompt de comandos e ciclano chama de linha de comandos. Mas todos esses termos remetem a algo que nós, profissionais de TI, reconhecemos ao ver, mas sequer sabemos sua história. Não estou aqui para falar de máquinas de escrever, até porque são apenas uma parte da história. Teríamos que falar de sinais elétricos e teoria da comunicação para chegar à base do que hoje é a interface que interage com o núcleo do sistema operacional. Sim, estou falando da tela preta e letra branca (ou "esverdeada" para alguns). Aquela tela que você vê o hacker digitando rapidamente e, de repente, aparece um alerta que ele foi descoberto ou que o firewall foi penetrado com sucesso [lá ele] (vide takedown).

O terminal com o qual você interage nada mais é que uma interface - termo genérico para designar controles dos quais você envia e recebe sinais com o outro ator que está do outro lado. Em nosso caso, nós despachamos comandos usando a interface de terminal, e o terminal repassa nossos comandos digitados para o sistema operacional. É como comprar um bilhete de metrô em São Paulo, usando um caixa com uma pessoa de verdade e não caixa eletrônico. Você diz quantos bilhetes quer, coloca ali o dinheiro, o caixa pega seu dinheiro, processa sua solicitação e lhe entrega os bilhetes, simples assim. Indo pela etimologia da palavra, "Terminal" é relativo a uma extremidade. Lembre-se dos mainframes: o CPU ficava em um lugar - em uma extremidade, e o terminal em outra extremidade. O terminal era a tela e teclado (interface) pelo qual o usuário interagia com o sistema. E é o que mantemos até hoje. Você pode acessar o firewall pelo terminal "físico", com teclado e mouse, e vai interagir com o sistema operacional enviando comandos e aguardando resultados, ou via terminal remoto. Antigamente se usava telnet; devido à sua fragilidade (simplicidade) de segurança, hoje usamos o SSH, que permite essa interação usuário/sistema via rede de forma segura, sem permitir que um curioso "ponha o ouvido no cabo" e escute os comandos que você está dizendo ao sistema operacional do outro lado.
Dei essa volta toda para lhe contar o óbvio.

O TERMINAL DO FIREWALL

Há mais de uma forma de acessar o terminal (interface para enviar comandos e receber resultados) do sistema. Vai depender um pouco do hardware e de onde você está em relação a ele. Vamos pelos mais simples: na época da vovó, em dispositivos mais simples, eles não possuíam teclado e mouse, assim como os videogames. Uma vez programados, não havia interface para administrar, ou era administrado via o software que ali rodava, com uma interface bem limitada referente ao que se podia fazer no sistema. Muitas caixas de firewall foram criadas para usarem hardware embarcado, o menor hardware possível com a maior potência, sendo específico para um determinado fim. Quando estudei no SENAI e pude participar de um treinamento para um campeonato de robótica (do qual acabei não participando no final das contas), eu estava na equipe de pneumática - usávamos um robô pronto, já vinha programado, só tínhamos que usar o software gráfico construtor de blocos para dar a lógica ao robô. Mas havia outra equipe, a da eletrônica, e o robô deles eles mesmos construíram e programaram do zero. Era muito mais interessante que o nosso... E esse robô (interessante), que era inclusive programado em C (mais tarde eu descobri que o nosso tinha SDKs e poderia ser programado em C, Java, C++ e Python, mas os coordenadores demonstraram que não era aceitável trabalhar dessa forma, pois não era para entender o robô, era só para ganhar a competição), tinha uma interface de comunicação com o mundo externo, e era uma saída Serial (RS232). Essa saída permitia que um comando por vez fosse enviado ao robô, que o processaria e então devolveria na mesma porta Serial o resultado para aquilo que estava conectado à porta (um computador quando faziam debug ou um sensor quando entrava em testes na pista). O que eu quero dizer com isso é que há hardware em que o firewall pode ser instalado e que não terá teclado e mouse, mas sim uma porta serial para comunicação do hardware com o mundo exterior. Geralmente, nesse tipo de hardware, o sistema operacional é instalado em um cartão de memória em um notebook e então levado e instalado no minicomputador do firewall. Assim, o sistema já dá boot com o S.O pré-instalado e, a partir dali, você pode se comunicar com ele via porta Serial ou se conectar a ele via rede/webgui. Mas como, nos dias atuais, ficou banal usar hardware x86 para tudo, não seria diferente com os firewalls. Tanto que o pfSense foi um dos precursores em permitir a execução de um firewall robusto em hardware x86 de desktops (você verá por aí alguns artigos chamando de commodity). Essas máquinas desktop, de maneira geral, possuem placas-mãe integradas com conectores de teclado, mouse e vídeo - famoso on-board. Para esses casos, o firewall pode ser instalado via CD-ROM (ou pendrive para os mais novos) diretamente no hardware em que será usado, e você acessa e interage inicialmente com o sistema via teclado/monitor, até que ele tenha rede e o restante você faz da sua própria mesa.

Para este artigo, estou assumindo que o firewall OPNsense está instalado em um hardware x86 e que você pode, a qualquer momento, conectar teclado e mouse na "CPU" para executar comandos no sistema.

O CONSOLE PADRÃO DO OPNSENSE

Você vai notar que, após ligar o firewall, pode acompanhar no monitor várias letras passando até que o sistema seja inteiramente carregado na memória. Essas letras são informações que o BootLoader e o *Kernel vão gerando na medida que o sistema é carregado. Uma vez pronto para operar, você é apresentado ao console padrão do OPNsense, protegido por senha.

Thu Nov 14 22:45:51 -03 2024

*** utm.citrait.corp: OPNsense 24.7.8 ***

WAN (hn1) -> 192.168.254.2/24
LAN (hn0) -> v4: 192.168.1.1/24
-> v6/t4: 2804:d45:d9e4:[:redacted:]1300/64

HTTPS: sha256 30 B7 03 7C E1 EC 1B 0F 3D 84 AE 1B EF E3 41 D3
93 48 85 BE 7C 72 FF AB D1 CA 97 15 AD D3 A8 ED

FreeBSD/amd64 (utm.citrait.corp) (ttyv0)

login:

Este é um TTY (console virtual) alocado para ser exibido no monitor, e através dele você já pode interagir com o sistema, claro, depois que provar que tem as chaves (login e senha). Neste momento, o console está executando um programa chamado "Login", que única e exclusivamente tem a função de validar login + senha e, se estiver errado, repetir até que uma combinação válida seja informada.
Ao fornecer uma combinação de login e senha válidos, o programa "Login" vai preparar o ambiente do usuário, ler seu shell padrão disponível no arquivo /etc/passwd e então vai invocar este shell. O shell em si é o interpretador de comandos interativo, que lê uma linha por vez, leva para o S.O, aguarda o processamento e traz de volta o resultado.

Mas qual é o Shell padrão do usuário padrão do OPNsense?
Bom, o usuário padrão é o root, e para saber qual o shell padrão, devemos verificar o arquivo /etc/passwd.

Code: [Select]

$ cat /etc/passwd

[...]
root:*:0:0:System Administrator:/root:/usr/local/sbin/opnsense-shell
[...]

Veja que o shell padrão é o último parâmetro do arquivo (aqui os parâmetros são separados por dois pontos ":"). No caso do root, o shell será o /usr/local/sbin/opnsense-shell. Para você que é curioso, basta ler o conteúdo do arquivo para entender melhor o que ele faz. Você não vai se arrepender

Code: [Select]

less /usr/local/sbin/opnsense-shell

[...]
#!/bin/sh

# Copyright (c) 2014-2018 Franco Fichtner <franco@opnsense.org>
# Copyright (c) 2004-2011 Scott Ullrich <sullrich@gmail.com>
# Copyright (c) 2003-2004 Manuel Kasper <mk@neon1.net>
# All rights reserved.

# make sure the user can't kill us
trap : 2
trap : 3
[...]

Bem no início do arquivo nós podemos atestar aquela célebre frase: se eu cheguei longe, foi porque subi nos ombros de gigantes. o que você tá ai usando como opnsense vem de 20 anos atrás.
Kasper teve coragem para iniciar, Ullrich teve visão para continuar, Franco teve "as manha" de aperfeiçoar.
E se observar bem, a frase logo abaixo nos diz mais sobre legado: aquilo que você faz pelo mundo deixa um legado e você precisa garantir que a semente que plantou levará seu nome no fruto.
Certamente que nenhum usuário poderá remover o nome de qualquer um de vocês, certo? Vocês não removeram os nomes de quem veio antes. Ainda sim armam uma emboscada, só pra garantir... E assim a tradição passa. *estou me referindo ao texto acima do arquivo. "make sure the user can't kill us". Quer outra *coincidência no código? trap é um comando shell para receber sinais externos ao seu programa. Ao declarar o trap para os sinais 2 (sigint) e 3 (sigquit), de fato o número 3 da lista saiu, desistiu, e o número 2 foi interrompido...

OPÇÕES DO SHELL PADRÃO

Ao ter acesso ao shell padrão, você é apresentado com algumas opções pré-definidas, como executar um ping para testar a conectividade da rede, reiniciar o firewall, restaurar o padrão de fábrica, e até mesmo atualizar o firmware. Basicamente este é um menu pré-definido para realizar ações rotineiras. Raramente precisaremos acessar o shell (bom, espero que você não precise, se você precisa acessar o shell, você é o tipo de pessoa que deveria estar escrevendo este artigo ao invés de lê-lo).
Mas além das opções pré-definidas do shell, há também uma opção sob o menu de número 8 chamada Shell. O shell vai permitir fazer tudo o que este menu pré-programado não permite fazer.

ESCAPE PARA A CONCHA (ESCAPE TO THE SHELL)

Bom, se já acessou alguma vez algum sistema linux, você já sabe o que fazer.

CAMINHOS IMPORTANTES NO SHELL

Assim como um sistema linux com pastas parametrizadas conforme uma hierarquia comum (FHS), o FreeBSD também possui uma estrutura semelhante de pastas e arquivos no sistema de arquivos. Entre os importantes:

/tmp => pasta de arquivo temporários. Esta pasta é uma boa decisão de armazenar informações temporárias, que serão limpar após um reboot.

/etc => para quem vem do Linux, a pasta etc é onde concentramos os arquivos de parâmetros e configurações dos serviços do sistema, como o carregador de inicialização (grub), SSH, BIND, montagem de filesystem (fstab), scripts de inicialização (rc.d), dentre diversos outros aspectos configuráveis do sistema. Aqui no FreeBSD/OPNsense você perceberá que esta pasta não leva todas as configurações e sim somente algumas... porque?

/usr/local => se você já compilou algum programa do mundo *nix na linha de comandos, sabe que comumente existe um parâmetro chamado --prefix e através dele dizemos qual a hierarquia de pastas que o programa vai gerar os arquivos quando for instalado. No linux comumente usamos os diretorios /usr, /etc, /bin, /sbin, ou seja, o prefixo para pastas e arquivos dos programas vão direto na raiz "/". Aqui no FreeBSD/OPNsense a pegada é diferente. Os programas são compilados previamente tendo o prefixo sendo a pasta /usr/local (repare o "local" - não misturar o que é sistema/s.o com o que é configuração local de programa/userland).

/usr/local/www => pasta que comporta os arquivos .php (e também html/css) do opnsense, em específico a interface web no que diz respeito a parte legada. Hoje muita coisa foi construída em cima da API e na medida que o tempo passa, mais áreas da webgui estão se adaptando a ela. Os arquivos da API fica numa pasta diferente.

/usr/local/opnsense => este é grande... basicamente manifesta a essência do OPNsense - a interface (web) que orquestra todo o ecossistema de softwares rodando por debaixo dos panos. Aqui temos a definição da webgui em modelo/visão/controller (modelo MVC para os mais íntimos da programação), além da definição do backend responsável por receber as requisições da web e transformar em arquivos de configurações (templates) para os daemons (serviços). Além disso, há vários scripts para tarefas auxiliares presentes nesta pasta. Muitos que você deveria inclusive saber se quiser entender melhor como o sistema funciona.

/usr/local/opnsense/service/templates => certa vez eu precisei alterar um parâmetro no arquivo squid.conf que o OPNsense gera. Mas sempre que reiniciava o serviço ou dava um reboot no firewall o arquivo era gerado novamente e perdia a minha customização. Nesta pasta se encontram os arquivos "template/modelo" que o opnsense usa para gerar as configurações, então se precisar ajustar algo que não está disponível na webgui, a melhor forma de fazer isso é alterando diretamente nos templates. Não aconselho alterar diretamente os arquivos do OPNsense, mas se for algo para resolver um problema ou implementar uma funcionalidade ainda não existente, você já sabe o caminho.

/usr/local/opnsense/service/conf/actions.d => pasta onde ficam os arquivos de tarefas automáticas. inclusive vimos em um episódeo passado como criar e agendar seu script crontab.

/var => alguns serviços como o dhcp e o unbound (dns) gravam dados nesta pasta. "var" é de variável, geralmente onde deveriam estar pastas e arquivos usados constantemente como uploads, bancos de dados e caches, assim como logs (registros de eventos).

/var/log => esse nem precisa de mistério.

CONCLUSÃO

Não invente problemas que não existem. Obedeça as regras e sua vida será fácil. Desvie do caminho e terá que resolver os problemas por conta própria, pois está todo mundo na linha, e ninguém é louco o suficiente para sair dela como você fez.

That's all folks.

Portuguese - Português / HOWTO - Traffic Shaping Reservar Banda para Telefonia

« on: November 12, 2024, 02:38:57 am »

================================================================
=== OPNSENSE - TRAFFIC SHAPING ===
========== RESERVAR BANDA PARA TELEFONIA ==========
================================================================
Responsável: ludarkstar99
Data: 11/11/2024
Versão: 1.0
================================================================

OPNSENSE - USANDO TRAFFIC SHAPING PARA RESERVAR BANDA PARA A TELEFONIA/VOIP

RESUMO

Este é um procedimento para aplicar o traffic shaping de forma a limitar o tráfego em duas vias:
1a via para o tráfego de telefonia
2a via para o tráfego de outros acessos (internet, e-mail, ... tudo que não for telefonia).
Além disso o emprego da banda para telefonia é apenas um exemplo, poderia ser para qualquer outro tráfego selecionado.
Neste exemplo estamos usando um link de internet simétrico - 100Mbps tanto de download quanto de upload. Algumas pessoas conhecem o tipo de link como "Full/Dedicado".
Assume-se que estamos reservando 10Mbps de download/upload para o tráfego de voz, e o restante para os demais tráfegos como navegação, email, ftp, etc, etc.

IMPORTANTE

A ordem das regras importa! Na hora de aplicar os pipes criados, tenha em mente que a aplicação é de cima para baixo, ou seja, se um determinado tráfego possivelmente corresponder em duas regras, apenas a regra criada acima será aplicada imediatamente. Programe suas regras de forma que as regras mais específicas estejam no topo, e as mais gerais embaixo.

ETAPAS

1. RESERVAR BANDA

1.1. Criar os pipes (quantidade de banda reservada)

1.1.1. Acessar o menu Firewall > Shaper > Pipes.
1.1.2. Criar um pipe com nome "UploadVoz10Mbps" banda de 10Mbps e máscara (none) (todos os ips que aplicam vão compartilhar a banda).
1.1.3. Duplicar o pipe acima com nome "DownloadVoz10Mbps".
1.1.4. Criar um pipe com nome "UploadOutros90Mbps" banda de 90Mbps e máscara (none) (todos os ips que aplicam vão compartilhar a banda).
1.1.5. Duplicar o pipe acima com nome "DownloadOutros90Mbps".

1.2. Criar as regras para aplicar os pipes

1.2.1. Acessar o menu Firewall > Shaper> Rules.
1.2.2. Criar uma regra aplicando na interface WAN com origem any e destino o IP do servidor SIP/VOIP, e target o pipe UploadVoz10Mbps.
1.2.3. Duplicar a regra acima e alterar a origem para o IP o IP do servidor SIP/VOIP, destino any, target DownloadVoz10Mbps.
1.2.4. Criar uma regra aplicando na interface WAN com origem a rede LAN, destino any, e target o UploadOutros90Mbps.
1.2.5. Duplicar a regra acima e alterar a origem para any, destino a rede LAN, e target DownloadOutros90Mbps.

2. TESTAR
Parece meio óbvio (com a voz do senhorzinho de "o poço" disponível na netflix), mas é necessário testar.

That's all folks.

Portuguese - Português / HOWTO - VPN IPsec Site a Site Atrás de NAT

« on: November 11, 2024, 04:51:47 pm »

================================================================
=== OPNSENSE - IPSEC SITE-A-SITE ATRÁS DE NAT ===
================================================================
Responsável: ludarkstar99
Data: 10/11/2024
Versão: 1.0
================================================================

OPNSENSE - CONFIGURAR IPSEC SITE-A-SITE ATRÁS DE NAT (AMBAS AS PONTAS)

RESUMO

Este procedimento foi criado para permitir que você configure o IPsec para conectar entre duas unidades, de forma que apenas uma delas vai precisar de um IP público com publicação de portas.

OBSERVAÇÕES

Este procedimento NÃO irá funcionar se Ambas as pontas estão atrás de CGNAT (carrier gra... se seu IP no modem/firewall começa com 100.xx.xx.xx);
> Será usado o modo Tunnel (ou policy routing, aquele no qual o IPsec não mostra a rota na lista, mas sabe como rotear direto no kernel os pacotes de um lado pro outro da vpn).

PREMISSAS

- Será configurado o IPsec usando o modo Connections (menu mais recente), para que conectemos ambas as pontas com sucesso.
- Um lado será o "servidor" da vpn, e o outro será o "cliente".
- Na unidade que será o "servidor" da VPN, além do IP público, precisará de confirmação que pode publicar portas (ver com provedor).

ILUSTRAÇÃO

MATRIZ
IP da LAN: 192.168.10.1/24
WAN: IP PRIVADO RECEBENDO DMZ

FILIAL
IP da LAN: 192.168.20.1/24
WAN: IP PRIVADO OU CGNAT

MATRIZ FILIAL
______________________________________________________________________________
-----------------------------------------------TÚNEL IPSEC-------------------------------------------------
______________________________________________________________________________
192.168.10.0/24 LAN < --- 192.168.20.0/24 LAN
---> Firewall < --- Firewall
---> Modem roteado com DMZ ---> <--- Modem roteado sem dmz (ou cgnat)
Internet

ETAPAS

1. No firewall da matriz (lado "servidor" da vpn)

1.1. Criando o túnel na matriz

1.1.1. Acesse o menu VPN > IPsec > Pré-Shared Keys.
1.1.2. Crie uma nova Pré-Shared key clicando no ícone (+) adicionar.
1.1.3. Preencha o Local Identifier como matriz e o Remote Identifier como filial, preencha a pré-shared key (exemplo: password) que deverá ser a mesma nos 2 firewalls e clique em Save, depois Apply.
1.1.4. Acesse o menu VPN > IPsec > Connections.
1.1.5. Crie um novo túnel clicando no ícone (+) adicionar.
1.1.6. Marque a opção "advanced mode" que fica no canto superior esquerdo do formulário.
1.1.7. Selecione o campo Unique como Replace.
1.1.8. Selecione o campo Version como IKEv2
1.1.9. Em local address preencha com o IP público do link (ou se tier atrás do modem/dmz - deixar vazio).
1.1.10. Deixe o campo remote addresses como vazio.
1.1.11. Habilite o campo UDP encapsulation.
1.1.12. Preencha uma descrição para o túnel.
1.1.13. Clique em adicionar (+) um Local Authentication.
1.1.14. Preencha o campo Id como matriz e salve.
1.1.15. Clique em adicionar (+) um Remote Authentication.
1.1.16. Preencha o campo Id como filial e salve.
1.1.17. Clique para adicionar (+) uma nova Children.
1.1.18. Em start action selecione Trap (vamos deixar o túnel em pé, mas aguardando o lado cliente vpn começar enviar tráfego).
1.1.19. Preencha o campo Local com a rede local (ex.: 192.168.10.0/24) e o campo Remote com a rede remota (ex.: 192.168.20.0/24).
1.1.20. Clique em salvar para fechar a fase 2.
1.1.21. Clique em salvar para salvar o túnel vpn.

1.2. Criar as regras de Firewall para permitir entrada da conexão IPSec.

1.2.1. Acesse o menu Firewall > Rules > Floating.
1.2.2. Crie uma nova regra para liberar o tráfego ipsec, selecionando as interfaces de internet, protocolo UDP, porta 4500, origem Any e destino o próprio firewall (this firewall / self). Aplique a regra após ter salvo.
1.2.3. Crie uma nova regra para liberar o tráfego ipsec, selecionando as interfaces de internet, protocolo UDP, porta 500, origem Any e destino o próprio firewall (this firewall / self). Aplique a regra após ter salvo.
1.2.4. Acesse o menu Firewall > Rules > IPsec e crie uma regra de firewall na interface do IPsec liberando todo o tráfego origem/destino/protocolo. Depois que tiver validado, você volta e cria apenas as regras de acessos específicos, mas por enquanto vamos deixar aberto mesmo.
1.2.5. Crie uma nova regra de firewall na interface LAN permitindo a rede local da matriz chegar na rede local da filial (allow, source:lan net, destination: single host or network 192.168.20.0/24). Após criar esta regra suba ela para o topo para ter precedência entre as outras.

2.1. Criando o túnel na filial

2.1.1. Acesse o menu VPN > IPsec > Pré-Shared Keys.
3.1.2. Crie uma nova Pré-Shared key clicando no ícone (+) adicionar.
2.1.3. Preencha o Local Identifier como filial e o Remote Identifier como matriz, preencha a pré-shared key (exemplo: password) que deverá ser a mesma nos 2 firewalls e clique em Save, depois Apply.
2.1.4. Acesse o menu VPN > IPsec > Connections.
2.1.5. Crie um novo túnel clicando no ícone (+) adicionar.
2.1.6. Marque a opção "advanced mode" que fica no canto superior esquerdo do formulário.
2.1.7. Selecione o campo Unique como Replace.
2.1.8. Selecione o campo Version como IKEv2.
2.1.9. Em local address deixar vazio.
2.1.10. Preencha o campo remote addresses com o IP público/ddns da matriz.
2.1.11. Habilite o campo UDP encapsulation.
2.1.12. Preencha uma descrição para o túnel.
1.1.13. Clique em adicionar (+) um Local Authentication.
2.1.14. Preencha o campo Id como filial e salve.
2.1.15. Clique em adicionar (+) um Remote Authentication.
2.1.16. Preencha o campo Id como matriz e salve.
2.1.17. Clique para adicionar (+) uma nova Children.
2.1.18. Em start action selecione Start (iniciar ativamente a conexão).
2.1.19. Preencha o campo Local com a rede local da filial (ex.: 192.168.20.0/24) e o campo Remote com a rede da matriz(ex.: 192.168.10.0/24).
2.1.20. Clique em salvar para fechar a fase 2.
2.1.21. Clique em salvar para salvar o túnel vpn.

2.2. Criar as regras de Firewall para permitir entrada da conexão IPSec.

2.2.1. Acesse o menu Firewall > Rules > IPsec e crie uma regra de firewall na interface do IPsec liberando todo o tráfego origem/destino/protocolo. Depois que tiver validado, você volta e cria apenas as regras de acessos específicos, mas por enquanto vamos deixar aberto mesmo.
2.2.2. Crie uma nova regra de firewall na interface LAN permitindo a rede local da filial chegar na rede local da matriz (allow, source:lan net, destination: single host or network 192.168.10.0/24). Após criar esta regra suba ela para o topo para ter precedência entre as outras.

3. Criar um gateway local (em ambos os firewalls) para forçar o tráfego Firewall <--> Firewall sair com o IP de lan.

3.1. Este procedimento não é obrigatório, mas vai facilitar quando você tem serviços iniciado dentro do próprio firewall que precisam conversar com a outra ponta.
3.2. Acesse o menu System > Gateways > Configuration.
3.3. Clique em adicionar um novo gateway (+).
3.4. Preencha o nome do gateway (GW_IPSEC_MATRIZ), selecione a interface LAN, e no campo IP address preencha com o endereço IP da interface LAN do firewall (192.168.20.1 a LAN do firewall da filial). Clique em salvar.
3.5. Acesse o menu Routes > Configuration.
3.6. Clique para adicioanar uma nova regra (+).
3.7. Preencha o campo Network address com a rede lan da matriz (192.168.10.0/24). Selecione o gateway criado anteriormente (GW_IPSEC_MATRIZ), dê uma descrição para a rota (ROTA_LAN_MATRIZ) e clique em Save depois em Apply.
3.8. Repita esta etapa agora no firewall da matriz, mas preenchendo os dados na perspectiva da matriz (alterar o ip do gateway para 192.168.10.1 e destino da rota como 192.168.20.0/24).

4. Testar
agora é só testar e validar que funciona.

Troubleshoot

- Faça uma captura de pacotes para garantir que o firewall da filial está chegando com algum tráfego na porta 500/4500 do firewall matriz.
- Verifique os logs em busca de alguma configuração desalinhada entre os dois firewalls.

Portuguese - Português / Re: HOWTO - Sobrevivendo na Linha de Comandos

« on: November 09, 2024, 03:58:02 am »

======================================================
=== 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]

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]

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]

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]

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]

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]

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.

Portuguese - Português / Re: HOWTO - Sobrevivendo na Linha de Comandos

« on: November 08, 2024, 12:13:07 am »

======================================================
=== 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]

[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]

[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

Portuguese - Português / HOWTO - Instalando NTOPNG

« on: November 06, 2024, 02:43:09 pm »

================================================================
=== 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]

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.

Portuguese - Português / HOWTO - Sobrevivendo na Linha de Comandos

« on: November 05, 2024, 03:58:15 pm »

======================================================
=== 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.

Portuguese - Português / HOWTO - OPNsense na Oracle OCI

« on: November 05, 2024, 03:37:07 pm »

======================================================
=== 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

)
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]

<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.

Portuguese - Português / Re: HOWTO Tunning do Firewall (generalizado)

« on: November 05, 2024, 02:56:48 pm »

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.

Portuguese - Português / HOWTO Tunning do Firewall (generalizado)

« on: November 04, 2024, 12:27:20 pm »

================================================================
=== 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://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.

Portuguese - Português / OpenVPN Connect - Erro Sufixo DNS

« on: November 03, 2024, 01:35:22 am »

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]

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.

Portuguese - Português / HOWTO Configurar Wireguard Site-a-Site

« on: November 02, 2024, 09:57:32 pm »

======================================================
=== 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.

Portuguese - Português / HOWTO Configurar Bridge para LAN

« on: November 02, 2024, 04:45:12 pm »

=============================================
=== 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.

Portuguese - Português / HOWTO Configuração MONIT

« on: November 01, 2024, 04:00:32 pm »

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.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 NOVO LOGIN SSH e WebGui
2.1. Criar o teste Novo_Login_SSH
Acessar a tela Service Tests Settings
Clicar em adicionar um novo Test
Preencher o nome com Novo_Login_SSH
Preencher a condição com: content = "Accepted .* ssh2"
Selecionar a ação sendo: Alert
Clicar em Save

2.2. Criar o teste Novo_Login_WebGui
Acessar a tela Service Tests Settings
Clicar em adicionar um novo Test
Preencher o nome com Novo_Login_WebGui
Preencher a condição com: content = "Successful login for user"
Selecionar a ação sendo: Alert
Clicar em Save

2.3. Criar o Service Acesso_Ao_Firewall_Detectado
Acessar a tela Service Settings
Clicar em adicionar um novo Service
Marcar a caixa: Enable Service Checks
Preencher o nome com: Acesso_Ao_Firewall_Detectado
Preencher o Tipo como: File
Preencher o path como: /var/log/audit/latest.log
Selecionar os testes criados anteriormente: Novo_Login_SSH e Novo_Login_WebGui
Preencher a descrição: Notifica novos logins no firewall.
Clicar em Save

3. CONFIGURAR PARA ALERTAR EM ALTERAÇÃO DE CONFIGURAÇÃO
3.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

3.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

4. CONFIGURAR PARA ALERTAR NA FALHA DE GATEWAY
4.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

4.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

5. CONFIGURAR PARA ALERTAR SE VPN CAIR (E REINICIAR TAMBÉM)
5.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

5.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.

6. CONFIGURAR PARA ALERTAR QUANDO O CROWDSEC BLOQUEAR IP INTERNO
6.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

6.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

7. TESTAR
7.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.

Pages: [1] 2