Messages

[Olá, pessoal!]

Olá, pessoal!

Espero que estejam todos bem. Hoje vou falar sobre algo que sempre me deixa intrigado: Logs. Mais especificamente, pesquisa em logs. 
Se você já precisou verificar as datas de autenticações de um usuário no log da VPN ou rastrear uma sessão "presa" na tela de states/sessions, deve ter se perguntado qual seria a melhor maneira de preencher a caixa de pesquisa para filtrar e encontrar rapidamente o que procura. 

Pois bem, como diria um famoso youtuber: "Vem comigo!"

COMEÇANDO PELO COMEÇO

A ideia é mostrar como funciona a pesquisa no OPNsense, para que isso possa servir de referência em futuras investigações. Precisei desse conhecimento e quase ninguém explicou como fazer. Então, deixo aqui o rastro para você não dizer que ninguém te ajudou.

Primeiro, vamos conferir como era a pesquisa em um firewall com a versão "OPNsense 24.1". É importante entender o passado para encarar o futuro. 

• Acesse VPN > OpenVPN > Log File.
• Na tela, você verá os logs mais recentes do OpenVPN em formato paginado.
• No canto superior direito, há uma barra de pesquisa para filtrar informações específicas.

Faça um teste: conecte-se à VPN, retorne a essa tela, pesquise pelo seu login e marque o nível de severidade como DEBUG para ver todas as mensagens. Você deve encontrar entradas de log relacionadas ao seu usuário, o que é bem útil.

Code Select Expand

Date                Severity    Process         Line
2025-02-19T20:41:27-03:00 Notice openvpn_server4 ludarkstar99/177.177.177.177:51645 SIGUSR1[soft,ping-restart] received, client-instance restarting
2025-02-19T20:41:27-03:00 Notice openvpn_server4 ludarkstar99/177.177.177.177:51645 [ludarkstar99] Inactivity timeout (--ping-restart), restarting
2025-02-19T08:16:14-03:00 Notice openvpn_server4 ludarkstar99/177.177.177.177:51645 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt

Agora, imagine que você quer apenas as linhas de autenticação bem-sucedida do usuário ludarkstar99. Filtrar apenas pelo login traz várias outras mensagens (inatividade, criptografia, certificado etc.). Se quiser apenas a linha que indica conexão bem-sucedida — algo como:

Code Select Expand

177.177.177.177:51645 [ludarkstar99] Peer Connection Initiated with [AF_INET6]::ffff:177.177.239.204:51645 (via 177.39.39.39%vmx0_vlan301)

Talvez você tente "[ludarkstar99] Peer Connection Initiated with" na caixa de pesquisa... e não encontre nada! Isso acontece porque o OPNsense remove caracteres especiais como `[]`, `+`, `&`, `$` etc.  e isso quebra a correspondência exata dos termos em sequência, pois falta os caracteres "[" e "]".

Então, como pesquisar tanto pelo nome do usuário quanto pelo texto que indica autenticação bem-sucedida? Em geral, sistemas de log permitem expressões regulares ou curingas. De fato, o OPNsense suporta algo do tipo, mas com ressalvas.

OS PRUDENTES VEEM O PERIGO E SE ABRIGAM

Sempre que surge um problema, gosto de pensar que esses desafios nos fazem crescer. Se eu simplesmente entregasse a solução de bandeja, você talvez não entendesse todo o processo. Então, vamos explorar como o OPNsense faz essa busca nos logs.

• Abra as Ferramentas de Desenvolvedor do navegador (Ctrl+F12 ou Ctrl+Shift+I). 
  
• No campo de pesquisa, digite, por exemplo: [ludarkstar99] Peer Connection Initiated. 
  
• Observe a requisição na aba Rede: ela chama "/api/diagnostics/log/core/openvpn" com parâmetros searchPhrase e severity. 
  

A requisição chega ao servidor, que remove caracteres especiais e, em seguida, aciona o configd para executar a ação "system diag log", passando parâmetros como módulo (core), arquivo (openvpn) e severidades. Por fim, o configd chama o script /usr/local/opnsense/scripts/syslog/queryLog.py, que realiza a busca no arquivo de log. 

O ponto crucial é: esse script substitui o caractere "*" por ".*" (expressão regular) e, caso você não use "*", o script adiciona ".*" antes e depois do termo pesquisado. Isso significa que, na versão 24.1, se você quiser filtrar "ludarkstar99" + "Peer Connection Initiated" numa mesma linha, precisa usar o curinga "*". Por exemplo:

Code Select Expand

*ludarkstar99*Peer Connection Initiated

Dessa forma, o script consegue montar a expressão regular que "casa" com a linha completa, incluindo eventuais caracteres entre o usuário e o texto desejado.
Obs.: Repare que é é necessário antes do nome do usuário o caractere curinga (*) pois a linha de log não começa com o nome do usuário...

AS COISAS VELHAS JÁ PASSARAM, EIS QUE TUDO SE FEZ NOVO

Até aqui tudo bem para a versão 24.1. Mas e se você estiver na versão 24.7.3 em diante e nada funcionar? Pois é, houve mudanças!

Nessa versão, o script /usr/local/opnsense/scripts/syslog/queryLog.py foi alterado. Em vez de usar expressões regulares, a busca passou a ser literal, fazendo apenas "line.find(clause)". Ou seja, o conceito de "*" como coringa deixa de existir. Se você incluir vários termos, o sistema vai buscar todos eles na linha, mas não com curinga. 

Portanto, se quiser achar "ludarkstar99" e "Peer Connection Initiated" na mesma linha, basta digitar:

Code Select Expand

ludarkstar99 Peer Connection Initiated

Agora, o OPNsense procura cada palavra na linha. Se todas aparecerem, a linha é exibida. Se não, não aparece nada.


Conclusão: 

• Na versão 24.7.2 (ou anteriores), use "*" como coringa para junções. 
  
• Na versão 24.7.3 em diante, a busca se tornou literal e o "*" não tem mais efeito. Basta digitar todas as palavras que deseja encontrar na mesma linha. 
  

That's all folks.


Obs.: Esta mensagem foi melhorada com ajuda de I.A para trazer clareza e diminuir a densidade textual. o texto original possuía mais de 300 linhas, além de sarcasmo excessivo, piadas de mau gosto, e explicações profundamente duvidosas.
"O simples convence."

Olá m4igor, seja bem vindo ao fórum.

Vamos deixar algo claro desde o início: Seu ambiente é um laboratório, e tem suas particularidades.

Nesse caso, você precisa que o gateway da rede 192.168.18.0/24 (ONT) direcione a rede 192.168.27.0/24 (via rota estática) para o IP do opnsense (wan) na rede 192.168.18.0/24 (próximo salto).
Assim o OPNsense vai receber as conexões pela wan destinadas a rede 27 e vai encaminhar via interface LAN para a rede interna dele. Lembra que a WAN do opnsense vem sem regra de liberação nenhuma, então vai ser necessário cria ao menos uma para autorizar a rede .18 chegar na rede .27.

O melhor a se fazer para você que está iniciando, e minimizar a complexidade, seria com que a ONT seja a WAN do opnsense, e que todos os seus outros aparelhos recebem a rede LAN do opnsense. assim todos os equipamentos internos estarão na rede 192.168.27.0/24 e você nem precisa se preocupar com rota.

- ahh mas eu quero segmentar a rede... então compra um appliance certinho, faz as vlans no switch e no firewall e seja feliz.
- ahh mas meu firewall tá virtualizado: segue a mesma lógica - faz as vlans no switch e no firewall sendo que o firewall que vai tá conectado no swich e não mais a ONT. a ONT só vai estar conectada na porta WAN do firewall.

INTERNET <--> ONT <--> PROXMOX/WAN-OPNSENSE <-->PROXMOX/LAN-OPNSENSE<-->SWITCH DA REDE/WIFI.

Thanks for this script.
Question related to the "In all firewall rules or RDR (nat) must be a comment." requirement: comment means a the "Description" field in pfSense UI?
Why is this requirement imposed?

Hi Robi,
Yes, you need to set a description for each pfSense firewall/NAT rule.
This is a limitation I introduced to help identify already imported rules and avoid duplicates.

If an error occurs during the import process, you have the opportunity to correct it and re-import, skipping the rules that were already successfully imported.

Hi jojothehumanmonkey,

[  ] Are you using certificates to authenticate users in this openvpn profile?
[  ] Did you checked the option "Username as CN"?
[  ] Does the term "Donald" matches the user certificate common name (case sensitive)?
[  ] In the field common name on screen Client Specific Overrides, have you verified any leading white space?

it's not mandatory a "real" dns name for certificate common name for this purpose. in doubt use the internal dns name like fw01.doe.it.
but keep in mind: the name you insert there gonna be displayed in the connection status.

Can you expand the log selection for what's surrounding the line:

Code Select Expand


2024-12-12T09:11:33 Error monit 'New_Firewall_Access_Detected' content match:


Also, make sure there's a firewall rule in LAN interface, on top of the list, allowing the lan subnet (source) to the modem address (destination), without force any gateway or gateway group - just leave default.

Please, note, in the condition field, just put

Code Select Expand


content = "Successful login for user"


the "if" is not needed.

Can you print or copy+paste the configuration? in special the service test match line.

or the raw configuration file at /usr/local/etc/monitrc.

Hi deanfourie,

these instructions were taken from https://forum.opnsense.org/index.php?topic=43771.msg218097#msg218097 (pt-br).


2. CONFIGURE TO ALERT ON NEW SSH AND WebGUI LOGIN

2.1. Create the test New_Login_SSH

Access the Service Tests Settings screen.
Click Add a new Test.
Fill in the name with New_Login_SSH.
Set the condition to: content = "Accepted .* ssh2"
Select the action as: Alert.
Click Save.


2.2. Create the test New_Login_WebGui

Access the Service Tests Settings screen.
Click Add a new Test.
Fill in the name with New_Login_WebGui.
Set the condition to: content = "Successful login for user"
Select the action as: Alert.
Click Save.


2.3. Create the Service New_Firewall_Access_Detected

Access the Service Settings screen.
Click Add a new Service.
Check the box: Enable Service Checks.
Fill in the name with: New_Firewall_Access_Detected.
Set the Type to: File.
Set the path to: /var/log/audit/latest.log.
Select the tests created earlier: New_Login_SSH and New_Login_WebGui.
Fill in the description: Notifies new logins on the firewall (ssh/webgui).
Click Save.


hope it helps.

Hi TrickyD,

The message indicating that "TLS negotiation failed to occur within the connection time" means the client/PC was unable to reach the OpenVPN service running on OPNsense.

I'm assuming you've already followed the official documentation at https://docs.opnsense.org/manual/how-tos/sslvpn_client.html.

For troubleshooting, please try the following:

- Verify that the Windows client is connecting from a WAN network (i.e., dialing in from outside your local network). You can simulate this by sharing your mobile broadband connection with your laptop.

- Based on the attached logs, I see the Windows 11 client is trying to connect to the address 192.168.3.16, which is an internal address. When exporting the profile (Client Export), ensure you set the hostname to your internet-routable address (e.g., your WAN IP if your firewall has a public IP, or the public IP of your modem if your firewall is behind it).

- Have you created a firewall rule on your WAN interface to allow incoming connections on port 1401/udp?

- If your OPNsense WAN interface is behind a routed modem (not a bridge modem), have you configured your ISP modem to forward all ports (or at least port 1401) to your firewall's WAN IP address?

- Can you open and redirect other ports on your firewall? To test, try connecting on a closed port and check the live logs for any activity. Avoid testing port 1401, as it uses UDP/TLS and will not respond unless the correct encryption key is provided.

The setup works flawlessly in most cases, so it's likely something unusual in your configuration.

======================================================
===              OPNSENSE - SOBREVIVENDO NA LINHA DE COMANDOS                 ===
======            1 Temporada: EP VI - Sorria, você está sendo filmado! ;D
===========                      ÚLTIMO EPISÓDIO                 ===============                 
===========                                                                           ===========
======================================================
Responsável: ludarkstar99
Data: 11/12/2024
Versão: 1.0
======================================================



INTRODUÇÃO

Certa vez fui atender a um chamado urgente pois o servidor do cliente havia parado de funcionar na rede.
Logo notei algo de estranho, o servidor estava meio "diferente"... estava infectado! você talvez pergunte, por gripe suína? não meu amigo... um de nossos analistas havia sido atarefado de proativamente limpar o servidor, e na sua ingenuidade baixou uma ferramenta para limpar arquivos temporários no servidor. Me pergunta como eu sei! Ele nao quis falar. Eu tive que puxar pelos logs do windows e vi que 10:30 começaram a instalar drivers com nomes estranho no sistema. Se alguém baixou alguma coisa, ou veio do USB , ou da rede ou veio da internet. Acho que nunca tive tanto orgulho de ter instalado um proxy para um cliente. Dito e feito, lá estava a URL que levou ao download (dica: application/octet-stream) do programa. E se parar pra analisar, o analista não tinha muita chance mesmo, a url era muito parecida com a original. Mas fato é, deu pra correlacionar o horário de instalação dos drivers, com o logon desse analista, com o download do arquivo. Parece até as ruas de Londres, uma câmera em cada esquina (um pub também :D).
Mas pode ficar tranquilo, apesar de eu querer o sangue ainda quente deste colega, meu chefe da época me ensinou uma grande lição. Ele estava fazendo o trabalho dele, e eu fazendo o meu (muito bem por sinal - palavras dele...). É engraçado como a vida ensina, bem diferente de uma sala de aula. Eu achava que aprenderia cálculos de excel com um engenheiro aposentado, acabei aprendendo sobre pessoas no ambiente de trabalho.


THE BIG BROTHER IS WATCHING YOU
Privacidade e monitoramento são como yin e yang. É engraçado essa relação. Se você está doente, precisa ser monitorado para diagnóstico, entretanto o hospital passa a ter seus dados, como tipo sanguíneo, e possivelmente substâncias encontradas no seu sangue (não que isso seja um problema, não é??). Nem precisa ir tão longe, para que o U.S. neutralize uma ameaça terrorista antes dela entrar em ação, precisa monitorar seus próprios moradores. Edward Snowden curtiu esse post \:-)
Quer navegar https para não ter sua senha vazada? Então tá, me diz como vamos detectar um malware nesse teu joguinho do facebook... Não tem resposta fácil. Mas a solução é monitorar... ah! e nisso a tecnologia é muito boa. Você ainda acha normal aparecer aquela propaganda de neusaudina bem no dia em que você está com dor de cabeça? Tenho uma notícia para você.


DIGA-ME ONDE LÓGAS, E EU LHE DIREI QUEM TU ÉS
Sei que talvez você chegou até aqui querendo saber como monitorar tudo que o usuário faz, para poder provar para a ANPD que o problema não é seu. E nós sabemos que não é. Mas calma lá, você que está trabalhando com tecnologia precisa entender que nem todo herói usa capa, as vezes ele só sai de madrugada para comprar sorvete pra esposa, e que ao trabalhar com open source, você vai ter que sujar um pouco a roupa.
Imagina o seguinte: Você se levantou da mesa para ir almoçar e esqueceu o computador ligado. No outro dia é chamado no RH para explicar porque enviou uma foto do neg@0 da pic0na para o diretor da companhia. (eu nunca fiz, te sugiro também não fazer). E você não tem como provar pois tudo aponta que foi você! O computador é o que você usa, o e-mail usado no disparo também foi o seu, o login do computador também foi o seu... E aí josé? Pois é. É nesses momentos que o registro de atividades pode auxiliar. Nesse caso é muito difícil  provar que não foi você, mas se buscar a hora do disparo do e-mail, com as imagens da câmera de segurança, bam! vai dar pra ver que não era você usando seu computador. A Câmera de segurança pode ser entendida como um registro de atividades.
Para ser mais exato, damos o nome de "registro de eventos", e é isso mesmo que quer dizer. Eventos são ocorrências de interações, e precisamos guardar o resultado dessas interações. Se um usuário interagiu com o formulário de login do sistema, é bom que nós saibamos, pois caso contrário se for uma tentativa de acesso indevida que vai tentar 300 vezes a senha até encontrar uma válida, nós não teremos registro e não iremos nem ficar sabendo, e nem ter como explicar. Nos anos 90 se você não "pegasse o hacker", estava tudo bem, era porque "o hacker" era habilidoso. Hoje em dia se você não ver a ameaça chegando, você é motivo de chacota pelos colegas de profissão (lembre-se, pimenta no -rabo- olho dos outros, é refresco!). Já dizia a filósofa pitty - quem não tem teto de vidro que atire a primeira pedra!


QUE HAJA LOGS!
E o que o Firewall OPNsense é capaz de registrar nos registros de eventos? Para todo efeito, iremos chamar a partir de agora somente de "logs" estes registros de eventos.
Pois bem, como qualquer sistema operacional que se preze, junto de suas aplicações, muitas das interações que ocorrem no sistema são registradas, como: login de um usuário no shell remoto (ssh), um device obteve um endereço IP emprestado do DHCP, um usuário se autenticou no Captive Portal, ou na VPN. Esses são alguns dos tipos de eventos registrados pelo OPNsense. Mas... como?
Eu sei... Eu sei... você sabe! quando precisa contar com eles, ele sempre está lá, na tela de "logs" de cada módulo. SE você precisa ver os logs do DHCP, vai no menu DHCP > Logs. Se precisa ver os logs de quem acessou a WebGui, vai em System > Log Files > Audit. Mas, e como o log vai parar lá? Tem um duende dentro do firewall??
talvez até tenha, nós vamos achar ele juntos!


"NA MINHA ÉPOCA ERÃO TÃO MAIS DIFÍCIL..." - vovô
Já parou pra se perguntar, como um programa gera um Log? Além do mais, como cada log vai parar no arquivo certinho? Indo mais além, como os logs são rotacionados diariamente e mantidos apenas os últimos 31 dias de logs (diferente de nosso primo pfSense, em que tínhamos que calcular a raiz quadrada de cosseno, para dizer quantos dias de logs seriam mantidos). E ainda subo mais um nível: como é enviado o log para um SIEM (ou um simples servidor syslog, já quebra o galho).

Para entender melhor vamos usar um programa simples de exemplo - o "logger". Não precisa se assustar, não é nenhum termo de desenvolvedor. é um programa de linha de comandos que só tem uma utilidade, gerar uma linha de log no sistema. Para usá-lo simplesmente chamamos o programa e passamos a mensagem que queremos registrar.

Code Select Expand

logger "oi, eu sou o goku"

Tá, mas e onde foi parar a mensagem?

Code Select Expand

# podemos ver nas últimas linha gravadas no log geral de sistema
# `date +"%Y%m%d"` é para pegar o arquivo com a data atual no pedaço do nome
tail /var/log/system/system_`date +"%Y%m%d"`.log

[...]
<13>1 2024-12-10T00:44:13-03:00 fwunder.citrait.local luciano 91722 - [meta sequenceId="1"] oi eu sou o goku

O log foi gerado e foi salvo. Mas, como saiu da linha de comandos e foi parar no arquivo?
Pois bem, aqui vamos entrar em mais um nível. Para quem assistiu o filme do leonardo dicaprio, inception, sabe que pode sentir náuses a qualquer momento. vamos, pois tem que ter aventura, certo?!

Iremos fazer os seguinte, vamos jogar o programa "logger" embaixo dágua, de forma que qualquer movimento que ele faça, possamos capturar em camera lenta e analisar. A analogia foi bem ruinzinha, mas acho que deu pra entender que vamos analisar o que o programa "logger" faz minuciosamente, quase uma engenharia reversa.

Code Select Expand

# truss é como o strace do linux, ele intercepta as syscalls para que possamos analisar.
# -af mostra detalhes das chamadas, -s 100 mostra até 100 caracteres de strings passadas como argumentos de funções.
truss -af -s 100 logger "oi eu sou o goku"

[...]
open("/lib/libcap_syslog.so.1",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
[...]
connect(4,{ AF_UNIX "/var/run/log" },106) = 0 (0x0)
sendto(4,"<13>1 2024-12-10T01:08:48.538926-03:00 fwunder.citrait.local luciano 83921 - - oi eu sou o goku"....
[...]

Agora em posse de uma lupa, podemos claramente ver o que acontece: o logger está importando uma biblioteca chamada syslog, e logo então abre uma conexão com um dispositivo de rede (um socket no filesystem local/AF_UNIX) e logo em seguida envia o texto do log para este socket. sockets no sistema operacional são como conexões de rede. se forem usados no filesystem local, indica que haverá uma comunicação entre processos. Logo se o "logger" está em uma ponta, deve haver outro programa/processo em outra ponta esperando a mensagem chegar.

Pois bem, lembra que comentei sobre o logger importar a biblioteca syslog. isso quer dizer algo. Syslog é um subsistema de logs. Foi desenvolvido para padronizar a bagunça que era antigamente. Imagina um servidor rodando 50 processos servidores (daemons) e todos eles competindo para gravar registro de eventos. É como ter 1 orelhao na cidade e 50 pessoas na fila querendo usar. Se for interior então, dá até briga de faca!

No OPNsense esse sistema de syslog é feito por um programa chamado syslog-ng, e sua configuração fica na pasta /usr/local/etc:

Code Select Expand

root@fwunder:/var/log # ls /usr/local/etc/syslog-ng
syslog-ng.conf         syslog-ng.conf.d/      syslog-ng.conf.dist    syslog-ng.conf.sample  syslog-ng/

E olhando de perto o arquivo syslog-ng.conf, podemos ver que ele define um socket unix justamente no caminho /var/run/log, que foi onde o logger estava gravando a linha de texto.

Code Select Expand

source s_all {
    internal();
    file("/dev/klog" follow-freq(0) flags(no-parse) program-override("kernel"));
    unix-dgram("/var/run/log" flags(syslog-protocol));
[...]


Maravilha! saímos do logger, entramos no syslog pelo arquivo/socket /var/run/log, mas e como fomos parar no arquivo system.log?
Já estamos chegando lá.
Para essa pergunta, vamos encontrar a resposta em outro arquivo de configuração do syslog-ng, que é o /usr/local/etc/syslog-ng.conf.d/syslog-ng-local.conf.

Code Select Expand

destination d_local_system {
    file(
        "/var/log/system/system_${YEAR}${MONTH}${DAY}.log"
        create-dirs(yes)
        flags(syslog-protocol)
    );
};

Agora ficou claro, que o próprio syslog-ng se encarrega de encaminhar alguns logs para o arquivo /var/log/system/system_$ano$mes$dia.log. Mas, só pra não ficar aquela dúvida... qual é mesmo a instrução que faz isso?

Code Select Expand

################################################################################
# not captured elsewhere, but relevant, send to system[__].log
################################################################################
filter f_local_system {
    not filter(f_local_wireless) and not filter(f_local_wireguard) and not filter(f_local_vpn) and not filter(f_local_suricata) and not filter(f_local_routing) and not filter(f_local_resolver) and not filter(f_local_ppps) and not filter(f_local_portalauth) and not filter(f_local_pkg) and not filter(f_local_openvpn) and not filter(f_local_ntpd) and not filter(f_local_monit) and not filter(f_local_lighttpd) and not filter(f_local_kea) and not filter(f_local_ipsec) and not filter(f_local_gateways) and not filter(f_local_firewall) and not filter(f_local_filter) and not filter(f_local_dnsmasq) and not filter(f_local_dhcrelay) and not filter(f_local_dhcpd) and not filter(f_local_configd) and not filter(f_local_audit) and not filter(f_local_squid_access)
    and level(notice..emerg)
};

destination d_local_system {
    file(
        "/var/log/system/system_${YEAR}${MONTH}${DAY}.log"
        create-dirs(yes)
        flags(syslog-protocol)
    );
};

log {
    source(s_all);
    filter(f_local_system);
    destination(d_local_system);
};

"not captured elsewhere, but relevant, send to system[__].log"
A linha log no final basicamente diz que de todas as mensagens de entrada no syslog (source s_all), será feito um filtro (filter f_local_system) em que aquilo que não corresponder com serviços conhecidos, vai se enquadrar como log de sistema e salvo no destination d_local_system. pronto. espero que não tenha ficado nenhuma dúvida. Se você entendeu até aqui, coletar logs de switches, roteadores, firewalls e até mesmo sistemas linux se torna trivial. Talvez você só precise alterar o padrão de 31 dias de logs do opnsense para 60... ou talvez queira implementar uma solução SIEM trabahando em conjunto com o OPNsense, e então esse tipo de informação se torna relevante para um engenheiro de detecção - nome bunito para quem aprendeu usar expressão regular em correlação de eventos. don't get me wrong, just kidding ;D


Vamos desmistificar outra coisa importante também, observe o formato em que a mensagem é enviada para o syslog, há um prefixo com uns números esquisitos e uma data/hora.

Code Select Expand

<13>1 2024-12-10T01:08:48.538926-03:00 fwunder.citrait.local luciano 83921 - - oi eu sou o goku

o que seria então esse prefixo? Qual a utilidade dele?
Pois bem, é um padrão e você pode ler na integra essa informação nas RFCs 3164 (mais antiga, tenta explicar a bagunça que era o syslog em que cada um fazia de um jeito), e a RFC 5424, com um padrão mais robusto na formatação das mensagens.

Por partes:

<13> := é a prioridade, mas é um valor composto. A fórmula é: Categoria do log * 8 + importância. ex.: (kernel * 8 + emerg). Ok, o cálculo parece estranho, mas emergencia e kernel na mesma frase é sinônimo de que algo está a ponto de explodir, diferente da combinação e-mail + audit.

1 := é a versão do formato syslog usado.

2024-12-10T01:08:48.538926-03:00 := é o carimbo de data/hora com informação de timezone.

fwunder.citrait.local := é o hostname do sistema.

luciano := é o progama que gerou o log. nesse caso foi gerado manualmente, então o logger botou meu nome mesmo.

83921 := é o PID do processo que gerou o evento.

- := é o ID da mensagem omitido.

"oi eu sou o goku" := é a mensagem que foi registrada pelo evento.

 
Mais uma para terminar (apenas em teste):
Habilite o repositório FreeBSD no OPNsense, e instale o pacote logstash.
Configure o pipeline do logstash como abaixo:

Code Select Expand

input {
  file {
    path => "/var/log/filter/latest.log"
  }
}
filter {
   grok {
     match => {"message" => "%{WORD:protocol},%{NUMBER:length},%{IPV4:source},%{IPV4:destination},%{NUMBER:srcport},%{NUMBER:dstport}"}
   }
}
output {
    stdout {
        codec => rubydebug
    }
}

e então execute o logstash que irá monitorar os logs do filtro de pacotes...

Code Select Expand

/usr/local/logstash/bin/logstash

[...]
{
   "protocol" => "udp",
   "@version" => "1",
"source" => "10.141.65.73",
 "@timestamp" => 2024-12-11T04:14:47.810Z,
   "host" => "utm.citrait.corp",
"dstport" => "53",
"srcport" => "1231",
"length" => "328",
   "path" => "/var/log/filter/latest.log",
"message" => "<134>1 2024-12-11T01:10:56-03:00 utm.citrait.corp filterlog 45031 - [meta sequenceId=\"4\"] 70,,,fae559338f65e11c53669fc3642c93c2,hn1,match,pass,out,4,0x10,,128,6421,0,none,17,udp,328,10.141.65.73,1.1.1.1,1231,53,308",
"destination" => "1.1.1.1"
}


E agora, que tal configurar os logs do squid irem parar no SIEM ao invés de flat text files?


CONCLUSÃO

Certa vez um sabio estava na estrada e acabou parando numa fazenda para pedir água. Viu uma família pobre, e perguntou o que eles faziam para sobreviver. "Vivemos do leite de nossa única vaca", respondeu o pai mostrando a família de 5 pessoas. O sábio foi embora, pensativo. Alguns anos depois, o mesmo sábio estava passando pela mesma estrada e se lembrou da família pobre. Resolveu procurar a casinha simples, mas havia uma grande casa com muito gado em volta. Querendo saber o trágico fim da família, foi até a casa e perguntou o que havia ocorrido com a família que morava alí. Foi surpreendido com a resposta: "Ainda somos os donos daqui. Depois que nossa única fonte de renda, que era a vaquinha, morreu, tivemos que nos virar e passamos a trabalhar fora e a ganhar dinheiro". 



That's all folks.

Hi janiswolf.
you can publish different external ports with NAT.

external_address:1066 --> internal_nas1:6690
external_address:1090 --> internal_nas2:6690

Hoje mesmo tive um colega com este problema.
Ele tinha uma vpn com outra unidade, daí passei o IP do site da receita através deste túnel vpn o acesso a este site em específico sair pela matriz, e foi só sucesso.

Hi yannickx,
Have you setup gateway monitoring?
The default gateway switching should be seamless.

https://docs.opnsense.org/manual/how-tos/multiwan.html