proxsmtp - средство для обработки «на лету» исходящих почтовых сообщений. Работает в виде демона, слушает по умолчанию 10025 порт и представляет собой, как не трудно догадаться, прокси для SMTP.

Постановка задачи и умолчания

Есть внешний почтовый сервер, находится по адресу 1.2.3.4. Пользователи локальной сети отправляют с него почту, подключаясь на 25 порт (стандартный smtp без шифрования).

В локальной сети 192.168.0.0/24 есть шлюз на Linux, находящийся по адресу 192.168.0.1. На шлюзе есть iptables, никакие дополнительные пакеты ставить нельзя. То есть, proxsmtp на нём стоять не может.

В этой же локалке есть сервер 192.168.0.22, на котором есть возможность поставить proxsmtp и достаточное количество свободного места для хранения собранных исходящих сообщений.

Для пользователей всё должно быть прозрачно, они не должны почувствовать никаких изменений.

Решение

При отправке письма происходит соединение компьютера пользователя с почтовым сервером. Причём подключение идёт с произвольного порта локальной машины на 25 порт почтового сервера.

Для простоты рассмотрим пока единственного пользователя локальной сети, с адресом 192.168.0.333

Схема движения сетевых пакетов

В нашей схеме пакеты должны будут двигаться так:

  • Пользователь 192.168.0.333:xxx инициирует подключение на 1.2.3.4:25 (xxx - произвольный порт. Мы не знаем, какой он)
  • iptables шлюза загибает пакеты, предназначенные для 1.2.3.4:25 на 192.168.0.22:10025
  • proxsmtp, работающий на 192.168.0.22, подхватывает такие пакеты и обрабатывает их, пересылая результат на 1.2.3.4:25
  • Ответ с 1.2.3.4 приходит напрямую пользователю, он нас не интересует.

Настройка iptables на шлюзе

eth0 - внутренний сетевой интерфейс, локальная сеть.
eth1 - внешний сетевой интерфейс, провайдер интернета.

1. Проверяем, осуществляется ли подключение к почтовому серверу. Если да, то загибаем такой пакет на локальный сборщик почты 192.168.0.22. В зависимости от того, пропустим мы пакет или загнём, он уйдёт в интернет или останется в локальной сети, поэтому это действие должно выполняться перед решением о маршрутизации. То есть, должно находиться в цепочке PREROUTING таблицы nat.

iptables -t nat -A PREROUTING -i eth0 -s 192.168.0.333 -d 1.2.3.4 -p tcp --dport 25 -j DNAT --to-destination 192.168.0.22:10025

2. Если пакет был загнут и остался в локальной сети, то получится, что он пришёл с интерфейса eth0 и уходит обратно туда же. На многих шлюзах такие пакеты считаются некорректными и дропаются цепочкой FORWARD таблицы filter. Надо убедиться, чтобы это было не так.

iptables -t filter -I FORWARD N -i eth0 -o eth0 -j ACCEPT

Здесь N - корректный номер правила для цепочки FORWARD.

3. Решение о маршрутизации принято, пакет успешно загнут и прошёл фильтры. Вот только proxsmtp попытается вернуть ответ по обратному адресу, то есть станции 192.168.0.333. Минуя шлюз. Станция этого не поймёт, потому что ожидает ответ именно от шлюза. Чтобы этого не произошло, добавляем ещё одно правило.

iptables -t nat -A POSTROUTING -d 192.168.0.22 -p tcp --dport 10025 -j SNAT --to-source 192.168.0.1

Настройка proxsmtp

proxsmtp - мощный инструмент, но нам много от него не надо. Требуется только, чтобы он все проходящие письма сохранял на жёсткий винт.

Проходящие письма обрабатываются самописным скриптом (в прямом смысле, мы его должны сами написать), путь к этому скрипту указывается настройкой в конфигурационном файле proxsmtp. Там же указывается как скрипт будет оперировать с данными: править файл или брать из стандартного ввода и отправлять на стандартный вывод. Я выбрал второй вариант: меньше операций с диском, поэтому работает быстрее.

Но - обо всём по порядку.

Конфигурационный файл proxsmtp изначально не существует. В убунте демон стартует в стольких экземплярах, сколько существует файлов *.conf в каталоге /etc/proxsmtp. Это очень удобно: можно обрабатывать письма для нескольких почтовых серверов. У нас - один.

Создаём файл /etc/proxsmtp/1-2-3-4.conf и наполняем его таким содержимым:

Listen: 192.168.100.22:10025
MaxConnections: 256
OutAddress: 1.2.3.4
TransparentProxy: off
User: имя_пользователя
FilterCommand: /etc/proxsmtp/tee.sh
FilterType: pipe

Listen: ловим пакеты, предназначенные порту 10025 адреса 192.168.0.22 (их нам любезно предоставляет iptables шлюза)
MaxConnections: разрешаем 256 одновременных соединений, для обычной сети больше и не надо
OutAddress: указываем, что письма, прошедшие через наш скрипт (см. ниже) будут отправлены на сервер 1.2.3.4, для дальнейшего движения
TransparentProxy: демон работает не в режиме прозрачного прокси.

Здесь надо остановиться подробнее.
Режим прозрачного прокси удобен в том случае, если proxsmtp установлен непосредственно на шлюзе. В этом случае не надо было бы указывать сервер в OutAddress и для ловли пакетов потребовалось бы только одно правило в iptables.
Но результат был бы тем же: пользователь ничего не знает о том, что его отправленные письма сохраняются.

User: указанное здесь имя_пользователя используется для запуска демона, от этого же имени демон производит операции над данными. Для этих целей рекомендуется создавать отдельного пользователя.
FilterType: тип фильтрации. Как будем обрабатывать данные. pipe означает, что данные будем передавать скрипту в стандартный ввод, а результат брать из стандартного вывода.
FilterCommand: полный путь к фильтрующему скрипту. Может лежать где угодно, я расположил в /etc/proxsmtp/tee.sh

В моём случае скрипт такой:

#!/bin/bash
tee "/mnt/proxsmtp/`date +\%Y\%m\%d-\%H\%M\%S-\%N`.eml"

Здесь:
Команда tee дублирует информацию из стандартного ввода в файл и в стандартный вывод
/mnt/proxsmtp/ - хранилище проходящей почты
`date +\%Y\%m\%d-\%H\%M\%S-\%N` - формирует имя для каждого сохранённого письма. Так они будут храниться аккуратно, по датам отправки. Микросекунды в конце исключают потерю разных писем, отправленных в одно и то же время, в противном случае одно может затереться другим.

Всё.

Теперь при отправке письма пользователем, оно упадёт в каталог /mnt/proxsmtp и в неизменном виде будет отправлено адресату.
В случае ошибок смотрим лог /var/log/mail.log, демон пишет сообщения туда.


Напоминаю: настройка выше производилась для перехвата исходящей почты с единственного компьютера в сети. Теперь рассмотрим варианты.

Перехват почты со всех компьютеров локальной сети

Потребуется изменить только первое правило в iptables. Теперь оно будет выглядеть так:

iptables -t nat -A PREROUTING -i eth0 -s !192.168.0.22 -d 1.2.3.4 -p tcp --dport 25 -j DNAT --to-destination 192.168.100.22:10025

Обращаю отдельное внимание: перенаправляются пакеты со всех адресов локальной сети кроме самого сервера proxsmtp! Если его не исключить - возникнет страшная рекурсия.

Правда, программу тоже не дураки писали, поэтому всё закончится на второй итерации, выводом в /var/log/mail.log ошибки.

Перехват почты с диапазона адресов локальной сети

Опять же, изменяем только первое правило. Например, для диапазона 192.168.0.144-159:

iptables -t nat -A PREROUTING -i eth0 -s 192.168.100.144/28 -d 1.2.3.4 -p tcp --dport 25 -j DNAT --to-destination 192.168.0.22:10025

Очень удобный вариант. Если надо сохранять исходящую почту не от всех пользователей, а от избранных (например, есть подозрение, что хамят клиентам ;), то поступаем следующим образом:

1. Настраиваем систему на сбор почты с диапазона адресов.
2. Вносим в этот диапазон нужных людей.

После чего процедуры «поставить на наблюдение» и «снять с наблюдения» сводятся к изменению ip-адреса рабочей станции. Вдвойне удобнее, если в локальной сети работает DHCP.

Многие не могут понять, почему диапазон адресов 192.168.0.144-159 можно задать в iptables как 192.168.100.144/28 (кстати, по-другому там ряд адресов и не задашь). Даю подсказку:

144: 10010000
159: 10011111

Перехват почты для нескольких почтовых серверов

Например, 5.6.7.8 - второй почтовый сервер, письма на который надо перехватывать.

Добавляем в iptables:

iptables -t nat -A PREROUTING -i eth0 -s 192.168.0.333 -d 5.6.7.8 -p tcp --dport 25 -j DNAT --to-destination 192.168.0.22:10026
iptables -t nat -A POSTROUTING -d 192.168.0.22 -p tcp --dport 10026 -j SNAT --to-source 192.168.0.1

Обращаю внимание: изменился порт, на который перенаправляем пакеты. Это другой почтовик и его будет слушать другой демон.

На сервере proxsmtp добавляем второй конфиг для демона: /etc/proxsmtp/5-6-7-8.conf. Например, такого содержания:

Listen: 192.168.100.22:10026
MaxConnections: 256
OutAddress: 5.6.7.8
TransparentProxy: off
User: имя_пользователя
FilterCommand: /etc/proxsmtp/tee2.sh
FilterType: pipe

Можно использовать и одинаковые скрипты (tee.sh), но есть смысл отделять почту, отправляемую с разных серверов, по разным папкам. Пример tee2.sh:

#!/bin/bash
tee "/mnt/proxsmtp5678/`date +\%Y\%m\%d-\%H\%M\%S-\%N`.eml"

Надеюсь, система понятна.


http://thewalter.net/stef/software/proxsmtp/transparent.html


Алексей
2012.09.08 09:30:19
#cid40442

Ответить

Отлично! Благодарю за наводку на софт.

2012.09.09 07:31:18
#cid40544

Ответить

#cid40442, Алексей

Отлично! Благодарю за наводку на софт.

Пожалуйста.

Vik-Kurc-Han
2015.09.21 02:06:36
#cid90975

Ответить

интересно=)

Alex
2016.03.16 10:17:51
#cid91424

Ответить

Отличная статья! Нет ли готовых решений для перехвата исходящих писем, если наши подопечные используют веб-интерфейсы почтовых служб? Т.е. они не шлют письма из почтовых клиентов, цепляясь на 25 порт удаленного почтового сервера, как здесь описано, а заходят на этот сервер через браузер.

2016.03.16 18:47:56
#cid91426

Ответить

#cid91424, Alex

Отличная статья! Нет ли готовых решений для перехвата исходящих писем, если наши подопечные используют веб-интерфейсы почтовых служб?

Веб-интерфейс — это когда содержимое письма отправляется через протоколы http или https и ничем не отличается от обычного веб-трафика. А с этим и сложности: отделить именно почтовые сообщения невозможно.
Плюс, если с http всё более-менее понятно (можно ловить исходящие http-соединения, куда кстати попадут и данные любых веб-форм), то с шифрованным https всё сложнее, хотя есть способы и для этого.

В целом — не имеет смысла. Любое решение будет костыльным.

Надо либо поднимать свой почтовый сервер, либо организовывать работу пользователей так, чтобы получить возможность следить за почтой на стороне клиента, либо ставить следилку типа АктуалСпая или ЛанАгента.
Последнее вообще следит за всем, но это не всегда законно. Будь осторожен.

Alex
2016.03.16 22:19:28
#cid91427

Ответить

Спасибо за ответ!

Я и хочу поднимать свой почтовый сервер, но возможность, в т.ч. и легальная, переписки через публичные сервисы всё равно останется. Дело тут не в слежке за сотрудниками, а в организации контроля всех коммуникаций продажников с клиентами, хранении в БД, ну прочее такое. Я сам хозяин своей конторы, вдрядли мне может грозить юридическое преследование за использование сетевых штучек. Про Ланагент бы почитал с интересом.

2016.03.17 09:06:42
#cid91428

Ответить

#cid91427, Alex

Я и хочу поднимать свой почтовый сервер

На мой взгляд — не самое лучшее решение. У своего почтовика много недостатков.

Я сам хозяин своей конторы, вдрядли мне может грозить юридическое преследование за использование сетевых штучек.

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

Про Ланагент бы почитал с интересом.

LanAgent, ActualSpy — программы одного рода. Становятся как службы, скрывают свою работу от пользователя (некоторые даже прячут себя от диспетчера задач), ведут полный лог клавиатуры, запущенных приложений, буфера и делают скриншоты через заданное время. Всё настраивается, всё с метками времени — то есть, в любой момент можно полностью восстановить деятельность работника за любой рабочий день.

Если понадобится предметная помощь — оставляй координаты через электропочту, пообщаемся.
(Москва от Новосибирска далеко, но скайп и тим вьювер ещё никто не отменял)

Alex
2016.03.17 10:23:58
#cid91430

Ответить

Ага, спасибо еще раз :) Про Ланагента уже почитал, если честно, смущает, что он только по винду и ставиться индивидуально на каждую машину. Мне больше по душе собирать все данные на шлюзе. Вобщем я пока собираю информацию. Здорово, что есть с кем обсудить такие интересные вещи.

2016.03.17 13:09:13
#cid91431

Ответить

#cid91430, Alex

Про Ланагента уже почитал, если честно, смущает, что он только по винду и ставится индивидуально на каждую машину.

Это клиентская часть. Есть серверная часть, куда централизованно сливается вся информация.
Если сервер по каким-то причинам недоступен, собранная информация хранится на локальных машинах в скрытых каталогах, но передаётся на сервер сразу при его появлении в сети. При этом вся локальная информация уничтожается. То есть, работает как временный кэш.

Но вся структура — и клиенты, и сервер — работает только на виндах, это да.

Мне больше по душе собирать все данные на шлюзе.

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

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

Если же остановишься на решении, при котором данные собирает шлюз (iptables+ulogd, http/https-прокси и т.д.), то опять же — настраиваешь сторонний сервер, чтобы тот периодически забирал полученные данные, а доступ со шлюза на него так же закрываешь.

Вобщем я пока собираю информацию. Здорово, что есть с кем обсудить такие интересные вещи.

:)
Многое уже придумано до нас, остаётся только грамотно, со всех сторон оценить задачу и подобрать оптимальное решение.

Alex
2016.03.19 16:11:49
#cid91440

Ответить

Привет еще раз. Расчитывал я на DBmail в качестве сборщика в БД входящей почты. Мне это нужно для использования в своей инф. системе, как и proxsmtp, впрочем. Так вот DBm нету для Debian8, я впичали. Насколько я понимаю proxsmtp здесь не поможет. Не сталкивались ли вы с DBm, может его можно самому подкрутить под Джесси из исходника? Или может какие-то другие аналогичные решения знаете?

2016.03.19 19:45:20
#cid91441

Ответить

#cid91440, Alex

Привет еще раз. Расчитывал я на DBmail в качестве сборщика в БД входящей почты. Мне это нужно для использования в своей инф. системе, как и proxsmtp, впрочем. Так вот DBm нету для Debian8, я впичали. Насколько я понимаю proxsmtp здесь не поможет. Не сталкивались ли вы с DBm, может его можно самому подкрутить под Джесси из исходника? Или может какие-то другие аналогичные решения знаете?

proxsmtp — это простое решение для одной конкретной задачи.
DBmail сам не собирал, подводных камней не знаю.

В подавляющем большинстве случаев для небольших организаций подходит перенос почтовика под управление, например, Яндекса.
https://pdd.yandex.ru/
Никакого спама, удобный API для дополнительных задач, надёжная работа и т.д.

Если надо что-то понавороченнее — посмотри в сторону zimbra
https://habrahabr.ru/post/114079/
Импортное и тяжеловесное решение, но со своими плюсами.

А так — я ж не знаю всего спектра твоих задач, тут вникать надо и стараться учитывать нюансы по максимуму.
Но лично я не вижу плюсов в хранении почты в базе.

Alex
2016.03.19 19:59:33
#cid91442

Ответить

Письма в БД исключительно для удобного отображения переписки, привязанной к сделке. За рекомендации спасибо, обязательно познакомлюсь с этими продуктами.

Alex
2016.03.19 20:17:21
#cid91443

Ответить

А если proxsmtp настроить на перехват входящего SMTP трафика, который идет снаружи на 25 порт, и так же разбирать письма скриптами?

2016.03.20 06:20:10
#cid91444

Ответить

#cid91443, Alex

входящего SMTP трафика, который идет снаружи на 25 порт

То есть, кто-то извне будет подключаться к шлюзу по 25 порту для отправки писем?!
Настроить конечно можно и работать будет нормально, только случай больно необычный.
Выставить наружу голый почтовый порт без шифрования — это хардкор.

Alex
2016.03.20 07:07:48
#cid91445

Ответить

Не, ну зачем так жестко. Можно уже отфильтрованный трафик с почтовика еще раз направлялся на внутренний МТА опять на :25, а перед ним проходил через proxsmtp с целью разгребания в БД входящих писем.

Т.о. изначальная схема стенда: "Ответ с 1.2.3.4 приходит напрямую пользователю, он нас не интересует." изменяется, поскольку нас таки интересует и ответ пользователю тоже.

imen
2016.04.07 16:50:21
#cid91481

Ответить

#cid91444,

Выставить наружу голый почтовый порт без шифрования — это хардкор.

Игра верю-не верю [некоторому самоподписанному сертификату] — та ещё лотерея.