Gerador de Porta Aleatória

Faixas IANA

• 0–1023: Well-known (HTTP 80, HTTPS 443, SSH 22…) — reservadas.
• 1024–49151: Registered — atribuídas a apps comuns.
• 49152–65535: Dynamic / Ephemeral — livre para uso temporário.

Escolhendo uma porta TCP/UDP: o que os números significam

Uma porta TCP ou UDP é um inteiro de 16 bits sem sinal — o campo no cabeçalho de transporte tem dois bytes, então valores válidos vão de 0 a 65535. A IANA divide esse espaço em três categorias administrativas. As portas well-known 0–1023 são reservadas para serviços de sistema e exigem privilégios de root ou administrador para bind em sistemas Unix-like: HTTP 80, HTTPS 443, SSH 22, SMTP 25, DNS 53, FTP 21, IMAP 993, POP3 110, Telnet 23. As portas registered 1024–49151 são alocadas pela IANA a aplicações específicas (PostgreSQL 5432, MySQL 3306, MongoDB 27017, Redis 6379, Tomcat 8080, etc.). A faixa dynamic / ephemeral 49152–65535 é destinada a sockets efêmeros do lado cliente quando um host abre uma conexão de saída.

Os sistemas operacionais discordam sobre a faixa ephemeral exata. O Linux usa por padrão 32768–60999 (configurável em /proc/sys/net/ipv4/ip_local_port_range); Windows e macOS/BSD seguem a recomendação da IANA, 49152–65535. A RFC 6056 descreve como os kernels devem randomizar a seleção de porta ephemeral para mitigar ataques TCP off-path como blind reset e sequestro de conexão — problema documentado no paper de Watson (2004) sobre injeção de TCP RST.

Portas perigosas que você nunca deve expor

Algumas portas são varridas constantemente por botnets: 22 (brute force SSH), 23 (Telnet deprecated, ainda comum em IoT), 3389 (RDP do Windows), 445 (SMB — vetor do WannaCry), 6379 (Redis vinha sem autenticação em versões antigas), 27017 (MongoDB ficou anos com "sem auth por padrão" até a 3.6), 5432 (PostgreSQL), 3306 (MySQL), 9200 (Elasticsearch), 11211 (memcached, usado como vetor de amplificação UDP). Nunca faça bind dessas portas em 0.0.0.0 em um host público — coloque atrás de VPN, túnel SSH ou ao menos uma regra de firewall com allow-list.

Por que sortear uma porta aleatória

Desenvolvimento local entra em conflito nos suspeitos de sempre: 3000 (Node.js), 5000 (Flask/AirPlay do macOS), 8000 (Django/http.server do Python), 8080 (Tomcat). Subir dezenas de microsserviços num mesmo laptop vira um tetris de "address already in use". Escolher uma porta aleatória acima de 1024 — idealmente acima de 10000 — elimina esses conflitos e é útil também para fixar uma porta estável para um sidecar de service mesh, uma porta SSH não-trivial, ou uma aplicação self-hosted sem registro na IANA.

Perguntas frequentes

Posso usar qualquer número de porta? A porta 0 é reservada (o kernel a usa como "qualquer porta disponível"), mas qualquer valor de 1 a 65535 é legal. No Linux/macOS/BSD você precisa de root para fazer bind abaixo de 1024; de 1024 em diante qualquer usuário comum pode escutar.

TCP e UDP compartilham os mesmos números de porta? Compartilham o espaço numérico mas vivem em namespaces independentes. Um processo pode fazer bind em TCP/8080 e UDP/8080 simultaneamente sem conflito — o kernel trata como sockets distintos.

Uma porta listening é única por máquina? Sim — um socket listening é identificado unicamente pela tupla (protocolo, IP local, porta local). Dois processos não podem fazer bind da mesma tripla a menos que habilitem explicitamente SO_REUSEPORT.

O gerador evita portas well-known? Sim, quando "Evitar portas reservadas (0–1023)" está marcado a saída fica restrita a ≥ 1024. Sem o checkbox, o sorteio pode cair em qualquer ponto da faixa pedida.