Courier Mail Server Forum Index Courier Mail Server
www.courierms.ru
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

v2,3| DoS-уязвимость почтовых серверов. Кольцевой форвардинг

 
Post new topic   Reply to topic    Courier Mail Server Forum Index -> Готовые решения
View previous topic :: View next topic  
Author Message
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 21 Nov 2005 9:51 (Mon)    Post subject: v2,3| DoS-уязвимость почтовых серверов. Кольцевой форвардинг Reply with quote

Общие принципы DoS-атак.
Если отбросить рассмотрение различных механизмов организации DoS-атак (Denied of Service — отказ обслуживания), то общим в них является принуждение атакуемого сервера выполнять некие нестандартные действия, что приводит к нарушению его работы, засорению каналов связи, повышению нагрузки на процессор, бесконтрольному расходованию оперативной памяти и дискового пространства.
Значительную часть DoS-атак составляют действия, вынуждающие сервер посылать по некоторым адресам ответы, размеры которых превышают размеры запроса. Если же такой ответ заставить выдавать не на некий абстрактный несуществующий адрес, а самому себе и при этом такой ответ является в свою очередь тоже запросом, требующего следующего ответа, то в результате произойдет зацикливание и постепенное увеличение трафика.
Оказывается, почтовые сервера предоставляют обильную почву для такого рода атак. Сами механизмы релея и форвардинга таят в себе возможности создания закольцованной передачи почты.
Только сначала поясню значение этих терминов:

Форвардинг (англ. forwarding) — пересылка или копирование входящей почты по другим почтовым адресам.
Релей (англ. relay) — 1) Процесс пересылки почтового сообщения не напрямую от отправителю к получателю, а через промежуточный сервер. 2) Промежуточный почтовый сервер, осуществляющий такую пересылку.
Процесс релея используется в следующих случаях:
    1. Отправитель не в состоянии самостоятельно разрешить доменное имя получателя в IP-адрес его почтового сервера или шлюза. В этом случае используется релей-посредник, обладающий такой возможностью.
    2. Получатель запретил прямую доставку с целью проведения дополнительной централизованной обработки приходящей почты на промежуточном релее.
    3. Отправитель использует промежуточный релей для централизованной обработки исходящей почты.
    4. Отправитель использует релей для скрытия или затруднения определения своего адреса. Данный метод широко используется вирмейкерами и спамерами.

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 21 Nov 2005 9:53 (Mon)    Post subject: DoS-атака на публичные сервера. Reply with quote

DoS-атака на публичные сервера.
Организовать подобную DoS-атаку на публичный сервер, обладающий Web-интерфейсом, ранее не составляло труда даже ленивому. Примеры таких атак упоминаются на различных сайтах. Правда, в последнее время все более-менее серьезные сервера защищены от подобных действий. Yandex, например, разрешает форвардинг только после подтверждения от получателя. Rambler не требует явных подтверждений, но, видимо, в нем установлена проверка и запрет на получение почты аккаунтом от самого себя (в т.ч. через цепочку других аккаунтов). Во всяком случае, больше одного круга посты по закольцовке не делали.
Суть этого типа DoS-атак проста:
На любом публичном сервере (или на нескольких) организуются почтовые ящики с форвардингом друг на друга по замкнутой цепочке. На один из них посылается несколько тысяч небольших писем. И начинают эти посты скакать с одного ящика на другой, как блохи, постепенно жирея за счет добавляемых в заголовок полей. Рано или поздно их размер превысит допустимый на этом сервере (если там не отменили по непонятным ограничениям этот лимит), но и в этом случае DoS-атака не захлебнется. Ведь обычно в таком случае обратно отправляется письмо с указанием превышения размера, которое тоже начинает курсировать по замкнутому маршруту.
Как вариант, можно организовать 3-4 ящика, с каждого из которых производится форвардинг на на один следующий, а на все остальные. В этом случае процесс уже не будет линейным. Количество пересылаемых постов будет увеличиваться в геометрической прогрессии (DoS-атака с умножением).
Также возможно кроме организации взаимного форвардинга дополнительно указать форвардинг на сторонний ящик. Этот ящик вскоре будет завален всяким хламом.
Повторю, что сам я проверил на возможность проведения такой атаки только почтовые системы Yandex и Rambler. В обоих случаях безрезультатно. Остальные публичные сервера не проверял. Жалко времени, да и поймать могут в случае удачи. И доказывай потом, что действовал исключительно из научного интереса.
Такой вариант DoS-атаки для Courier Mail Server v2.00 не страшен по причине отсутствия публичного Web-интерфейса и форвардинга. Более сложные варианты пересылки, основанные на организации закольцованных заданий приема почты, теоретически возможны, но требуют взлома сервера для доступа к файлам конфигурации. Практически же процесс выполнения таких заданий будет выполняться несколько реже, чем форвардинг (максимум 1 раз в минуту). Да и возможности открываются в этом случае такие, что смысл в проведении DoS-атаки теряется. Но при создании собственных публичных почтовых систем с поддержкой форвардинга следует предусмотреть проверку на закольцовку и исключение ее возможности.

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 21 Nov 2005 9:55 (Mon)    Post subject: DoS-атака на открытый релей. Reply with quote

DoS-атака на открытый релей.
Обычно провайдер предоставляет своим клиентам почтовый релей без доступа к нему для настроек и создания новых ящиков. Но и в этом случае возможно проведение атаки.
Основывается она на присутствии некорректных MX-записей на DNS для некоторых доменов. Видимо, купив домен, его администратор еще не успел развернуть почтовый сервер, а раз так, то оставляет MX-запись, указывающую на некую заглушку с IP-адресом 127.0.0.1. При попытке отправить почту в этот домен, она будет отправлена … самому себе. Вернее через самого себя, как через очередной релей.
Теперь представим, что на почтовый адрес в таком домене посылается письмо через открытый релей. Этот релей пытается определить адрес почтового шлюза получателя, но вместо реального адреса получает 127.0.0.1. Отправив это письмо по этому адресу, а на самом деле самому себе, он получит его снова и опять попытается отослать получателю. Так будет продолжаться весьма долго. Причем в письмо будут добавляться все новые и новые поля "Received" и его размер будет расти и расти.
К сожалению, мне не удалось придумать механизм DoS-атаки с умножением. Может быть кто-нибудь сумеет сделать это.
Простой и надежный способ защитить релей от атаки такого рода — запретить ему отсылать "вовне" посты, пришедшие по SMTP с 127.0.0.1. Но и он не является надежным средством защиты от такого рода атак.
Дело в том, что при невозможности обработать принимаемый пост, почтовый SMTP-сервер получателя выдает SMTP-клиенту код ошибки. Если в свою очередь этот SMTP-клиент является частью некоего почтового сервера-релея, то обычно данным сервером генерируется письмо-оповещение, которое направляется по адресу отправителя.
А теперь представим себе, что отправитель подменил свой адрес, который передается в поле "From:" и в команде "MAIL FROM" (но не обратный адрес, передаваемый в поле "Reply-To"), на фиктивный адрес из такого домена, содержащую ошибочную MX-запись. Значит, при запрете пересылки писем с адреса 127.0.0.1 будет выдан код ошибки, отправленный самому себе. По этому коду будет сформировано оповещение, которое сервер попытается отослать отправителю атакующего поста. Но обнаружит там опять адрес 127.0.0.1! Таким образом, вновь будет предпринята попытка зацикливания отправки. Правда, в письме-оповещении не обязательно будет стоять реальный адрес почтового сервера, совершившего его. Скорее всего, поле "From:" , будет просто какая-то смысловая информация, а в команде "MAIL FROM" параметр вообще будет отсутствовать. Это делается как раз специально, чтобы избежать зацикливания обмена оповещениями между почтовыми серверами. В результате теперь новое письмо-оповещение не будет никуда доставлено и атака закончится еле начавшись.

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!


Last edited by GrAnd on 21 Nov 2005 10:15 (Mon); edited 1 time in total
Back to top
View user's profile Send private message
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 21 Nov 2005 10:08 (Mon)    Post subject: DoS-атака на оконечный сервер. Reply with quote

DoS-атака на оконечный сервер.
Предположим теперь, что на сервере какой-либо организации релей запрещен. Защищен ли он теперь от DoS-атак закольцовкой? Отнюдь. Ведь смысл такой атаки по отношению к почтовому серверу состоит как раз в том, чтобы вынудить его совершить какие-либо ответные действия. Это не обязательно релей-пересылка, а, как показывалось выше, например, оповещение.
Пусть на атакуемый сервер приходит письмо, размер которого превышает максимально допустимый размер. Или почтовый ящик получателя переполнен. Или получатель в данном домене не зарегистрирован и при этом включена функция выдавать оповещение о несуществующих пользователях. Тогда будет сформировано соответствующее письмо-оповещение, которое будет отправлено по обратному адресу. Но если обратный адрес фиктивный и принадлежит домену с некорректной MX-записью, и при этом на почтовом сервере разрешена отправка "вовне" с адреса 127.0.0.1, то возникнет ситуация аналогичная предыдущей. Оповещение будет бесконечно передаваться самому себе, постепенно увеличиваясь в размерах. При этом размер log-файлов будет расти катастрофически. Будет расти нагрузка на канал передачи и на процессор. Через несколько часов или дней, если не принять мер, сервер начнет заметно тормозить, а затем тихо умрет. При этом его не спасут и перезагрузка — только вычищение таких писем из очереди отправки.
Чтобы не запрещать релей вовне с адреса 127.0.0.1 можно использовать другой способ, заключающийся в помещении в заголовок пересылаемого поста или формируемого оповещения специальных X-полей, анализируя которые антиспам-система сервера может заблокировать получение и дальнейшую пересылку письма. На практике опробовано включение X-поля с оригинальным содержимым (DNS-имя почтового сервера) в оповещение и отсеивание таких писем антиспам системой Courier Mail Server. Это позволило впредь избегать подобных DoS-атак, которые уже до этого 2 раза обрушивали оконечный почтовый сервер предприятия. Правда при этом использовалась особенность CMS помещать оповещения для локальных получателей в их почтовые ящики минуя проверку антиспамом.
Реализован этот способ был следующим образом:
В шаблон оповещения было добавлено поле X-Autoreply.
Code:
From: "Mail Daemon" <postmaster>
To: %Sender%
Subject: Message is not delivered
X-Autoreply: Delivery system mx.mydomain.ru
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="%MIMEBoundary%"

В черный список добавлено правило
Code:
X-Autoreply:mx.mydomain.ru

Т.к. в белом списке присутствовали правила принимать почту от автоответчиков
Code:
From:DAEMON
From:post
,
то они были изменены соответствующим образом, чтобы письмо, сформированное автоответчиком не разрешалось по белому списку автоматически
Code:
From:DAEMON;From!:"Mail Daemon" <postmaster>
From:post;From!:"Mail Daemon" <postmaster>

Данный способ, в принципе, может быть использован и для исключения кольцевого форвардинга, когда возможность форвардинга будет реализована в Courier Mail Server.
Осталось добавить, что этот способ с использованием X-поля, был предложен Романом Ругаленко (NAMOR), а я его только доработал и реализовал.

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!


Last edited by GrAnd on 21 Nov 2005 10:23 (Mon); edited 1 time in total
Back to top
View user's profile Send private message
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 21 Nov 2005 10:10 (Mon)    Post subject: Выводы. Reply with quote

Выводы.
    1. Для предотвращения кольцевого форвардинга почтовый сервер должен запрещать поступление в почтовый ящик писем, уже прошедших через него, либо использовать иные механизмы, не позволяющие создавать кольцевой форвардинг.
    2. Наиболее действенным способом борьбы с DoS-атаками, основанными на подмену адреса получателя на 127.0.0.1, является запрет релея вовне с 127.0.0.1.
    3. Альтернативой блокирования релея с адреса 127.0.0.1 может служить использование в заголовках пересылаемых постов или формируемых оповещений специальных X-полей, позволяющих засечь повторное прохождение письма через почтовый сервер. Данный способ расчитан на отсеивание таких писем антиспам-системой, анализирующей заголовки проходящих писем, просто интегрируется с ней и может быть использован и для предотвращения кольцевого форвардинга.

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 22 Mar 2007 16:34 (Thu)    Post subject: Еще один обнаруженный вариант. Reply with quote

Еще один обнаруженный вариант.
Некоторое время назад с одного из локальных компьютеров было отправлено письмо с адреса lebddv@hvac.com.tw на адрес jessica@hvac.com.tw. Каким образом это было сделано, еще предстоит разбираться. Скорее всего компьютер был зомбирован, но поверхностный анализ пока не выявил ничего подозрительного.

Но дело не столько в этом, а в том, что можно было обнаружить при попытке определить адрес почтового шлюза домена hvac.com.tw. При помощи nslookup было видно, что сам домен настроен безобразно. Но, кроме всего прочего, среди его адресов также числятся такие как 192.168.0.1 и 169.254.91.143 - т.е. из очень "серых" зон. Кстати, видимо по этому домену ведутся активные работы, т.к. состав адресов и их порядок часто меняется ...

В результате этого почтовый сервер разрешал адрес получателя в 192.168.0.1. А, как известно, в малых и средних офисных локальных сетях почтовый сервер часто находится на шлюзе, имеющем именно такой IP. Поэтому и возникала ситуация, аналогичная описанной выше с адресом 127.0.0.1. Только теперь исключить адрес 192.168.0.1 из локальной группы IP-адресов нельзя, т.к. на нем могут быть установлены дополнительные службы, обращающиеся к почтовому серверу.

В качестве выхода из ситуации я добавил к черному списку антиспама следующее правило:
Code:
Received:"from DNS-имя_почтового_хоста ([192.168.0.1])"

где DNS-имя_почтового_хоста - имя хоста, как оно указано в CMS в разделе "Настройки|Общие".

Один раз такое письмо все-же будет отправлено, но вот затем при следующих попытках будет обнаружено данное условие и письмо будет отвергнуто как спам. Разумеется, затем будет сформировано письмо-уведомление, отправленное самому себе. Но оно тоже не будет циркулировать долго, т.к. по стандарту не имеет отправителя.

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
GrAnd
CMS Master
CMS Master


Joined: 21 Oct 2005
Posts: 766
Location: г. Коломна

PostPosted: 05 Dec 2008 18:11 (Fri)    Post subject: Случайная закольцовка из-за ошибок в настройках. Reply with quote

Случайная закольцовка из-за ошибок в настройках конфигурации сети.
Недавно наш сервер вновь подвергся закольцовке отправки. Причем, возникла она не в результате намеренной DoS-атаки, а в результате особенностей конфигурации и настроек сети и стечению обстоятельств.

Особенности были такими:
  1. На шлюзе был установлен MTA, выполняющий фильтрацию проходящей почты от спама. Прошедшая фильтрацию почта направлялась на основной MTA в сети. Подробнее можно прочитать здесь.
  2. Псевдоним основного MTA на локальном DNS был таким же, как и имя почтового шлюза домена на внешних DNS. Т.е. на локальном DNS-сервере был заведен псевдоним mx.mydomain.ru для локального адреса 192.168.х.х, а на внешних DNS такое же имя было привязано к внешнему интерфейсу шлюза 88.86.х.х.
  3. Хотя в локальной сети был поднят локальный DNS, в настройках которого были указаны адреса внешних доверенных DNS-серверов, на внешнем интерфейсе шлюза так же были прописаны адреса внешних DNS. То ли это осталось в память о смутных временах, когда локального DNS не было, то ли было просто сделано для того, чтобы со шлюза можно было бы подключиться к Инету, даже если локальный DNS упадет.
  4. Ну и разумеется, это даже особенностью не назвать (скорее это является правилом), на MTA, расположенном на шлюзе (его роль исполняет трехпользовательская версия CMS), было указано использовать DNS-сервера, прописанные в системе. Т.к. в настройках интерфейсов были прописаны и локальный и внешние сервера, то он сначала пытался запросить локальный DNS, а при отсутствии ответа обращался к внешним.

И вот в один не очень прекрасный день, который был, как назло выходным, локальный DNS-сервер все-таки упал.
В результате МТА на шлюзе попытался переслать не отвергнутое письмо на основной MTA и с этой целью запросил DNS разрезольвить его имя mx.mydomain.ru в адрес. Но локальный DNS не ответил. Поэтому запрос был повторен на внешний DNS. И тот сообщил адрес 88.86.х.х. Т.е. вместо локального адреса был получен адрес внешнего интерфейса шлюза. И письмо было отправлено на него. Т.е. самому себе! И так снова и снова. Затем количество писем стало увеличиваться. Не выдержала система антиспам-фильтрации и отказалась помечать письма как спам. В результате весь поток спама хлынул через данный MTA без отсева вновь на него же. Кроме того, при каждой пересылке письма слегка увеличивались в размерах за счет добовляемого поля "Received:". В результате размер логов возрастал катастрофически. Если в обычный день размер логов редко превышал 30-40Мб, то за каждые сутки такой нештатной работы их размер составлял более 1Гб.

Выводы:
  1. Если в сети имеется локальный DNS-сервер, настроенный на пересылку неразрезольвенных запросов на внешние доверенные сервера, не следует прописывать адреса внешних DNS на внешнем интерфейсе шлюза. Повышение надежности здесь весьма спорное, а всяких коллизий может быть предостаточно.
  2. Так же при настройке сети не следует давать почтовому серверу локальное имя, совпадающее с внешним именем почтового шлюза.

_________________
Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Courier Mail Server Forum Index -> Готовые решения All times are GMT + 4 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group