Крис Касперский - ТЕХНИКА СЕТЕВЫХ АТАК
Но если сервер не снабжен функцией определения IP адреса клиентов, ему не остается ничего другого, кроме как воспользоваться информацией, предоставленной самим отправителем, поверив тому на слово. Поэтому, существует возможность сообщения подложных данных, и, выдачи себя за локального пользователя, имеющего право отправки сообщений по любому адресу.
Клиент дважды указывает свой адрес: приветствуя сервер, командой “HELO” он сообщает свой домен, а в поле “MAIL FROM” приводит собственный обратный адрес. Некоторые сервера проверяют одно из этих значений, а некоторые оба одновременно.
В эксперименте, приведенном ниже, отправитель сообщает не свой собственный домен, а домен владельца сервера, и в качестве обратного адреса, использует один из адресов локальных пользователей сервера (чтобы его узнать, необходимо получить с этого сервера хотя бы одно письмо, или попробовать выяснить имена зарегистрированных пользователей методом перебора):
· 220 WITHELD FTGate server ready -Fox Mulder
· HELO dore.on.ru
· 250 Ready
· MAIL FROM:« [email protected]»
· 250 « [email protected]» Sender Ok
· RCPT TO:« [email protected]»
· 250 Recipient Ok
В результате такого подлога, сервер оказался введен в заблуждение и согласился доставить письмо. Очевидно, подлинный отправитель сообщения не может быть установлен по заголовку, поскольку в нем находится только та информация, которую отправитель пожелал оставить самостоятельно.
Для массовой рассылки лучшего способа и придумать невозможно, но вот для обычной переписки такая методика не подходит. Ведь ответ на письмо возвратится по адресу [email protected]! Этого можно избежать, если добавить в заголовок поле “Reply-To”, содержащее истинный адрес отправителя (тот, который он захотел оставить сам). Это может выглядеть, например, таким образом:
· 220 WITHELD FTGate server ready -Fox Mulder
· HELO dore.on.ru
· 250 Ready
· MAIL FROM:« [email protected]»
· 250 « [email protected]» Sender Ok
· RCPT TO:« [email protected]»
· 250 Recipient Ok
· data
· 354 Start mail input; end with «CRLF».«CRLF»
· Subject:TEST
· Reply-To:« [email protected]»
·
· Hello!
·.
· 250 Ok Message queued
· quit
· 221 dore.on.ru Service closing transmission channel
Заголовок такого письма должен выглядеть приблизительно так:
· Received: from relay1.aha.ru ([195.2.83.105] verified)
· by aha.ru (CommuniGate Pro SMTP 3.1b2)
· with ESMTP id 3882573 for [email protected]; Mon, 05 Jul 1999 20:01:40 +0400
· Received: from warlock.miem.edu.ru (miem-as.ins.ru [195.19.18.226])
· by relay1.aha.ru (8.9.3/8.9.3/aha-r/0.04B) with ESMTP id UAA07173
· for « [email protected]»; Mon, 5 Jul 1999 20:01:40 +0400 (MSD)
· Received: from dore.miem.edu.ru (rtuis.miem.edu.ru [194.226.32.50])
· by warlock.miem.edu.ru (8.9.3/8.9.3) with ESMTP id UAA00637
· for « [email protected]»; Mon, 5 Jul 1999 20:00:42 +0400 (MSD)
· Received: from fox by dore.on.ru (FTGate 2, 1, 2, 1);
· Mon, 05 Jul 99 20:02:30 +0400
· Message-ID: « [email protected]»
· From: « [email protected]»
· To: « [email protected]»
· Subject: TEST
· Reply-To:« [email protected]»
· Date: Mon, 5 Jul 1999 20:02:29 +0400
·
· Hello!
При попытке ответить отправителю, почтовый клиент получателя извлечет содержимое поля “Reply-To” и отправит письмо по указанному в нем адресу. Именно этим и пользуются спамеры для достижения полной анонимности с одной стороны, и возможности получения ответов от заинтересованных лиц - с другой.
Если внимательно посмотреть на заголовок письма, в нем можно обнаружить несколько строк “Received”. Их оставили транзитные сервера, иначе называемые Релеями (от английского relay).
Любой почтовый клиент может отправить письмо напрямую. Однако для этого придется собственноручно указать в настойках сервера исходящей почты адрес получателя.
Например, чтобы отправить письмо для [email protected] с помощью “OutLock Express” придется зайти в «Учетные записи» (меню «Сервис»), выбрать «Свойства» и перейти к закладке «Серверы», задав для исходящей почты сервер «computerra.ru».
Очевидно, это слишком утомительно и непрактично. До тех пор, пока программное обеспечение не научиться выполнять такую операцию автоматически, пользователи будут вынуждены пользоваться прежними методами.
Работа типичного мелкокорпоративного сервера исходящей почты выглядит приблизительно так: получив в свое распоряжение письмо, он тут же устанавливает соединение с почтовым ящиком получателя, и отправляет послание. При этом он сталкивается с теми же затруднениями, что и обычный клиент. Поэтому, широко используется ретрансляция сообщений. Если письмо по каким-то причинам не может быть передано напрямую, оно передается ретранслятору.
Ретранслятор - точно такой же SMTP-сервер, как и все остальные, обсуждаемые в этой главе. В зависимости от настоек сервера маршрут пересылки письма может варьироваться. Одно сообщение может отправляться напрямую, а другое - долго «крутиться» на Релеях. Доверие это прекрасно, но только когда не касается вопросов безопасности. Кто рискнет доверять ретрансляторам неизвестного происхождения? Тем более, дальнейший маршрут письма каждым из транзитных серверов определяется самостоятельно, и нет никаких гарантий, что в эту цепочку не вклиниться злоумышленник.
Но протокол SMTP позволяет отправителю самостоятельно задавать маршрут пересылки сообщения Параметр команды “RCPT TO” может содержать не только адрес получателя, но и путь ретрансляции!
Формат его следующий:
· RCPT TO:«@s1,@s2,@s3,@sn: [email protected]»
где s1,s2,s3,sn - имена (или IP адреса) промежуточных хвостов, а [email protected] почтовый ящик получателя. В первую очередь сообщение передается узлу s1 - самому левому серверу в цепочке. Он модифицирует параметр команды RCPT TO, «выкусывая» из нее имя своего узла:
· RCPT TO:«@s2,@s3,@sn: [email protected]»
Затем, извлекается адрес следующего получателя - s2. Если сервер s1 не берется за доставку корреспонденции серверу s2, письмо возвращается назад отправителю с сообщением об ошибке. В противном случае процесс повторяется до тех пор, пока сообщение не окажется в почтовом ящике получателя.
Недостаток такой схемы заключается в том, что некоторые SMTP сервера для пересылки на очередной хвост могут прибегать к услугам своих собственных ретрансляторов. Таким образом, гарантируется, что письмо при успешной доставке посетит все заданные узлы в указанном порядке. Но не всегда выполняется прямая пересылка между соседними хвостами в цепочке.
Поэтому, задача подбора транзитных серверов осложняется. Каждый из них должен быть не только защищен от посторонних вторжений, но заведомо не пользоваться услугами сторонних ретрансляторов.
К сожалению, большинство почтовых клиентов, проверяя корректность ввода адреса получателя, считают такую операцию синтаксически неправильной и отказываются отправлять письмо. Приходится в очередной раз запускать telnet и передавать сообщение вручную.
Узнать какие именно команды поддерживаются конкретным SMTP сервером можно с помощью «HELP», а подробнее о назначении каждой из них “HELP command”.
Для получения детальной информации о командах протокола SMTP можно обратиться к RFC-788, RFC-821, RFC-822, RFC-1341, RFC-1342, RFC-1426, RFC-1521, RFC-1806, RFC-1830, RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049, RFC-2076.
Протокол IMAP4
O В этой главе
O Достоинства протокола IMAP4
O Основные команды
O Чтение сообщений
Протокол IMAP4 (Internet Mail Access Protocol) сильно уступает в популярности POP3, но значительно превосходит его функциональности. Однако никакого противоречия здесь нет. В отличие от POP3, IMAP4 предполагает хранение и обработку сообщений на сервере, откуда вытекает необходимость наличия постоянного канала связи. Большинство пользователей не могут позволить себе подобную роскошь, и потому IMAP4 в основном используется в локальных корпоративных сетях, где постоянная связь с сервером - не проблема.
Большинство получателей, не имеющих постоянного соединения с Internet, предпочитают не хранить почту на сервере, а забирать ее на свой локальный ящик и обрабатывать сообщения собственными клиентскими средствами.
Совсем иная ситуация складываться в локальных корпоративных сетях, где постоянная и стабильная связь с сервером - не проблема. Корреспонденция, хранящаяся на сервере, доступна всем клиентам, обладающими соответственными правами доступа, и надежно защищена (равно как и сам сервер), в то время как гарантировать целостность информации на множестве локальных машин затруднительно.
С другой стороны, в POP3-ящиках почта храниться незначительные промежутки времени, и это затрудняет ее похищение злоумышленником. Напротив же, идеология IMAP4 диктует постоянное хранение всей почты на одном сервере. И если этот сервер окажется взломан, злоумышленник получит доступ сразу ко всей корреспонденции.
Под обработкой сообщений понимается возможность растасовать корреспонденцию по множеству папок и наличие развитых функций поиска необходимого письма. Все это реализовано практически в любой почтовой программе (например, Outlook Express, The Bat), однако, при использовании протокола IMAP4 эти операции выполняются сервером, а не клиентом.
