Постфиксное ограничение доступа отправителя - Нарушение защиты?

Мы встречаемся с проблемами безопасности с нашим почтовым сервером и хотели бы некоторый совет.

История его

На нашем почтовом сервере (Постфикс 2.9.6 + Голубятня 2.1.7) мы хотели бы смочь создать ограниченные почтовые ящики. Те учетные записи (используемый стажерами) смогли бы отправить/получить электронные письма в локальные домены только (из соображений безопасности, которые мы не хотим, чтобы они смогли отправить или получить электронные письма к другим почтовым серверам). Для создания этого простым мы создали определенный субдомен для ограниченных почтовых ящиков.

На нашей инфраструктуре все почтовые ящики являются базирующимся LDAP, файлы конфигурации включены по настоящему документу.

Что мы сделали

В постфиксе возможно создать правила ограничения в файле /etc/postfix/main.cf и таким образом, мы добавили правила:

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

разделять:

smtpd_recipient_restrictions

Наверняка, следующие строки были также добавлены:

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

Содержание /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

Это возвращается "хорошо", когда домену позволяют послать электронные письма снаружи.


Содержание /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

Это возвращает "insiders_only", когда домен может быть достигнут только локальными доменами.


Содержание /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

Это возвращается "хорошо", когда домен локален (может послать электронные письма ограниченному субдомену).


Для большей точности, постфикса smtpd_recipient_restrictions раздел содержит:

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

Это хорошо работает в sens, что все электронные письма от субдомена могут послать электронные письма только другим локальным доменам и могут только получить электронные письма от локальных доменов.

НО...

Так как мы включаем это, мы заметили, что люди могли использовать почтовый сервер для отправки СПАМА (таким образом, мы временный удалили его).

Мы заметили проблему потому что файл журнала /var/log/mail.log содержавшие строки как:

Jul 22 11:59:24 mail postfix/qmgr[366]: F342F42AE4: from=<mnd0gb8@example.com>, 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

Что мы предполагаем

Как ограничение мы устанавливаем соответствия только домен (для отправителя), кто-то использовал наш сервер в качестве реле с с электронными письмами, где отправитель был подделан для соответствия anything@example.com и будет так принят.

Мы собираемся изменить настройки, чтобы заставить правило соответствовать целой электронной почте вместо этого, но мы не уверены, что это предотвратит спуфинг.

Что Вы думаете об этом? Мы сделали что-то не так? Есть ли иначе (или функциональность), чтобы иметь такое ограничение?

PS: Мы можем разместить больше информации в случае необходимости

2
задан 29 July 2015 в 01:53
2 ответа

Поскольку установленное нами ограничение соответствует только домену (для отправителя), кто-то использовал наш сервер в качестве ретранслятора с электронными письмами, где отправитель был подделан для сопоставления (скрыт) и будет принят.

Да, это вызвано этим ограничением в smtpd_recipient_restrictions

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

Возможно, решение состоит в замене результата запроса «OK» на «DUNNO». Различия между этими двумя параметрами заключаются в следующем:

  • Когда OK, postfix завершает список проверки ограничений
  • Когда DUNNO, postfix переходит к следующему списку проверки ограничений

См. Также доступ man 5 .

OK Подтвердите адрес и т. Д., Соответствующий шаблону.

DUNNO Представьте, что ключ поиска не был найден. Это предотвращает попытку Postfix пробовать подстроки ключа поиска (например, поддомен имя или подсеть сетевого адреса).

Эта функция доступна в Postfix 2.0 и более поздних версиях.

3
ответ дан 3 December 2019 в 09:34

Для людей, заинтересованных в реализации аналогичного ограничения:

Это работает нормально, только если создается дополнительный файл, например /etc/postfix/ldap_virtual_domains_restrict_access.cf с следующее содержимое

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

Затем в файле /etc/postfix/main.cf измените строки как:

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

Таким образом, функция запроса работает нормально! В противном случае, при сопоставлении «local_only» или «insiders_only», если результатом запроса ldap является «DUNNO», то отправитель или получатель отклоняется (как после следующего правила запроса «отклонить»).

С result_format = OK , когда результатом является «DUNNO», то результат запроса ldap будет «OK».

Надеюсь, это поможет другим

2
ответ дан 3 December 2019 в 09:34

Теги

Похожие вопросы