HTTP sem curl: como fazer requisições diretamente no Bash com /dev/tcp

Q: O /dev/tcp funciona em qualquer container com Bash?

Não. Depende de duas coisas: o Bash deve ter sido compilado com --enable-net-redirections (a maioria tem, mas Alpine Linux com bash-static às vezes desativa), e o kernel precisa permitir conexões de saída, o que pode ser bloqueado por seccomp ou capabilities como CAP_NET_CONNECT. Teste com exec 3<> /dev/tcp/google.com/80 && echo ok .

Q: Essa técnica é segura para uso em produção?

É segura como ferramenta de diagnóstico e health check, mas não como cliente HTTP genérico. Falta tratamento de erros, timeout robusto, certificação TLS e proteção contra injeção de cabeçalhos. Em produção, limite seu uso a scripts internos, com inputs validados e executados com permissões mínimas.

17 de junho de 2026

Aprofundamento CEVIU

Aprofundamento

O /dev/tcp não é um dispositivo real, é uma funcionalidade de redirecionamento embutida no Bash desde a versão 2.04, ativada em tempo de compilação com --enable-net-redirections. Ele faz DNS lookup e connect(2) por trás das cortinas, atribuindo um file descriptor (ex: exec 3<> /dev/tcp/api:8080) para leitura/escrita direta. Isso transforma o shell em um cliente TCP bruto, útil em containers Alpine ou scratch, mas sem parsing HTTP, sem TLS, sem retries e sem suporte a HTTP/2 ou chunked encoding.

Essa técnica aparece em cenários reais de DevOps: sidecars de health check sem curl, scripts de diagnóstico em init-containers do Kubernetes e até varreduras rápidas de portas em ambientes restritos. Mas atenção: ela também é usada em ataques, regras do Elastic Security (dez/2025) flagram processos que abrem /dev/tcp em background como possível reverse shell. Ou seja: é uma ferramenta de DX poderosa, mas que exige controle de contexto de execução e monitoramento de runtime.

O que mudou

A cobertura anterior do CEVIU sobre testes leves em shell (15/05) focava em validação estruturada com prove e TAP, ou seja, verificação *do que o script faz*. Agora, com /dev/tcp, o desenvolvedor passa a validar *o que o ambiente permite fazer*: conectividade de rede, resolução DNS, comportamento de servidores sob requisições manuais. É uma mudança de camada: de teste funcional para teste de infraestrutura nativo no shell.

Por que isso importa

Em times que adotam imagens scratch ou distros ultra-leves (como Distroless), instalar curl vira um trade-off entre segurança, tamanho e observabilidade. O /dev/tcp elimina essa escolha, sem aumentar a superfície de ataque nem o tamanho da imagem. Também impacta práticas de SRE: um health check feito com timeout 3 bash -c 'echo -e "GET /health HTTP/1.1\r\nHost: api\r\nConnection: close\r\n\r\n" > /dev/tcp/api:8080; cat <&3' roda em menos de 100ms e não depende de binários externos. Isso reduz falhas por dependência ausente e melhora a confiabilidade de pipelines de deploy em clusters com políticas rígidas de imutabilidade.

Linha do tempo

2026-05-15
CEVIU publica análise sobre prove e TAP para testes leves em shell
2026-06-17
Publicação da técnica de HTTP direto no Bash via /dev/tcp em containers minimalistas

Perguntas frequentes

O /dev/tcp funciona em qualquer container com Bash?

Não. Depende de duas coisas: o Bash deve ter sido compilado com --enable-net-redirections (a maioria tem, mas Alpine Linux com bash-static às vezes desativa), e o kernel precisa permitir conexões de saída, o que pode ser bloqueado por seccomp ou capabilities como CAP_NET_CONNECT. Teste com exec 3<> /dev/tcp/google.com/80 && echo ok.

Posso usar isso para HTTPS?

Não diretamente. /dev/tcp abre um socket TCP plano. Para HTTPS, você precisaria encadear com openssl s_client, o que já adiciona dependência. Se o objetivo é evitar curl, melhor usar uma imagem com openssl pré-instalado do que tentar reinventar TLS no shell.

Como evitar que o comando fique travado esperando resposta?

Sempre inclua 'Connection: close' no cabeçalho HTTP e use timeout. Exemplo seguro: timeout 5 bash -c 'echo -e "GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n" > /dev/tcp/example.com/80; cat <&3'. Sem timeout, o cat pode travar indefinidamente em servidores que ignoram Connection: close.

Essa técnica é segura para uso em produção?