Техника сетевых атак

Первым в заголовке обычно указывается поле ‘Received’, вставляемое транзитными серверами, пересылающими почту. Какова роль промежуточных узлов? Не проще ли устанавливать соединение непосредственно с почтовым сервером получателя? Да, когда-то именно так все и происходило, но с ростом потока сообщений пришлось усложнить схему пересылки. Появились серверы - ретрансляторы, специализирующиеся на пересылке почты. Подробнее о них рассказано в главах «Протокол SMTP» и «Почтовый сервер изнутри».

Содержимое поля “Received” произвольно и меняется от сервера к серверу. В той или иной форме оно должно указывать на адреса серверов отправившего и получившего письмо с сообщением времени отправления - доставки.

Каждый последующий сервер в цепочке добавляет новую запись в начало заголовка, и самая верхняя строка оставляется почтовым сервером адресата, получившим письмо. В приведенном выше примере она выглядит так:

· Received: from baldrick.eia.brad.ac.uk ([143.53.48.11])
· by camel.mail.ru with esmtp (Exim 3.02 #107)
· id 12KQqZ-000AmG-00
· for KPNC@aport.ru; Mon, 14 Feb 2000 22:07:47 +0300

Анализ заголовка позволяет установить, что в приведенном примере, сообщение было передано сервером baldrick.eia.brad.ac.uk (в скобках указан его IP адрес), но… удивительно, кем оно было получено! В заголовке значится доменное имя camel.mail.ru, принадлежащее популярной бесплатной службе mail.ru, а пути немотивированного возникновения письма на сервере mail.computerra.ru становятся весьма загадочными. Вероятно, заголовок был модифицирован, - удалена, по крайней мере, одна строка. Действительно, изначально письмо адресовалось kpnc@aport.ru. Оно было благополучно доставлено адресату, но хитрый mail.computerra.ru перебросил его в свой ящик, ни словом не обмолвившись этим фактом в заголовке. Впрочем, сервера с таким поведением большая редкость.

Две бесплатные почтовые службы mail.ru и aport.ru на самом деле являются одной службой в разных лицах!

Следующее (и последнее в цепочке) поле “Received” содержит адрес сервера-отправителя, но не сообщает никакой информации о самом отправителе. Поэтому достоверно определить кем было отправлено письмо не представляется возможным.

· Received: by baldrick.eia.brad.ac.uk (8.9.3/8.9.0) id TAA21004;
· Mon, 14 Feb 2000 19:04:23 GMT

Если собственноручно добавить к заголовку еще одно поле “Received” с некоторой информацией и передать письмо на baldrick.eia.brad.ac.uk, то получатель, анализируя заголовок, извлечет последнюю строчку «Received», содержащую подложный адрес. Подробнее о фальсификации содержимого поля “Received” рассказано в главе «Анонимная рассылка корреспонденции».

Поле «Data» заполняется сервером-отправителем сообщения, но его достоверность не гарантирована, ведь злоумышленник способен передать письмо непосредственно на ретранслятор от имени почтового сервера-отправителя.

Поле «Message-Id» служит для идентификации сообщений, позволяя из одних писем ссылаться на другие. Для обеспечения непротиворечивости каждый идентификатор должен быть уникален для всей сети Internet, то есть необходимо гарантировать существование всего лишь одного письма с данным идентификатором. Но как можно согласовать работу множества несвязанных друг с другом серверов? Организовать банк данных, отслеживающий все выданные идентификаторы возможно только теоретически. Но, поскольку каждый сервер обладает уникальным IP адресом (и, вероятнее всего, доменным именем), достаточно включить его в идентификатор, дополнив уникальной для данного сервера последовательностью, что обеспечит единственность такой комбинации во всей сети. Поэтому, идентификатор обычно состоит из имени узла-отправителя сообщения и буквенно-числовой последовательности, как правило [191], включающей в себя дату и время пересылки сообщения.

Ниже приведен пример типичного идентификатора (локальная уникальная последовательность выделена жирным шрифтом):

· Message-Id: « 200002141904.TAA21004 @baldrick.eia.brad.ac.uk»

Поле “From:” содержит обратный адрес отправителя сообщения, который пожелал оставить сам отправитель. При отправке письма сервер проверяет лишь синтаксическую корректность содержимого поля “From”, но не гарантирует подлинность представленных данных. Так, в приведенном примере, отправитель создает впечатление, что он находится на узле telescope.org, но анализ идентификатора Message-Id позволяет установить истинный адрес сервера-отправителя.

· From www@telscope.org Mon Feb 14 22:07:48 2000
·…
· Message-Id: «200002141904.TAA21004@ baldrick.eia.brad.ac.uk »