- Portspoof faz com que todas as 65535 portas TCP pareçam abertas e emula assinaturas de serviço, transformando a fase de reconhecimento do atacante de uma varredura rápida em uma tarefa longa e cara
- Retorna
SYN+ACK para toda tentativa de conexão e usa mais de 9000 assinaturas dinâmicas de serviço baseadas em regex para que cada porta responda como um serviço legítimo diferente
- Atribui na inicialização modos mistos de entrega por porta, como banner imediato, resposta atrasada e manutenção sem resposta, e adiciona jitter ao tempo de retenção da conexão para dificultar a filtragem baseada em timing
- Na configuração padrão de tarpit, uma varredura completa de versões com
nmap -sV -p- pode levar mais de 10 horas e gerar centenas de MB de dados falsos, consumindo o tempo e as threads do scanner do atacante
- A implementação usa um loop de eventos
epoll de thread única, roda em espaço de usuário sem privilégios de root e vincula apenas uma porta TCP por instância em execução
O problema que o Portspoof quer resolver
- O objetivo do Portspoof é tornar o reconhecimento do atacante lento, caro e pouco confiável
- Em vez de um scan típico de 5 segundos mapear os serviços reais do sistema, diante do Portspoof todas as 65535 portas parecem abertas
- Cada porta parece ser um serviço legítimo diferente, e o sistema foi projetado para que não haja uma forma rápida de distinguir quais portas correspondem a serviços reais
Recursos principais
-
Responde como se as 65535 portas TCP estivessem abertas
- Em vez de indicar que uma porta está
CLOSED ou FILTERED, retorna SYN+ACK para toda tentativa de conexão
-
Emulação de serviço
- Usa mais de 9000 assinaturas dinâmicas de serviço baseadas em regex
- Cada porta responde às sondas do scanner com uma identidade de serviço diferente e convincente
-
Modos mistos de entrega
- Cada porta recebe um perfil de comportamento diferente na inicialização
- Há uma mistura de envio imediato de banner, resposta atrasada e modo sem resposta
- Os tempos de retenção se distribuem por uma faixa ampla, fazendo com que a detecção de versão em toda a faixa com
nmap -sV -p- ultrapasse os limites práticos
-
Defesa agressiva
- Pode ser usado como “Exploitation Framework Frontend”, mirando vulnerabilidades do próprio conjunto de ferramentas de scanning do atacante
-
Modelo de execução leve
- Roda em espaço de usuário
- Não requer privilégios de root
- Vincula apenas uma porta TCP por instância em execução
- O uso de CPU e memória é baixo
Como confunde scanners e detecção de versão
- Em scans simples de portas, até mesmo uma faixa pequena como portas 1~20 aparece toda como
open
- Na saída de exemplo, aparecem misturados nomes de serviços como
tcpmux, compressnet, echo, daytime e ftp-data
- Em scans de detecção de versão, retorna assinaturas dinâmicas válidas para as sondas de serviço
- No exemplo das portas 1~100, aparecem vários serviços e strings de versão como
irc, http, pop3, ssh, ftp, smtp, telnet e tor-control
- Como resultado, fica difícil para o atacante determinar quais números de porta o sistema realmente usa
- Uma varredura completa de versões com
nmap -sV -p- leva mais de 10 horas na configuração padrão de tarpit e gera centenas de MB de dados falsos
- O scanner desperdiça tempo e threads em conexões que não levam a resultados reais
Abordagem de design: tarpit epoll de thread única
- Serviços reais como SSH, SMTP, FTP e HTTP enviam banner, mantêm a conexão aberta e aguardam entrada do cliente
- Uma emulação convincente também precisa seguir o fluxo accept, send, hold da mesma forma
- Um modelo com uma thread por cliente consome memória e CPU e, por causa do custo de troca de contexto, pode fazer o defensor esgotar recursos antes
- O Portspoof usa um loop de eventos
epoll de thread única
- Cada porta recebe um modo de entrega na inicialização
- Algumas portas enviam banner imediatamente, algumas respondem após dados do cliente e algumas ficam em silêncio
- Os tempos de retenção se distribuem por várias ordens de grandeza, de dezenas de milissegundos a minutos
- Há jitter por conexão, então mesmo repetindo a sondagem na mesma porta o timing não retorna igual
- Isso dificulta ataques que enviam dados inúteis a todas as portas e medem o tempo de resposta
- Um tarpit simples pode segurar a conexão por alguns segundos, enquanto um serviço real tende a fechar rapidamente diante de um protocolo incorreto
- Com modos mistos e ampla dispersão de timing, milhares de portas falsas também se fecham em faixas parecidas com as de serviços reais
- Deixa de existir um limiar limpo para filtragem
Assimetria de custo
- O custo para o defensor é de cerca de 1~2KB de memória de kernel por conexão ociosa
- O loop
epoll é de thread única, então não há overhead de troca de contexto
- Até hardware comum consegue suportar mais de 10 mil conexões simultâneas
- O custo para o atacante é deslocado para tempo e esforço
- Apenas o port scan faz com que todas as portas pareçam abertas, então é difícil obter informação útil
- Para encontrar serviços reais, é necessário fazer detecção de versão nas 65535 portas e também sondagem em nível de protocolo nos alvos plausíveis
- Um scan de 5 segundos se transforma em mais de 10 horas de trabalho ativo, e o resultado ainda continua parecendo um palheiro
Mudanças da v2.0
- A v2.0 abandona a abordagem antiga de enviar banner e depois encerrar a conexão
- A abordagem anterior era vulnerável ao bypass de encerramento de conexão discutido no post de blog de Vicarius/Hored1971
- O novo mecanismo de tarpit mantém todas as conexões abertas com timing misto
- O objetivo dessa abordagem é impedir filtragem por encerramento de conexão, fingerprinting por timing, análise de banner e modelagem estatística de padrões
Instalação e configuração básica
- O build requer um compilador C++ e CMake 3.10+
- O procedimento de build a partir do código-fonte é o seguinte
mkdir build && cd build
cmake -DCMAKE_INSTALL_SYSCONFDIR=/etc ..
make
sudo make install
- O Portspoof roda em espaço de usuário, mas para interceptar o tráfego destinado a outras portas são necessárias regras de firewall do sistema
- A porta padrão é 4444, e as portas de serviços reais devem ser excluídas primeiro; depois, o tráfego TCP restante é redirecionado para o Portspoof
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j RETURN
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 4444
eth0 deve ser trocado pela interface de rede real- É preciso adicionar uma regra
RETURN para cada porta em que haja um serviço real em execução
- Para persistência, é possível salvar as regras do iptables ou usar
iptables-config no diretório system_files
- Para scripts de inicialização, é possível usar o exemplo em
system_files/init.d/
Modos de execução
- O modo de emulação de serviço é o modo recomendado
- Ele gera e entrega assinaturas falsas de serviço para scanners de porta
portspoof -c /etc/portspoof.conf -s /etc/portspoof_signatures -D
- Timings personalizados de tarpit podem ser definidos com
-t e -T
- O exemplo mantém cada conexão aberta por 10 a 60 segundos
portspoof -s /etc/portspoof_signatures -t 10 -T 60 -D
- O Open Port Mode retorna apenas o estado
OPEN para toda tentativa de conexão, sem banners de serviço
- As conexões continuam sendo tratadas pelo tarpit
portspoof -D
- O Fuzzing Mode pode ser usado para enviar payloads aleatórios ou baseados em wordlist para ferramentas de scanning
portspoof -1 -v
portspoof -f payloads.txt -v
Reforço com base em iptables
- Funciona mesmo só com a regra básica
REDIRECT, mas scanners agressivos podem pressionar o Portspoof pelo número de conexões
- Regras de reforço adicionam limitação de taxa e bloqueio automático
- Portas de serviços reais são excluídas do redirecionamento
- No exemplo, a porta SSH 22 é excluída
- A regra de bloqueio global também se aplica aos serviços reais
- O exemplo de regras inclui os seguintes elementos
- Permitir loopback
- Descartar por 60 segundos IPs marcados como
PORTSCAN
- Descartar novos SYN por IP de origem acima de 10 por segundo, com burst de 30
- Se um único IP mantiver mais de 100 conexões com a porta 4444 do Portspoof, ele é marcado e depois descartado
- Permitir tráfego established/related e novos SYN, descartando o restante
- Em implantações de alto tráfego, o tamanho da lista
xt_recent pode ser aumentado
echo "options xt_recent ip_list_tot=10000" > /etc/modprobe.d/xt_recent.conf
- Também é possível ajustar configurações de rastreamento de conexão do kernel e de backlog
sysctl -w net.netfilter.nf_conntrack_max=131072
sysctl -w net.core.somaxconn=4096
Portspoof Pro
- Portspoof Pro expande a deception do nível de um único host para o nível de rede inteira
- Um único sensor emula uma rede
/16 inteira
- Oferece milhares de IPs
- Cada IP tem serviços únicos em todas as portas
- Mantém diálogos com estado em várias etapas
- Fornece recursos de deception em toda a rede
- Converte espaço de IP escuro e sub-redes não utilizadas em uma grade ativa de deception
- Cada host emulado apresenta serviços únicos com personalidades diferentes por IP de origem
- O tarpit ativo esgota o pool de sockets do atacante e aplica throttling às ferramentas automatizadas
- Suporta detecção de scan e fingerprinting de ferramentas
- Detecta técnicas de scan SYN, FIN, NULL, XMAS e ACK
- Faz fingerprinting de Nmap, Masscan, ZMap e scanners personalizados
- Envia telemetria JSON estruturada para SIEM com mapeamento MITRE ATT&CK incluído
- Foi pensado para implantação em ambientes operacionais
- Roda em um ambiente sandbox ao lado do tráfego de produção
- Políticas de roteamento enviam o tráfego de deception ao sensor
- Informa que não há tap inline nem risco para workloads reais
- Dá suporte a NIS2, DORA, ISO 27001, NIST CSF e CIS Controls
Licença e relato de problemas
- O Portspoof usa a licença GNU GPLv2
- Para aplicações comerciais e legais, orienta entrar em contato com o autor para discutir o licenciamento apropriado
- Bugs e solicitações de recursos podem ser reportados no GitHub Issue Tracker ou por e-mail
1 comentários
Comentários do Hacker News
Existem 65.536 portas, e a porta 0 também é uma porta na qual alguns sistemas operacionais permitem expor serviços acessíveis pela internet.
E, se algum desenvolvedor do MariaDB estiver lendo isto, a configuração padrão de fazer o banco de dados escutar na porta 0 para impedir acesso pela internet, na prática, não impede o acesso ao DB pela internet em um número considerável de sistemas.
if (mysqld_port)significa “quandomysqld_porté diferente de 0”, e parece ser um comportamento presente pelo menos desde o MariaDB 5.5.A segurança de computadores parece fadada a continuar evoluindo para uma forma de defesa ativa como a descrita acima.
Quando se vê o quanto o sistema imunológico é complexo e em camadas, parece que um dia computadores ou redes também acabarão se parecendo com isso.
Um dia a TI será uma área suficientemente madura, mas esse dia ainda não é hoje.
Mas, se incluirmos esse aspecto, talvez surja um paralelo ainda mais preocupante.
Certa vez, para impedir spambots que coletavam e-mails, criei uma página web que gerava infinitos endereços de e-mail aleatórios: http://web.archive.org/web/20020610054821/http://www.sourtim...
Se eu rodar algo assim, alguém pode escanear minha máquina e me enviar dezenas de pedidos de bug bounty dizendo que estou executando “uma versão sabidamente vulnerável do X”.
Em meados dos anos 90 havia um produto de honeypot chamado CyberCop Sting, anterior ao Ballista, da Secure Networks.
O CyberCop Sting conseguia simular serviços TCP/UDP de várias implementações e, se minha memória não falha, também permitia configurar o comportamento da pilha TCP/IP para parecer diferentes sistemas operacionais. Para algo de quase 30 anos atrás, era uma funcionalidade bastante inovadora.
[1] https://theswissbay.ch/pdf/Gentoomen%20Library/Security/0321...
[2] https://news.ycombinator.com/item?id=26440139
Claro que parece algo que alguém teria feito, mas é meio surpreendente eu nunca ter pensado nisso antes; e mais surpreendente ainda estar ouvindo essa ideia pela primeira vez.
Fico pensando se isso não acabaria fazendo hackers ou bots olharem o servidor com mais atenção ou, no mínimo, gerando mais tráfego.
Imagino que a maioria dos script kiddies não esteja filtrando potenciais honeypots ou dispositivos desse tipo em suas ferramentas.
Mas, depois que se descobre que o host está ativo, a questão passa a ser quais portas atacar. Supondo que o custo de escanear ou atacar cada porta de cada servidor seja parecido, mesmo que você consiga distinguir portas falsificadas, é melhor procurar outra máquina com maior probabilidade de sucesso. Dá até para rodar o portspoof no 127.0.0.35 local e comparar dados de resposta ou diferenças de timing, mas o espaço de busca aumenta de repente algo como 5.000 vezes em relação às poucas portas normalmente abertas, e as portas de outros servidores podem parecer ter maior chance de sucesso.
A maioria das ferramentas não considera a situação em que todas as portas estão abertas e gerando falsos positivos. Em testes de intrusão isso é comum e faz perder tempo, mas eu não quero dar a um atacante mais motivos para olhar minha infraestrutura. Prefiro port knocking, que é quase o oposto disso.
Contra ataques amplos, ela precisaria ser implantada em dezenas de milhões de hosts para ter algum efeito, de modo que se tornasse impraticável para o atacante simplesmente encontrar e interagir só com honeypots. Se você estiver sofrendo um ataque direcionado, talvez consiga atrasar um pouco o invasor fazendo-o tentar explorar portas honeypot, mas, se estiver rodando um serviço vulnerável, no fim será comprometido. Além disso, se você for um fornecedor, pode acabar tendo que responder a questionários de segurança muito irritantes quando a equipe de segurança de um cliente em potencial fizer uma varredura.
Faço algo parecido no meu site. https://bini.wales retorna 200 para todos os endpoints e registra todas as tentativas, virando um honeypot razoável para ataques automatizados
Em geral, captura varreduras em massa atrás de plugins vulneráveis do WordPress ou backdoors deixados para trás. De forma semelhante, https://varun.ch/login imita um site WordPress com uma pequena reviravolta
Bom. Fico feliz que a palavra “honeypot” não tenha aparecido nenhuma vez
Uma vez herdei um honeypot “de verdade” e, ao verificar, vi que havia umas 30 portas abertas; literalmente falei em voz alta: “que lixo é esse?”
Deixa as portas abertas para empolgar script kiddies, fazendo-os achar que acessaram alguma coisa, mas na verdade não é nada. Um honeypot trancado, a essa altura, não parece muito um honeypot
Honeypots são usados para atrair e detectar atacantes, normalmente registrando suas ações e padrões para análise ou bloqueio. Seria bom se esta ferramenta tivesse mais logging além do iptables; por si só, ela não é um honeypot, mas a ideia não está muito distante. Só que a página do GitHub dizer que isso “aumenta a segurança do SO” não me convence nem um pouco. Ela até oferece um pouco de ofuscação contra scanners automáticos de serviços, mas, se um servidor MySQL está escutando na 3306 e o atacante se conecta à 3306, ele ainda está falando com o MySQL. Não importa se as outras 65534 portas respondem com lixo
Diz que “se vincula a apenas uma porta TCP por instância em execução”; fico curioso para saber como isso funciona
Para cobrir todas as portas, seria preciso executar 65535 instâncias?
Depois ele chama
getsockoptpara descobrir qual era a porta original: https://github.com/drk1wi/portspoof/blob/c3f3c34531c59df229e...Não conheço o limite rígido real nem o uso de memória, mas provavelmente o redirecionamento de portas é mais simples
Será que isso não poderia ser potencialmente um amplificador de DoS?
Enviando pacotes falsificados do jeito certo, daria para fazer muitos pacotes voltarem para a origem aparente?
Se fosse UDP, aí poderia virar uma coisa realmente absurda