Определение активных портов удаленного компьютера

Алексей Волков, Вячеслав Семенов

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

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

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

Как и везде, в организации механизма портов имеются свои недостатки. Любой пользователь имеет возможность исследовать сетевое окружения сервера методом опроса его портов. Достаточно лишь послать «лавину» пакетов на все возможные номера портов сервера (1-65535), и по тому, от каких портов будут (или не будут) получены ответы, определить открытые порты и службы, работающие на исследуемом сервере.

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

Методы сканирования TCP-портов

Определение состояния сервера методом ICMP-сканирования

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

В сетях, организованных на базе стека протоколов TCP/IP, для этой цели используется протокол ICMP [1]. Данный протокол является вспомогательным и позволяет маршрутизатору сообщать конечному узлу об ошибках либо непредвиденных ситуациях, которые имели место при передаче IP-дейтаграммы от этого узла.

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

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

Для программной реализации данного метода пользователю необходимо знать некоторые особенности построения подобных запросов. Любое ICMP-сообщение имеет два уровня инкапсуляции в IP-дейтаграмму (см. рис.1).

Рисунок 1: Инкапсуляция ICMP-сообщения

В начале любого ICMP-сообщения находятся три поля: «Тип сообщения», «Код» (причина ошибки) и «Контрольная сумма». Поле “Тип” определяет смысл ICMP-сообщения и соответствующий ему формат. Значения этого поля приведены в таблице 1.

Таблица 1

В рассматриваемом методе используются типы сообщений «Запрос эха» (8) и «Ответ на эхо» (0). Обычно запрос эха и связанный с ним ответ используются для проверки достижимости получателя (т.е. сканируемого сервера) IP-дейтаграммы и его способности отвечать на запросы. Формат ICMP-сообщений «запрос эха» и «ответ на запрос эха» показан на рис.2.

Рисунок 2: Формат сообщения "запрос эха" и ответа на него

Поле «Необязательные данные» имеет переменную длину и содержит данные, которые необходимо вернуть отправителю. Поля «Идентификатор» и «Последовательный номер» используются отправителем для проверки соответствия ответов запросам.

Так как запрос эха и ответ на него передаются в IP-дейтаграммах, то успешный прием ответа свидетельствует о работоспособности основных частей транспортной системы, т.е. выполнена маршрутизация, работоспособны все промежуточные маршрутизаторы, получатель активен и работает корректно, программное обеспечение протоколов IP и ICMP выполняет свои функции. Иными словами, при получении ответа от сканируемого сервера на отправленный ему «запрос эха» свидетельствует о том, что сервер работает и, возможно, ожидает запрос на соединение.

Во многих операционных системах программа, используемая для посылки запроса эха, называется ping. По этой причине запрос эха называют еще ping-запросом. Программа ping специально предназначена для определения состояния любого объекта сети, имеющего собственный IP-адрес.

При сканировании больших сетей задержка во времени между посылкой запроса и получением ответа на него может превысить установленное значение, в результате чего ping может неправильно интерпретировать состояние объекта и указать на отсутствие к нему доступа. Аналогичная ситуация может произойти при «ручном» формировании запроса эха. В обоих случаях этого можно избежать, увеличив время ожидания ответа на ping-запрос.

Сканирование TCP-портов функцией connect()

Данный метод использовался в самом начале развития технологии сканирования, однако до сих пор является основным и единственным в некоторых операционных системах (Windows), поддерживающих механизм сокетов, для сканирования портов по протоколу TCP. Функция connect() позволяет хосту соединиться с любым портом сервера. Если порт, указанный в качестве параметра функции, прослушивается сервером (т.е. порт открыт для соединения), то в результате выполнения функции connect(n) будет установлено соединение с сервером по указанному порту n. В противном случае, если соединение не установлено, то порт с номером n является закрытым.

Этот метод обладает некоторыми преимуществами. Во-первых, его может применить любой пользователь, не обладающий никакими привилегиями на хосте. Во-вторых, данный метод обеспечивает довольно высокую скорость исследования. Последовательный перебор портов путем вызова функции connect() для каждого номера порта, определение его состояния и закрытие соединения – достаточно долгий процесс. Однако его можно ускорить, применив метод «параллельного просмотра» с использованием неблокированного ввода/вывода (non-blocked I/O). Такой метод позволяет практически одновременно определить состояние всех портов сервера.

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

Сканирование TCP-портов флагом SYN

Данный метод известен еще как «сканирование с установлением наполовину открытого соединения» (half-open scanning), поскольку полное установление TCP-соединения не производится. Рассмотрим схему создания TCP-соединения, описанную в протоколе TCP [2]. В исходном состоянии сервер «прослушивает» порты в ожидании соединения. Соединение между хостом и сервером не установлено.

Рисунок 3: Первый этап установления соединения

Рисунок 4: Второй этап установления соединения

Рисунок 5: Третий этап установления соединения

Рисунок 6: Хост передает данные серверу

Как видно, процесс установления соединения предусматривает взаимный обмен пакетами синхронизации между сервером и хостом. Каждая из сторон должна получить первоначальный номер очереди (ISS) «партнера» и послать подтверждение. Пакет синхронизации представляет собой сформированное по правилам протокола TCP сообщение с выставленным в нем флагом SYN (либо SYN и ACK для подтверждения синхронизации). Формат заголовка протокола TCP и назначение флагов приведено на рис.7.

Рисунок 7: Формат TCP-сообщения

Алгоритм сканирования следующий. Хост отправляет на определенный порт сервера SYN-пакет, как бы намереваясь создать соединение, и ожидает ответ. Наличие в ответе флагов SYN|ACK означает, что порт открыт и прослушивается сервером. Получение в ответ TCP-пакета с флагом RST означает, что порт закрыт и не прослушивается.

В случае приема SYN|ACK-пакета хост немедленно отправляет RST-пакет для сброса устанавливаемого сервером соединения и не продолжает процесс обмена синхропакетами. Таким образом, производится проверка способности сканируемого сервера установить соединение по указанному порту.

Преимущество данного метода заключается в том, что лишь немногие серверы способны зарегистрировать такого рода сканирование без использования специальных средств защиты. Метод возможно использовать только в случае, если на хосте, с которого производится сканирование, установлена операционная система из семейства UNIX. Кроме того, пользователь должен обладать статусом root, в противном случае пользователь попросту не сможет программно сформировать одиночный SYN-пакет.

Сканирование TCP-портов флагом FIN

Как уже говорилось, лишь немногие серверы способны отследить попытку SYN-сканирования их портов. Так, некоторые файрволлы и пакетные фильтры «ожидают» поддельные SYN-пакеты на закрытые порты защищенного ими сервера, и специальное программное обеспечение типа synlogger или courtney распознает попытку SYN-сканирования. Если сервер обрывает соединение после опроса нескольких портов, используется FIN-сканирование.

В этом методе используются FIN-пакеты, используемые в процедуре закрытия соединения. Пакет предусматривает установку в TCP-сообщении флага FIN. Рассмотрим процедуру закрытия соединения.

Рисунок 8: Хост передает серверу данные

Рисунок 9: Первый этап закрытия соединения

Рисунок 10: Второй этап закрытия соединения

Рисунок 11: Третий этап закрытия соединения

Рисунок 12: четвертый этап закрытия соединения

FIN-пакеты способны обойти средства защиты сети. Идея заключается в том, что согласно [2], на прибывший на закрытый порт FIN-пакет сервер должен ответить RST-пакетом (TCP-пакет с установленным в нем флагом RST). FIN-пакеты на открытые порты игнорируются сервером.

Аналогичный прием используется при Xmas и NULL-сканировании, за исключением того, что в первом случае в посылаемом сканируемому хосту пакете установлены флаги FIN|URG|PSH (отсюда название - «новогодняя елка»), в то время как во втором случае какие-либо флаги в пакете отсутствуют.

Заметим, что не все типы ОС следуют рекомендации [2], и потому данный метод к ним неприменим. Так, ОС Windows 95/98/NT, по всей видимости, имеют иммунитет к такому сканированию, однако большинство ОС являются восприимчивыми. Таким образом, совместно используя SYN и FIN-сканирование можно с успехом обойти средства защиты сервера и просканировать его порты.

Сканирование TCP-портов флагами SYN(FIN) с использованием IP-фрагментации

Данный метод представляет собой комбинацию SYN и FIN-сканирования с небольшим усовершенствованием. Он основан на использовании функциональной особенности протокола IP [3], называемой фрагментацией.

Фрагментация – это процесс разделения большого пакета данных на несколько частей перед непосредственной передачей его в сеть для получения размера фрагмента, соответствующего стандарту используемой сети (т.н. параметр MTU – Maximum Transmission Unit, максимальный размер блока). Фрагментация пакета на стороне источника и его сборка на стороне приемника осуществляется автоматически. Каждая фрагментированная часть исходного пакета имеет одинаковый формат. Этот метод позволяет маршрутизировать фрагменты независимо друг от друга.

Рассмотрим пример фрагментации пакета с приведением конкретных значений полей заголовка дейтаграммы протокола IP. На рис.13 показан исходный заголовок дейтаграммы.

Рисунок 13: формат IP-заголовка нефрагментированного пакета

Общая длина фрагментируемой дейтаграммы составляет 472 байта (20 байт заголовок и 452 байта данных). Максимальное значение MTU примем равным 280 байт. На рис.14 приведены значения полей заголовков двух полученных в результате фрагментации дейтаграмм. первый фрагмент возникает после фрагментации исходной дейтаграммы по границе 256 байт.

Поля «Идентификатор», «Флаги» и «Смещение фрагмента» предназначены для управления процессами фрагментации и сборки дейтаграммы.

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

Поле «Флаги» указывает на возможность фрагментации. Нулевое состояние первого бита разрешает выполнять фрагментацию, единичное – запрещает. Второй бит определяет последний пакет дейтаграммы.

Поле «Смещение фрагмента» используется для указания места данного фрагмента в дейтаграмме. Смещение измеряется группами по 8 байт (т.е. в нашем случае смещение составляет 32 группы по 8 байт, или 256 байт). Первый фрагмент всегда имеет нулевое смещение. Значение остальных полей вы найдете в [3].

Рисунок 14: пример фрагментации дейтаграммы

Таким образом, TCP-пакет (SYN или FIN-пакет, имеющий размер порядка 24 байт) разбивается на стороне хоста на пару IP-фрагментов меньшего размера, и эта пара IP-фрагментов отправляется серверу. На стороне сервера IP-фрагменты «собираются» в один TCP-пакет и производится его обработка (те же действия, как и при SYN или FIN-сканировании).

В этом случае фрагментация позволяет уменьшить вероятность обнаружения сканирования фильтрами пакетов и другим подобным оборудованием. Однако при этом следует быть очень осторожным, поскольку некоторые программы имеют обыкновение «зависать» при попытке обработки такого маленького IP-фрагмента.

Сканирование TCP-портов методом reverse-ident (обратной идентификации)

Протокол ident [4] позволяет определить имя (username или login, указанное при входе в систему) владельца любого запущенного на сервере процесса, связанного с ним, даже если сам этот процесс не инициализировал TCP-соединение.

Протокол ident иначе называется протоколом аутентификации сервера. За ним зарезервирован 113-й TCP-порт, который используется демоном (синоним драйвера в ОС Windows) identd, выполняющим функции аутентификации согласно протокола ident, для приема запросов и передачи ответов на них. Этот процесс происходит следующим образом.

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

  <Порт сервера>,<Порт клиента>

где <Порт сервера> - это номер порта сервера, на котором запущен identd и о котором необходимо получить информацию, а <Порт клиента> - номер порта на хосте, посылающем запрос серверу, на который сервер должен прислать ответ. Например:

  6191 , 23

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

  <Порт сервера>,<Порт клиента>:<Ответ>:<Дополн.инф.>

где <Порт сервера> и <Порт клиента> копируются из запроса хоста, <Ответ> представляет собой ключевое слово, определяющее тип ответа, а <Дополн.инф.> является текстовой строкой, содержание которой зависит от типа ответа. Например:

  6193, 23 : USERID : UNIX : stjohns

6195, 23 : ERROR : NO-USER

Полный список возможных типов ответов приведен в [4].

Как и большинство программ, identd имеет некоторые интересные особенности функционирования, позволяющие получить требуемую информацию, не используя стандартный 113 порт и уж тем более не проходя процедуру аутентификации. Так, например, имеется возможность подключиться к http-порту и затем использовать identd чтобы определить, работает ли на сервере пользователь root.

К сожалению, это может быть сделано только при установлении «полного» TCP-соединения к порту исследуемого сервера, что позволяет системному администратору отследить ваши действия.

Сканирование TCP-портов с использованием атаки «Прорыв через FTP»

Интересной «возможностью» протокола FTP [5] является поддержка т.н. «уполномоченных» (proxy) соединений. Другими словами, атакующий, находясь на сервере source.com, может подключиться к интерпретатору протокола (Protocol Interpreter - PI) FTP-сервера target.com для установления контроля над сетевым соединением. Затем атакующий дает запрос PI сервера инициализировать активный DTP-сервер (Data Transfer Process) и отправить через него любой файл на любой узел Internet !

Данная особенность (известная, кстати, с 1985 года) может использоваться для похищения почты и новостей, «взлома» серверов, заполнения их дисков, обхода файрволлов, и на практике подобную деятельность очень сложно отследить. В нашем случае можно осуществить сканирование TCP-портов исследуемого сервера с помощью proxy-FTP. Так, пройдя через файрволл, хост соединяется с FTP-сервером, и затем сканируются порты, доступ к которым был заблокирован файрволлом (например, 139-й порт). Кроме того, если FTP-сервер позволяет читать и записывать данные в каталог (например /incoming), имеется возможность отправлять любые данные на обнаруженный открытый порт сервера.

Перед непосредственным сканированием порта необходимо установить соединение с FTP-сервером и использовать команду PORT с указанием номера интересующего порта. Таким образом серверу будет сообщено, что пассивный User-DTP на стороне  хоста ожидает приема через некоторый указанный порт. Затем необходимо дать команду LIST для текущего каталога, и FTP-сервер отправит данные о каталоге по каналу Server-DTP, соединенному с User-DTP по указанному порту.

Если указанный в команде PORT порт сервера открыт, результат выполнения LIST будет успешным (код ответа в этом случае будет 150 и 226). В противном случае будет иметь место подобный ответ:

425 Can’t build data connection: Connection Refused

После этого вновь используется команда PORT с указанием другого порта и операция повторяется.

Преимущества данного метода очевидны (невозможность отслеживания сканирования, обход файрволлов). К недостаткам относится прежде всего низкая скорость сканирования и то, что некоторые FTP-серверы наконец-то закрыли эту «дыру».

Методы сканирования UDP-портов

Сканирование UDP-портов проверкой ICMP-сообщения «Порт недостижим»

Этот метод также предназначен для определения состояния портов сервера. Основным отличием является использование протокола UDP [6] вместо протокола TCP. Не смотря на то, что организация протокола UDP проще, чем TCP, сканировать UDP-порты гораздо труднее. Это связано прежде всего с концепцией протокола UDP как протокола с негарантированной доставкой данных. Поэтому UDP-порт не посылает подтверждение приема запроса на установление соединения, и нет никакой гарантии, что отправленные UDP-порту данные успешно дойдут до него.

К счастью, большинство серверов в ответ на пакет, прибывший на закрытый UDP-порт, отправляют ICMP-сообщение «Порт недоступен» (Port Unreachable - PU). Таким образом, если в ответ на UDP-пакет пришло ICMP-сообщение «PU», то сканируемый порт является закрытым, в противном случае (при отсутствии «PU») порт открыт. Поскольку нет гарантии, что запросы хоста дойдут до сервера, пользователь должен позаботиться о повторной передаче UDP-пакета, который, по всей видимости, оказался потерянным.

Этот метод работает очень медленно из-за использования на некоторых машинах т.н. «компенсации» ([7], раздел 4.3.2.8), ограничивающей частоту генерирования ICMP-сообщений об ошибке. Например, ядро Linux ограничивает частоту генерирования ICMP-сообщения «адресат недостижим» (Destination Unreachable) до 80 сообщений за 4 секунды, с простоем ¼ секунды, если это ограничение было превышено. Кроме того, для использования данного метода (а именно – для обнаружения ICMP-сообщений об ошибке) пользователь должен обладать статусом root на хосте, с которого производится сканирование.

Сканирование UDP-портов с использованием функций recvfrom() и write()

Этот метод используется в случае, когда пользователь, проводящий сканирование, не обладает статусом root на хосте. Поскольку не-root пользователь не может «читать» ICMP-сообщение PU, в ОС, поддерживающих механизм сокетов (например в Linux), имеется возможность получения информации о состоянии UDP-порта косвенным способом. Так, например, попытка вызова функции write() на закрытый порт обычно приводит к возникновению ошибки.

Функция recvfrom() в этом плане более информативна. Вызов ее на неблокированный UDP-сокет сервера обычно возвращает ошибку EAGAIN (Try Again – «попытайтесь еще раз», код 13) в случае, когда ICMP-сообщение не было принято, и ECONREFUSED (Connection Refused – «соединение закрыто», код 111), если ICMP-сообщение было принято.

Может показаться, что сканирование UDP-портов не дает той полноты информации, какую можно получить при сканировании TCP-портов. Однако, принимая во внимание существующие (хотя и не многочисленные) «дыры» в службах, использующих протокол UDP (например, «дыру» в rpcbind-демоне ОС Solaris, который может находится на любом UDP-порту с номером выше 32770), сканирование UDP-портов кажется не таким уж бессмысленным.

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

Программная реализация сканера портов: SYNSCAN

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

Необходимо обратить внимание на то, что программа написана на языке C и работает исключительно под управлением ОС типа Linux. Это связано прежде всего с огромными трудностями при низкоуровневом программировании стека TCP/IP у закрытых коммерческих ОС, каковой является Windows 95/98/NT. В отличие от Windows, операционная система UNIX (и ее разновидность Linux) позволяет весьма гибко управлять TCP/IP, посылать и принимать специфические пакеты а также предоставляет очень богатые возможности по их обработке.

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

Сканер разработан для применения в операционной системе UNIX а также ее клонов типа Linux, FreeBSD и др. Программа полностью совместима с большинством из этих операционных систем. Приведенная версия откомпилирована и протестирована в ОС Linux Mandrake 7.0.

Перед непосредственны запуском программы вам необходимо получить статус root на системе, с которой вы производите ее запуск, а также убедиться в наличии компилятора gcc и библиотек, указанных в разделе #include приведенного исходного кода. Пользователям русской версии необходимо также установить поддержку кириллических шрифтов в кодировке koi-8r для корректного отображения сообщений программы.

После компиляции вы можете запустить программу. Формат вызова следующий:

./ synscan <source> <target> <max-port-to-scan> [-f filename]

где:    source – IP-адрес вашего хоста

          target – IP-адрес сканируемого хоста

          max-port-to-scan – верхняя граница диапазона сканируемых портов

          [-f filename] – имя файла для записи результатов сканирования (если не указан – результат отображается на экране).

При отсутствии одного из параметров (кроме имени файла) или неправильном его указания сканер выдаст соответствующее сообщение и прекратит работу. Исходный код английской версии программы приведен в файле synscan_eng.c, русской версии (кодировка KOI-8r) – synscan_rus.c.

Заключение

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

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

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

ЛИТЕРАТУРА

[1]     RFC 792: Internet Control Message Protocol (ICMP). DARPA Internet program. Protocol specification. J. Postel, Network Working Group, 1981.

[2]     RFC 793: Transmission Control Protocol (TCP). DARPA Internet program. Protocol specification. Information Sciences Institute, 1981.

[3]     RFC 791: Internet Protocol (IP). DARPA Internet program. Protocol specification. Information Sciences Institute, 1981.

[4]     RFC 1413: Identification Protocol. M. St. Johns, US Department of Defense, 1993.

[5]     RFC 959: File Transfer Protocol (FTP). J. Postel, J. Reynolds, ISI, 1985.

[6]     RFC 768: User Datagram Protocol. J. Postel, ISI, 1980.

[7]     RFC 1812: Requirements for IP Version 4 Routers. F. Baker, Cisco Systems, 1995.