Предисловие
Про IronPort c170 я написал на хабре год назад. И это была моя первая статья, которая подарила мне инвайт. К сожалению, с того времени, на хабре не появилось ни одной (!) статьи про эту железку, что, я считаю, непозволительно для такого ресурса, как хабр. Для начала, я, конечно, напомню про свою первую статью: habrahabr.ru/post/148317
Она обзорная и не делающая никаких выводов. Но за год я немного разобрался с железкой, научился некоторым хитростям и встретился с ошибкой прошивки… и вообще теперь я готов рассказать про нее нечто больше, чем ничего :)
Для начала я бы хотел опять показать, какое количество спама в мире ходит.
В млрд писем в день. Всего спам составляет примерно 85% от общего трафика почты в мире.
Несмотря на низкую эффективность, его количество не собирается уменьшаться. Блин, да кто его вообще читает? Неужели люди действительно звонят по этим телефонам? Ну да ладно, отвлекся…
Итак. Начнем с того, что вспомним общую дефолтовую методику отсеивания спама. В первую очередь, IronPort заботит не тело письма, а его отправитель. Адрес, подсеть для него имеет большую роль и для каждого источника железка выставляет баллы от -10 до +10. Баллы IronPort берет с сайта senderbase.org. Если просто зайти на сайт и ввести адрес своего исходящего почтового сервера, можно увидеть лишь краткое poor, good или neutral. Но IronPort знает больше этого и выставляет оценку вплоть до десятых. По-умолчанию, система разрывает smtp сессию еще до передачи данных, если рейтинг сервера меньше, чем -3.
Как я улучшал антиспам фильтр
Этот раздел скорее для тех, кто уже владеет железкой
Меня это устраивало, я видел что за письма приходят с таким рейтингом и если у клиента рейтинг вообще отрицательный, это определенно значит, что из этого источника было замечено много писем с плохим содержимым и доверять такому серверу стоит с осторожностью, а лучше вообще не доверять.
Пока… долгожданное письмо для директора не было просто дропнуто. И это я посчитал неприятным событием. Я быстренько добавил сервера в белый список и аккуратно сообщил директору, что как-бэ… за спам посчитали письмо и можно посылать его еще раз! Все обошлось, молнии не стали метать и я стал думать, как же мне модернизировать систему так, что бы и спам не приходил и письма не дропал.
Я начал с простого: отделил трафик -3, но не стал его уничтожать, а создал специальный карантин, в который стал закидывать письма. Это было самое простое, но главное, это защитило меня от безвозвратного уничтожения писем. Для карантина я выделил максимально оставшееся место на дисках в 2.3ГБ(не знаю почему так мало, но больше нельзя) со сроком хранения в 50 дней. И теперь в среднем этот карантин полон на 55%.
Однако этого было мало. Я замечал, что проходит непозволительно много спама с отрицательным рейтингом где-то от -0.5 до -3. Это было печально, потому что просто так их отсеивать нельзя — несколько процентов писем из них были доброкачественные. Так как все-равно ни кто весь текст не читает, спешу сообщить, что полотенчик одоряэ этот пост. Однако я заметил, что ни кто из спам писем не содержит верных PTR записей, однако все правильные письма с таким рейтингом содержат верную связку PTR-A. Однако моему разочарованию все же не было предела. В стандартной фильтрации нет возможности настроить фильтр по источнику группы отправителя. Можно сразу дропнуть письмо, а отфильтровать нельзя! Глупость.
Пришлось пойти дальше и сдуть пыль с пдф инструкции и посмотреть что же есть еще в настройках. Для того, что бы решить проблему фильтрации для без PTR-ных источников, пришлось углубиться в недры неприветливого командного интерфейса.
В итоге пришлось создать особое правило фильтрации. Выглядит оно довольно просто:
Текст конфига
Num Active Valid Name
1 Y Y DNS_Fail_ToSpam
DNS_Fail_ToSpam: if sendergroup == "UNVERIFIED_LowScore" {
quarantine("trash");
}И делает как раз то что надо — если письмо приходит из группы отправителей UNVERIFIED_LowScore, то оно уходит в тот самый особый карантин.
В итоге, по сравнению с изначальной настройкой, где письма меньше -3 просто уничтожались, а выше доходят почти все, мои настройки показали более высокий уровень фильтрации, а также непревзойденную устойчивость к потере писем, даже самый отъявленный треш будет храниться… на всякий случай:) Только письма с неверным адресатом убиваются сразу.
Наблюдение: С того момента, как я начал принимать все smtp сессии и письма с ними, количество соединений резко уменьшилось! И уменьшилось в несколько раз. Из чего я сделал вывод, что спамерам все равно какие у вас временный задержки сессий, дропы и все остальное, они будут пытаться послать письмо много раз, а не один, как это считается.
Проблема с прошивкой
В какой-то момент на почту от железки стали присылаться очень странные письма. Что-то вроде такого:
Текст письма
The Critical message is:
An application fault occurred: ('egg/coro_postgres.py _simple_query|756', "<class 'coro_postgres.QueryError'>", '_simple_query (ERROR 53000: could not write block 14 of 17144/17171 blind: Too many open files in system)', '[egg/quarantine_hermes.py _expiration_main|1980] [egg/quarantine.py expire_all_messages|771] [egg/quarantine.py _process_transaction|871] [egg/quarantine.py _expire_messages|1355] [egg/quarantine.py _query|1669] [egg/quarantine.py _call_db|1643] [egg/quarantine.py _db_query|1726] [egg/coro_postgres.py query|346] [egg/coro_postgres.py _simple_query|756]')
Version: 7.6.1-022
Serial Number: 5057A8E1583B-FGL161740BG
Timestamp: 13 Dec 2012 00:32:18 +0400
To learn more about alerts, please visit our Knowledge Base. In many cases, you can find further information about this specific alert. Please click the Knowledge Base link after logging into our Support Portal at:
www.cisco.com/web/ironport/index.html
If you desire further information, please contact your support provider.
To open a support request for this issue, access the IronPort C170 and issue the «supportrequest» command. The command sends an email with diagnostic information directly to Cisco IronPort Customer Support to facilitate a rapid diagnosis of the problem.
Thank you.
An application fault occurred: ('egg/coro_postgres.py _simple_query|756', "<class 'coro_postgres.QueryError'>", '_simple_query (ERROR 53000: could not write block 14 of 17144/17171 blind: Too many open files in system)', '[egg/quarantine_hermes.py _expiration_main|1980] [egg/quarantine.py expire_all_messages|771] [egg/quarantine.py _process_transaction|871] [egg/quarantine.py _expire_messages|1355] [egg/quarantine.py _query|1669] [egg/quarantine.py _call_db|1643] [egg/quarantine.py _db_query|1726] [egg/coro_postgres.py query|346] [egg/coro_postgres.py _simple_query|756]')
Version: 7.6.1-022
Serial Number: 5057A8E1583B-FGL161740BG
Timestamp: 13 Dec 2012 00:32:18 +0400
To learn more about alerts, please visit our Knowledge Base. In many cases, you can find further information about this specific alert. Please click the Knowledge Base link after logging into our Support Portal at:
www.cisco.com/web/ironport/index.html
If you desire further information, please contact your support provider.
To open a support request for this issue, access the IronPort C170 and issue the «supportrequest» command. The command sends an email with diagnostic information directly to Cisco IronPort Customer Support to facilitate a rapid diagnosis of the problem.
Thank you.
Текст постоянно менялся. Некоторое время не обращал на них особенного внимания и считал, что пока письма фильтруются можно не волноваться. Все было нормально, пока письма фильтроваться перестали :) IronPort в какой-то момент просто перестал назначать баллы серверам отправителям и получилось так, что «астрологи объявили неделю длинного МПХ. Количество спама выросло в 10 раз».
Ну я и сделал как написано: обратился в техподдержку.
Сначала со мной начал разговор некий Ahmed Aaref. Вероятно, из солнечной Индии. Но потом, когда открыли кейс, со мной связался уже сотрудник из Германии. Затем, были долгие мытарства что бы настроить специальный секьюрный канал для техподдержки. Это все ни как не получалось и сошлись на том, что я просто им дам полный SSH доступ :) Не очень безопасно, подумал я, да только стандартными средствами выйти за пределы IronPort-а невозможно. После этого инженер начал ковыряться. И, о чудо, все заработало.
Однако до глубины души меня поразила причина сбоя:
Решение техподдержки
I have investigated the issue further and can confirm that the appliance encountered known defect 86843 after upgrade to AsyncOS version 7.6.1-022, where a subfolder for the reputation engine was not created. This did not cause any issue at the time after the upgrade, but in the morning of December 12, an update of the reputation engine has taken place, causing the engine not being able to restart properly due to the missing folder.
In order to solve the issue, I have created the missing subfolder on the appliance. In order to restart the reputation engine properly, the appliance needs to be rebooted. Could you please go ahead and reboot the unit gracefully? After the reboot, the appliance should work properly again and retrieve the SenderBase Reputation Scores!
In order to solve the issue, I have created the missing subfolder on the appliance. In order to restart the reputation engine properly, the appliance needs to be rebooted. Could you please go ahead and reboot the unit gracefully? After the reboot, the appliance should work properly again and retrieve the SenderBase Reputation Scores!
Тонны страшных ошибок, а причина в… подпапке. Тем не менее, в итоге хочу заявить, что общение с техподдержкой мне понравилось. Вели себя хоть и в какой-то мере шаблонно, но все равно чувствовалось, что там люди и они хотят помочь. Они понимали мой карявый английский и я при этом понимал их)
Что мне не понравилось после года эксплуатации
- Все-таки недостаточно продуманный веб-интерфейс, который заставляет придумывать костыли. Может быть это сделано и специально, что бы привлекать инженеров для выполнения более сложных задач.
- Отсутствие поддержки агрегации каналов LACP.
- Невозможность сделать обратную проверку отправителя.
- Недостаточно гибкие правила. Хотелось бы самостоятельно управлять оценками, добавлять новые инструменты проверки для увеличения или уменьшения оценки.
Что порадовало? Стоит ли он свое?
Не знаю, стоит ли он своих денег) Стоимость все-таки немаленькая. Около 20-30$ за пользователя в год. Может быть сейчас я бы поискал и другие решения, однако за все время реальная проблема была только одна. И она описана выше. Если бы я не проводил обновление прошивки, она бы и во все не появилась. Больше проблем с устройством не было. Стоит, жужит себе в серверной, есть не просит. Порой я забываю на какие порты настраивал административную часть и вообще забываю где что находится, когда что-то требуется подкрутить. В этом плане все шикарно :)
Спам же фильтрует достаточно качественно, а личный карантин позволяет избавить администратора от ручных действий по извлечению писем, пользователь может сам разблокировать письмо в еженедельном отчете по своему карантину.
Спасибо всем, кто дочитал. Если у кого-то будут вопросы по железке, всем отвечу. В пределах того, что знаю, конечно :)
Ну и добавляю скрин со своей статистикой.
