Добрый день!
Интересует вопрос о трафике почтового сервера, раньше когда у меня был Mdaemon, выходило примерно 2500 - входящего и 2500 исходящего трафик в мегабайтах. Бывало и 3000/3000 мбайт примерно на 25 учеток.
Сейчас стоит Postfix, почему-то входящего трафика стало мало, а исходящий возрос.например 2100 - входящий и 2600 - исходящий в мбайтах (за месяц).
Почему произошла такая разница с Mdaemon и Postfix, в трафике. Почему у первого примерно одинаково, а у второго по другому.
Интересно, а у вас как?
LinuxForum.Fans
Опрос: Сколько трафика входящего и исходящего у вашего почтовика в мес
Автор: AlfaStriker
29 сообщений
3348 просмотров
Постфикс умеет очень неплохо бороться со спамом. Сам. Рубит соединения уже на этапе HELO. А если ему помогает разбирать контент Amavis, то вообще шоколадно получается. У меня после перехода на постфикс входящий трафик упал кардинально. Настолько упал, что юзеры стали жаловаться - почта, мол, не работает. А до того они спамом были завалены по самые уши. Поэтому сокращение входящего трафика вполне ожидаемо.
У меня в день по 3-4 тыщи попыток ботовских заходов регистрируется, пропускается где-то под сотню-другую. Дальше amavis контент почикает и пропустит уже не сотню, а с десяток-другой писем.
А вот по исходящему - может активность собственно фирмы выросла?
Всего скорей так и есть, когда был почтовик на Windows, было много спама.
Сейчас ситуация изменилась, в итоге входящий трафик снизился.
Нашел замечательный анализатор логов почтового сервера pflogsumm :
text
# yum -y install postfix-perl-scripts
# perl /usr/sbin/pflogsumm -d yesterday /var/log/maillogЭтот анализатор показал мне все как на ладони, всю статистику которую мне нужно было узнать.
И в правду, много рубится спама.
когда был почтовик на Windows, было много спама.
Просто руки не от туда растут. *WALL*
Может быть вы и правы, но все настройки на этом сервере были более-менее правильны.
Только вот SpamAssasin не был включен и обучен.
А так были:
- контент фильтр (редко очень залазил туда)
- DKIM/DomainKeys
- SPF
- серые списки
- обязательная авторизация
Может быть вы и правы, но все настройки на этом сервере были более-менее правильны.
Только вот SpamAssasin не был включен и обучен.
А так были:
- контент фильтр (редко очень залазил туда)
- DKIM/DomainKeys
- SPF
- серые списки
- обязательная авторизация
Мой опыт настройки Postfix:
Показать
#Проверки на этапе HELO/EHLO
smtpd_helo_restrictions = permit_mynetworks,
# - разрешить при аутентификации (пользователи)
#### permit_sasl_authenticated,
# "Белый Список" должен быть впереди остальных проверок
# отсекаем приветствия отправителя от моего имени
# а также прописываем разрешения для "продвинутых"
check_helo_access hash:/etc/postfix/helo_checks,
# отсекаем тех, кто представляется ИП-адресом.
# это явное нарушение RFC, но практика показала, что это один из явных
# признаков спама.
check_helo_access regexp:/etc/postfix/helo_regexp,
# - отказать при нарушении синтаксиса имени хоста в HELO
#(случается очень редко, тем не менее...)
reject_invalid_hostname,
# - отказать, если имя хоста в HELO не в полной форме
#(не должно быть просто server, а должно быть типа server.domain.ltd)
reject_non_fqdn_hostname,
# - отказать, если у хоста, указанного в команде HELO,
# в DNS нет записи типа MX или A (множество зобми-хостов)
reject_unknown_hostname,
# Проверяем SPF
check_policy_service unix:private/spf,
# - в другом случае продолжать прием
permit
#Проверки на этапе MAIL FROM
smtpd_sender_restrictions = permit_mynetworks,
# - разрешить при аутентификации (пользователи)
### permit_sasl_authenticated,
check_sender_access hash:/etc/postfix/sender_white_list,
# - отказать, если имя отправителя не в полной форме
# (должно быть не name или name@domain а name@domain.ltd)
reject_non_fqdn_sender,
# - отказать, если наш сервер не является "родным" для отправителя
# и домен отправителя не имеет в DNS записи MX или A, или если он
# имеет неверную запись MX (например, пустую)
reject_unknown_sender_domain,
# Проверка завязана на команде VRFY, которая может быть запрещена
# reject_unverified_sender,
permit
# ограничения, проверяемые на этапе RCPT TO:
smtpd_recipient_restrictions =
# - отказать при попытке отправки почты от чужого имени
reject_authenticated_sender_login_mismatch,
# - отсечь хосты, которые пытаются слать команды в конвейере
reject_unauth_pipelining,
check_client_access cidr:/etc/postfix/originating.cidr,
permit_mynetworks,
# permit_sasl_authenticated,
# whitelists:
check_client_access hash:/etc/postfix/sender_white_list,
check_client_access regexp:/etc/postfix/client_access_regexp,
# host check's:
reject_unknown_client,
reject_unknown_client_hostname,
# - отказать, если имя получателя не в полной форме (должно быть не name или name@domain а name@domain.ltd)
reject_non_fqdn_recipient,
# - отказать, если мы не являемся "родным" сервером для получателя и домен получателя не имеет
# в DNS записи MX или A, или если он имеет неверную запись MX (например, пустую)
reject_unknown_recipient_domain,
# - отказать, если домен-адресат: 1) не перечислен в списке доменов, для которых мы форвардим почту
# ($relay_domains) и не содержит команд переадресации (типа user@another@domain);
# 2) не является "нашим" (т.е. не перечислен в списках $mydestination,
# $inet_interfaces, $proxy_interfaces, $virtual_alias_domains, или
# $virtual_mailbox_domains ) и не содержит команд переадресации
# (типа user@another@domain).
# Это - традиционные правила, чтобы наш сервер не служил т.н. Open Relay, через который спамеры
# рассылают почту третьим лицам.
reject_unauth_destination,
# - отказать, если адрес получателя не указан в списках получателей домена
# (не перечислен в $local_recipient_maps или $virtual_alias_maps или
# $virtual_mailbox_maps или $relay_recipient_maps, в зависимости от того,
# в какой именно таблице найден домен получателя)
# Если письмо для многих получателей, но нет хотя бы одного в нашнй базе, то отказать
reject_unlisted_recipient,
# Greylist:
check_policy_service inet:127.0.0.1:10030,
permit
smtpd_data_restrictions =
permit_mynetworks,
# permit_sasl_authenticated,
reject_unauth_pipelining,
check_client_access regexp:/etc/postfix/add_auth_header.regexp,
permit
smtpd_end_of_data_restrictions =
permit_mynetworks,
# permit_sasl_authenticated,
# Отклоняем письма с нулевым отправителем (Bounce), у которых более одного получателя
reject_multi_recipient_bounce,
permit
smtpd_helo_restrictions = permit_mynetworks,
# - разрешить при аутентификации (пользователи)
#### permit_sasl_authenticated,
# "Белый Список" должен быть впереди остальных проверок
# отсекаем приветствия отправителя от моего имени
# а также прописываем разрешения для "продвинутых"
check_helo_access hash:/etc/postfix/helo_checks,
# отсекаем тех, кто представляется ИП-адресом.
# это явное нарушение RFC, но практика показала, что это один из явных
# признаков спама.
check_helo_access regexp:/etc/postfix/helo_regexp,
# - отказать при нарушении синтаксиса имени хоста в HELO
#(случается очень редко, тем не менее...)
reject_invalid_hostname,
# - отказать, если имя хоста в HELO не в полной форме
#(не должно быть просто server, а должно быть типа server.domain.ltd)
reject_non_fqdn_hostname,
# - отказать, если у хоста, указанного в команде HELO,
# в DNS нет записи типа MX или A (множество зобми-хостов)
reject_unknown_hostname,
# Проверяем SPF
check_policy_service unix:private/spf,
# - в другом случае продолжать прием
permit
#Проверки на этапе MAIL FROM
smtpd_sender_restrictions = permit_mynetworks,
# - разрешить при аутентификации (пользователи)
### permit_sasl_authenticated,
check_sender_access hash:/etc/postfix/sender_white_list,
# - отказать, если имя отправителя не в полной форме
# (должно быть не name или name@domain а name@domain.ltd)
reject_non_fqdn_sender,
# - отказать, если наш сервер не является "родным" для отправителя
# и домен отправителя не имеет в DNS записи MX или A, или если он
# имеет неверную запись MX (например, пустую)
reject_unknown_sender_domain,
# Проверка завязана на команде VRFY, которая может быть запрещена
# reject_unverified_sender,
permit
# ограничения, проверяемые на этапе RCPT TO:
smtpd_recipient_restrictions =
# - отказать при попытке отправки почты от чужого имени
reject_authenticated_sender_login_mismatch,
# - отсечь хосты, которые пытаются слать команды в конвейере
reject_unauth_pipelining,
check_client_access cidr:/etc/postfix/originating.cidr,
permit_mynetworks,
# permit_sasl_authenticated,
# whitelists:
check_client_access hash:/etc/postfix/sender_white_list,
check_client_access regexp:/etc/postfix/client_access_regexp,
# host check's:
reject_unknown_client,
reject_unknown_client_hostname,
# - отказать, если имя получателя не в полной форме (должно быть не name или name@domain а name@domain.ltd)
reject_non_fqdn_recipient,
# - отказать, если мы не являемся "родным" сервером для получателя и домен получателя не имеет
# в DNS записи MX или A, или если он имеет неверную запись MX (например, пустую)
reject_unknown_recipient_domain,
# - отказать, если домен-адресат: 1) не перечислен в списке доменов, для которых мы форвардим почту
# ($relay_domains) и не содержит команд переадресации (типа user@another@domain);
# 2) не является "нашим" (т.е. не перечислен в списках $mydestination,
# $inet_interfaces, $proxy_interfaces, $virtual_alias_domains, или
# $virtual_mailbox_domains ) и не содержит команд переадресации
# (типа user@another@domain).
# Это - традиционные правила, чтобы наш сервер не служил т.н. Open Relay, через который спамеры
# рассылают почту третьим лицам.
reject_unauth_destination,
# - отказать, если адрес получателя не указан в списках получателей домена
# (не перечислен в $local_recipient_maps или $virtual_alias_maps или
# $virtual_mailbox_maps или $relay_recipient_maps, в зависимости от того,
# в какой именно таблице найден домен получателя)
# Если письмо для многих получателей, но нет хотя бы одного в нашнй базе, то отказать
reject_unlisted_recipient,
# Greylist:
check_policy_service inet:127.0.0.1:10030,
permit
smtpd_data_restrictions =
permit_mynetworks,
# permit_sasl_authenticated,
reject_unauth_pipelining,
check_client_access regexp:/etc/postfix/add_auth_header.regexp,
permit
smtpd_end_of_data_restrictions =
permit_mynetworks,
# permit_sasl_authenticated,
# Отклоняем письма с нулевым отправителем (Bounce), у которых более одного получателя
reject_multi_recipient_bounce,
permit
Я вполне осознанно обрезал требование обязательной аутентификации, но оставил в обязательном порядке работу только из локальной сети. К сожалению Postfix не умеет реализовывать два фильтра, объединяя их по И. Идет последовательный вызов, то есть логика ИЛИ. И если снаружи кто сумеет каким либо образом подобрать пароль, то он получит доступ к почтарю. Мне этого не надо. Поэтому настраиваю postfix только на обслуживание "мой сети" (серые адреса, извне фиг доберешься).
Так вот, на этапе HELO/EHLO валится 99% спамеров. То есть postfix их отрубает даже до начала отправки ими каких либо команд. Напрочь. Редкая птица долетит до контент-фильтра в amavisd. Ну и тот свою лепту не преминет внести.
Хорошие у вас ограничения, я тоже сперва понапихал всего :)
Что некоторые письма перестали приходить. Пришлось обойтись минимальным конфигом.
А по поводу трафика, у нас раньше было много пользователей примерно 50-60, это сейчас у нас их всего ~15. Подразумеваю, что именно из за этого такие расхождения.
как-то тема на опрос не похожа.
вот у меня раньше стоял exchange 2010 и траффика было около 300мб в день принятых и 120 отосланных, а сейчас зимбра, и принятых около 5Гб, а отосланных 3.5.
и кому какое дело что юзеров стало не 25 человек а ближе к 1000...
Поэтому настраиваю postfix только на обслуживание "мой сети" (серые адреса, извне фиг доберешься).
юзеры удаленно не работают? елефонами, в конце концов не пользуются?
Мне тоже интересно, почему у Cruiser78 почтовые клиенты только в локальной сети.
А у нас работают всего 4-юзера удаленно с телефонами и ноутбуками, тип ящика у них IMAP. Некоторые пользователи проверяют свою почту через браузер.
Тема на опрос не похожа, потому что товарищи скрывают цифры.
[quote="Cruiser78"]Поэтому настраиваю postfix только на обслуживание "мой сети" (серые адреса, извне фиг доберешься).
юзеры удаленно не работают? елефонами, в конце концов не пользуются?[/quote]
Работают. Но - VPN. Если надо работать не в лавке - изволь подготовить рабочий комп (по моим правилам, а компьютерной безопасности я отдал без малого 15 лет жизни в весьма крупной конторе, так что знаю что и как) для ремутной работы. И тогда ты станешь участником "моей сети".
Работают. Но - VPN. Если надо работать не в лавке - изволь подготовить рабочий комп (по моим правилам, а компьютерной безопасности я отдал без малого 15 лет жизни в весьма крупной конторе, так что знаю что и как) для ремутной работы. И тогда ты станешь участником "моей сети".
жестоко. особенно учитывая современные технологии, когда можно обеспечивать безопасность доступа и без VPN
[quote=dyasny][quote="Cruiser78"]Поэтому настраиваю postfix только на обслуживание "мой сети" (серые адреса, извне фиг доберешься).
юзеры удаленно не работают? елефонами, в конце концов не пользуются?[/quote]
Работают. Но - VPN. Если надо работать не в лавке - изволь подготовить рабочий комп (по моим правилам, а компьютерной безопасности я отдал без малого 15 лет жизни в весьма крупной конторе, так что знаю что и как) для ремутной работы. И тогда ты станешь участником "моей сети".[/quote]
Теперь стало ясно, откуда пришла соль....)
жестоко. особенно учитывая современные технологии, когда можно обеспечивать безопасность доступа и без VPN
Зато дешево и практично. Какие есть угрозы (то есть строим модель нарушителя) от ремутного компьютера.
1. Ремутный (разъездной) ноут можно пролюбить в каком либо кабаке. Нарушитель получает доступ к телу ноута. Следовательно - надо сделать так, чтобы к данным, к ключам доступа, которые есть на этом ноуте он доступа не получил. Как? Криптография. Диск тотально зашифрован.
2. Юзер может на слабоконтролируемом ремутном компе словить какой-нибудь зловред, который шифрует (а точнее - корячит) все файлы, документы, до которых может дотянуться. Если он дотянется до файлов в лавке, то порушит их. А если он их будет крушить не подряд, а выборочно, например, с вероятностью 7%, то никакие архивные копии не спасут гиганта мысли. Секс по поиску порушенного и его восстановлению будет еще тот. Оно мне надо? Отсюда два подхода. Доступ к файловым ресурсам преимущественно через терминальный доступ (попробуй дотянись). Или, если хочется монтировать файловую раздачу на свой комп - ставим линукс.
Комбинируя 1 и 2 получаем типовую настройку - линукс на зашифрованных дисках для работы. Если нужны игры - dualboot c вынью. Остальное добавляется по вкусу.
Этот самый dualboot может быть слабым местом. Пусть и теоретически, но ведь может.
Этот самый dualboot может быть слабым местом. Пусть и теоретически, но ведь может.
Нет. Его стойкость определяется решением задачи криптоанализа. Сумеешь расшифровать рабочий диск, то есть подобрать ключ - молодец, возьми с полки пирожок. А не сумеешь...
Так что есть дуалбут или нет его - всё едино.
Зато дешево и практично. Какие есть угрозы (то есть строим модель нарушителя) от ремутного компьютера.
1. Ремутный (разъездной) ноут можно пролюбить в каком либо кабаке. Нарушитель получает доступ к телу ноута. Следовательно - надо сделать так, чтобы к данным, к ключам доступа, которые есть на этом ноуте он доступа не получил. Как? Криптография. Диск тотально зашифрован.
какое это отношение имеет в тотальному использованию VPN?
2. Юзер может на слабоконтролируемом ремутном компе словить какой-нибудь зловред, который шифрует (а точнее - корячит) все файлы, документы, до которых может дотянуться. Если он дотянется до файлов в лавке, то порушит их. А если он их будет крушить не подряд, а выборочно, например, с вероятностью 7%, то никакие архивные копии не спасут гиганта мысли. Секс по поиску порушенного и его восстановлению будет еще тот. Оно мне надо? Отсюда два подхода. Доступ к файловым ресурсам преимущественно через терминальный доступ (попробуй дотянись). Или, если хочется монтировать файловую раздачу на свой комп - ставим линукс.
и опять же - при чем тут доступ к почте?
у меня например зимбра, для доступа рекомендуется пользоваться не клиентами а веб панелькой - доступ к ней только по https. телефоны и клиенты на IMAPS
к терминалам доступ через цисковый VPN, плюс завинчены все гайки, вытащить документ из сервера можно только распечатав его (что видно в аудите) или сфотографировав экран
для телефонов кстати, разворачиваем MDM, и вебсенсовский DLP для всей фирмы.
какое это отношение имеет в тотальному использованию VPN?
Есть причина, есть следствие. У меня не только почта в VPN завернута. Но и иные сервисы. Например, Asterisk. Оплачивать звонки в Нигерию? Потому и закрываю всё единым механизмом. А чтобы исключить несанкционированный доступ к ключам VPN - шифруем диск, где они могут лежать. Я предпочитаю метод изоляции. Надежнее ножниц еще ничего не придумали. VPN как раз и обеспечивает нужную мне изоляцию.
А к DLP (если мы понимаем оно и тоже) у меня отношение, пока еще, осторожное. Это как порося стричь - визгу много, а шерсти мало. Настраивать DLP замучаешься, а толку чуть выше плинтуса. Ожидаемый эффект не адекватен трудозатратам.
Есть причина, есть следствие. У меня не только почта в VPN завернута. Но и иные сервисы. Например, Asterisk. Оплачивать звонки в Нигерию? Потому и закрываю всё единым механизмом.
имхо это неверный подход - в каждой организации есть множество технологий, и "заворачивать" их все в одну и ту же меру безопасности вряд ли верно. Мои юзеры например, если им придется при каждой проверке почты с телефона, подключаться к VPN, вбивая код на убогой клаве смартфона... да они мне все уши оттопчут - и правильно сделают.
плюс у меня есть еще и требования к внешним контракторам, которые должны закачивать файлы на наш файлер - давать им доступ в vlan где все юзеры vpn сидят? нет уж - только одноразовые пароли и SFTP.
a некоторые сервисы заперты настолько наглухо что никакой VPN не поможет - только source IP == bastion-server который сам по себе за двумя файрволлами.
что касается DLP, то тут нужен правильный подход. Эта система вряд ли способна полностью предотвратить уечку, да и не в этом ее задача. А задача ее в том, чтоб узнать как утечка произошла, если она все таки случится.
плюс у меня есть еще и требования к внешним контракторам, которые должны закачивать файлы на наш файлер - давать им доступ в vlan где все юзеры vpn сидят? нет уж - только одноразовые пароли и SFTP.
что касается DLP, то тут нужен правильный подход. Эта система вряд ли способна полностью предотвратить уечку, да и не в этом ее задача. А задача ее в том, чтоб узнать как утечка произошла, если она все таки случится.
1. А в чем особый смысл держать такой файлер на собственных ресурсах. У меня корпоративный WWW и FTP у хостера. И нет проблем.
2. По DLP - баловство это. Здесь я стою на позиции "заставь дурака Богу молиться, он и лоб расшибет". До тех пор, пока юзеры не станут сдавать свои головы в секретную часть - в своей голове они унесут всё что угодно. Самую большую ценность представляет не сам документ, а идея как сделать, концепция, подход. Человек может просто за рюмкой чая сболтануть (по доброте душевной) лишнее, а специалисту достаточно и этого "лишнего", чтобы понять суть секрета и раскрутить его на своих подходах. DLP - это дорогостоящаа имитация безопасности.
Войдите или зарегистрируйтесь, чтобы ответить.
