Tcp Fragmenting (tcp-сканирование с использованием ip-фрагментации)
TCPфрагментация сама по себе не является методом сканирования, но позволяет скрыть применение других методов. Заключается она в том, что при отправкеTCPпакет разбивается на несколько сегментов. На стороне сервераIP-фрагменты "собираются" в одинTCP-пакет и производится его обработка. Иногда это может привести к не предсказуемым результатам, т.к. заголовок пакета может оказаться фрагментированным. Некоторые хосты не могут обрабатывать и собирать очень маленькие сегменты, и это может привести сбоям или даже перезагрузкам хостов.
Из-за того, что большинство IDSиспользуют сигнатуры для обнаружения попыток сканирования, фрагментация помогает обходить такие методы фильтрации и обнаружения.
Преимущества:обходитIDS, сложно логируется
Недостатки:возможны проблемы с получением пакетов на исследуемом хосте
Остальные методы сканирования
Эта категория содержит методы, которые не могут быть разделены по категориям скрытности, но все еще актуальны.
СканированиеUdp-портов проверкойIcmp-сообщения "Порт недоступен"
Этот метод также предназначен для определения состояния портов сервера. Основным отличием является использование протокола 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-портов кажется не таким уж бессмысленным.
Если пакет приходит на открытый порт, сервер не отвечает. Повторные посылки пакетов уменьшают вероятность ложного определения состояния порта:
Если пакет приходит на закрытый порт, отсылается ICMP-сообщение "Порт недоступен":
Преимущества:возможно сканирование неTCPпортов, обходитIDS
Недостатки:необходимы права администратора (root), пакеты могут быть легко блокированы, метод легко обнаруживается