Restrição de acesso do remetente do postfix - Violação de segurança?

2

Encontramos problemas de segurança com nosso servidor de e-mail e gostaríamos de receber alguns conselhos.

A história por trás disso

Em nosso servidor de e-mail (Postfix 2.9.6 + Dovecot 2.1.7), gostaríamos de poder criar contas de e-mail restritas. Essas contas (usadas pelos estagiários) seriam capazes de enviar / receber e-mails apenas para / dos domínios locais (por motivos de segurança, não queremos que eles possam enviar ou receber e-mails para outros servidores de e-mail). Para simplificar, criamos um subdomínio específico para as contas de e-mail restritas.

Na nossa infraestrutura, todas as contas de e-mail são baseadas em LDAP, os arquivos de configuração estão incluídos abaixo.

O que fizemos

No postfix, é possível criar regras de restrição no arquivo /etc/postfix/main.cf e, portanto, adicionamos regras:

check_sender_access ldap:/etc/postfix/ldap_restricted_senders.cf
check_recipient_access ldap:/etc/postfix/ldap_restricted_recipients.cf

para a seção:

smtpd_recipient_restrictions

Com certeza, as seguintes linhas também foram adicionadas:

smtpd_restriction_classes =
  local_only,
  insiders_only

local_only = check_recipient_access ldap:/etc/postfix/ldap_virtual_domains_restrict.cf, reject
insiders_only = check_sender_access ldap:/etc/postfix/ldap_virtual_domains_restrict.cf, reject

O conteúdo de /etc/postfix/ldap_restricted_senders.cf é:

bind = yes
bind_dn = uid=postfix,ou=service,dc=example,dc=com
bind_pw = *******
server_host = ldap://127.0.0.1:389
search_base = ou=domain,dc=example,dc=com
query_filter = (&(ObjectClass=DNSDomain)(dc=%s))
result_attribute = description

Isso retorna "ok" quando o domínio tem permissão para enviar e-mails para fora.

O conteúdo de /etc/postfix/ldap_restricted_recipients.cf é:

bind = yes
bind_dn = uid=postfix,ou=service,dc=example,dc=com
bind_pw = ******
server_host = ldap://127.0.0.1:389
search_base = ou=domain,dc=example,dc=com
query_filter = (&(description=local_only)(dc=%s))
result_attribute = description
result_filter = insiders_only

Isso retorna "insiders_only" quando o domínio pode ser alcançado apenas por domínios locais.

O conteúdo de /etc/postfix/ldap_virtual_domains_restrict.cf é:

bind = yes
bind_dn = uid=postfix,ou=service,dc=example,dc=com
bind_pw = ******
server_host = ldap://127.0.0.1:389
search_base = ou=domain,dc=example,dc=com
query_filter = (&(ObjectClass=dNSDomain)(dc=%s))
result_attribute = dc
result_filter = OK

Isso retorna "ok" quando o domínio é local (pode enviar e-mails para o subdomínio restrito).

Para mais precisão, a seção smtpd_recipient_restrictions do postfix contém:

smtpd_recipient_restrictions =
  permit_mynetworks,
  reject_sender_login_mismatch
  check_sender_access ldap:/etc/postfix/ldap_restricted_senders.cf
  check_recipient_access ldap:/etc/postfix/ldap_restricted_recipients.cf
  permit_sasl_authenticated,
  reject_non_fqdn_hostname,
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unauth_destination,
  reject_unauth_pipelining,
  reject_invalid_hostname,
  check_policy_service unix:private/policy-spf

Isso funciona bem no sentido de que todos os e-mails do subdomínio podem enviar e-mails apenas para outros domínios locais e só podem receber e-mails de domínios locais.

MAS ...

Desde que ativamos isso, notamos que as pessoas podem usar o servidor de e-mail para enviar SPAM (por isso, o removemos temporariamente).

Percebemos o problema porque o arquivo de log /var/log/mail.log continha linhas como:

Jul 22 11:59:24 mail postfix/qmgr[366]: F342F42AE4: from=<[email protected]>, size=2171, nrcpt=11 (queue active)
Jul 22 11:59:24 mail postfix/smtp[382]: 1344D42ACC: to=<iraci@*******>, relay=127.0.0.1[127.0.0.1]:10024, delay=1197348, delays=1197334/12/0.17/2.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as F342F42AE4)
Jul 22 11:59:24 mail postfix/smtp[382]: 1344D42ACC: to=<hugocesar_007@*******>, relay=127.0.0.1[127.0.0.1]:10024, delay=1197348, delays=1197334/12/0.17/2.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as F342F42AE4)
Jul 22 11:59:24 mail postfix/smtp[382]: 1344D42ACC: to=<reginadanielian@*******>, relay=127.0.0.1[127.0.0.1]:10024, delay=1197348, delays=1197334/12/0.17/2.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as F342F42AE4)
Jul 22 11:59:24 mail postfix/smtp[382]: 1344D42ACC: to=<thais_jp@*******>, relay=127.0.0.1[127.0.0.1]:10024, delay=1197348, delays=1197334/12/0.17/2.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as F342F42AE4)
Jul 22 11:59:24 mail postfix/smtp[382]: 1344D42ACC: to=<tropicalfmcomerciais@*******>, relay=127.0.0.1[127.0.0.1]:10024, delay=1197348, delays=1197334/12/0.17/2.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as F342F42AE4)
Jul 22 11:59:24 mail postfix/smtp[382]: 1344D42ACC: to=<valeria.x@*******>, relay=127.0.0.1[127.0.0.1]:10024, delay=1197348, delays=1197334/12/0.17/2.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as F342F42AE4)
Jul 22 11:59:24 mail postfix/smtp[382]: 1344D42ACC: to=<veloso1071@*******>, relay=127.0.0.1[127.0.0.1]:10024, delay=1197348, delays=1197334/12/0.17/2.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as F342F42AE4)
Jul 22 11:59:24 mail postfix/smtp[382]: 1344D42ACC: to=<termopiso@*******>, relay=127.0.0.1[127.0.0.1]:10024, delay=1197348, delays=1197334/12/0.17/2.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as F342F42AE4)
Jul 22 11:59:24 mail postfix/smtp[382]: 1344D42ACC: to=<rafaelpm84@*******>, relay=127.0.0.1[127.0.0.1]:10024, delay=1197348, delays=1197334/12/0.17/2.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as F342F42AE4)
Jul 22 11:59:24 mail postfix/smtp[382]: 1344D42ACC: to=<vanessyca@*******>, relay=127.0.0.1[127.0.0.1]:10024, delay=1197348, delays=1197334/12/0.17/2.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as F342F42AE4)
Jul 22 11:59:24 mail postfix/qmgr[366]: 1344D42ACC: removed

O que supomos

Como a restrição que configuramos corresponde apenas ao domínio (para o remetente), alguém estava usando nosso servidor como retransmitido com e-mails onde o remetente foi falsificado para corresponder a qualquer [email protected] e seria aceito.

Vamos alterar as configurações para que a regra corresponda a todo o email, mas não temos certeza de que isso impedirá o spoofing.

O que você acha disso? Nós fizemos algo errado? Existe outra maneira (ou funcionalidade) de ter tal restrição?

PS: Podemos postar mais informações, se necessário

    
por user301825 28.07.2015 / 16:45

2 respostas

3

As the restriction we setup matches only the domain (for the sender) someone was using our server as relay with with emails where sender was forged to match [email protected] and would so be accepted.

Sim, isso é causado por essa restrição em smtpd_recipient_restrictions

check_sender_access ldap:/etc/postfix/ldap_restricted_senders.cf

Você disse acima, esta consulta retornará "OK", quando o remetente puder enviar e-mails enviados. Isso significa que o postfix permitirá o email e contornará a restrição abaixo dele

  check_recipient_access ldap:/etc/postfix/ldap_restricted_recipients.cf
  permit_sasl_authenticated,
  reject_non_fqdn_hostname,
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unauth_destination,
  reject_unauth_pipelining,
  reject_invalid_hostname,
  check_policy_service unix:private/policy-spf

Talvez a solução seja substituir o resultado da consulta "OK" por "DUNNO". As diferenças entre esses dois parâmetros é,

  • Quando OK, o postfix encerra a lista de verificação de restrições
  • Quando DUNNO, o postfix passará para a próxima lista de verificação de restrições

Veja também acesso do homem 5 .

OK Accept the address etc. that matches the pattern.

DUNNO Pretend that the lookup key was not found. This prevents Postfix from trying substrings of the lookup key (such as a subdomain name, or a network address subnetwork).

This feature is available in Postfix 2.0 and later.

    
por 29.07.2015 / 01:13
2

Para pessoas interessadas em implementar uma restrição semelhante:

Isso funciona bem apenas se um arquivo extra for criado, por exemplo /etc/postfix/ldap_virtual_domains_restrict_access.cf com o seguinte conteúdo

bind = yes
bind_dn = uid=postfix,ou=service,dc=example,dc=com
bind_pw = xxxxxx
server_host = ldap://127.0.0.1:389
search_base = ou=domain,dc=example,dc=com
query_filter = (&(ObjectClass=dNSDomain)(dc=%s))
result_attribute = dc
result_filter = dunno
result_format = OK

Em seguida, no arquivo /etc/postfix/main.cf altere as linhas como:

local_only = check_recipient_access ldap:/etc/postfix/ldap_virtual_domains_restrict_access.cf, reject
insiders_only = check_sender_access ldap:/etc/postfix/ldap_virtual_domains_restrict_access.cf, reject

Dessa forma, o recurso de solicitação funciona bem! Caso contrário, ao corresponder "local_only" ou "insiders_only", se o resultado da consulta ldap for "DUNNO", o remetente ou destinatário será rejeitado (como após a solicitação, a próxima regra será "reject").

Com result_format = OK quando o resultado é "DUNNO", o resultado da solicitação de ldap é "OK".

Espero que isso ajude os outros

    
por 10.08.2015 / 11:55