Что прослушивать?

Что прослушивать?

Существует много интересной информации для поиска во время наблюдения сети. В самом очевидном случае может быть перехвачена информация аутентификации (имена пользователей и пароли) и далее использована для получения доступа к ресурсу. Другие виды информации, такие как электронная почта и моментальные сообщения, также могут перехватываться. Все, что проходит через сеть, открыто глазам наблюдающего.

Получение информации аутентификации

Следующие подразделы предоставляют примеры разнообразных типов сетевого трафика, являющихся привлекательными нарушителю, ведущему прослушивание вашей сети. Подразделы упорядочены по протоколу или сервису, которому соответствует трафик, и никоим образом не представляют всеобъемлющий список.

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

Следующие разделы предоставляют краткий обзор типов информации аутентификации, которые могут быть собраны с соответствующих протоколов. Эти примеры были упрощены, и в некоторых случаях текущая версия данных протоколов поддерживает более продвинутые механизмы аутентификации, которые смягчают показанные риски. В случае общих Интернет-протоколов существуют запросы на комментарии (RFC), которые могут конкретизировать спецификации.

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

[~] % telnet localhost

Trying 127.0.0.1...

Connected to localhost.

Escape character is “^]”.

Red Hat Linux release 6.1 (Cartman)

Kernel 2.2.12-20 on an i686

login: oliver

Password: welcome

[18:10:03][redhat61]

Прослушивание FTP (порт 21) Сервис протокола передачи файла (FTP) используется для передачи файла через сеть, также посылает свою информацию аутентификации в открытом виде. В отличие от Telnet, FTP может также использоваться для разрешения анонимного доступа к файлам, посредством чего пользователь использует имя пользователя «anonymous» или «ftp» и выдает случайный пароль. Информация протокола FTP обычно спрятана дружественным интерфейсом клиента, однако лежащий в основе аутентификации трафик имеет следующий вид:

[~] % telnet localhost 21

Trying 127.0.0.1...

Connected to localhost.

Escape character is “^]”.

220 localhost FTP server (Version wu-2.5.0(1) Tue Sep 21

16:48:12 EDT 1999) ready.

USER oliver

331 Password required for oliver.

PASS welcome

Прослушивание POP (порт 110) Сервис почтового протокола (POP) является сетевым сервисом, с помощью которого клиентские программы электронной почты соединяются для доступа к электронной почте пользователя на центральном сервере. POP сервера обычно находятся в сети поставщика услуг Интернет (ISP) для осуществления доставки сообщений электронной почты клиентам. POP-трафик часто не шифруется, и информация аутентификации посылается в открытом виде. Имя пользователя и пароль передаются на удаленный сервер посредством команд USER и PASS. Пример протокола:

[~] % telnet localhost 110

Trying 127.0.0.1...

Connected to localhost.

Escape character is “^]”.

+OK POP3 localhost v7.59 server ready

USER oliver

+OK User name accepted, password please

PASS welcome

Необходимо отметить, что существуют расширения протокола POP, которые предотвращают прохождение информации аутентификации по сети в открытом виде, в дополнение к шифрованию сессии. Прослушивание IMAP (порт 143) Сервис-протокол доступа к сообщениям в сети Интернет является альтернативным протоколом сервису POP и предоставляет ту же функциональность. Как и у POP-протокола, информация аутентификации во многих случаях отправляется через сеть в открытом виде. IMAP-аутентификация производится путем отправления строки, состоящей из выбранного пользователем токена, команды LOGIN, а также имени пользователя и пароля, как показано ниже:

[~] % telnet localhost imap

Trying 127.0.0.1...

Connected to localhost.

Escape character is “^]”.

* OK localhost IMAP4rev1 v12.250 server ready

A001 LOGIN oliver welcome

Необходимо отметить, что существуют расширения протокола IMAP, которые предотвращают прохождение информации аутентификации по сети в открытом виде, в дополнение к шифрованию сессии. Прослушивание NNTP (порт 119) Сетевой протокол передачи новостей (NNTP) поддерживает чтение и написание для сообщений новостных групп Usenet. Аутентификация NNTP может проходить многими путями. В традиционных системах аутентификация базировалась на сетевом адресе клиента, разрешая доступ к серверу новостей только тем хостам (или сетям), которые находятся в указанном диапазоне адресов. Расширения NNTP были созданы для поддержки разнообразных методов аутентификации, включая открытые и шифрованные механизмы реагирования. Механизм аутентификации открытым текстом прямой и может быть с легкостью перехвачен в сети. Это выглядит следующим образом:

[~] % telnet localhost 119

Trying 127.0.0.1...

Connected to localhost.

Escape character is “^]”.

200 Welcome to My News Server (Typhoon v1.2.3)

AUTHINFO USER oliver

381 More Authentication Required

AUTHINFO PASS welcome

Прослушивание rexec (порт 512)

Сервис rexec, называемый rexеcd в большинстве UNIX-операционных систем, является традиционным сервисом, используемым для удаленного выполнения команд. Сервис выполняет аутентификацию посредством послания имени пользователя и пароля от клиента серверу в открытом виде. Сервис получает буфер от клиента, состоящий из следующих данных:

• номер порта в ASCII, указание порта серверу, на который посылать стандартное сообщение об ошибке. Этот порт на хосте клиента, который будет ожидать соединения. 0 указывается, в случае если это не требуется, данная строка разделяется NULL;

• разделенное NULL-имя пользователя. Длина 16 символов или меньше;

• разделенный NULL-пароль. Длина 16 символов или меньше;

• разделенная NULL-команда для выполнения на удаленном хосте.

0oliverwelcometouch /tmp/hello

Если аутентификация прошла успешно, сервером возвращается NULL, в противном случае значение 1 в дополнение к строке ошибки. Прослушивание rlogin (порт 513)

Протокол rlogin предоставляет практически такую же функциональность, как и протокол Telnet, объединенный с механизмом аутентификации протокола rexec с некоторыми исключениями. Он поддерживает доверительные отношения, которые указывают посредством файла rhosts в домашней директории пользователя. Этот файл содержит список тех пользователей и хостов, на которых они находятся, которым разрешено подключаться к указанным учетным записям без пароля. Аутентификация проводится путем доверия тому, что пользователь удаленного клиента rlogin говорит, кто он или она. Данный механизм аутентификации работает только между UNIX-системами и является чрезвычайно некорректным во многих отношениях; поэтому он не используется широко в сетях на сегодняшний день. Если доверительных отношений не существует, имя пользователя и пароль передаются в открытом виде по этому протоколу, как и у rexec:

• номер порта в ASCII, указание порта серверу, на который посылать стандартное сообщение об ошибке. Этот порт на хосте клиента, который будет ожидать соединения. 0 указывается, в случае если это не требуется, данная строка разделяется NULL;

• разделенное NULL-имя пользователя. Длина 16 символов или меньше;

• разделенный NULL-пароль. Длина 16 символов или меньше;

• разделенная NULL-команда для выполнения на удаленном хосте.

Сервер возвращает 0, чтобы показать, что он получил эти данные. Если аутентификация посредством автоматического механизма не удается, соединение передается программе входа в систему, далее вход в систему проходит так, как будто пользователь подключился с помощью сервиса Telnet.

X11 Window-система использует «магическую булочку» («magiccookie») для авторизации клиентов, пытающихся подключиться к серверу. Случайно сгенерированный 128-битный идентификатор посылается клиентами X11 во время соединения к серверу X Window. Перехватив данный идентификатор, нарушитель может использовать его для подключения к тому же серверу X Window. Обычно идентификатор хранится в файле . Xauthority в домашней директории пользователя. Данный идентификатор передается серверу X Window программой xdm при входе в систему.

Сетевая файловая система (NFS), созданная компанией Sun Microsystems, для разрешения доступа к конкретному файлу или директории на файловом сервере использует так называемый дескриптор файла NFS. Прослушивая сеть на наличие дескрипторов файла NFS, существует возможность перехвата данного дескриптора и использования его для получения доступа к ресурсу. К сожалению, протокол NFS использует открытую сетевую обработку – удаленный вызов процедуры (ONC-RPC) для выполнения операций, представляющих механизм аутентификации, более сложный, чем механизм аутентификации открытым текстом. Данный факт не обеспечивает большую защиту; однако делает сложным приведение примера в данной книге. Процесс, который делает легитимным доступ клиента NFS к файловой системе на сервере, следует далее.

• Пытаясь подмонтировать удаленную файловую систему, пользователь посылает запрос на монтирование.

• Локальная операционная система связывается с сервисом удаленного вызова процедур rpc.mountd на удаленном хосте, посылая ему имя файловой системы, к которой она хочет получить доступ.

• Программа mountd производит проверку достоверности доступа для определения, пришел ли запрос от привилегированного порта на хосте клиента и есть ли разрешение у клиентского хоста на доступ к данному хосту.

• Программа mountd посылает клиенту ответ, включающий дескриптор файла NFS, который предоставляет возможность доступа к корневому каталогу файловой системы, доступ к которой пользователь хочет получить.

• Программа клиента далее связывается демоном NFS (nfsd) на целевом хосте, передает дескриптор файла и получает доступ к ресурсу.

Операционная система Windows поддерживает несколько разных типов аутентификации, каждый из которых постепенно увеличивает свою безопасность. Использование слабых механизмов аутентификации Windows NT, как объясняется далее, создает одно из самых слабых звеньев в безопасности Windows NT. Типы поддерживаемых механизмов аутентификации описаны ниже.

• Открытый текст. Пароли передаются по сети в открытом виде.

• Управляющая программа локальной сети (LAN Manager). Используется слабый механизм запроса-ответа, при котором сервер посылает запрос клиенту, клиент использует его для операции зашифрования кэша пароля пользователя и далее посылает его обратно серверу. Сервер проделывает то же самое и сравнивает результаты для аутентификации пользователя. Механизм, которым данный кэш был преобразован до передачи, является слабым, и исходный кэш может быть перехвачен из сети и взломан довольно просто. В Windows NT 4, несмотря на то что используется более стойкий механизм аутентификации управляющей программы локальной сети NT (NTLM), LM-кэш все еще посылается через сеть вместе с NTLM-кэшем, что понижает общую защиту до защиты механизма LM.

• Управляющая программа локальной сети NT (NTLM) и Управляющая программа локальной сети NT v2 (NTLMv2). NTLM и NTLMv2 предоставляют намного более стойкий механизм запроса-ответа, который намного усложняет процесс взлома перехваченного запроса аутентификации. NTLMv2 был представлен в релизе Service Pack 4 для Windows NT 4.0. NTLMv2 должен использоваться, если возможно, однако необходимо удостовериться, что ваши клиенты поддерживают данный протокол. В случае необходимости нужно установить дополнительное программное обеспечение на клиентах для использования NTLMv2.

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

Данный текст является ознакомительным фрагментом.