01 - HELO (Identifica o Cliente)
video: https://youtu.be/... no frontmatter da nota.Comando HELO (Identifica o Cliente)
O comando HELO (e o seu sucessor moderno EHLO) representa o primeiro estágio ativo de comunicação entre o cliente SMTP e o servidor receptor, logo após o estabelecimento da conexão TCP. Este processo, tecnicamente conhecido como o Aperto de Mão (Handshake) do SMTP, é onde as identidades são apresentadas e as capacidades técnicas de ambos os lados são negociadas para o restante da sessão.
1. Fundamentos Técnicos e Evolução (HELO vs EHLO)
A evolução da identificação reflete o crescimento da complexidade da Internet e a necessidade de extensibilidade do protocolo original.
HELO (RFC 821, 1982)
O comando original era extremamente simples. O cliente enviava HELO seguido de seu nome de host. O servidor respondia apenas com um 250 OK. Não havia provisão para negociar recursos extras como segurança ou autenticação. Atualmente, o HELO é considerado um comando de compatibilidade retroativa e deve ser evitado em servidores modernos.
C: HELO mail.emissor.com
S: 250 mail.receptor.com Hello mail.emissor.com [203.0.113.5]
EHLO (Extended HELO - RFC 5321)
Introduzido com o SMTP Estendido (ESMTP), o comando EHLO mudou o paradigma da conexão de correio:
- O cliente se identifica:
EHLO mail.emissor.com. - O servidor responde com uma lista estruturada de capacidades suportadas (Extensions).
- O cliente agora sabe exatamente o que pode fazer (ex: autenticar, cifrar, enviar mensagens de 20MB).
C: EHLO mail.emissor.com
S: 250-mail.receptor.com Hello mail.emissor.com [203.0.113.5]
S: 250-SIZE 10485760
S: 250-PIPELINING
S: 250-STARTTLS
S: 250-AUTH LOGIN PLAIN
S: 250-8BITMIME
S: 250 HELP
2. A Negociação de Extensões ESMTP
Quando o cliente envia um EHLO, a resposta do servidor (código 250) funciona como uma vitrine de recursos protegidos pela IANA (registry "SMTP Service Extensions").
| Extensão | Função |
|---|---|
STARTTLS |
Indica que o servidor pode elevar a conexão para TLS |
SIZE [bytes] |
Informa o limite físico de uma mensagem única |
AUTH |
Lista os métodos de autenticação permitidos (LOGIN, PLAIN, CRAM-MD5) |
PIPELINING |
Permite ao cliente enviar vários comandos de uma vez |
8BITMIME |
Indica que o servidor pode processar caracteres de 8 bits |
DSN |
Delivery Status Notifications (notificações de entrega) |
SMTPUTF8 |
Suporte a endereços de e-mail com caracteres Unicode (RFC 6531) |
HELP |
Servidor oferece comando HELP para assistência |
3. Identificação e Validação: O Papel do DNS no Handshake
Para um administrador de redes ou profissional de Cyber Security, a identificação do cliente não é apenas uma formalidade, é um ponto de controle de segurança (Admission Control).
Validação de FQDN (Fully Qualified Domain Name)
O cliente deve usar o seu nome de domínio completo no comando EHLO. Servidores receptores realizam as seguintes verificações:
- Reverse DNS (PTR) Match: O servidor verifica se o endereço IP do cliente aponta para o mesmo nome de host declarado no
EHLO. Se não houver registro reverso, a mensagem é frequentemente marcada como SPAM. - FQDN Check: Recusar conexões que usam nomes inválidos (ex:
EHLO localhostouEHLO 192.168.1.1). - MX/SPF Validation: Verificar se o IP do cliente está autorizado pelo SPF do domínio declarado.
O Banimento de Clientes Precipitados (Pre-greeting Spam)
Uma técnica de segurança comum é observar o "timing" da identificação.
- O Ataque: Robôs de spam enviam o comando
HELOimediatamente, sem esperar o banner de saudação do servidor (código 220). - A Defesa: Servidores modernos implementam um pequeno atraso deliberado no banner (Postfix
smtpd_delay_reject). Se o cliente enviar qualquer dado antes de receber o banner (o chamado "Pre-greeting"), a conexão é cortada imediatamente, pois MTAs legítimos sempre esperam a palavra do servidor primeiro.
4. Cyber Security: Banner Grabbing e Enumeração
O banner de saudação que precede o EHLO é uma fonte rica de metadados para atacantes em fase de reconhecimento (Recon).
Anatomia do Banner (Código 220)
220 mail.empresa.com ESMTP Postfix (Ubuntu)
- Vulnerabilidade: Se o banner expõe a versão do software (
Postfix (Ubuntu)), o atacante pode procurar por CVEs específicas para essa versão. - Hardening: A recomendação de segurança é remover a versão e o nome e as capacidades do banner, apresentando apenas o FQDN do servidor:
220 mail.empresa.com ESMTP.
# No Postfix: main.cf
smtpd_banner = $myhostname ESMTP
# No Exim: exim4.conf
smtp_banner = $smtp_active_hostname ESMTP
5. Respostas de Erro no Handshake
Se as coisas derem errado durante a identificação, o SMTP utiliza códigos específicos:
| Código | Significado |
|---|---|
500 |
Syntax error, command unrecognized |
501 |
Syntax error in parameters (HELO sem hostname) |
502 |
Command not implemented (servidor não suporta EHLO) |
503 |
Bad sequence of commands |
504 |
Command parameter not implemented |
421 |
Service not available, closing transmission channel |
450 |
Mailbox temporarily unavailable (anti-spam greylisting) |
521 |
Host does not accept mail (RFC 7505 - null MX) |
O código 421 é frequentemente usado por defesas anti-spam (como o Greylisting) para desconectar o cliente suspeito temporariamente, sugerindo que ele tente novamente em alguns minutos.
6. Comparação HELO vs EHLO
| Característica | HELO (RFC 821) | EHLO (RFC 5321) |
|---|---|---|
| Ano | 1982 | 1995 (RFC 1869), 2008 (RFC 5321) |
| Negocia extensões | Não | Sim |
| Resposta | Apenas 250 OK |
Lista multilinha de 250-... |
| Status | Obsoleto/compatibilidade | Padrão moderno |
| Suporta STARTTLS | Não | Sim |
| Suporta AUTH | Não | Sim |
7. Diagnóstico e Auditoria em Cyber Labs
Como o Handshake é o primeiro passo, ele é o ponto ideal para testar a conectividade base e as políticas de criptografia.
Comando de Auditoria (OpenSSL)
# Testar o handshake EHLO em texto plano
echo -e "EHLO auditor.local\nQUIT" | nc -w5 mx.alvo.com 25
# Testar com TLS desde o inicio
openssl s_client -connect mx.alvo.com:465 -crlf
# Upgrade STARTTLS (porta 587)
openssl s_client -connect mx.alvo.com:587 -starttls smtp -crlf
# Usando swaks (Swiss Army Knife for SMTP)
swaks --to vítima@alvo.com --from auditor@auditoria.com \
--server mx.alvo.com --ehlo auditoria.com -q HELO
Este comando permite ao analista de segurança ver exatamente qual é a resposta do EHLO e diagnosticar problemas de certificados digitais ou suítes de cifra fracas durante a negociação de criptografia.
8. Considerações sobre Identidade Forjada
O comando EHLO é declarativo: o cliente informa quem ele é, mas o protocolo não obriga o servidor a validar essa afirmação. Por isso:
- A identidade do
EHLOé apenas uma "afirmação de intenção". - A validação real da identidade é feita por mecanismos externos:
- SPF (Sender Policy Framework): Confirma se o IP pode enviar pelo domínio.
- DKIM (DomainKeys Identified Mail): Assinatura criptográfica do e-mail.
- DMARC: Política que alinha SPF e DKIM com o domínio do cabeçalho From.
- Em ambientes internos corporativos, o IP do cliente é frequentemente usado como fator de reputação mais confiável que o nome declarado.
9. Conclusão da Identificação
A identificação correta com EHLO define o tom e as fronteiras técnicas para toda a sessão SMTP. É o momento em que o servidor estabelece as "regras do jogo". Sem uma identificação validada e robusta, os e-mails subsequentes correm o risco de serem descartados silenciosamente pelos motores de inteligência de reputação e filtros bayesianos que protegem as caixas de correio de bilhões de pessoas em todo o mundo.
| Atributo | Valor |
|---|---|
| Comando | HELO ou EHLO <hostname> |
| RFC | 821 (HELO), 5321 (EHLO/ESMTP) |
| Resposta Sucesso | 250 (ou 250- multiline) |
| Camada | Aplicação |
| Transporte | TCP porta 25 (relay), 587 (submission), 465 (SMTPS) |
| Estado Prévio | Após receber banner 220 |