А Специальные ip-адреса
Рисунок 4.1.1.3.2.а. Специальные ip-адреса
IP-адрес имеет Интернет- и местную секции, первая характеризует место (организацию, сеть или даже группу сетей), вторая - конкретную ЭВМ. Местная секция адреса может быть разделена на части, характеризующие локальную сеть и конкретную ЭВМ (Рисунок 4.1.1.3.3).
Базовая транзакция аутентификации
Рисунок .24. Базовая транзакция аутентификации
Пример, использующий базовую транзакцию аутентификации, включает в себя следующие процедуры: когда имеет место базовая транзакция аутентификации на ранней фазе сессии, тогда, например финансовая организация может:
| - сформировать безопасный канал связи с покупателем (напр., используя [SSL/TLS]); | |
| - аутентифицировать покупателя, используя базовую транзакцию аутентификации и затем; | |
| - предоставить покупателю доступ к информации и другим услугам с конфиденциальностью, с которой они общаются с добросовестными клиентами. |
9.1.7. Базовая транзакция депозита
Базовая транзакция депозита поддерживает операции по размещению депозита электронных средств в финансовой орнганизации.
Финансовая организация в этой операции выполняет роль продавца (депозита электронных средств), который предлагает эту услугу за определенное вознаграждение, которое может поступить, например, с некоторого счета клиента в другом банке. Базовая транзакция депозита включает в себя следующие документальные обмены:
опционный документальный обмен аутентификации (смотри раздел 9.1.1); документальный обмен предложения (смотри раздел 9.1.2) и документальный обмен платежа (смотри раздел 9.1.3).Способ, с помощью которого эти документальные обмены могут взаимодействовать, показан на Рисунок .25.
Базовая транзакция депозита
Рисунок .25. Базовая транзакция депозита
Смотри раздел 9.1.12, чтобы определить какие комбинации документальных обменов применимы к конкретным транзакциям.
Заметим, что:
Продавец (финансовая организация) может принять депозит в виде различных видов электронных платежей. Но покупатель, который собирается разместить депозит, обячно знает, каким видом электронного платежа он намерен воспользоваться, по этой причине все многообразие электронных платежей в каждом конкретном случае сводится к одной разновидности. Однако могут быть несколько протоколов, которые могут использоваться с одним и тем же видом электронного платежа. В этом случае предложение, зависимое от вида платежа, може подойти для согласования используемого протокола. Продавец (финансовая организация) может использовать результаты аутентификации не только для идентификации покупателя, но и счета, на котором следует разместить депозит. Если не удается идентифицировать один счет, используются другие средства. Например:| - покупатель может специфицировать номер счета перед началом базовой транзакции депозита или | |
| - покупатель может быть идентифицирован ранее, например, с помощью базовой транзакции аутентификации, а счет может быть выбран из списка, предоставляемого финансовой организацией. |
| - если предыдущая транзакция, например, отзыва сделки или аутентификации уже идентифицировала покупателя, а канал связи обеспечивает достаточную безопасность, что гарантирует аутентифицированность клиента; | |
| - если аутентификация является частью платежного протокола и, следовательно, уже включена в платежный документальный обмен; | |
| - если аутентификация покупателя реализована каким-то иным способом вне рамак протокола IOTP, например, путем использования парольной фразы или аппаратным образом. |
9.1.8. Базовая транзакция покупки
Базовая транзакция покупки поддерживает покупку товаров или услуг с применением любых платежных методов. Она включает в себя следующие документальные обмены:
опционный документальный обмен аутентификации (смотри раздел 9.1.1) документальный обмен предложения (смотри раздел 9.1.2) или:| - документальный обмен платежа ge (смотри раздел 9.1.3), за которым следует | |
| - документальный обмен доставки (смотри раздел 9.1.4) |
Способы, какими эти документальные обмена могут комбинироваться показаны на Рисунок .26.
Базовая транзакция обмена ценностями
Рисунок .29. Базовая транзакция обмена ценностями
Базовая транзакция обмена ценностями осуществляется в двух вариантах: Обмен ценностями, зависящий от вида платежа. Где содержимое предложения, например курс по которому одна форма ценности обменивается на вторую, зависит от вида платежа и протокола, выбранного клиентом и Обмен ценностями, независящий от вида платежа. Где содержимое предложения, не зависит от вида платежа и протокола, выбранного клиентом.
В выше приведенном примере фигурирует роль продавца, хотя организацией, выполняющей обмен ценностями может быть банк или какая-то другая финансовая организация. Это потому, что банк выполняет здесь роль продавца, направляя покупателю предложение, которое он может принять или отвергнуть.
Блоки TPO и отклика Offer могут быть объединены в одном сообщении, только если содержимое блока отклика Offer не изменяется в результате выбора вида платежа и платежного протокола для обмена ценностями.
Использование подписей, чтобы гарантировать целостность обмена ценностями проиллюстрирована на диаграмме Рисунок .30.
Базовая транзакция отзыва сделки
Рисунок .28. Базовая транзакция отзыва сделки
Заметим, что: Продавец (финансовая организация) может предложить реализацию возврата средств различными видами электронных платежей. Однако может быть несколько различных протоколов для каждого из видов электронных платежей. Продавец (финансовая организация) может использовать результаты аутентификации для того, чтобы идентифицировать не только покупателя, но счета, куда надлежит перевести возвращаемые средства. Если не удается идентифицировать один счет, используются другие средства. Например:
| - покупатель может специфицировать номер счета перед началом базовой транзакции отзыва или | |
| - покупатель может быть идентифицирован ранее, например, с помощью базовой транзакции аутентификации, а счет может быть выбран из списка, предоставляемого финансовой организацией. |
| - если предыдущая транзакция, например, депозит или аутентификация уже идентифицировала покупателя, а канал связи обеспечивает достаточную безопасность, что гарантирует аутентифицированность клиента; | |
| - если аутентификация является частью платежного протокола и, следовательно, уже включена в платежный документальный обмен; | |
| - если аутентификация покупателя реализована каким-то иным способом вне рамак протокола IOTP, например, путем использования парольной фразы или аппаратным образом. |
9.1.11. Базовая транзакция обмена ценностями
Базовая транзакция обмена ценностями использует документальный обмен платежа, чтобы поддержать обмен ценностями в одной валюте с помощью одного метода оплаты и с привлечением той же или (обычно) другой валюты с помощью того же или иного платежного метода (встречный платеж). Примеры реализации такой процедуры включают в себя:
Перенос электронных средств на кредитную карту. Например, первый платеж может быть "dollar SET Payment", использующий кредитную карту, а второй платеж использует кредитную карту Visa Cash и осуществляет электронный перевод в долларах. Платежный обмен с заграничным субъектом посредством идентичных платежных методов.Например, один платеж может заключаться в снятии средств со счета в английских фунтах методом Mondex, а второй – предполагает внесение на счет денег в евро с помощью того же метода Mondex. Платежный обмен с заграничным субъектом посредством различных платежных методов. Например, один платеж может осуществляться по протоколу SET в канадских долларах, а второй - методом GeldKarte в немецких марках. Базовый обмен ценностями использует следующие документальные обмены:
опционный документальный обмен аутентификации (смотри раздел 9.1.1); документальный обмен предложения (смотри раздел 9.1.2), который определяет детали того, какие суммы и валюты подлежат обмену и два документальных обмена платежа (смотри раздел 9.1.3), которые осуществляют два реализуемые платежа. Способы, которыми эти документальные обмены комбинируются друг с другом изображены на Рисунок .29.
Базовая транзакция покупки
Рисунок .26. Базовая транзакция покупки
Чтобы определить, какие комбинации документальных обменов встречаются в каждой из транзакций смотри раздел 9.1.12.
9.1.9. Базовая транзакция возврата денег
Процесс возврата денег обычно состоит из:
запроса возврата, направленного покупателем продавцу, и имеющего целью продемонстрировать:| - исходная сделка имела место, например, путем предоставления расписки для исходной транзакции; | |
| - используется некоторый вид аутентификации, чтобы показать, что субъект, запросивший возврат, действительно является покупателем, или представителем покупателя, который осуществлял исходную сделку; | |
| - причину, почему продавец должен вернуть деньги. |
Базовая транзакция возврата денег поддерживает субнабор возможностей перчисленных выше, в частности поддерживает:
отдельную аутентификацию покупателя, где используется базовая транзакция аутентификации (смотри раздел 9.1.6) возвратный платеж продавца покупателю с помощью следующих двух торговых обменов:| - опционный документальный обмен аутентификации (смотри раздел 9.1.1) | |
| - документальный обмен предложения (смотри раздел 9.1.2) и | |
| - документальный обмен платежа (смотри раздел 9.1.3). |
Способы того, как эти документальные обмены взаимодействуют, показаны на Рисунок .27.
Базовая транзакция статусного запроса
Рисунок .32. Базовая транзакция статусного запроса
Блок ссылок транзакции
Торговая роль, делающая информационный запрос, должна использовать Id-компонент (смотри раздел 3.3.1), где атрибуты IotpTransId и TransTimeStamp имеют те же значения, что и в Id-компоненте исходной транзакции, объекта запроса. Атрибут IotpTransID в этом компоненте выполняет роль ключа при запросе записей, которые ведет торговая роль. Значение ID-атрибута Id-компонента должно быть отличным от любых других в исходной транзакции (смотри раздел 3.4.1).
Если требуются текущие статусные данные, компонент MsgId, и конкретный ID-атрибут для компонента MsgId должен отличаться от любых других в сообщениях, посланных торговой роли. Блок информационного запроса (смотри раздел 8.12) содержит следующие компоненты:
один компонент типа информационного запроса (смотри раздел 7.18). Он идентифицирует, относится ли запрос к предложению, платежу или доставке. нуль или один компонент платежной схемы (смотри раздел 7.10). Это нужно для инкапсуляции специфических платежных сообщений.Блок подписи (информационный запрос)
Если в сообщении, содержащем блок информационного запроса, присутствует блок подписи, тогда он может быть проверен, чтобы определить, авторизован ли этот запрос.
Если присутствует блок подписи информационного запроса (смотри раздел 8.12), то он содержит следующие компоненты:
один компонент Signature (смотри раздел 7.19) один или более компонентов сертификата, если таковые нужны.Блоки информационного отклика должны формироваться, только если транзакция авторизована. Цифровые подписи информационного запроса ставятся только в том случае, если получатель ожидает получение подписанных запросов. В данной версии IOTP это требует предварительного согласования. Это означает, что:
Покупатели вряд ли будут генерировать запросы, снабженные подписью, но если они это сделают, это не будет считаться ошибкой; другие торговые роли могут согласовать применение цифровых подписей, если это требуется.Например, Кассир может потребовать, чтобы информационный запрос был подписан Продавцом. С другой стороны, если исходная транзакция, к которой относится запрос, реализована через безопасный канал (напр., [SSL]), тогда разумно предположить, что, если отправитель информационного запроса знает Id-компонент исходного сообщения (включая, например, временную метку), то запрос является подлинным. Блок отклика INQUIRY (смотри раздел 8.13) содержит следующие компоненты:
один компонент Status (смотри раздел 7.16). Этот компонент содержит статусную информацию о запрашиваемой транзакции, нуль или один компонент платежной схемы. Этот компонент содержит инкапсулированные платежные сообщения, специфические для выбранной схемы оплаты. Блок SIGNATURE (отклик информационного запроса)
Если в сообщении, содержащем блок информационного запроса, присутствует блок подписи, тогда он может быть проверен получателем на предмет корректности информационного отклика.
Если блок подписи информационного отклика присутствует (смотри раздел 8.13), он содержит следующие компоненты:
один компонент Signature (смотри раздел 7.19) один или более компонентов Certificate, если они нужны. Цифровые подписи информационного отклика могут использоваться, только если получатель ожидает прихода подписанных откликов. В данной версии IOTP tэто предполагает предварительное согласование применение цифровых подписей. Это означает, что:
Покупатели вряд ли будут формировать отклики с подписями, хотя, если они это сделают, это не будет ошибкой; другие торговые роли могут договориться о том, что подпись необходима. Например, продавец может потребовать присылки подписанного информационного отклика от кассира. 9.2.2. Базовая транзакция Ping
Целью базовой транзакции IOTP Ping является проверка коннективности между торговыми ролями, принимающими участие в транзакции. Это позволяет приложению IOTP сделать следующее:
определить, работает ли приложение IOTP другой торговой роли; проконтролировать, могут ли торговые роли работать с цифровыми подписями. Например, эта транзакция может быть использована продавцом, чтобы определить, функционирует ли кассир или агент доставки, прежде чем запускать транзакцию, требующую участия этих торговых ролей.
Торговыми блоками, используемыми транзакцией Ping, являются:
блок запроса Ping (смотри раздел 8.14), блок отклика Ping (смотри раздел 8.15) и блок Signature (смотри раздел 8.16). Сообщения PING
На Рисунок .33 отображен обмен сообщениями прибазовой транзакции Ping.
| 1. | Приложение IOTP первой торговой роли решает проверить, находится ли в рабочем состоянии соответствующее приложение партнера. Оно генерирует блок запроса Ping, опционный блок подписи и шлет их другой торговой роли. |
| 1 a 2 | Запрос PING. IotpMsg: блоки Trans Ref; подписи (опционный); запроса Ping |
| 2. | Вторая торговая роль, которая получает блок запроса Ping, генерирует блок отклика Ping и посылает его отправителю исходного запроса Ping, с блоком подписи, если это требуется. |
| 1 ? 2 | Отклик PING. IotpMsg: блоки Trans Ref; подписи (опционный); отклика Ping |
| 3. | Первая торговая роль проверяет блок отклика Ping и выполняет необходимые действия, если это требуется |
Базовая транзакция возврата денег
Рисунок .27. Базовая транзакция возврата денег
Базовая транзакция возврата денег без документального обмена аутентификации может использоваться: когда аутентификация покупателя осуществлена как-то иначе, например, покупатель, чтобы идентифицировать себя ввел представленный ему ранее код. Код может может быть записан на WEB-странице или прислан по электронной почте. когда предыдущая транзакция, например базовая аутентификация, идентифицировала покупателя, при этом используется безопасный канал гарантирует корректность предыдущей аутентификации. когда аутентификация покупателя осуществлена кассиром в рамках реализации платежного алгоритма.
9.1.10. Базовая транзакция отзыва платежа
Базовая транзакция отзыва поддерживает возврат электронных средств из финансовой организации.
Финансовая организация в рамках технологии IOTP имеет в этой транзакции, роль Продавца – за выполнение этой операции она может получить определенную оплату. Базовая транзакция отмены сделки включает в себя следующие документальные обмены:
опционный документальный обмен аутентификации (смотри раздел 9.1.1) документальный обмен предложения (смотри раздел 9.1.2) и документальный обмен платежа (смотри раздел 9.1.3).Способы, какими эти документальные обмены могут комбинироваться показаны на Рисунок .28.
Базовые сообщения транзакции Ping
Рисунок .33. Базовые сообщения транзакции Ping
Верификация того, что подписи могут обрабатываться, осуществляется отправителем блока запроса Ping путем включения: компонентов Organisation, которые идентифицируют себя и предполагаемого получателя блока запроса Ping; блок подписи, который гарантирует корректность и целостность запроса Ping.
Получатель запроса Ping таким образом:
знает, кто послал запрос Ping и может следовательно верифицировать подпись запроса; знает, кто должен генерировать подпись отклика Ping.Заметим, что запрос Ping:
не влияет на выполнение транзакций; в отличии от других сообщений IOTP, таких как TPO или статусный запрос, не запускает новых транзакций IOTP.Все приложения IOTP должны присылать отклики Ping отправителю запросов Ping, сразу по получении.
Базовый запрос IOTP Ping может также содержать опционный блок подписи. Приложение IOTP может, например, использовать блок подписи для проверки того, способен ли получатель этого запроса формировать и верифицировать цифровые подписи.
Для каждой транзакции Ping, каждая роль IOTP может устанавливать различные транспортные сессии.
Любая торговая роль IOTP может посылать запрос Ping любой другой торговой роли. Сообщение Ping имеет свой собственный IotpTransId, который отличается от соответствующего параметра других транзакций.
Блок ссылок транзакции
IotpTransId транзакции Ping должен быть уникальным и отличать данную транзакцию от любых других.
Блок запроса PING
Если транзакция Ping является анонимной, тогда в блок запроса Ping включается компонент no Organisation (смотри раздел 8.7).
Если транзакция Ping не анонимна, то блок запроса Ping содержит компоненты Organisation для:
отправителя блока запроса Ping; верификатора компонента подписи.Если присутствуют компоненты Organisation, это указывает, что отправитель запроса Ping сформировал блок подписи. Блок подписи должен быть верифицирован торговой ролью, которая получила этот запрос Ping.
Блок подписи запроса Ping (смотри раздел 8.16) содержит следующие компоненты:
один компонент Signature (смотри раздел 7.19) один или более компонентов Certificate, если они требуются.Блок отклика PING
Блок отклика PING (смотри раздел 8.15) содержит следующие компоненты:
компонент Organisation отправителя сообщения-отклика PingЕсли транзакция Ping не является анонимной, тогда отклик Ping дополнительно содержит:
копии компонентов Organisation, содержащиеся в блоке запроса Ping.Блок SIGNATURE (отклик PING)
Блок подписи отклика Ping (смотри раздел 8.16) содержит следующие компоненты:
один компонент Signature (смотри раздел 7.19); один или более компонентов Certificate, если они нужны.Блок-диаграмма обмена сообщениями платежа и аутентификации
Рисунок .17. Блок-диаграмма обмена сообщениями платежа и аутентификации
Допустимые комбинации документального обмена зависят от конкретного типа транзакции IOTP.
Далее рассматриваются методы обработки рабочих ошибок (Business Errors) в процессе документального обмена (смотри раздел 4.2).
9.1.1. Документальный обмен аутентификации
Документальный обмен аутентификации является непосредственной реализацией торгового обмена аутентификации (смотри раздел 2.2.4). Он включает в себя:
| o | Аутентификатор организация, которая запрашивает аутентификацию; |
| o | Аутентифицируемый - организация, которая должна пройти аутентификацию. |
Аутентификация состоит из:
Запрос аутентификации, посылаемый аутентификатором аутентифицируемому, Отклик аутентификации, посылаемый аутентифицируемым аутентификатору в ответ на запрос. Отклик проверяется аутентификатором, результат этой проверки посылается аутентифицируемому, который из этой статусной информации узнает, прошел он аутентификацию или нет.Документальный обмен аутентификации предполагает также:
Предоставление аутентифицируемому компонента Organisation, который описывает аутентификатора и Опционно, предоставление аутентификатору компонента Organisation, который описывает аутентифицируемого.Запрос аутентификации может быть подписан цифровым образом, что позволяет аутентифицируемому, проверить доверительные параметры (credentials) аутентификатора. IOTP-сообщения, которые используются в таком обмене представлены на Рисунок .18.
| 1. | Первая организация предпринимает некоторое действие (например, нажимает кнопку на HTML-странице), которое требует аутентификации |
| 1 a 2 |
Необходимость аутентификации (за пределами протокола IOTP) |
| 2. | Вторая организация генерирует: блок запроса аутентификации, содержащий один или несколько компонентов запроса аутентификации и/или компонент информационного запроса о торговой роли, которые посылаются первой организации |
| 1 ? 2 |
Запрос TPO & аутентификации. Сообщение IotpMsg: блоки TransRef; Signature (опционно); TPO; запроса аутентификации |
| 3 | Запускается приложение IOTP. Если присутствует блок Signature, первая организацияможет использовать проверку параметров доверия (credentials) второй организации. Если все в порядке, первая организация выбирает запрос аутентификации (если присутствует или их более одного), и запускает аутентификационный алгоритм для формирования блока отклика аутентификации. Для генерации компонентов Organisation, если требуется, используетсякомпонент запроса данных о торговой роли. Наконец создается, если нужно, компонент Signature и все компоненты посылаются второй организации для проверки. |
| 1 a 2 | Отклик аутентификации. Сообщение IotpMsg: блоки Trans Ref; Signature (опционно) ; Auth Response |
| 4. | Вторая организация проверяет отклик Authentication, сопостовляя его с блоком запроса и убеждаясь, что первая организация именно та, за которую она себя выдает. По результатам проверки первой организации посылается статусный блок аутентификации. |
| 1 ? 2 |
Состояние аутентификации. Сообщение IotpMsg: блоки Trans Ref; Signature (опционно); Auth Response |
| 5. | Первая организация проверяет статусный блок и, если все в порядке, завершает транзакцию. |
Cхема вложения пакетов в TCP/IP (в данном примере в поле тип Ethernet кадра будет записан код )
Рисунок 4.1.1.3.4. cхема вложения пакетов в TCP/IP (в данном примере в поле тип Ethernet кадра будет записан код 0800)
Отдельные сети в Интернет соединяются друг с другом через узловые серверы (gateway, их иногда называют пограничными маршрутизаторами - boarder gateway), расстояние между которыми может измеряться метрами или тысячами километров. В межсетевых обменах также используется принцип вложения так пакеты Ethernet могут вкладываться в пакеты FDDI и т.д..
Прикладные программы также как и все протокольное программное обеспечение уровня Интернет и выше работают только с ip-адресами, в то время как уровень сетевого программного обеспечения работает с физическими сетевыми адресами (так Ethernet использует 48-битные адреса).
Обычно при описании сетей используется терминология 7-уровневой модели ISO ("стек протоколов"). Так уж получилось, но Интернет лишь с определенными натяжками можно описать, придерживаясь этой схемы.
Ethernet инкапсуляция (RFC 894) (размеры полей указаны в байтах)
Цифровые подписи и IOTP
6. Цифровые подписи и IOTP
IOTP может успешно работать без использования цифровых подписей в открытой сетевой среде, но это менее безопасно - смотри 5. Ниже рассматривается использование цифровых подписей для решения различных задач.
6.1. Как IOTP использует цифровые подписи?
В IOTP цифровые подписи используются как:
Компоненты IOTP (смотри раздел 7). Подпись содержит дайджест одного или более компонентов или торговых блоков, которые могут также включать в себя другие компоненты подписи в любом сообщении; идентификатор:| - того, какая организация сделала подписи; | |
| - какая организация должна обрабатывать подпись с целью проверки. |
Цифровые сертификаты могут быть связаны с цифровой подписью, если используется асимметричная криптография.Однако если используется симметричная криптография, цифровой сертификат заменяется некоторым идентификатором используемого секретного ключа. Способ, с помощью которого формируются компоненты подписи для одного или нескольких элементов, проиллюстрирован ниже на Рисунок .10.
Дайджесты подписи
Рисунок .10. Дайджесты подписи
Классическим примером того, как одна цифровая подпись подтверждает другую в IOTP, является случай когда Продавец сначала подписывет предложение, формируя подпись отклика предложения, которое позднее подтверждается кассиром с помощью подписи платежной расписки. Таким путем платеж в транзакции IOTP связывается с предложением продавца.
Заметим, что один Manifest может соответствовать многим элементам подписи "Value", где каждый элемент значения содержит цифровую подпись того же самого Manifest. Это, в частности, позволяет продавцу согласовать применение различных секретных ключей с кассиром и агентом доставки. Детальные описания компонента подписи содержится в разделе 7.19.
6.1.1. Пример подписи IOTP
Пример использования подписи проиллюстрирован ниже на Рисунок .11, где показано как взаимодействуют различные компоненты и элементы друг с другом.
Для целей иллюстрации была использована базовая торговая транзакция. Применение элементов и атрибутов аналогично для всех типов транзакций IOTP.
Элемент Manifest в компоненте подписи содержит дайджесты TransRefBlock (не покаазан); ID-компонента транзакции (не покаазан); компонентов организаций (Продавца, Кассира, Агента доставки); компонент списка видов платежа; компонент заказа, платежный компонент, компонент доставки и компонент выбора вида платежа (если покупка зависит от вида платежа).
Диалог в локальных сетях и в Интернет
4.5.15 Диалог в локальных сетях и в Интернет
Команды Talk (для SUN), Phone (для VAX/VMS) и другие служат для переговоров двух человек, работающих на одной и той же ЭВМ с удаленных терминалов в реальном масштабе времени. Хотя эти команды и не используют протоколы TCP/IP, они весьма удобны при работе, в частности при отладке новых телекоммуникационных каналов. Вызов осуществляется в соответствии с форматами: Talk bobyshev@ns.itep.ru или Phone <ID>, где <ID> - имя партнера (его ID, используемое при входе в ЭВМ), с которым вы хотите поговорить. При использовании этих процедур экран делится на две части по вертикали, верхняя часть предназначена для печати текста вызывающего, нижняя часть для его партнера.
Существует версия и Internet-Phone, которая обеспечивает голосовую двухстороннюю связь между пользователями сети. Этот вид услуг примыкает скорее к разновидностям сервиса, описанным в следующей главе. Для обеспечения работы такого канала связи достаточно ЭВМ PC-486SX с частотой 25МГц, памятью 8Мбайт и стандартной аудио-картой. Программы, поддерживающие этот вид сервиса, работают в рамках Windows, Winsock 1.1. При этом вы займете полосу канала шириной 7.7Кбит/c. При установке звуковой VC-платы c сжатием аудио-информации можно ограничить требования на полосу до уровня 6.72Кбит/c. Следует ожидать появления программ и на других платформах и в других средах. Общедоступное программное обеспечение для работы с аудио-версией Phone можно получить через анонимное FTP по адресу ftp.volcaltec.com (используйте ID-пользователя=ftp). Разговаривать можно только с одним партнером одновременно. Возможно совмещение разговора с другими процедурами Internet, что особенно привлекательно при диагностике и отладке каналов и сетевых программ. Internet-Phone контактирует с IRC (Internet Relay Chat, смотри подробнее в следующей главе), что позволяет получить необходимую справочную информацию. Используя возможности IRC, можно выбрать мышкой нужного вам партнера и начать беседовать с ним, если он конечно сидит у ЭВМ, которая оснащена необходимым аппаратным и программным обеспечением.
В рамках этого вида сервиса вы можете обсудить какой-то документ, отображенный на экране терминалов, отмечая нужные места с помощью манипуляторов мышь. Это дает возможность согласовать в реальном масштабе времени текст документа, обсудить элементы конструкции или схемы, не тратя деньги на командировку или на дорогостоящее оборудование для видеоконференций. Бесплатно поболтать с вашим приятелем в Рио-де-Жанейро - это ли не мечта многих россиян?
Если же специального оборудования в вашем распоряжении нет, можно воспользоваться текстовой версией Talk или Phone. Обращение к Talk имеет форму:
talk имя_пользователя [ ttyname ]
Если вы хотите поговорить с кем-то на вашей ЭВМ, достаточно в качестве параметра ввести имя_пользователя (login ID). Если же ваш партнер работает на другой машине, имя адресата может иметь вид: host!пользователь или host.пользователь, или host:пользователь, или пользователь@host, где host - это имя ЭВМ, на которой работает ваш партнер. Последняя форма используется чаще. При необходимости переговорить с человеком, работающем на определенном терминале, следует ввести имя этого терминала (ttyname). При получении запроса Talk выдает на экран следующее сообщение:
Message from TalkDaemon@his_machineattime...
talk: connection requested by ваше_имя@ваша_ЭВМ.
talk: respond with: talk ваше_имя@ваша_ЭВМ
Пользователь, желающий участвовать в диалоге, должен ответить:
talk ваше_имя@ваша_ЭВМ
Когда связь установлена, оба участника диалога могут печатать текст одновременно с отображением обоих текстов в верхней и нижней частях экрана. Нажатие комбинации СTRL-L переписывает заново содержание экрана. Для завершения диалога следует нажать CTRL-Y. Имя ЭВМ адресата можно найти в файле /etc/hosts, а имя терминала в файле /etc/utmp. В процессе общения с использованием терминала возникает проблема - "пальцы не поспевают за мыслью". Традиция англоязычного общения выработала некоторые общепринятые сокращения часто используемых слов и выражений, которые могут облегчить диалог:
Документальный обмен аутентификации
Рисунок .18. Документальный обмен аутентификации
9.1.1.1. Принципы обработки сообщений
При получении ссобщения-запроса TPO & Authentication (смотри ниже), аутентифицируемый может:
сформировать и послать аутентификатору сообщение-отклик аутентификации или обнаружив ошибку в запросе аутентификации, послать аутентификатору блок Cancel, содержащий компонент Status аутентификации с атрибутом StatusType и/или ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равным: AutEeCancel, NoAuthReq, TradRolesIncon или Unspecified.Получив сообщение-отклик Authentication (смотри ниже), аутентификатор должен в ответ послать сообщение состояния аутентификации, содержащее блок Status с компонентом Status, где StatusType = Authentication и:
атрибут ProcessState компонента Status = CompletedOk, в случае успешного завершения проверки, или атрибут ProcessState = Failed, а атрибут CompletionCode =: AutOrCancel, AuthFailed или Unspecified, в случае неудачи аутентификации,Получив сообщение состояния аутентификации (смотри ниже), аутентифицируемый должен проверить компонент Status в блоке состояния. Если он указывает на:
| o | успех аутентификации, тогда аутентифицируемый должен сделать следующее: |
| - | продолжить следующий шаг транзакции, частью которой является документальный обмен аутентификации, или |
| - | индицировать отказ продолжения транзакции путем посылки аутентификатору блока Cancel, содержащего компонент Status с атрибутом аутентификации StatusType, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) = AutEeCancel. |
| o | аутентификация не прошла, тогда аутентифицируемый должен быть оповещен о неудаче, а процесс остановлен. |
Если аутентификатор получает от Покупателя сообщение IOTP, содержащее блок Cancel, тогда аутентифицируемый может обратиться к сетевому узлу CancelNetLocn, специифицированному элементом торговой роли в компоненте Organisation для аутентификатора, указанного в блоке опций торгового протокола.
9.1.1.2. Сообщение запроса аутентификации и TPO
Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:
блок опций торгового протокола (смотри раздел 8.1), блок запроса Authentication (смотри раздел 8.4) и опционный блок Signature (смотри раздел 8.16). Каждый из них описан ниже.
Блок опций торгового протокола
Блок опций торгового протокола (смотри раздел 8.1) должен содержать следующие торговые компоненты:
один компонент протокольных опций (смотри раздел 7.1), который определяет опции, работающие для всего документального обмена аутентификации. один компонент Organisation (смотри раздел 7.6), который описываетаутентификатор. Компонент торговой роли организации должен указывать на роль, какую играет аутентификатор в данной сделке, например Пордавец или Покупатель. Блок запроса аутентификации
Блок запроса аутентификации (смотри раздел 8.4) должен содержать следующие торговые компоненты:
один компонент запроса аутентификации (смотри раздел 7.2), и Блок подписи (Запрос аутентификации)
Если запрос аутентификации был снабжен цифровой подписью, то должен быть включен блок Signature. Он содержит дайджесты следующих XML-элементов:
| o | блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит информацию, описывающую сообщение и транзакцию; |
| o | Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP; |
| o | следующие компоненты блока TPO: |
| - компонент протокольных опций; | |
| - компонент Organisation. |
| - компонент запроса аутентификации | |
| - компонент информационного запроса о торговой роли |
Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:
блок отклика Authentication (смотри раздел 8.5) и опционный блок Signature (смотри раздел 8.16). Блок отклика AUTHENTICATION
Блок отклика аутентификации должен содержать следующие торговые компоненты:
один компонент отклика аутентификации (смотри раздел 7.3) один компонент Organisation для каждой торговой роли, идентифицированной в атрибуте TradingRoleList компонента информационного запроса о торговой роли, содержащегося в блоке запроса аутентификации. Блок SIGNATURE (Отклик аутентификации)
Если элемент Algorithm ( смотри раздел 12) компонента запроса аутентификации содержащийся в блоке запроса аутентификации, указывает, что отклик аутентификации должен содержать цифровую подпись, тогда блок Signature должен быть включен в то же сообщение, где размещается блок отклика аутентификации. Компонент Signature содержит элементы дайджестов для следующиз XML-элементов:
блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит информацию, описывающую сообщение и транзакцию IOTP; Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP; следующие компоненты блока запроса аутентификации:
| - компонент запроса аутентификации; | |
| - компонент информационного запроса о торговой роли; |
9.1.1.4. Сообщение состояния аутентификации
Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение содержит в себе:
блок состояния аутентификации (смотри раздел 8.5) и опционный блок Signature (смотри раздел 8.16). Блок состоояния аутентификации
Блок состоояния аутентификации (смотри раздел 8.6) должен содержать следующие торговые компоненты:
один компонент Status (смотри раздел 7.16) с атрибутом ProcessState = CompletedOk. Блок SIGNATURE (состояние аутентификации)
Если блок состояния аутентификации подписан цифровым образом, тогда блок Signature должен включать то что содержать дайджесты следующих XML-элементов:
блок ссылок транзакции (смотри раздел 3.3) для сообщения, которое содержит информацию, описывающую сообщение IOTP и транзакцию; Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP; Следующие компоненты блока состояния аутентификации: - компонент Status (смотри раздел 7.16).
Если за документальным обменом аутентификации следует документальный обмен предложения (Offer) (смотри раздел 9.1.2), тогда блок состояния аутентификации и блок подписи (состояние аутентификации) могут объединяться с:
сообщение TPO (смотри раздел 9.1.2.3), или сообщение TPO и отклик Offer (смотри раздел 9.1.2.6) 9.1.2. Обмен документами предложения
Обмен документами предложения oвстречается в двух формах:
обмен предложения, зависящего от вида платежа. Где содержимое предложения, напр., детали заказа, сумма, детали доставки, и т.д., зависят от вида платежа и протокола, выбранных покупателем; обмен предложения, не зависящего от вида платежа. Где содержимое предложения не зависит от выбранного вида платежа или протокола. Каждый из этих типов документального обмена предложения может следовать за бокументальным обменом аутентификации (смотри раздел 9.1.1).
9.1.2.1. Документальный обмен предложения, зависящего от вида платежа
В документальном обмене предложения, зависящего от вида платежа блоки TPO отклика Offer посылаются отдельно продавцом покупателю, т.e.:
комонент списка вида платежа посылается покупателю в блоке TPO; Покупатель выбирает вид платежа, платежный протокол и опционно вид валюты из компонента видов платежа; Покупатель посылает выбранные вид платежа, протокол и валюту продавцу в блоке выбора TPO; Продавец использует полученную информацию, чтобы определить содержимое и затем послать блок отклика Offer покупателю. Это проиллюстрировано на диаграмме ниже (Рисунок .19).
| 1. | Покупатель решает совершить покупку и посылает продавцу информацию (напр., используя HTML), которая позволяет продавцу сформировать предложение, |
| C a M | Информация предложения – вне области действия IOTP |
| 2. | Продавец решает, какой платежный протокол, валюту и пр. использовать, помещает эти данные в компонент видов платежа в блоке TPO и посылает покупателю |
| C ? M | TPO (опции торгового протокола). IotpMsg: блоки Trans Ref Block; TPO |
| 3. | Приложение IOTP запущено. покупатель выбирает вид платежа, платежный протоколи вид валюты. Компонент выбора вида платежа посылается Продавцу. |
| C a M | Выбор TPO. IotpMsg: блоки Trans Ref Block и выбора TPO |
| 4. | Продавец использует выбранный вид платежа, плптежный протокол, валюту и информацию предложения для формирования блока отклика Offer, содержащего детали транзакции IOTP, включая цену, и т.д., опционно подписывает его и посылает покупателю |
| C ? M | Отклик OFFER. IotpMsg: блоки Trans Ref, Signature (опционный) и отклика Offer |
| 5. | Покупатель проверяет все ли в порядке в Offer, затем комбинирует компоненты из блоков TPO, выбора TPO и отклика Offer, чтобы сформировать следующее сообщение транзакции, и посылает его вместе с блоком подписи (если таковая нужна) соответствующей торговой роли |
Документальный обмен платежа и доставки
Рисунок .23. Документальный обмен платежа и доставки
Блоки отклика доставки и платежного отклика могут быть обхединены в одном сообщении только если кассир имеет необходимую информацию, чтобы послать блок отклика доставки. Это вероятно так, если роли продавца, кассира и агента доставки совмещены.
Атрибут DelivAndPayResp компонента доставки (смотри раздел 7.13), содержащийся в блоке отклика Offer (смотри раздел 8.3), делается равным True, если блоки отклика доставки и платежного отклика объединены в одном сообщении, и равен False, если блоки отклика доставки и платежного отклика посланы в разных IOTP-сообщениях.
9.1.5.1. Принципы обработки сообщений
Получив сообщение платежного запроса или платежного обмена, кассир должен выполнить некоторые действия по документальному платежному обмену (смотри раздел 9.1.3.1).
Получив сообщение платежного обмена, покупатель также должен выполнить некоторые действия по платежному документальному обмену (смотри раздел 9.1.3.1).
По получении сообщения платежного отклика и отклика доставки транзакция завершена.
Если покупатель получает сообщение IOTP, содержащее блок Cancel, информация, содержащаяся в сообщении должна быть доведена до сведения покупателя и более никаких действий не предпринимается.
Если кассир получает сообщение IOTP, содержащее блок Cancel, тогда покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для кассира.
Если продавец получает сообщение IOTP, содержащее блок Cancel, тогда покупатель должен прервать операцию платежа. В этом случае покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для продавца. Здесь он может предпринять какие-то дальнейшие действия.
9.1.5.2. Сообщение платежного запроса IOTP
Содержимое этого сообщения то же, что и для запроса при платежном документальном обмене (смотри раздел 9.1.3.2).
9.1.5.3. Сообщение платежного обмена IOTP
Содержимое этого сообщения то же, что и для платежного документального обмена (смотри раздел 9.1.3.3).
9.1.5.4. Сообщение платежного отклика и отклика доставки
Содержимое этого сообщения включает в себя:
блок платежного отклика, опционный блок подписи (платежный отклик) и блок отклика доставки. Содержимое блока платежного отклика то же, что и в платежном отклике при платежном документальном обмене (смотри раздел 9.1.3.4).
Блок SIGNATURE (отклик PAYMENT)
Содержимое этого блока то же, что и в блоке Signature (платежный отклик) при платежном документальном обменее (смотри раздел 9.1.3.4).
Содержимое блока отклика доставки то же, что и в блоке отклика доставки при платежном документальном обменее (смотри раздел 9.1.4.3).
9.1.6. Базовая транзакция аутентификации
Базовая транзакция аутентификации может иметь место в любое время между торговыми ролями, вовлеченными в сделку IOTP. Это означает, что она может иметь место:
перед другой транзакцией IOTP; одновременно с другой транзакцией; независимо от каких-либо других транзакций. Базовая транзакция IOTP аутентификации предполагает обмен аутентификационными документами (смотри раздел 9.1.1) как это показано на Рисунок .24.
Документальный обмен предложения, зависимого от вида платежа
Рисунок .19. Документальный обмен предложения, зависимого от вида платежа
Покупатель идентифицирует документальный обмен предложения, зависимого от вида платежа, с помощью отсутствия блока отклика Offer в первом сообщении IOTP.
Обработка сообщений
Получив сообщение TPO (смотри ниже), Покупатель может:
сформировать и послать сообщение выбора TPO Продавцу, или индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с атрибутом StatusType = Offer, ProcessState = Failed и CompletionCode (смотри раздел 7.16.4) равным: ConsCancelled или Unspecified.Получив сообщение выбора TPO (смотри ниже), Продавец может:
сформировать и послать сообщение отклика Offer Покупателю, или индицировать сбой, послав Покупателю блок Cancel, содержащий компонент Status с атрибутом StatusType = Offer, ProcessState = Failed и CompletionCode (смотри раздел 7.16.4) равным: MerchCancelled или Unspecified.Получив сообщение отклика Offer (смотри ниже), Покупатель может:
сформировать и послать следующее сообщение транзакции IOTP соответствующей торговой роли. Это зависит от типа транзакции, или индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с StatusType = Offer, ProcessState =of Failed и CompletionCode (смотри раздел 7.16.4) равным: ConsCancelled или Unspecified.Если продавец получает сообщение IOTP, содержащее блок Cancel, покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный в элементе торговой роли компонента Organisation продавца. Если покупатель получает сообщение, содержащее блок Cancel, тогда информация, содержащаяся в сообщении должна быть доведена до сведения покупателя.
9.1.2.2. Документальный обмен предложения, независимого от вида платежа
В документальном обмене предложения, независящего от вида платежа, блоки TPO и отклика Offer посылаются вместе от продавца к покупателю, т.e. имеется одно сообщение IOTP, которое содержит блоки TPO и отклика Offer.
Обмен сообщениями проиллюстрирован на Рисунок .20 ниже:
| 1. | Покупатель решает заключить сделку и посылает продавцу информацию (напр., используя HTML), которая позволяет ему подготовить предложение, |
| C a M | Информация предложения – вне пределов действия IOTP |
| 2. | Продавец решает, какой применить платежный протокол и валюту, помещает эти данные в компонент списка видов платежа в блок TPO, формирует отклик Offer, содержащий некоторые детали транзакции, например цену, опционно подписывает эту информацию и посылает покупателю |
| C ? M | Отклик TPO & OFFER. IotpMsg: блоки Trans Ref; Signature; TPO; отклика Offer |
| 3. | Запускается приложение IOTP. Покупатель выбирает вид платежа, платежный протокол, валюту. Записывает свой выбор в компонент выбора вида платежа, проверяет предложение и, если все в порядке, комбинирует компонент выбора вида платежа и информацию из блоков TPO Block и отклика Offer, чтобы сформировать следующее сообщение транзакции и послать его соответствующей торговой роли. |
Допустимые комбинации документальных обменов
Рисунок .31. Допустимые комбинации документальных обменов
1) Если первое сообщение IOTP транзакции содержит запрос аутентификации, то:
| a) Транзакция IOTP содержит документальный обмен аутентификации (смотри раздел 9.1.1). (Замечание 1) | ||
| b) Если последнее сообщение документального обмена аутентификации содержит блоки TPO и отклика предложения, тогда: | ||
| i) Транзакция IOTP включает документальный обмен предложения, независимый от вида платежа (смотри раздел 9.1.2.2). (Замечание 2) | ||
| c) В противном случае, если последнее сообщение аутентификационного обмена содержит блок TPO, но не содержит блока отклика предложения, тогда: | ||
| i) Сообщение IOTP содержит документальный обмен предложения, зависимый от вида платежа (смотри раздел 9.1.2.1). (Замечание 2) | ||
| d) В противном случае (сообщение состояния аутентификации документального обмена не содержит ни блока TPO ни блока отклика предложения). | ||
| i) Транзакция IOTP содержит только документальный обмен аутентификации. (Замечание 3) |
2) В противном случае (отсутствие запроса аутентификации в первом сообщении IOTP):
| e) Транзакция IOTP не включает в себя документальный обмен аутентификации (Замечание 2) | ||
| f) Если первое сообщение содержит блок отклика предложения, тогда: | ||
| i) Транзакция IOTP содержит документальный обмен предложения, независимый от вида платежа (Замечание 2) | ||
| g) В противном случае (отсутствие блока отклика предложения в первом сообщении): | ||
| i) Транзакция IOTP включает документальный обмен предложения, зависимый от вида платежа (Замечание 2) |
3) Если блок отклина предложения присутствует в каком-либо сообщении IOTP, тогда:
| h) Если блок отклика предложения содержит компонент доставки, тогда: | |||
| i) Если атрибут DelivAndPayResp компонента доставки равен “Истинно”, то компонент доставки делается равной “Истинно”, тогда: | |||
| (1) Транзакция IOTP состои из документальных обменов платежа и доставки (смотри раздел 9.1.5) (Замечание 4) | |||
| ii) В противном случае (атрибут DelivAndPayResp компонента доставки делается равным “Ложно”) | |||
| (1) Транзакция состоит из документального обмена платежа (смотри раздел 9.1.3), за которым следует обмен доставки (смотри раздел 9.1.4) (Замечание 4) | |||
| i) В противном случае (блок отклика предложения не содержит компонента доставки ) | |||
| i) если блок отклика предложения содержит только один компонент платежа, тогда: | |||
| (1) Транзакция IOTP содержит только один документальный обмен платежа (Замечание 5) | |||
| ii) если блок отклика Offer содержит компонент платежа, тогда: | |||
| (1) Транзакция IOTP включает в себя два документальных платежных обмена. Атрибут StartAfter компонента платежа используется для индикации того, какой платеж происходит первым. (Замечание 6) | |||
| iii) если блок отклика Offer не содержит ни одного или имеет более двух платежных компонентов, то имеет место ошибка | |||
| 4) В противном случае (отсутствие блока отклика Offer) имеет место ошибка. |
Некоторые платежные методы могут выполнять аутентификацию в ходе платежного обмена. В этом случае информация, необходимая для выполнения аутентификации будет включаться в компоненты платежной схемы.
В этом примере приложение IOTP не будет уверено, что аутентификация состоялась, так как компоненты платежной схемы, которые содержат аутентификационную информацию, не отличимы о других компонентов платежной схемы.
9.2. Инфраструктурные транзакции
Инфраструктурные транзакции разработаны, для поддержки запросов, прошла ли транзакция успешно или работает ли корректно некоторая торговая роль. Существует два типа таких транзакций:
транзакция запроса состояния транзакции, которая предоставляет информацию о статусе существующей или уже завершившейся транзакции; транзакция Ping, которая позволяет одному приложению определить, работает ли соответствующее приложение другой торговой роли и проверить, могут ли обрабатываться подписи. 9.2.1. Базовая транзакция запроса состояния транзакции IOTP
Базовая транзакция запроса состояния предоставляет информацию о состоянии существующей или завершившейся транзакции IOTP. Базовая транзакция запроса состояния использует следующие торговые блоки:
торговый блок информационного запроса (смотри раздел 8.12), торговый блок информационного отклика (смотри раздел 8.13) опционный блок подписи (смотри раздел 8.16). Запросы состояния транзакции IOTP могут производиться по разным причинам. Например:
чтобы помочь возобновить прерванную транзакцию и определить текущее состояние одной из других торговых ролей, определить продавцу, завершен ли платеж, доставка и т.д.. Например, покупатель может объявить, что платеж произведен, но нет платежной расписки, подтверждающей это утверждение. Если продавец делает запрос кассиру, то он может определить, произведена или нет соответствующая проплата. Запросы о базовых транзакциях IOTP Ping (смотри раздел 9.2.2) игнорируются.
Одна торговая роль может послать запрос любой другой торговой роли в любое время.
Программа, которая поддерживает торговую роль покупателя IOTP может не делать:
не подписать цифровым образом отклик, если это запрашивается, при условии, что она не способна сделать это, или совсем не реагировать на информационный запрос, так как она может быть в нерабочем состоянии или считать запрос неправомочным из-за того, что он, например, не подписан. Базовыми требованиями являются:
Покупатель должен послать блок статусного запроса торговой роли только после следующих событий:
| - Продавцу, после отправки блока выбора TPO, | |
| - Кассиру, после отправки блока платежного запроса, | |
| - Агенту доставки, после отправки блока запроса доставки, |
Рабочие ошибки (смотри раздел 4.2) в исходных сообщениях-запросах. Технические ошибки (смотри раздел 4.1) – как IOTP, так и специфических для определенных платежных схем es – в исходных IOTP-сообщениях. Технические ошибки в сообщении, содержащем сам блок информационного запроса. Рабочие ошибки в исходных сообщениях
Возврат блока информационного запроса, содержащего компонент Status, который был послан покупателю последним.
Технические ошибки в исходных сообщениях
Возврат блока информационного отклика, содержащего компонент Status. Компонент Status должен содержать атрибут ProcessState равный ProcessError. В этом случае в качестве отклика посылается блок Error, указывающий, где в исходном сообщении была найдена ошибка.
Технические ошибки в блоке информационного запроса
Возврат сообщения Error. То есть, возврат блока Error, содержащего код ошибки (смотри раздел 7.21.2), который описывает природу ошибки в сообщении информационного запроса.
Сообщения информационого запроса транзакции
На Рисунок . 32 рассмотрен процесс реализации базовой транзакции информационого запроса.
| 1. | Первая роль решает сделать запрос о транзакции IOTP, например, нажав кнопку запроса в приложении IOTP. Это вызовет генерацию блока информационого запроса и посылку его соответствующей торговой роли. |
| 1 a2 | Информационый запрос. IotpMsg: блоки TransRef; подписи (опционный); информационого запроса |
| 2. | Вторая торговая роль проверяет цифровую подпись (если она присутствует). Если получатель хочет среагировать, тогда торговая роль проверяет состояние транзакции, объекта запроса, используя IotpTransId в ID-компоненте блока ссылок транзакции, посылает сообщение первой торговой роли, после чего процесс останавливается |
| 1 ? 2 | Информационный отклик. IotpMsg: блоки TransRef; информационного отклика; подписи (опционный) |
| 3. | Первая торговая роль проверяет блок информационного отклика и опционную подпись, выполняет необходимые действия и останавливается. Это может включать отображение статусной информации конечному пользователю. |
Допустимые значения атрибута CompletionCode
Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode для доставки. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
| Значение | Описание |
| BackOrdered | Back Ordered. Товары, подлежащие доставке, ожидают длставки, но еще не доставлены. Доставка будет оформлена, когда товар будет получен. Это справедливо, если ProcessState = CompletedOk. Восстановление невозможно. |
| PermNotAvail | Постоянно не доступен (Permanently Not Available). Товары не доступны и не могут быть перезаказаны. Это справедливо, если ProcessState = Failed. Восстановление не возможно. |
| TempNotAvail | Временно не доступен. Товары временно не доступны и могут быть получены при повторном заказе. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно. |
| ShipPending | Задержка доставки. Товары доступны и запланированы к доставке, но еще не доставлены. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно. |
| Shipped | Товары доставлены (Goods Shipped). Товар уже доставлен. Ожидается подтверждение доставки. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно. |
| ShippedNoConf | Доставлен – никакого подтверждения доставки (Shipped - No Delivery Confirmation). Товары были доставлены, но их доставку невозможно подтвердить. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно. |
| ConsCancelled | Аннулировано Покупателем (Consumer Cancelled). Покупатель по какой-то причине решает аннулировать доставку. Этот код допустим только в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно. |
| DelivCancelled | Доставка аннулирована (Delivery Cancelled). Агент доставки по какой-то причине отказался завершить процедуру доставки и аннулировал транзакцию. Этот код допустим только в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно. |
| Confirmed | Подтверждено (Confirmed). Все товары были доставлены и получено подтверждение их доставки. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно. |
| Unspecified | Неспецифицированная ошибка (Unspecified error). Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Атрибут StatusDesc должен прояснить причину. Восстановление невозможно. |
| TimedOutRcvr | Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение от другой торговой роли получено вновь. |
| TimedOutNoRcvr | Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно. |
Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
| Значение | Описание |
| InMsgHardError | Серьезная ошибка во взодном сообщении (Input Message Hard Error). Тип блока запроса не может быть идентифицирован или является несовместимым. Следовательно никакой однодокументный обмен не может быть идентифицирован. Это может вызвать серьезную ошибку в транзакции. |
7.16.6. Коды завершения информационного запроса транзакции
Код завершения требуется только тогда, когда атрибут ProcessState = Failed.
Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
| Значение | Описание |
| UnAuthReq | Неавторизованный запрос (Unauthorised Request). Получатель запроса состояния транзакции отказывается откликаться на запрос. |
7.17. Компонент данных торговой роли
Компонент данных торговой роли содержит данные, которые должны быть пересланы между торговыми ролями вовлеченными в транзакцию.
Компоненты торговой роли определяют:
o организацию, которая сформировала компонент и
o организацию, которая его получила.
Они являются первыми сформированными и включенными в блок “отклик” и затем скопированных в соответствующий блок “запрос”. Например, кассиру может оказаться нужно проинформировать агента доставки о том, что платеж через кредитную карточку авторизован (but not captured). В другом примере продавцу может понадобиться предоставить кассиру некоторую специфическую информацию о Покупателе.
Его определение представлено ниже.
<!ELEMENT TradingRoleData (PackagedContent+) >
<!ATTLIST TradingRoleData ID ID #REQUIRED
OriginatorElRef NMTOKEN #REQUIREDDestinationElRefs NMTOKENS #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент данных торговой роли транзакции IOTP. |
| OrginatorElRef | Содержит ссылку элемента на компонент Organisation организации, которая создала компонент данных о торговой роли и включила его в блок отклика (напр., блок отклика предложения или платежа). |
| DestinationElRefs | Содержит ссылку элемента на компоненты Organisation организации, которая получила компонент данных о торговой роли в блоке запроса (напр., блоков запроса платежа или доставки). |
Cодержимое:
| PackagedContent | Содержит данные, которыые должны быть пересланы между торговыми ролями в виде одного или нескольких элементов PackagedContent, смотри раздел 3.7. |
7.17.1. Кто получает компонент данных о торговой роли
Восстановление при неудаче или в случае частично завершенной доствки невозможно. Покупатель для получения текущего состояния транзакции должен использовать информационный запрос (смотри раздел 9.2.1).
7.16.4. Коды завершения аутентификации
Код завершения необходим только в случае, если атрибут ProcessState = Failed. Ниже следующая таблица содержит допустимые значения атрибута CompletionCode, которые можно использовать. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
| Значение | Описание |
| AutEeCancel | Аннулировано аутентифицируемым (Authenticatee Cancel). Организация по какой-то причине отказывается от аутентификации. Это может быть, например, потому что подпись аутентификационного запроса оказалась некорректной или аутентификатор оказался неизвестным или неприемлемым. Восстановление невозможно. |
| AutOrCancel | Аннулировано аутентификатором (Authenticator Cancel). Организация, запросившая аутентификацию по каким-то причинам отказывается проверять полученный аутентификационный отклик и аннулирует транзакцию. Восстановление невозможно. |
| NoAuthReq | Запрос аутентификации не возможен (Authentication Request Not Available). Аутентифицирующийся субъект не имеет данных, которые должны быть предоставлены. Например, забыт пароль или субъект не авторизован. Восстановление невозможно. |
| AuthFailed | Аутентификация не прошла (Authentication Failed). Аутентификатор проверил аутентификационный отклик, но эта проверка по какой-то причине не прошла. Например, оказался неправильным пароль. Восстановление может быть возможно аутентифицируемым путем повторной посылки отклика аутентификации с корректными данными. |
| TradRolesIncon | Торговые роли несоместимы (Trading Roles Inconsisten). Торговые роли, содержащиеся в атрибуте TradingRoleList компонента информационного запроса торговых ролей (смотри раздел 7.4) не согласуются с торговой ролью, которую аутентифицируемый играет в данной транзакции IOTP. Примеры несогласованности включают в себя: о запрос Кассира информации об Агенте доставки; о запрос Покупателя информации о Продавце. Восстановление может выполнить аутентификатор путем повторной посылки блока аутентификационного запроса с поправленной информацией. |
| Unspecified | Неспецифицированная ошибка (Unspecified error). Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Восстановление невозможно. |
| TimedOutRcvr | Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение от другой торговой роли получено вновь. |
| TimedOutNoRcvr | Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно. |
Код завершения требуется только тогда, когда атрибут ProcessState = Failed.
Ниже описаны правила, которые определяют, что следует делать с компонентами данных торговой роли.
Когда бы ни был получен компонент данных торговой роли в блоке "Отклик", идентифицировать компоненты Organisation, которые должны получить его, как идентифицированные атрибутом DestinationElRefs. Когда бы ни был послан блок "Запрос", проверить, был ли он послан одной из организаций (адресат), идентифицированной атрибутом. Если это так, включить в блок "Запрос" следующее:
| - компонент данных о торговой роли, а также, | |
| - компонент Organisation, идентифицированной атрибутом OriginatorElRef. |
Компонент типа информационного запроса содержит информацию, которая указывает тип процесса, о котором получен запрос. Его определение представлено ниже.
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType ID ID #REQUIREDType NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIEDProcessReference CDATA #IMPLIED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент типа информационного запроса транзакции IOTP. |
| Type | Содержит тип информационного запроса. Допустимые значения типа запроса: o Offer. Запрос касается статуса предложения и обращен к продавцу. o Payment. Запрос касается статуса платежа и обращен к кассиру. o Delivery. Запрос касается статуса доставки и обращен к агенту доставки. |
| ElRef | Содержит ссылку элемента (смотри раздел 3.5) на компонент, к которому относится информационный запрос. Это: о Блок TPO, когда тип = Offer; o Компонент Payment, когда тип = Payment; o Компонент Delivery, когда тип = Delivery. |
| ProcessReference | Опционно содержит ссылку на процесс, о котором произведен запрос. Он должен быть установлен, если информация доступна. Для определения значений, которые он может принимать, смотри атрибут ProcessReference компонента Status (смотри раздел 7.16). |
Определения структур XML для подписей и сертификатов описаны в документе "Digital Signatures for the Internet Open Trading Protocol" Kent Davidson и Yoshiaki Kawatsura, опубликованном одновременно с этим документом - смотри [IOTPDSIG].
В будущем ожидается, что новые версии IOTP зафиксируют какой-то метод цифровой подписи XML в к ачестве стандарта.
Каждый компонент подписи цифровым образом подтвержжает один или более блоков или компонентов, включая компоненты подписи.
Компонент подпись:
содержит дайджесты одного или более блоков или компонентов в одном или нескольких IOTP-сообщениях в пределах одной транзакции IOTP и помещает результат в элемент Digest; объединяет элементы дайджестов с другой информацией о типе подписи, об отправителе и потенциальных получателях, а также об используемом алгоритме подписи, и помещает их в элемент Manifest, подписывает элемент Manifest, используя опционный сертификат, идентифицированный в компоненте Certificate блока Signature, помещая результат в элемент Value комполнента Signature. Заметим, что может быть много элементов Value, которые содержат подписи элемента Manifest. Компонент Signature может иметь один из четырех типов:
Подпись отклика предложения, Подпись отклика платежа, Подпись отклика доставки, или Подпись отклика аутентификации. Для общего объяснения подписей смотри раздел 6.
7.19.1. Использование элементов подписи и атрибутов IOTP
Определения элементов и атрибутов содержится в [IOTPDSIG]. Ниже представлена дополнительная информация, которая описывает, как эти элементы и атрибуты используются в IOTP.
Элемент SIGNATURE
ID-атрибут является обязательным.
Элемент MANIFEST
Опционный атрибут LocatorHrefBase содержит текст, который должен быть включен до текста, содержащегося в атрибуте LocatorHREF всех элементов Digest в пределах элемента Manifest.
Целью элемента Manifest является сокращение значения атрибута LocatorHREF, так как первая часть атрибутов LocatorHREF в подписи идентична.
Обычно в IOTP он будет содержать все символы атрибута LocatorHref вплоть до ("#") (смотри текст ниже).
Элементы ALGORITHM и PARAMETER
Элемент algorithm идентифицирует алгоритмы, использованные при формировании подписи. Тип алгоритма определяется значением алгоритма Type, который указывает, следует ли его использовать в качестве Digest-алгоритма, алгоритма подписи или алгоритма Key Agreement.
Следует использовать следующие алгоритмы дайджестов:
алгоритм [DOM-HASH]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:ibm:dom-hash"; алгоритм [SHA1]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:fips:sha1" и алгоритм [MD5]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:rsa:md5". Следует применять следующие алгоритмы подписи: алгоритм [DSA]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:us.gov:dsa" алгоритм [HMAC]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:ibm:hmac" Рекомендуется, чтобы использовался также следующий алгоритм подписи:
алгоритм [RSA]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:rsa:rsa" Кроме того могут использоваться другие специфические алгоритмы схем платежа. В этом случае значение атрибута name, которое надлежит использовать, специфицировано в приложении по платежным схемам.
Один алгоритм может использовать другие алгоритмы через посредство элемента Parameter, например:
<Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
<Parameter type='AlgorithmRef'>A2</Parameter> </Algorithm>
<Algorithm ID=A2 type="digest" name="urn:fips:sha1"> </Algorithm>
<Algorithm ID=A3 type="signature" name="urn:ibm:hmac">
Элемент DIGEST
Атрибут LocatorHREF идентифицирует элемент IOTP, который подписан цифровым образом. Он состоит из:
значения ID-атрибута IotpTrans ID-компонента транзакции, за которым следует: символ "#", за которым следует ссылка элемента (смотри раздел 3.5) на элемент транзакции IOTP, который является субъектом дайджеста. Прежде чем анализировать структуру атрибута LocatorHREF, он должен быть объединен со значением атрибута LocatorHrefBase элемента Manifest (смотри непосредственно выше).
Элемен атрибут
Должен существовать один и только один элемент атрибута, который содержит атрибут Type со значением типа подписи и содержимым равным одному из: OfferResponse, PaymentResponse, DeliveryResponse, AuthenticationRequest, AuthenticationResponse, PingRequest или PingResponse; в зависимости от типа подписи.
Значения содержимого элемента атрибута управляются процедурой, определенной в разделе 12 (IANA), и допускающей определение значений пользователем.
Атрибут Critical должен быть установлен равным true.
Элемент ORIGINATORINFO
Атрибут OriginatorRef элемента OriginatorInfo должен всегда присутствовать и содержать ссылку элемента (смотри раздел 3.5) на компонент Organisation организации, которая сформировала компонент Signature.
Элемент RECIPIENTINFO
Атрибут RecipientRefs содержит список ссылок (смотри раздел 3.5), указывающих на организации, которые должны будут проверить подлинность подписи.
7.19.2. Компонент подписи отклика предложения
Элемент Manifest подписи, который имеет тип OfferResponse должен содержать элементы дайджеста для следующих компонентов:
Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, которое содержит подпись отклика предложения; Блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, которое содержит подпись отклика предложения из блока TPO:
| компонент опций протокола; | |
| каждый из компонентов Organisation; | |
| каждый из компонентов списка видов платежа; |
| компонент Order; | |
| каждый из компонентов Payment; | |
| компонент Delivery; | |
| каждый из компонентов запроса аутентификации; | |
| любой компонент данных о торговой роли. |
если продавец получил блок выбора TPO, содержащий компоненты выбора вида платежа, тогда генерируется элемент дайджеста для кассира, идентифицированного компонентом выбора вида платежа, и для агента доставки, идентифицированного компонентом Delivery.
Смотри раздел 6.3.1. если Продавец не ожидает получить блок выбора TPO, тогда ренерируется элемент дайджеста для Агента доставки и всех Кассиров, вовлеченных в сделку. 7.19.3. Компонент подписи платежной расписки
Элемент Manifest компонента подписи платежной расписки должен содержать элеиенты Digest для следующих компонентов:
Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, который содержит подпись платежной расписки; Блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, который содержит подпись платежной расписки; компонент подписи отклика предложения; компонент платежной расписки; компонент Payment Note; компонент Status; компонент выбора вида платежа; любой компонент данных о торговой роли. 7.19.4. Компонент подписи отклика доставки
Элемент Manifest компонента отклика доставки должен содержать элементы Digest для следующих компоентов:
Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, который содержит подпись отклика доставки; блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, который содержит подпись отклика доставки; компонент данных доставки покупателя, содержащихся в предыдущем запросе доставки (если имется); компоненты Signature, содержащиеся в предыдущем запросе доставки (если имется); компонент Status; компонент Delivery Note. 7.19.5. Компонент подписи запроса аутентификации
Элемент Manifest компонента подписи запроса аутентификации должен содержать элементы Digest для следующих компонентов:
блок ссылки транзакции (смотри раздел 3.3) для сообщения IOTP, который содержит информацию, которая описывает сообщение и транзакцию IOTP; Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP; следующие компоненты блока TPO:
| - компонент опций протоколов; | |
| - компонент Organisation. |
| - компоненты запроса аутентификации (если имеются) | |
| - компонент запроса информации о торговой роли (если имеется) |
Компонент подписи отклика аутентификации
Элемент Manifest компонента подписи отклика аутентификации должен содержать элементы Digest для следующих компонентов:
блок ссылки транзакции (смотри раздел 3.3) для сообщения IOTP, который содержит информацию, описывающую сообщение и транзакцию IOTP; Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP; следующие компоненты блока запроса аутентификации:
| - компонент запроса аутентификации, который был использован в аутентификации (если имеется); | |
| - компонент информационного запроса о торговой роли (если имеются). |
Если информационный запрос подписан (смотри раздел 9.2.1) элемент Manifest компонента подписи информационного запроса должен содержать элементы Digest компонента типа информационного запроса и, если присутствует, компонент схемы платежа.
7.19.8. Компонент подписи
Если информационный отклик подписан (смотри раздел 9.2.1) элемент Manifest компонента подписи информационного запроса должен содержать элементы Digest блока торгового отклика и компонент Status.
7.19.9. Компонент подписи запроса Ping
Если запрос Ping подписан (смотри раздел 9.2.2), элемент Manifest компонента подписи запроса Ping должен содержать элементы Digest для всех компонентов Organisation.
7.19.10. Компонент подписи отклика Ping
Если отклик Ping подписан (смотри раздел 9.2.2), элемент Manifest компонента подписи запроса Ping должен содержать элементы Digest для всех компонентов Organisation.
7.20. Компонент Certificate
Определения структур XML для подписей и сертификатов описаны в работе "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Смотри также начало раздела 7.19.
Компонент Certificate содержит цифровой сертификат. Они используются только, когда, например, использована асиметричная криптография и верифицирующий получатель подписи не получил еще общедоступного ключа (Public Key).
Структура сертификата определена в [IOTPDSIG].
7.20.1. Использование в IOTP атрибутов и элементов подписи
Подробные определения упомянутых выше элементов и атрибутов содержатся в [IOTPDSIG]. Далее представлена дополнительная информация, которая описывает, как эти элементы и атрибуты используются в IOTP.
Компонент CERTIFICATE
ID-атрибут является обязательным.
Элемент VALUE
ID-атрибут является обязательным.
7.21. Компонент Error
Компонент Error содержит информацию о технических ошибках (смотри раздел 4.1) в сообщении IOTP, которое было получено одной из торговых ролей, вовлеченных в сделку. Для ясности ниже приведены две фразы, которые определяют использование компонента Error:
сообщение сопряжено с ошибкой. Сообщение IOTP, которое содержит или вызывает ошибку какого-то вида; сообщение, уведомляющее об ошибке. Сообщение IOTP, которое содержит компонент Error, который описывает ошибку, обнаруженную в сообщении. Определение компонента Error представлено ниже.
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIREDErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED Severity (Warning|TransientError|HardError) #REQUIRED
| MinRetrySecs CDATA #IMPLIED | SwVendorErrorRef CDATA #IMPLIED> |
| ID | Идентификатор, который однозначно определяет компонент Error транзакции IOTP. |
| xml:lang | Определяет язык, используемый атрибутами или дочерними элементами компонента, если только значение не переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8. |
| ErrorCode | Содержит код ошибки, который указывает на природу ошибки в сообщении. Допустимые значения ErrorCode приведены в секции 7.21.2. |
| ErrorDesc | Содержит текстовое описание ошибки на языке, заданном xml:lang. Содержимое этого атрибута определено поставщиком/разработчиком программного обеспечения, которое сгенерировало компонент Error. |
| Severity | Определяет степень (severity) ошибки. Допустимы следующие значения: о Warning. Индицирует, что хотя имеется ошибочное сообщение, транзакция может продолжаться. о TransientError. Индицирует, что ошибка в сообщении может быть исправлена, если ошибочное сообщение, на которое указывает элемент ErrorLocation, послать повторно. o HardError. Индицирует, что в сообщении имеется неустранимая ошибка, трпнзакция IOTP должна быть остановлена. |
| MinRetrySecs | Этот атрибут должен присутствовать, если Severity равен TransientError. Он равен минимальному числу полных секунд, которое приложение IOTP, получившее сообщение об ошибке, должно подождать прежде чем переадресовать сообщение, идентифицированное элементом ErrorLocation. |
Если атрибут Severity не равен TransientError, тогда значение этого атрибута игнорируется.
| SwVendorErrorRef | Этот атрибут является ссылкой, чье значение установлено поставщиком/разработчиком программы, которая сформировала компонент Error. Он должен содержать данные, которые позволяют поставщику идентифицировать точную позицию в его прогрпмме и установить причины, которые вызвали сообщение об ошибке. Смотри также атрибут SoftwareID Id-элемента сообщения в блоке ссылки транзакции (раздел 3.3). |
| ErrorLocation | Идентифицирует Id транзакции IOTP сообщения с ошибкой и, если возможно, элемент и атрибут сообщения, который вызвал формирование компонента Error. |
| PackagedContent | Содержит дополнительные данные, которые могут использоваться для понимания ошибки. Его содержимое может варьироваться в зависимости от природы ошибки (смотри раздел 7.21.2) и ои поставщика/разработчика приложения IOTP. Определение f PackagedContent смотри в разделе 3.7. |
Если об ошибке уведомляют более чем один компонент Error в сообщении, следует выполнять обработку компонента Error с наивысшим значением атрибута severity. В этом контексте, HardError имеет выше уровень “серьезности” (severity), чем TransientError, который имеет серьезность выше, чем Warning.
7.21.1.1. Severity = предупреждение
Если приложение генерирует сообщение об ошибке с компонентом Error, где атрибут Severity = Warning, тогда, если сообщение об ошибке не содержит другого компонента ошибки с атрибутом Severity выше, чем Warning, сообщение должно включать торговые блоки и компоненты, которые следовало бы включить, если бы сообщения об ошибке отсутствовало. Если сообщение получено с компонентом Error, где Severity = Warning, тогда:
рекомендуется, чтобы информация об ошибке была доведена до сведения пользователя, разработчик приложения IOTP должен:
| - продолжеть транзакцию как обычно или | |
| - прервать транзакцию, выработав сообщение с компонентом Error и атрибутом Severity = HardError (смотри раздел 7.21.1.3). |
Если они не сформированы, то вырабатывается сообщение с компонентом Error и Severity = HardError.
7.21.1.2. Severity = переходная ошибка
Если приложение генерирует сообщение с компонентом Error, где атрибут Severity = TransientError, тогда в сообщение должен быть только один компонент Error. Кроме того, должен присутствовать атрибут MinRetrySecs. Если сообщение, уведомляющее об ошибке получено с компонентом Error, где Severity = TransientError тогда:
если атрибут MinRetrySecs присутствует и имеет правильное значение, тогда следует использовать данную величину MinRetrySecs. В противном случае, если MinRetrySecs отсутствует или имеет неверное значение, тогда:
| - сформироать сообщение с компонентом Error и атрибутом Severity = Warning, после чего послать его со следующим сообщением (если такое имеется) торговой роли, которая прислала сообщение об ошибке с неверным значением MinRetrySecs и | |
| - использовать величину MinRetrySecs, установленное поставщиком/ разработчиком приложения IOTP. |
Если приложение генерирует сообщение об ошибке с компонентом Error, где атрибут Severity = HardError, тогда в сообщении должен быть только один компонент Error.
Если получено сообщение с компонентом Error, где атрибут Severity = HardError, транзакция прерывается.
7.21.2. Коды ошибок
Ниже следующая таблица содержит допустимые значения атрибута ErrorCode компонента Error. Первое предложение описания содержит текст, который должен использоваться для описания ошибки при отображении. Индивидуальные реализации могут транслировать его на альтернативные языки по своему усмотрению. ErrorCode не должен быть длиннее 14 символов.
| Значение | Описание |
| Reserved | Reserved. Эта ошибка зарезервирована поставщиком/ разработчиком программы. Контактируйте, если требуется, с поставщиком/разработчиком программы. Смотри ID-атрибут Software Id-элемента сообщения в блоке ссылок транзакции (раздел 3.3). |
| XmlNotWellFrmd | XML плохо сформирован. Документ XML плохо сформатирован. Смотри [XML]Ю, для того чтобы понять, что значит "хорошо сформатирован". Даже если XML сформатирован плохо, он должен быть просмотрен, найден блок ссылок транзакции, с тем чтобы было можно правильно сформировать отклик Error. |
| XmlNotValid |
XML некорректен. Документ XML сформатирован хорошо, но он некорректен. Для того чтобы понять, что значит "корректен" смотри [XML], в частности: oдокумент XML не следует регламентациям, определенным декларацией типов документов IOTP (DTD) (смотри раздел 13) и o документ XML не следует регламентациям, определенным расширениям декларации типов документов [XML Namespace]. |
| ElUnexpected | Нестандартный элемент. Несмотря на то что документ XML сформирован правильно и корректен, присутствует элемент, который не является стандартным для данного контекста согласно правил и ограничениям, содержащимся в данной спецификации. |
| ElNotSupp | Элемент не поддерживается. Несмотря на то что документ XML сформирован правильно и корректен, присутствует элемент, который: o согласуется с правилами и ограничениями данной спецификации, но o не поддерживается приложением IOTP, которое обрабатывает IOTP-сообщение. |
| ElMissing | Элемент отстутствует. Несмотря на то что документ XML сформирован правильно и корректен, отсутствует элемент, который должен присутствовать, если следовать правилам и ограничениям данной спецификации. |
| ElContIllegal | Содержимое элемента не верно. Несмотря на то что документ XML сформирован правильно и корректен, элемент Content содержит значения, которые не согласуются с правилами и ограничениями данной спецификации. |
| EncapProtErr | Ошибка инкапсулированного протокола. Несмотря на то что документ XML сформирован правильно и корректен, PackagedContent элемента содержит данные инкапсулированного протокола, которые неверны. |
| AttUnexpected | Нестандартный атрибут. Несмотря на то что документ XML сформирован правильно и корректен, присутствие такого атрибута в данном контексте не предусмотрено и не согласуются с правилами и ограничениями данной спецификации. |
| AttNotSupp | Атрибут не поддерживается. Несмотря на то что документ XML сформирован правильно и корректен, и приутствие атрибута элемента согласуется с правилами и ограничениями данной спецификации, он не поддерживается конкретной программной реализацией, которая обрабатывает сообщение IOTP. |
| AttMissing | Атрибут отсутствует. Несмотря на то что документ сформирован правильно и корректен, отсутствует атрибут, который согласно правилам и ограничениям данной спецификации должен присутствовать. |
В этом случае следует установить PackagedContent компонента Error соответствующим типу пропущенного атрибута.
| AttValIllegal | Не верно значение атрибута. Атрибут содержит значение, которое не согласуется с правилами и ограничениями данной спецификации. |
| AttValNotRecog | Значение атрибута не распознано. Атрибут содержит значение, которое приложение IOTP, обрабатывающее сообщение, не смогло распознать. |
| MsgTooLarge | Сообщение имеет слишком больую длину. Сообщение слишком велико для приложения, его обрабатывающего. |
| ElTooLarge | Элемент слишком велик. Элемент слишком велик для приложения, его обрабатывающего. |
| ValueTooSmall | Значение слишком мало. Значение всего или части элемента Content или атрибута, хотя и верно, но слишком мало. |
| ValueTooLarge | Значение слишком велико. Значение всего или части элемента Content или атрибута, хотя и верно, но слишком велико. |
| ElInconsistent | Элемент не согласован. Несмотря на то что документ сформирован правильно и корректен, согласно правилам и ограничениям данной спецификации: о содержимое элемента не согласуется с содержимым других элементовили их атрибутов или о значение атрибута не согласуется со значением одного или нескольких других атрибутов. |
| TransportError | Транспортная ошибка (Transport Error). Этот код ошибки используется для индикации проблем с транспортным механизмом, которые приводят к потере сообщения. Она обычно ассоциируется с переходной ошибкой. Объяснение переходной ошибки содержится с атрибуте ErrorDesc. Значения, которые могут использоваться в ErrorDesc с TransportError специфицированы в приложении IOTP для транспортного механизма. |
| MsgBeingProc | Сообщение обрабатывается (Message Being Processed). Этот код ошибки используется только с серьезностью (Severity) переходных ошибок. Код указывает, что предыдущее сообщение обрабатывается и, если в орговоренное время, заданное атрибутом MinRetrySecs, не получено отклика, оригинальное сообщение следует послать вновь. |
| SystemBusy | Система занята (System Busy). Этот код ошибки используется только с серьезностью (Severity) переходных ошибок. Он указывает, что сервер, который получил сообщение, в настоящее время занят и обработать сообщение не может. Если в орговоренное время, заданное атрибутом MinRetrySecs, не получено отклика, оригинальное сообщение следует послать вновь. |
Если транспортный механизм сервера/системы (например, HTTP) занят, следует использовать транспортные ошибки. Этот код нужно использовать в связи с серверами/системами IOTP или другими аналогичными системами, с которыми связан IOTP.
| UnknownError | Неизвестная ошибка. Индицирует, что транзакция не может завершиться по неидентифицированной причине. Атрибут ErrorDesc следует использовать для индикации природы проблемы. Эта ошибка может быть применена для указания, например, внутренней ошибки оконечного сервера или процесса клиента. |
Элемент Error Location указывает элемент и опционно атрибут в сообщении, с которым ассоциируется ошибка. Он содержит ссылку на сообщение IOTP, торговый блок, торговый компонент, элемент и атрибут, где обнаружена ошибка.
<!ELEMENT ErrorLocation EMPTY >
| <!ATTLIST ErrorLocation ElementType | NMTOKEN #REQUIRED |
| IotpMsgRef NMTOKEN #IMPLIED | BlkRef NMTOKEN #IMPLIED |
| CompRef NMTOKEN #IMPLIED | ElementRef NMTOKEN #IMPLIED |
Атрибуты:
| ElementType | Имя типа элемента, где обнаружена ошибка. Например, если элемент декларирован как <!ELEMENT Org, тогда его имя - "Org". |
| IotpMsgRef | Значение ID-атрибута Id-компонента сообщения (смотри раздел 3.3.2), к которому относится компонент Error. |
| BlkRef | Если ошибка ассоциирована со специфическим торговым блоком, тогда это значение ID-атрибута торгового блока, где обнаружена ошибка. |
| CompRef | Если ошибка ассоциирована со специфическим торговым компонентом, тогда это значение ID-атрибута торгового компонента, где обнаружена ошибка. |
| ElementRef | Если ошибка ассоциирована со специфическим элементом торгового компонента, тогда, если элемент имеет атрибут с типом (смотри [XML]) "ID", тогда это значение данного атрибута. |
| AttName | Если ошибка ассоциирована со значением атрибута, тогда это имя данного атрибута. В этом случае PackagedContent компонента Error должен содержать значение атрибута. |
Функциональная схема операция IOTP
Рисунок .7. Функциональная схема операция IOTP
На приведенной выше диаграмме Интернет рассматривается в качестве транспортного механизма. Но это не всегда так. Сообщения IOTP могут транспортироваться с использованием различных механизмов.
В этой версии IOTP специфицированы следующие операции IOTP (смотри раздел 9):
Покупка. Поддерживает предложение, платеж и, опционно, доставку. Возврат. Поддерживает возврат денег для сделанной ранее покупки. Обмен ценностями. Включает в себя два платежа, которые реализуют обмен ценностями, например валютный обмен. Аутентификация. Поддерживает удаленную аутентификацию одной торговой роли другой ролью с помощью различных аутентификационных алгоритмов, и предоставляет информацию об организации – торгового агента, который должен быть аутентифицирован с целью, например, подготовки предложения. Отзыв. Поддерживает отзыв электронного платежа из финансовой организации. Депозит. Поддерживает депозит электронного платежа в финансовой организации. Запрос. Поддерживает запрос состояния транзакции IOTP, которая в данный момент реализуется или уже завершилась. Ping. Эта операция поддерживает простой запрос, который позволяет одному приложению IOTP выяснить, работает ли некоторое другое приложение IOTP.3.2. Сообщение IOTP
Как было описано выше, сообщения IOTP представляют собой [XML] документы, которыми обмениваются торговые роли, участвующие в сделке.
XML-определение сообщения IOTP выглядит следующим образом.
<!ELEMENT IotpMessage
( TransRefBlk,
| SigBlk?, | |
| ErrorBlk?, | |
| ( AuthReqBlk | | |
| AuthRespBlk | | |
| AuthStatusBlk | | |
| CancelBlk | | |
| DeliveryReqBlk | | |
| DeliveryRespBlk | | |
| InquiryReqBlk | | |
| InquiryRespBlk | | |
| OfferRespBlk | | |
| PayExchBlk | | |
| PayReqBlk | | |
| PayRespBlk | | |
| PingReqBlk | | |
| PingRespBlk | | |
| TpoBlk | | |
| TpoSelectionBlk | |
| )* |
) >
<!ATTLIST IotpMessage
xmlns CDATA
'iotp:ietf.org/iotp-v1.0'
Содержимое:
TransRefBlkсодержит информацию, которая характеризует сообщение IOTP в пределах операции IOTP (смотри раздел 3.3)
| AuthReqBlk, AuthRespBlk, | Торговые блоки. |
| DeliveryReqBlk | Торговые блоки присутствуют в сообщениях IOTP, а само содержимое |
| DeliveryRespBlk | торгового блока зависит от типа выполняемой операции IOTP |
| ErrorBlk | смотри определение каждой операции в разделе 9. |
| InquiryReqBlk, | |
| InquiryRespBlk, | |
| OfferRespBlk, PayExchBlk, | |
| PayReqBlk | Полные определения каждого торгового блока описаны в разделе 8. |
| PayRespBlk, PingReqBlk, PingRespBlk, SigBlk, TpoBlk, TpoSelectionBlk |
| Xmlns | Определение [XML Namespace] для сообщений IOTP. |
Сообщение IOTP является корневым элементом XML-документа. Оно, следовательно, должно предшествоваться соответствующим прологом документа XML. Например:
<?XML Version='1.0'?>
<!DOCTYPE IotpMessage >
<IotpMessage>
...
3.3. Блок ссылок операции (Transaction Reference Block)
Блок ссылок транзакции содержит информацию, которая идентифицирует IOTP-транзакцию и сообщение IOTP. Блок ссылок операции включает в себя:
Компонент ID-операции, который однозначно идентифицирует операцию IOTP. Компоненты ID-операции идентичны для всех сообщений IOTP, относящихся к одной IOTP-операции. Компонент ID-сообщения, который предоставляет управляющую информацию о сообщении IOTP, а также однозначно идентифицирует сообщение IOTP в рамках операции IOTP. Нуль или более компонентов Related To, которые связывают эту операцию IOTP с другими операциями или другими событиями, используя идентификаторы этих событий. Определение блока ссылок операции (Transaction Reference Block) выглядит следующим образом:
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk ID ID #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет блок ссылок операции в пределах IOTP-процедуры (смотри раздел 3.4). |
| TransId | Смотри 3.3.1 Id-компонент операции. |
| MsgId | Смотри 3.3.2 Id-компонент сообщения. |
| RelatedTo | Смотри 3.3.3 Компонент Related To. |
Идентификационная компонента транзакции
Идентификационная компонента транзакции содержит информацию, которая однозначно задает транзакцию IOTP. Ее определение представлено ниже:
<!ELEMENT TransId EMPTY >
| <!ATTLIST TransId ID | ID #REQUIRED |
| Version | NMTOKEN #FIXED '1.0' |
| IotpTransId | CDATA #REQUIRED |
| IotpTransType | CDATA #REQUIRED |
| TransTimeStamp | CDATA #REQUIRED > |
| ID | Идентификатор, который однозначно определяет Id-компонент транзакции в рамках операции IOTP. |
| Version | Определяет версию IOTP и, следовательно структуру сообщений IOTP, которые используются транзакцией IOTP. |
| IotpTransId | Содержит данные, которые однозначно определяют транзакцию IOTP. Это атрибут должен отвечать правилам для идентификаторов сообщений [RFC 822]. |
| IotpTransTyp | Это тип исполняемой транзакции IOTP. Для базовой версии IOTP он идентифицирует "стандартную" транзакцию IOTP и предполагает определенную последовательность и содержимое сообщений IOTP, которыми обмениваются торговые роли. Корректными значениями атрибута являются: |
| о | BaselineAuthentication (Базовая аутентификация) |
| o | BaselineDeposit |
| o | BaselinePurchase |
| o | BaselineRefund |
| o | BaselineWithdrawal |
| o | BaselineValueExchange |
| o | BaselineInquiry |
| o | BaselinePing |
| TransTimeStamp | Там где система, запускающая транзакцию IOTP, имеет внутренние часы, атрибут устанавливается равным времени старта транзакции IOTP в формате [UTC]. |
Некоторые системы не могут генерировать временные метки.
В этом случае этот атрибут должен содержать значение "NA" (Not Available).
3.3.2. Идентификатор сообщения
Компонент Id-сообщения предоставляет контрольную информацию о сообщении IOTP, а также однозначно идентифицирует сообщение в рамках транзакции IOTP. Его определение выглядит следующим образом.
<!ELEMENT MsgId EMPTY >
| <!ATTLIST MsgId ID ID #REQUIRED | RespIotpMsg NMTOKEN #IMPLIED |
| xml:lang NMTOKEN #REQUIRED | LangPrefList NMTOKENS #IMPLIED |
| CharSetPrefList NMTOKENS #IMPLIED | SenderTradingRoleRef NMTOKEN #IMPLIED |
| SoftwareId CDATA #REQUIRED | TimeStamp CDATA #IMPLIED > |
| ID | Идентификатор, который однозначно идентифицирует сообщение IOTP в рамках транзакции IOTP (смотри раздел 3.4 ID атрибуты). Заметим, что если сообщение IOTP пересылается повторно, тогда значение этого атрибута остается неизменным. |
| RespIotpMsg | Это ID-атрибут содержит Id-компонент сообщения IOTP, откликом на которое оно является. Таким образом все сообщения IOTP в пределах транзакции оказываются связаны. Это поле необходимо каждому сообщению IOTP за исключением первого сообщения IOTP в транзакции. |
| SenderTradingRoleRef | Элемент ссылки (смотри раздел 3.5) торговой роли, которая сформировала сообщение IOTP. Он используется, чтобы идентифицировать сетевую позицию (Net Locations) (смотри раздел 3.9) торговой роли, которой требуется сообщить о технических ошибках (смотри раздел 4.1), связанных с торговыми блоками. |
| Xml:lang | Определяет язык, используемый атрибутом, или дочерние элементы в пределах этого компонента, если не переписан атрибутом xml:lang в дочернем элементе. Смотри раздел 3.8. |
| LangPrefList | Опционный список языковых кодов, который согласуется с идентификацией языков [XML]. Он используется отправителем, чтобы указать порядок предпочтения языков, которые получатель сообщения должен использовать при подготовке отклика. Получатель не обязан использовать один из указанных языков. |
| CharSetPrefList | Опционный список идентификаторов символьных наборов, которые соответствуют символам в [XML]. Он используется отправителем для указания порядока предпочтения символьных наборов, которые получатель может применить при формировании отклика. Получатель не обязан использовать один из указанных символьных наборов. |
| SoftwareId | Содержит информацию, которая идентифицирует программу, сформировавшую сообщение IOTP. Его целью является помочь разрешить проблему совместной работы различных программ, обменивающихся сообщениями. Это простая текстовая строка на языке, определенном xml:lang. Она должна содержать, по крайней мере: |
| имя производителя программного продукта название программного продукта версию программы форму программного обеспечения (build) | |
| TimeStamp | Когда прибор, отправляющий сообщение имеет внутренние часы, атрибут делается равным времени генерации сообщения IOTP в формате [UTC]. |
3.3.3. Компонент Related To
Компонент Related To связывает транзакции IOTP с другими транзакциями или другими событиями с помощью идентификаторов этих событий. Определение этого компонента представлено ниже.
<!ELEMENT RelatedTo (PackagedContent) >
| <!ATTLIST RelatedTo ID ID #REQUIRED | xml:lang NMTOKEN #REQUIRED |
| RelationshipType NMTOKEN #REQUIRED | Relation CDATA #REQUIRED |
Атрибуты:
| ID | Идентификатор, который однозначно jghtltkztn компонент Related To в рамках транзакции IOTP. |
| xml:lang | Определяет язык, использованный атрибутом или дочерним элементом в данном компоненте, если не переписан атрибутом xml:lang дочернего элемента. Смотри раздел 3.8. |
| RelationshipType | Определяет тип отношения. Корректными значениями являются: |
| Relation | Атрибут Relation содержит фразу на языке, определенном xml:lang, он определяет природу отношений между транзакцией, которая содержит этот компонент и другой транзакцией или другим событием. Окончательное текстовое выражение оставлено на усмотрение составителей программ IOTP. |
| RelnKeyWords | Этот атрибут содержит ключевые слова, которые могут быть использованы, чтобы помочь идентифицировать подобные отношения, например все виды возвратов. Ожидается, что рекомендуемые ключевые слова будут выбраны в процессе практического использования. В этой версии спецификации не содержится никаких специальных рекомендаций по ключевым словам |
| PackagedContent | Packaged Content (смотри раздел 3.7) содержит данные, которые идентифицируют связанные транзакции. Его формат варьируется в зависимости от значения атрибута RelationshipType. |
IOTP-сообщения, блоки (т.e. блоки ссылок операции и торговые блоки), торговые компоненты (включая ID-компонент транзакции и компонент подписи) и некоторые их дочерние элементы задаются атрибутом "ID" XML, который служит для идентификации этих XML-элементов. Эти элементы используются так, что один элемент может ссылаться на другой. Всем этим атрибутам присваиваются ID.
Значения каждого ID-атрибута является уникальным в пределах транзакции IOTP т.e. набор IOTP-сообщений, который имеет тот же самый компонент ID транзакции. Однажды присвоенное значение ID-атрибута элемента никогда не меняется. Это означает, что когда элемент копируется, значение ID-атрибута остается неизменным.
Как следствие можно использовать эти идентификаторы для ссылки и нахождения содержимого любого сообщения IOTP, блока или компонента (смотри раздел 3.5).
3.4.1. Определение ID-атрибутов сообщений IOTP
ID-атрибут Id-компонента IOTP-сообщения должен быть уникальным в пределах транзакции IOTP. Его определение представлено ниже:
IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix
IotpMsgIdPrefix ::= NameChar (NameChar)*
| о | "M" - Продавец (Merchant) |
| о | "C" – Покупатель (Consumer) |
Для сообщений, которые содержат торговый блок отклика на информационный запрос или блок отклика Ping, префикс равен "Q".
Префикс для других торговых ролей в сделке содержится в компоненте Organisation (организации) и прописывается обычно Продавцом. Ниже представлены рекомендуемые значения:
| о | "P" - Первый Кассир |
| o | "R" – Второй Кассир |
| o | "D" – Агент доставки |
| o | "C" – Доставка (Deliver To) |
| IotpMsgIdSuffix | Суффикс состоит из одной или более цифр. Суффикс должен быть уникальным для данной торговой роли транзакции IOTP. Рекомендации сводятся к следующему: |
| o | Первому сообщению IOTP, посланному торговой ролью, присваивается суффикс "1". |
| o | Для второго и последующих IOTP-сообщений, посланных той же торговой ролью, суффикс увеличивается на 1 для каждого последующего сообщения. |
| o | Суффикс не может содержать начальных нулей. |
3.4.2. Определения ID-атрибута для блока и компонента
ID-атрибут блоков и компонентов в пределах транзакции IOTP также должен быть уникальным. Ниже представлено его определение:
BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix
IdSuffix ::= Digit (Digit)*
| IotpMsgId_value | ID-атрибут. ID-компонента сообщения IOTP, где блок или компонент использован впервые. |
| IdSuffix | Суффикс состоит из одной или более цифр. Суффикс должен быть уникальным для ID-атрибута ID-компонента сообщения, используемого для генерации ID-атрибута. Рекомендуется здесь следующее: |
| o | Первому блоку или компоненту, посылаемому торговой ролью присваивается суффикс "1" |
| o | Для второго и далее блоков или компонентов ID-атрибуты увеличивается на 1 для каждого последующего сообщения. |
| o | Суффикс не может содержать начальных нулей. |
3.4.3. Пример использования ID-атрибутов
На диаграмме проиллюстрировано, как используются значения ID-атрибутов.
Интернет
4.4 Интернет
| Номер раздела | Название раздела | Объем в страницах | Объем в кбайт |
| 4.4 | 3 | 2 | |
| 4.4.1 | 10 | 91 | |
| 4.4.2 | 7 | 5 | |
| 4.4.3 | 15 | 135 | |
| 4.4.4 | 10 | 93 | |
| 4.4.5 | 10 | 103 | |
| 4.4.6 | 4 | 141 | |
| 4.4.7 | 1 | 11 | |
| 4.4.8 | 1 | 13 | |
| 4.4.9 | 3 | 20 | |
| 4.4.10 | 3 | 30 | |
| 4.4.11 | 10 | 86 | |
| 4.4.12 | 15 | 100 | |
| 4.4.13 | 6 | 52 | |
| 4.4.14 | 5 | 39 | |
| 4.4.15 | 47 | 190 | |
| 4.4.16 | 11 | 68 |
Виртуальная сеть виртуальных сетей - Интернет является самой большой и самой популярной сетью. Можно смело утверждать, что эта сеть сохранит это лидерство в ближайшие годы. Привлекательность сети не только в том, что это единая среда общения людей, находящихся в разных странах и на разных континентах. Интернет предоставляет все более широкий спектр услуг. Это и информационно-поисковые системы, телефония, аудио и видео письма, доставляемые за считанные секунды в любую точку мира (где имеется Интернет), видеоконференции, электронные журналы, службы новостей, дистанционное обучение, банковские операции и многое, многое другое. Интернету предстоит мучительная процедура перехода на 128-битовые адреса (IPv6), но по ее завершении можно ожидать дальнейшего расширения списка услуг. Уже сегодня Интернет стал средой, предоставляющей возможность целевой рекламы и дистанционной торговли. Уже в начале следующего века сети станут самым мощным средством массовой информации. Но для решения всех этих проблем в этой сфере еще очень много надо сделать. Современные поисковые системы, несмотря на впечатляющие успехи, требуют существенного улучшения эффективности, много надо сделать для того, чтобы Интернет пришел в каждую квартиру.
Сегодня Интернет использует многие десятки протоколов. Если сюда добавить протоколы физического уровня, то их число превысит сотню. На уровне локальных сетей наиболее распространены различные разновидности Ethernet, а также Token Ring и некоторые другие. Особенно велико разнообразие протоколов межсетевого обмена. Здесь помимо PPP используется FDDI, X.25, ISDN, ATM, SDH, Fibre Channel и пр..
На транспортном уровне в Интернет работают протоколы UDP (без установления соединения) и TCP (с установлением соединения). Это два принципиально разных подхода к передаче данных. В обоих случаях и передатчик и приемник имеют индивидуальные IP-адреса и порты. Но в случае TCP они ассоциируются в соединители (socket) - две пары IP-адрес-порт и прием/передача в рамках одной сессии происходит по схеме точка-точка. Для UDP же допускается возможность передачи одновременно нескольким приемникам (мультикастинг) и прием данных от нескольких передатчиков в рамках одной и той же сессии. Протокол TCP используется для поточной передачи данных, при которой доставка гарантируется на протокольном уровне. Это обеспечивается обязательным подтверждением получения каждого пакета TCP. Напротив, протокол UDP не требует подтверждения получения. В этом случае, как правило, исключается также и фрагментация пакетов, так как пакеты при схеме без установления соединения никак не связаны между собой. По этим причинам UDP в основном служит для передачи мультимедийных данных, где важнее своевременность, а не надежность доставки. Протокол TCP используется там, где важна надежная, безошибочная доставка информации (файловый обмен, передача почтовых сообщений и WEB-технология).
Схема без установления соединения привлекательна также тем, что позволяет при передаче данных от исходного источника к большому числу приемников минимизировать общий трафик. Если бы для этой цели использовался протокол TCP, то при N приемниках надо было бы сформировать N виртуальных каналов и транспортировать N идентичных пакетов (Рисунок 4.4.1). В случае UDP от передатчика до точки разветвления передается только один пакет, что уменьшает загрузку данного участка в N раз (Рисунок 4.4.2). Причем аналогичная экономия может быть реализована и по пути к очередной точке разветвления (смотри описание протокола мультикастинг-маршрутизации PIM).
Интернет в Ethernet
4.1.1.3 Интернет в Ethernet
В Интернет не существует иерархии сетей. Локальная сеть на основе Ethernet, две ЭВМ, связанные через последовательный интерфейс, или общенациональная сеть страны - это все сети и по логике Интернет они все равны. Каждая сеть имеет свое имя и как минимум один IP-адрес. Имя привычнее для людей, адреса - для машин. Между именами и адресами существует строгое соответствие.
Для того чтобы пояснить взаимодействие различных систем в сети, рассмотрим сильно упрощенную схему обработки команды telnet vxdesy.desy.de, которая предполагает осуществление удаленного доступа к vx-кластеру в ДЕЗИ, Гамбург (вызов через windows обрабатывается практически аналогично). Сначала ЭВМ выделяет команду telnet и запускает соответствующую программу. Эта программа рассматривает символьный адрес vxdesy.desy.de в качестве параметра команды telnet.
Локальная часть IP-адреса
Рисунок 4.1.1.3.3. Локальная часть IP-адреса
Такая схема обеспечивает необходимую гибкость, дает возможность разделить локальную сеть на субсети. При работе с субсетью необходимо использовать 32-разрядную маску. Разряды маски должны равняться 1, если сеть рассматривает данный бит как часть адреса сети, и 0, если он характеризует адрес ЭВМ в этой сети. Например:
255.255.255.254 (десятично-точечное представление)
11111111 11111111 11111111 11111110 (двоичное представление)
описывает маску субсети, в которой работает автор. Некоторую информацию о масках в работающей сети можно получить с помощью команды ifconfig (SUN):
/usr/etc/ifconfig -a (курсивом здесь и далее выделяются команды, введенные с клавиатуры)
le0: flags=863
inet 193.124.224.35 netmask ffffffe0 broadcast 193.124.224.32
lo0: flags=869
inet 127.0.0.1 netmask ffffff00,
где le0 и lo0 - имена интерфейсов, флаг -a предполагает выдачу данных обо всех интерфейсах.
Во всех схемах IP-адресации адрес со всеми единицами в секции адрес ЭВМ (host) означает широковещательное обращение ко всем ЭВМ сети. Следует помнить, что широковещательные запросы сильно перегружают сеть, и без особой необходимости их использовать не следует. В настоящее время обсуждаются четыре предложения усовершенствования IP-адресации (см. RFC-1454):
IP-адрес безусловно удобный для использования ЭВМ, почему-то плохо запоминается людьми, поэтому они разработали символьную систему имен для узлов Интернет. Эта система (DNS-
) имеет иерархический характер. Имя содержит несколько полей, разделенных символом "." (точка). В качестве примера можно привести имя домена itepnet - cl.itep.ru. Это имя содержит три поля. Поле ru указывает на принадлежность данного домена России, поле itep определяет принадлежность узла ITEP (Institute for Theoretical and Experimental Physics), cl - характеризует то, что данное конкретное имя относится к кластеру ЭВМ (имя субдомена). Никаких ограничений на число полей в имени, кроме налагаемых здравым смыслом, не существует. Собственно имя домена - это itep.ru. Самое правое поле в имени домена характеризует принадлежность к определенному типу организации или стране.
На показана зависимость числа атак от времени суток, полученная за дней
Рисунок 2.
На Рисунок 3 показана зависимость числа атак от времени суток, полученная за 19 дней.
На показано распределение атак
Рисунок 3.
На Рисунок 4 показано распределение атак по доменным зонам. Из распределения видно, что этому занятию предаются чаще всего "жители" больших и комерческих сетей. Хотя нельзя исключить, что именно они являются чаще жертвами хакеров.
Рисунок 4.
| Код атаки | Описание атаки | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000001 | Land attack. Атакер пытается замедлить работу вашей машины, послав пакет с идентичными адресами получателя и отправителя. Для стека протоколов Интернет такая ситуация не нормальна. ЭВМ пытается выйти из бесконечной петли обращений к самой себе. Имеются пэтчи для большинства операционных систем. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000002 | Unknown IP protocol. Традиционными транспортными протоколами являются UDP, TCP и ICMP, которые работают поверх протокола IP. Код протокола определяется полем тип протокола заголовка IP-дейтограммы. Существует большое число протоколов, которые идентифицируются с помощью номеров портов, например, HTTP, использующий в качестве транспорта TCP. Появление незнакомого протокола должно всегда настораживать, так как может нарушить нормальную работу программ. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000003 | Teardrop attack. Опасное перекрытие IP-фрагментов, сформированное программой teardrop. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем. Адрес отправителя вероятнее всего не является истинным. Это означает, что отправитель использует фальшивый IP-адрес, и прикидывается кем-то еще. К сожалению, не существует простых способов определить, кто в действительности посылает кадры с искаженным адресом отправителя. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000004 | NewTear attack. Опасное перекрытие IP-фрагментов, сформированное программой newtear. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем. Адрес отправителя вероятнее всего не является истинным. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000005 | SynDrop attack. Опасное перекрытие IP-фрагментов, сформированное программой syndrop. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000006 | TearDrop2 attack. Тоже что и, например, SynDrop, но для программы teardrop2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000007 | Bonk DoS.. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000008 | Boink DoS. Тоже что и, например, SynDrop, но для программы boink | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000009 | IP Fragment overlap. Смотри, например 2000005 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000010 | IP last fragment length changed.. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000011 | Too much IP fragmentation.. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000012 |
Ping of death. Предпринимается попытка послать пакет, длина которого больше теоретического предела 65536 байтов.
Системы Firewall блокируют такие пакеты по умолчанию. Разные пакеты могут быть посланы ЭВМ, чтобы вызвать эхо-отклик. Сюда входят:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000207 | UDP short header. Заголовок UDP-дейтограммы содержит менее 8 байт (в надежде сломать программу-обработчик) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000208 | Saihyousen attack. Атака против ConSeal PC Firewall | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000209 | W2K domain controller attack. Атакер посылает error-пакет вашей ЭВМ на UDP порт 464, а ваша система отвечает, возможно получение бесконечного цикла. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000210 | Echo_Denial_of_Service. Посылается UDP-пакет с номером порта отправителя и получателя равным 7. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000211 | Chargen_Denial_of_Service. Посылается UDP-пакет с номером порта отправителя и получателя равным 19. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000301 | TCP port scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000302 | TCP SYN flood. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000303 | WinNuke attack. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000304 | TCP sequence out-of-range. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000305 | TCP FIN scan. Разновидность TCP-сканирования. Однако хакер здесь пытается осуществить так называемое "FIN-сканирование". Он пытается закрыть несуществующее соединение сервера. Это ошибка, но системы иногда выдают разные результаты в зависимости от того, является ли данная услуга доступной. В результате атакер может получить доступ к системе. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000306 | TCP header fragmentation. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000307 | TCP short header. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000308 | TCP XMAS scan. Посылается TCP-сегмент с ISN=0 и битами FIN, URG и PUSH равными 1. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000309 | TCP null scan. Посылается TCP-сегмент с ISN=0 и битами флагов равными нулю. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000310 | TCP ACK ping. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000311 | TCP post connection SYN. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000312 | TCP FIN or RST seq out-of-range.. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000313 |
TCP OS fingerprint. Посылается необычная комбинация TCP-флагов с тем, чтобы посмотреть реакцию.
Вообще, если вы хотите жить немного спокойнее, лучше заблокировать применение telnet, предложив пользователям перейти на SSH. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000908 | Telnet Environment Format String Attack. В районе августа 2000, выявлено большое число атак типа "". Эти атаки связаны с попыткой проникнуть в Telnet-машины путем посылки некорректных переменных окружения (environmental variables with format commands). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000909 | Telnet RESOLV_HOST_CONF. Переменная окружения RESOLV_HOST_CONF посылается с привлечением поля опций Telnet. Это поле не должно никогда изменяться таким способом. Это может означать попытку получения доступа к критическим файлам типа паролей и т.д. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000910 | Telnet bad TERM. Совершена попытка исказить "TERM" Telnet. Клиент Telnet может эмулировать многие виды терминалов текстового типа. Клиент передает эту информацию серверу с помощью переменной "TERM" или команды "term-type". Если обнаружено необычное значение этой переменной, возможно предпринята атака против вашей системы. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000911 | Telnet bad TERMCAP. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000912 | Telnet XDISPLOC. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000913 | Telnet AUTH USER overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000914 | Telnet ENV overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000915 | Telnet login name well known. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2000916 |
Telnet Backdoor. Атакер пытается воспользоваться известным именем/паролем "задней" двери telnet . Протокольный анализатор извлекает login name и пароль из входной строки Telnet и сравнивает их со списком известных параметров доступа для задней двери telnet. Некоторые из них приведены ниже:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001000 | SMTP Attack. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001001 |
SMTP pipe in mail address. кто-то пытается компрометировать e-mail сервер путем посылки исполняемого кода shell внутри e-mail адреса. Это имеет целью компрометировать e-mail сервер, а также субсистему, обрабатывающую заголовки почтового сообщения. Ниже приводится пример SMTP-сессии с попыткой реализации такой атаки: HELO MAIL FROM: |/usr/ucb/tail|/usr/bin/sh RCPT TO: root DATA From: attacker@example.com To: victim@example.com Return-Receipt-To: |foobar Subject: Sample Exploit | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001002 | SMTP DEBUG command. Кто-то сканирует вашу систему с целью выявления ее уязвимости. В 1988, червь Morris уложил Интернет Internet. Одним из путей распространения червя являлась программа sendmail. Sendmail поддерживала нестандартную команду "DEBUG", которая позволяет любому получить контроль над сервером. Червь Morris автоматизировал этот процесс для распространения через системы sendmail Internet. Сейчас маловероятно, что вы найдете такую старую почтовую систему. Следовательно, такая атака будет означать, что кто-то использует универсальный сканер уязвимости. Иногда система может выйти из синхронизма (сбой в ISN), что вызывает большие потери пакетов. В таких условиях по ошибке может быть запущена команда DEBUG. Например, если вы работаете с версией сервера для системы 486, который обрабатывает большое количество e-mail, такая десинхронизация может произойти. Уязвимой системой является Sendmail/5.5.8. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001003 | SMTP login name overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001004 | SMTP EXPN command. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001005 | SMTP VRFY command. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001006 | SMTP WIZ command. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001007 | SMTP Too many recipients. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001008 | SMTP corrupted MAIL command. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001009 | SMTP email name overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001010 | SMTP corrupted RCPT command. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001011 | SMTP relay attempt. Предпринята попытка использования SMTP в качестве ретранслятора сообщений - это может случиться, когда спамер некорректно использует SMTP-сервер. Это одна из наиболее успешных атак на Internet. Спамер регулярно ищет в Интернет ретранслирующие e-mail сервера. Примерно половина всех e-mail серверов поддерживают ретрансляцию в той или иной форме. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001012 | SMTP command overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001013 |
SMTP mail to decode alias. Обнаружено сообщение, адресованное пользователю с именем decode. Это может быть попыткой взломать почтовый сервер, или это может быть частью сканирования системы. Это достаточно старый трюк, выявленный в 1990. Системы UNIX позволяют посылать почту клиенту с именем decode, чтобы передать сообщение не клиенту, а программе uudecode. Атакер может попытаться таким образом переписать файлы таким образом, чтобы проникнуть в систему. Эта дырка связана с файлом /etc/aliases, содержащим строку типа: decode: |/usr/bin/uudecode Сейчас, такой тип вторжения может проявиться лишь в случае универсального сканирования с целью выявления уязвимости вашей системы. Например, атакер пытается передать по каналу uuencoded-файл после команды DATA. HELO MAIL FROM: test@example.com RCPT TO: decode DATA begin 644 /usr/bin/.rhosts $*R`K"@`` ` end . QUIT Этот пример пытается атаковать систему путем записи строки "+ +" в файл ".rhosts". Это будет указывать системе, что следует доверять любому, кто вошел в нее через программу типа 'rlogin'. Этот вид атаки существенен только для почтовых серверов, работающих под UNIX. Просмотрите файл "aliases", размещенный в /etc/aliases. Проверьте, нет ли строк типа: decode: |/usr/bin/uudecode uudecode: |/usr/bin/uuencode -d Удалите эти строки. Заметим, что новые системы не допускают такой возможности. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001014 | SMTP mail to uudecode alias. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001015 | SMTP too many errors. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001016 | SMTP MIME file name overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001017 | SMTP uucp-style recipient. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001018 | SMTP encapsulated relay. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001019 | STMP encapsulated Exchange relay. Spam-атака. Выявляется инкапсулируемый почтовый адрес вида . Некоторые версии Microsoft Exchange не способны проверять эти типы адресов, таким образом, они могут использоваться спамерами для посылки неавторизованной почты. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001020 | SMTP mail to rpmmail alias. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001021 | SMTP MIME name overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001022 | SMTP MIME filename repeated chars. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001023 | SMTP MIME filename repeated blanks. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001024 | SMTP ETRN overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001025 | SMTP Date overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001026 | SMTP Recipient with trailing dot. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001027 | SMTP FROM: field overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001028 | SMTP MIME null charset. Обнаружено незнакомое почтовое сообщение, вероятно сконструированное, чтобы разрушить почтовый сервер. В заголовки "Reply-To:" сообщения встраиваются исполняемые Shell и PERL коды. Когда система откликается, эти коду будут исполнены. Например, старые версии list-сервера MAJORDOMO исполняют любой PERL-скрипт, который вставлен в это поле. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001030 | SMTP ENVID overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001031 | SMTP false attachment. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001032 | SMTP Expn Overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001033 | SMTP Vrfy Overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001034 | SMTP Listserv Overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001036 | SMTP Auth Overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001040 | SMTP Xchg Auth. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001041 | SMTP Turn. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001101 | Finger. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001102 | Finger forwarding. Предпринята попытка использования программы finger для переадресации запроса другой системе. Это часто делается атакерами, чтобы замаскировать свою идентификацию. Finger поддерживает рекурсивные запросы. Запрос типа "rob@foo@bar" просит "bar" сообщить информацию о "rob@foo", заставляя "bar" послать запрос "foo". Эта техника может использоваться для сокрытия истинного источника запроса. Finger является опасным источником информации и по этой причине должен быть заблокирован в /etc/inetd.conf. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001103 | Finger forwarding overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001104 | Finger command. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001105 | Finger list. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001106 | Finger filename. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001107 | Finger overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001108 | Finger search. Демон "cfinger" позволяет осуществлять поиск любых или всех имен пользователей, при вводе "search.*". Эта возможность поиска предоставляет атакеру легкий способ пронумеровать всех пользователей системы. Широкополосные сканеры (напр. CyberCop Scanner, ISS Scanner) осуществляют сканирование этого типа. Сигнатурой для этого вида атаки является наличие строки "search.*" в качестве имени пользователя. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001109 | Finger Backdoor. Кто-то пытается повторно войти в систему через известную заднюю дверь в finger. Раз система была компрометирована, атакеры могу оставит для себя открытую "потайную" дверь, через которую они смогут войти, когда захотят. Например, одна потайная дверь допускает посылку finger команды "cmd_rootsh", которая открывает shell с привилегиями суперпользователя. Заметим, что если потайная дверь действительно имеется, ваша система уже была скомпрометирована. В настоящее время, все известные потайные двери finger существуют только в системах UNIX. Если вы столкнулись с такой проблемой то, во-первых, просмотрите информацию откликов, которая может быть в наличии. Если вы обнаружили какие-то уведомления об ошибках, то вероятно попытка вторжения не была успешной (но не обольщайтесь). Во-вторых, если вы озабочены возможностью наличия потайной двери в системе, исполните команду finger сами. Чтобы устранить уязвимость данного вида, следует, во-первых, рассмотреть возможность удаления услуги finger вообще. Это опасная услуга, которая предоставляет полезную информацию атакерам. Во-вторых, если вы чувствуете, что система компрометирована, следует заново инсталлировать операционную систему. Поищите потайную дверь в списке пользователей. Трудно представить, что какой-то пользователь в вашей системе имеет имя "cmd_shell". Многие широкодиапазонные сканеры ищут такие потайные двери. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001110 | Finger Scan. Производится сканирование известных из Finger имен пользователей с целью получения персональной информации. Например, если вы направляете запрос finger "jsmith", вы вероятно ищите данные о "Jane Smith". В безопасных сетях, любое использование finger подозрительно, так как оно может раскрыть важную информацию о пользователе. Однако, существует в системе большое число не пользовательских аккоунтов, таких как "adm", "bin" или "demo". Попытки Finger обратиться к этим аккоунтам указывают, что кто-то использует протокол finger для того, чтобы сканировать сервер с целью получения более существенной информации. В настоящее время, finger работает на UNIX-системах. Чтобы забыть об этих проблемах, заблокируйте finger. Если он работает, атакеры могут получить нужные им данные, а за помощь им вам не платят. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001111 | Finger Enumeration. Зафиксированы подозрительные команды finger. Finger используется для поиска информации о пользователях. Некоторые системы допускают множественный поиск пользователей. Здесь возможны некорректности. Например, запрос finger о пользователе с именем "e" выдаст список всех пользователей в системе, содержащими "e" в своем имени. Некоторые системы finger допускают также спецификацию множественных имен. Это означает, что finger для "a b c d e f...x y z" перечисляет всех пользователей в системе. В настоящее время, finger работает в основном на системах UNIX. Чтобы забыть об этих проблемах, заблокируйте finger. Если он работает, атакеры могут получить нужные им данные. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001201 | TFTP file not found. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001202 | TFTP file name overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001203 | TFTP Traversal. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001204 | TFTP Exe Transfer. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001205 | TFTP Web Transfer. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001206 | TFTP Echo Bounce. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001301 |
FTP invalid PORT command. Если вы такое обнаружили, это означает, что совершается попытка вторжения в вашу FTP-систему. Немногие ЭВМ допускают такую атаку. Команда "PORT" является частью протокола FTP но обычно незаметна для пользователя, хотя он часто и получает статусные сообщения "PORT command successful". Это уведомляет противоположную сторону о том, кода следует направлять данные. Эта команда форматируется в виде списка из 6 чисел, разделенных запятыми. Например: PORT 192,0,2,63,4,01 Данная команда сообщает противоположной стороне, что данные следует отправлять по адресу 192.0.2.63, порт 1025. Если эта команда искажена, то вероятно атакер пытается компрометировать FTP-сервис. Однако, так как большинство FTP-сервисов противостоит этому типу атаки, шансов у хакера в этом варианте немного. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001302 | FTP PORT bounce to other system. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001303 | FTP PORT restricted. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001304 | FTP CWD ~root command. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001305 |
FTP SITE EXEC command. Старые версии FTP-серверов поддерживают эту команду, которая разрешает нежелательный доступ к серверу. В версиях wu-ftpd ниже 2.2, имеется возможность исполнения программы (об этом хакер может только мечтать) . Ниже показана сессия, где "robert" имеет легальный аккоунт в системе и пытается реализовать режим строчно-командного доступа к shell.
220 example.com FTP server (Version wu-2.1(1) ready. Name (example.com:robert): robert 331 Password required for robert. Password: foobar 230 User robert logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> quote "site exec cp /bin/sh /tmp/.runme" 200-cp /bin/sh /tmp/runme ftp> quote "site exec chmod 6755 /tmp/.runme" 200-chmod 6755 /tmp/runme ftp> quit 221 Goodbye. Теперь пользователь авторизован и может работать с shell на уровне привилегий root в каталоге /tmp. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001306 | FTP USER name overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001307 | FTP password overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001308 | FTP CWD directory overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001309 | FTP file name overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001310 | FTP command line overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001311 | FTP pipe in filename. Совершена попытка исполнить программу на FTP-сервере. Допускающее это ошибка имеется во многих FTP-демонах около 1997, таких что, если перед именем файла присутствует символ PIPE (|), сервер пытается исполнить программу имя которой следует за ним. Так как FTP-сервер обычно работает с привилегией root, может произойти его компрометация. Проверьте, что у вас работает новейшая версия сервера. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001312 | FTP MKD directory overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001313 | ProFTPD snprintf exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001314 | FTP SITE PSWD exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001315 | FTP compress exec exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001316 | FTP file exec exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001317 | FTP command too long. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001318 | FTP data too long. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001319 | FTP NLST directory overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001320 | FTP SITE ZIPCHK metacharacters. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001321 | FTP SITE ZIPCHK buffer overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001322 | FTP SITE EXEC exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001323 | FTP PrivilegedBounce. Кто-то пытается нарушить безопасность FTP-сервиса, чтобы сканировать другие ЭВМ. Если атака FTP используется при одновременной спецификации привилегированного порта, можете не сомневаться - это сетевая атака. Возможно, что FTP-переадресация на непривилегированный порт является результатом FTP-прокси. По этой причине комбинированная атака рассматривается как отдельная сигнатура. Это позволяет атакеру маскировать свою сетевую идентичность. Возможно также, что атакер, используя эту технику, может обойти некоторые плохо конфигурированные фильтры пакетов или firewalls. Например, если ваш mail-сервер допускает соединения посредством telnet с вашим внутренним FTP-сервером, а с внешними ЭВМ из Internet не допускает, атакер сможет соединиться с вашим telnet-портом на вашем SMTP методом переадресации через ваш FTP-сервер. К системам допускающим такую атаку относятся SunOS 4.1.x, Solaris 5.x, большинство систем, работающих со старыми FTP-серверами. Чтобы покончить с такого рода угрозой раз и навсегда. Просмотрите, какие ЭВМ и порты вовлечены в этот процесс. Если это ваши ЭВМ, проконтролируйте, как это реализовано. Если же это не ваша ЭВМ, убедитесь, что администратор этой машины, видит, что в соединении участвует ваш FTP-сервер, и если атака осуществлена, ваша машина будет выглядеть, как источник этой атаки. Вы можете провзаимодействовать с этим администратором или по крайней мере записать logs оригинального источника атаки. После этих дипломатических шагов вам следует установить новую версию FTP-сервера, где данная ошибка исправлена, например, wu-ftpd 2.4.2 beta 15 или более новую. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001324 | FTP Site Exec DotDot. Попытка неавторизованного доступа. Некоторые версии wu-ftpd позволяют использовать команду site exec для удаленных машин. Путем предоставления прохода с определенными параметрами, удаленный пользователь может исполнить произвольные команды на FTP-сервере. Эта атака позволяет атакующему выполнять команды на атакуемой машине. Это может привести к получению им доступа root-уровня. Такой дефект имеют системы wu-ftpd 2.4.1 и ранее. Чтобы защитить себя от таких атак, просмотрите команды, которые атакер использовал. Если они представляют угрозу для атакуемой ЭВМ, можете считать машину скомпрометированной. Обновите программное обеспечение FTP-сервера или замените его вообще. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001325 | FTP Site Exec Format Attack. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001326 | FTP Site Exec Tar. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001327 | FTP Site Chown Overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001328 | FTP AIX Overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001329 | FTP HELP Overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001330 | FTP Glob Overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001331 | FTP Pasv DoS. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001332 | FTP Mget DotDot. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001401 | RWHO host name overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001501 | Back Orifice scan. Кто-то сканирует вашу систему на предмет троянского коня "Back Orifice". Back Orifice сканы наиболее частые атаки, встречающиеся в Internet. Ваша машина просканирована, но еще не выбрана для атаки. Это означает, что хакер сканирует тысячи ЭВМ в Interent, надеясь найти одну, которая была скомпрометирована посредством Back Orifice. Хакер не обязательно охотится именно на вашу ЭВМ. Большинство взломов происходит путем установки хакером инфицированных программ или документов в Internet в надежде, что какой-то неосторожный клиент скопирует и запустит их у себя. Хакер сканирует затем Internet и ищет эти скомпрометированные ЭВМ. Но даже, если ваша машина была скомпрометирована программой Back Orifice, ваша субсистема firewall может заблокировать доступ к ней. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001502 | Netbus response. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001503 | Quake backdoor. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001504 | HP Remote watch. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001505 | Back Orifice response. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001506 | Back Orifice ping. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001507 | PCAnywhere ping. Кто-то пингует систему для того чтобы проверить, работает ли PCAnywhere. Это может быть атака, но может быть и случайный инцидент. PCAnywhere является продуктом Symantec, который позволяет осуществить удаленное управление ЭВМ. Она является очень популярной в Internet для этих легальных целей, позволяя администраторам удаленно контролировать серверы. Хакеры часто сканируют Internet с целью поиска машин, поддерживающих этот продукт. Многие пользователи используют пустые пароли или пароли, которые легко угадать (например слово "password"). Это предоставит легкий доступ хакеру. Если хакер захватил контроль над машиной, он не только могут украсть информацию, но и использовать эту машину для атаки других ЭВМ в Интернет. Случайные сканирования клиентами PCAnywhere обычно видны со стороны соседей. Программа инсталлирует иконку, названную "NETWORK", которая сканирует локальную область. Хотя эти сканы не содержат враждебных намерений, они могут создавать дискомфорт. Чтобы проверить, что на самом деле имеет место, следует рассмотреть IP-адрес атакер. Если IP-адрес относится к локальному сегменту (т.e. подобен вашему IP-адресу), тогда ничего страшного. В противном случае (адрес внешний) - имеет место атака вашей системы. PCanywhere сканирует то, что называется диапазоном "класса C", например, 192.0.2.0 - 192.0.2.255. Если вы не работаете с PCAnywhere, тогда проблем нет. В противном случае, читайте советы по обеспечению безопасности сервера PCAnywhere. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001508 | ISS Ping Scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001509 | ISS UDP scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001510 | Cybercop FTP scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001511 | WhatsUp scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001512 | Back Orifice 2000 ping. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001513 | Back Orifice 2000 auth. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001514 | Back Orifice 2000 command. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001515 | Back Orifice 2000 response. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001517 | Scan by sscan program. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001518 | phAse Zero trojan horse activity. Возможная попытка вторжения. Программа phAse Zero обладает всеми стандартными особенностями троянского коня, включая возможность выгружать и загружать файлы в ЭВМ с помощью FTP, исполнять программы, стирать и копировать файлы, а также читать и записывать в конфигурационную базу данных (registry). Здесь имеется функция 'Trash Server', которая удалит все файлы из каталога вашей системы Windows. phAse Zero работает под Windows 95, 98 и Windows NT. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001519 | SubSeven trojan horse activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001520 | GateCrasher trojan horse activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001521 | GirlFriend trojan horse activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001522 | EvilFTP trojan horse activity. Неавторизованная попытка вторжения. Троянский конь EvilFTP является одним из многих программ подобного рода, который может использовать атакер для доступа к вашей компьютерной системы без вашего ведома. Когда программа, содержащая троянского коня работает, EvilFTP инсталлирует FTP-сервер на порт12346 с login "yo" паролем "connect." Этот троянский конь при инсталляции в удаленной системе позволяет атакеру выгружать и загружать файлы для системы, где он инсталлирован. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001523 | NetSphere trojan horse activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001524 | Trinoo Master activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001525 | Trinoo Daemon activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001526 | NMAP ping. Для проверки вашей системы на уязвимость используется программа NMAP. NMAP -очень популярная программа, используемая хакерами для сканирования Internet. Она работает под Unix, и имеет много конфигурационных опций и использует несколько трюков, чтобы избежать детектирования системами, детектирующими вторжение. NMAP не позволяет хакеру вторгнуться в систему, но допускает получение им полезной информации о конфигурации системы и доступных услугах. Программа часто используется как прелюдия более серьезной атаки. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001527 | NetSphere Client. Активность клиента NetSphere. Это указывает, имеется пользователь в вашей сети, который применил NetSphere для хакерства. Это не должно быть заметно клиентам, если только они сами не работают с NetSpheres. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001528 | Mstream agent activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001529 | Mstream handler activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001530 | SubSeven password-protected activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001531 | Qaz trojan horse activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001532 | LeakTest trojan horse activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001533 | Hack-a-tack trojan horse activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001534 | Hack-a-tack trojan horse ping. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001535 | Bionet trojan horse activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001536 | Y3K trojan horse ping. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001537 | Y3K trojan horse activity. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001601 | FTP login failed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001602 | HTTP login failed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001603 | IMAP4 login failed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001604 | POP3 login failed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001605 | rlogin login failed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001606 | SMB login failed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001607 | SQL login failed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001608 | Telnet login failed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001609 | SMTP login failed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001610 | PCAnywhere login failed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001611 | SOCKS login failed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001612 | VNC login failed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001701 | rpc.automountd overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001702 | rpc.statd overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001703 | rpc.tooltalkd overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001704 | rpc.admind auth. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001705 | rpc.portmap dump. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001706 | rpc.mountd overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001707 | RPC nfs/lockd attack. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001708 | rpc.portmap.set. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001709 | rpc.portmap.unset. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001710 | rpc.pcnfs backdoor. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001711 | rpc.statd dotdot file create. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001712 | rpc.ypupdated command. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001713 | rpc.nfs uid is zero. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001714 | rpc.nfs mknod. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001715 | rpc.nisd long name. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001716 | rpc.statd with automount. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001717 | rpc.cmsd overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001718 | rpc.amd overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001719 | RPC bad credentials. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001720 | RPC suspicious credentials. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001721 | RPC getport probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001722 | rpc.sadmind overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001723 | rpc.SGI FAM access. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001724 | RPC CALLIT unknown. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001725 | RPC CALLIT attack. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001726 | RPC CALLIT mount. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001727 | rpc.bootparam whoami mismatch. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001728 | RPC prog grind. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001729 | RPC high-port portmap. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001730 | RPC ypbind directory climb. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001731 | RPC showmount exports. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001732 | RPC selection_svc hold file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001733 | RPC suspicious lookup. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001734 | RPC SNMPXDMID overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001735 | RPC CALLIT ping. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001736 | RPC yppasswdd overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001737 | rpc.statd Format Attack. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001738 | RPC Sadmind Ping. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001739 | RPC Amd Version. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001801 | IRC buffer overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001802 | SubSeven IRC notification. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001803 | IRC Trinity agent. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001804 | Y3K IRC notification. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001901 | IDENT invalid response. Чужой сервер пытается использовать identd клиента. Многие программы осуществляют реверсивные lookups IDENT. Эти программы уязвимы к атакам, когда сервер присылает некорректный отклик. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001902 | IDENT scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001903 | IDENT suspicious ID. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001904 | IDENT version. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2001905 | IDENT newline. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002001 | SNMP Corrupt. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002002 | SNMP Crack. Обнаружено большое число строк community (паролей), которые индицируют попытку вскрыть систему контроля паролей. Большое число сообщений SNMP с различными строками community за ограниченный период времени должны рассматриваться как подозрительная активность, и как попытка подобрать корректное значение поля community. SNMP(Simple Network Management Protocol) используется для мониторирования параметров оборудования. Однако, это крайне небезопасный протокол, и ничто не препятствует простому подбору пароля путем простого перебора. Следует конфигурировать систему так, чтобы она была доступна со стороны ограниченного числа машин. Рекомендуется также использовать максимально возможно длинные строки community, что позволит зарегистрировать подбор до того, как он успешно завершится. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002003 | SNMP backdoor. Атакер пытается использовать известную "потайную дверь" сетевого оборудования. Однако, многие приборы имеют пароли для "потайной двери", которые могут использоваться для обхода нормальных проверок, предусмотренных нормальной системой обеспечения безопасности. Скрытые и недокументированные строки community имеются во многих субагентах SNMP, которые могут позволить атакерам поменять важные системные параметры. Удаленные атакеры могут убить любой процесс, модифицировать маршруты, или заблокировать сетевые интерфейсы. Важно то, что атакер может выполнить апосредовано произвольные команды, требующие привилегий суперюзера. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002004 | SNMP discovery broadcast. Атакер посылает команду SNMP GET по широковещательному адресу. Это может быть попыткой определить, какие системы поддерживают различные возможности SNMP. Это часто дает полную информацию об управляемом приборе, и иногда может предоставить полный контроль над прибором. В то же время, SNMP крайне небезопасный протокол, с легко угадываемым паролем. В результате, он является популярным протоколом для хакеров. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002005 | SNMP sysName overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002006 | SNMP WINS deletion. Совершена попытка стереть записи WINS через интерфейс SNMP сервера. Это может быть попытка реализовать Denial-of-Service (DoS) или просканировать систему безопасности. Клиенты Windows контактируют с системой WINS для того, чтобы найти серверы. Многие системы уязвимы для атак при помощи SNMP-команд, посланных серверу для того, чтобы стереть записи. Это не взламывает сервер, но после стирания записи в базе данных, клиенты и серверые смогут более найти друг друга. Однако этот отказ обслуживания (DoS) может предварять другие атаки. Это может быть частью широко диапазонного сканирования с целью поиска слабых точек в сети. Эта атака может быть против систем, где нет работающих SNMP или WINS. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002007 | SNMP SET sysContact. Совершена попытка удаленно установить поле sysContact через SNMP. Это вероятно сканирование уязвимых мест вашей системы. Группа SNMP "system" используется всеми MIB. Она часто сканируется хакерами при предварительной разведке. Одним из способов сканирования является выполнение команд SET для поля "sysContact" для того, чтобы просмотреть, реагирует ли какая-либо система. Такие SET часто используют для взлома хорошо известные пароли/communities. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002008 | SNMP lanmanger enumeration. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002009 | SNMP TFTP retrieval. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002010 | SNMP hangup. Совершена попытка подвесить пользователя коммутируемой телефонной сети с помощью протокола SNMP. Некоторые типы сетевого оборудования (Ascend, Livingston, Cisco, etc.) могут допускать такое подвешивание пользователей. Это может быть обычным отказом обслуживания (DoS) в chat-комнатах и при играх в реальном времени. Один участник в chat-комнате может не любить другого. Он может взять IP-адрес жертвы, затем осуществлять поиск, пока не найдут прибор доступа, через который подключен клиент телефонной сети. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002011 | SNMP disable authen-traps. Совершена попытка заблокировать трэпы неудач SNMP-аутентификации, возможно с целью замаскировать активность хакера. Если строка community некорректна, прибор может послать на консоль управления трэп "authentication-failure". Эти строки community не управляют доступом всего SNMP-агента MIB. Вместо этого, они управляют "видами" MIB: различные строки community могут позволять управление различными частями MIB. Предположим сценарий, где атакер желает взломать строку community, отвечающую за секцию MIB поставщика. Это включает множество (возможно миллионы) попыток выяснить правильный пароль. Следовательно, чтобы избежать оповещений об атаке, нападающий должен заблокировать трэпы, которые могут поступить на консоль. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002012 |
SNMP snmpdx attack. Совершена попытка заменить Sun Solstice Extension Agent, используя SNMP. Это может быть попытка вскрыть систему. Sun Solaris 2.6 поставляется со встроенной SNMP. В этот пакет входит возможность "extension agents": агенты, которые подключены к первичному SNMP-агенту для управления другими частями системы. Следует просмотреть log-book b jndtnbnm на вопросы: Имеется ли платформа управления, которая может выполнять подобные операции? Является ли строка "community" одной из "печально" известных для Solaris (в особенности "all private")? Параметр "val" содержит имя программы, которая будет исполнена. Выглядит ли это как демон или выглядит ли она как программа, предназначенная для компрометации системы? Типичными вариантами компрометации является создание xterm или скрипта, который изменяет /etc/passwd. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002013 | SNMP 3Com communities. Совершена попытка прочесть строку community/пароля устройства 3Com с помощью SNMP. Это может быть попыткой проникновения в систему. Многие старые версии оборудования 3Com содержат дефекты, которые делают строку community/пароля общедоступной. Атакер, чтобы получить пароли, может прочесть специфические таблицы, используя строку community+"public". После этого атакер получает полный контроль над прибором. Такого рода атаки возможны для хабов 3Com SuperStack II версий ранее 2.12, карт HiPer Arc, с кодами выпуска ранее 4.1.59. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002014 | SNMP dialup username. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002015 | SNMP dialup phone number. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002016 | SNMP scanner. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002017 | SNMP passwd. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002018 | SNMP community long. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002019 | SNMP echo bounce. Обнаружен пакет UDP путешествующий между портами SNMP и ECHO. Техника, которая иногда используется, заключается в том, что пакеты SNMP посылаются службе ECHO промежуточной системы. IP-адрес отправителя фальсифицируется так, чтобы ECHO посылалось службе SNMP атакуемой системы. Атакуемый объект доверяет промежуточной системе и поэтому принимает пакет. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002020 | SNMP HP Route Metachar. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002101 | rlogin -froot backdoor. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002102 | rlogin login name overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002103 | rlogin password overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002104 | rlogin TERM overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002105 | Rlogin login name well known. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002201 | Melissa virus. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002202 | Papa virus. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002203 | PICTURE.EXE virus. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002204 | W97M.Marker.a virus. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002205 | ExploreZip worm. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002206 | Keystrokes monitored. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002207 | PrettyPark worm. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002208 | ILOVEYOU worm. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002209 | Worm extensions. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002210 | Worm address. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002301 | Duplicate IP address. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002401 | NNTP name overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002402 | NNTP pipe seen. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002403 | NNTP Message-ID too long. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002500 | Suspicious URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002501 | bat URL type. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002502 | cmd URL type. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002503 | CGI aglimpse. Совершена попытка исполнить программу aglimpse, которая имеет известные уязвимости. Атакер сканирует web-сервер системы и ищет потенциальные уязвимости в секции web-сервера "dynamic content generation" (динамическая генерация содержимого). Эта утилита web-сервера исполняет отдельную программу для генерации web-страниц, когда пользователи осуществляют доступ к сайту. Существует сотни таких программ, которые содержат ошибки в сфере безопасности. В данном примере, хакер просматривает web-сервер и ищет одну из таких программ. Большая часть того, что вы читали в новостях о хакерских "штучках", является описанием слабостей таких программ и повреждений web-сайта. Особенно много информации можно найти о слабостях cgi-bin. Если скрипт виден внешнему миру, вам следует удалить его из данного каталога. Следует также удалить все динамическое содержимое, которое не является абсолютно необходимым для работы web-сайта. Выполните двойную проверку скриптов, которые вы действительно используете, на предмет наличия в них брешей уязвимости. Данная атака является стандартной, использующей метасимвольный CGI на PER. Программа PERL передает "поврежденный" ввод пользователя непосредственно в интерпретатору shell. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002504 | CGI AnyForm2. Совершена попытка исполнить программу anyform2, которая имеет известную уязвимость. Программа AnyForm cgi-bin содержит уязвимость, которая позволяет удаленному атакеру исполнять программы Web-сервера. Атакер сканирует web-сервер системы и ищет потенциальные уязвимости в секции web-сервера "dynamic content generation" (динамическая генерация содержимого). Эта утилита web-сервера исполняет отдельную программу для генерации web-страниц, когда пользователи осуществляют доступ к сайту. Существует сотни таких программ, которые содержат ошибки в сфере безопасности. В данном примере, хакер просматривает web-сервер и ищет одну из таких программ. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002505 | CGI bash. Совершена попытка исполнить скрипт bash, который в случае успеха, позволит хакеру получить доступ к серверу. Это программа shell, которая может исполнять произвольные операции на сервере. Если она была случайно помещена в удаленно доступный каталог, и, если вы обнаружили, что какие-то параметры системы стали доступны хакеру, считайте свою систему скомпрометированной. Вы должны немедленно удалить эту программу из данного каталога, проверить систему на наличие троянских коней и проконтролировать, не изменялась ли ее конфигурация. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002506 | CGI campas. Совершена попытка исполнить campas, которая имеет известную уязвимость. Это известный скрипт, поставляемый с оригинальными web-серверами NCSA. Он оказался весьма популярным среди хакеров (вместе с phf), но в настоящее время его важность незначительна. Эта точка уязвимости позволяет удаленному атакеру исполнять команды на ЭВМ Web-сервера, как если бы он работал на самой машине, где размещен httpd. Эта уязвимость разрешает доступ хакеру к файлам web-сервера. При определенных конфигурациях web-сервера возможно получение хакером административного доступа к ЭВМ. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002507 | CGI convert.bas. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002508 | CGI csh. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002509 | CGI faxsurvey. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002510 | CGI finger. Произведена попытка исполнить программу finger, который может позволить хакеру неавторизованный доступ к серверу. Атакер сканирует web-сервер системы и ищет потенциальные точки уязвимости в секции "dynamic content generation". Эта утилита web-сервера исполняет отдельную программу для генерации web-страниц, когда пользователь получает доступ к сайту. Существуют сотни таких программ, которые имею окна уязвимости. в данном примере, хакер просматривает web-сервер и ищет одну из таких уязвимых программ. Дополнительную информацию можно найти в cgi-bin exploits. Если этот скрипт виден внешнему миру, его следует удалить из данного каталога. Следует удалить также все динамические данные, которые совершенно необходимы для работы web-сайта. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002511 | CGI formmail. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002512 | CGI formmail.pl. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002513 | CGI glimpse. Попытка исполнения программы glimpse, которая известна своими уязвимостями. Эти уязвимости позволяют атакеру исполнять команды на ЭВМ Web-сервера во время работы процесса пользователя в httpd. В зависимости от конфигурации web-сервер, это может позволить атакеру получит root или административный доступ к ЭВМ. В любом случае, атакер сможет изменить содержимое web-сайта. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002514 | CGI guestbook.cgi. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002515 | CGI guestbook.pl. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002516 |
CGI handler. Попытка исполнения CGI-хандлера, который обладает известными слабостями Эта CGI-программа является частью "Outbox Environment" в системах SGI IRIX. Программа может использоваться для выполнения любой команды на web-сервере. Для того, чтобы реализовать это, используйте программу Telnet следующим образом: telnet www.example.com 80 GET /cgi-bin/handler/useless_shit;cat /etc/passwd|?data=Download HTTP/1.0 Используйте символ TAB, чтобы ввести пробел в пределах команды. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002517 | CGI htmlscript. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002518 | CGI info2www. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002519 | CGI machineinfo. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002520 | CGI nph-test-cgi. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002521 | CGI perl. Произведена попытка исполнить perl-скрипт, который позволит хакеру неавторизованный доступ к серверу. Это программа shell, которая может выполнить произвольные операции на сервере. Если эта программа случайно помещена в удаленно доступный каталог, и, если выявлена модификация некоторого системного параметра, можете считать свою систему скомпрометированной. Вам следует немедленно удалить программу из ее каталога и поместить в более подходящее место, проверьте вашу систему на наличие троянских коней, а также проконтролируйте конфигурацию на предмет возможных модификаций. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002522 | CGI perl.exe. Произведена попытка исполнить perl.exe, которая позволит хакеру неавторизованный доступ к серверу. Это программа shell, которая может выполнить произвольные операции на сервере. Если эта программа случайно помещена в удаленно доступный каталог, и, если выявлена модификация некоторого системного параметра, можете считать свою систему скомпрометированной. Вам следует немедленно удалить программу из ее каталога и поместить в более подходящее место, проверьте вашу систему на наличие троянских коней, а также проконтролируйте конфигурацию на предмет возможных модификаций. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002523 | CGI pfdispaly.cgi. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002524 | CGI phf. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002525 | CGI rguest.exe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002526 | CGI wguest.exe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002527 | CGI rksh. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002528 | CGI sh. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002529 | CGI tcsh. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002530 | CGI test-cgi.tcl. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002531 | CGI test-cgi. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002532 | CGI view-source. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002533 | CGI webdist.cgi. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002534 | CGI webgais. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002535 | CGI websendmail. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002536 | CGI win-c-sample.exe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002537 | CGI wwwboard.pl. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002538 | CGI uploader.exe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002539 | CGI mlog.html. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002540 | CGI mylog.html. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002541 | CGI snork.bat. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002542 | CGI newdsn.exe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002543 | FrontPage service.pwd. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002544 | .bash_history URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002545 | .url URL type. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002546 | .lnk URL type. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002547 | WebStore admin URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002548 | Shopping cart order URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002549 | Order Form V1.2 data URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002550 | Order Form data URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002551 | EZMall data URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002552 | QuikStore configuration URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002553 | SoftCart password URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002554 | Cold Fusion Sample URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002555 | favicon.ico bad format. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002556 | Site Server sample URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002557 | IIS sample URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002558 | IIS password change. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002559 | IIS malformed .HTR request. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002560 | IIS data service query. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002561 | .htaccess URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002562 | passwd.txt URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002563 | NT system backup URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002564 | CGI imagemap.exe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002565 | adpassword.txt URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002566 | CGI whois suspicious field. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002567 | Cold Fusion cache URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002568 | IIS malformed HTW request. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002569 | CGI finger.cgi. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002570 | WebSpeed admin URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002571 | UBB suspicious posting. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002572 | SubSeven ICQ pager URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002573 | Oracle batch file URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002574 | sojourn.cgi argument contains %20. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002575 | Index Server null.htw exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002576 | FrontPage extension backdoor URL. Прислан "подозрительный" URL. Библиотека dvwssr.dll, встроенная в расширения FrontPage 98 для IIS, включает в себя ключ шифрования "Netscape engineers are weenies!". Этот ключ может быть использован для маскирования имени запрошенного файла, который затем передается в качестве аргумента в dvwssr.dll URL. Любой, кто имеет привилегии доступа к web-серверу ЭВМ мишени может загрузить любую Web-страницу, включая файлы текстов программ ASP. Используя файл dvwsrr.dll можно также переполнить буфер. Успешная атака может позволить исполнение на сервере удаленной программы. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002577 | FrontPage htimage.exe URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002578 | InfoSearch CGI exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002579 | Cart32 Clientlist URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002580 | Cart32 ChangeAdminPassword URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002581 | Listserv CGI exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002582 | Calendar CGI exploit. Подозрительный URL. Конфигурационный параметр содержит мета-символы, которые вероятно означают, что атакер пытается использовать слабости в некоторых версиях CGI-скрипта. В случае успеха, он сможет выполнить произвольную команду на сервере. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002583 | Rockliffe CGI exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002584 | RealServer Denial-of-service URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002585 | Java Admin Servlet backdoor URL. Административный модуль Java Web Server допускает компиляцию и исполнение программы Java server с помощью специального URL. Если атакеру удалось загрузить свой собственный Java-код на сервере, он может тогда скомпилировать и исполнить этот код и получить контроль над серверной системой. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002586 | DOS DoS URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002587 | Auction Weaver CGI exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002589 | CGI jj exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002590 | classifieds.cgi. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002591 | BNBSurvey survey.cgi. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002592 | YaBB exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002593 | Webplus CGI exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002594 | Squid cachemgr.cgi. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002595 | IIS system32 command. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002596 | Webevent admin. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002597 | Unify UploadServlet. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002598 | Thinking Arts directory traversal. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002599 | Lotus Domino directory traversal. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002600 | Commerce.cgi directory traversal. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002601 | CGI mailnews suspicious field. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002602 | FrontPage Publishing DoS. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002603 | way-board cgi file access. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002604 | roads cgi file access. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002605 | Hack-a-tack ICQ pager URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002606 | Bionet ICQ pager URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002607 | IIS .printer overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002608 | ISAPI index extension overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002609 | Y3K ICQ pager URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002610 | HTTP Pfdisplay Execute. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002611 | HTTP Pfdisplay Read. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002701 | SMB passwd file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002702 | SMB sam file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002703 | SMB winreg file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002704 | SMB pwl file type. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002705 | SMB win.ini file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002706 | Startup file access. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002707 | SMB autoexec.bat file access. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002710 | SMB RICHED20.DLL access. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002801 | MS rpc dump. Атакер пытается сканировать вашу систему для услуг RPC/DCOM. Возможно он ищет слабости в системе доступа. Была попытка загрузки списка всех услуг RCP/DCOM. Это специальная команда, которая может быть послана к "RPC End-Point Mapper" работающему с . Эта атака не направлена непосредственно на вторжение. Она является частью (разведывательного этапа) reconnaissance атаки. Команда 'epdump' попросит ЭВМ Windows перечислить все работающие сервисы. Хакер, получив эти данные, сможет эффективнее искать слабые места в вашей обороне. Если хакер найдет какие-то их этих услуг, он вероятно попытается воспользоваться ими. Например, существуют пути, посредством которых спамер может направить e-mail через Microsoft Exchange Servers. Путем выполнения 'epdump', спамер может выяснить, работает ли машина в качестве сервера. Если это так, спамер может затем заставить систему переадресовать SPAM своим "клиентам". Зафильтруйте порт 135 в firewall, как для UDP так и TCP. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002802 | MS share dump. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002803 | MS domain dump. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002804 | MS name lookup. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002805 | MS security ID lookup. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002806 | Malformed LSA request. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002807 | RFPoison attack. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002808 | LsaLookup Denial of Service. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002901 | PPTP malformed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002902 | IGMP fragments. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002903 | SNTP malformed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002904 | XDMCP gdm exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002905 | VNC no authentication. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002906 | VCF attachment overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002907 | SNTP overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002908 | Quake Exploit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002911 | RADIUS User Overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2002912 | RADIUS Pass Overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003001 | HTTP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003002 | POP3 port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003003 | SMTP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003004 | FTP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003005 | IMAP4 port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003006 | TELNET port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003007 | FINGER port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003008 | RLOGIN port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003009 | NetBIOS port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003010 | NNTP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003011 | DNS TCP port robe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003012 | PCANYWHERE port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003013 | SQL port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003014 | MSRPC TCP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003015 | XWINDOWS port probe. Возможно хакер просканировал вашу систему, чтобы проверить, доступно ли XWINDOWS. Иногда это делается в ходе подготовки будущей атаки, или иногда это делается с целью выяснения, уязвима ли ваша система. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003016 | RPC TCP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003017 | SOCKS port probe. Кто-то сканирует вашу систему, чтобы проверить, не работает ли там SOCKS. Это означает, что хакер хочет устроить переадресацию трафика через вашу систему на какой-то другой сетевой объект. Это может быть также chat-сервер, который пытается определить, не пробует ли кто-то использовать вашу систему для переадресации. SOCKS представляет собой систему, которая позволяет нескольким машинам работать через общее Интернет соединение. Многие приложения поддерживают SOCKS. Типичным продуктом является WinGate. WinGate инсталлируется на ЭВМ, которая имеет реальное Интернет соединение. Все другие машины в пределах данной области подключаются к Интернет через эту ЭВМ. Проблема с SOCKS и продуктами типа WinGate заключается в том, что они не делают различия между отправителем и получателем, что облегчает удаленным машинам из Интернет получить доступ к внутренним ЭВМ. Что важно, это может позволить хакеру получить доступ к другим машинам через вашу систему. При этом хакер маскирует свое истинное положение в сети. Атака против жертвы выглядит так, как если бы она была предпринята со стороны вашей машины. Этот вид атаки на первом этапе выглядит как сканирование. При использовании SOCKs систему следует конфигурировать так, чтобы заблокировать посторонний доступ. Хакер рассчитывает на вашу ошибку при конфигурации. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003018 | PPTP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003019 | IRC port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003020 | IDENT port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003021 | Linux conf port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003022 | LPR port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003101 | TCP trojan horse probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003102 | TCP port probe. Кто-то пытался получить доступ к вашей машине, но не смог. Это довольно распространенный вид атаки. Типовой хакер сканирует миллионы ЭВМ, не обольщайтесь вы не являетесь главным объектом интересов хакеров, но и расслабляться пожалуй не следует. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003103 | Netbus probe. Кто-то попрововал получить доступ к вашей ЭВМ с помощью "NetBus Trojan Horse" и потерпел неудачу. Хакер ищет ЭВМ, скомпрометированную посредством этой программы. Раз вы не скомпрометированы, хакер потерпел неудачу. Программа Trojan рассылается клиентам в надежде, что какой-то легкомысленный человек ее запустит. Задача такой программы похитить пароль, установить вирус, или переформатировать ваш диск. Специальную популярную группу образуют троянские кони, обеспечивающие удаленный доступ к вашей машине. Такие программы хакер пытается прислать по почте, через chat или новости, при этом хакер может не знать, где в Интернет находится ваша ЭВМ (он не знает, кто читает новости, да и по почте он рассылает эту гадость по тысячам адресов). Хакер знает только, кто является вашим провайдером, и вынужден сканировать всех клиентов данного ISP. При таком сканировании хакера устроит ситуация, когда вы получили данного троянского коня от другого атакера. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003104 | Proxy port probe. Атакер сканирует вашу систему с целью обнаружения прокси-сервера. Затем атакер может воспользоваться вашим прокси-сервером для анонимного просмотра Internet. В настоящее время сканирование TCP-портов 3128,8000 или 8080 рассматривается как обращение к прокси. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003105 | SubSeven port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003106 | T0rn port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003201 | SECURITY/SAM reg hack. Была предпринята попытка доступа к ключу registry под HKLM/SECURITY/SAM. Под этим ключом зарегистрированы имена и пароли пользователей. Хотя пароли зашифрованы, они могут быть проанализированы off-line и выяснены путем грубого перебора. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003202 |
RUN reg hack. Была предпринята попытка записи в ключи registry, которые управляют программой при загрузке системы или когда в систему входит новый пользователь. Такими ключами являются HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Run HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunOnce HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunOnceEx HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunServices HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunServicesOnce HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunServicesEx Если имела места попытка записи в один из этих ключей, это может быть попыткой продвинуть Trojan Horse. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003203 |
RDS reg hack. Была предпринята серьезная попытка скомпрометировать систему или легальная сетевая платформа осуществляет удаленное конфигурирование системы. Осуществлена попытка удаленной записи ключей registry HKLM\SOFTWARE\Microsoft\DataFactory\HandlerInfo или HKLM\SOFTWARE\Microsoft\Jet\3.5\Engines\SandboxMode. Эти ключи ограничивают удаленный доступ к определенным базам данных в системе Windows. Атакер может попытаться установить свои значения для этих объектов registry, так что неавторизованный удаленный доступ может быть осуществлен позднее через точку уязвимости RDO exploit. По умолчанию, эти ключи могут быть переписаны кем угодно. Разрешения должны быть изменены так, что только администратор мог их менять. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003204 | Index Server reg hack. Была предпринята попытка удаленного доступа к записям Index Server's registry. Сделана попытка доступа к ключу registry Remove remote access в HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\Winreg\AllowedPaths | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003205 | NT RASMAN Privilege Escalation attempt. Была предпринята попытка удаленного доступа к троянскому коню RAS manager. Сделана попытка доступа к ключу registry HKLM\SYSTEM\CurrentControlSet\Services\RASMan, который удаленно изменяет программу путем изменения сервера, при следующем запуске ЭВМ, будет исполнена специфицированная программа. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003206 | LSA Secrets attempt. Была предпринята попытка удаленного доступа к "Local System Authority" через вызов registry. Атакер получает удаленный доступ к информации о секретных пароля хremotely. Эти пароли хранятся в зашифрованном виде в registry. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003207 | AeDebug reg hack. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003208 | IMail privilege escalation attempt. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003209 | SQL Exec Passwd. Была предпринята попытка сканирования записей SQLExecutive registry. Происходит подозрительное чтение записей registry из SQL-сервера. Иногда пароли записываются в registry, что делает систему уязвимой. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003301 | AOL Instant Messenger overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003302 | AOL w00w00 attack. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003401 | SNMP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003402 | RPC UDP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003403 | NFS port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003404 | TFTP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003405 | MSRPC UDP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003406 | UDP ECHO port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003407 | CHARGEN port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003408 | QOTD port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003409 | DNS UDP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003410 | MSDNS port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003411 | NFS-LOCKD port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003412 | Norton Antivirus port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003501 | UDP Trojan Horse probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003502 | UDP port probe. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003601 | FTP passwd file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003602 | FTP sam file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003604 | FTP pwl file type. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003605 | FTP win.ini file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003606 | FTP Host File. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003701 | TFTP passwd file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003702 | TFTP sam file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003704 | TFTP pwl file type. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003705 | TFTP win.ini file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003706 | TFTP Host File. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003707 | TFTP Alcatel files. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003801 | HTTP GET passwd file. Была предпринята подозрительная попытка доступа к файлу. Сделана попытка доступа к файлу passwd, который содержит зашифрованные Unix-пароли. Атакер может после этого использовать общедоступные программные средства для вскрытия паролей, содержащихся в этом файле. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003802 | HTTP GET sam file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003804 | HTTP GET pwl file type. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003806 | HTTP GET AltaVista password. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003901 | HTTP POST passwd file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003902 | HTTP POST sam file. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003904 | HTTP POST pwl file type. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2003905 | HTTP POST win.ini file. Была предпринята попытка удаленного доступа к системному файлу WIN.INI посредством Web-формы. Эта попытка может быть сопряжена с намерением реконфигурировать систему, чтобы реконфигурированная система при последующем запуске загрузила троянского коня. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004001 | SOCKS connect. Кто-то подключился через вашу систему, используя протокол SOCKS. Это может быть хакер, который хочет переадресовать трафик через вашу систему на другие ЭВМ, а также сервер chat, пытающийся определить, не пробует ли кто-то проскочить через вашу систему чтобы работать анонимно на "халяву". SOCKS представляет собой систему, которая позволяет нескольким машинам работать через общее Интернет соединение. Многие приложения поддерживают SOCKS. Типичным продуктом является WinGate. WinGate инсталлируется на ЭВМ, которая имеет реальное Интернет соединение. Все другие машины в пределах данной области подключаются к Интернет через эту ЭВМ. Проблема с SOCKS и продуктами типа WinGate заключается в том, что они не делают различия между отправителем и получателем, что облегчает удаленным машинам из Интернет получить доступ ко внутренним ЭВМ. Что важно, это может позволить хакеру получить доступ к другим машинам через вашу систему. При этом хакер маскирует свое истинное положение в сети. Атака против жертвы выглядит так, как если бы она была предпринята со стороны вашей машины. Этот вид атаки на первом этапе выглядит как сканирование. При использовании SOCKs систему следует конфигурировать так, чтобы заблокировать посторонний доступ. Хакер рассчитывает на вашу ошибку при конфигурации. Ваша внутренняя сеть должна использовать IP-адреса, которые никогда не появляются в Internet. Такими адресами обычно являются "192.168.x.x", "172.16.x.x" или "10.x.x.x". | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004002 | SOCKS over SOCKS. Кто-то подключился через вашу систему, используя протокол SOCKS. то может быть хакер, который хочет переадресовать трафик через вашу систему на другие ЭВМ. В этом случае, трафик оказывается инкапсулированным в SOCKS, это означает, что атакер вероятно намерен использовать вашу систему для переадресации к другой системе SOCKS. SOCKS представляет собой систему, которая позволяет нескольким машинам работать через общее Интернет соединение. Многие приложения поддерживают SOCKS. Типичным продуктом является WinGate. WinGate инсталлируется на ЭВМ, которая имеет реальное Интернет соединение. Все другие машины в пределах данной области подключаются к Интернет через эту ЭВМ. Проблема с SOCKS и продуктами типа WinGate заключается в том, что они не делают различия между отправителем и получателем, что облегчает удаленным машинам из Интернет получить доступ ко внутренним ЭВМ. Что важно, это может позволить хакеру получить доступ к другим машинам через вашу систему. При этом хакер маскирует свое истинное положение в сети. Атака против жертвы выглядит так, как если бы она была предпринята со стороны вашей машины. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004101 | Java contains Brown Orifice attack. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004201 | HTTP Cross site scripting. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004301 | DHCP Domain Metachar. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004302 | BOOTP File Overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004303 | UPNP NOTIFY overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004401 | SubSeven email. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004402 | Bionet email. Программа троянского коня Bionet имеет возможность посылать оповещения через e-mail, когда система, содержащая троянского коня, загружается. Это позволяет хакеру знать, что Bionet работает, и ваша система может быть компрометирована хакером. Судя по всему ваша система скомпрометирована. Вам следует использовать антивирусную программу, чтобы немедленно удалить троянского коня Bionet из вашей системы. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004403 | Y3K email. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004501 | HTTP GET contains xp_cmdshell. В качестве аргумента URL обнаружена строка xp_cmdshell; это обычно указывает, что предпринята попытка исполнить команду shell для атакера исполнять на сервере команды shell. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004502 | HTTP POST contains xp_cmdshell. В данных, передаваемых Web-сайту, обнаружена строка xp_cmdshell. Это обычно указывает, что предпринята попытка выполнить команду shell на SQL-сервере. Если SQL-сервер некорректно сконфигурирован, имеется возможность для атакера выполнять на сервере команды shell. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004601 | Code Red I. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004602 | Code Red II. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2004603 | Code Red II+. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2009100 | DNS crack successful. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2009201 | ISS Scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2009202 | CyberCop Scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2009203 | Nessus Scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2009204 | Satan Scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2009205 | Saint Scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2009206 | Cerebus Scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2009207 | Retina Scan. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2010000-2010999 | User-specified filename. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2011000-2011999 | User-specified URL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2012000-2012999 | User-specified email recipient. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2013000-2013999 | User-specified email pattern. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2014000-2014999 | User-specified MIME-attached filename. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2015000-2015999 | User-specified TCP probe port. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2016000-2016999 | User-specified UDP probe port. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2017000-2017999 | User-specified registry key. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2018000-2018999 | User-specified TCP trojan response. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2019000-2019999 | User-specified IRC channel name. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2020000-2020999 | User-specified Java pattern. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2900001 | Application Terminated. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2900002 | Application Added. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2900003 | Application Communication Blocked. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Config | Configuration parameters. |
Обмен аутентификации
Рисунок .5. Обмен аутентификации
Обмен аутентификации использует следующие торговые компоненты, которыми обмениваются между собой две организации: Компонент запрос аутентификации, который требует аутентификации, указывает, какой алгоритм аутентификации следует употребить. Компонент запроса данных о торговых ролях, который требует информации об организации, например адрес. Компонент отклик аутентификации, который содержит отклик на вызов, сформированный получателем компонента запроса аутентификации. Компонент организации, который содержит результат запроса данных о торговых ролях. Компонент статуса, который содержит результаты верификации отклика аутентификации второго партнера.
2.3. Обзор базового уровня IOTP
Здесь описываются операции, которые образуют основу IOTP. Главными факторами, определяющими реализацию IOTP, являются роли, которые поддерживает реализованное решение. Роли в пределах IOTP более детально описаны в разделе 2.1. Базовыми ролями являются: продавец, покупатель, кассир, агент доставки и агент обслуживания покупателя.
Существует три типа Кассиров:
принимающие платеж как часть сделки или совершающие выплату, как возврат платежа; принимающие средства как часть депозитной операции; выдающие средства при отмене сделки.Ниже приведенная таблица определяет для каждой роли операции IOTP и торговые блоки, которые должны поддерживаться для каждой роли.
Продавцы |
||||||
| Склад | Пла-тиль-щик | Получа-тель платежа | Покупатель | Кассир | Агент доставки | |
Транзакции |
||||||
| Покупка | Нужно | Нужно | ||||
Продавцы |
||||||
| Store | Пла-тиль-щик | Получа-тель платежа | Покупатель | Кассир | Агент доставки | |
| Возврат средств | Нужно | b) Зависит |
||||
| Аутентификация | Можно | Нужна | Можно | b) Зависит |
||
| Обмен ценностями | Можно | Нужно | ||||
| Отзыв | Нужно | b) Зависит |
||||
| Депозит | Нужно | b) Зависит |
||||
| Запрос данных | Нужно | Нужно | Нужно | Можно | Нужно | Нужно |
| Ping | Нужно | Нужно | Нужно | Можно | Нужно | Нужно |
Торговые блоки |
||||||
| TPO | Нужно | Нужно | Нужно | Нужно | ||
| Выбор TPO | Нужно | Нужно | Нужно | Нужно | ||
| Запрос Auth | a) Зависит |
a) Зависит |
a) Зависит |
|||
| Отклик Auth | a) Зависит |
a) Зависит |
a) Зависит |
|||
| Отклик предложения | Нужно | Нужно | Нужно | Нужно | ||
| Запрос платежа | Нужно | Нужно | ||||
| Платежный обмен | Нужно | Нужно | ||||
| Платежный отклик | Нужно | Нужно | ||||
| Запрос доставки | Нужно | Нужно | ||||
| Отклик доставки | Нужно | Нужно | ||||
Продавцы |
||||||
| Склад | Пла-тильщик | Получа-тель | Покупатель | Кассир | Агент доставки | |
| Запрос данных | Нужно | Нужно | Нужно | Нужно | Нужно | Нужно |
| Отклик данных | Нужно | Нужно | Нужно | Нужно | Нужно | Нужно |
| Запрос Ping | Нужно | Нужно | Нужно | Нужно | Нужно | Нужно |
| Отклик Ping | Нужно | Нужно | Нужно | Нужно | Нужно | Нужно |
| Подпись | Нужно | Нужно | Нужно | Ограничено | Нужно | Нужно |
| Ошибка | Нужно | Нужно | Нужно | Нужно | Нужно | Нужно |
В выше приведенной таблице:
"Нужно" означает, что торговая роль должна поддерживать операцию или торговый блок. "Можно" означает, что программная реализация может поддерживать операцию или торговый блок по усмотрению разработчика. "Зависит" означает, что программная реализация операции или торгового блока зависит от одного из следующих условий:
| - Поддерживаются базовые операции аутентификации IOTP; | |
| - Если требуется для данного метода платежа, как это определено в его сопровождающем документе IOTP. |
Обмен для предложения, независимого от вида платежа
Рисунок .20. Обмен для предложения, независимого от вида платежа
Заметим, что документальный обмен предложения, независимого от видов платежа происходит, когда продавец предлагает покупателю лишь один вид платежа, протокол и вид валюты. Это может произойти и при нескольких предлагаемых видах платежа, если имеется один Кассир и все виды платежа используют один и тот же набор протоколов.
Заметим, что блоки TPO и отклика Offer могут быть посланы в одном IOTP-сообщении (смотри документальный обмен предложения, зависимого от вида платежа), даже если блок отклика Offer не изменяется. Однако это увеличивает число сообщений в транзакции и следовательно может увеличить время отклика.
Приложения, поддерживающие торговую роль Покупателя, должны проверять наличие блока отклика Offer в первом сообщении IOTP с тем чтобы определить, является ли обмен зависимым от вида платежа.
Принципы обработки сообщений
Получив сообщение TPO и отклика Offer (смотри ниже), Покупатель может:
сформировать и послать следующее сообщение IOTP транзакции соответствующей торговой роли. Это зависит от разновидности транзакции. индицировать отказ, послав Продавцу блок Cancel, содержащий компонент Status с StatusType = Offer, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.1) равным: ConsCancelled или Unspecified.Если продавец поличает сообщение, содержащее блок Cancel, тогда Покупатель вероятно направится в сетевой узел CancelNetLocn, специфицированный в элементе торговой роли компонента Organisation для Продавца.
9.1.2.3. Сообщение TPO
Сообщение используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), в это сообщение входит блок опций торгового протокола (смотри раздел 8.1), который описан ниже.
Блок TPO (TRADING PROTOCOL OPTIONS)
Блок опций торгового протокола (смотри раздел 8.1) должен содержать следующие торговые компоненты:
Один компонент протокольных опций, который определяет опции, относящиеся ко всей транзакции.Смотри раздел 7.1. Один компонент списка видов платежа (смотри раздел 7.7) для каждого платежа в транзакции, который содержит один или болеее видов платежа и протоколов, которые могут быть выбраны для каждой из проплат. Компоненты Organisation (смотри раздел 7.6), со следующими ролями:
| - Продавец, который сделал предложение | |
| - Покупатель, который осуществляет транзакцию | |
| - Кассир. "ID" компонента организщации-кассира содержится в атрибуте PhOrgRef компонента платежа (Payment). |
Компоненты Organisation со следующими ролями:
| - Агент доставки (DeliveryHandler), который осуществляет доставку товаров или услуг; | |
| - DelivTo т.e. лицо или организация, куда нужно выполнить доставку. |
Если за документальным обменом Offer следует обмен аутентификации, тогда сообщение TPO может также содержать:
блок состояния аутентификации (смотри раздел 8.6) и опционный блок Signature (состояния аутентификации). Для получения подробностей смотри раздел 9.1.1.4 (сообщение о состоянии аутентификации).
9.1.2.4. Сообщение IOTP выбора TPO
Сообщение выбора TPO используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя блок выбора TPO (смотри раздел 8.1), который описан ниже.
Блок выбора TPO (смотри раздел 8.2) содержит:
Один компонент выбора вида платежа (смотри раздел 7.8) для использования в последующем платежном обмене. Он содержит результаты выбора покупателем вида платежа, платежного протокола и вида валюты из списка компонента выбора вида платежа. 9.1.2.5. Сообщение отклик на предложение IOTP
Сообщение отклика Offer используется только в документальном обмене предложения, зависящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение состоит из:
блока отклика Offer (смотри раздел 8.1) aиnd опционного блока подписи (смотри раздел 8.16). Блок отклика предложения (блок отклика OFFER)
Блок отклика Offer (смотри раздел 8.3) содержит следующие компоненты:
один компонент Status (смотри раздел 7.16), который индицирует состояние отклика Offer. Атрибут ProcessState должен быть равен CompletedOk; один компонент Order (смотри раздел 7.5), который содержит детали о товарах и услугах, которые покупаются, или о финансовых операциях, которые имеют место; один или более компонентов (смотри раздел 7.9) для каждого платежа, которы надлежит произвести; нуль или один компонент Delivery (смотри раздел 7.13), содержащий детали доставки, которую надлежит осуществить, если транзакция предполагает доставку; нуль или более компонентов данных о торговой роли (смотри раздел 7.17), если это затребовано Продавцом. Блок подписи (отклик предложения)
Если блок состояния аутентификации снабжен цифровой подписью, тогда должен быть включен блок Signature, который содержит компонент подписи (смотри раздел 7.19) с элементами дайджестов для следующих XML-элементов:
Если отклик Offer снабжен цифровой подписью, тогда должен быть включен блок Signature, который содержит компонент подписи (смотри раздел 7.19) с элементами дайджестов для следующих XML-элементов:
блок ссылок транзакции (смотри раздел 3.3) для сообщения, которое содержит информацию, описывающую сообщение и IOTP-транзакцию; Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию; Следующие компоненты блока TPO:
| - компонент опций протокола и | |
| - компонент списка видов платежей; | |
| - компоненты всех организаций. |
| - компонент заказа; | |
| - все платежные компоненты; | |
| - компонент Delivery, если имеется; | |
| - любые компоненты данных о торговых ролях. |
Сообщение TPO и отклика Offer используется только в документальном обмене предложения, независящего от вида платежа. Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя:
блок опций торгового протокола (TPO) (смотри раздел 8.1); блок отклика Offer (смотри раздел 8.1) и опционный блок Signature (смотри раздел 8.16). Блок TPO (TRADING PROTOCOL OPTIONS)
Это тот же самый блок опций торгового протокола, что описан в IOTP-сообщении TPO (смотри раздел 9.1.2.3).
Блок отклика OFFER
Это тот же самый блок отклика Offer, что и в сообщении отклика Offer (смотри раздел 9.1.2.5).
Если до документального обмена Offer имел место обмен аутентификации, тогда сообщение TPO и отклика Offer может содержать (смотри раздел 8.6).
Блок подписи тот же самый блок Signature, что и в сообщении отклика Offer (смотри раздел 9.1.2.5), со следующими добавлениями:
если документальный обмен Offer является зависимым от вида платежа, тогда компонент Signature в блоке подписи дополнительно имеет элемент дайждеста для компонента выбора вида платежа, содержащегося в блоке выбора TPO; если перед документальным обменом Offer имела место аутентификация, тогда компонент Signature в блоке подписи дополнительно содержит элемент дайджеста для блока состояния аутентификации. 9.1.3. Обмен документами при платеже
Документальный обмен платежа является непосредственной реализацией последней части платежного обмена (смотри раздел 2.2.2) после того как вид платежа выбран покупателем. Платежный обмен состоит из:
Покупатель формирует платежный запрос, используя информацию из предыдущего IOTP-сообщения, и посылает его кассиру; Затем кассир и покупатель обмениваются платежными IOTP-сообщениями, куда инкапсулируются сообщения платежного протокола. Этот обмен происходит вплоть до завершения процедуры платежа и, наконец, Кассир посылает сообщение платежного отклика покупателю, где содержится платежная расписка. IOTP-сообщения, которые используются при платежном обмене показаны на Рисунок .21.
| 1. | Покупатель формирует блок платежного запроса, если необходимо, инкапсулирует в него сообщение платежного протокола, и посылает кассиру, снабжая при необходимости цифровой подписью |
| C a P | Запрос платежа. IotpMsg: блоки Trans Ref; подписи (опционный); платежного запроса |
| 2. | Кассир обрабатывает блок платежного запроса, проверяет подпись, если таковая имеется, и начинает обмен с покупателем сообщениями (вложенными в блок платежного обмена) согласно платежному протоколу |
| C « P | Платежный обмен. IotpMsg: блоки Trans Ref; Pay Exchange |
| 3. | Покупатель и кассир продолжают обмен платежными блоками, пока платеж не будет осуществлен и кассир не сформирует платежную расписку (которая опционно может быть снабщена цифровой подписью) и не пошлет ее покупателю. Эта операция завершает платежный обмен. |
| C ? P | Платежный отклик. IotpMsg: блоки Trans Ref; Signature (опционный); платежного отклика |
| 4. | Покупатель проверяет, все ли в порядке с платежным откликом. Опционно могут регистрироваться все операции IOTP. После этого покупатель может остановиться или послать очередное сообщение IOTP (снабдив его, если требуется, подписью) соответствующей торговой роли |
Обмен документами при доставке
Рисунок .22. Обмен документами при доставке
9.1.4.1. Принципы обработки сообщений
Получив сообщение-запрос доставки, агент доставки должен проверить авторизацию выполнения такой операции (смотри раздел 6). Далее он может:
сформировать и послать покупателю сообщение-отклик доставки или индицировать сбой путем посылки покупателю блока Cancel, содержащего компонент Status с StatusType = Delivery, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равными: DelivCanceled или Unspecified.Получив сообщение-отклик доставки, покупатель может считать, что транзакция завершена.
Если покупатель получает сообщение, содержащее блок Cancel, информация, содержащаяся в сообщении должна быть доведена до сведения покупателя и дальнейшая работа прервана.
9.1.4.2. Сообщение запроса доставки IOTP
Сообщение запроса доставки IOTP состоит из:
блок запроса доставки и опционный блок подписиБлок запроса доставки (смотри раздел 8.10) содержит:
следующие компоненты копируются из блока отклика Offer:| - компонент Status (смотри раздел 7.16) | |
| - компонент Order (смотри раздел 7.5) | |
| - компонент Organisation (смотри раздел 7.6) с ролями: Продавец, Агент доставки и DeliverTo | |
| -компонент Delivery (смотри раздел 7.13) |
| компонент Status (смотри раздел 7.16). |
Блок подписи (запрос доставки)
Если предыдущиц документальный обмен Offer содержит подпись отклика Offer илт платежный обмен содержит подпись платежного отклика, тогда тогда они должны быть скопированы в блок подписи.
9.1.4.3. Сообщение-отклик доставки
Сообщение-отклик доставки содержит блок отклика доставки и опционно блок подписи.
Блок отклика доставки содержит:
один компонент накладной (Delivery Note) (смотри раздел 7.15), который содержит инструкции по доставке товаров или услуг.Блок подписи (отклик доставки)
Блок подписи должен содержать один компонент подписи, который содержит элементы дайджеста, которые относятся к:
Id-компоненту транзакции (смотри раздел 3.3.1) сообщения, которое содержит подпись отклика Delivery; блок ссылок транзакции (смотри раздел 3.3) сообщения, которое содержит подпись отклика доставки; компонент данных покупателя, содержащийся в блоке запроса доставки покупателя; компоненты подписи, содержащиесчя в блоке запроса доставки (если имеется); компонент Status; компонент накладной (Delivery Note) 9.1.5. Обмен документами в процессе платежа и доставки
Документальный обмен платежа и доставки представляет собой комбинацию последней части торгового обмена платежа (смотри раздел 2.2.2) и обмена доставки (смотри раздел 2.2.3). Он состоит из:
Запрос покупателя начинается с формирования сообщения-запроса платежа, где используется информация предыдущего IOTP-сообщения транзакции. Далее этот запрос направляется кассиру; Кассир и покупатель обмениваются платежными сообщениями, в которые вкладываются сообщения платежного протокола, до тех пор пока транзакция не будет завершена; Кассир посылает покупателю в одном сообщении IOTP:
| - блок платежного отклика, содержащий платежную расписку, и | |
| - блок отклика доставки, содержащий подробности о доставленных товарах или услугах. |
| 1. | Покупатель генерирует блок платежного запроса, в который, если требуется, вкладывается сообщение платежного протокола, и посылает его кассиру, снабжая опционно цифровой подписью |
| C a P | Платежный запрос. IotpMsg: блоки Trans Ref; подписи; платежного запроса |
| 2. | Кассир обрабатывает блок платежного запроса, проверяет опционную подпись и начинает обмен с покупателем в рамках платежного протокола (вкладывая эти сообщения в блоки платежного обмена) |
| C « P | Платежный обмен. IotpMsg: блоки Trans Ref; платежного обмена |
| 3. | Покупатель и кассир обмениваются блоками платежного обмена до тех пор пока платежный протокол не завершит свою работу. Кассир формирует компонент платежной расписки, помещает его в блок платежного отклика, опционно формирует компонент подписи, который укладывается в блок Signature, затем использует информацию из блока отклика предложения, чтобы сформировать блок отклика отклика доставки и посылает его покупателю. |
| C ? P | Отклики платежа и доставки. IotpMsg: блоки Trans Ref; подписи; платежного отклика; отклика доставки |
| 4. | Покупатель проверяет блоки платежного отклика и отклика доставки. Опционно он может вести запись всех транзакций. Здесь покупатель может остановиться или сформировать очередное сообщение и послать его соотвествующе торговой роли. |
Обмен доставки
Рисунок .4. Обмен доставки
Обмен доставки использует следующие торговые компоненты, которыми обмениваются покупатель, продавец и агент доставки: Компонент Статус используется для указания агенту доставки, что предыдущий обмен (например, обмен предложения или платежный обмен) успешно завершился, а агентом доставки для индикации завершения обмена доставки. Компоненты организации содержат информацию об адресе доставки и ролях агента доставки и продавца:
| -Адрес доставки указывает, куда должны быть доставлен товар или услуги. | |
| -Роль агента доставки необходима для того, чтобы он мог проверить, что может выполнить данную операцию; | |
| -Роль продавца необходима для того, чтобы агент доставки мог определить, какой продавец затребовал доставку. |
2.2.4.
Аутентификационный обмен
Целью аутентификационного обмена является допущение одной организации, например, финансовому учреждению, иметь возможность проверить, что другая организация, например Покупатель, является тем, за кого себя выдает.
В аутентификационный обмен вовлечены:
Аутентификатор – организация, запрашивающая аутентификацию и
Аутентифицируемый – организация, которая должна быть аутентифицирована.>
Это проиллюстрировано на диаграмме ниже.
| 1. | Первая организация, например покупатель, осуществляет действие (например, нажимает на клавишу на HTML-странице), которое требует, чтобы организация была аутентифицирована. |
| 1 a 2 | Запрос аутентификации (за пределами действия IOTP) |
| 2. | Вторая организация генерирует данные вызова и список алгоритмов, которые могут быть использованы для аутентификации и/или запрос данных об организации, после чего посылает все это первой организации. |
| 1 ? 2 | Запрос аутентификации. Компоненты: запрос аутентификации, запрос информации о торговых ролях. |
| 3. | Первая организация опционно проверяет любую подпись, связанную с запросом аутентификации, после чего использует специфицированный алгоритм аутентификации, чтобы сформировать отклик аутентификации, который посылается второй организации вместе с запрошенной информацией об организации. |
| 1 a 2 | Отклик аутентификации. Компонент: отклик аутентификации, организации |
| 4. | Отклик аутентификации проверяется согласно данным вызова для того чтобы выяснить является ли первая организация той, за которую себя выдает, результат записанный в компонент статус посылается первой организации. |
| 1 ? 2 | Статус аутентификации. Компонент: Статус |
| 5. | Первая организация опционно проверяет результаты, записанные в cтатус, и все соответствующие подписи, после чего предпринимает некоторые действия или останавливает процедуру. |
Обмен платежными документами
Рисунок .21. Обмен платежными документами
9.1.3.1. Принципы обработки сообщений
Получив сообщение платежного запроса, кассир должен проверить, авторизован ли данный платеж (смотри раздел 6). Он может затем:
сформировать и послать сообщение платежного обмена покупателю, если этого требует платежный протокол или сформировать и послать сообщение платежного отклика, если протокольный платежный обмен завершен или индицировать сбой, послав покупателю блок Cancel, содержащий компонент Status с атрибутом StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равным: BrandNotSupp, CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument или Unspecified.Получив платежное ообщение, Покупатель может:
сформировать и послать платежное сообщение Кассиру или индицировать сбой, послав кассиру блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.2) равным: ConsCancelled или Unspecified.Получив платежное ообщение, кассир может:
сформировать и послать платежное сообщение покупателю, если этого требует платежный протокол или сформировать и послать сообщение платежного отклика, если протокольный платежный обмен завершен или индицировать сбой, послав Покупателю блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодами CompletionCode (смотри раздел 7.16.2) равными: PaymtCancelled или Unspecified.Получив платежное ообщение-отклик, Покупатель может:
сформировать и послать следующее сообщение транзакции соответствующей торговой роли. Это зависит от разновидности транзакции, остановиться, так как транзакция завершена или индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.1) равным: ConsCancelled или Unspecified.Если покупатель получает сообщение, содержащее блок Cancel, тогда информация из сообщения IOTP должна быть доведена до сведения покупателя и не должны предприниматься никакие другие действия.
Если кассир получает сообщение, содержащее блок Cancel, тогда покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для кассира, здесь он сможет предпринять некоторые дальнейшие действия.
Если продавец получает сообщение, содержащее блок Cancel, тогда покупатель должен завершить операцию платежа. В этом случае покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для продавца, здесь он сможет предпринять некоторые дальнейшие действия.
9.1.3.2. Сообщение платежного запроса
Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение может содержать:
блок платежного запроса и опционный блок подписи Блок платежного запроса (смотри раздел 8.7) состоит из:
следующих компонентов копируемых из блока отклика Offer, полученного в ходе предыдущего документального обмена предложения:
| - компонент Status | |
| - компонент Payment для выполняемого платежа |
| - компоненты Organisation с ролями Продавец и Кассир, которые были пересланы в блоке платежного запроса; | |
| - компонент списка видов платежа, т.e. список видов платежа, указанный в атрибуте BrandListRef компонента Payment; |
| - скопирован из блока выбора вида платежа, если платеж предшествовал документальному обмену предложения, зависящего от вида платежа (смотри раздел 9.1.2.1) или | |
| - сформирован Покупателем. В этом случае он содержит код вида платежа, платежный протокол и вид валюты, выбранные из списка видов платежа (смотри раздел 9.1.2.2). |
если в блоке отклика Offer имеется более одного компонента Payment, тогда вторым платежем являет тот, что записан в блоке отклика Offer и который содержит атрибут StartAfter (смотри раздел 7.9), указывающий на компонент Payment предыдущего платежа; Кассир, который должен быть сюда включен, идентифицируется компонентом выбора платежа (смотри раздел 7.8). Объясненеи того как идентифицируется Кассир смотри в разделе 6.3.1; компонент списка видов платежей определяется атрибутом BrandListRef компонента o Payment; компонент выбора вида платежа берется из блока отклика Offer, где имеется атрибут BrandListRef (смотри раздел 3.5), который идентифицирует компонент списка видов платежей. Блок подписи (запрос платежа)
Если предшествующий документальный обмен предложения содержал цифровую подпись(смотри раздел 9.1.2.5), или подпись была включена в предыдущий платежный отклик (смотри раздел 9.1.3.4), тогда они должны обе быть скопированы в блок подписи сообщения платежного запроса.
9.1.3.3. Сообщение платежного обмена IOTP
Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя блок платежного обмена.
Блок платежного обмена (смотри раздел 8.8) включает в себя:
один компонент платежной схемы (смотри раздел 7.10), который содержит специфические данные метода платежа. Подробности по платежному методу смотри в приложении. 9.1.3.4. Платежное сообщение отклика
Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя:
платежный блок отклика опционный блок подписи Платежный блок отклика (смотри раздел 8.9) включает в себя:
один компонент платежной расписки (смотри раздел 7.11), которая содержит специфические данные для платежной схемы, которые позволяют, если нужно, проконтролировать платеж; один компонент платежной схемы (смотри раздел 7.10), который, если требуется, содержит специфические данные метода платежа. Подробности смотри в приложении; опционный компонент накладной (Payment Note) (смотри раздел 7.12); нуль или более компонентов данных о торговой роли (смотри раздел 7.17). Блок подписи (платежный отклик)
Если предоставлена подписанная платежная расписка, что индицируется атрибутом SignedPayReceipt= True компонента Payment, тогда блок Signature должен содержать компонент Signature, который содержит элементы дайджеста следующих видов:
блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит первый вариант блока платежного отклика, Id-компонент транзакции (смотри раздел 3.3.1) в блоке ссылок транзакции, который однозначно идентифицирует транзакцию, компонент платежной расписки из блока платежного отклика, компонент накладной (Payment Note) из блока платежного отклика, другие компоненты, на которые ссылается атрибут PayReceiptNameRefs (если имеется) компонента платежной расписки, компонент Status из блока платежного отклика, любой компонент данных о торговой роли в блоке платежного отклика и все компоненты Signature, содержащиеся в блоке платежного запроса (если имеются). 9.1.4. Обмен документами при доставке
Документальный обмен доставки является непосредственной реализацией торгового обмена доставки (смотри раздел 2.2.3). Он состоит из следующих шагов:
Покупатель запрашивает доставку путем формирования сообщения запроса доставки. При этом используется информация предыдущего IOTP-сообщения транзакции и затем посылает его Агенту доставки; Агент доставки посылает сообщение отклика доставки покупателю. Это сообщение содержит детали отклика агента на запрос и опционно цифровую подпись. Схема обмена сообщениями представлена на Рисунок .22.
| 1. | Покупатель генерирует блок запроса доставки и посылает его агенту доставки, снабдив, если требуется, цифровой подписью |
| C a D | Запрос доставки. IotpMsg: блоки Trans Ref; подписи; запроса доставки |
| 2. | Агент доставки проверяет компоненты Status и Order запроса доставки и опционно подпись, создает блок отклика доставки, посылает его покупателю. |
| C ? D | Отклик доставки. IotpMsg: блоки Trans Ref; подписи; отклика доставки |
| 3. | Покупатель проверяет блок отклика доставки и опционный блок подпии. Опционно производит запись о транзакции на будущее. |
Обработка ошибок IOTP
4. Обработка ошибок IOTP
IOTP создан как протокол запросов/откликов, где каждое сообщение состоит из нескольких торговых блоков, которые содержат некоторое. Существует несколько взаимосвязанных соображений при обработке ошибок, ретрансмиссий, дубликатов и тому подобное. Эти факторы приводят к тому, что IOTP вынужден обрабатывать поток сообщений не просто как последовательность запросов и откликов. Кроме того может встретится большое разнообразие ошибок в сообщениях, на транспортном уровне или в торговых блоках или компонентах. Датее будет рассмотрено, как IOTP обрабатывает ошибки, повторные попытки и дубликаты сообщений.
Могут произойти различные ошибки:
| - | "технические ошибки", которые не зависят от цели сообщения IOTP, |
| - | "деловые ошибки", которые указывают, что имеется специфическая проблема для процесса (напр., для платежа или доставки), который исполняется. |
Глубина ошибки показывает, где произошла ошибка (при транспортировке, при составлении сообщения или на уровне блока/компонента)
4.1. Технические ошибки
К техническим ошибкам относятся ошибки, которые не зависят от значения сообщения. Это означает, что они могут влиять на любую попытку передачи. Обычно они обрабатываются стандартным образом с ограниченным числом опций для пользователя. Такие ошибки могут быть:
o повторная попытка передачи;
o аннулирование транзакции.
Когда связь работает достаточно хорошо, техническая ошибка индицируется компонентом Error (смотри раздел 7.21) в блоке Error (смотри раздел 8.17), посланным партнером, который детектировал ошибку в сообщении IOTP, партнеру, пославшему ошибочное сообщение.
Если связь слишком плохая, сообщение, которое было послано, может не достичь адресата. В этом случае может произойти таймаут.
Коды ошибок, соответствующие техническим ошибкам записываются в компоненте Error, где перечисляются различные технические ошибки, которые могут случиться.
4.2. Рабочие ошибки
Рабочие ошибки могут случиться, когда IOTP-сообщения "технически" вполне корректны.
Они связаны с определенным процессом, например, предложение, платеж, доставка или аутентификация, где каждый процесс имеет разный набор возможных рабочих ошибок.
Например, "Недостаточно средств" является сообщением об ошибке при платеже, но не имеет никакого значения для доставки, в то время как "Back ordered" возможное сообщение об ошибке доставки, но не имеет смысла для платежа. Рабочие ошибки индицируются компонентом Status (смотри раздел 7.16) "блока отклика" соответствующего типа, например, блока Payment Response или Delivery Response. Это допускает любой дополнительный отклик, связанный с информацией, которая необходима для пояснения возникшей ошибки.
Рабочие ошибки должны обычно представляться пользователю так, чтобы он мог решить, что делать дальше. Например, если ошибка связана с недостаточностью платежных средств в предложении, независящим от типа платежа (смотри раздел 9.1.2.2), пользователь может пожелать выбрать другой счет того же типа или другой тип платежа или даже другую платежную систему. Иными словами, если реализация, базирующаяся на IOTP, допускает это и пользователь может перевести дополнительные средства на счет и совершить еще одну попытку.
4.3. Глубина ошибки
Три уровня, на которых могут произойти ошибки в IOTP, включают транспортный уровень, уровень сообщения и уровень блока.
4.3.1. Транспортный уровень
Этот уровень ошибки указывает фундаментальную проблему в транспортном механизме, через который осуществляется передача в IOTP.
Все ошибки транспортного уровня являются техническими и индицируются явно на транспортном уровне, как "No route to destination" из TCP/IP или через таймаут, когда не получено отклика на посланный запрос.
Единственно разумным автоматическим действием, когда сталкиваешся с ошибками транспортного уровня, является попытка повторной передачи, а после нескольких попыток информирование пользователя об этом.
Неявная индикация ошибки, которая может быть получена, является зависимой от транспортной среды и для принятия решения относительно конкретных действий следует обращаться к документации транспортного приложения IOTP.
Таймауты здесь являются функцией как транспорта так и платежной системы, если в запрос инкапсулирована платежная информация. Для выяснения параметров таймаутов и повторных передач рекомендуется обращаться к документации по транспортной и платежной системам. Часто нет способа непосредственно проинформировать партнера об ошибках транспортного уровня, при таких обстоятельствах такие события должны регистрироваться и, если автоматическое восстановление системы не сработало, а в процесс вовлечен человек-пользователь, его следует проинформировать об инциденте.
4.3.2. Уровень сообщения
Этот уровень ошибки указывает на фундаментальную техническую проблему с IOTP-сообщением в целом. Например, XML документ некорректно оформлен, сообщение имеет слишком большую длину для получателя, или обнаружена ошибка в блоке ссылок транзакции (смотри раздел 3.3).
Все ошибки уровня сообщений являются техническтими ошибками и индицируются компонентами Error (смотри раздел 7.21), послаными партером. Компонент Error включает в себя атрибут Severity (степень угрозы), который указывает, является ли ошибка предупреждениеим и может быть проигнорирована, TransientError и что повторная попытка может разрешить проблему или HardError, что говорит о срыве транзакции. Технические ошибки (смотри раздел 7.21.2; Коды ошибок), которые являются ошибками уровня сообщения, включают:
XML not well formed. Документ имеет не верный формат XML (смотри [XML])
XML not valid. Документ не вполне отвечает требованиям XML (смотри [XML])
Технические ошибки блочного уровня (смотри раздел 4.3.3) в блоке ссылок транзакции (смотри раздел 3.3) и блоке подписи. Следует проверить только эти блоки, если с XML все в порядке.
Заметим, что проверки блока подписи включают проверку, где это возможно, того, что каждый из компонентов подпися вычислен правильно. Если подпись вычислена неправильно, тогда данные, которые покрываются подписью не будут признаны истинными. Процедура проверки подписи описана в разделе 6.2.
4.3.3. Уровень блоков
Ошибки блочного уровня указывают на проблему с блоком или одним из его компонентов в сообщении IOTP (помимо блоков ссылок транзакции или подписи). Сообщение передано корректно, структура всего сообщения, включая блоки ссылок транзакции и подписи, вполне разумна, но имеется ошибка, связанная с каким-то другим блоком. Ошибки блочного уровня могут быть:
техническими ошибками
рабочими ошибками
Технические ошибки далее делятся на:
Связанные с проверкой атрибутов блочного уровня и элементов.
Связанные с проверкой согласованности блоков и компонентов.
Переходные технические ошибки.
Если случислась техническая ошибка, связанная с блоком или компонентом, формируется компонент Error для посылки отправителю некорректного сообщения.
4.3.3.1. Проверки атрибутов блочного уровня и элементов
Проверки элемента и атрибута блочного уровня производятся только в пределах одного и того же блока. Проверки, которые включают в себя перекрестные сверки с другими блоками, относятся к проверкам согласованности блоков и компонент.
Проверки элемента и атрибута блочного уровня включают в себя:
проверку того, что значение каждого атрибута в каждом элементе блока согласуется с правилами спецификации IOTP;
проверку того, что содержимое каждого элемента согласуется с правилами спецификации IOTP;
если предыдущие проверки прошли успешно, тогда осуществляется контроль согласованности значений атрибутов и содержимого элементов со значениями атрибутов и содержимым элементов любых других компонентов в пределах блока.
4.3.3.2. Проверки согласованности компонентов и блоков
Проверки согласованности компонентов и блоков состоит из:
проверки того, что комбинации блоков и/или компонентов, присутствующих в сообщении IOTP, согласуются с правилами спецификации;
проверки взаимосогласованности атрибутов и содержимого элементов в блоках сообщения IOTP;
проверки взаимосогласованности атрибутов и элементов в блоках данного сообщения IOTP и блоков, полученных ранее IOTP-сообщений в рамках одной и той же транзакции.
Если блок проходит проверку атрибутов и элементов блочного уровня и контроль согласованности блоков и компонентов, тогда он обрабатывается IOTP-приложением или какой-то оконечной системой, такой как платежный сервер.
4.3.3.3. Переходные технические ошибки
Во время обработки блока могут произойти временные отказы, которые в принципе могут быть преодолены позднее повторной передачей исходного сообщения. В этом случае партнер информируется о переходной ошибке путем посылки компонента Error (смотри раздел 7.21) с атрибутом Severity равным TransientError и атрибутом MinRetrySecs равным некоторому значению, удобному для используемого транспортного механизма и/или платежного протокола (смотри соответствующие приложения транспортного и платежного протокола). Заметим, что переходные технические ошибки могут генерироваться любыми торговыми агентами, вовлеченными в транзакцию.
4.3.3.4. Рабочие ошибки блочного уровня
Если в процессе платежа или доставки происходит рабочая ошибка, тогда присылается соответствующий тип блока отклика, содержащий компонент Status (смотри раздел 7.16) с атрибутом ProcessState равным Failed и CompletionCode, указывающим на природу проблемы.
Некоторые рабочие ошибки могут быть переходными, при таких обстоятельствах Покупатель может справиться с ситуацией самостоятельно и успешно завершить транзакцию каким-то способом. Например, если на кредитной карточке покупателя недостаточно денег, он может воспользоваться для покупки другой кредитной карточкой.
Преодоление переходных рабочих ошибок зависит от CompletionCode. Для понимания имеющихся возможностей смотри определение компонента Status. Заметим, что для рабочих ошибок не формируется компонент или блок Error.
4.4. Idempotency, последовательность обработки и поток сообщений
IOTP-сообщения представляют в действительности комбинацию блоков и компонентов, как это описано в 3.1.1 (Структура сообщений IOTP). В будущем при расширении IOTP разнообразие таких комбинаций еще более расширится. Важно, что многократные приемы/передачи одного и того же запроса изменения состояния имеют тот же результат, как и однократная передача/прием этого запроса. Это называется идемпотентностью. Например, покупатель, оплачивая заказ, желает оплатить его только раз.
Большинство сетевых транспортных механизмов имеют определенную вероятность доставки одного сообщения несколько раз или не доставить ни разу, что потребует позднее повторной передачи. С другой стороны, запрос состояния можно повторять и при этом каждый раз должно обрабатываться вновь полученное значение. Правильная реализация IOTP может моделироваться по разному различными процессами.
4.5. Последовательность обработки для роли сервера
"Роли сервера" – это любые торговые роли, несовпадающие с ролью Покупателя. Они являются "ролями сервера", так как они обычно получают запросы, которые они должны обработать и посылать на них отклики. Однако Роли сервера могут также инициировать транзакции. Более конкретно роли сервера должны быть способны:
| o | Инициировать транзакцию (смотри раздел 4.5.1). Это могут быть: | |
| - | платеж, связанный с транзакцией; | |
|   | - | инфраструктурные транзакции. |
| o | Принять и обработать сообщение полученное от другой торговой роли (смотри раздел 4.5.2). Сюда относится: | |
| - | идентификация, если сообщение принадлежит транзакции, которая была запущена ранее; | |
| - | обработка сообщений-дубликатов; | |
| - | генерация переходных ошибок, если сервер, который обрабатывает входные сообщения перегружен; | |
| - | обработка сообщения, если оно лишено ошибок и авторизовано, и при благоприятном исходе, послать отклик отправителю сообщения. | |
| o | Аннулировать текущую транзакцию, если поступил такой запрос (смотри раздел 4.5.3) | |
| o | Повторно передать сообщение, если ожидается отклик, который не поступил за определенный период времени (смотри раздел 4.5.4). |
Роли сервера могут инициировать большое число различных транзакций. В чатности:
| o | Транзакцию информационного запроса (смотри раздел 9.2.1); | |
| o | Транзакцию Ping (смотри раздел 9.2.2); | |
| o | Транзакцию аутентификации (смотри раздел 9.1.6); | |
| o | Транзакцию, сопряженную с платежем, такую как: | |
| - | Депозит (смотри раздел 9.1.7); | |
| - | Покупка (смотри раздел 9.1.8); | |
| - | Возврат денег (смотри раздел 9.1.9); | |
| - | Отзыв сделки (смотри раздел 9.1.10); | |
| - | Обмен ценностями (смотри раздел 9.1.11). |
Обработка входных сообщений
Обработка входных сообщений включает в себя:
| o | проверку структуры и идентификацию сообщения; |
| o | выявление и обработку сообщений-дубликатов; |
| o | обработку недублированных, оригинальных сообщений, которая включает в себя: |
| - | выявление ошибок, и, если они не обнаружены, |
| - | обработку сообщений и, если требуется, выработку откликов. |
Крайне важно проверить, что сообщение имее корректную XML-форму и идентификатор транзакции (IotpTransID-атрибут компонента TransId) в сообщении IOTP может быть распознан, так как IotpTransId будет нужен при формировании отклика.
Если входное сообщение сформировано некорректно, тогда генерируется компонент Error с атрибутом Severity равным HardError и код ошибки XmlNotWellFrmd.
Если входное сообщение сформировано правильно, но IotpTransId не может быть идентифицировано, генерируется компонент Error с :
| o | атрибутом Severity = HardError и кодом ошибки (ErrorCode) = AttMissing, |
| o | содержимым PackagedContent, включающим в себя "IotpTransId" потерянного атрибута. |
4.5.2.2. Выявление и обработка дублированных сообщений
Если входное сообщение может быть идентифицировано, как корректное, то проверяется, не получалось ли раньше точно такое же сообщение. Под идентичностью здесь подразумевается, что все блоки, компонентя, элементы, значения атрибутов и элементы содержимого тождественны.
Рекомендуемым способом проверки идентичности сообщений является проверка равентства их [DOM-HASH].
Если получено сообщение, прежде чем его исследовать, нужно проверить, завершилась ли обработка предыдущего.
Если обработка не завершилась, генерируется компонент Error с атрибутом Severity = TransientError и кодом ошибки = MsgBeingProc, чтобы указать, что сообщение обрабатывается и послать его обратно отправителю, с предложением повторной присылки поздее.
4.5.2.3. Обработка недублированных сообщений
Если установлено, что сообщение не является дубликатом ранее полученного, тогда оно обрабатывается. Процедура обработки включает в себя:
| o | проверку того, что сервер готов для обработки, если это не так, генерируется переходная ошибка; |
| o | проверку, не находится ли транзакция в режиме ошибки или неаннулирована; |
| o | контроль корректности входного сообщения, который предусматривает: |
| - проверку глубины ошибки сообщения; | |
| - проверку ошибок блочного уровня; | |
| - проверку любых инкапсулированных данных | |
| o | проверку ошибок в последовательности полученных блоков; |
| o | генерацию компонентов ошибки для любых обнаруженных ошибок; |
| o | если никаких серьезных или переходных ошибок не выявлено, производится обработка сообщения и, если требуется, генерация отклика отправителю входного сообщения. |
Процесс обработки входного сообщения должен проверить, свободна ли остальная система. Если сервер слишком занят, он должен выдать компонент Error с атрибутом Severity равным Transient Error и кодом ошибки равным SystemBusy, после чего вернуть отправителю входное сообщение, запрашивая тем самым повторную присылку этого сообщения спустя некоторое время.
Некоторые серверы могут оказаться перегруженными из-за неожиданного всплеска загрузки. Данный подход позволяет преодолевать ситуации с кратковременными пиковыми нагрузками, запрашивая отправителя переслать сообщение несколько позже.
Проверка того, что транзакция не зафиксировала ошибку и не оказалась аннулированной.
Предполагается следующий контроль:
| o | предыдущие посланные или полученные сообщения не содержат серьезных (Hard) ошибок; |
| o | транзакция не была анулирована покупателем или торговой ролью сервера. |
Если с транзакцией все в порядке, производится поиск ошибок на уровне сообщения. Это включает в себя:
проверку формат XML; проверку того, что все элементы, атрибуты и содержимое блока ссылок транзакции не содержат ошибок и соответствуют спецификации IOTP; проверку цифровой подписи, которая в свою очередь предполагает:
| - проверку того, что корректно вычислена электронная подпись; | |
| - проверку того, что значение дайджеста вычислено правильно. |
| о | проверку в пределах каждого блока (помимо блока ссылок транзакции) того что: |
| - атрибуты, элементы и содержимое элементов корректно; | |
| - значения атрибутов, элементы и содержимого элементов не противоречат друг другу в пределах блока. | |
| о | проверку того, что комбинации блоков корректны |
| o | проверку того, что значения атрибутов, элементы и содержимое элементов взаимосогласованы на межблочном уровне в пределах входного сообщения с блоками, полученными или отправленными ранее. Это включает проверку уместности данного блока для этого типа транзакции. |
4.5.2.4. Проверка ошибок в последовательности блоков
Далее при объяснении поиска ошибок в последовательностях блоков выражение типа "относится к транзакции IOTP" следует интерпретировать как "содержится в сообщении IOTP, где TransRef Block включает в себя IotpTransId, который указывает на данную танзакцию". Так, например, "Если ошибка или аннулированный блок относится к транзакции IOTP, которая не распознана, тогда..." следует интерпретировать как "Если ошибка или аннулированный блок содержатся в сообщении IOTP, TransRefBlock включает в себя IotpTransId, который относится к транзакции IOTP, которая не распознана, тогда...”.
Ошибки в последовательности прихода блоков зависят от блока. Блоки, где требуется проверка последовательности:
Error и Cancel блоки. Если Error или Cancel блок относится к транзакции IOTP, которая не распознана, тогда это серьезная (Hard) ошибка. Чтобы избежать зацикливания, не следует посылать оповещения об ошибке, если получен Error или Cancel блок транзакции IOTP. Блоки отклика и информационного запроса. Если блоки отклика и информационного запроса относятся к транзакции IOTP, которая не распознана, это серьезная (Hard) ошибка. Блок запроса аутентификации. Если блок запроса аутентификации относятся к транзакции IOTP, которая распознана, это серьезная (Hard) ошибка. Блок отклика аутентификации проверяется следующим образом:
| - Если блок отклика аутентификации не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае. | |
| - Если блок отклика аутентификации не относится к аутентификационному запросу, который был ранее послан, то это серьезная (Hard) ошибка, в противном случае. | |
| - Если блок отклика аутентификации получен в рамках IOTP-транзакции, до того как аутентификация успешно завершилась, то это серьезная (Hard) ошибка. | |
| о | Блок состояния аутентификации проверяется следующим образом: |
| - если блок состояния аутентификации не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае, | |
| - если блок состояния аутентификации не относится к аутентификационному отклику, который был перед эти послан, тогда это серьезная (Hard) ошибка, в противном случае, | |
| - если блок состояния аутентификации получен для той же самой транзакции раньне, то это предупреждение (а не ошибка). | |
| o | Блок выбора TPO (только для продавца) прооверяется следующим образом: |
| - если блок выбора TPO не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае, | |
| - если блок выбора TPO не относится к транзакции IOTP, где блок TPO и отклик предложения (в одном сообщении) были посланы ранее, то это серьезная (Hard) ошибка, в противном случае, | |
| - если блок выбора TPO относится к транзакции IOTP, где только блок TPO (т.e. без отклика на предложение) был послан ранее, то это серьезная (Hard) ошибка, в противном случае, | |
| - если блок выбора TPO для того же блока TPO получен ранее, то это серьезная (Hard) ошибка. | |
| o | Блок запроса платежа (только для кассира) проверяется следующим способом: |
| - если блок запроса платежа относится к транзакции IOTP, которая не распознана, тогда все в порядке, в противном случае | |
| - если блок запроса платежа относится к транзакции IOTP, которая не связана с платежом, то это серьезная (Hard) ошибка, в противном случае | |
| - если был предшествующий платеж, который не прошел с кодом завершения недопускющим восстановление, то это серьезная (Hard) ошибка, в противном случае | |
| - если предыдущий платеж еще в работе, то это серьезная (Hard) ошибка. | |
| o | Блок платежного обмена (только для кассира) проверяется следжующим образом: |
| - если блок платежного обмена не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае | |
| - если платежный обмен не относится к транзакции IOTP, где такой обмен уже был, то это серьезная ошибка (Hard). | |
| o | Запрос доставки (только для агентов доставки). Если блок запроса доставки относится к транзакции IOTP, которая распознана сервероим, то это серьезная ошибка. |
Если сгенерированы какие- либо компоненты Error, то они должны быть собраны в блок Error для посылки отправителю входного сообщения. Заметим, что блоки Error следует отсылать назад отправителю сообщения и ErrorLogNetLocn для торговой роли отправителя, если это специфицировано.
Описанная выше проверка последовательности аутентификационных откликов и платежных запросов поддерживает повторение запросов Покупателя, если предыдущая операция не прошла, например:
o потому что не получен корректный отклик (напр., пароль) на аутентификацию или
o не удалось произвести оплату, так как нехватает денег на кредитной карточке.
Обработка входного сообщения, лишенного ошибок
Если входное сообщение прошло предыдущие проверки, то оно должно быть обработано и послан, если требуется, отклик. Заметим, что:
Информационные запросы на транзакции Ping следует игнорировать; Если входное сообщение содержит блок Error с переходной ошибкой, следует подождать необходимое время и затем повторно послать предыдущее сообщение, если не было получено отклика на сообщение, посланное ранее; Если входное сообщение содержит компонент Error с HardError или блок Cancel, тогда последующая обработка транзакции должна быть остановлена. Это включает в себя блокировку отправки любых текущих сообщений или посылку откликов на любые новые приходящие недублированные сообщения; Обработка инкапсулированных сообщений (напр., сообщения платежного протокола) может вызвать дополнительные переходные ошибки; Цифровая подпись может быть корректно сформирована лишь в случае, если сгенерированы все блоки и компоненты и известно, какие элементы в сообщении должны быть подписаны. Если выходное сообщение сгенерировано, оно должно быть запомнено, так чтобы иметь возможность, если потребуется, послать его повторно. Заметим, что выходные сообщения, которые содержат переходные ошибки, не запоминаются, так что они формируются заново, при их повторной посылке.
4.5.3. Аннулирование транзакции
Этот процесс используется, чтобы аннулировать транзакцию, Этот процесс служит для аннултрования транзакции работающей на сервере IOTP.
Он инициируется некоторым другим процессом, как результат внешнего запроса отдругой системы или сервера, который играет ту же торговую роль. Обработка такого запроса требует:
если IotpTransId транзакции, которую надо аннулировать, не распознан, или она завершена, то запрос не проходит, в противном случае, если IotpTransId относится к транзакции Ping, то запрос не проходит, в противном случае, определить, какой локументальный обмен нужно прервать, сформировать блок Cancel и послать его партнеру. Аннулирование транзакции на сервере IOTP обычно возникает по деловым причинам. Например продавец может попытаться безуспешно аутентифицироваться несколько раз, после чего решает аннулировать транзакцию. Следовательно процесс, который решаетпроизвести такое действие, должен послать сообщение из процесса/сервера с инструкцией о том, какую транзакцию следует аннулировать.
4.5.4. Повторная посылка сообщений
Сервер должен периодически проводить проверки, нет ли транзакций, ожидающих сообщения-отклики и неполчивших их своевременно. Такая задержка может быть связана со следующими факторами:
| о | из-за используемого танспортного механизма; |
| o | из-за времени, необходимого для обработки инкапсулированных сообщений (напр., платежных) и |
| o | зависит оттого, нужен или нет ввод со стороны человека. |
| o | TimedOutRcvr, если транзакция может быть восстановлена позднее, или |
| o | TimedOutNoRcvr, если транзакция невосстановима. |
"Роль клиента" в IOTP является торговой ролью Покупателя.
Компания или организация, которая является Продавцом может, например, взять на себя роль покупателя, делая покупки или или выполняя отзыв электронного платежа.
В частности Покупатель должен быть способен:
| o | Инициировать транзакции (смотри раздел 4.6.1). Среди них могут быть: |
| - платеж, связанный с транзакцией | |
| - инфраструктурные транзакции. | |
| o | Воспринять и обработать сообщение, полученное от другой торговой роли (смотри раздел 4.6.2). Сюда входит: |
| - идентификация того, принадлежит ли сообщение транзакции, запущенной ранее; | |
| - обработка дублированных сообщений; | |
| - генерирование переходных ошибок, если сервер, который обрабатывет входное сообщение перегружен; | |
| - обработка сообщения, если оно не имеет ошибок и, если необходимо, посылка отклика партнеру по результатам обработки. | |
| o | Аннулировать текущую транзакцию, если поступил соответствующий запрос, например от пользователя (смотри раздел 4.6.3). |
| o | Повторно передать сообщение, если ожидаемый отклик не пришел своевременно (смотри раздел 4.6.4). |
Роль Покупателя может инициировать большое число различных транзакций. В частности:
| o | Процедуру запроса (смотри раздел 9.2.1) |
| o | Транзакцию Ping (смотри раздел 9.2.2) |
| o | Процедуру аутентификации (смотри раздел 9.1.6) |
Обработка входных сообщений для роли покупателя происхотит также как и для IOTP-сервера (смотри раздел 4.5.2) за исключением проверки ошибок в последовательности блоков (для IOTP-сервера смотри раздел 4.5.2.4).
Описание обработки входных сообщений для сервера IOTP включает соображения многопроцессности и многозадачности. Для роли покупателя – в частности при работе на изолированной рабочей системе использование много процессности оставляется на усмотрение разработчика.
4.6.2.1. Поиск ошибки в последовательности блоков
Последовательность обработки блоков для роли покупателя та же, что и для IOTP-сервера (смотри раздел 4.5.2.4) за исключением того, что роль покупателя подставляется вместо роли сервера IOTP:
| о | Блоки Error и Cancel, |
| o | Блоки отклика и информационного запроса, |
| o | Блоки запросов аутентификации, отклика и состояния. |
Блоки, где важна последовательность проверки перечислены ниже:
| o | Блок TPO проверяется следующим образом: |
| - если входное сообщение содержит блок запроса аутентификации и блок отклика на предложение, то это серьезная (Hard) ошибка, в противном случае, | |
| - если входное сообщение содержит блок запроса аутентификации и статуса аутентификации, то это серьезная (Hard) ошибка, в противном случае, | |
| - если входное сообщение содержит блок запроса аутентификации и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае, | |
| - если входное сообщение содержит блок состояния аутентификации и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае, | |
| - если входное сообщение содержит блок состояния аутентификации, а блок состояния аутентификации послан до сообщения-отклика аутентификации, то это серьезная (Hard) ошибка, | |
| - если входное сообщение содержит блок отклика на предложение и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае, | |
| o | Блок отклика предложения проверяется следующим образом: |
| - если блок отклика на предложение является частью брэнд-независимого обмена предложения (смотри раздел 9.1.2.2), тогда никакой проверки последовательности не нужно, так как это первое сообщение, в противном случае, | |
| - если блок отклика на предложение не является частью транзакции IOTP, которая распознана покупателем, то это серьезная (Hard) ошибка, в противном случае, | |
| - если блок отклика на предложение не относится к транзакции, где в последнем сообщении послан блок выбора TPO, то это серьезная (Hard) ошибка. | |
| o | Блок платежного обмена проверяется следующим образом: |
| - если блок платежного обмена не относится к транзакции IOTP, которая распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае, | |
| - если платежный обмен не относится к транзакции IOTP, где только что послан блок платежного запроса или платежного обмена, то это серьезная (Hard) ошибка. | |
| o | Блок платежного отклика проверяется следующим образом: |
| - если блок платежного отклика не относится к транзакции IOTP, которая распознана системой Покупателя, то это серьезная (Hard) ошибка, в противном случае, | |
| - если блок платежного отклика не относится к транзакции IOTP, где только что послан блок платежного обмена или блок платежного запроса, то это серьезная (Hard) ошибка. | |
| o | Блок отклика доставки проверяется следующим образом: |
| - если блок отклика доставки не относится к транзакции IOTP, которая распознана системой Покупателя, то это серьезная (Hard) ошибка, в противном случае, | |
| - если блок отклика доставки не относится к транзакции IOTP, где только что послан блок запроса платежа или платежного обмена, то это серьезная (Hard) ошибка. |
Этот процесс аннулирует текущую транзакцию системы покупателя в результате внешнего запроса пользователя или другой системы или сервера, исполняющего роль покупателя. Обработка запроса делается также как для сервера IOTP (смотри раздел 4.5.3).
4.6.4. Повторная передача сообщений
Ретрансмиссия сообщений осуществляется так же, как и в случае сервера IOTP (смотри раздел 4.5.4).
Определения типов данных протокола IOTP
13. Определения типов данных протокола IOTP
Этот раздел содержит XML DTD для IOTP.
<!--
******************************************************
* *
* INTERNET OPEN TRADING PROTOCOL VERSION 1.0 DTD *
* Имя файла: ietf.org/rfc/rfc2801.dtd *
* *
* Отличие от версии 07 (iotp-v1.0-protocol-07.dtd) *
* - никаких изменений *
* *
* Copyright Internet Engineering Task Force 1998-2000*
* *
******************************************************
******************************
* Определение сообщения IOTP *
******************************
-->
<!ELEMENT IotpMessage ( TransRefBlk, IotpSignatures?, ErrorBlk?,
( AuthReqBlk | AuthRespBlk | AuthStatusBlk | CancelBlk | DeliveryReqBlk |
DeliveryRespBlk | InquiryReqBlk | InquiryRespBlk | OfferRespBlk | PayExchBlk |
PayReqBlk | PayRespBlk | PingReqBlk | PingRespBlk | TpoBlk | TpoSelectionBlk
)* ) >
<!ATTLIST IotpMessage xmlns CDATA 'iotp:ietf.org/iotp-v1.0' >
<!--
***************************************
* Определение блока ссылок транзакции *
*************************************** -->
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*)>
<!ATTLIST TransRefBlk ID ID #REQUIRED>
<!ELEMENT TransId EMPTY>
<!ATTLIST TransId ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0'IotpTransId CDATA #REQUIRED
IotpTransType CDATA #REQUIREDTransTimeStamp CDATA #REQUIRED>
<!ELEMENT MsgId EMPTY>
<!ATTLIST MsgId ID ID #REQUIRED
| RespIotpMsg NMTOKEN #IMPLIED | xml:lang NMTOKEN #REQUIRED |
| LangPrefList NMTOKENS #IMPLIED | CharSetPrefList NMTOKENS #IMPLIED |
SenderTradingRoleRef NMTOKEN #IMPLIED
| SoftwareId CDATA #REQUIRED | TimeStamp CDATA #IMPLIED> |
<!ELEMENT RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo ID ID #REQUIRED
| xml:lang NMTOKEN #REQUIRED | RelationshipType NMTOKEN #REQUIRED |
| Relation CDATA #REQUIRED | RelnKeyWords NMTOKENS #IMPLIED> |
<!--
**********************************
* Общий элемент Packaged Content *
********************************** -->
<!ELEMENT PackagedContent (#PCDATA)>
<!ATTLIST PackagedContent Name CDATA #IMPLIED
| Content NMTOKEN "PCDATA" | Transform (NONE|BASE64) "NONE"> |
***********************
* Торговые компоненты *
*********************** -->
<!-- PROTOCOL OPTIONS COMPONENT -->
<!ELEMENT ProtocolOptions EMPTY >
<!ATTLIST ProtocolOptions ID ID #REQUIRED
| xml:lang NMTOKEN #REQUIRED | ShortDesc CDATA #REQUIRED |
| SenderNetLocn CDATA #IMPLIED | SecureSenderNetLocn CDATA #IMPLIED |
<!-- AUTHENTICATION DATA COMPONENT -->
<!ELEMENT AuthReq (Algorithm, PackagedContent*)>
<!ATTLIST AuthReq ID ID #REQUIRED
AuthenticationId CDATA #REQUIREDContentSoftwareId CDATA #IMPLIED>
<!-- AUTHENTICATION RESPONSE COMPONENT -->
<!ELEMENT AuthResp (PackagedContent*) >
<!ATTLIST AuthResp ID ID #REQUIRED
AuthenticationId CDATA #REQUIREDSelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!-- TRADING ROLE INFO REQUEST COMPONENT -->
<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq ID ID #REQUIRED
TradingRoleList NMTOKENS #REQUIRED>
<!-- ORDER COMPONENT -->
<!ELEMENT Order (PackagedContent*)>
><!ATTLIST Order ID ID #REQUIRED
| xml:lang NMTOKEN #REQUIRED | OrderIdentifier CDATA #REQUIRED |
| ShortDesc CDATA #REQUIRED | OkFrom CDATA #REQUIRED |
| OkTo CDATA #REQUIRED | ApplicableLaw CDATA #REQUIRED |
<!-- ORGANISATION COMPONENT -->
<!ELEMENT Org (TradingRole+, ContactInfo?, PersonName?, PostalAddress?)>
<!ATTLIST Org ID ID #REQUIRED
| xml:lang NMTOKEN #REQUIRED | OrgId CDATA #REQUIRED |
| LegalName CDATA #IMPLIED | ShortDesc CDATA #IMPLIED |
<!ELEMENT TradingRole EMPTY>
><!ATTLIST TradingRole ID ID#REQUIRED
| TradingRole NMTOKEN #REQUIRED | IotpMsgIdPrefix NMTOKEN #REQUIRED |
| CancelNetLocn CDATA #IMPLIED | ErrorNetLocn CDATA #IMPLIED |
<!ELEMENT ContactInfo EMPTY>
<!ATTLIST ContactInfo xml:lang NMTOKEN #IMPLIED
| Tel CDATA #IMPLIED | Fax CDATA #IMPLIED |
| Email CDATA #IMPLIED | NetLocn CDATA #IMPLIED> |
<!ATTLIST PersonName xml:lang NMTOKEN #IMPLIED
| Title CDATA #IMPLIED | GivenName CDATA #IMPLIED |
| Initials CDATA #IMPLIED | FamilyName CDATA #IMPLIED> |
<!ATTLIST PostalAddress xml:lang NMTOKEN #IMPLIED
| AddressLine1 CDATA #IMPLIED | AddressLine2 CDATA #IMPLIED |
| CityOrTown CDATA #IMPLIED | StateOrRegion CDATA #IMPLIED |
| PostalCode CDATA #IMPLIED | Country CDATA #IMPLIED |
<!-- BRAND LIST COMPONENT -->
<!ELEMENT BrandList (Brand+, ProtocolAmount+, CurrencyAmount+, PayProtocol+)>
| <!ATTLIST BrandList ID | ID #REQUIRED |
| xml:lang NMTOKEN #REQUIRED | ShortDesc CDATA #REQUIRED PayDirection |
<!ELEMENT Brand (ProtocolBrand*, PackagedContent*)>
<! ATTLIST Brand ID ID #REQUIRED
| xml:lang NMTOKEN #IMPLIED | BrandId CDATA #REQUIRED |
| BrandName CDATA #REQUIRED | BrandLogoNetLocn CDATA #REQUIRED |
| BrandNarrative CDATA #IMPLIED | ProtocolAmountRefs IDREFS #REQUIRED |
<!ELEMENT ProtocolBrand (PackagedContent*) >
<!ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #REQUIRED>
<!ELEMENT ProtocolAmount (PackagedContent*) >
| <!ATTLIST ProtocolAmount ID | ID #REQUIRED |
| PayProtocolRef IDREF #REQUIRED | CurrencyAmountRefs IDREFS #REQUIRED |
<!ELEMENT CurrencyAmount EMPTY >
| <!ATTLIST CurrencyAmount ID | ID #REQUIRED |
| Amount CDATA #REQUIRED | CurrCodeType NMTOKEN 'ISO4217-A' |
<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol ID ID #REQUIRED
| xml:lang NMTOKEN #IMPLIED | ProtocolId NMTOKEN #REQUIRED |
| ProtocolName CDATA #REQUIRED | ActionOrgRef NMTOKEN #REQUIRED |
| PayReqNetLocn CDATA #IMPLIED | SecPayReqNetLocn CDATA #IMPLIED |
<!-- BRAND SELECTION COMPONENT -->
<!ELEMENT BrandSelection (BrandSelBrandInfo?,
| BrandSelProtocolAmountInfo?, | BrandSelCurrencyAmountInfo?)> |
| <!ATTLIST BrandSelection ID | ID #REQUIRED |
| BrandListRef NMTOKEN #REQUIRED | BrandRef NMTOKEN #REQUIRED |
CurrencyAmountRef NMTOKEN #REQUIRED>
<!ELEMENT BrandSelBrandInfo (PackagedContent+)>
<! ATTLIST BrandSelBrandInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+)>
<!ATTLIST BrandSelProtocolAmountInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+)>
<!ATTLIST BrandSelCurrencyAmountInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT COMPONENT -->
<!ELEMENT Payment EMPTY>
| <!ATTLIST Payment ID | ID #REQUIRED |
| OkFrom CDATA #REQUIRED | OkTo CDATA #REQUIRED |
| BrandListRef NMTOKEN #REQUIRED | SignedPayReceipt (True | False) #REQUIRED |
<!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent+) >
| <!ATTLIST PaySchemeData ID | ID #REQUIRED |
| PaymentRef NMTOKEN #IMPLIED | ConsumerPaymentId CDATA #IMPLIED |
| PaymentHandlerPayId CDATA #IMPLIED | ContentSoftwareId CDATA #IMPLIED> |
<!ELEMENT PayReceipt (PackagedContent*) >
| <!ATTLIST PayReceipt ID ID #REQUIRED | PaymentRef NMTOKEN #REQUIRED |
| PayReceiptNameRefs NMTOKENS #IMPLIED | ContentSoftwareId CDATA #IMPLIED> |
<!ELEMENT PaymentNote (PackagedContent+)>
<!ATTLIST PaymentNote ID ID #REQUIREDContentSoftwareId CDATA #IMPLIED>
<!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
| <!ATTLIST Delivery ID | ID #REQUIRED |
| xml:lang NMTOKEN #REQUIRED | DelivExch (True | False) #REQUIRED |
| DelivAndPayResp (True | False) #REQUIRED | ActionOrgRef NMTOKEN #IMPLIED> |
| <!ATTLIST DeliveryData xml:lang | NMTOKEN #IMPLIED |
| OkFrom CDATA #REQUIRED | OkTo CDATA #REQUIRED |
| DelivMethod NMTOKEN #REQUIRED | DelivToRef NMTOKEN #REQUIRED |
| DelivReqNetLocn CDATA #IMPLIED | SecDelivReqNetLocn CDATA #IMPLIED |
<!-- CONSUMER DELIVERY DATA COMPONENT -->
<!ELEMENT ConsumerDeliveryData EMPTY>
<!ATTLIST ConsumerDeliveryData ID ID #REQUIRED
ConsumerDeliveryId CDATA #REQUIRED>
<!-- DELIVERY NOTE COMPONENT -->
<!ELEMENT DeliveryNote (PackagedContent+)>
| <!ATTLIST DeliveryNote ID | ID #REQUIRED |
| xml:lang NMTOKEN #REQUIRED | DelivHandlerDelivId CDATA #IMPLIED |
<!-- STATUS COMPONENT -->
<!ELEMENT Status EMPTY>
| <!ATTLIST Status ID | ID #REQUIRED |
| xml:lang NMTOKEN #REQUIRED | StatusType NMTOKEN #REQUIRED |
| ElRef NMTOKEN #IMPLIED | ProcessState (NotYetStarted | InProgress | |
| CompletedOk | Failed | ProcessError) #REQUIRED CompletionCode NMTOKEN #IMPLIED |
|
| ProcessReference CDATA #IMPLIED | StatusDesc CDATA #IMPLIED > |
<!ELEMENT TradingRoleData (PackagedContent+)>
<!ATTLIST TradingRoleData ID ID #REQUIRED
<!ELEMENT InquiryType EMPTY>
| <!ATTLIST InquiryType ID | ID #REQUIRED |
| Type NMTOKEN #REQUIRED | ElRef NMTOKEN #IMPLIED |
<!-- ERROR COMPONENT -->
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*)>
| <!ATTLIST ErrorComp ID | NMTOKEN #REQUIRED |
| xml:lang NMTOKEN #REQUIRED | ErrorCode NMTOKEN #REQUIRED |
| ErrorDesc CDATA #REQUIRED | Severity (Warning|TransientError|HardError) #REQUIRED |
| MinRetrySecs CDATA #IMPLIED | SwVendorErrorRef CDATA #IMPLIED> |
| <!ATTLIST ErrorLocation ElementType | NMTOKEN #REQUIRED |
| IotpMsgRef NMTOKEN #IMPLIED | BlkRef NMTOKEN #IMPLIED |
| CompRef NMTOKEN #IMPLIED | ElementRef NMTOKEN #IMPLIED |
<!--
**********************
* ТОРГОВЫЕ БЛОКИ *
********************** -->
<!-- TRADING PROTOCOL OPTIONS BLOCK -->
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* )>
<!ATTLIST TpoBlk ID ID #REQUIRED >
<!-- TPO SELECTION BLOCK -->
<!ELEMENT TpoSelectionBlk (BrandSelection+)>
<!ATTLIST TpoSelectionBlk ID ID #REQUIRED>
<!-- OFFER RESPONSE BLOCK -->
<!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*)>
<!ATTLIST OfferRespBlk ID ID #REQUIRED >
<!-- AUTHENTICATION REQUEST BLOCK -->
<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?)>
<!ATTLIST AuthReqBlk ID ID #REQUIRED>
<!-- AUTHENTICATION RESPONSE BLOCK -->
<!ELEMENT AuthRespBlk (AuthResp?, Org*)>
<!ATTLIST AuthRespBlk ID ID #REQUIRED>
<!-- AUTHENTICATION STATUS BLOCK -->
<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk ID ID #REQUIRED>
<!-- PAYMENT REQUEST BLOCK -->
<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*, TradingRoleData*)>
<!ATTLIST PayReqBlk ID ID #REQUIRED>
<!-- PAYMENT EXCHANGE BLOCK -->
<!ELEMENT PayExchBlk (PaySchemeData)>
<!ATTLIST PayExchBlk ID ID #REQUIRED>
<!-- PAYMENT RESPONSE BLOCK -->
<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
PaymentNote?, TradingRoleData*) >
<!ATTLIST PayRespBlk ID ID #REQUIRED>
<!-- DELIVERY REQUEST BLOCK -->
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
ConsumerDeliveryData?, TradingRoleData*) >
<!ATTLIST DeliveryReqBlk ID ID #REQUIRED>
<!-- DELIVERY RESPONSE BLOCK -->
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote)>
<!ATTLIST DeliveryRespBlk ID ID #REQUIRED>
<!-- INQUIRY REQUEST BLOCK -->
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? )>
<!ATTLIST InquiryReqBlk ID ID #REQUIRED >
<!-- INQUIRY RESPONSE BLOCK -->
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?)>
<! ATTLIST InquiryRespBlk ID ID #REQUIRED
LastReceivedIotpMsgRef NMTOKEN #IMPLIED
LastSentIotpMsgRef NMTOKEN #IMPLIED>
<!-- PING REQUEST BLOCK -->
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk ID ID #REQUIRED>
<!-- PING RESPONSE BLOCK -->
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk ID ID #REQUIRED
PingStatusCode (Ok | Busy | Down) #REQUIRED
BR/P> xml:lang NMTOKEN #IMPLIEDPingStatusDesc CDATA #IMPLIED>
<!-- ERROR BLOCK -->
><!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*)>
<!ATTLIST ErrorBlk ID ID #REQUIRED>
<!-- CANCEL BLOCK -->
<!ELEMENT CancelBlk (Status)>
<!ATTLIST CancelBlk ID ID #REQUIRED>
<!--
*****************************
* Определение блока подписи *
***************************** -->
<!ELEMENT IotpSignatures (Signature+ ,Certificate*)>
<!ATTLIST IotpSignatures ID ID #IMPLIED>
<!--
*******************************************
* Определение компонента подписи IOTP *
******************************************* -->
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature ID ID #IMPLIED>
<!ELEMENT Manifest ( Algorithm+,
Digest+,
Attribute*,
OriginatorInfo,
RecipientInfo+ )>
<!ATTLIST Manifest LocatorHRefBase CDATA #IMPLIED>
<!ELEMENT Algorithm (Parameter*)>
<!ATTLIST Algorithm ID ID #REQUIRED
>type (digest|signature) #IMPLIEDname NMTOKEN #REQUIRED>
<!ELEMENT Digest (Locator, Value)>
<!ATTLIST Digest DigestAlgorithmRef IDREF #REQUIRED>
<!ELEMENT Attribute ( ANY ) >
<!ATTLIST Attribute type NMTOKEN #REQUIRED
>critical ( true | false ) #REQUIRED>
<!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo OriginatorRef NMTOKEN #IMPLIED>
<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #IMPLIEDSignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED>
<!ELEMENT KeyIdentifier EMPTY>
<! ATTLIST KeyIdentifier value CDATA #REQUIRED>
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter type CDATA #REQUIRED>
><!--
*******************************************
* Определение компонента сертификата IOTP *
******************************************* -->
<!ELEMENT Certificate ( IssuerAndSerialNumber, ( Value | Locator ) )>
<!ATTLIST Certificate ID ID #IMPLIEDtype NMTOKEN #REQUIRED>
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber issuer CDATA #REQUIRED number CDATA
#REQUIRED>
<!--
**************************************
* Определение компонента SHARED IOTP *
************************************** -->
<!ELEMENT Value ( #PCDATA )>
<!ATTLIST Value ID ID #IMPLIED encoding (base64|none) 'base64'>
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator xml:link CDATA #FIXED 'simple' href CDATA #REQUIRED>
Открытый торговый протокол Интернет–
4.6. 1 Открытый торговый протокол Интернет– IOTP версия 1.0
Перевод Семенова Ю.А. (ГНЦ ИТЭФ)
| Мерзавцам этим только б воровать, Про то торговцы титулами знают, Но, кроме денег, им на все плевать. Джузеппе Джусти, "Шутки" |
IOTP поддерживает:
Известные модели торговли Новые модели торговли Глобальную совместимость 1.1. Коммерция в Интернет
Рост Интернет и прогресс в электронной коммерции привносят огромные изменения в сферу бизнеса, политики, управления и в само общество. Методы, которые используются партнерами в торговле, обогатились и необратимо изменились. Наиболее заметные изменения характера торговли включают в себя:
Присутствие. Операции, требующие личного контакта, становятся исключением, а не правилом. Этот процесс начался при внедрении торговли по почте и по телефону. Электронная коммерция через Интернет еще шире раздвигает область и объем операций, проводимых без личного контакта участников сделок. Аутентификация. Важной частью личного присутствия является возможность партнеров использование знакомых объектов и диалога для подтверждения того, кем они являются. Продавец демонстрирует различными способами свою способность производить кредитные и платежные операции. Покупатель предъявляет физические свидетельства своей платежеспособности, полученные от государства или финансовой организации. При этом учитывается разнообразная объективная информация: местоположение магазина, внешность, знакомство и поведение участников, знакомство с данной фирмой и ее торговым знаком. Инструменты платежа.
Несмотря на широкое рзвитие безналичных платежей, заметная часть торговых операций обеспечивается наличными деньгами или даже бартером. Существующая инфраструктура платежной системы по экономическим соображениям не может поддерживать операции с низкими суммами платежей, но и не может от них отказаться. Стоимость операций. Новое значение низкой стоимости операции в Интернет связано с возможностью того, что продавец может предложить, например, объекты с ценой, составляющей долю денежной единицы, которой не существует в реальности. Доставка. Внедряются новые методы доставки, включая доставку по сети, например, информации или программных продуктов. Возможна доставка по частям при играх, просмотре, прослушивании и некоторых других виртуальных услугах, при этом она должна быть подтверждена до осуществления платежа. Логично, что деньги в этом случае не могут быть возвращены. 1.2. Преимущества IOTP
Разработки программ для электронной коммерции будут более привлекательны, если они окажутся совместимыми для разных разработчиков. Однако IOTP призван, прежде всего, решить проблему коммуникаций между различными решениями.
Виды платежей
IOTP предлагает стандартные рамки для инкапсуляции платежных протоколов. Это означает, что средства платежей смогут лучше взаимодействовать, если они встроены в программы, следующие протоколу IOTP. В результате базовые виды электронных платежей смогут найти более широкое распространение на большем разнообразии рабочих платформ.
Продавцы
Существует несколько преимуществ для торговцев:
Они смогут предложить более широкий перечень видов платежей, Они смогут быть более уверены, что покупатель будет иметь программу, необходимую для осуществления покупки При получении платежа и расписки от покупателя о получении товара или услуги они смогут обеспечить клиента гарантией, что он имел дело именно с тем человеком или организацией новые торговцы смогут вступить в этот Интернет-рынок с новыми продуктами и услугами, используя новые возможности, предоставляемые IOTP. Банки и финансовые организации
Существует несколько преимуществ для банков и финансовых организаций:
они смогут предоставить услуги IOTP для торговцев они найдут новые возможности для реализации услуг, сопряженных с IOTP: - предоставление услуг клиентам продавцов
- деньги от обработки новых платежей и депозитов
они имеют возможность построить отношения с новыми продавцами Покупатели
Для покупателей также имеется несколько преимуществ:
они получат больший выбор продавцов, с которыми они смогут иметь дело > имеется более удобный интерфейс для осуществления покупки существуют возможности уладить их проблемы через продавца (а не через банк) существует запись их операций, которая может использоваться, например, налоговыми службами 1.3. Основы IOTP
Протокол описывает содержимое, формат и последовательность сообщений, которые пересылаются между партнерами электронной торговли - покупателями, торговцами и банками или финансовыми организациями.
Протокол спроектирован так, чтобы обеспечить его применимость при любых схемах электронных платежей, так как он реализует весь процесс продажи, где передача денег всего лишь один шаг из многих.
Схемы платежей которые поддерживает IOTP включают MasterCard Credit, Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, Proton и т.д..
Каждая схема содержит некоторый обмен сообщениями, который является характерным именно для нее. Эти схемно-зависимые части протокола помещены в приложения к данному документу.
Документ не предписывает участникам, какое следует использовать программное обеспечение или процесс. Он определяет только необходимые рамки в пределах которых реализуется торговая операция.
Отношения элементов списка видов платежа
Рисунок .15. Отношения элементов списка видов платежа
Примеры списков видов платежа содержатся в главе 11.2.
7.7.1. Элемент Brand
Элемент Brand описывает вид платежа, который может быть использован при оплате покупки. Один или более таких элементов образуют компонент списка видов платежа, который имеет атрибут PayDirection, установленный равным Debit. Только один элемент вида платежа может содержаться в компоненте списка видов платежа (Brand List), который имеет атрибут PayDirection = Credit.
<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >
ContentSoftwareId CDATA #IMPLIED>
Атрибуты:
| ID | Идентификатор элемента, относящийся потенциально к компоненту выбора вида платежа (Brand Selection), содержащегося в последнем сообщении платежного запроса, и однозначно идентифицирующий элемент Brand данной транзакции. |
| xml:lang | Определяет язык, используемый атрибутами и содержимым данного элемента. Смотри раздел 3.8. |
| BrandId | Содержит уникальный идентификатор для вида платежа. Он используется для установления соответствия со списком платежных инструментов, которыми располагает Покупатель, чтобы определить, может ли он обеспечить платеж данного вида. |
Так как значения BrandId управляются процедурами IANA, допускается определение значений самим пользователем.
| BrandName | Содержит название вида платежа, например MasterCard. Это описание вида платежа, которое отображается для Покупателя на понятном для него языке, заданном атрибутом xml:lang. Например, это может быть "American Airlines Advantage Visa". Заметим, что этот атрибут не используется для установления соответствия с инструментами платежа, которыми располагает Покупатель. |
| BrandLogoNetLocn | Сетевая позиция, которая может быть использована для загрузки логотипа организации. Смотри раздел “Получение логотипа” (раздел 10). |
Содержимое этого атрибута должно соответствовать документу [RFC1738].
Cодержимое:
| PackagedContent | Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протоколе и/ или виде платежа, которые может использовать платежный протокол. Содержимое этой информации определяется в приложении для платежных протоколов. |
Элемент Protocol Amount связывает вид платежа с:
видом валюты и суммами в элементах Currency Amount (смотри раздел 7.7.4), которые могут использоваться с данным видом платежа, и платежными протоколами и Кассирами, определенными в элементе платежного протокола (смотри раздел 7.7.5), котоый может быть использован для этого видв валюты и сумм платежа. Его определение представлено ниже:
<!ELEMENT ProtocolAmount (PackagedContent*) >
<!ATTLIST ProtocolAmount ID ID #REQUIRED
PayProtocolRef IDREF #REQUIREDCurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Атрибуты:
| ID | идентификатор элемента, на который может ссылаться элемент Brand; или компонент выбора видов платежа, содержащийся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент Protocol Amount для данной транзакции IOTP. |
| PayProtocolRef | Содержит ссылку элемента (смотри раздел 3.5), которая указывает на элемент платежного протокола (смотри раздел 7.7.5), содержащийплатежный протокол и Кассира, которые могут использоваться для данного вида платежа. |
| CurrencyAmountRefs | Содержит список ссылок элемента (смотри раздел 3.5), который указывает на элемент Currency Amount (смотри раздел 7.7.4), описывающий вид валюты и сумму, которые могут использоваться для данного вида платежа. |
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протокольной сумме, которая может использоваться платежным протоколом. Содержимое этой информации определено в приложении для платежных протоколов. |
7.7.4. Элемент валютной суммы
Элемент валютной суммы содержит в себе:
код валюты (и ее тип), сумму. Один или более таких элементов заключены в каждом компоненте списка видов платежа. Его определение приведено ниже:
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount ID ID #REQUIRED
>Amount CDATA #REQUIREDCurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED >
Атрибуты:
| ID | Идентификатор элемента, (Brand Selection), содержащиеся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент Currency Amount данной транзакции IOTP. |
| Amount | Указывает сумму, которая должна быть заплачена. Например $245.35 будет выражено как "245.35". Заметим, что значения меньше наименьшей целой величины вполне допустима. Например одна десятая цента будет записана как "0.001". |
| CurrCodeType | Указывает CurrCode области. Этот атрибут включен с тем, чтобы была возможность поддержания нестандартных "валют" например “торговых марок” и т.д.. Атрибут может принимать значения: |
| CurrCode | Код, идентифицирующий валюту, которая должна использоваться при платеже. Область корректных кодов валюты определена атрибутом CurrCodeType. |
7.7.5. Элемент платежного протокола
Элемент платежного протокола специфицирует детали для платежного протокола и для Кассира, которые могут использоваться для жанного видв платежа. Один или более таких элементов содержится в каждом списке видов платежа.
<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol ID ID #REQUIRED
| xml:lang NMTOKEN #IMPLIED | ProtocolId NMTOKEN #REQUIRED |
| ProtocolName CDATA #REQUIRED | ActionOrgRef NMTOKEN #REQUIRED |
| PayReqNetLocn CDATA #IMPLIED | SecPayReqNetLocn CDATA #IMPLIED |
Атрибуты:
| ID | Идентификатор элемента, на который может ссылаться элемент Brand; или компонент выбора вида платежа (Brand Selection), содержащиеся в последующих сообщениях платежного запроса. Он однозначно идентифицирует элемент PayProtocol данной транзакции IOTP. |
| xml:lang | Определяет язык, используемый атрибутами и содержимым данного элемента. Смотри раздел 3.8. |
| ProtocolId | Состоит из имени протокола и версии, например "SETv1.0". |
| ProtocolName | Описание платежного протокола и его версии на языке, идентифицированном атрибутом xml:lang. Например "Secure Electronic Transaction Version 1.0". Его целью является помочь, если требуется, в предоставлении информации об используемом платежном протоколе. |
| ActionOrgRef | Ссылка элемента (смотри раздел 3.5) на компонент Organisation для Кассира при данном платежном протоколе. |
| PayReqNetLocn | Сетевая позиция, указывающая куда следует послать платежный запрос в отсутствии гарантии безопасности при заданном протоколе. |
| SecPayReqNetLocn | Сетевая позиция, указывающая куда следует послать платежный запрос в условиях гарантии безопасности при заданном протоколе. Безопасный платеж предполагает для коммуникации с кассиром использование безопасного канала, такого как [SSL/TLS]. |
ContentSoftwareIdСмотри раздел 14. Словарь.
Cодержимое:
| PackagedContent | Опционные элементы Packaged Content (смотри раздел 3.7), содержащие информацию о протоколе, который используется платежным протоколом. Содержание этой информации определяется в приложении для платежных ппротоколов. |
7.8. Компонент выбора вида платежа
Компонент выбора вида платежа идентифицирует выбор вида платежа, платежный протокол и кассира. Этот элемент используется:
в сообщениях платежных запросов в транзакциях покупки и обмена ценностями для идентификации вида платежа, протокола и кассира; чтобы опционно проинформировать продавца об используемом виде платежа с целью возможной последующей коррекции предложения и заказа. В базовой версии IOTP, целостность компонентов выбора вида платежа не гарантируется. Однако модификация компонентов выбора вида платежа может привести лишь к отказу обслуживания, если сам платежный протокол безопасен и контролирует модификацию или дублирование сообщений и может противостоять любым другим атакам.
Определение компонента выбора вида платежа представлено ниже.
<!ELEMENT BrandSelection (BrandSelBrandInfo?, BrandSelProtocolAmountInfo?,
BrandSelCurrencyAmountInfo?) >
<!ATTLIST BrandSelection ID ID #REQUIRED
| BrandListRef NMTOKEN #REQUIRED | BrandRef NMTOKEN #REQUIRED |
CurrencyAmountRef NMTOKEN #REQUIRED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент выбора вида платежа транзакции. |
| BrandListRef | Ссылка элемента (смотри раздел 3.5) компонента списка видов платежа, из которого был выбран Brand. |
| BrandRef | Ссылка элемента Brand компонента списка видов платежа, который был выбран из списка и использован для платежа. |
| ProtocolAmountRef | Ссылка элемента для Protocol Amount в пределах компонента списка видов платежа, который использован при платеже. |
| CurrencyAmountRef | Ссылка элемента для Currency Amount в пределах компонента списка видов платежа, который использован при платеже. |
| BrandSelBrandInfo, BrandSelProtocolAmountInfo, Содержит любые дополнительные данные, которые могут быть необходимы при конкретном платеже или протоколе. Смотри разделы 7.8.1, 7.8.2, и 7.8.3. |
атрибут BrandListRef должен содержать идентификатор компонента списка видов платежа транзакции IOTP; на каждый компонент списка видов платежа в блоке опций торгового протокола (смотри раздел 8.1) должен ссылаться один и только один компонент выбора вида платежа. BrandRef должен относиться к ID Brand, содержащегося в компоненте списка видов платежа, на который ссылается BrandListRef ProtocolAmountRef должен относиться к одному ID элемента, содержащемуся в атрибуте ProtocolAmountRefs элемента Brand, идентифицированного BrandRef CurrencyAmountRef должен относиться к одному ID элемента содержащемуся в атрибуте ProtocolAmountRefs элемента Protocol Amount, идентифицированного ProtocolAmountRef. Пример компонента выбора вида платежа включен в раздел 11.2.
7.8.1. Информационный элемент выбора вида платежа
Информационный элемент выбора вида платежа cсодержит любую дополнительную информацию, которая может быть необходима для какого-то конкретного вида платежа. Смотри приложение IOTP для платежных методов, где описано применние этого элемента.
<!ELEMENT BrandSelBrandInfo (PackagedContent+) >
<!ATTLIST BrandSelBrandInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED >
Атрибуты:
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Элементы Packaged Content (смотри раздел 3.7), содержащие дополнительные данные, которые могут быть необходимы для конкретного вида платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента. |
Элемент Amount Info протокола выбора вида платежа содержит любую дополнительную информацию, зависящую от платежного протокола, которая может быть необходима для конкретного вида платежа или плптежного протокола. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+)>
<!ATTLIST BrandSelProtocolAmountInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
Атрибуты:
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Элементы Packaged Content (смотри раздел 3.7), которые могут содержать дополнительную информацию, необходимую для конкретного вида платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента. |
Информационный элемент валютной суммы выбора вида платежа содержит любую дополнительную информацию, зависящую от вида платежа и валюты, которая может быть необходима при конкретном виде платежа. Смотри приложение IOTP по платежным методам, где описаны методы использования данного элемента.
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+)>
<!ATTLIST BrandSelCurrencyAmountInfo ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED>
Атрибуты:
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Элементы Packaged Content (смотри раздел 3.7), которые содержат дополнительную информацию, относящуюся к виду платежа и валюты. Смотри приложение IOTP по платежным методам, где описано использование этого элемента. |
Компонент платежа содержит информацию, используемую для управления процедурой выполнения платежа. Он предоставляет информацию о:
Временном интервале в пределах которого Кассир может начать платежную операцию; Ссылку на список видов платежа (смотри раздел 7.7), который идентифицирует виды платежа, протоколы, виды валюты и суммы, которые могут использоваться при осуществлении платежа. следует ли предоставлять платежную расписку; должен ли данному платежу предшествовать другой платеж. Его определение выглядит следующим образом.
<!ELEMENT Payment EMPTY > <!ATTLIST Payment ID ID #REQUIRED
| OkFrom CDATA #REQUIRED | OkTo CDATA #REQUIRED |
| BrandListRef NMTOKEN #REQUIRED | SignedPayReceipt (True | False) #REQUIRED |
Атрибуты:
| ID | Идентификатор, который однозначно идентифицирует платежный компонент в транзакции IOTP. |
| OkFrom | Дата и время в формате [UTC], после которого кассир может воспринимать на обработку блок платежного запроса (смотри раздел 8.7), содержащий компонент платежа. |
| OkTo | Дата и время в формате [UTC], до которого Кассир может воспринимать на обработку блок платежного запроса, содержащий компонент платежа. |
| BrandListRef | Ссылка элемента (смотри раздел 3.5) компонента списка видов платежа (смотри раздел 7.7) в рамках торгового блока TPO транзакции IOTP. Список видов платежа идентифицирует альтернативные способы осуществления платежа. |
| SignedPayReceipt | Указывает, должен ли быть подписан блок платежного отклика (смотри раздел 8.9), сгенерированный Кассиром. |
| StartAfter | Содержит ссылки элемента (смотри раздел 3.5) других платежных компонентов, которые описывают платежи, которые должны быть проведены до того, как будет произведен данный платеж. Если атрибут StartAfter отсутствует, тогда никаких зависимостей нет и платеж может быть проведен немедленно. |
7.10. Компонент платежной схемы
Компонент платежной схемы содержит информацию платежного протокола для специфической платежной схемы, реализуемой между партнерами, вовлеченными в платеж, например [SET]-сообщение. Определение компонента представлено ниже.
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData ID ID #REQUIRED
| PaymentRef NMTOKEN #IMPLIED | ConsumerPaymentId CDATA #IMPLIED |
| PaymentHandlerPayId CDATA #IMPLIED | ContentSoftwareId CDATA #IMPLIED> |
| ID | Идентификатор, который однозначно определяет компонент схемы оплаты транзакции IOTP. |
| PaymentRef | Ссылка элемента (смотри раздел 3.5) компонента платежа (смотри раздел 7.9), с которым связан компонент схемы платежа. Атрибут необходим, если только компонент схемы платежа не является частью запроса состояния транзакции (смотри раздел 9.2.1). |
| ConsumerPaymentId | Идентификатор, специфицированный Покупателем, который в случае возвращения Кассиром в другом компоненте схемы платежа (или другим способом) позволит Покупателю определить, о каком платеже идет речь. |
| PaymentHandlerPayId | Идентификатор, специфицированный Кассиром, который в случае возвращения Покупателем в другом компоненте схемы платежа (или другим способом) позволит Кассиру определить, о каком платеже идет речь. Атрибут необходим для каждого компонента схемы платежа, вне зависимости от того, что содержится в блоке платежного запроса. |
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Содержит протокольную информацию о схеме платежа в виде элементов Packaged Content (смотри раздел 3.7). Определение содержимого смотри в приложение по схемам платежа. |
значения атрибута Name каждого элемента pakaged content определены в приложении для платежных протоколов; значение каждого Name должно быть уникальным для платежа, где платеж определяется как совокупность всех платежных схем или компонентов платежных расписок с идентияным значением атрибута PaymentRef. 7.11.
Компонент платежной расписки
Плптежная расписка представляет собой запись о платеже, которая показывает, какая сумма заплачена или получена. Она отдичается от расписки о покупке, тем что здесь нет записи о том, что куплено. Обычно в компоенте платежной расписки содержатся данные, которые описывают:
сумму платежа и его валюту; дату и время платежа; внутренние числовые ссылки, которые идентифицируют платеж для платежной системы; цифровые подписи, выработанные платежным механизмом и призванные позднее подтвердить, что платеж состоялся. Если использованный платежный метод сконфигироирован соответствующим образом, то компонент платежной расписки должен содержать сообщения платежного протокола или ссылки на сообщения, которые подтверждают выполнение платежа.
Точное определение содержимого платежной расписки зависит от метода платежа. Информация, содержащаяся в компоненте платежной расписки, должна отображаться или каким-либо другим способом доводиться до сведения Покупателя.
Если компонент платежной расписки содержит сообщения платежного протокола, тогда они должны быть обработаны программой метода платежа,чтобы преобразовать их в формат понятный Покупателю.
Определение компонента платежной расписки.
<!ELEMENT PayReceipt (PackagedContent*)>
| <!ATTLIST PayReceipt ID | ID #REQUIRED |
| PaymentRef NMTOKEN #REQUIRED | PayReceiptNameRefs NMTOKENS #IMPLIED |
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент платежной расписки транзакции IOTP. |
| PaymentRef | Содержит ссылку элемента (смотри раздел 3.5) на компонент платежа (смотри раздел 7.9), к которому относится данная расписка. |
| PayReceiptNameRefs | Опционно содержит список значений атрибутов Name элементов Packaged Content, которые образуют расписку. Элементы Packaged Content могут содержать: |
| о | компоненты данных платежной схемы, обмен которыми производится между Кассиром и Покупателем в процессе платежа и/или |
| o | сам компоент платежной расписки. Заметим, что: |
| o | каждый компонент схемы определяет в своем приложении имена элементов Packaged Content, которые должны быть перечислены в этом атрибуте (если они нужны). |
| о | Если компонент платежной схемы содержит элементы Packaged Content, с именами которые совпадают с именем в PayReceiptNameRefs, тогда на такие компоненты платежной схемы должны ссылаться дайджесты в компоненте подписи платежного отклика (если используется такая подпись). |
Программа клиента должна спасать все компоненты, на которые имеются ссылки, с тем чтобы платежная расписка могла быть воспроизведена, если это потребуется.
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Опционно содержит информацию платежной расписки (платежную схему) в виде элементов Packaged Content (смотри раздел 3.7). Определение его содержимого смотри в прилжении платежной схемы. |
| о | значения атрибута Name каждого элемента packaged content определены приложением платежного протокола; |
| о | значение Name должно быть уникальным для каждого платежа, как и для всех схем платежа или компонентов платежной расписки с идентичным значением атрибута PaymentRef. |
7.12. Компоент Payment Note
Компонент Payment Note (платежное заывление) содержит дополнительную, несвязанную с платежом информацию, которую Кассир хочет предоставит покупателю. Например, если был произведен отзыв сделки или осуществлен депозит, тогда он может содержать информацию о балансе по завершении перевода. Данные должны дублировать информацию, содержащуюся в компоненте платежной расписки.
Информация, содержащаяся в компоненте Payment Note должна быть отображена или представлена каким-то иным способом покупателю. Для совместимости компонент Payment Note должен поддерживать как минимум содержимое типа "Plain Text", HTML и XML. Его определение представлено ниже.
<!ELEMENT PaymentNote (PackagedContent+) >
<!ATTLIST PaymentNote ID ID #REQUIREDContentSoftwareId CDATA #IMPLIED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент платежной расписки транзакции IOTP. |
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Содержит дополнительную, не связанную с платежом информацию, которую кассир хочет довести до сведения покупателя в виде одного или более элементов Packaged Content (смотри раздел 3.7). |
Компонент доставки
Компонент доставки содержит информацию, необходимую для доставки товаров или услуг. Его определение приведено ниже.
<!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
<!ATTLIST Delivery ID ID #REQUIRED
| xml:lang NMTOKEN #REQUIRED | DelivExch (True | False) #REQUIRED |
| DelivAndPayResp (True | False) #REQUIRED | ActionOrgRef NMTOKEN #IMPLIED> |
| ID | Идентификатор, который однозначно определяет компонент доставки транзакции. |
| xml:lang | Определяет язык, используемый атрибутами и дочерними элементами этого компонента, если только атрибут дочернего элемента xml:lang не перепишет это значение. Смотри раздел 3.8. |
| DelivExch | Индицирует факт наличия в транзакции сообщений, ассоциированных с обменом доставки. Корректные значения: о“Истинно” указывает на наличие обмена доставки. o“Ложно” указывает на отсутствие обмена доставки. |
| DelivAndPayResp |
Индицирует то, чтоблок отклика доставки (смотри раздел 8.11) и блок отклика плптежа (смотри раздел 8.9) находся в одном и том же сообщении IOTP. Корректные значения: o “Истинно” указывает, что оба блока находятся в одном и том же сообщении IOTP и o “Ложно” указывает, что каждый блок размещен в разных сообщениях IOTP. |
На практике комбинирование блока отклика доставкии блока отклика платежа имеет смысл только в случае, когда Продавец, Кассир и Агент доставки принадлежат одной организации, так как:
о Кассир должен иметь доступ к информации компонента Order, с тем чтобы знать что надо доставлять и
o Кассир должен должен быть способен осуществить доставку.
| ActionOrgRef | Ссылка элемента на компонент организации Агента доставки. |
| DeliveryData | Содержит подробности того, как будет осуществляться доставка. Смотри 7.13.1. |
| PackagedContent | Содержит данные "пользователя", определенные для продавца и необходимые агенту доставки в виде одного или нескольких элементов Packaged Content. Смотри раздел 3.7. |
7.13.1. Элемент Delivery Data
Элемент DeliveryData содержит информацию о том, куда и как должны доставляться товары или услуги. Его определение представлено ниже.
<!ELEMENT DeliveryData (PackagedContent*) >
| <!ATTLIST DeliveryData xml:lang | NMTOKEN #IMPLIED |
| OkFrom CDATA #REQUIRED | OkTo CDATA #REQUIRED |
| DelivMethod NMTOKEN #REQUIRED | DelivToRef NMTOKEN #REQUIRED |
| DelivReqNetLocn CDATA #REQUIRED | SecDelivReqNetLocn CDATA #REQUIRED |
Атрибуты:
| xml:lang | Определяет язык, используемый атрибутами компонента. Смотри раздел 3.8. |
| OkFrom | Дата и время в формате [UTC] после которого Агент доставки может принять на обработку блок запроса доставки (смотри раздел 8.10). |
| OkTo | Дата и время в формате [UTC], до которого Агент доставки может принять на обработку блок запроса доставки. |
| DelivMethod |
Индицирует метод, с помощью которого могут быть доставлены товары или предоставлены услуги. Корректными считаются значения: о Post. Товары будут доставлены по почте или курьером. o Web. Товары будут доставлены электронным образом в комоненте Delivery Note. o Email. Товары будут доставлены электронным образом через e-mail |
| DelivToRef | Ссылка элемента (смотри раздел 3.4) компонента Organisation транзакции IOTP, которая имеет роль DelivTo. Информация в этом блоке используется, чтобы определить, куда следует доставить покупку. Она должна быть совместимой с DelivMethod. В частности, если DelivMethod является: о Post, тогда здесь должен быть элемент почтового адреса, содержащий достаточно информации для доставки по почте, o Web, тогда не нужны никакие специфические требования. Информация будет послана на web-страницу Покупателя, o Email, тогда здесь должен быть элемент контактной информации с корректным адресом e-mail. |
| DelivReqNetLocn | Содержит сетевую позицию, куда должен быть послан небезопасный блок запроса доставки (смотри раздел 8.10), который содержит компонент доставки. Содержимое этого атрибута зависит от транспортного механизма и должно согласовываться с требованиями документа [RFC-1738]. |
| SecDelivReqNetLocn | Содержит сетевую позицию, куда должен быть послан безопасный блок запроса доставки (смотри раздел 8.10), который содержит компонент доставки. |
Безопасный запрос доставки предполагает использование безопасного канала, такого как [SSL/TLS] для того чтобы взаимодействовать с кассиром.
Содержимое этого атрибута зависит от транспортного механизма и должно соответствовать регламентациям документа [RFC1738]. Смотри также раздел 3.9.
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Дополнительная информация о доставке в виде одного или несколько элементов Packaged Content (смотри раздел 3.7), предоставляемая агенту доставки продавцу. |
Информационный компонент доставки покупателя используется покупателем для спецификации идентификатора, который может быть использован им для идентификации доставки. Его определение приведено ниже:
<!ELEMENT ConsumerDeliveryData EMPTY>
<!ATTLIST ConsumerDeliveryData ID ID #REQUIRED
ConsumerDeliveryId CDATA #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет информационный компонент доставки покупателя для данной транзакции. |
| ConsumerDeliveryId | Идентификатор, специфицированный покупателем, который в случае возврата агентом доставки позволяет покупателю идентифицировать процедуру доставки. |
Компонент Delivery Note (накладная)содержит инструкции о доставке товаров или услу, или саму информацию о доставке. Это информация, которую частное лицо или организация, получающие накладную, могут использовать, когда осуществляется доставка.
Для совместимости компонент Delivery Note должен поддерживать Plain Text, HTML и XML. Его определение представлено ниже.
<!ELEMENT DeliveryNote (PackagedContent+) >
| <!ATTLIST DeliveryNote ID ID #REQUIRED | xml:lang NMTOKEN #REQUIRED |
| DelivHandlerDelivId CDATA #IMPLIED | ContentSoftwareId CDATA #IMPLIED> |
| ID | Идентификатор, который однозначно определяет компонент Delivery Note транзакции IOTP. |
| xml:lang | Определяет язык, используемый атрибутами или дочерними элементами в рамках данного компонента, если только его значение не будет переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8. |
| DelivHandlerDelivId | Опционный идентификатор, специфицированный Агентом доставки, который в случае возвращения Покупателем в другом компоненте доставки или каким-либо другим способом, позволяет Агенту доставки определить, о какой доставке идет речь. Он необходим для любого компонента доставки, вне зависимости от того содержится ли от в блоке запроса доставки. |
| ContentSoftwareId | Смотри раздел 14. Словарь. |
| PackagedContent | Содержит информацию декларации доставки (delivery note) в виде одного или нескольких элементов Packaged Content (смотри раздел 3.7). |
7.16. Компонент Status
Компонент Status содержит информацию состояния бизнес-процесса (успех или неудача) (смотри раздел 4.2). Его определение приведено ниже.
<!ELEMENT Status EMPTY >
| <!ATTLIST Status ID ID #REQUIRED | xml:lang NMTOKEN #REQUIRED |
| StatusType NMTOKEN #REQUIRED | ElRef NMTOKEN #IMPLIED |
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIEDStatusDesc CDATA #IMPLIED >
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент Status транзакции IOTP. |
| xml:lang | Определяет язык, используемый атрибутами в пределах компонента. Смотри раздел 3.8. |
| StatusType | Индицирует тип обмена документами, о котором сообщает компонент Status. Он может быть установлен в состояние предложение, платеж, доставка, аутентификация или “неопределено” (Undefined). |
| ElRef | Если StatusType не установлено равным Undefined
(неопределено), тогда ElRef содержит ссылку элемента (смотри раздел 3.5) на компонент, для которого описан Status. Он может относиться к: о компоненту Order (смотри раздел 7.5), если StatusType = Offer, o компоненту Payment (смотри раздел 7.9), если StatusType = Payment, o компоненту Delivery (смотри раздел 7.13), если StatusType = Delivery; o компоненту запрос аутентификации (смотри раздел 7.2), если StatusType = Authentication. |
| ProcessState | Содержит код состояния (State Code), который индицирует текущее состояние исполняемого процесса. Допустимыми значениями ProcessState являются: о NotYetStarted. Получен блок Request, но процесс еще не начат; o InProgress. Обработка блока Request начата, но еще не завершена; o CompletedOk. Обработка блока Request успешно завершена; o Failed. Обработка блока Request не прошла из-за рабочей ошибки (Business Error) (смотри раздел 4.2) o ProcessError. Это значение применяется, только когда компонент Status используется в связис торговым блоком информационного запроса (смотри раздел 8.12). Оно указывает, что была техническая ошибка (смотри раздел 4.1) в блоке запроса, который обрабатывается, тди другая внутренняя ошибка обработки. |
Заметим, что этот код сообщает об обработке блока запроса. Далее, после посылки блока отклика, сопряженного с процессом, может осуществляться асинхронная обработка.
| CompletionCode | Индицирует то, как завершился процесс. Корректные значения CompletionCode приведены ниже вместе с указанием условий, когда атрибут должен присутствовать и указанием возможности восстановления при неудаче. |
| ProcessReference | Этот опционный атрибут хранит ссылку для процесса, о состоянии которого сообщается. Он может содержать следующие значения: о когда StatusType = Offer, он должен содержать OrderIdentifier компонента Order; o когда StatusType = Payment, он должен содержать PaymentHandlerPayId компонентаданных о схеме платежа; o когда StatusType = Delivery, он должен содержать DelivHandlerDelivId компонента Delivery Note; o когда StatusType = Authentication, он должен содержать AuthenticationId компонента запроса аутентификации. |
Этот атрибут может быть использован внутри блока информационного отклика (смотри раздел 8.13), для того чтобы предоставить код ссылки для транзакции, которя ранее была недоступна.
Например, код упаковки может быть не присвоен в момент получения отклика доставки. Однако, если покупатель поздее выдаст запрос состояния транзакции, Агент доставки может проставить код упаковки в атрибут сообщения информационного отклика и послать его Покупателю.
| StatusDesc | Опционное текстовое описание текущего состояния процесса на языке, заданном атрибутом xml:lang. |
Код завершения является единственно необходимым, если атрибут ProcessState = Failed (неудача). Ниже следующая таблица содержит допустимые значения CompletionCode, которые могут использоваться и индицировать, возможно ли восстановление процесса. Рекомендуется, чтобы там, где это необходимо для дальнейшего разъяснения, использовался атрибут StatusDesc.
| Значение | Описание |
| AuthError | Ошибка аутентификации. Проверка отклика аутентификации не прошла. |
| ConsCancelled | Прервано покупателем (Consumer Cancelled). Покупатель по каким-то причинам решает прервать транзакцию. Это код является единственно верным в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно. |
| MerchCancelled | Предложение аннулировано (Offer Cancelled). Продавец по каким-то причинам аннулирует свое предложение и прерывает транзакцию. Этот код является единственно верным в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно. |
| Unspecified | Неспецифицированная ошибка. Возникла какая-то неизвестная проблема или ошибка, которая не соответствует ни однму из кодов CompletionCodes. Восстановление невозможно. |
| TimedOutRcvr | Восстановимый таймаут (Recoverable Time Out). Сообщения были посланы, а откликов не получено. Документальный обмен прерван таймаутом. Этот код допустим в случае информационного запроса транзакции. |
| TimedOutNoRcvr | Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были посланы повторно, а откликов не получено. Документальный обмен прерван таймаутом. Этот код допустим в случае информационного запроса транзакции. Восстановление невозможно. |
CompletionCode необходим, если атрибут ProcessState = Failed. Ниже следующая таблица содержит допустимые значения CompletionCode, которые могут использоваться и индицировать, когда возможно восстановление. Рекомендуется, чтобы атрибут StatusDesc использовался индивидуальными платежными схемами для предоставления дальнейших пояснений, там где это уместно.
| Значение | Описание |
| BrandNotSupp | Вид платежа не поддерживается Кассиром. |
| CurrNotSupp | Валюта не поддерживается. Валюта, в которой выполнен платеж, не поддерживается платежным инструментом или кассиром. |
| ConsCancelled | Отмена Покупателем (Consumer Cancelled). Покупатель по какой-либо причине решил аннулировать платеж. Этот код является единственно верным в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно. |
| PaymtCancelled | Платеж аннулирован (Payment Cancelled). Кассир по каким-то причинам не хочет завершить платежную операцию и аннулирует транзакцию. Этот код является единственно верным в компоненте Status, содержащегося в блоках Cancel или информационного отклика. Опции восстановления смотри ниже. |
| AuthError | Ошибка аутентификации. Аутентификационная проверка платежной схемы не прошла. Восстановление возможно. Чтобы определить, что допустимо, смотри приложение по платежным схемам. |
| InsuffFunds | Нехватает средств. Средств для осуществления платежа недостаточно. Опции восстановления смотри ниже. |
| InstBrandInvalid | Платежный инструмент не приемлем для данного вида платежа. Использован платежный инструмент, который не соответствует выбранному виду платжа. Например, использована кредитная карта Visa, хотя в качестве вида платежа была выбрана MasterCard. Опции восстановления смотри ниже. |
| InstNotValid | Платежный инструмент не приемлем для сделки. Платежный инструмент по каким-то причинам не может быть использован для предлагаемого вида сделки. Опции восстановления смотри ниже. |
| BadInstrument | Плохой инструмент. Имеется проблема с использованным платежным инструментом, что означает, что он не может быть применен для платежа. Опции восстановления смотри ниже. |
| Unspecified | Неспецифицированная ошибка. Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Атрибут StatusDesc должен предоставить объяснение причины. Опции восстановления смотри ниже. |
| TimedOutRcvr | Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение другой торговой роли получено снова. |
| TimedOutNoRcvr | Невосстановимый таймаут. Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно. |
Восстановление прооцедуры платежа при покупках, зависящих от вида платежа возможно только в случае, если компонент выбора вида платежа, посланный продавцом покупателю, не изменился. На практике это означает, что должны использоваться тот же элемент вида платежа, платежный протокол и сумма. Единтвенно что можно изменить – это платежный инструмент. Любые другие изменения будут неприемлемы.
7.16.3. Коды завершения доставки
Платежный обмен
Рисунок .3. Платежный обмен
Платежный обмен использует следующие торговые компоненты, которыми обмениваются покупатель, продавец и кассир: Компонент списка типов платежей содержит перечень допустимых видов платежа (например, MasterCard, Visa, Mondex, GeldKarte), платежные протоколы (например, SET Version 1.0, SCCD (Secure Channel Credit Debit – имя, используемое для платежей через кредитные карточки, где неавторизованный доступ блокируется с помощью механизма формирования безопасного транспортного канала, такого как SSL/TLS), а также сумма и вид валюты. Продавец посылает список типов платежей покупателю. Покупатель сравнивает типы платежей, протоколы, тип валюты и сумму со своими возможностями и делает выбор. Компонент выбора типа платежа содержит выбор покупателя. Тип платежа, протокол, вид валюты, сумма и возможно протокольно зависимая информация посылается продавцу. Эта информация используется для модификации данных предложения (Offer Exchange). Например, продавец может предложить скидку, с тем, чтобы стимулировать использование карточки накопления (store card). Компонент Статус используется, чтобы проинформировать кассира, что обмен предложения успешно завершился, и кассиром для сообщения о благополучном завершении платежного обмена. Компоненты Организаций генерируются Продавцом. Они содержат детали ролей Продавца и Кассира:
| - Роль продавца необходима для того, чтобы Кассир мог идентифицировать, какой продавец инициализировал платеж. Обычно, результатом платежа, реализованного кассиром в пользу продавца, является кредитная или дебитная операция, выполненная со счетом продавца. Эти операции находятся за пределами области действия IOTP | |
| - Роль кассира необходима, чтобы продавец мог проверить, что платежную операцию произвел именно тот Кассир, который нужно. |
Заметим, что компоненты списка типов платежа (Brand List) и выбор типа платежа (Brand Selection) не подписываются до тех пор, пока платежные данные не сформированы (шаг 4 на диаграмме). Компонент данные о торговых ролях (Trading Role Data) содержит информацию о других ролях (например, продавца), о которых нужно проинформировать кассира. Компонент схема платежа (Payment Scheme) содержит сообщения платежного протокола, используемого при сделке. Например, это могут быть сообщения SET, сообщения Mondex, сообщения GeldKarte или какого-то другого метода платежа, поддерживаемого IOTP. Содержимое компонента схема платежа (Payment Scheme) определено в приложениях, которые описывают то, как работает IOTP с различными платежными протоколами. Компонент платежной расписки (Payment Receipt) содержит запись о платеже. Содержимое зависит от используемого платежного протокола. Компонент подпись платежной расписки (Payment Receipt) предоставляет подтверждение корректности платежа путем цифровой подписи компонентов платежной расписки и подписи отклика-предложения. Подпись предложения гарантирует целостность и корректность компонентов заказа, организаций, и доставки, содержащихся в предложении. Эта подпись соединяет платеж и предложение. Пример платежного обмена представленного выше, является наиболее общим случаем. Возможны и более простые варианты. Например, если сумма платежа не зависит от выбранного типа платежа и платежного протокола, тогда информация, генерируемая на этапе 3, может быть послана покупателю одновременно с формированием компонента список типов платежей (Brand List) на этапе 1. Эти и другие вариации описаны в разделе базовые торговые операции IOTP (смотри раздел 9.1.8).
2.2.3. Обмен доставки
Целью обмена доставки является обеспечить физическую или сетевую доставку купленного товара или услуги покупателю. Второй целью служит передача покупателю “декларации о доставке”, предоставляя дополнительную информацию о доставке, такую как номера накладной или номер трайлера, с помощью которого будет доставлен груз.
Результат доставки может быть также подтвержден с помощью электронной подписи. Обмен сообщениями показан на диаграмме ниже.
| 1. | Покупатель решает осуществить сделку и посылает информацию продавцу о том, что нужно доставить и как это лучше сделать. |
| C a M | Информация о том, что следует доставить (вне зоны ответственности IOTP) |
| 2. | Продавец проверяет информацию, полученную от покупателя, добавляет информацию о том, как будет осуществляться доставка, информацию об организациях, вовлеченных в доставку и, опционно, электронную подпись, после чего отправляет все это покупателю. |
| C ? M | Компоненты: lоставка; jрганизации (fгент доставки, доставит туда-то); заказ, опционная подпись отклика-предложения |
| 3. | Покупатель проверяет, корректна ли доставочная информация, получает разрешение на доставку, например путем оплаты, и посылает эти данные агенту доставки. |
| C a D | Запрос доставки. Компоненты: cтатус; доставка, организации: (продавец, агент доставки, DelivTo); Заказ, данные о торговой роли (опционны); опционная подпись отклика-предложения, опционная подпись платежной расписки (из платежного обмена) |
| 4. | Агент доставки проверяет информацию и авторизацию. Запускает или диспетчеризует доставку, а также готовит и отправляет накладную покупателю, которая опционно может быть подписана. |
| C ? D | Отклик доставки. Компоненты: статус; накладная (Delivery Note), данные о торговой роли (опционны); опционная подпись отклика доставки |
| 5. | Покупатель проверяет накладную и принимает товар или ждет доставки, как это указано в накладной (Delivery Note). |
Подписи при обмене ценностями
Рисунок .30. Подписи при обмене ценностями
9.1.12. Допустимые комбинации документальных обменов
Диаграмма на Рисунок .31. иллюстрирует информационные условия в различных IOTP-сообщениях, которые могут быть использованы покупателем, чтобы определить допустима или нет конкретная комбинация документальных обменов.
Получение логотипов
10. Получение логотипов
Ниже описано, как извлекать логотипы для отображения их программой IOTP, используя атрибут Logo Net Locations, содержащийся в элементе вида платежа (смотри раздел 7.7.1) и компоненте Organisation (смотри раздел 7.6). Полный адрес логотипа определяется следующим образом: Logo_address ::= Logo_net_location "/" Logo_size Logo_color_depth ".gif"
Где:
Logo_net_location получено из атрибута LogoNetLocn элемента вида платежа (смотри раздел 7.7.1) или компонента Organisation. Заметим, что: - содержимое этого атрибута зависит от используемого транспортного механизма (такого как HTTP). - разработчики должны проверить, что если самый правый символ в Logo Net Location представляет собой "/", тогда другой такой же символ не должен включаться в запись адреса логотипа Logo_size идентифицирует размер логотипа, Logo_color_depth идентифицирует насыщенность цвета логотипа; "gif" идентифицирует, что логотип имеет формат "gif" .Logo_size и Logo_color_depth специфицирует разработчик программы IOTP, которая извлекает логотип, в зависимости от размера и цвета, который желательно иметь.
10.1. Размер Logo
Имеется пять стандартных рамеров логотипа. Размеры в пикселях соответствуют в таблице значениям размера логотипа.
| Размер в пикселях | Размер логотипа значение |
| 32 x 32 или 32 x 20 |
exsmall (сверх малый) |
| 53 x 33 | small (малый) |
| 103 x 65 | medium (средний) |
| 180 x 114 | large (большой) |
| 263 x 166 | exlarge (сверх большой) |
10.2. Насыщенность цвета логотипа
Существует три стандартных значения насыщенности цвета. Насыщенность цвета (включая число бит на пиксель) и соответствующее значение для Logo_Color_Depth представленны ниже в таблице.
| Насыщенность цвета | Цвет логотипа |
| (бит на пиксель) | Значение насыщенности |
| 4 (16 цветов) | 4 |
| 8 (256 цветов) | ничего |
| 24 (16 миллионов цветов) | 24 |
Заметим, что если насыщенность цвета логотипа пропущена, тогда извлекается логотип с 256 цветами.
10.3. Примеры логотипа для сетевой позиции
Если логотип сетевой позиции равен "ftp://logos.xzpay.com", тогда:
"ftp://logos.xzpay.com/medium.gif" извлечет логотип среднего размера с 256 цветами "http://logos.xzpay.com/small4.gif" извлечет логотип малого размера с 16 цветамиОрганизации, которые делают логотип доступными для работы с IOTP должны всегда допускать размеры "small" и "medium" и использовать формат "gif".
Предложение
Рисунок .2. Предложение
Предложение использует следующие торговые компоненты, которые пересылается между покупателем и продавцом. Компонет статус используется для сообщения партнеру что сформирован корректный отзыв-предложение. Компоненты Организации содержит информацию, которая описывает организации, исполняющие определенные торговые роли в данной сделке.
| Покупатель предоставляет информацию о том, кто он и, если товар или услуги доставлены, место, куда они доставлены. | |
| Продавец дополняет эту информацию данными о себе, о Кассире, Агенте обслуживания Покупателя и, если товар или услуга должна быть доставлена, то и об агенте доставки. |
| o | Компонент Заказа (Order Component) содержит описания товаров или услуг, предмет сделки, если покупателя устроит соглашение. Эта информация посылается Продавцом покупателю. |
| o | Компонент оплаты (Payment Component), генерируемый продавцом, содержит детали того сколько надо платить, в какой валюте и кто должен платить кому, например покупатель может попросить вернуть деньги. Заметим, что число платежей в сделке может быть больше одного. |
| o | Компонент Доставки (Delivery Component), также генерируемый продавцом, используется, если товары или услуги требуют доставки. Он содержит информацию о том, как будет осуществляться доставка, например с помощью обычной или электронной почты. |
| o | Компонент данных о торговых ролях содержит информацию, которую продавец хочет довести до сведения другой торговой роли, такой как Кассир или Агент доставки. |
| o | Компонент подпись "отклика на предложение", если присутствует, подписывает все выше перечисленные компоненты с целью гарантии их целостности. |
Точное содержание информации, выданной Продавцом Покупателю, варьируется в зависимости от типа операции IOTP. Например:
низкая стоимость сделки может не требовать подписи сумма оплаты может варьироваться в зависимости от фирмы и используемого протокола оплаты некоторые предложения могут не включать в себя доставку товара обмен ценностями включает два платежа продавец может не предлагать покупателю каких-либо услуг.Информация, предоставляемая покупателем продавцу, предоставляется различными способами, например, она может быть получена.
Используя [HTML] страницы, как часть "практики" покупателей. Используя стандарт OPS (Open Profiling Standard), который был недавно предложен, В форме компонентов Организации, ассоциирующихся с аутентификацией Покупателя Продавцом. Как компоненты Заказа в последней версии IOTP. 2.2.2. Платежный обмен
Целью платежного обмена (Payment Exchange) является оплата, производимая покупателем еассиру или наоборот, используя вид и протокол платежа, выбранные покупателем. Второй целью является опционное обеспечение покупателя платежной распиской (Payment Receipt), которая может использоваться для связи платежа с его причиной, как это описано в обмене предложения (Offer Exchange).
Обмены платежа могут реализовываться различными способами. Наиболее общий случай, где сделка зависит от типа и платежного протокола, показан на диаграмме Рисунок .3. Возможны и более простые платежные обмены.
| 1. | Покупатель решает что-то купить и посылает информацию об этой операции (запрос предложения) Продавцу, напр., используя HTML. |
| C a M | Информация о том, что покупается (вне рамок стандарта IOTP) |
| 2. | Продавец решает, какой тип и протокол платежа следует предложить, записывает эти данные в компонент Brand List и посылает покупателю. |
| C ? M | Компоненты: список типов платежей (Brand List) |
| 3. | Покупатель выбирает тип платежа, протокол и вид валюты, формирует компонент выбор типа и посылает его продавцу. |
| C a M | Компонент: Выбор из списка типов платежа (Brand List Selection) |
| 4. | Продавец проверяет выбор типа, определяет сумму платежа, опционно подписывает документ и посылает его Покупателю. |
| C ? M | Компонент: Платеж; Организации (продавец и кассир); опционная подпись отклика-предложения, которая подтверждает другие компоненты. |
| 5. | Покупатель проверяет объявленную сумму платежа и, если согласен, посылает запрос кассиру. |
| C a P | ЗАПРОС ПЛАТЕЖА. Компоненты: Статус, Платеж; Организации (продавец и Кассир); Информация о торговых ролях (опционно); опционная подпись отклика-предложения, которая подтверждает все прочие компоненты. Данные о схеме платежа. |
| 6. | Кассир проверяет информацию, включая опционную подпись и, если все в порядке, начинает обмен компонентами данных по схеме платежа с целью выбора типа и протокола платежа. |
| C « P | ПЛАТЕЖНЫЙ ОБМЕН. Компонент: Данные о схеме платежа |
| 7. | Как только обмен протокольными платежными сообщениями завершится, Кассир посылает Покупателю платежную расписку, которая опционно подписывается, с целью подтверждения платежа. |
| C « P | ОТКЛИК на ПЛАТЕЖ. Компоненты: Статус, платежная расписка; платежное заявление; данные о торговых ролях (опционно); опционная подпись отклика-предложения; опционная подпись платежной расписки, которая связывает платеж и предложение |
| 8. | Покупатель проверяет платежную расписку |
фрагментации пакета
Рисунок 4.1.1.3.6. Пример фрагментации пакета
Куда будет направлен Ethernet-кадр, указывает значение для типа в заголовке кадра (Рисунок 4.1.1.3.5). Если IP-пакет попадает в модуль IP, то содержащиеся в нем данные могут быть переданы либо модулю TCP (Transmission Control Protocol), либо UDP, что определяется полем "протокол" в заголовке IP-пакета.
Одним из основополагающих понятий в теории маршрутизации является автономная система (AS). Автономную систему составляет IP-сеть (или система из нескольких IP-сетей), проводящая единую политику внешней маршрутизации и имеющая одного или более операторов. Все AS имеют уникальные номера. Идеология AS позволяет решить проблему безудержного роста размера таблиц маршрутизации. Построение узла Интернет неотделимо от формирования локальной сети, поэтому прежде чем перейти к углубленному описанию протоколов TCP/IP, введем определения некоторых сетевых устройств, без которых построение локальной сети невозможно.
использование подписи при покупке
Рисунок .11. Пример использование подписи при покупке
6.1.2. Элементы OriginatorInfo и RecipientInfo
Атрибут OriginatorRef элемента OriginatorInfo в компоненте подписи содержит ссылку на элемент (смотри раздел 3.5), которая указывает на комполнент организации, сгенерировавшей подпись. В данном примере это продавец.
Заметим, что значение элемента атрибута с атрибутом типа, устанавленным равным типу подписи IOTP, должно соответствовать торговой роли организации, которая его подписала. Если это не так, возникает ошибка. Корректные значения представлены ниже в таблице.
Тип подписи IOTP |
Корректная торговая роль |
| OfferResponse | Продавец |
| PaymentResponse | Кассир |
| DeliveryResponse | Агент доставки |
| AuthenticationRequest | Любая роль |
| AuthenticationResponse | Любая роль |
| PingRequest | Любая роль |
| PingResponse | Любая роль |
Атрибут RecipientRefs элемента RecipientInfo в компоненте подписи содержит ссылки элементов на компоненты организации, которая должна использовать подпись, чтобы проверить:
| о | они имеют отношение к организации, генерировавшей подпись, |
| о | данные, защищенные подписью, не были изменены, |
| о | данные были подписаны корректно |
| о | действия, которые нужно предпринять для продавца авторизованы. |
Заметим, что, если используется симметричная криптография, отдельные элементы RecipientInfo и Value для каждого набора общих секретных ключей размещаются в компоненте Signature. В противном случае, если используется асимметричная криптография, атрибут RecpientRefs одного элемента RecipientInfo может относиться к нескольким компонентам Organisation, если они все используют один и тот же сертификат.
6.1.3. Использование подписей для подтверждения корректного завершения операций
Проверка успешного завершения операции осуществляется с помощью подписи данных сообщений-откликов. В частности:
для отклика предложения, когда продавец делает предложение Покупателю, котоорое может быть затем послано:| - Кассиру, чтобы проверить, что продавец авторизует платеж; | |
| - Агенту доставки, чтобы проверить, что продавец авторизует доставку. |
Для платежного отклика, когда Кассир генерирует платежную расписку, которая может быть послана:
| - Агенту доставки, в блоке запроса доставки для авторизации доставки вместе с подписью отклика предложения, или | |
| - другому кассиру во втором платежном запросе, чтобы авторизовать второй платеж в транзакции обмена ценностями. |
Отклик доставки, когда Агент доставки генерирует накладную (Delivery Note). Это может быть использовано, чтобы проверить по завершении, что все сделано так как надо. Отклик доставки. Один метод аутентификации партнера по сделке заключается в посылке запроса аутентификации, где определено, что эта процедура предсматривает использование электронной подписи. Запрос состояния транзакции. Блок отклика информационного запроса может быть снабжен цифровой подписью, чтобы удостоверить аутентичность отклика. Ping. Отклик Ping может быть подписан, чтобы иметь возможность проверки распознаваемости подписи. 6.2. Проверка корректности вычисления подписи
Проверка корректности вычисления электронной подписи является частью проверки ошибок уровня сообщения (смотри раздел 4.3.2).
Прежде чем торговая роль сможет проверить подпись, она должна идентифицировать, какой из элементов подписи следует проверить. При этом производятся следующие действия:
проверка того, что блок подписи присутствует и содержит один или более компонентов подписи; идентификация компонента Organisation, который содержит OrgID-атрибут организации, осуществляющей проверку. Если не найдено ни одного компонента организации или обнаружено более одного такого компонента, фиксируется ошибка; использование ID-атрибута компонента организации, чтобы найти элемент RecipientInfo, который содержит атрибут RecipientRefs, имеющий отношение к компоненту Organisation. Заметим, что может не быть подписи и по этой причине нечего проверять. проверка компонента Signature, который содержит идентифицированный элемент RecipientInfo в виде:
| - используются атрибуты SignatureValueRef и SignatureAlgorithmRef, чтобы идентифицировать, соответственно: элемент Value, который содержит подпись, подлежащую проверке и элемент алгоритма подписи, который характеризует алгоритм вычисления подписи, предназначенный для ее верификации, затем | |
| - если элемент алгоритма подписи указывает, что использована асимметричная криптография, тогда для идентификации сертификата применяется SignatureCertRef; | |
| - если элемент алгоритма подписи указывает, что использована симметричная криптография, тогда для идентификации корректного значения общего ключа используется содержимое элемента RecipientInfo; | |
| - используется специфицированный алгоритм подписи для проверки того, что элемент Value правильно подписывает элемент Manifest; | |
| - проверется, что элементы Digest в элементе Manifest вычислены правильно. При этом предполагается, что компоненты или блоки, на которые ссылается дайджест, были получены организацией, выполняющей проверку подписи. |
6.3. Проверка платежа или доставки
Далее описываются процессы, необходимые для кассира или агента доставки, чтобы проверить возможность выполнения платежа или доставки. Это может включать проверку подписей, если она специфицирована продавцом.
При этом осуществляются следующие шаги:
проверка того, что платежный запрос или запрос доставки посланы правильной организацией; проверка того, что в запросе представлены правильные компоненты IOTP; проверка того, что платеж или доставка авторизованы. В данном разделе используются следующие термины:
"Блок запроса" используется в связи с блоком запроса платежа (смотри раздел 8.7) или блоком запроса доставки (смотри раздел 8.10), если не специфицировано обратного; "Блок отклика" используется в связи с блоком платежного отклика (смотри раздел 8.9) или блоком отклика доставки (смотри раздел 8.11); "Операция" используется в связи с операцией, которая реализуется при получении блока запроса. Операцией может быть платеж или доставка; "Операционная организация" используется в отношении Кассира или Агента доставки, которые реализуют операцию; "Подписант операции" используется в отношении организации, которая подписаладанные об операции с целью ее авторизации; "Верификатор операции" используется в отношении организаций, которые верифицируют данные, чтобы определить, авторизованы ли они для выполнения операции; атрибут ActionOrgRef содержит ссылки элемента, которые могут быть использованы для идентификации "Операционной организации", которая должна выполнить операцию. 6.3.1. Проверка того, что блок запроса послан правильной организацией
Проверка того, послан ли блок запроса правильной организации, варьируется в зависимости от того платеж это или доставка.
6.3.1.1. Платеж
Кассир проверяет, может ли он принять или выполнить платеж путем идентификации компоненты платежа в полученном им блоке платежного запроса. Затем, используя ID плетежного компонента для идентификации организации, выбранной Покупателем, проверяет, что это та самая организация.Метод доступа к данным для решения поставленных задач проиллюстрирован на Рисунок .12.
использования ID-атрибутов
Рисунок .8. Пример использования ID-атрибутов
3.5. Элемент References
Торговый компонент или один из его дочерних XML элементов может содержать XML-атрибут, который указывает на другой блок (т.e. Блок ссылок транзакции или торговый блок) или торговый компонент (включая идентификатор транзакции и компонент подписи). Эти ссылки элементов используются для многих целей, ниже предлагается несколько примеров:
Идентификация элементов XML, чей дайджест включен в компонент подписи. Указание на компонент организации кассира, который используется при платеже.Элементы Reference всегда содержат значение ID-атрибута блокаили компонента. Идентификация сообщения IOTP, торговогоблока или торгового компонента, на который указывает ссылка элемента, включает в себя наождение XML-элемента, который:
Принадлежит той же самой IOTP-транзакции (т.e. Id-компонет транзакции и IOTP-сообщения совпадают). Имеет значение ID-атрибута элемента соответствующее значению ссылки элемента.Термин "соответствует" в данной спецификации имеет то же определение, что и в [XML]. Пример "соответствия" ссылки элемента показан ниже.
