Техника сетевых атак
Шрифт:
На первый взгляд ничего сложного в этом нет. Достаточно, например, запрашивать пароль при входе на сервер, но… это потребовало бы переделки всего клиентского программного обеспечения. Поэтому, было решено использовать в качестве пароля IP-адрес клиента. К сожалению, в большинстве случаев провайдеры предоставляют абонентам, так называемый, динамический IP адрес, который может выдаваться множеству лиц и в качестве уникального идентификатора личности не подходит. Тогда предложили следующий механизм, - сначала пользователь должен подключится к POP3 серверу и ввести свое имя и пароль [203]. После успешного завершения операции определяется IP адрес клиента и передается SMTP-серверу. В течение некоторого промежутка времени [204], SMTP-сервер открывает вход для пользователя,
Процесс отправки почты с помощью Outlook, на сервер требующий авторизации отправителя, выглядит так, - при первой попытке отправки письма SMTP сервер возвращает ошибку, рекомендуя сначала «засветиться» по POP3. Щелчок мыши по кнопке «доставить почту» приводит к повторной попытке зайти на SMTP сервер, которая точно так же будет отвергнута. После этого Outlook заходит на POP3 сервер, где и оставляет требуемый IP адрес. Второй щелчок мыши «доставить почту» наконец-то приводит к желаемому результату, но, сколько же лишних операций для этого пришлось сделать!
Некоторые сервера всего лишь проверяют обратный адрес клиента, сообщаемый им командой “MAIL FROM”. Разумеется, ничего не стоит передать поддельные данные, послав письмо от имени другого человека. Для этого достаточно знать имя хотя бы одного пользователя, зарегистрированного на сервере.
Поэтому, современные почтовые серверы оснащены собственными механизмами аутентификации, требующими явной передачи имени и пароля.
К сожалению, аутентификацию отправителя поддерживают далеко не все почтовые клиенты, к числу которых относятся все версии Outlook, младше пятой.
Outlook 5.0 и выше обеспечивают проверку подлинности пользователя - для этого достаточно взвести соответствующую галочку в настойках «Серверы»
Рисунок 029 Аутентификация отправителя
Поддержка SMTP-транзакции опирается на SMTP-соединение [205] и включает в себя три шага. Это открытие транзакции (совершаемое командой «MAIL FROM»), определение адресов доставки (задаваемое серией команд «RCPT TO») и передачи текста сообщения (инициируемое командой «DATA»). Последовательность «перенос строки», «точка», «перенос строки» завершает транзакцию. Подробно этот процесс описан в главе «Протокол SMTP», но некоторые нюансы остались «за кадром» и будут рассмотрены ниже.
«Транзакция» переводится на русский язык как «групповая операция», - и в данном случае обозначает возможность отправки одного сообщения по множеству (группе) адресов. Открытие транзакции заставляет получателя очистить все старые таблицы и буферы данных для приема нового сообщения. Затем последовательными вызовами «RCPT TO» перечисляются адреса назначения. При этом возможны следующие ситуации, - если получатель находится на узле SMTP-сервера, письмо будет просто опущено в его почтовый ящик, в противном же случае поведение Агента Пересылки будет зависеть от настроек, установленных администратором. Во многих случаях рассылка корреспонденции за пределы локальной машины запрещена, - сервер действует только на прием. Именно такая конфигурация и называется в просторечии «почтовым ящиком пользователя». Так, например, сканирование портов сервера mail.computerra.ru, указывает на открытый двадцать пятый порт (т.е. SMTP
Рисунок 30.gif Сканирование портов сервера mail.computerra.ru
Но попытка использовать mail.computerra.ru в качестве сервера исходящей почты в своем почтовом клиенте ни к чему не приведет, - сервер откажется отправлять сообщения. На самом деле он может их отправлять, но только на локальные адреса - такие, которые выглядят как имя@computerra.ru. То есть полноценный SMTP сервер используется исключительно для приема входящей почты. Так называемые в обиходе сервера исходящей почты отличаются от него всего лишь одной строкой [206] конфигурационного файла, разрешающей пересылку за пределы локальной машины.
С этим связан частый вопрос пользователя «почему я не могу отправлять сообщения через mail.ru - сервер ругается и отвергает получателя». На самом деле на mail.ru [207] установлено два SMTP сервера - один по адресу mail.ru, допускающий рассылку только в пределах mail.ru; другой же находится на smtp.mail.ru - вот он-то и нужен большинству пользователей.
При этом опять-таки возможны варианты, - если адрес получателя и протокол опознан сервером, он пытается отправить письмо по назначению, в противном случае предлагает сделать это клиенту самостоятельно [208]. Наконец, адрес получателя может быть задан некорректно или вовсе отсутствовать, о чем SMTP сервер незамедлительно уведомит отправителя. Однако ошибка указания одного или нескольких получателей не разрывает SMTP-транзакцию и никак не влияет на остальные команды “RCPT TO”.
Если возникает необходимость разорвать текущую транзакцию и перезагрузить SMTP-соединение, используют команду «RSET», вызываемую без аргументов [209]. Буфера отправителя и получателя данной транзакции окажутся очищенными и отправку письма придется начинать сначала.
Агент Пересылки добавит исходящее сообщение в очередь отправки, чаще всего расположенную в файле «/var/spool/mqueue», и в порядке «социалистической очереди» будет пытаться доставить письма получателям. Если по каким-то причинам, например, отсутствию связи с сервером, сообщение не удастся отправить в течение нескольких часов, отправителю будет передано уведомление, и, по прошествии определенного количества попыток, SendMail возвратит письмо отправителю и удалит его из очереди.
В некоторых случаях задача доставки корреспонденции по назначению ложится на специализированные сервера, называемые Релеями (от английского relay), затронутые в главе «Протокол SMTP». В общих чертах они идентичны обычным SMTP-серверам и часто реализуются на базе SendMail. Практически единственное существенное отличие relay-серверов заключается в пропускной способности канала, соединяющего их с Internet, - он должен быть рассчитан на интенсивную рассылку корреспонденции.
Описанными выше возможностями должен обладать любой Агент Пересылки, отвечающий стандартам RFC. Но помимо базовых функций существует набор команд необязательных для реализации, среди которых порой попадаются удивительно полезные и любопытные.
Так, например, с помощью электронной почты несложно организовать конференцию для общения в реальном времени [210]. Для этого достаточно воспользоваться командами, пересылающими письма на удаленный терминал, а не в почтовый ящик. В первых версиях DeliverMail [211] существовала возможность задать адрес получателя в виде “host/dev/con”, но из соображений безопасности это было исправлено, однако такая идея понравилась разработчикам и получила дальнейшее развитие.