Техника сканирования портов. Аттестационная работа
Было разработано огромное количество различных методов для поиска протоколов и портов, которые "прослушивает" удаленная машина. Все методы имеют определенные преимущества и недостатки. Ниже рассмотрены наиболее часто используемые из них.
Сканирование сервера с использованием ICMP-эха
Перед непосредственным сканированием портов удаленного хоста необходимо выяснить, какие хосты в сети являются функционирующими, и определить их адреса. Особенно это важно при сканировании группы хостов либо при сканировании определенного сегмента сети.
Данный метод работает аналогично команде ping (пингование - определение ответа). В качестве запроса хост отправляет серверу ICMP-сообщение и ожидает получения ответа, также представляющего собой ICMP-сообщение (т.н. ICMP-эхо). Варьируя время ожидания ответа на ping-запрос, можно сканировать большие сети.
Данный метод является основным для сканирования портов по протоколу TCP. Функция connect позволяет хосту соединиться с любым портом сервера. Если порт, указанный в качестве параметра функции, прослушивается сервером (т.е. порт открыт для соединения), то результатом выполнения функции будет установление соединения с сервером по указанному порту. В противном случае, если соединение не установлено, то порт с указанным номером является закрытым.
Этот метод обладает одним серьезным преимуществом: его может применить любой пользователь, не обладающий никакими привилегиями на хосте. Другое преимущество - скорость исследования. Последовательный перебор портов путем вызова функции connect для очередного номера порта, определение его состояния и закрытие соединения - достаточно долгий процесс. Однако его можно ускорить, применив метод "параллельного просмотра" с использованием неблокированного соединения (non-blocked socket). Такой метод позволяет определить состояние практически всех портов сервера одновременно.
Большим недостатком данного метода является возможность обнаружения и фильтрации такого рода сканирования, причем сделать это достаточно легко. Log-файл сканируемого сервера укажет службам, отвечающим за внешние подключения, на наличие многочисленных попыток подключения с одного адреса и ошибок установления соединения (поскольку хост исследующего после соединения с сервером сразу обрывает его), а те, в свою очередь, немедленно заблокируют доступ к серверу для хоста с данным адресом.
Сканирование TCP-портов флагом SYN
Данный метод известен еще как "сканирование с установлением наполовину открытого соединения" (half-open scanning), поскольку установление полного TCP-соединения не производится. Вместо этого хост отправляет на определенный порт сервера SYN-пакет, как бы намереваясь создать соединение, и ожидает ответ. Наличие в ответе флагов SYN|ACK означает, что порт открыт и прослушивается сервером. Получение в ответ TCP-пакета с флагом RST означает, что порт закрыт и не прослушивается.
В случае приема SYN|ACK-пакета хост немедленно отправляет RST-пакет для сброса устанавливаемого сервером соединения. Преимущество данного метода, прежде всего, заключается в том, что лишь немногие серверы способны зарегистрировать такого рода сканирование. Пользователь, должен обладать статусом Root на хосте, с которого производится сканирование. Если статус будет ниже Root, то пользователь попросту не сможет программно сформировать одиночный SYN-пакет.
Сканирование TCP-портов флагом FIN
Как уже говорилось, лишь немногие серверы способны отследить попытку SYN-сканирования их портов. Так, некоторые файрволлы (программы защиты портов на сервере) и пакетные фильтры "ожидают" поддельные SYN-пакеты на закрытые порты защищаемого ими сервера, и специальное программное обеспечение типа synlogger или courtney распознает попытку SYN-сканирования. Если сервер прерывает соединение после опроса нескольких портов, используется FIN-сканирование.
FIN-пакеты способны обойти эти средства защиты. Идея заключается в том, что, согласно RFC 793, на прибывший FIN-пакет на закрытый порт сервер должен ответить RST-пакетом. FIN-пакеты на открытые порты игнорируются сервером. Однако не все ОС придерживаются этой рекомендации. Так, ОС Windows 95/98/NT, по всей видимости, имеют иммунитет к такому сканированию, однако большинство ОС являются восприимчивыми. Таким образом, совместно используя SYN и FIN-сканирование можно с успехом обойти средства защиты сервера и просканировать его порты.
Сканирование TCP-портов флагами SYN|FIN с использованием IP-фрагментации
Данный метод представляет собой комбинацию SYN и FIN-сканирования с небольшим усовершенствованием. TCP-пакет (SYN или FIN-пакет, имеющий небольшой размер) разбивается на стороне хоста на пару IP-фрагментов меньшего размера, и эта пара IP-фрагментов отправляется серверу. На стороне сервера IP-фрагменты "собираются" в один TCP-пакет и производится его обработка (те же действия, как и при SYN или FIN-сканировании).
Фрагментация позволяет уменьшить вероятность обнаружения сканирования фильтрами пакетов и другим подобным оборудованием. Однако при этом следует быть очень осторожным, поскольку некоторые программы имеют обыкновение "зависать" при попытке обработки такого маленького IP-фрагмента.
Сканирование TCP-портов методом reverse-ident (обратной идентификации)
Протокол ident (RFC 1413) позволяет определить имя (username (имя пользователя) или login, указанное при входе в систему) владельца любого запущенного на сервере процесса, связанного с ним, даже если сам этот процесс не инициализировал TCP-соединение. Так, например, имеется возможность подключиться к http-порту и затем использовать identd, чтобы определить, работает ли на сервере пользователь root. Это может быть сделано только при установлении "полного" TCP-соединения к порту исследуемого сервера.
Сканирование TCP-портов с использованием атаки "Прорыв через FTP"
Физический и канальный уровень модели TCP/IP аналогичны соответствующим уровням OSI:
на физическом уровне осуществляется физическое соединение между компьютерной системой и физической средой передачи. Он определяет расположение кабельных контактов, напряжение питания и т.п. Единицей данных на этом уровне является бит;
на канальном уровне осуществляется пакетирование данных для передачи и распакетирование для приема. Единица данных на этом уровне называется фреймом;
на сетевом уровне осуществляется маршрутизация данных в сети. Единицей данных этого уровня является дэйтаграмма.
Интересной "возможностью" протокола FTP (RFC 959) является поддержка т.н. "уполномоченных" (proxy) соединений. Другими словами, атакующий, находясь на сервере source.com, может подключиться к интерпретатору (Protocol Interpreter) протокола FTP-сервера taregt.com для установления контроля над сетевым соединением. Затем атакующий дает запрос IP сервера инициализировать активный DTP-сервер (Data Transfer Process) и отправить через него любой файл на любой узел Internet !
Данная особенность (известная, кстати, с 1985 года) может использоваться для похищения почты и новостей, "взлома" серверов, заполнения их дисков, обхода файрволлов, и на практике подобную деятельность очень сложно отследить. В нашем случае можно осуществить сканирование TCP-портов исследуемого сервера с помощью proxy-FTP. Так, пройдя через файрволл, хост соединяется с FTP-сервером, и затем сканируются порты, доступ к которым был заблокирован файрволлом (например, 139-й порт - самый уязвимый порт ОС Windows - Net BIOS). Кроме того, если 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 вместо протокола TCP. Не смотря на то, что организация протокола UDP проще, чем TCP, сканировать UDP-порты гораздо труднее. Это связано, прежде всего, с концепцией протокола UDP как протокола с негарантированной доставкой данных. Поэтому UDP-порт не посылает подтверждение приема запроса на установление соединения, и нет никакой гарантии, что отправленные UDP-порту данные успешно дойдут до него.
К счастью, большинство серверов в ответ на пакет, прибывший на закрытый UDP-порт, отправляют ICMP-сообщение "Порт недоступен" (Port Unreachable - PU). Таким образом, если в ответ на UDP-пакет пришло ICMP-сообщение PU, то сканируемый порт является закрытым, в противном случае (при отсутствии PU) порт открыт. Поскольку нет гарантии, что запросы от хоста дойдут до сервера, пользователь должен позаботиться о повторной передаче UDP-пакета, который, по всей видимости, оказался потерянным.
Этот метод работает очень медленно из-за использования на некоторых машинах "компенсации" (RFC 1812 раздел 4.3.2.8), ограничивающей частоту генерирования ICMP-сообщений об ошибке. Например, ядро Linux ограничивает частоту генерирования ICMP-сообщения "адресат недостижим" (Destination Unreachable) до 80 сообщений за 4 секунды, с простоем 0,25 секунды, если это ограничение было превышено. Кроме того, для использования данного метода (а именно - для обнаружения ICMP-сообщений об ошибке) пользователь должен обладать статусом Root на хосте, с которого производится сканирование.
Может показаться, что сканирование UDP-портов не дает той полноты информации, какую можно получить при сканировании TCP-портов. Однако, принимая во внимание существующие (хотя и не многочисленные) "дыры" в службах, использующих протокол UDP (например, "дыру" в rpcbind-демоне ОС Solaris, который может находится на любом UDP-порту с номером выше 32770), сканирование UDP-портов кажется не таким уж бессмысленным.
Сканирование UDP-портов с использованием функций recvfrom() и write()
Этот метод используется в случае, когда пользователь, проводящий сканирование, не обладает статусом Root на хосте. Поскольку не-root пользователь не может "читать" ICMP-сообщение PU, в ОС, поддерживающих механизм сокетов (например в Linux), имеется возможность получения информации о состоянии UDP-порта косвенным способом. Так, например, попытка вызова функции write() на закрытый порт обычно приводит к возникновению ошибки.
Функция recvfrom() в этом плане более информативна. Вызов ее на неблокированный UDP-сокет сервера обычно возвращает ошибку EAGAIN (Try Again - "попытайтесь еще раз", код 13) в случае, когда ICMP-сообщение не было принято, и ECONREFUSED (Connection Refused - "соединение закрыто", код 111), если ICMP-сообщение было принято. Таким образом, по этим признакам также возможно определить состояние портов сканируемого сервера.
Направленный шторм ложных TCP-запросов на создание соединения
На каждый полученный TCP-запрос на создание соединения операционная система должна сгенерировать начальное значение идентификатора ISN и отослать его в ответ на запросивший хост. При этом, так как в сети Internet (стандарта IPv4) не предусмотрен контроль за IP-адресом отправителя сообщения, то невозможно отследить истинный маршрут, пройденный IP-пакетом, и, следовательно, у конечных абонентов сети нет возможности ограничить число возможных запросов, принимаемых в единицу времени от одного хоста. Поэтому возможно осуществление типовой атаки "Отказ в обслуживании", которая будет заключаться в передаче на атакуемый хост как можно большего числа ложных TCP-запросов на создание соединения от имени любого хоста в сети. При этом атакуемая сетевая ОС в зависимости от вычислительной мощности компьютера либо - в худшем случае - практически зависает, либо - в лучшем случае - перестает реагировать на легальные запросы на подключение (отказ в обслуживании).
Это происходит из-за того, что для всей массы полученных ложных запросов система должна, во-первых, сохранить в памяти полученную в каждом запросе информацию и, во-вторых, выработать и отослать ответ на каждый запрос. Таким образом, все ресурсы системы "съедаются" ложными запросами: переполняется очередь запросов, и система занимается только их обработкой.
Недавно в Сети был отмечен новый тип атак. Вместо типичных атак Denial of Service хакеры переполняют буфер
пакетов корпоративных роутеров не с единичных машин, а с целых тысяч компьютеров-зомби.
Такие атаки способны блокировать каналы мощностью вплоть до Т3 (44.736 Мбит/c) и уже отмечено несколько таких случаев. Опасность атаки становится тем важнее, чем больше бизнесов используют частные сети типа VPN и другие Интернет-технологии. Ведь отказ канала у публичного провайдера приведет в этом случае не просто к отключению отдельных пользователей, а к остановке работы огромных корпораций.
В этом случае существуют трудности в определении источника атаки - ложные пакеты идут с различных неповторяющихся IP-адресов. "Зомби-атаку" называют самой сложной из известных. На одинокую жертву нападает целая армия, и каждый зомби бьет только один раз.
Приемлемых способов защиты от подобных атак в сети стандарта IPv4 нет, так как невозможен контроль за маршрутом сообщений. Для повышения надёжности работы системы можно использовать по возможности более мощные компьютеры, способные выдержать направленный шторм ложных запросов на создание соединения.
