Рассылка спама с моего почтового сервера

[s.zirro]

Добрый день.
Что есть: сервер на ОС FreeBSD 9.2, почтовый сервер Exim 4.82 с авторизацией пользователей через AD.
В пятницу заметил в почте "возвраты" с других почтовых адресов с проблемой "невозможно доставить сообщение", причём с адресов, которым я ничего не отправлял.
Например:
"A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
dj-t.point@freenet.de
SMTP error from remote mail server after RCPT TO:<dj-t.point@freenet.de>:
host mx.freenet.de [195.4.92.211]: 550 unrouteable address
... "
Стал рыться в логах сквида и, действительно, с моего адреса отправляются письма на непонятные адреса. Впопыхах решил, что это на моей машине вирус завёлся и, естественно, проверился несколькими антивирусами (хотя и так штатный есть), а также настроил Exim так, чтобы не мог отсылать почту без аутентификации (каюсь, все остальные пользователи ЛС могут отправлять письма без аутентификации). Проверил на своём почтовом клиенте - без аутентификации не отправляет. Вирусов не нашлось.
Однако, через некоторое время в журнале Exim'а снова наблюдаю отправку почты с моего ящика на левые адреса. Опять же, не вникая в суть, хотел решить вопрос кардинально и сменил свой пароль в AD. Снова проверил на локальном клиенте: со старым паролем ругается и не отправляет, с новым всё работает.
Но в журнале снова вижу что с моего ящика отправляются письма, которые я не посылал.
Стал более детально смотреть журнал и наконец увидел интересную вещь: оказывается соединение с Exim происходит с какого-то внешнего хоста, а не с моего локального адреса.
Например:
2014-01-17 15:16:48 1W47Pp-000MCh-C5 <= мой адрес@мой домен.ru H=(Galina) [91.65.34.20]:52373 I=[IP-адрес моего почтового сервера]:25 P=esmtpsa X=TLSv1.2:AES128-SHA256:128 CV=no SNI="имя моего почтового сервера" A=plain_ldap:мой адрес S=113785 M8S=0 T="=?utf-8?q?Ihre Mahnung - Lastschrift konnte nicht durchgef=C3=BChrt werden 17.01.2014?=" from <мой адрес@мой домен.ru> for entifique@mudjaheddin.de
Положим, кто-то с внешней машины отправляет письма "как будто от меня", но как проходит аутентификация, если я пароль сменил всего час назад на довольно сложный (хотя и до этого стоял не слабый).
Или я может что-то упускаю?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[xM]

Вероятно, у вас сообщения с этого внешнего хоста принимаются сервером без выполнения правила аутентификации.
Проверьте, нет ли адреса "вражеской" машины в списке доверенных хостов.
И причём тут "логи сквида", кстати?

[s.zirro]

Про логи ошибся, конечно же логи Exim'а. Про остальное: "вражеская" машина каждый раз разная, без аутентификации разрешена отправка только с локалхоста и из локальных сетей. Кроме того, не являясь спецом в разборке логов Exim'а могу предположить что: A=plain_ldap:мой адрес
в строке журнала
2014-01-17 15:16:48 1W47Pp-000MCh-C5 <= мой адрес@мой домен.ru H=(Galina) [91.65.34.20]:52373 I=[IP-адрес моего почтового сервера]:25 P=esmtpsa X=TLSv1.2:AES128-SHA256:128 CV=no SNI="имя моего почтового сервера" A=plain_ldap:мой адрес S=113785 M8S=0 T="=?utf-8?q?Ihre Mahnung - Lastschrift konnte nicht durchgef=C3=BChrt werden 17.01.2014?=" from <мой адрес@мой домен.ru> for entifique@mudjaheddin.de
означает что использовался метод аутентификации plain_ldap - аутентификация в AD.

[xM]

A=plain_ldap:мой адрес

Говорит о том, что пройдена аутентификация по LDAP с вашим адресом нешифрованным паролем.
Дебажьте каким образом спаммеры проходят вашу аутентификацию. Видимо, где-то дыра, если смена пароля не помогла.
Ещё порт как-то странно выглядит

Код: Выделить всё

[91.65.34.20]:52373

[s.zirro]

Вот про "дебажьте" хотелось бы поподробней. Каким образом? Смену пароля я проверил на своём MUA (Thenderbird): со старым паролем не отправляются письма, с новым отправляются.

>> порт странный
Так то не мой порт - это "вражий" порт.

[xM]

Код: Выделить всё

# /usr/local/etc/rc.d/exim stop
# exim -bd -d+all > /var/log/eximdebug.log 2>&1

Потом смотрите что там у вас происходит.
Не забудьте после окончания разборок снова Exim запустить.

[s.zirro]

Запустил Exim в режиме отладки, но теперь у меня вообще голова кругом, я не могу разобраться в таком огромном наборе информации. Я даже не могу различить где заканчиваются сообщения об одном письме и начинаются сообщения о другом . Видимо завтра с утра на свежую голову придётся разбираться.

[xM]

Не затягивайте. А то вас уже, наверняка, полинтернета забанили.

[s.zirro]

Я банально заблокировал отправку почты с тех адресов, от имени которых отправляется спам. Для экспериментов то блокирую их, то разблокирую. Но Вы правы, затягивать не стоит, вот тока пока никаких мыслей.

[s.zirro]

Ковырялся, ковырялся с логами, пока мало что понял, но, похоже, что-то не то с аутентификаторами. Задумка была такая: по полю "mail" или "OtherMailbox" искать пользователя и с помощью ldapauth проверять может ли он аутентифицироваться в AD со своим паролем.
Аутентификатор выглядит так:

Код: Выделить всё

plain_ldap:
    driver                  = plaintext
    public_name             = PLAIN

    server_condition        = ${if ldapauth {user="${lookup ldapdn{user=LDAP_AD_BINDDN \
                            pass=LDAP_AD_PASS \
                            ldap://мой домен:389/?dn?sub?(|(otherMailbox=$auth2)(mail=$auth2))}}" \
                            pass=${quote_ldap:$auth3} \
                            ldap://мой домен:389/}{yes}{no}}

    server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
    server_set_id           = $auth2

Однако, если я правильно разобрался с логами, полученными с помощью debag'а, при отправке письма происходят 2 странные вещи:
1 . При первичном поиске в AD с такими настройками ничего не находится:

Код: Выделить всё

16:55:05 18854 perform_ldap_search: ldapdn URL = "ldap://мой домен:389/?dn?sub?(|(otherMailbox=мой ящик)(mail=мой ящик))" server=NULL port=0 sizelimit=0 timelimi
t=0 tcplimit=0
16:55:05 18854 after ldap_url_parse: host=мой домен: port=389
16:55:05 18854 ldap_initialize with URL ldap://мой домен::389/
16:55:05 18854 initialized for LDAP (v3) server мой домен::389
16:55:05 18854 LDAP_OPT_X_TLS_TRY set due to ldap:// URI
16:55:05 18854 binding with user=CN="пользователь, который может искать в AD",CN=Users,DC=corp,DC=xxxxx,DC=ru password=password
16:55:05 18854 Start search
16:55:05 18854 search ended by ldap_result yielding 101
16:55:05 18854 ldap_parse_result: 0
16:55:05 18854 ldap_parse_result yielded 32: No such object
16:55:05 18854 lookup failure forced
16:55:05 18854 LDAP search failed - error 32: No such object/0000208D: NameErr: DSID-031001E5, problem 2001 (NO_OBJECT), data 0, best match of:
16:55:05 18854  ''
16:55:05 18854
16:55:05 18854 lookup failed

2. ну не нашёл и ладно бы с ним, хоть бы сругался. Однако, без всякой ругани происходит аутентификация пустого пользователя с моим паролем

Код: Выделить всё

16:55:05 18854 expanding: user="${lookup ldapdn{user=CN="пользователь, который может искать в AD",CN=Users,DC=corp,DC=xxxxx,DC=ru pass=password ldap://мой домен:389/?dn?sub?(|(otherMailbox=$auth2)(mail=$a
uth2))}}" pass=${quote_ldap:$auth3} ldap://мой домен:389/
16:55:05 18854    result: [b]user=""[/b] pass=мой пароль ldap://мой домен:389/
16:55:05 18854 LDAP parameters: [b]user=[/b] pass=мой пароль size=0 time=0 connect=0 dereference=0 referrals=on
16:55:05 18854 perform_ldap_search: ldapauth URL = "ldap://corp.kio.ru:389/" server=NULL port=0 sizelimit=0 timelimit=0 tcplimit=0
16:55:05 18854 after ldap_url_parse: host=мой домен port=389
16:55:05 18854 ldap_initialize with URL ldap://мой домен:389/
16:55:05 18854 initialized for LDAP (v3) server мой домен:389
16:55:05 18854 LDAP_OPT_X_TLS_TRY set due to ldap:// URI
16:55:05 18854 binding with [b]user=[/b] pass=мой пароль
16:55:05 18854 [b]Bind succeeded: ldapauth returns OK[/b]
16:55:05 18854 condition: ldapauth {user=CN="пользователь, который может искать в AD",CN=Users,DC=corp,DC=xxxxx,DC=ru pass=password ldap://мой домен:389/?dn?sub?(|(otherMailbox=$auth
2)(mail=$auth2))}}" pass=${quote_ldap:$auth3} ldap://мой домен:389/}
16:55:05 18854    result: true
16:55:05 18854 expanding: yes
16:55:05 18854    result: yes
16:55:05 18854 expanding: no
16:55:05 18854    result: no
16:55:05 18854 skipping: result is not used
16:55:05 18854 expanding: ${if ldapauth {user="${lookup ldapdn{user=CN="пользователь, который может искать в AD",CN=Users,DC=corp,DC=xxxxx,DC=ru pass=password ldap://мой домен:389/?dn?sub?(|(otherMailbox=
$auth2)(mail=$auth2))}}" pass=${quote_ldap:$auth3} ldap://мой домен:389/}{yes}{no}}
16:55:05 18854    result: yes
16:55:05 18854 expanded string: yes
16:55:05 18854 expanding: $auth2
16:55:05 18854    result: мой почтовый адрес
16:55:05 18854 [b]SMTP>> 235 Authentication succeeded[/b]

Я достоверно знаю, что ранее пользователь не мог отправить письмо без предоставления корректных аутентификационнных данных. Конфиг Exim'а я правлю крайне редко, а в части аутентифкаторов - ни разу с момента ввода в эксплуатацию сервера. Не знаю что произошло (это возможно выяснится позже), но работающий ранее аутентификатор стал работать некорректно и как это исправить у меня практически не осталось идей .

[xM]

У вас условие раскрывается в "истина", соответственно аутентификация проходит успешно.
Поиграйтесь условием

${if ldapauth {user="${lookup ldapdn{user=LDAP_AD_BINDDN \
pass=LDAP_AD_PASS \
ldap://мой домен:389/?dn?sub?(|(otherMailbox=$auth2)(mail=$auth2))}}" \
pass=${quote_ldap:$auth3} \
ldap://мой домен:389/}{yes}{no}}

при помощи команды exim -be - посмотрите что там происходит. Очевидно, что там есть ошибка в логике.
Только значения переменных $auth ручками подставлять придётся.

[s.zirro]

при помощи команды exim -be - посмотрите что там происходит. Очевидно, что там есть ошибка в логике.
Только значения переменных $auth ручками подставлять придётся.

Этим и сижу занимаюсь полдня пока безрезультатно и ошибок в логике не вижу. Быть может в синтаксисе какая-нибудь ошибка, но опять пока не нашёл где

[s.zirro]

Вроде бы разобрался.
С помощью exim -be -d стал смотреть как раскрываются строки в моём аутентификаторе. И понял, что, во-первых: с таким синтаксисом поиск (lookup ldap) не всегда работает успешно, а, во-вторых: если после неудачного поиска возвращается пустое значение (user=""), то ldapauth возвращает "истина" в любом случае.
Соответственно, я сперва добился чтобы гарантированно работал поиск в LDAP. Вот в таком варианте у меня заработало (заменил lookup ldap на lookup ldapdn, заменил имя домена на IP-адрес контроллера домена, добавил к параметру LDAP baseDN):

Код: Выделить всё

LDAP_AUTH = user="cn=пользователь, который может искать в AD,cn=Users,dc=corp,dc=ххххх,dc=ru" pass="пароль"
LDAP_URL = ldap://IP-адрес контроллера домена:389/dc=corp,dc=ххххх,dc=ru
lookup ldapdn{LDAP_AUTH LDAP_URL?dn?sub?(|(otherMailbox=$auth2)(mail=$auth2))

если пользователь есть в AD возвращает "DN-пользователя", если нет - пустую строку.

Далее объединил в одном условии проверку: 1. такой пользователь существует в AD (чтобы поиск не возвращал пустую строку) и 2. пользователь может аутентифицироваться в AD.

Код: Выделить всё

server_condition = ${if and{{!eq{}{${lookup ldapdn{LDAP_AUTH LDAP_URL?dn?sub?(|(otherMailbox=$auth2)(mail=$auth2))}}}}\
                  {ldapauth {user="${lookup ldapdn{LDAP_AUTH LDAP_URL?dn?sub?(|(otherMailbox=$auth2)(mail=$auth2))}}" \
                   pass="$auth3" LDAP_URL}}}{yes}{no}}

В данном условии меня смущает то, что необходимо дважды производить поиск в AD (lookup ldapdn). К сожалению, у меня не хватило ума как ещё оптимизировать это условие. К тому же я успокаиваю себя тем, что, судя по отладочным логам, реальный поиск происходит только в первый раз, затем используется кэширование и, кроме того, пользователей реально пользующихся аутентификацией при отправке письма очень мало и значит никакой значимой нагрузки двойной поиск не создаёт.

[xM]

Главное, что вы разобрались в чём дело.
А оптимизацией можно заниматься всю жизнь.