Краткое содержание «Техника сетевых атак»
жүктеу/скачать 4.21 Mb.
|
- Бұл бет үшін навигация:
- Протоколы telnet и rlogin (глава для профессионалов)
- Врезка «замечание»
- Врезка «информация» *
- Врезка «алгоритм Нагла» *
Протоколы Internet
“…документация подобна сексу: просто великолепно, когда она хороша; но если даже она несовершенна, то это все же лучше, чем ничего.” Дик Брандон В основе межсетевого общения лежат протоколы – соглашения, выполняемые сервером и клиентом. А сетевые атаки, в свою очередь, базируются либо на ошибках реализаций протоколов, либо используют уязвимости самих протоколов. В главах «Атака на Windows NT» и «Атака на Windows 95» уже упоминался прикладной протокол SMB, слабости реализации которого позволяют злоумышленнику подбирать пароль для входа в систему, устанавливать подложный именной канал и т.д. Реализации других протоколов также порой далеки от совершенства и часто позволяют злоумышленнику выполнять действия никак не запланированные ни разработчиками, ни администратором системы. Следует различать понятия «протокола» от «реализации протокола». Сам протокол – это только набор соглашений, правил и договоренностей, записанный на бумаге184. Реализация протокола – «живая» действующая программа, со всеми присущими ей программными ошибками. Ошибкам подвержены как сами протоколы, так и их реализации (причем реализации гораздо чаще). Но ошибки реализации устраняются программными заплатками, а недостаток защищенности протокола можно рассматривать как концептуальную уязвимость. Например, UDP протокол работает без установки соединения и не гарантирует, что полученный пакет был действительно отправлен отправителем, а не кем-то еще, кто вздумал подделать его адрес. Это создает возможность внедрения ложных объектов в сеть, и часто приводит к успешным атакам. Собственно, незащищенность UDP протокола еще не повод объявлять этот протокол «плохим», ведь ничто не хорошо и не плохо само по себе. А вот бездумное применение UDP протокола, в ответственных ситуациях, чувствительных к подделке адреса отправителя – плохо, ибо приводит к уязвимости. Так, DNS сервер, работающий на UDP протоколе, позволяет злоумышленнику отправлять ответы от имени DNS, и программное обеспечение жертвы вместо соединения с положенным сервером, неожиданно (и незаметно!) для нее подключается к машине злоумышленника! И жертва, не подозревая подлога, доверчиво передаст свой пароль на «вражеский» узел! Другой пример: протокол SMTP не требует авторизации и позволяет злоумышленнику рассылать письма, используя чужие сервера. Исправление этой очевидной ошибки (хотя при разработке протокола она не была такой очевидной, ведь в то время спамеров еще не существовало) оказалось сопряжено со значительными трудностями. Устранение недостатков протоколов автоматически не исправляет существующее программное обеспечение! Любой мало-мальски популярный протокол может иметь многие тысячи реализаций серверных и клиентских приложений, созданных различными, никем не координированными, разработчиками. Нужны очень веские доводы, чтобы склонить всех разработчиков, администраторов и пользователей перейти на новый стандарт. Даже если он имеет неоспоримые преимущества, его внедрение может растянуться на несколько лет. Но появление новых протоколов не приводит к полному отказу от старых, и они мирно уживаются рядом друг с другом. Ниже будут подробно рассмотрены наиболее популярные протоколы, и описаны некоторые ошибки их реализаций. В большинстве книг изложение традиционно начинается с изучения транспортных протоколов, а затем переходят к прикладным. Но такой подход имеет, по крайней мере, один существенный недостаток: читатель в первых главах не может «пощупать» предмет изучения и должен довольствоваться сухой теорией. Напротив, работу прикладных протоколов легко продемонстрировать простыми экспериментами. Поэтому, в этой книге предпринята попытка изложить весь материал в обратном направлении – от прикладных протоколов вглубь к транспортным. Книга рассчитана на неподготовленного читателя, поэтому, помимо обсуждения уязвимости протоколов и их конкретных реализаций, в общих чертах описывается и сам протокол. Протоколы telnet и rlogin (глава для профессионалов)
Врезка «замечание»Понимание протокола telnet не обязательно для усвоения всего остального материла, но может потребоваться при расшифровке перехваченных telnet сессией, а также понадобится при написании собственных telnet клиентов и серверов. В остальных случаях эту главу можно без ущерба пропустить. Протокол telnet один из старейших в сети. Он разрабатывался в конце шестидесятых годов, когда слово “Internet” еще не существовало, а кабель, соединяющий несколько узлов, гордо именовался «сетью ARPANET». Тогда telnet составлял основу сети, и относился к фундаментальным протоколам – большинство узлов общались друг с другом именно посредством telnet. Со временем его вытеснили новые специализированные протоколы, и он потерял свою главенствующую роль. Сегодня telnet используется практически только для удаленного администрирования UNIX-серверов. Telnet – прикладной протокол, реализуемый поверх транспортного TCP протокола. Он обеспечивает дуплексный, 8 битный канал между участниками соединения и поддерживает виртуальные терминалы. По умолчанию для подключения к telnet серверу необходимо установить соединение по 23 порту. Врезка «информация» *Виртуальный терминал (NVT – Network Virtual Terminal) это мнимое символьное устройство с клавиатурой и принтером. Данные, набранные на клавиатуре, отправляются серверу, а ответ сервера печатается на принтере. Под «клавиатурой» и «принтером» подразумеваются некие мнимые устройства. В действительности ответ сервера вовсе не обязательно выводить на настоящий принтер, вместо этого обычно используется экран. Виртуальный терминал позволяет согласовать форматы представления данных обеих сторон, ширину и высоту экрана и т.д. Соответствие между мнимыми и физическими устройствами узла должна обеспечить реализация протокола. Подробнее о виртуальном терминале рассказано ниже, в конце этой главы. Протокол telnet использует довольно оригинальный способ передачи команд, называемый команды в потоке (in-band signaling), заключающийся в следующем: любой байт из интервала [0x0, 0xFF)185 интерпретируется как данные, а байт 0xFF, называемый IAC (Interpret As Command – интерпретировать как команду), указывает на то, что следующий за ним байт является командным байтом. Если возникнет необходимость передать байт данных, равный 0xFF, его следует продублировать, т.е. отправить два байта 0xFF 0xFF. Командный байт может принимать следующие значения, перечисленные в таблице (необходимые объяснения даны ниже).
Многие из перечисленных в таблице команд в настоящее время вышли из употребления и поэтому представляют лишь исторических интерес, а потому рассмотрены по возможности кратко:
Для согласования дополнительных параметров используются квиточки WILL, WONT, DO, DONT. Отправитель может попросить получателя изменить требуемые опции или уведомлять его об изменении своего состояния.
Существует множество опций, подробно описанных в “Assigned Numbers RFC”, ниже для примера описаны лишь некоторые, наиболее часто употребляемые, из них.
Некоторые опции, такие, например, как тип терминала, имеют один или несколько параметров, которые передаются следующим образом: сразу за опцией следует команда Протокол telnet поддерживает четыре режима передачи данных: полудуплексный, символьный, строчечный и линейный. Полудуплексный режим в настоящее время практически вышел из употребления и используется крайне редко. Обмен данными происходит так: клиент дожидается получения команды GA от сервера и только после этого начинает передачу данных, завершаемую командой GA, после чего он готов к приему ответа сервера. Т.е. команда GA играет роль ключа, меняющие обе стороны ролями. Такая форма общения заметно ускоряет обмен (особенно на медленных каналах), но не позволяет взаимодействовать с приложениями, посимвольно обрабатывающими ввод. По стандарту клиент по умолчанию находится в полудуплексном режиме. В символьном режиме каждый посланный отправителем символ немедленно доставляется получателю. Это полноценный дуплексный режим, где сторонам нет необходимости договариваться об очередности передачи. Однако с помещением каждого символа в отдельный пакет значительно падает скорость обмена, а накладные расходы резко возрастают (практически по сети передаются одни заголовки пакетов). На быстрых каналах это может быть и не заметно, но ощутимо сказывается на загруженных линиях. Чтобы перейти в символьный режим одна из сторон должна либо попросить другую отключить у себя опцию GA, либо сделать это самостоятельно и послать другой стороне уведомление. Т.е. это может выглядеть либо так: Строчечный режим еще называемый kluge186 line mode не предусматривался разработчиками явно и фактически возник в результате ошибки. В RFC 858 декларируется, что для ввода символа за один раз с удаленным эхом, опция эхо-отображения должна быть включена, а команда GA запрещена. Если же хотя бы одно из этих условий не выполняется, telnet находится в режиме строка за один раз (т.е. строчечном). Такая ситуация может возникнуть при запросе пароля, если сервер посылает клиенту Значительно более совершенен недавно разработанный режим line mode, который устраняет недостатки всех остальных режимов, но сохраняет их достоинства. Подробно он описан в RFC 1184. Существенным достижением (относящимся к безопасности) является возможность передавать пароль на сервер в зашифрованном виде.
На практике, однако, ситуация варьируется от сервера к серверу и часто оказывается намного сложнее. Перехватить сессию связи между сервером и клиентом можно с помощью специально разработанного для этой цели Proxy сервера TCPSPY (на прилагаемом к книге диске он находится в файле /SRC/tcpspy.bat, а его исходный текст приведен в Приложении). Запустив его, необходимо указать порт удаленного сервера (23), порт локального сервера (скажем, 123) и адрес удаленного сервера (в приведенном ниже примере использовался telnet.org). Затем запустить telnet клиент (в этом примере использовался клиент, входящий в Windows 2000) и установить соединение с узлом 127.0.0.1 по выбранному порту (123). Ниже приведен протокол работы, сохраненный в файле tcpspy.log (на диске, приложенном к книге он расположен в /SRC/telnet.log)
Расшифровка перехваченной сессии выглядит следующим образом (разумеется, возможны вариации в зависимости от используемого читателем клиента и сервера).
Обращает на себя внимание тот факт, что данный сервер запрещает клиенту использовать локальное эхо. Вместо этого он самостоятельно возвращает все полученные символы, разумеется, за исключением символов пароля. Заметно, что Windows клиент (как от Windows 95, так и от Windows 2000) не поддерживает всех опций, предлагаемых ему сервером.
В сравнении с telnet, rlogin гораздо проще и не поддерживает согласования параметров, поэтому, его реализации гораздо компактнее и, как правило, устойчивее в работе. Его подробное описание вместе с исходными текстами rlogin сервера и rlogin клиента можно найти в RFC 1282. После установки соединения с rlogin сервером, rlogin клиент посылает серверу четыре строки (все строки должны заканчиваться нулем):
Сервер отвечает нулевым байтом и пытается аутентифицировать пользователя. В первую очередь анализируется файл .rhosts, содержащий список доверенных узлов и пользователей. Если адрес клиента совпадает с одним из адресов, перечисленных в этом файле, для входа на сервер вводить пароль не потребуется. В противном случае клиент должен передать серверу незашифрованную строку пароля (впрочем, последние реализации rlogin из 4.4BSD используют Kerberos для шифровки паролей, посылаемых по сети). Протокол rlogin поддерживает единственный режим общения с сервером – символьный. Для улучшения производительности и предотвращения перегрузки сети огромным числом тиниграмм используется алгоритм Нагла. Если rlogin серверу требуется передать служебную команду клиенту, он входит в режим срочности TCP и отправляет команду в последнем байте срочных данных. Клиент, получив уведомление о режиме срочности, должен читать и сохранять данные до тех пор, пока не получит командный байт (последний байт срочных данных). В зависимости от команды, сохраненные данные могут быть выведены на терминал или проигнорированы. Ниже описываются четыре командных байта.
Передача команд от клиента к серверу происходит следующим образом: клиент посылает два байта, равные 0xFF, за которыми следуют два командных байта (еще их называемых флаговыми). В настоящее время определена всего одна команда – уведомление клиентом изменения размеров окна. В этом случае два командных байта равны 0x73 0x73, за ними идут два 16 битные значения (в порядке сетевых байтов), выражающие количество символов в строке, количество символов в столбце, количество пикселей по горизонтали и количество пикселей по вертикали. Обычно два последние значения равны нулю, поскольку большинство приложений определяют размер экрана в пикселах, но не символах. Протокол rlogin не позволяет передать символ 0xFF 0xFF в потоке данных, поскольку они используются для служебных целей, но в отличие от telnet, не существует специальной команды для снятия такого ограничения. Помимо командных байтов, пересылаемых с последним байтом срочных данных, в распоряжении сервера есть и другие способы управления работой клиента. Для этого клиенту передается специальный знак «~» (тильда) в первой позиции строки, за которым следует один из четырех специальных символов:
Легко видеть, в отличие от протекла telnet, rlogin плохо и даже небрежно продуман, и очень ограничен в своих возможностях. В настоящее время он практически вышел из употребления и используется очень редко. Оба протокола работают с сетевыми виртуальными терминалами NVT, представляющими собой мнимое устройство для ввода вывода 7 битных USASCII188 символов. Однако это не означает невозможность передачи 8 битных символов, с использованием национальной кодировки. Но NVT не обеспечивает согласования принятых сервером и клиентом кодировок и не гарантирует правильность отображения национальных символов. Поддержка расширений зависит от конкретных реализаций, но, как правило, практически все telnet клиенты и сервера такие расширения поддерживают. Символы с кодами от 0 до 31 и 127 называются управляющими и имеют специальное назначение, описанное в приведенной ниже таблице:
Все остальные управляющие коды по стандарту должны игнорироваться и не влиять на работу NVT терминала. Однако множество реализаций поддерживают собственные расширения. Символы, набираемые с клавиатуры NVT-терминала, должны накапливаться в локальном буфере до завершения ввода целой строки, и только после этого они могут быть переданы получателю. В форсированном же режиме передачи каждый символ должен не задерживаясь в буфере немедленно доставляться получателю. Поддержка протоколом telnet виртуальных терминалов, позволяет приложениями взаимодействовать с удаленным клиентом точно так, как с локальным терминалом, который имеет ширину и высоту. Поэтому, протокол telnet часто используют для удаленного выполнения программ на сервере. Для этого, виртуальный терминал необходимо связать с командной оболочкой (shell), которая сможет работать с удаленным клиентом точно так, как если бы он был физически подсоединен к машине. На самом деле, возможности telnet протокола не ограничиваются удаленным выполнением программ, и он может успешно применяться и для других целей. Однако в настоящее время эти дополнительные возможности практически не используются, поскольку вытеснены другими специализированными протоколами.
жүктеу/скачать 4.21 Mb. Достарыңызбен бөлісу:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||