HOWTO - Sobrevivendo na Linha de Comandos

[ludarkstar99]

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

[juliocbc]

ótimo resumo!

Se me permite acrescentar um:

Code: [Select]

pfctl -sa

Lista todas as regras em memóra, states, informações do pf, tables, etc. (ou seja, mostra tudo!)

[ludarkstar99]

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

[ludarkstar99]

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

[ludarkstar99]

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