Техника сетевых атак
Шрифт:
· 250 «fox@dore.on.ru» Sender Ok
· RCPT TO:«kpnc@aport.ru»
· 250 Recipient Ok
В результате такого подлога, сервер оказался введен в заблуждение и согласился доставить письмо. Очевидно, подлинный отправитель сообщения не может быть установлен по заголовку, поскольку в нем находится только та информация, которую отправитель пожелал оставить самостоятельно.
Для массовой рассылки лучшего способа и придумать невозможно, но вот для обычной переписки такая методика не подходит. Ведь ответ на письмо возвратится по адресу fox@dore.on.ru! Этого можно избежать, если добавить в заголовок поле “Reply-To”, содержащее истинный адрес отправителя (тот, который он захотел оставить сам). Это может выглядеть, например, таким образом:
· 220 WITHELD FTGate server ready -Fox Mulder
· HELO dore.on.ru
· 250 Ready
· MAIL FROM:«fox@dore.on.ru»
· 250 «fox@dore.on.ru» Sender Ok
· RCPT TO:«kpnc@id.ru»
· 250 Recipient Ok
· data
· 354 Start mail input; end with «CRLF».«CRLF»
· Subject:TEST
· Reply-To:«kpnc@hotmail.com»
·
· 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 kpnc@id.ru; 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 «kpnc@id.ru»; 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 «kpnc@id.ru»; 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: «000301bec6ff$c87f5220$16fe7dc1@fox»
· From: «fox@dore.on.ru»
· To: «KPNC@id.ru»
· Subject: TEST
· Reply-To:«kpnc@HotMail.com»
· Date: Mon, 5 Jul 1999 20:02:29 +0400
·
· Hello!
При попытке ответить отправителю, почтовый клиент получателя извлечет содержимое поля “Reply-To” и отправит письмо по указанному в нем адресу. Именно этим и пользуются спамеры для достижения полной анонимности с одной стороны, и возможности получения ответов от заинтересованных лиц - с другой.
Если внимательно посмотреть на заголовок письма, в нем можно обнаружить несколько строк “Received”. Их оставили транзитные сервера, иначе называемые Релеями (от английского relay).
Любой почтовый клиент может отправить письмо напрямую. Однако для этого придется собственноручно указать в настойках сервера исходящей почты адрес получателя.
Например, чтобы отправить письмо для kpnc@computerra.ru с помощью “OutLock Express” придется зайти в «Учетные записи» (меню «Сервис»), выбрать «Свойства» и перейти к закладке «Серверы», задав для исходящей почты сервер «computerra.ru».
Очевидно, это слишком утомительно и непрактично. До тех пор, пока программное обеспечение не научиться выполнять такую операцию автоматически, пользователи будут вынуждены пользоваться прежними методами.
Работа типичного мелкокорпоративного сервера исходящей почты выглядит приблизительно так: получив в свое распоряжение письмо, он тут же устанавливает соединение с почтовым ящиком получателя, и отправляет послание. При этом он сталкивается с теми же затруднениями, что и обычный клиент. Поэтому, широко используется ретрансляция сообщений. Если письмо по каким-то причинам не может быть передано напрямую, оно передается ретранслятору.
Ретранслятор - точно такой же SMTP-сервер, как и все остальные, обсуждаемые в этой главе. В зависимости от настоек сервера маршрут пересылки письма может варьироваться. Одно сообщение может отправляться напрямую, а другое - долго «крутиться» на Релеях. Доверие это прекрасно, но только когда не касается вопросов безопасности. Кто рискнет доверять ретрансляторам неизвестного происхождения? Тем более, дальнейший маршрут письма каждым из транзитных серверов определяется самостоятельно, и нет никаких гарантий, что в эту цепочку не вклиниться злоумышленник.
Но протокол SMTP позволяет отправителю самостоятельно задавать маршрут пересылки сообщения Параметр команды “RCPT TO” может содержать не только адрес получателя, но и путь ретрансляции!
Формат его следующий:
· RCPT TO:«@s1,@s2,@s3,@sn:name@host»
где s1,s2,s3,sn - имена (или IP адреса) промежуточных хвостов, а name@host почтовый ящик получателя. В первую очередь сообщение передается узлу s1 - самому левому серверу в цепочке. Он модифицирует параметр команды RCPT TO, «выкусывая» из нее имя своего узла:
· RCPT TO:«@s2,@s3,@sn:name@host»
Затем, извлекается адрес следующего получателя - s2. Если сервер s1 не берется за доставку корреспонденции серверу s2, письмо возвращается назад отправителю с сообщением об ошибке. В противном случае процесс повторяется до тех пор, пока сообщение не окажется в почтовом ящике получателя.
Недостаток такой схемы заключается в том, что некоторые SMTP сервера для пересылки на очередной хвост могут прибегать к услугам своих собственных ретрансляторов. Таким образом, гарантируется, что письмо при успешной доставке посетит все заданные узлы в указанном порядке. Но не всегда выполняется прямая пересылка между соседними хвостами в цепочке.